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

[Mario Limonciello <mario_limonciello@dell.com>]

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

Hi Alan:

Alan Stern wrote:
> Right.  The log clearly shows that HID devices 4-1.1 and 4-1.2 survive 
> the suspend-resume cycle intact, whereas the BT device 4-1.3 is gone.
>
> Since the BT device was created by means of a userspace script in the 
> first place, it seems logical that a userspace script should respond to 
> the uevent announcing its disappearance and try to bring it back to 
> life.
>
> Last I heard, you had created a udev rule which was supposed to match
> the removal event for the BT device, but which udev wasn't executing.  
> Is that still the case?  If it is, you should post the rule together
> with the udev log for a resume.  Maybe somebody will be able to figure 
> out why the rule isn't being executed.
>   
Yeah, Kay already identified why the rule wasn't being executed.  It was
reliant on properties of the device that aren't cached in the udev database.
> Also, I noticed that your C program for reviving the BT device seemed
> more complex than necessary.  You should know beforehand that if the BT
> device's path is 4-1.3 then the corresponding mouse device's path will
> be 4-1.2 (just decrement the last byte of the pathname).  You can then
> match this device up with libusb by reading the busnum and devnum
> attributes from the sysfs directory.
>   
I wasn't sure I wanted to jump to this conclusion as I can't predict if
this will change for future hardware that supports these features.
> Alan Stern
>
>   
I'm at a loss at what else can really be done from userspace.  If I
can't match the device on removal and send it to the userspace app, not
sure how else it can be revived.
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


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