From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Maksim (Max) Krasnyanskiy" Date: Thu, 18 Jul 2002 16:49:10 +0000 Subject: Re: [PATCH] usb.agent should processes usermap before other Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org >>Currently usb.agent processes usermap after the kernelmap. Unfortunately >>it doesn't work for >>Broadcom USB (BCM) firmware loader. The problem is that Bluetooth HCI USB >>driver (hci_usb) >>has to claim any device with proper Bluetooth class, subclass and >>protocol regardless >>of the vendorid/productid. But at the same time fw loader has to be able >>to claim devices >>with specific vendorid/productid even if they have proper Bluetooth >>class, subclass, proto. > >If hci_usb shouldn't be claiming specific devices, it's simple >to teach it not to do so. I notice it's not using driver_info >for anything, so it'd be easy to store flags there telling it >not to bind to the pre-firmware IDs (idProduct = 0x2033); then >the with-firmware path would work normally (idProduct = 0x2000). > >That'd total about half a dozen lines: define the flag, add a >MODULE_DEVICE_TABLE entry to blacklist that one device, add code >in the probe() routine to test that flag and return if it's set. Yeah, I was gonna do that anyway because processing usermap first doesn't help when driver is already loaded. I thought it might be nice if USB core could do that ie something like USB_IGNORE_DEVICE(xxx, yyy) in the driver id_table. But Johannes pointed out that it probably won't be useful for other drivers. >>So, the solution is to process usermap first. It kinda makes sense anyway, >>usermap should have priority over kernelmap. > >No can do ... remember that when drivers are statically linked, >the kernel is going to get first whack regardless of what you >try to make userland do. Changing that isn't an option today, >and wouldn't IMO be a good idea in any case. > >That means you must make the kernel driver bind correctly, >or in the case of this no-firmware device, not bind. I was gonna say that it would not work but then I noticed that it's actually fixed in 2002.04.01. usb.agent that came with RH 7.2 was doing if [ "$FOUND" = "false" -a -r $MAP_USERMAP ]; Which means that usermap won't be processed if kernel driver exists for this device, even if driver ignores these particular ids. I didn't notice that you guys got rid of FOUND = false check in latest usb.agent. Now that this check isn't there it should work correctly if driver ignores pre-fw ids. Max ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel