On Fri, 15 Nov 2002, Duncan Haldane wrote: | | On 15-Nov-2002 Randy.Dunlap wrote: | > On Fri, 15 Nov 2002, Pete Zaitcev wrote: | > | >| VERY many moons ago. Today, the same effect is accomplished by | >| module_init() without #ifdef bracket. If the module is compiled | >| into the kernel, do_initcalls does the call there. | >| | >| To make cpia initialize later than the USB, the proper configuration | >| must be used, which prohibits CPIA being 'y' and USB core 'm'. | >| It can be done without "if", by using dep_tristate as appropriate. | >| Also, the order in which cpia and usbcore are listed in the Makefile | >| is significant, it determines the order in which do_initcalls | >| calls them in case of them being 'y'. | > | > The case is both cpia and usb are 'y'. | > cpia is being init-ed before usbcore. | > Where's your patch/solution? 8;) | > | > As I said earlier (now deleted), controlling init order in 2.4 | > is odd. In 2.5 it's much easier, but that doesn't matter for this | > problem. Mucking around with order in Makefile isn't a good solution | > IMO.
| But... such a Makefile change DOES fix it. Yep, I didn't say it wouldn't work, it's just too much like makefile magic IMO. The next version of make might be different. :( But this is certainly a better solution than initializing the semaphore in a second place. | I see that the position of the cpia driver in | drivers/media/video is anomalous: it started out as a parport driver | and now supports both parport and usb devices. There used to be a separate cpia driver in drivers/usb/, but then they were merged. | I moved the position of drivers/media.o to after drivers/usb.o in the Makefile, | and the problem is gone. I would like to get something like this into | 2.4.20 as an immediate workaround, if at all possible. I guess to be less | invasive though, I should somehow remove cpia*.o from video.o and hence from | media.o, and create a cpiadrv.o so the | init position of other drivers in media.o is not messed with. I expect that it will be difficult to get this into 2.4.20-rc2++. There are other less-intrusive workarounds (like cpia as a module). IMO you should push this patch to 2.4.21-pre1 thru Greg KH or Alan Cox (?). | I'm assuming moving parport drivers down the list to after usb wont | break them, though. I hope not. | I guess it can be justified because cpia is a special case: are there any | other kernel drivers | that support both parport and usb that can be used as a model for | what to do? (maybe scanners?) Not that I know of. | --- Makefile Sun Nov 10 11:35:09 2002 | +++ Makefile.usb_fix Fri Nov 15 13:40:21 2002 | @@ -137,8 +137,7 @@ | DRIVERS-y += drivers/char/char.o \ | drivers/block/block.o \ | drivers/misc/misc.o \ | - drivers/net/net.o \ | - drivers/media/media.o | + drivers/net/net.o | DRIVERS-$(CONFIG_AGP) += drivers/char/agp/agp.o | DRIVERS-$(CONFIG_DRM_NEW) += drivers/char/drm/drm.o | DRIVERS-$(CONFIG_DRM_OLD) += drivers/char/drm-4.0/drm.o | @@ -179,6 +178,7 @@ | DRIVERS-$(CONFIG_HAMRADIO) += drivers/net/hamradio/hamradio.o | DRIVERS-$(CONFIG_TC) += drivers/tc/tc.a | DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o | +DRIVERS-y += drivers/media/media.o | DRIVERS-$(CONFIG_INPUT) += drivers/input/inputdrv.o | DRIVERS-$(CONFIG_HIL) += drivers/hil/hil.o | DRIVERS-$(CONFIG_I2O) += drivers/message/i2o/i2o.o Looks OK to me. -- ~Randy "I read part of it all the way through." -- Samuel Goldwyn ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
