From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 12 Mar 2009 00:35:30 +0000 Subject: Re: USB driver assignment with udev Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On Thu, Mar 12, 2009 at 00:37, Greg KH wrote: > On Wed, Mar 11, 2009 at 11:20:53PM +0000, Steve Calfee wrote: > Have you read the documentation on how this happens in the book, Linux > Device Drivers, third edition, which is free online? > >> It seems that a udev rule does a modprobe for a driver to handle a devic= e. >> In most cases the module is already in-kernel and this step does nothing. > > Not really true, lots of times the module is not present. And udev does call modprobe only for devices which are not bound to a driver, so some of the modprobes end up doing nothing, yes, and modprobe calls are very cheap these days, we just resolve with a binary index a modalias string to a module name, and look if /sys/$module exists, and exit if it's already there. >> The module/driver probe routine is called by the kernel, only if there i= s a >> match in its registered usb_device_id table. If more than one driver >> matches, the first one installed gets called first. In 2.6.16, if the pr= obe >> "failed" (returned non-zero), no more modules were probed. I think this = is >> broken, and I am now trying 2.6.28, maybe it does the right thing and >> continues looking for a driver that wants a device. >> >> I have a different situation, but a classic issue is if a user wants to >> have ub handle one device and usb-storage handle others. How can this be >> done? udev loads the driver, but the driver itself grabs the devices. The >> first module loaded will hog all the devices. USBIP will also sooner or >> later hit this problem, some devices might need to be local and some pla= ced >> remotely. =C2=A0Presumably separate drivers will be needed. > > See the libusual code for how this is handled. > >> So right now, a Linux USB driver will in-kernel determine if it wants to >> bind to a particular device. This is weakly controlled by userspace by t= he >> order of module registering (usually by order of insmod). But there is no >> way for userspace to determine a mapping between devices and drivers. Is >> there a udev solution for this? > > Not really, but I fail to see the problem that you are trying to solve > here. None of the solutions are provided by default, but can be made working today, with a bit of hacking. 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