[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJQfnxFzj9m43wntnb2gvXkJS6B5+aQGsu7v6hc4H4ktAopk7g@mail.gmail.com>
Date: Fri, 23 Jul 2021 19:42:56 +0800
From: Archie Pusaka <apusaka@...gle.com>
To: Marcel Holtmann <marcel@...tmann.org>
Cc: linux-bluetooth <linux-bluetooth@...r.kernel.org>,
CrosBT Upstreaming <chromeos-bluetooth-upstreaming@...omium.org>,
Archie Pusaka <apusaka@...omium.org>,
Abhishek Pandit-Subedi <abhishekpandit@...omium.org>,
Hilda Wu <hildawu@...ltek.com>,
Johan Hedberg <johan.hedberg@...il.com>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] Bluetooth: hci_h5: add WAKEUP_DISABLE flag
Hi Marcel,
On Thu, 22 Jul 2021 at 22:32, Marcel Holtmann <marcel@...tmann.org> wrote:
>
> Hi Archie,
>
> > Some RTL chips resets the FW on suspend, so wakeup is disabled on
> > those chips. This patch introduces this WAKEUP_DISABLE flag so that
> > chips that doesn't reset FW on suspend can leave the flag unset and
> > is allowed to wake the host.
> >
> > This patch also left RTL8822 WAKEUP_DISABLE flag unset, therefore
> > allowing it to wake the host, and preventing reprobing on resume.
> >
> > Signed-off-by: Archie Pusaka <apusaka@...omium.org>
> > Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> > Reviewed-by: Hilda Wu <hildawu@...ltek.com>
> >
> > ---
> >
> > Changes in v2:
> > * Remove unnecessary variable
> >
> > drivers/bluetooth/hci_h5.c | 83 +++++++++++++++++++++++++++-----------
> > 1 file changed, 59 insertions(+), 24 deletions(-)
>
> so the set does not apply cleanly to bluetooth-next
>
> Applying: Bluetooth: hci_h5: Add runtime suspend
> error: patch failed: drivers/bluetooth/hci_h5.c:11
> error: drivers/bluetooth/hci_h5.c: patch does not apply
Hmm, it applies cleanly for me. Not sure what's going on.
Anyway I rebased and made a little change as v3, please take a look!
>
>
> And I am really close to not accepting any patches for hci_h5.c anymore. This thing turns into crazy hacking and nobody is taking my hint to redo this as clean H:5 3-Wire serdev standalone driver.
Pardon my unfamiliarity, but could you share more about your vision of
a clean h5 driver? Should the RTL component be moved out to btrtl?
Do we have something as a reference?
>
> Regards
>
> Marcel
>
Thanks,
Archie
Powered by blists - more mailing lists