Hi Jason,
On 22/07/22 22:13, Jason A. Donenfeld wrote:
Hi Valentin,
On Fri, Jul 22, 2022 at 10:09 PM Valentin Schneider vschneid@redhat.com wrote:
I had initially convinced myself this would be somewhat involved, but writing the above I thought maybe not... The below is applied on top of your v10, would you be able to test whether it actually works? It does however mean patching up any sleeping hwrng (a quick search tells me there are more, e.g. npcm-rng does readb_poll_timeout())
I'm not able to test this easily, no (I don't own any hardware), and I'm not going to put in the effort to rewrite/audit every sleeping hwrng. That's not a good use of time, given the numerous other problems the framework has (briefly discussed with Eric). Instead, maybe at some point I'll look into overhauling all of this so that none of this will be required anyway. So I think v10 is my final submission on this.
I think that's fair, I hope I didn't discourage you too much from contributing in that area.
But if you'd like to attempt more comprehensive changes throughout the tree on all the drivers and do something large, I guess you can do that independently (since you mentioned your thing works on top of v10). And this way v10 still exists to fix the actual bug that's currently reeking havoc. On the other hand, maybe don't bother, and we can look into fixing the whole rats nest properly in some months when I'm more motivated to jump into hwrng.
Just to make sure I'm on the same page as you - is your patch solely for ath9k, or is it supposed to fix other drivers?
AFAICT your changes to hw_random/core.c work with any hwnrg driver that does a variant of schedule_timeout() during rng_get_data(), whereas what I suggested only works for "opted-in" drivers (just ath9k ATM), but it doesn't break the other drivers in any way.
So if ath9k is widely used / a problem for lots of folks, we could just fix that one and leave the others TBD. What do you think?