From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Thu, 18 Jul 2002 05:35:59 +0000 Subject: Re: [PATCH] usb.agent should processes usermap before other maps. 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 Maksim (Max) Krasnyanskiy wrote: > Hi Folks, > > 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. > 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. - Dave ------------------------------------------------------- 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