From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 14 Jul 2009 22:45:08 +0000 Subject: Re: [PATCH] Explicitly disable BT radio using rfkill interface on Message-Id: List-Id: References: <4A4A8B6D.3060509@dell.com> In-Reply-To: <4A4A8B6D.3060509@dell.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: linux-hotplug@vger.kernel.org On Tue, Jul 14, 2009 at 23:24, Kay Sievers wrote: > On Tue, Jul 14, 2009 at 23:00, Mario > Limonciello wrote: > > Ok, I took a look first over the stuff we currently have. > > What kind of directory is that? I've never seen such a thing: >  sprintf(devname, "%s/usb/hid/hiddev%d", devpath, i); That all needs to be fixed. We are not hooking into USB device events and write to hard-coded /dev/hidraw* devices. If these devices need to be handled with hidraw, the tools needs to hook into hidraw events. >> I'll split that up into some more readable for loops.  I was >> just trying to walk through the bus to find the appropriate usb_device to >> match and return. > > Why do you need to *find* the device at all? Same question for the > normal call case too, not only the resume case. Seems libusb is too stupid to handle a specific device, and unfortunately even the new libusb seems to be not better regarding this. It really needs an interface to select a specific device by whatever _unique_ property, not by vid/pid, instead of this braindead brute-force searching across all possible devices to find itself. So, seems there is not hid2hci fault, and it can not do much here. Kay