On Tue, 2007-02-13 at 14:23 -0500, Dan Williams wrote: > The simpler, the better I think; but it's complicated. A sample of > current drivers and when they call request_firmware() from a 2.6.19 > kernel: > > on dev->open: atmel, prism54, bcm43xx (softmac) > on dev->init: ipw2100, ipw2200 > on probe: zd1201, libertas, spectrum_cs ouch. > So this isn't really consistent. I'm unclear as to why the ipw cards > need it on init rather than on dev open, but hey, why make things > easier? When is ->init() called anyway? Isn't it when you register the netdev so it would be on probe? > With USB devices (and spectrum_cs I guess), most can't do _anything_ > until you upload firmware to them, so the firmware upload really does > need to happen on probe, not device up. I guess we have two main > use-cases to target here. We all know what the case on dev up is > (-ENOFILE or whatever gets returned from request_firmware()) -ENOENT :) But then we need to specify that returning -ENOENT from dev up is not valid in any other case I guess. > but I have > no idea how to detect the error on module load (ie, probe) because > that's _waaay_ before NM gets into the business. The kernel should > normally be autoloading the modules for you, otherwise half the time NM > won't even know the device is there in the first place. Well, the kernel will just show in sysfs what the system can support and udev will autoload modules based on that. But actually, I don't think you fail module load. The thing is that when ->probe() fails the module will usually (unless you write code) be loaded but not bound to any device. > So for USB devices and the like, if the firmware isn't there, the module > will have already failed to load, and HAL won't know it's a wireless > interface because it's not in sysfs as a wireless interface, and > therefore NM won't know about it, and therefore there is no error to > catch. I don't think NM should be in the business of searching through > USB devices to find ones that don't report themselves as wireless > devices. Yeah, that's a good point. > So there are two questions: > > 1) What's the failure mode for request_firmware() error on probe? How > does a userspace program notice that the hardware has no firmware? As I said above, the driver will be loaded but no device will be bound to it. That could actually be taken as a sign... If you look into /sys/module/*/drivers you can find those values for * that are known wireless modules and have no devices associated. ;) Of course, DON'T ACTUALLY DO THIS! This breaks for various reasons: * drivers that are built-in * computers with multiple wireless devices that have a single driver but need different firmware (can happen with bcm43xx) (and that's just those that I can think of right now) This is a really tough case to recognise for a program. But then again, even usb drivers don't need to load firmware to know that there's a device and to register a netdev. They might not be able to assign a mac address but that shouldn't hurt (though we have to make sure d80211 can cope with this), so we can mandate deferring it at least to netdev registration, and then I don't see why ipw* needs it right away there as opposed to open(). johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
