Hi Andy, Em 11-08-2012 21:06, Andy Walls escreveu: > On Wed, 2012-08-08 at 13:18 -0400, bjloc...@lockie.ca wrote: >> How hard would it be to get an official kernel option not to load firmware > > Submit a patch for the cx23885 driver to the list. It could add a > module option so the user can specify not to load cx23885-av firmware > (and maybe CX23417 firmware too). The new module option could be set on > your kernel commandline: cx23885.no_firmware_load=1
No, adding a parameter there is not right: it is not an user option to not do firmware load during module init; it is a requirement for a driver to work with newer userspace tools. There are two situations there: 1) for devices where the firmware is inside an I2C driver, the solution is to simply not load the firmware during module probing. The easiest do to that is to call request_firmware_nowait() during module probing. This call will start a deferred work that will use a callback to warn the driver when the firmware is loaded. If you want an example, please see: 61a96113de51e1f8f43ac98cbeadb54e60045905. While I intend to do the same on other drivers as I have some spare time, please don't wait for me on that, as I'm not with much spare time those days. You'll likely need to add a status flag at all drivers callback, that would return a temporary error indication like -EAGAIN (or -ERESTARTSYS) and maybe change the drivers to handle such error code. 2) for drivers where the firmware is needed for the bridge driver to work, I couldn't find a perfect solution. There are two alternatives there: a) patch the drivers base in order to improve the deferred probe. Currently, a deferred probe will only be called again if a new device driver is probing. It would make sense to add some way to make it do the probe after a while. b) lie to probe(), returning 0 before probing the driver, and run a deferred probe inside the driver, in order to load the firmware and run the real probing code. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
