| Message ID | 4A11C126.1000704@dell.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Mon, May 18, 2009 at 03:12:22PM -0500, Mario Limonciello wrote: > Dell BT devices need to be removed from the bus and reinserted > so that userspace udev rules can transition the devices into the > proper mode after S3 or S4. This sounds wrong. What kind of reinitialisation are you talking about?
Hi Matthew: Matthew Garrett wrote: > On Mon, May 18, 2009 at 03:12:22PM -0500, Mario Limonciello wrote: > >> Dell BT devices need to be removed from the bus and reinserted >> so that userspace udev rules can transition the devices into the >> proper mode after S3 or S4. >> > > This sounds wrong. What kind of reinitialisation are you talking about? > Dell BT adapters will startup in a HID mode. In HID mode two logical USB devices are exposed, a mouse and a keyboard. If properly set, the BT radio will work with pre-paired keyboards or mice in this mode. This is useful for things like BIOS control via a BT keyboard. A command is sent to one of the descriptors of the mouse to cause the device to transition to HCI mode. When transitioned to HCI mode, a radio device is exposed allowing it to pair and operate with any BT device. Here's what the utility looks like that ships with bluez: http://git.kernel.org/?p=bluetooth/bluez.git;a=blob;f=tools/hid2hci.c;h=11d707fd76e940b884c9078907ab1504cd7350d4;hb=HEAD Look at the switch_dell method to see how it works. Currently, this is implemented via a set of udev rules shipped with bluez that match the Dell device and transition it to HCI mode. Here's the udev rule that matches: ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_CLASS}=="mouse", ATTRS{bmAttributes}=="e0", KERNEL=="mouse*", RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci" When coming out of S3 if the killswitch isn't activated, the logical USB mouse isn't coldplugged again preventing the udev rule from being matched upon. You can manually run hid2hci and the device will switch modes.
On Mon, May 18, 2009 at 04:36:40PM -0500, Mario Limonciello wrote: > Dell BT adapters will startup in a HID mode. In HID mode two logical > USB devices are exposed, a mouse and a keyboard. If properly set, the > BT radio will work with pre-paired keyboards or mice in this mode. This > is useful for things like BIOS control via a BT keyboard. A command is > sent to one of the descriptors of the mouse to cause the device to > transition to HCI mode. When transitioned to HCI mode, a radio device > is exposed allowing it to pair and operate with any BT device. > > Here's what the utility looks like that ships with bluez: > http://git.kernel.org/?p=bluetooth/bluez.git;a=blob;f=tools/hid2hci.c;h=11d707fd76e940b884c9078907ab1504cd7350d4;hb=HEAD > Look at the switch_dell method to see how it works. > > Currently, this is implemented via a set of udev rules shipped with > bluez that match the Dell device and transition it to HCI mode. > Here's the udev rule that matches: > ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_CLASS}=="mouse", ATTRS{bmAttributes}=="e0", KERNEL=="mouse*", RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci" > > When coming out of S3 if the killswitch isn't activated, the logical USB > mouse isn't coldplugged again preventing the udev rule from being > matched upon. You can manually run hid2hci and the device will switch > modes. Ok. I don't think the right way to implement this is forcing dell-laptop to simulate an unplug. The HCI driver should be responsible for saving and restoring state of the device in its suspend/resume method.
Hi Matthew, > > Dell BT adapters will startup in a HID mode. In HID mode two logical > > USB devices are exposed, a mouse and a keyboard. If properly set, the > > BT radio will work with pre-paired keyboards or mice in this mode. This > > is useful for things like BIOS control via a BT keyboard. A command is > > sent to one of the descriptors of the mouse to cause the device to > > transition to HCI mode. When transitioned to HCI mode, a radio device > > is exposed allowing it to pair and operate with any BT device. > > > > Here's what the utility looks like that ships with bluez: > > http://git.kernel.org/?p=bluetooth/bluez.git;a=blob;f=tools/hid2hci.c;h=11d707fd76e940b884c9078907ab1504cd7350d4;hb=HEAD > > Look at the switch_dell method to see how it works. > > > > Currently, this is implemented via a set of udev rules shipped with > > bluez that match the Dell device and transition it to HCI mode. > > Here's the udev rule that matches: > > ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_CLASS}=="mouse", ATTRS{bmAttributes}=="e0", KERNEL=="mouse*", RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci" > > > > When coming out of S3 if the killswitch isn't activated, the logical USB > > mouse isn't coldplugged again preventing the udev rule from being > > matched upon. You can manually run hid2hci and the device will switch > > modes. > > Ok. I don't think the right way to implement this is forcing dell-laptop > to simulate an unplug. The HCI driver should be responsible for saving > and restoring state of the device in its suspend/resume method. what do you expect the generic USB driver to do? I don't see anything we can do about it, if the device gets removed from underneath us. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 19. Mai 2009 07:14:24 schrieb Marcel Holtmann: > > > When coming out of S3 if the killswitch isn't activated, the logical > > > USB mouse isn't coldplugged again preventing the udev rule from being > > > matched upon. Â You can manually run hid2hci and the device will switch > > > modes. > > > > Ok. I don't think the right way to implement this is forcing dell-laptop > > to simulate an unplug. The HCI driver should be responsible for saving > > and restoring state of the device in its suspend/resume method. > > what do you expect the generic USB driver to do? I don't see anything we > can do about it, if the device gets removed from underneath us. In order to do this we'd have to put hid2hci into usbcore and maintain a list of devices it should operate on. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Oliver, > > > > When coming out of S3 if the killswitch isn't activated, the logical > > > > USB mouse isn't coldplugged again preventing the udev rule from being > > > > matched upon. You can manually run hid2hci and the device will switch > > > > modes. > > > > > > Ok. I don't think the right way to implement this is forcing dell-laptop > > > to simulate an unplug. The HCI driver should be responsible for saving > > > and restoring state of the device in its suspend/resume method. > > > > what do you expect the generic USB driver to do? I don't see anything we > > can do about it, if the device gets removed from underneath us. > > In order to do this we'd have to put hid2hci into usbcore and maintain > a list of devices it should operate on. you know that hid2hci is a user space utility. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 19. Mai 2009 08:45:12 schrieb Marcel Holtmann: > Hi Oliver, > > > what do you expect the generic USB driver to do? I don't see anything > > > we can do about it, if the device gets removed from underneath us. > > > > In order to do this we'd have to put hid2hci into usbcore and maintain > > a list of devices it should operate on. > > you know that hid2hci is a user space utility. Yes. I wanted to say that we'd have to port it into kernel space. I don't think it would be worth the effort. Sorry for being unclear. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 18, 2009 at 10:14:24PM -0700, Marcel Holtmann wrote: > Hi Matthew, > > Ok. I don't think the right way to implement this is forcing dell-laptop > > to simulate an unplug. The HCI driver should be responsible for saving > > and restoring state of the device in its suspend/resume method. > > what do you expect the generic USB driver to do? I don't see anything we > can do about it, if the device gets removed from underneath us. If the device is getting removed from underneath you, why isn't hid2hci being run again when it reappears as the hid device?
Am Dienstag, 19. Mai 2009 11:06:12 schrieb Matthew Garrett: > On Mon, May 18, 2009 at 10:14:24PM -0700, Marcel Holtmann wrote: > > Hi Matthew, > > > > > Ok. I don't think the right way to implement this is forcing > > > dell-laptop to simulate an unplug. The HCI driver should be responsible > > > for saving and restoring state of the device in its suspend/resume > > > method. > > > > what do you expect the generic USB driver to do? I don't see anything we > > can do about it, if the device gets removed from underneath us. > > If the device is getting removed from underneath you, why isn't hid2hci > being run again when it reappears as the hid device? udev triggers exactly that. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 19, 2009 at 02:47:33PM +0200, Oliver Neukum wrote: > Am Dienstag, 19. Mai 2009 11:06:12 schrieb Matthew Garrett: > > On Mon, May 18, 2009 at 10:14:24PM -0700, Marcel Holtmann wrote: > > > Hi Matthew, > > > > > > > Ok. I don't think the right way to implement this is forcing > > > > dell-laptop to simulate an unplug. The HCI driver should be responsible > > > > for saving and restoring state of the device in its suspend/resume > > > > method. > > > > > > what do you expect the generic USB driver to do? I don't see anything we > > > can do about it, if the device gets removed from underneath us. > > > > If the device is getting removed from underneath you, why isn't hid2hci > > being run again when it reappears as the hid device? > > udev triggers exactly that. It doesn't seem to for Mario, otherwise this patch wouldn't change anything.
Hi Guys: Matthew Garrett wrote: > On Tue, May 19, 2009 at 02:47:33PM +0200, Oliver Neukum wrote: > > > It doesn't seem to for Mario, otherwise this patch wouldn't change > anything. > > During S3, when power gets cut, the device is reset and the radio logical device no longer shows up. At no point do either of the USB keyboard/mouse devices stop showing up on the bus. Henceforth, there is no event for udev to trigger from when a mouse or keyboard gets added/removed.
On Tue, May 19, 2009 at 11:30:32AM -0500, Mario Limonciello wrote: > Hi Guys: > > Matthew Garrett wrote: > > On Tue, May 19, 2009 at 02:47:33PM +0200, Oliver Neukum wrote: > > > > > > It doesn't seem to for Mario, otherwise this patch wouldn't change > > anything. > > > > > During S3, when power gets cut, the device is reset and the radio > logical device no longer shows up. At no point do either of the USB > keyboard/mouse devices stop showing up on the bus. Henceforth, there is > no event for udev to trigger from when a mouse or keyboard gets > added/removed. I thought all USB devices got reenumerated on resume?
Hi Matthew: Matthew Garrett wrote: > On Tue, May 19, 2009 at 11:30:32AM -0500, Mario Limonciello wrote: > > > I thought all USB devices got reenumerated on resume? > Leaving udevadm monitor running on a terminal during S3, I don't see any events that would agree with this.
Am Dienstag, 19. Mai 2009 18:52:47 schrieb Mario Limonciello: > Hi Matthew: > > Matthew Garrett wrote: > > On Tue, May 19, 2009 at 11:30:32AM -0500, Mario Limonciello wrote: > > > > > > I thought all USB devices got reenumerated on resume? > > Leaving udevadm monitor running on a terminal during S3, I don't see any > events that would agree with this. If the drivers support reset_resume(), no udev event is generated, but the devices have to be present for that. Please post dmesg. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 19. Mai 2009 22:36:40 schrieb Mario Limonciello: > [ Â 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 This error shouldn't happen. But you do get a disconnection. Please recheck you see no udev event and please post "lsusb -v" before and after suspension. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 19. Mai 2009 23:47:02 schrieb Mario Limonciello: > Hi Oliver: > Attached are both the lsusb listings. As you can see, the missing > device post-suspend is that Bluetooth radio device (which is why I > proposed this patch in the first place). This explains the error in your log. > There is a udev removal event for this device, but as I said, there are > no add/remove/change events for the keyboard or mouse devices. I'm > attaching udevadm monitor ran from right before the suspend to right after. 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. > Sending the appropriate hid report to the mouse device will re-attach > this Bluetooth radio device to the bus. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
On Wed, 20 May 2009, Oliver Neukum wrote: > Am Dienstag, 19. Mai 2009 23:47:02 schrieb Mario Limonciello: > > Hi Oliver: > > > Attached are both the lsusb listings. As you can see, the missing > > device post-suspend is that Bluetooth radio device (which is why I > > proposed this patch in the first place). > > This explains the error in your log. > > > There is a udev removal event for this device, but as I said, there are > > no add/remove/change events for the keyboard or mouse devices. I'm > > attaching udevadm monitor ran from right before the suspend to right after. > > 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. > > > Sending the appropriate hid report to the mouse device will re-attach > > this Bluetooth radio device to the bus. > > 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? 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? 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? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 20 May 2009, Oliver Neukum wrote: > > 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) That's okay. Inelegant, perhaps, but workable. Besides, as we see below, the new rule would have to do more than the old rule. > 2. It is unclean, as the removal event doesn't tell you which device to run > hid2hci on I'm sure you could figure it out from the sysfs paths. > 3. The device might really be physically removed True. So you'd want to delay for a second or so before trying to do the switch and check whether the device is still attached. > 4. You can intentionally run hid2hci to switch back to HID Does that create the same removal event? If it does then you wouldd be in an unfortunate state. The script would have to check somehow whether the removal was deliberate or spontaneous. > PS: Why, oh why don't people use configurations as they were designed? I can't answer that. :-) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Alan: Alan Stern wrote: > On Wed, 20 May 2009, Oliver Neukum wrote: > > > > That's okay. Inelegant, perhaps, but workable. Besides, as we see > below, the new rule would have to do more than the old rule. > > I agree this is a rather inelegant solution. A new rule would have to be added to hid2hci then. It's much more preferable to be able to fix kernel space from mucking up the device. Is there a way to mark a device to /not/ run reset-resume after S3? > > Does that create the same removal event? If it does then you wouldd be > in an unfortunate state. The script would have to check somehow > whether the removal was deliberate or spontaneous. > Yes it does create the same removal event when you switch to HID mode. I don't know of any way that you can calculate if the switch was intentional.
On Wed, 20 May 2009, Mario Limonciello wrote: > Hi Alan: > > Alan Stern wrote: > > On Wed, 20 May 2009, Oliver Neukum wrote: > > > > > > > > That's okay. Inelegant, perhaps, but workable. Besides, as we see > > below, the new rule would have to do more than the old rule. > > > > > I agree this is a rather inelegant solution. A new rule would have to > be added to hid2hci then. It's much more preferable to be able to fix > kernel space from mucking up the device. Is there a way to mark a > device to /not/ run reset-resume after S3? echo 0 >/sys/bus/usb/devices/.../power/persist This will also prevent reset-resume after hibernation. > > Does that create the same removal event? If it does then you wouldd be > > in an unfortunate state. The script would have to check somehow > > whether the removal was deliberate or spontaneous. > > > Yes it does create the same removal event when you switch to HID mode. > I don't know of any way that you can calculate if the switch was > intentional. You can't. Instead you have to arrange things so that when the intentional change was made, it left behind a timestamp indicator. If that timestamp if present and not more than a few seconds in the past, you know the change was intentional. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From ab8b8ad20dede82f9d13293e94e76b4dd360fcf4 Mon Sep 17 00:00:00 2001 From: Mario Limonciello <Mario_Limonciello@Dell.com> Date: Mon, 18 May 2009 21:07:59 +0100 Subject: [PATCH] Explicitly disable BT radio using rfkill interface on suspend. Dell BT devices need to be removed from the bus and reinserted so that userspace udev rules can transition the devices into the proper mode after S3 or S4. --- drivers/platform/x86/dell-laptop.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c index af9f430..90a3d7c 100644 --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -186,6 +186,24 @@ static int dell_rfkill_set(int radio, enum rfkill_state state) return 0; } +static int dell_rfkill_suspend(struct device *dev, pm_message_t state) +{ + struct rfkill *rfkill = to_rfkill(dev); + + /* store state for the resume handler */ + rfkill->state_for_resume = rfkill->state; + + /* kill radio explicitly if it's on. it needs proper + * reinitialization post suspend */ + rfkill->toggle_radio(NULL,RFKILL_STATE_SOFT_BLOCKED); + + /* mark class device as suspended */ + if (dev->power.power_state.event != state.event) + dev->power.power_state = state; + + return 0; +} + static int dell_wifi_set(void *data, enum rfkill_state state) { return dell_rfkill_set(1, state); @@ -266,6 +284,7 @@ static int dell_setup_rfkill(void) bluetooth_rfkill->name = "dell-bluetooth"; bluetooth_rfkill->toggle_radio = dell_bluetooth_set; bluetooth_rfkill->get_state = dell_bluetooth_get; + bluetooth_rfkill->dev.class->suspend = dell_rfkill_suspend; ret = rfkill_register(bluetooth_rfkill); if (ret) goto err_bluetooth; -- 1.5.4.3