Messages in this thread | | | From | Jon Masters <> | Date | Mon, 04 Sep 2006 22:16:38 +0100 | Subject | Re: [PATCH][RFC] request_firmware examples and MODULE_FIRMWARE |
| |
On Mon, 2006-09-04 at 14:02 -0700, Andrew Morton wrote:
> > Also, I'd like to comment on Jon Masters push to include the > > MODULE_FIRMWARE api addition. I strongly believe that policy should > > not be included in driver code, in this case it's in the form of a > > filename. > > You should have cc'ed him! Some people are not subscribed, and few read > it all.
Thanks. My lkml subscription bounced last week after I decided to overhaul my home email (moving country in a couple of weeks...).
I disagree that MODULE_FIRMWARE encodes policy in the driver. It encodes a reference - nothing more. We need to know what firmware we're going to be asked for if we have any hope of being able to package up drivers for use in distro initrds and the like. I think we can agree on that much.
Some alternatives:
* The firmware API get hacked yet again to use static strings we can parse (ugly) or otherwise somehow provide this information.
* We add hacks in userspace "if it's this driver and someone used MODULE_VERSION correctly, and we can determine the right firmware...".
> > The firmware loader currently needs a filename passed to it so it can > > then pass the $FIRMWARE environment variable to the hotplug script. > > This is ok if you provide a generic filename like "firmware.bin" and > > then let the hotplug script worry about version numbers, i.e. > > "firmware-x.y.z.bin"
> > MODULE_FIRMWARE should be used to provide the generic filenames and > > which order the files should be loaded (request_firmware can be > > called various times), but I think its bad to have to change the > > driver everytime a new firmware version is released. > > Yes, that does sound bad, but what would I know ;)
I'm ok with the idea of having a generic name, but it does add more processing in userspace. Frankly, I don't care what is adopted but something needs to be done - sooner or later, it's going to be more drivers than Qlogic (and a few others) we need this working for :-)
I'm optimistic that we'll find the right one line patch eventually!
Jon.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |