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 do
On Tue, 15 Aug 2017 18:02:57 -0400
Ken Goldman wrote:
> On 8/13/2017 7:53 PM, msuchanek wrote:
> > About 500 out of 700 mainboards sold today has a PS/2 port which is
> > probably due to prevalence of legacy devices and usbhid limitations.
> >
> > Similarily many boards have serial and parallel
On 8/13/2017 7:53 PM, msuchanek wrote:
About 500 out of 700 mainboards sold today has a PS/2 port which is
probably due to prevalence of legacy devices and usbhid limitations.
Similarily many boards have serial and parallel hardware ports.
In all diagrams detailed enough to show these ports I h
On Mon, Aug 14, 2017 at 08:12:53AM -0400, Mimi Zohar wrote:
> On Mon, 2017-08-14 at 13:56 +0300, Jarkko Sakkinen wrote:
>
> > > > Since the main concern about this change is breaking old systems that
> > > > might potentially have other peripherals hanging off the LPC bus, can
> > > > we define a
On Mon, Aug 14, 2017 at 08:03:05AM -0400, Mimi Zohar wrote:
> On Mon, 2017-08-14 at 13:56 +0300, Jarkko Sakkinen wrote:
>
> > > > > I would like to see tpm_msleep() wrapper to replace current msleep()
> > > > > usage across the subsystem before considering this. I.e. wrapper that
> > > > > interna
On Mon, 2017-08-14 at 13:56 +0300, Jarkko Sakkinen wrote:
> > > Since the main concern about this change is breaking old systems that
> > > might potentially have other peripherals hanging off the LPC bus, can
> > > we define a new Kconfig option, with the default as 'N'?
> > >
> > > Mimi
> >
>
On Mon, 2017-08-14 at 13:56 +0300, Jarkko Sakkinen wrote:
> > > > I would like to see tpm_msleep() wrapper to replace current msleep()
> > > > usage across the subsystem before considering this. I.e. wrapper that
> > > > internally uses usleep_range(). This way we can mechanically convert
> > > >
On Mon, Aug 14, 2017 at 01:51:30PM +0300, Jarkko Sakkinen wrote:
> On Fri, Aug 11, 2017 at 11:30:19AM -0400, Mimi Zohar wrote:
> > On Fri, 2017-08-11 at 14:14 +0300, Jarkko Sakkinen wrote:
> > > On Wed, Aug 09, 2017 at 11:00:36PM +0200, Peter Huewe wrote:
> > > > Hi Ken,
> > > > (again speaking onl
On Fri, Aug 11, 2017 at 11:30:19AM -0400, Mimi Zohar wrote:
> On Fri, 2017-08-11 at 14:14 +0300, Jarkko Sakkinen wrote:
> > On Wed, Aug 09, 2017 at 11:00:36PM +0200, Peter Huewe wrote:
> > > Hi Ken,
> > > (again speaking only on my behalf, not my employer)
> > >
> > > > Does anyone know of platfor
On Fri, Aug 11, 2017 at 05:54:19PM -0400, Ken Goldman wrote:
> 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 SLB96
Hello,
On Fri, 11 Aug 2017 17:32:12 -0400
Ken Goldman wrote:
> 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 hav
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 T
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 19
On Fri, 2017-08-11 at 14:14 +0300, Jarkko Sakkinen wrote:
> On Wed, Aug 09, 2017 at 11:00:36PM +0200, Peter Huewe wrote:
> > 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 Su
On Wed, Aug 09, 2017 at 11:00:36PM +0200, Peter Huewe wrote:
> 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 port
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 TPM.
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 th
On 8/8/2017 3:11 PM, Jarkko Sakkinen wrote:
> On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote:
>> Are you sure this is a good idea?
>> On lpc systems this more or less stalls the bus, including
keyboard/mouse (if connected via superio lpc).
>>
>> On which systems have you tested thi
On 8/8/2017 3:11 PM, Jarkko Sakkinen wrote:
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 the final response, I have a
On Mon, Aug 07, 2017 at 07:55:49PM +0530, Nayna wrote:
>
>
> On 08/07/2017 05:22 PM, Peter Huewe wrote:
> >
> >
> > Am 7. August 2017 13:46:32 MESZ schrieb Nayna Jain
> > :
> > > The TPM burstcount status indicates the number of bytes that can
> > > be sent to the TPM without causing bus wait
On Mon, Aug 07, 2017 at 07:46:32AM -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. Further,
> some TPMs have a static burstcount, wh
On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote:
>
>
> Am 7. August 2017 13:46:32 MESZ schrieb Nayna Jain :
> >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 th
On 08/07/2017 05:22 PM, Peter Huewe wrote:
Am 7. August 2017 13:46:32 MESZ schrieb Nayna Jain :
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. Further,
som
Am 7. August 2017 13:46:32 MESZ schrieb Nayna Jain :
>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. Further,
>some TPMs have a static burstcount, when the va
24 matches
Mail list logo
