On Mon, Nov 27, 2017 at 07:08:51AM +, Leendert van Doorn wrote:
> Hmm, this is almost 20 years old code (
>
> I think the original code did a burst write and didn't check for error
> conditions until the very last byte write. I seem to remember that
> there was some text in the original
On Mon, Nov 27, 2017 at 07:08:51AM +, Leendert van Doorn wrote:
> Hmm, this is almost 20 years old code (
>
> I think the original code did a burst write and didn't check for error
> conditions until the very last byte write. I seem to remember that
> there was some text in the original
Hi, Leendert!
On Mon, 2017-11-27 at 07:08 +, Leendert van Doorn wrote:
> Hmm, this is almost 20 years old code (
>
> I think the original code did a burst write and didn't check for
> error conditions until the very last byte write. I seem to remember
> that there was some text in the
Hi, Leendert!
On Mon, 2017-11-27 at 07:08 +, Leendert van Doorn wrote:
> Hmm, this is almost 20 years old code (
>
> I think the original code did a burst write and didn't check for
> error conditions until the very last byte write. I seem to remember
> that there was some text in the
Hmm, this is almost 20 years old code (
I think the original code did a burst write and didn't check for error
conditions until the very last byte write. I seem to remember that there was
some text in the original standard to that effect (this may have gone back as
far as IBM's ESS spec).
The
Hmm, this is almost 20 years old code (
I think the original code did a burst write and didn't check for error
conditions until the very last byte write. I seem to remember that there was
some text in the original standard to that effect (this may have gone back as
far as IBM's ESS spec).
The
[Cc'ing Dave and Leendeert]
Hi Jarkko,
> > It seems that the last byte was sent from the beginning (27084ef
> > [PATCH] tpm: driver for next generation TPM chips,), does anyone
> > remember the reason ?
>
> Sent from the beginning?
I went through the commit logs to see if any of the patch
[Cc'ing Dave and Leendeert]
Hi Jarkko,
> > It seems that the last byte was sent from the beginning (27084ef
> > [PATCH] tpm: driver for next generation TPM chips,), does anyone
> > remember the reason ?
>
> Sent from the beginning?
I went through the commit logs to see if any of the patch
On Thu, Nov 23, 2017 at 08:17:42PM +0530, Nayna Jain wrote:
> Yeah, you are right, the first version of this patch sent all the
> bytes together, but after hearing ddwg inputs, i.e. "The last byte was
> introduced for error checking purposes (history).", I reverted back to
> original to be safe.
On Thu, Nov 23, 2017 at 08:17:42PM +0530, Nayna Jain wrote:
> Yeah, you are right, the first version of this patch sent all the
> bytes together, but after hearing ddwg inputs, i.e. "The last byte was
> introduced for error checking purposes (history).", I reverted back to
> original to be safe.
> On Wed, Nov 22, 2017 at 06:52:03AM +,
> alexander.stef...@infineon.com wrote:
> > > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when
> > > > > > trying
> to
> > > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent
> tests
> > > > > seem to take an
> On Wed, Nov 22, 2017 at 06:52:03AM +,
> alexander.stef...@infineon.com wrote:
> > > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when
> > > > > > trying
> to
> > > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent
> tests
> > > > > seem to take an
On Wed, Nov 22, 2017 at 06:52:03AM +, alexander.stef...@infineon.com wrote:
> > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when
> > > > > trying to
> > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent tests
> > > > seem to take an unusual amount of
On Wed, Nov 22, 2017 at 06:52:03AM +, alexander.stef...@infineon.com wrote:
> > > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when
> > > > > trying to
> > > > send large amounts of data, e.g. with TPM2_Hash, and subsequent tests
> > > > seem to take an unusual amount of
> > > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> > > >> The TPM burstcount status indicates the number of bytes that can
> > > >> be sent to the TPM without causing bus wait states. Effectively,
> > > >> it is the number of empty bytes in the command FIFO.
> > > >>
> > > >>
> > > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> > > >> The TPM burstcount status indicates the number of bytes that can
> > > >> be sent to the TPM without causing bus wait states. Effectively,
> > > >> it is the number of empty bytes in the command FIFO.
> > > >>
> > > >>
> > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> > >> The TPM burstcount status indicates the number of bytes that can
> > >> be sent to the TPM without causing bus wait states. Effectively,
> > >> it is the number of empty bytes in the command FIFO.
> > >>
> > >> This patch
> > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> > >> The TPM burstcount status indicates the number of bytes that can
> > >> be sent to the TPM without causing bus wait states. Effectively,
> > >> it is the number of empty bytes in the command FIFO.
> > >>
> > >> This patch
> On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> >> The TPM burstcount status indicates the number of bytes that can
> >> be sent to the TPM without causing bus wait states. Effectively,
> >> it is the number of empty bytes in the command FIFO.
> >>
> >> This patch optimizes the
> On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> >> The TPM burstcount status indicates the number of bytes that can
> >> be sent to the TPM without causing bus wait states. Effectively,
> >> it is the number of empty bytes in the command FIFO.
> >>
> >> This patch optimizes the
On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
The TPM burstcount status indicates the number of bytes that can
be sent to the TPM without causing bus wait states. Effectively,
it is the number of empty bytes in the command FIFO.
This patch optimizes the tpm_tis_send_data()
On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
The TPM burstcount status indicates the number of bytes that can
be sent to the TPM without causing bus wait states. Effectively,
it is the number of empty bytes in the command FIFO.
This patch optimizes the tpm_tis_send_data()
On Fri, Oct 20, 2017 at 02:42:54PM +, alexander.stef...@infineon.com wrote:
> > The TPM burstcount status indicates the number of bytes that can
> > be sent to the TPM without causing bus wait states. Effectively,
> > it is the number of empty bytes in the command FIFO.
> >
> > This patch
On Fri, Oct 20, 2017 at 02:42:54PM +, alexander.stef...@infineon.com wrote:
> > The TPM burstcount status indicates the number of bytes that can
> > be sent to the TPM without causing bus wait states. Effectively,
> > it is the number of empty bytes in the command FIFO.
> >
> > This patch
> The TPM burstcount status indicates the number of bytes that can
> be sent to the TPM without causing bus wait states. Effectively,
> it is the number of empty bytes in the command FIFO.
>
> This patch optimizes the tpm_tis_send_data() function by checking
> the burstcount only once. And if
> The TPM burstcount status indicates the number of bytes that can
> be sent to the TPM without causing bus wait states. Effectively,
> it is the number of empty bytes in the command FIFO.
>
> This patch optimizes the tpm_tis_send_data() function by checking
> the burstcount only once. And if
On Tue, Oct 17, 2017 at 04:32:30PM -0400, Nayna Jain wrote:
> The TPM burstcount status indicates the number of bytes that can
> be sent to the TPM without causing bus wait states. Effectively,
> it is the number of empty bytes in the command FIFO.
>
> This patch optimizes the
On Tue, Oct 17, 2017 at 04:32:30PM -0400, Nayna Jain wrote:
> The TPM burstcount status indicates the number of bytes that can
> be sent to the TPM without causing bus wait states. Effectively,
> it is the number of empty bytes in the command FIFO.
>
> This patch optimizes the
On Tue, Oct 17, 2017 at 04:32:30PM -0400, Nayna Jain wrote:
> The TPM burstcount status indicates the number of bytes that can
> be sent to the TPM without causing bus wait states. Effectively,
> it is the number of empty bytes in the command FIFO.
>
> This patch optimizes the
On Tue, Oct 17, 2017 at 04:32:30PM -0400, Nayna Jain wrote:
> The TPM burstcount status indicates the number of bytes that can
> be sent to the TPM without causing bus wait states. Effectively,
> it is the number of empty bytes in the command FIFO.
>
> This patch optimizes the
30 matches
Mail list logo
