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

[Oliver Neukum <oliver@neukum.org>]

Am Mittwoch, 20. Mai 2009 04:17:59 schrieb Alan Stern:
> On Wed, 20 May 2009, Oliver Neukum wrote:

> > 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?
>
> I'd like to know why the device switches back from HID+bluetooth to
> pure HID during a suspend-resume sequence.  Does it undergo a
> reset-resume?

Yes.

[  111.356035] usb 2-3: reset high speed USB device using ehci_hcd and address 2
[  111.668045] usb 3-4: reset full speed USB device using ohci_hcd and address 2
[  112.177152] usb 3-4.1: reset full speed USB device using ohci_hcd and address 3
[  112.361151] usb 3-4.2: reset full speed USB device using ohci_hcd and address 4
[  112.471157] pm_op(): usb_dev_resume+0x0/0x10 returns -19
[  112.471160] PM: Device 3-4.3 failed to resume: error -19
[  112.471373] PM: resume devices took 3.256 seconds
[  112.471980] PM: Finishing wakeup.
[  112.471982] Restarting tasks ... <6>usb 3-4.3: USB disconnect, address 5
[  112.504314] btusb_send_frame: hci0 urb f4520700 submission failed
>
> Here's another question: Since there is a udev removal event for the
> radio device, why not add a udev rule to switch back to HID+bluetooth
> mode every time that event occurs?

1. You'd have two rules doing the same thing (resume & addition)
2. It is unclean, as the removal event doesn't tell you which device to run
hid2hci on
3. The device might really be physically removed
4. You can intentionally run hid2hci to switch back to HID

	Regards
		Oliver

PS: Why, oh why don't people use configurations as they were designed?