When the ipw2200 driver is built into the kernel (not as a module), it attempts to load firmware from a file on disk while the kernel is initializing, which of course fails because there is no filesystem at this point in time.
Applying this patch:
causes the card to work properly except for one small detail: until the interface is brought up, it has MAC address 00:00:00:00:00:00. This is annoying because MAC address is an otherwise-perfect way to configure udev to give each network interface a unique, persistent, and sensible name (for instance, I use udev to name my interfaces eth_wired and eth_wifi).
I can think of a number of possible courses of action to resolve this, any of which might be sensible but all of which have drawbacks:
1. Restrict the kernel configuration so the driver can only be built as a module. Alternatively, document it - the kernel config option doesn't even MENTION the fact that the driver must be built as a module; in fact, it has the standard "if you want to build as a module..." blurb at the bottom. Drawback: I, and presumably many others, would rather just build a monolithic kernel and not even include module support at all.
2. Apply the patch. Drawback: MAC address reads all zeroes until the interface is brought up.
3. Build the firmware into the kernel instead of loading it from a file. I realize the reason it's not included in the kernel sources is legal. However, what if the user were to download the firmware files manually, then the kernel sources were to simply bring in the downloaded files? Drawback: might be hard to bring external files into the kernel (I don't know about this); might not be legal (IANAL); firmware upgrades require kernel rebuilds (is this really an issue?); requires work on someone's part to change the code
4. If firmware isn't needed to discover the card's MAC address, how about splitting the card initialization into two parts: one that's enough to find a MAC address that happens during initialize, and the rest (including firmware loading) during open? Drawback: requires work on someone's part to change the code
If I have a few hours sometime I might look into the driver's sources and see if it seems fairly easy to do #4, in which case I'll upload a patch.
Steps to Reproduce:
1. Build ipw2200 driver into the kernel.
ipw2200 gives "Unable to load firmware: -2" in dmesg and fails to start
it ought to in some way work, or else be impossible to choose that option
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:
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.