Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210715225146.v2.1.I68649745bd11a83265f1e816bf34ecc82775e95a@changeid>
 <57AE120A-78AE-4990-8D7F-BA8D8077B610@holtmann.org> <CAJQfnxFzj9m43wntnb2gvXkJS6B5+aQGsu7v6hc4H4ktAopk7g@mail.gmail.com>
 <A2D33DB0-40DD-4F14-BFB9-9FB34DB003A8@holtmann.org>
In-Reply-To: <A2D33DB0-40DD-4F14-BFB9-9FB34DB003A8@holtmann.org>
From:   Archie Pusaka <apusaka@google.com>
Date:   Mon, 26 Jul 2021 12:02:00 +0800
Message-ID: <CAJQfnxFikFjkGn6_+n=ycH4byzTMWY51C=+VJOycg_ZXmg=qqA@mail.gmail.com>
Subject: Re: [PATCH v2 1/3] Bluetooth: hci_h5: add WAKEUP_DISABLE flag
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     linux-bluetooth <linux-bluetooth@vger.kernel.org>,
        CrosBT Upstreaming <chromeos-bluetooth-upstreaming@chromium.org>,
        Archie Pusaka <apusaka@chromium.org>,
        Abhishek Pandit-Subedi <abhishekpandit@chromium.org>,
        Hilda Wu <hildawu@realtek.com>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Marcel,

On Fri, 23 Jul 2021 at 20:17, Marcel Holtmann <marcel@holtmann.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@chromium.org>
> >>> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> >>> Reviewed-by: Hilda Wu <hildawu@realtek.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!
>
> the v3 applied cleanly.
>
> >>
> >>
> >> And I am really close to not accepting any patches for hci_h5.c anymor=
e. 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?
>
> so a while back I send a bt3wire.c sample driver around. That would be a =
good starting point.
>
> Anyhow, the problem is that hci_uart.ko is inherent a line discipline dri=
ver from 2.4.x kernel days and it has been stacked and hacked on top of it.=
 It has become a burden, especially in the light that you can have clean se=
rdev based drivers now (like btmtkuart.c).
>
> And yes, it would be following the 3-Wire H:5 spec and then deal with ven=
dor specific details like btusb.c for example. And my hope would be that es=
pecially in the Realtek and Broadcom (RPi3 etc.) cases this can move into v=
endor specific blocks and shared between USB and UART transports.
>
> I also send around a btuart.c sample driver that is solely serdev based a=
nd should replace all the cases where we have H:4 as transport.
>

Thanks for the pointers!

The files you mentioned are rather hard to find, so below I paste the
URL where I found them in case anyone else is also interested.

[RFC v2] Bluetooth: Add new serdev based driver for UART attached controlle=
rs
https://www.spinics.net/lists/linux-bluetooth/msg74918.html

[RFC] Bluetooth: Add new serdev based driver for 3-Wire attached controller=
s
https://www.spinics.net/lists/linux-bluetooth/msg74839.html

Thanks,
Archie