linux-kernel - Re: [PATCH 0/2] Reset realtek bluetooth devices during user 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Pine.LNX.4.44L0.1909181442330.1507-100000@iolanthe.rowland.org>
Date:   Wed, 18 Sep 2019 14:51:07 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
cc:     linux-bluetooth@...r.kernel.org, <linux-usb@...r.kernel.org>,
        Douglas Anderson <dianders@...omium.org>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Hui Peng <benquike@...il.com>, <linux-pm@...r.kernel.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Mark Brown <broonie@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Wolfram Sang <wsa@...-dreams.de>,
        <linux-kernel@...r.kernel.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Len Brown <len.brown@...el.com>,
        Mathias Payer <mathias.payer@...elwelt.net>,
        Dmitry Torokhov <dtor@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mans Rullgard <mans@...sr.com>, Pavel Machek <pavel@....cz>,
        YueHaibing <yuehaibing@...wei.com>
Subject: Re: [PATCH 0/2] Reset realtek bluetooth devices during user suspend

On Wed, 18 Sep 2019, Abhishek Pandit-Subedi wrote:

> Sorry, last reply went out with HTML. Re-sending in plain text.
> 
> On Wed, Sep 18, 2019 at 7:23 AM Alan Stern <stern@...land.harvard.edu> wrote:
> >
> > On Tue, 17 Sep 2019, Abhishek Pandit-Subedi wrote:
> >
> > > On a Realtek USB bluetooth device, I wanted a simple and consistent way
> > > to put the device in reset during suspend (2 reasons: to save power and
> > > disable BT as a wakeup source). Resetting it in the suspend callback
> > > causes a detach and the resume callback is not called. Hence the changes
> > > in this series to do the reset in suspend_noirq.
> >
> > What about people who _want_ BT to be a wakeup source?
> 
> When BT is enabled as a wakeup source, there is no reset.
> 
> > Why does putting the device in reset save power?  That is, a suspended
> > device is very strictly limited in the amount of current it's allowed
> > to draw from the USB bus; why should it draw significantly less when it
> > is reset?
> 
> I don't know that it's significantly less (only that it's OFF). My
> greater motivation is to make sure the bluetooth chip isn't
> accumulating events while the host is turned off. Sorry, I should have
> made that more clear in the cover letter.
> 
> When the host is off, it continues to accumulate events for the host
> to process (packets from connected devices, LE advertisements, etc).
> At some point, the firmware buffers fill up and no more events can be
> stored. When the host is resumed later on, the firmware is in a bad
> state and doesn't respond. I had originally just reset in ->resume but
> then connected wireless devices wouldn't disconnect from the BT either
> and I had trouble getting them to reconnect.
> 
> >
> > > I looked into using PERSIST and reset on resume but those seem mainly
> > > for misbehaving devices that reset themselves.
> >
> > They are, but that doesn't mean you can't use them for other things
> > too.
> >
> > > This patch series has been tested with Realtek BT hardware as well as
> > > Intel BT (test procedure = disable as wake source, user suspend and
> > > observe a detach + reattach on resume).
> >
> > This series really seems like overkill for a single kind of device.
> >
> > Is there any way to turn off the device's BT radio during suspend (if
> > wakeup is disabled) and then turn it back on during resume?  Wouldn't
> > that accomplish what you want just as well?
> 
> Probably (but I couldn't find a way to do that).

There's no way to turn off the device's BT radio?  Then what happens 
when the user turns off Bluetooth from the wireless control panel?

>  I want to prevent
> bluetooth from waking up the host and to reliably be in a good state
> when the host resumes. The reset logic I implemented causes the hci
> device to disappear and reappear, which userspace seems to handle
> gracefully.

Have you tried out the persist/reset-on-resume approach?

Alan Stern