Summary: | ipw2200 firmware fails to load when driver built-in (not a module) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Head <bugs> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | VERIFIED FIXED | ||
Severity: | minor | CC: | kdvgent |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Christopher Head
2007-12-17 08:51:12 UTC
Unfortunately the only option is to document this implicit requirement. It's not acceptable for a driver to present an invalid MAC address before it has been brought up, and it's not possible to read the MAC address on this hardware without having firmware loaded. Making the component only buildable as a module is not valid either, because you can build the driver into your kernel image and it will work just fine provided that you have included the firmware in an initramfs. Fancy knocking up a patch for the Kconfig entry for this driver? I'd suggest removing the misplaced reference to the kbuild documentation at the same time. About the initramfs idea, I don't think that works. I tried putting the firmware into an initramfs, and it didn't work. For one thing I'm not even sure the initramfs is *mounted* during the phase of kernel boot where the ipw2200 driver comes up. More importantly, as far as I can tell, the ipw2200 driver calls into the firmware subsystem which uses uevent to talk to a userspace process and instruct it to load firmware. Since the first ever userspace process runs at the *end* of kernel bootup, there's no chance of anybody being there to hear the request and load the firmware, even if the initramfs itself is actually mounted. I just gave up and built as a module - I don't particularly like either option, even if the initramfs idea worked. I am sure that firmware loading from initramfs must work if you can figure out the details, because several storage drivers require firmware to be loaded in this way. I think the complication is having a firmware loader available as you say, but I would imagine the legacy hotplug based firmware loading will still work. Googling seems to confirm this via this howto: http://www.parisc-linux.org/~willy/initramfs-firmware-howto I have submitted a patch upstream to document this in the driver help text. Should be included in 2.6.25. I think that's the best we can do at the moment. Final comment, after not having time to work on this for a while I did eventually get it to work monolithic using a firmware loader in initramfs. Almost perfect solution - I kinda don't like initramfs either, but it's a lesser of evils. Thanks! |