linux-kernel - Re: Qualcomm Atheros QCA61x4 keeps drawing 0.85 W despite Bluetooth being disable in GNOME

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b6c77dc7-04e6-424c-b3b6-f51f437a1671@rowland.harvard.edu>
Date:   Tue, 21 Nov 2023 12:40:32 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-pm@...r.kernel.org,
        Hans de Goede <hdegoede@...hat.com>,
        Mike Jones <mike@...nes.io>,
        Rocky Liao <quic_rjliao@...cinc.com>
Subject: Re: Qualcomm Atheros QCA61x4 keeps drawing 0.85 W despite Bluetooth
 being disable in GNOME

On Tue, Nov 21, 2023 at 06:12:30PM +0100, Paul Menzel wrote:
> Dear Alan,
> 
> 
> Thank you for your reply.
> 
> 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.)

> > >      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.

Alan Stern