On Thu, Oct 01, 2020 at 11:09:20AM -0700, James Bottomley wrote: > The current state of the TIS TPM is that interrupts have been globally > disabled by various changes. The problems we got reported the last > time they were enabled was interrupt storms. With my own TIS TPM, > I've found that this is caused because my TPM doesn't do legacy > cycles, The TIS spec (chapter 6.1 "Locality Usage Per Register") > requires any TIS TPM without legacy cycles not to act on any write to > an interrupt register unless the locality is enabled. This means if > an interrupt fires after we relinquish the locality, the TPM_EOI in > the interrupt routine is ineffective meaning the same interrupt > triggers over and over again. This problem also means we can have > trouble setting up interrupts on TIS TPMs because the current init > code does the setup before the locality is claimed for the first time. > > James You should consider expanding the audience. Jerry, once you have some bandwidth (no rush, does not land before rc2), it would be great that if you could try this. I'm emphasizing this just because of the intersection. I think it would also make senset to get tested-by from Nayna. Speaking of the changelog, I almost never have encounter a patch set that does not have a changelog in the cover letter. And I'm not able to interpret the process text in a way that it would ask to scatter changelogs to the patches, and not put them to the cover letter [*]. Thus, I trust what I see as commodity. Not only that but it also helps a lot with to see quickly what has changed, especially if the patches are such that you have to take them in eventually. In my own patch sets, I've recently started to xref associated lore korg discussions in the change log entries, when it applies. I started to do this with the SGX series when I had missed to address a number of Boris' comments. It has helped a lot with my own tracking and I assume it is also helpful for reviewers and maintainers to get the context, when they need it. The last paragraph is not something I demand. I'm merely just mentioning it because I think it is a good practice for any patch set. [*] https://lore.kernel.org/linux-integrity/14edea1f5092c2b8442165756b2ee32e56bed1eb.camel@xxxxxxxxxxxxxxxxxxxxx/ /Jarkko
