linux-kernel - Re: [PATCH] Explicitly disable BT radio using rfkill interface on suspend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A13308E.4040703@dell.com>
Date:	Tue, 19 May 2009 17:19:58 -0500
From:	Mario Limonciello <mario_limonciello@...l.com>
To:	Oliver Neukum <oliver@...kum.org>
CC:	linux-usb@...r.kernel.org, Matthew Garrett <mjg59@...f.ucam.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Explicitly disable BT radio using rfkill interface on
 suspend

Hi Oliver:

Oliver Neukum wrote:
> Am Dienstag, 19. Mai 2009 23:47:02 schrieb Mario Limonciello:
>   
>
> That is correct the devices have been successfully resumed and thus are
> present. Generally the idea of suspened/resume is to have the same system
> after resumption. It is correct to not generate events. Usbcore cannot know
> that you use udev to switch the device from pure HID to HID + bluetooth.
>
>   
Right, which makes sense.
>
> Yes, the question is whether it is the clean thing to do.
>
> Marcel, are the HID devices usable after hid2hci has run? Should we
> choose to not resume from power loss any hid device which hid2hci
> operated on?
>
> 	Regards
> 		Oliver
>
>   
I can actually field this answer.  Currently those HID devices have no
purpose after hid2hci has operated on them.  If transitioned back into
full HID mode, then the mouse and keyboard HID devices can be functional.

Regards

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@...l.com


Download attachment "signature.asc" of type "application/pgp-signature" (261 bytes)