From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve Calfee <nospamcalfee@yahoo.com>
Date: Thu, 12 Mar 2009 23:01:23 +0000
Subject: Re: USB driver assignment with udev
Message-Id: <loom.20090312T224619-14@post.gmane.org>
List-Id: <linux-hotplug.vger.kernel.org>
References: <loom.20090311T231825-449@post.gmane.org>
In-Reply-To: <loom.20090311T231825-449@post.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-hotplug@vger.kernel.org

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