linux-kernel - Re: [PATCH] phy: qcom: qmp: Add SDM845 PCIe QMP PHY support

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: <20190227180952.GA1803@tuxbook-pro>
Date:   Wed, 27 Feb 2019 10:09:52 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Marc Gonzalez <marc.w.gonzalez@...e.fr>
Cc:     Kishon Vijay Abraham I <kishon@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        MSM <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Can Guo <cang@...eaurora.org>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Nicolas Dechesne <nicolas.dechesne@...aro.org>
Subject: Re: [PATCH] phy: qcom: qmp: Add SDM845 PCIe QMP PHY support

On Wed 27 Feb 01:27 PST 2019, Marc Gonzalez wrote:

> On 26/02/2019 07:59, Bjorn Andersson wrote:
> 
> > qcom_qmp_phy_init() is extended to support the additional register
> > writes needed in PCS MISC and the appropriate sequences and resources
> > are defined for SDM845.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > ---
> >  .../devicetree/bindings/phy/qcom-qmp-phy.txt  |   7 +
> >  drivers/phy/qualcomm/phy-qcom-qmp.c           | 160 ++++++++++++++++++
> >  drivers/phy/qualcomm/phy-qcom-qmp.h           |  12 ++
> >  3 files changed, 179 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> > index 5d181fc3cc18..dd2725a9d3f7 100644
> > --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> > +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> > @@ -11,6 +11,7 @@ Required properties:
> >  	       "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
> >  	       "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998,
> >  	       "qcom,msm8998-qmp-ufs-phy" for UFS QMP phy on msm8998,
> > +	       "qcom,sdm845-qmp-pcie-phy" for PCIe phy on sdm845,
> >  	       "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
> >  	       "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845,
> >  	       "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845.
> > @@ -48,6 +49,10 @@ Required properties:
> >  			"aux", "cfg_ahb", "ref".
> >  		For "qcom,msm8998-qmp-ufs-phy" must contain:
> >  			"ref", "ref_aux".
> > +		For "qcom,sdm845-qmp-usb3-phy" must contain:
> > +			"aux", "cfg_ahb", "ref", "refgen".
> 
> qcom,sdm845-qmp-usb3-phy in a PCIe patch?
> 

Must have forgotten to fix it up after copy pasting the other line,
thanks for spotting.

> > +		For "qcom,sdm845-qmp-usb3-phy" must contain:
> > +			"aux", "cfg_ahb", "ref", "com_aux".
> 
> qcom,sdm845-qmp-usb3-phy again in a PCIe patch?
> 

Ditto.

> 
> > +static const struct qmp_phy_init_tbl sdm845_pcie_pcs_misc_tbl[] = {
> > +	QMP_PHY_INIT_CFG(QPHY_V3_PCS_MISC_OSC_DTCT_CONFIG2, 0x52),
> > +	QMP_PHY_INIT_CFG(QPHY_V3_PCS_MISC_OSC_DTCT_MODE2_CONFIG2, 0x10),
> > +	QMP_PHY_INIT_CFG(QPHY_V3_PCS_MISC_OSC_DTCT_MODE2_CONFIG4, 0x1a),
> > +	QMP_PHY_INIT_CFG(QPHY_V3_PCS_MISC_OSC_DTCT_MODE2_CONFIG5, 0x06),
> > +	QMP_PHY_INIT_CFG(QPHY_V3_PCS_MISC_PCIE_INT_AUX_CLK_CONFIG1, 0x00),
> > +};
> 
> I was thinking I might need to do the same for msm8998, since downstream
> tweaks pcs_misc + 0x2c = 0x52
> (dunno if that's QPHY_V3_PCS_MISC_OSC_DTCT_CONFIG2)
> 

Yeah, we probably should add the 8998 sequences as well. I haven't been
able to compare the two side by side, but it's expected that they will
be slightly different.

> The thing is, phy driver writes unconditionally to pcs_misc + 0x0c
> (QPHY_V3_PCS_MISC_CLAMP_ENABLE). Should that be moved elsewhere?
> 

I spotted this as the only difference in the initialization sequence,
but concluded that it seems to work fine as it is. So I left that part
intact.

Regards,
Bjorn