Re: Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-16 Thread Ken Goldman
On 8/14/2017 6:10 AM, Jarkko Sakkinen wrote: Nuvoton, ST Micro, and Infineon confirmed that the TPM empties a byte from the FIFO in under 1 usec. So, even with a static burst count, the entire FIFO would empty in under 10 usec. Does this break anything lets say in a decade time frame? If it

Re: Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-16 Thread Ken Goldman
On 8/14/2017 6:10 AM, Jarkko Sakkinen wrote: Nuvoton, ST Micro, and Infineon confirmed that the TPM empties a byte from the FIFO in under 1 usec. So, even with a static burst count, the entire FIFO would empty in under 10 usec. Does this break anything lets say in a decade time frame? If it

Re: Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-11 Thread Ken Goldman
On 8/9/2017 4:43 PM, Peter Huewe wrote: Yes that's bad, especially with current msleep(5) is actually msleep(20). However, please also keep in mind SPI tpms show a much higher burst count value, (255) our I2C TPM SLB9645 even shows something in the range of 1k. :) One of our platforms has a

Re: Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-11 Thread Ken Goldman
On 8/9/2017 4:43 PM, Peter Huewe wrote: Yes that's bad, especially with current msleep(5) is actually msleep(20). However, please also keep in mind SPI tpms show a much higher burst count value, (255) our I2C TPM SLB9645 even shows something in the range of 1k. :) One of our platforms has a

Re: Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-11 Thread Ken Goldman
On 8/9/2017 5:00 PM, Peter Huewe wrote: Since we are the linux kernel, we do have to care for legacy devices. And a system with LPC, PS2Mouse on SuperIO and a TPM are not that uncommon. And heck, we even have support for 1.1b TPM devices Understood. However, remember that SuperIO is a

Re: Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-11 Thread Ken Goldman
On 8/9/2017 5:00 PM, Peter Huewe wrote: Since we are the linux kernel, we do have to care for legacy devices. And a system with LPC, PS2Mouse on SuperIO and a TPM are not that uncommon. And heck, we even have support for 1.1b TPM devices Understood. However, remember that SuperIO is a

Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-09 Thread Peter Huewe
Hi Ken, (again speaking only on my behalf, not my employer) > Does anyone know of platforms where this occurs? > I suspect (but not sure) that the days of SuperIO connecting floppy > drives, printer ports, and PS/2 mouse ports on the LPC bus are over, and > such legacy systems will not have a

Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-09 Thread Peter Huewe
Hi Ken, (again speaking only on my behalf, not my employer) > Does anyone know of platforms where this occurs? > I suspect (but not sure) that the days of SuperIO connecting floppy > drives, printer ports, and PS/2 mouse ports on the LPC bus are over, and > such legacy systems will not have a

Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-09 Thread Peter Huewe
Hi Ken, (speaking on behalf of myself here, not my employer :) ) > On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote: >> Imho: NACK from my side. > After these viewpoints definitive NACK from my side too... > I responded to the thread comments separately. However, assuming NACK > is

Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

2017-08-09 Thread Peter Huewe
Hi Ken, (speaking on behalf of myself here, not my employer :) ) > On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote: >> Imho: NACK from my side. > After these viewpoints definitive NACK from my side too... > I responded to the thread comments separately. However, assuming NACK > is