Re: USB driver assignment with udev

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, Mar 13, 2009 at 00:01, Steve Calfee <nospamcalfee@yahoo.com> wrote:
> 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.

> 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.

Oh, you will not need to know a device name in advance. You can just
hook into the event for "1-1" and trigger the binding with that name,
and the "1-1:1:0" will show up. If you disable autobinding, the
"usb_device" will need to be attached manually to the "usb" driver,
which will create the "usb_interface" devices.

In the events for the "usb_interface", which are the ones you are
interested in, you can plug your custom rules, which would look like
this for a device with vendor "1234", and a driver named "foo":
  ACTION="add", SUBSYSTEM="usb", \
     ENV{DEVTYPE}="usb_interface", \
     ATTRS{idVendor}="1234", ATTR{[drivers/usb:foo]bind}="$kernel"

And then you fall-back to a "default" rule, which will do what the
kernel does today, and which will also cover the interface creation.
It would look like:
  ACTION="add", SUBSYSTEM="usb", \
    ATTR{[subsystem/usb]drivers_probe}="$kernel"

As pointed out in the earlier mail, the missing piece is the case you
load a module later, and want to scan for devices which might be
interesting for the newly added driver. This is not covered at all and
will do nothing today with disabled autobinding.

Kay