Re: USB driver assignment with udev

[Steve Calfee <nospamcalfee@yahoo.com>]

Kay Sievers <kay.sievers <at> vrfy.org> writes:
> You can use udev rules to unbind a driver, and rebind a different one
> to a specific device.
> 
> Or you can disable kernel-driver-autobinding per bus, and let udev do
> all the driver binding for this bus. A default rule would trigger the
> in-kernel driver binding, and any custom rule added before that, could
> bind a specific driver to a specific device. What's not covered with
> disabled in-kernel driver binding is the device scanning at the time
> of loading of a module, which would need to be implemented.
> 
> Both setups should work. We did not see a lot of interest in offering
> any solution like that. We added:
> /sys/bus/*/{drivers_autoprobe,drivers_probe} long ago, because we
> thought it might be useful, but it's never got really used so far, and
> the missing pieces never got added to the kernel and udev.
> 
> Kay

Hi Kay,

I tried your suggestion about manually binding and unbinding. That sort of
works, but I would like to avoid the handling by the first module until udev can
switch it out.

So I have been trying this manually. Turning off drivers_autoprobe sounded like
a good idea, the problem is that device id for a newly plugged in device is not
fully formed. IE usually in sys/.../1-1/1-1:1.0 the 1-1:1.0 is the number used
to bind and unbind a device, but the 1.0 which I guess is
configuration.interface does not appear in the /sys/..../1-1/ device directory.
So the bind fails because there is no proper device yet. I can echo 1-1 >
/sys/.../drivers_probe, but then the drivers are probed in their original order
and the wrong device binds.  I guess I could unbind this device and rebind it to
my desired driver, but it is starting to get pretty strange - and I suspect
buggy devices will not like all the activity.

All USB devices could potentially have two drivers, the local one and then the
one to remote the device. What I want is to have a text file giving the rules
for which driver gets which device. Then a gui can change the file and the next
udev add activity would connect things up by running a script over the file and
using the udev device info. 

Thanks for the info, Steve