Hi Duncan, > > > So to my mind the importance of this patch is in improving correctness > > > (lack of > > > deadlocks) and responsiveness (newly plugged USB devices turn up at once, > > > even > > > if some other device is doing a long wait in its probe method), rather > > > than > > > performance. > > > > Would it be better to change the drivers so that they _don't_ wait a long > > time in their probe methods? For example, usb-storage starts up a > > separate thread to take care of potentially long-lasting I/O during > > probing. Other drivers could do the same thing, or could use > > schedule_work(). > > The speedtouch driver does too (though it adds an annoying amount of > complexity > which I would rather have the usb core take care of). Here are some USB > drivers > which load firmware in their probe method: > > drivers/bluetooth/bfusb.c > drivers/bluetooth/bcm203x.c > drivers/net/wireless/zd1211rw/zd_usb.c > drivers/net/wireless/zd1201.c > drivers/net/irda/irda-usb.c > drivers/media/dvb/ttusb-dec/ttusb_dec.c > > Interestingly enough, I didn't find any examples under drivers/usb.
I personally think that loading firmware in the probe routine is okay and I fully agree with you that the less complexity in the driver the better. Loading the firmware will almost always have to block since the device can't be used before the firmware loading has been finished. Regards Marcel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
