> 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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/