Hi Dave, I had another look at this bit:
Also I'd revert the change to create the driverfs interface files after all the probes succeed;
my patch doesn't create the driverfs interface files after all probes succeeds, it creates each one after the associated probe has succeeded. This is the same as right now. Checking over the code, I see that my patch only delays the creation of each driverfs file by a few processor cycles compared to the original code, i.e. nothing that can be noticed.
OK, I see what you mean. This is the relevant chunk.
It's still not right though ... the "registering..." messages are all emitted before the first registration gets done by device_add. That would definitely be noticed ... the probe() messages will seem to appear out of sequence!
Unrelated: the intf->dev setup doesn't seem to really "belong" in that routine at all. That's all static init that's just, for some reason, not in config.c when the interfaces are initialized.
- Dave
--- 1.39/drivers/usb/core/message.c Sun Oct 26 23:51:28 2003 +++ edited/drivers/usb/core/message.c Mon Jan 5 02:23:48 2004 @@ -1135,6 +1135,13 @@ "registering %s (config #%d, interface %d)\n", intf->dev.bus_id, configuration, desc->bInterfaceNumber); + } + /* Now that all interfaces are setup, any of them can be + * safely accessed from the probe() call for another + */ + for (i = 0; i < cp->desc.bNumInterfaces; ++i) { + struct usb_interface *intf = cp->interface[i]; + device_add (&intf->dev); usb_create_driverfs_intf_files (intf); }
So I think it is OK.
All the best,
Duncan.
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel