From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mario Limonciello Date: Wed, 15 Jul 2009 22:24:31 +0000 Subject: Re: [PATCH] Explicitly disable BT radio using rfkill interface on Message-Id: <4A5E571F.7070300@dell.com> MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------enig3587B676844CAD69871D2DDF" List-Id: References: <4A4A8B6D.3060509@dell.com> In-Reply-To: <4A4A8B6D.3060509@dell.com> To: linux-hotplug@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3587B676844CAD69871D2DDF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kay & Alan Kay Sievers wrote: > On Wed, Jul 15, 2009 at 04:07, Alan Stern wr= ote: > =20 >> On Wed, 15 Jul 2009, Kay Sievers wrote: >> >> =20 >>>> What kind of directory is that? I've never seen such a thing: >>>> sprintf(devname, "%s/usb/hid/hiddev%d", devpath, i); >>>> =20 >>> 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 t= o >>> be handled with hidraw, the tools needs to hook into hidraw events. >>> =20 >> That's absolutely right. At the time the USB device event takes place= , >> the HID driver might not even be loaded yet! >> =20 > > Right, and even when it's loaded, there is no guarantee, that this > device is already created by udev. > > =20 So this code for switch_logitech was originally authored by Marcel. I can try to help clean this part up, but I'd like to treat that as an independent problem to follow up to after I get the logic for getting this Dell HW working after S3. >>>> Why do you need to *find* the device at all? Same question for the >>>> normal call case too, not only the resume case. >>>> =20 >> This is the difficult aspect of the application. The program needs to= >> poke at an HID device when it receives an event concerning an HCI >> device. Mario doesn't want to assume there will be any fixed relation= >> between the two devices (although it should be safe to assume they wil= l >> always have the same parent hub). >> >> Thus some sort of search appears to be necessary. It's not clear >> whether the search result can be saved (say in udev's database) so tha= t >> later "resuscitate" invocations don't need to repeat the search. >> =20 > > Yeah, what a hardware. :) These are all *devices* not *interfaces* > right? And we poke a sibling device which is a HID device to manage > the other sibling which shows up as the bluetooth device then? > =20 Yes, these are all individual devices. It would be a safe assumption that they have the same parent hub, so perhaps the search could be simplified. > =20 >>> 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. >>> =20 >> The unique identifier appropriate for libusb is a (bus number, device >> number) pair. >> =20 > > Yeah, that would be good to use. That's what the device nodes use too. > =20 > =20 >> These values will not change across a suspend/resume. >> I don't know whether libusb has an API to open the particular device >> given by those numbers, but it ought to. >> =20 > > I didn't see anything like that. If that can't be done, I'll just add > the few needed things to switch the device to code inside of udev and > drop that libusb thing entirely. > > =20 I'll look into switching to this pair instead. I didn't see any obvious method to select devices by these properties, but I've just skimmed libusb source looking for them. If I don't find them, i'll resubmit the patch with Marcel's recommendations of using more pointers for readabilit= y. --=20 Mario Limonciello *Dell | Linux Engineering* mario_limonciello@dell.com --------------enig3587B676844CAD69871D2DDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpeVx8ACgkQ2CrZjkA73YsiLgCfbM0lmoXkBD4qufMA7QjbXYWA UlsAniWZlAMbSPsiCppAr/EzZCw+jDh6 =XDLP -----END PGP SIGNATURE----- --------------enig3587B676844CAD69871D2DDF--