I'm not happy for network drivers, although I'm happy to see that
David respected out NACKs on tg3/bnx2/etc. and didn't include those
bits.
I still haven't seen an answer to the chip reset issues. The argument
has been that this stuff is going to save kernel memory when the
driver isn't loading firmware, but that's not really possible.
When a lot of these network drivers reset, due to a transmit timeout
or other exception, we need to load the firmware again.
So this means, that if request_firmware() dies or fails for some
reason in these scenerios, we can't reset the network card. Something
as simple as a memory or other allocation failure deep inside of
request_firmware() means we lose the networking interface.
To me this seems like a very non-resilient setup. It makes sense
to just keep the firmware in-core so we can load it without having
to even think about possible failures.
And that to me basically makes this transformation pointless. It's
in fact a regression.
Furthermore, the issue of suspend and resume was brought up. What if
request_firmware() fails then? And can request_firmware() even be
allowed in that context? What if the disk on which the firmware
resides hasn't been resumed yet?
In response to the suspend/resume queries, a lot of special voodoo was
mentioned that perhaps would allow request_firmware() to get invoked
in the correct context and with the firmware partition's block device
resumed already.
But who the heck is going to write all of that code and fix up all
of these drivers so that they can resume reliably again?
And for what?
None of the people who wrote and maintain these effected networking
drivers want these changes installed. And they are the ones who will
have to diagnose strange request_firmware() failures that lead to
non-functioning devices during resume or after a transmit timeout.
--
