On Wed, May 14, 2014 at 11:05:44AM -0400, Alan Stern wrote: > On Wed, 14 May 2014, Pratyush Anand wrote: > > 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. > > As Bjørn said, this doesn't seem like a good way to go. > > > Please let me know if there could be a better way to do it. > > I don't know. It's a difficult problem. > > Greg, do you have any suggestions? If two drivers can manage the same > device, but one of them is intended for normal use whereas the other is > just for testing, how can we insure that the normal driver is the one > that gets bound to the device by default? You can't, if both drivers can be built as a module. > Is it really safe to rely on the device core always probing drivers in > order of driver registration? Yes it is. > If it is then we are okay (at least in this particular case), because > the hub driver will always be registered before the lvstest driver. Good, then there shouldn't be an issue. Or just make the lvstest driver have to be "manually" bound to the device through the bind file in sysfs, don't let the driver automatically bind to anything. thanks, greg k-h -- 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
