Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Cc: linux-bluetooth@vger.kernel.org, <linux-usb@vger.kernel.org>,
	Douglas Anderson <dianders@chromium.org>,
	Kai-Heng Feng <kai.heng.feng@canonical.com>,
	Hui Peng <benquike@gmail.com>, <linux-pm@vger.kernel.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mark Brown <broonie@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Wolfram Sang <wsa@the-dreams.de>, <linux-kernel@vger.kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Len Brown <len.brown@intel.com>,
	Mathias Payer <mathias.payer@nebelwelt.net>,
	Dmitry Torokhov <dtor@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mans Rullgard <mans@mansr.com>, Pavel Machek <pavel@ucw.cz>,
	YueHaibing <yuehaibing@huawei.com>
Subject: Re: [PATCH 0/2] Reset realtek bluetooth devices during user suspend
Date: Wed, 18 Sep 2019 14:51:07 -0400 (EDT)
Message-ID: <Pine.LNX.4.44L0.1909181442330.1507-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <CANFp7mX=THOVk-4TgSSscgtm598txqesDZYKE2sFtEVNHjN+-g@mail.gmail.com>

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


  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 21:27 Abhishek Pandit-Subedi
2019-09-17 21:27 ` [PATCH 1/2] usb: support suspend_noirq Abhishek Pandit-Subedi
2019-10-04 11:58   ` Greg Kroah-Hartman
2019-09-17 21:27 ` [PATCH 2/2] Bluetooth: btusb: Reset realtek devices on user suspend Abhishek Pandit-Subedi
2019-10-04 11:59   ` Greg KH
2019-09-18 14:23 ` [PATCH 0/2] Reset realtek bluetooth devices during " Alan Stern
2019-09-18 17:19   ` Abhishek Pandit-Subedi
2019-09-18 18:51     ` Alan Stern [this message]
2019-09-26 20:51       ` Abhishek Pandit-Subedi
2019-09-18 14:41 ` Oliver Neukum

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1909181442330.1507-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=abhishekpandit@chromium.org \
    --cc=benquike@gmail.com \
    --cc=broonie@kernel.org \
    --cc=dianders@chromium.org \
    --cc=dtor@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan.hedberg@gmail.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=len.brown@intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=marcel@holtmann.org \
    --cc=mathias.payer@nebelwelt.net \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=suzuki.poulose@arm.com \
    --cc=wsa@the-dreams.de \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git