On Fri, 2023-08-11 at 20:40 +0300, Jarkko Sakkinen wrote: > On Fri Aug 11, 2023 at 8:22 PM EEST, Jarkko Sakkinen wrote: > > On Fri Aug 11, 2023 at 11:18 AM EEST, Thorsten Leemhuis wrote: > > > > > > I see two long-standing options: > > > > A. Move from deny list to allow list when considering using IRQs. > > This > > can be supplemented with a kernel command-line parameter to > > enforce > > IRQs and ignore the allow list (and IRQ storm detection provides > > additional measure in case you try to enforce) > > B. Change deny list to match only vendors for the time being. This > > can > > be supplemented with a allow list that is processed after the > > deny > > list for models where IRQs are known to work. [...] > > This is also super time consuming and takes the focus away from more > important matters (like most likely the AMD rng fix would have gone > smoother without these getting in the way all the time). Main problem of any list is maintaining of them. So, I think there should not be any black or white lists at all. Module should work with reasonable default (polling is the one, which lived without problems for years and years due to bug, as I understand), and probably a boot option to force IRQ. Maybe module should warn user to try that option. I don't know: is it even worth it to use IRQ, if it so problematic? Are there any significant advantages of that? I understand, polling is a resource consumer, but its just TPM, which is used mainly at the boot time, is it worth it?
