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 TPM 1.2 with an 8 byte FIFO and a static 
burst count.  This is where we're debugging.

quoted

Would another solution be to reduce the burst count poll and sleep
to, e.g., 100 usec or even 10 usec? This would probably help
greatly, but till not incur the wait states that triggered the
NACK.

If you use sleep it's not guaranteed that you wakeup after exactly xx
specified amount of time. Just that you sleep at least xx amount of
time. Otherwise you would have to do delay/busywaiting.

Understood.  However, if the DD maintainers will not accept ignoring 
burstCount, would a short sleep (e.g., 10 usec) be acceptable.

If so, we can benchmark it.

Imho the best option is to figure out whether any vendor can
determine the "FIFO flush time" i.e. how much time does it take to
empty the fifo and fillup the burstcount and use this on the lower
bound of an usleep range. I don't think tpms are in the range of < 10
us...

@Ken: Maybe can you check in DDWG?

I asked this week.

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html