linux-kernel - Re: [PATCH 1/4] Bluetooth: btusb: mediatek: use readx_poll

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: <CAGp9Lzq5LrDi0qgOOWFXtGJObYEyxsMz=M_UBObwstBc9p+1=g@mail.gmail.com>
Date:   Wed, 14 Sep 2022 15:59:38 -0700
From:   Sean Wang <sean.wang@...nel.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
Cc:     sean.wang@...iatek.com, marcel@...tmann.org,
        johan.hedberg@...il.com, luiz.dentz@...il.com,
        Soul.Huang@...iatek.com, YN.Chen@...iatek.com,
        Leon.Yen@...iatek.com, Eric-SY.Chang@...iatek.com,
        Deren.Wu@...iatek.com, km.lin@...iatek.com,
        robin.chiu@...iatek.com, Eddie.Chen@...iatek.com,
        ch.yeh@...iatek.com, posh.sun@...iatek.com, ted.huang@...iatek.com,
        Stella.Chang@...iatek.com, Tom.Chou@...iatek.com,
        steve.lee@...iatek.com, jsiuda@...gle.com, frankgor@...gle.com,
        abhishekpandit@...gle.com, michaelfsun@...gle.com,
        abhishekpandit@...omium.org, mcchou@...omium.org,
        shawnku@...gle.com, linux-bluetooth@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] Bluetooth: btusb: mediatek: use readx_poll_timeout
 instead of open coding

HI Angelo,

On Tue, Sep 13, 2022 at 1:04 AM AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com> wrote:
>
> Il 13/09/22 00:18, sean.wang@...iatek.com ha scritto:
> > From: Sean Wang <sean.wang@...iatek.com>
> >
> > Use readx_poll_timeout instead of open coding to poll the hardware reset
> > status until it is done.
> >
> > Signed-off-by: Sean Wang <sean.wang@...iatek.com>
>
> Hello Sean, thanks for the patch!
> However, there's something to improve...
>
> > ---
> >   drivers/bluetooth/btusb.c | 32 ++++++++++++++++++--------------
> >   1 file changed, 18 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index c3daba17de7f..4dc9cae3e937 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
>
> ..snip..
>
> > @@ -2910,18 +2918,14 @@ static void btusb_mtk_cmd_timeout(struct hci_dev *hdev)
> >       btusb_mtk_uhw_reg_write(data, MTK_BT_SUBSYS_RST, 0);
> >       btusb_mtk_uhw_reg_read(data, MTK_BT_SUBSYS_RST, &val);
> >
> > -     /* Poll the register until reset is completed */
> > -     do {
> > -             btusb_mtk_uhw_reg_read(data, MTK_BT_MISC, &val);
> > -             if (val & MTK_BT_RST_DONE) {
> > -                     bt_dev_dbg(hdev, "Bluetooth Reset Successfully");
> > -                     break;
> > -             }
> > +     err = readx_poll_timeout(btusb_mtk_reset_done, hdev, val,
> > +                              val & MTK_BT_RST_DONE,
> > +                              100000, 1000000);
>
> I agree with using readx_poll_timeout() instead of open coding the same, but
> there's a catch: this macro uses usleep_range(), which is meant to be used
> for sleeping less than ~20ms.
>
> Even the kerneldoc at include/linux/iopoll.h advertises that:
>
>   * @sleep_us: Maximum time to sleep between reads in us (0
>   *            tight-loops).  Should be less than ~20ms since usleep_range
>   *            is used (see Documentation/timers/timers-howto.rst).
>
> So, if there's any reason for which you can't sleep for less than 100ms
> per iteration, I'm afraid that you can't use readx_poll_timeout()...
> ...otherwise, please change sleep_us to 20000 and keep the timeout at 1 sec.
>

It should be able to be done with polling in 20ms until 1 sec expires
or it is done. It increases some cost in the bus transaction
interacting with the device, but it seemed fine for me because the
code path is cold, it is only working in the device reset which should
rarely happen, and only involves when it is really necessary. That is
a nice catch. I was trying not to break the existing logic
but overlooked the requirements of the API.

    Sean

> Regards,
> Angelo
>
> > +     if (err < 0)
> > +             bt_dev_err(hdev, "Reset timeout");
> >
> > -             bt_dev_dbg(hdev, "Polling Bluetooth Reset CR");
> > -             retry++;
> > -             msleep(MTK_BT_RESET_WAIT_MS);
> > -     } while (retry < MTK_BT_RESET_NUM_TRIES);
> > +     if (val & MTK_BT_RST_DONE)
> > +             bt_dev_dbg(hdev, "Bluetooth Reset Successfully");
> >
> >       btusb_mtk_id_get(data, 0x70010200, &val);
> >       if (!val)
>