Re: [PATCH] Explicitly disable BT radio using rfkill interface on

[Mario Limonciello <mario_limonciello@dell.com>]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

Hi Kay & Alan

Kay Sievers wrote:
> On Wed, Jul 15, 2009 at 04:07, Alan Stern<stern@rowland.harvard.edu> wrote:
>   
>> On Wed, 15 Jul 2009, Kay Sievers wrote:
>>
>>     
>>>> 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.
>>>       
>> That's absolutely right.  At the time the USB device event takes place,
>> the HID driver might not even be loaded yet!
>>     
>
> Right, and even when it's loaded, there is no guarantee, that this
> device is already created by udev.
>
>   
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.
>>>>         
>> 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 will
>> 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 that
>> later "resuscitate" invocations don't need to repeat the search.
>>     
>
> 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?
>   
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.
>   
>>> 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.
>>>       
>> The unique identifier appropriate for libusb is a (bus number, device
>> number) pair.
>>     
>
> Yeah, that would be good to use. That's what the device nodes use too.
>   

>   
>> 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.
>>     
>
> 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.
>
>   
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 readability.
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]