On Thu, Aug 17, 2017 at 11:17:32AM -0600, Jason Gunthorpe wrote: > On Thu, Aug 17, 2017 at 12:38:07PM +0200, Sebastian Andrzej Siewior wrote: > > > > I worry a bit about "appears to fix". It seems odd that the TPM device > > > driver would be the first code to uncover this. Can anyone confirm that the > > > chipset does indeed have this bug? > > > > What Haris says makes sense. It is just not all architectures > > accumulate/ batch writes to HW. > > It doesn't seem that odd to me.. In modern Intel chipsets the physical > LPC bus is used for very little. Maybe some flash and possibly a > winbond super IO at worst? Plus the TPM. > > I can't confirm what Intel has done, but if writes are posted, then it > is not a 'bug', but expected operation for a PCI/LPC bridge device to > have an ordered queue of posted writes, and thus higher latency when > processing reads due to ordering requirments. > > Other drivers may not see it because most LPC usages would not be > write heavy, or might use IO instructions which are not posted.. > > I can confirm that my ARM systems with a custom PCI-LPC bridge will > have exactly the same problem, and that the readl is the only > solution. > > This is becuase writes to LPC are posted over PCI and will be buffered > in the root complex, device end port and internally in the LPC > bridge. Since they are posted there is no way for the CPU to know when > the complete and when it would be 'low latency' to issue a read. What you say makes sense to me but wasn't the patch tried with SPI-TPM, not LPC? Anyway, what you're saying probably still applies. /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
