linux-kernel - Re: [PATCH v1] phy: qcom-qmp: Raise qcom_qmp_phy

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] [day] [month] [year] [list]

Message-ID: <CAD=FV=XE=rdqUhFD-5ZynhfgkDXN4HNs=JcKgLiqeN3Aapnj9w@mail.gmail.com>
Date:   Mon, 24 Jun 2019 08:52:40 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Marc Gonzalez <marc.w.gonzalez@...e.fr>
Cc:     Kishon Vijay Abraham <kishon@...com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] phy: qcom-qmp: Raise qcom_qmp_phy_enable() polling delay

Hi,

On Thu, Jun 13, 2019 at 8:28 AM Marc Gonzalez <marc.w.gonzalez@...e.fr> wrote:
>
> readl_poll_timeout() calls usleep_range() to sleep between reads.
> usleep_range() doesn't work efficiently for tiny values.
>
> Raise the polling delay in qcom_qmp_phy_enable() to bring it in line
> with the delay in qcom_qmp_phy_com_init().
>
> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@...e.fr>
> ---
> Vivek, do you remember why you didn't use the same delay value in
> qcom_qmp_phy_enable) and qcom_qmp_phy_com_init() ?
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index bb522b915fa9..34ff6434da8f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1548,7 +1548,7 @@ static int qcom_qmp_phy_enable(struct phy *phy)
>         status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
>         mask = cfg->mask_pcs_ready;
>
> -       ret = readl_poll_timeout(status, val, val & mask, 1,
> +       ret = readl_poll_timeout(status, val, val & mask, 10,
>                                  PHY_INIT_COMPLETE_TIMEOUT);

I would agree that the existing code is almost certainly wrong, since,
as you said, trying to sleep for 1 us is likely pointless.  I quickly
coded up a test and ran it on sdm845-cheza.  It looked like this:

--

  ktime_t a, b, c;

  a = ktime_get();
  b = ktime_get();
  usleep_range(1, 1);
  c = ktime_get();

  pr_info("DOUG: %d ns, %d ns\n", (int)ktime_to_ns(ktime_sub(b, a)),
          (int)ktime_to_ns(ktime_sub(c, b)));

--

At bootup I got:

[    4.121247] DOUG: 52 ns, 9479 ns
[    4.144990] DOUG: 52 ns, 9636 ns
[    4.328168] DOUG: 0 ns, 11667 ns
[    4.332659] DOUG: 52 ns, 7136 ns
[    4.358833] DOUG: 0 ns, 6666 ns
[    4.362095] DOUG: 52 ns, 8229 ns

So basically the existing code is already waiting 5-10 us between
polls but it's spending all of that time context switching.  Changing
the above to:

  usleep_range(5, 10);

Give me instead:

[    4.120781] DOUG: 52 ns, 16927 ns
[    4.144626] DOUG: 53 ns, 17447 ns
[    4.327932] DOUG: 52 ns, 11302 ns
[    4.332501] DOUG: 0 ns, 7395 ns
[    4.357912] DOUG: 0 ns, 6823 ns
[    4.361175] DOUG: 52 ns, 9063 ns

...and that seems fine to me.

--

Thus:

Reviewed-by: Douglas Anderson <dianders@...omium.org>