[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKdAkRQP8DBbpdfA6yFZK6THw5eVUbdr+QnVQMkm-mLyEp5brg@mail.gmail.com>
Date: Mon, 12 Aug 2019 14:46:32 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Marcel Holtmann <marcel@...tmann.org>
Cc: Alex Lu <alex_lu@...lsil.com.cn>,
Johan Hedberg <johan.hedberg@...il.com>,
linux-bluetooth@...r.kernel.org,
lkml <linux-kernel@...r.kernel.org>,
Max Chou <max.chou@...ltek.com>
Subject: Re: [PATCH v2] Bluetooth: btusb: Fix suspend issue for Realtek devices
On Mon, Aug 12, 2019 at 9:36 AM Marcel Holtmann <marcel@...tmann.org> wrote:
>
> Hi Alex,
>
> > From the perspective of controller, global suspend means there is no
> > SET_FEATURE (DEVICE_REMOTE_WAKEUP) and controller would drop the
> > firmware. It would consume less power. So we should not send this kind
> > of SET_FEATURE when host goes to suspend state.
> > Otherwise, when making device enter selective suspend, host should send
> > SET_FEATURE to make sure the firmware remains.
> >
> > Signed-off-by: Alex Lu <alex_lu@...lsil.com.cn>
> > ---
> > drivers/bluetooth/btusb.c | 34 ++++++++++++++++++++++++++++++----
> > 1 file changed, 30 insertions(+), 4 deletions(-)
>
> this one doesn’t apply cleanly to bluetooth-next. Can you please send a version that does.
Is this a chip issue or system issue? I.e. if in some system BT
controller is wired so that it loses power over system suspend, this
is quite different form chip itself losing firmware in certain
situations, and this smells like a system issue and thus needs to be
addressed on system level.
Thanks.
--
Dmitry
Powered by blists - more mailing lists