Hi Alan, PS: For all other comments, will do as you suggested. On Tue, May 13, 2014 at 10:28:11PM +0800, Alan Stern wrote: > On Tue, 13 May 2014, Pratyush Anand wrote: > > > > The biggest bug may not be an obvious one. Suppose the lvstest driver > > > has been built into the kernel. When the kernel boots and the root > > > hubs are registered, what will prevent them all from binding to lvstest > > > instead of the normal hub driver? > > > > Sorry, I do not have much knowledge of device model, so may be I am > > wrong, but this is what I understand. > > > > Since core comes before misc in makefile, so won't it insure that > > hub_diver is registered before lvs_driver on usb bus? > > No. Order in the makefile has no direct connection with driver > probing. > > > And if that is > > insured than, would n't a root hub device always binds to the first > > driver and ie hub_driver. Infact, I am working with lvstest driver > > being built into the kernel. > > It works only because drivers get probed in the order they are > registered, and the hub driver is registered first. But the probing > order is not guaranteed, as far as I know. You shouldn't rely on it. > I see some references on different mailing lists that "probe will be executed according to object link order which is decided by Makefile". http://comments.gmane.org/gmane.linux.usb.general/98616 If that is not true, may be I can do what Bjørn Mork is suggesting. But that would require change in drivers/base/bus.c:driver_(un)bind. -- Add a new field manual_binding in struct device_driver. -- set this flag in drivers_bind before calling driver_probe_device. -- reset this flag if driver_probe_device returns error. -- reset this flag in driver_unbind. -- return error from lvs_rh_probe if manual_binding is not true. Please let me know if there could be a better way to do it. Regards Pratyush PS: For all other comments, will do as you suggested. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
