Messages in this thread | | | Date | Thu, 6 Sep 2012 13:59:57 +0100 | From | Alan Cox <> | Subject | Re: A workaround for request_firmware() stuck in module_init |
| |
> Sorry, I don't see anyone explained clearly why request_firmware() > can't be called inside module_init() in module case, so maybe it is > a bit early to say it is a fix on 'bug', :-)
Because the firmware load may trigger a need to load a driver to load the firmware.
> > dev_discard_firmware() > > > > so you an instance can drop its firmware reference if it doesn't need it > > post probe. > > This kind of mechanism has been implemented already: request_firmware() > and release_firmware() will get and put a refcount. And, the reference > count is associated with firmware name, and it should be so, IMO.
Yes - so a dev_ firmware interface is very thin.
> > You broke suspend/resume for lots of devices. > > The firmware cache mechanism will keep the firmware during suspend/resume > cycle to address the problem.
Ok
> For drivers, I understand request_firmware()/request_firmware_nowait() > and release_firmware() are enough. If many devices share one firmware, > there is only one firmware kept in memory for their requests if one holds > the firmware, and there is a refcount for it already, :-) > > So I don't see why it is difficult to use request/release_firmware() inside > drivers, :-)
The big problem can be summed up in one word "asynchronous". Having either an automated handler for it before ->probe is called or having the driver author cut and paste in
if (!dev_request_firmware(dev, blah)) return -EPROBE_DEFER;
avoids the need to deal with async completion after probe (and the *horrible* case of
probe request firmware remove firmware ready )
in each driver
Having an auto unload for it at the end is just neatness. Perhaps in fact it should be devm_request_firmware() and use the mechanism we have ?
| |