On Tue, 12 Mar 2002, Greg KH wrote: > Seriously, I think this is the best solution. As there are USB drivers > for just about every kernel driver subsystem, it should remain one of > the last things to be initialized. Putting your USB driver in the > drivers/usb/ directory ensures that your subsystem will be up and > running before the usb driver is loaded.
Admittedly, I don't really like the idea of moving hisax_st5481 into drivers/usb (though I could live with it). The ISDN code is supposed to be changing a lot during 2.5, and I'd prefer to have "my" code all in one subdirectory, as opposed to scattered around. The other drivers aren't in drivers/pci, drivers/isapnp or whatever, they're in drivers/isdn/.. The other reason why I started to think about this problem is drivers/net/irda/irda-usb.c. I can't tell other people to move their code, though. > So how does this differ from still relying on the link order? It > doesn't look like this will solve your problem. Well, my point of view is the following: Most things are organized by the kind of device they drive, not the bus they're on. So there's drivers/net, drivers/isdn, drivers/input, drivers/parport ... Mostly theses subsystems have some common code, which needs to initialize first. After that, drivers for individual devices initialize, registering with the common code (register_netdev(), don't know about input, register_isdn(), register_parport(), ...). Each subsystem takes care that common code has initialized before the first register_... takes place. Now, the drivers need to find their devices, nowadays mostly using new-style driver registration like pci_register_driver(), usb_register(), register_pccard_driver() etc. So they rely on the fact that the bus drivers have already been initialized, at least as far that the register_...() calls work. USB changes the picture here: Most USB drivers are actually in drivers/usb. They also need their subsystem having initialized before, that's why USB is linked late. Of course these drivers also rely on their bus registration, usb_register() to work, which it does because it is initialized first in drivers/usb. Now, my point is: These two point of views don't need to clash. The USB drivers need to be linked last, for the reasons above. But there's no reason why you can't provide an usb_register(), which works right from the start, like pci_register_driver() etc do. So it's just the USB core which needs early init, and this is what my patch is supposed to do. usb_register() in the ST5481 driver won't crash the system then, it'll merely just put this driver into some list and return. Later, when the actual USB host adapter drivers initialize (or even later when someone actually plugs in the device), the st5481_probe() routine will be called and that's just fine. Doesn't that make sense? --Kai _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
