On 03/01/12 11:57, Oliver Neukum wrote: > Am Dienstag, 3. Januar 2012, 01:42:20 schrieb Alan Cox: >> In that case however you don't want some generic firmware module knowing >> all this crap, your driver can just request_firmware() the stuff as >> modprobe and free it up on the module unload. For a typical 8bit firmware >> of a few K you'll free a ton more memory unloading the module than the >> firmware ! That I think actually covers the majority of devices under >> discussion. > > I am afraid it doesn't, at least not fully. > We have many devices whose primary (operational) driver does not load > the firmware. That job is left to a secondary driver or user space. > > We could leave those secondary drivers and their firmware in RAM after > their primary usage and except for a few pathological cases (which > can be solved with a few udev rules preventively loading drivers) we'd > be good, but we lack a mechanism for switching to a seconary driver > and back during resumption. You don't mension the bus used so I'm going to use USB as an example. As I understand it the majority of devices that need firmware have two different identities: the "bootstrap" id and the "primary" id. If we always make sure we have the drivers for both bootsrap and primary ids loaded then we should have the firmware in memory. If the device has lost its firmware then it will reregister with the bootstrap id otherwise it will continue with the primary id. Either way the correct driver should pick it up and handle it. That said, I guess there are more complicated / difficult pieces of hardware that might not do that. Is that the case here? Can we detect that the firmware needs reloading and have the primary driver "yield" to the firmware driver? Thanks, Jack -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
