Dear Alan, dear Hans,
Am 21.11.23 um 18:40 schrieb Alan Stern:
On Tue, Nov 21, 2023 at 06:12:30PM +0100, Paul Menzel wrote:
Am 21.11.23 um 17:23 schrieb Alan Stern:
[340560.441957] usb 1-3: finish reset-resume
[340560.570940] usb 1-3: reset full-speed USB device number 2 using xhci_hcd
Those two lines are unexpected. Why does the device need to be reset?
While the btusb module is loaded, does anything show up in
/sys/bus/usb/devices/1-3/quirks?
$ more /sys/bus/usb/devices/1-3/quirks
0x2
Ah. 0x2 is the RESET_RESUME quirk bit. The fact that it is on explains
why the device gets reset when it is resumed.
It also explains why the device isn't getting suspended. The USB core
will not autosuspend a device that has the RESET_RESUME quirk if its
driver wants remote-wakeup or does not support reset-resume. The btusb
driver is like that.
Apparently the RESET_RESUME quirk bit is set by the btusb driver itself
(see the btusb_check_needs_reset_resume() routine in btusb.c), based on
the computing platform rather than on the Bluetooth device. The
btusb_needs_reset_resume_table[] contains three entries: Dell OptiPlex
3060, Dell XPS 9360, and Dell Inspiron 5565.
Since your system is an XPS 9360, it has this problem with suspending
the onboard Bluetooth device. The only way the kernel can deal with it
is to avoid putting the device into runtime suspend while the driver
module is loaded.
So there's your answer. If you rebuild the btusb driver after removing
the XPS 9360 entry from btusb_needs_reset_resume_table[], you should
find that the device does get runtime suspended. (But then it might not
operate properly if you try to turn it on again after it has been
suspended.)
Thank you for finding this. This is commit 596b07a9a226 (Bluetooth:
btusb: Add Dell XPS 13 9360 to btusb_needs_reset_resume_table) from
April 2018 [1]. Hans, was it ever confirmed to be a platform limitation?
Does the Microsoft Windows driver do the same? Did the Dell engineers
verify it with the schematics? I was unable to see this in the bug
report [2].
Also, it would be nice, if Linux logged, if quirks are applied that
affect power usage.
As Alan wrote, that I’d need to rebuild the module to deactivate the
behavior, there is no switch to override the quirk table, right?
bmAttributes 0xe0
Self Powered
Remote Wakeup
That's what I was interested in. The device does support remote wakeup.
That would make sense so it can be resumed? (It does not necessarily mean
something like Wake-On-LAN, right?
It _does_ mean something like Wake-On-LAN: The device is capable of
asking the system to wake it up under some conditions while it or the
system is suspended.
Also, for this device it’s disabled?
$ grep . /sys/bus/usb/devices/1-3/power/wakeup
disabled
Yes. You can change that setting by writing "enabled" to the sysfs
file. But I don't think this will make any difference to your runtime
suspend problem; the power/wakeup setting affects only system suspend,
not runtime suspend.
Thank you again for the clarification.
Kind regards,
Paul
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=596b07a9a22656493726edf1739569102bd3e136
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
