David Woodhouse wrote:
> On Tue, 2009-10-13 at 22:38 +0100, Graham, David wrote:
>> Do you agree with Ivan that the issue with failing to reload is probably
>> because user space is still "frozen" at the time that e100 invokes
>> request_firmware() ? And if so, how do you think we should proceed ?
>
> Perhaps you should load the firmware before you suspend. Or just keep it
> around from init time, since you've obviously loaded it then already.
>
Thanks David, but the resume path takes us through full device
initialization, and we do need to reload the firmware.
e100_resume()
e100_up()
e100_hw_init()
e100_reset_hw() /* full reset of HW here */
e100_load_ucode_wait()
e100_request_firmware()
request_firmware() .....
We could change the resume flow to avoid the reset & subsequent
request_firmware, but if the NIC has been powered down (which I think
will happen during hibernate unless the LAN was configured for Wake On
Lan), networking will fail.
No doubt there's a way we could load the firmware ourselves, as we did
before the newer request_firmware() model, but then we'd have to either
embed the firmware in the driver again __as_well_as__ provide it to the
lib/firmware directory, or read it from the device during runtime, and
store it in a local driver structure that would preserve across
hibernate/resume. Both of these options complex workarounds would be risky.
If devices can't reload firmware using request_firmware() during the
resume because there is a dependency on a user space component that is
not yet available, that's surely a bug in the resume architecture ?
I'm hoping that maybe there's yet another solution, but if not, I think
we need to bug this against request_firmware().
Thanks
Dave
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
