On Wed, 25 Jun 2025 at 17:08, Jarkko Sakkinen wrote:
>
> On Wed, Jun 25, 2025 at 03:02:54PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Jun 20, 2025 at 03:08:10PM +0200, Stefano Garzarella wrote:
> > > From: Stefano Garzarella
> > >
> > > This driver does no
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
d and will require a new
version
- RFC:
https://lore.kernel.org/linux-integrity/20250311100130.42169-1-sgarz...@redhat.com/
[1] https://lore.kernel.org/linux-integrity/z8sfidehsg6ra...@kernel.org/
[2]
https://lore.kernel.org/linux-integrity/20250410135118.133240-1-sgarz...@redhat.com/
Stefano
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not imple
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not imple
From: Stefano Garzarella
Add a new `bufsiz` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `bufsiz` is
not used, but it will be used to implement devices with
On Fri, 23 May 2025 at 18:02, Jarkko Sakkinen wrote:
>
> On Thu, May 22, 2025 at 10:26:34AM +0200, Stefano Garzarella wrote:
> > On Wed, 21 May 2025 at 18:42, Jarkko Sakkinen wrote:
> > >
> > > On Wed, May 21, 2025 at 01:12:20PM +0300, Jarkko Sakkinen wrote:
> &g
On Wed, 21 May 2025 at 18:42, Jarkko Sakkinen wrote:
>
> On Wed, May 21, 2025 at 01:12:20PM +0300, Jarkko Sakkinen wrote:
> > > I tried, but the last patch (this one) is based on the series merged
> > > on the tip tree, where I introduced tpm_svsm.
> > > I can see that series in linux-next merged
On Tue, 20 May 2025 at 22:02, Jarkko Sakkinen wrote:
> On Tue, May 20, 2025 at 06:06:50PM +0200, Stefano Garzarella wrote:
> > On Thu, 15 May 2025 at 03:45, Jarkko Sakkinen wrote:
> > > On Wed, May 14, 2025 at 03:46:30PM +0200, Stefano Garzarella wrote:
> > >
On Thu, 15 May 2025 at 03:45, Jarkko Sakkinen wrote:
>
> On Wed, May 14, 2025 at 03:46:30PM +0200, Stefano Garzarella wrote:
> > From: Stefano Garzarella
> >
> > This driver does not support interrupts, and receiving the response is
> > synchronous with sendi
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not imple
From: Stefano Garzarella
Add a new `bufsiz` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `bufsiz` is
not used, but it will be used to implement devices with
.@redhat.com/
[1] https://lore.kernel.org/linux-integrity/z8sfidehsg6ra...@kernel.org/
[2]
https://lore.kernel.org/linux-integrity/20250410135118.133240-1-sgarz...@redhat.com/
Stefano Garzarella (4):
tpm: add bufsiz parameter in the .send callback
tpm: support devices with synchronous send()
t
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not imple
On Sat, May 10, 2025 at 10:44:38AM +0300, Jarkko Sakkinen wrote:
On Fri, May 09, 2025 at 10:57:10AM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
Add a new `buf_size` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not imple
From: Stefano Garzarella
Add a new `buf_size` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `buf_now` is
not used, but it will be used to implement devices
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not imple
re a new
version
- RFC:
https://lore.kernel.org/linux-integrity/20250311100130.42169-1-sgarz...@redhat.com/
[1] https://lore.kernel.org/linux-integrity/z8sfidehsg6ra...@kernel.org/
[2]
https://lore.kernel.org/linux-integrity/20250410135118.133240-1-sgarz...@redhat.com/
Stefano Garzarella (4):
On Wed, Apr 30, 2025 at 06:49:37PM +0300, Jarkko Sakkinen wrote:
On Mon, Apr 14, 2025 at 04:56:53PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set
On Wed, Apr 30, 2025 at 06:47:51PM +0300, Jarkko Sakkinen wrote:
On Mon, Apr 14, 2025 at 04:56:52PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set
On Wed, Apr 30, 2025 at 06:39:58PM +0300, Jarkko Sakkinen wrote:
On Mon, Apr 14, 2025 at 04:56:50PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
In preparation for the next commit, add a new `buf_size` parameter to
the `.send` callback in `tpm_class_ops` which contains the entire
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
From: Stefano Garzarella
In preparation for the next commit, add a new `buf_size` parameter to
the `.send` callback in `tpm_class_ops` which contains the entire buffer
size. In this patch it is pretty much ignored by all drivers, but it will
be used in the next patch.
Also rename the previous
On Mon, 14 Apr 2025 at 16:57, Stefano Garzarella wrote:
>
> From: Stefano Garzarella
>
> This driver does not support interrupts, and receiving the response is
> synchronous with sending the command.
>
> So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
>
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need to impl
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need the 4KB int
//lore.kernel.org/linux-integrity/z8sfidehsg6ra...@kernel.org/
[2]
https://lore.kernel.org/linux-integrity/20250410135118.133240-1-sgarz...@redhat.com/
Stefano Garzarella (4):
tpm: add buf_size parameter in the .send callback
tpm: support devices with synchronous send()
tpm/tpm_ftpm_tee: sup
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need the 4KB int
On Tue, Apr 08, 2025 at 06:31:30PM +0300, Jarkko Sakkinen wrote:
On Tue, Apr 08, 2025 at 10:32:06AM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need to impl
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
/20250403100943.120738-1-sgarz...@redhat.com/
Stefano Garzarella (4):
tpm: add buf_size parameter in the .send callback
tpm: support devices with synchronous send()
tpm/tpm_ftpm_tee: support TPM_CHIP_FLAG_SYNC
tpm/tpm_svsm: support TPM_CHIP_FLAG_SYNC
drivers/char/tpm/tpm_ftpm_tee.h | 4 -
From: Stefano Garzarella
In preparation for the next commit, add a new `buf_size` parameter to
the `.send` callback in `tpm_class_ops` which contains the entire buffer
size. In this patch it is pretty much ignored by all drivers, but it will
be used in the next patch.
Also rename the previous
On Thu, Aug 11, 2022 at 12:06 PM Sachin Sant wrote:
>
> 5.19.0-next-20220811 linux-next fails to build on IBM Power with
> following error:
>
> drivers/vdpa/vdpa_sim/vdpa_sim_blk.c: In function 'vdpasim_blk_handle_req':
> drivers/vdpa/vdpa_sim/vdpa_sim_blk.c:201:3: error: a label can only be part
37 matches
Mail list logo
