linux-kernel - Re: [PATCH 08/13] phy: qcom-qmp-pcie: drop power-down delay config

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y0V66q53I4ivlXI+@hovoldconsulting.com>
Date:   Tue, 11 Oct 2022 16:17:14 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Vinod Koul <vkoul@...nel.org>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/13] phy: qcom-qmp-pcie: drop power-down delay config

On Tue, Oct 11, 2022 at 05:04:04PM +0300, Dmitry Baryshkov wrote:
> On 11/10/2022 16:53, Johan Hovold wrote:
> > On Tue, Oct 11, 2022 at 04:46:53PM +0300, Dmitry Baryshkov wrote:
> >> On 11/10/2022 16:14, Johan Hovold wrote:
> >>> The power-down delay was included in the first version of the QMP driver
> >>> as an optional delay after powering on the PHY (using
> >>> POWER_DOWN_CONTROL) and just before starting it. Later changes modified
> >>> this sequence by powering on before initialising the PHY, but the
> >>> optional delay stayed where it was (i.e. before starting the PHY).
> >>>
> >>> The vendor driver does not use a delay before starting the PHY and this
> >>> is likely not needed on any platform unless there is a corresponding
> >>> delay in the vendor kernel init sequence tables (i.e. in devicetree).
> >>>
> >>> Let's keep the delay for now, but drop the redundant delay period
> >>> configuration while increasing the unnecessarily low timer slack
> >>> somewhat.
> >>
> >> Actually, the vendor driver does this 995..1005 sleep. But contrary to
> >> our driver it does that after programming whole PHY init sequence, which
> >> includes SW_RESET / START_CTL, but before programming the pipe clocks.
> > 
> > Right, it does it after starting the PHY which means that you don't have
> > to poll for as long for the PHY status.
> > 
> > It's a different delay entirely.
> 
> No-no-no. The 995-1005 delay was added guess for which SoC? For ipq8074, 
> where the config tables contain the ugly CFG_L writes for SW_RESET / 
> START_CTRL. So, it is the same delay, but added by somebody who didn't 
> care enough. The original 10-11 delay is a completely different story, 
> you are correct here.

Yeah, I noticed that ipq8074 was the first to abuse the prwdn_delay
and possibly because of it starting the PHY already in its PCS table
(which it never should have).

I'm talking about the intent of pwrdn_delay which was to add a delay
after powering-on the phy and before starting it.

The vendor driver has a 1 ms delay after starting the PHY and before it
starts polling as the PHY on newer SoC tend to take > 1 ms before they
are ready.

So, I still claim that that delay in the vendor driver is a different
one entirely.

> Thus, I'd say, the PCIe delay should be moved after the registers 
> programming.

No, not necessarily. Again, that's an optimisation in the vendor driver
to avoid polling so many times. Since I can say for sure that there are
no PHY that start in less than 1 ms, I wouldn't add it unconditionally.

Either way, separate change.
 
> >> I think we can either drop this delay completely, or move it before
> >> read_poll_timeout().
> > 
> > It definitely shouldn't be used for any new platforms, but I opted for
> > the conservative route of keeping it in case some of the older platforms
> > actually do need it.
> > 
> > My bet is that this is all copy-paste cruft that could be removed, but
> > I'd rather do that as a separate follow-on change. Perhaps after testing
> > some more SoC after removing the delay.
> > 
> > SC8280XP certainly doesn't need it.
> 
> I think in our case this delay just falls into status polling. We'd 
> probably need it, if we'd add the noretain handling.

I'm not sure I understand what you're referring to here ("noretain
handling")?

Johan