linux-kernel - Re: [RFC PATCH v2 1/3] dt-bindings: phy: qcom,qmp-usb3-dp: Add sm6350 compatible

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: <COLFSBYDJQVH.1Q9V9ISPWR6ZX@otso>
Date:   Fri, 25 Nov 2022 15:12:24 +0100
From:   "Luca Weiss" <luca.weiss@...rphone.com>
To:     "Johan Hovold" <johan@...nel.org>
Cc:     <linux-arm-msm@...r.kernel.org>,
        <~postmarketos/upstreaming@...ts.sr.ht>,
        <phone-devel@...r.kernel.org>, "Andy Gross" <agross@...nel.org>,
        "Bjorn Andersson" <andersson@...nel.org>,
        "Konrad Dybcio" <konrad.dybcio@...aro.org>,
        "Vinod Koul" <vkoul@...nel.org>,
        "Kishon Vijay Abraham I" <kishon@...nel.org>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        <linux-phy@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 1/3] dt-bindings: phy: qcom,qmp-usb3-dp: Add
 sm6350 compatible

On Fri Nov 25, 2022 at 2:52 PM CET, Johan Hovold wrote:
> On Fri, Nov 25, 2022 at 01:53:25PM +0100, Luca Weiss wrote:
> > > Parent clocks (ref_clk_src) should not be included in the binding, but
> > > rather be handled by the clock driver. For example, see:
> > >
> > > 	https://lore.kernel.org/all/20221121085058.31213-4-johan+linaro@kernel.org/
> > > 	https://lore.kernel.org/all/20221115152956.21677-1-quic_shazhuss@quicinc.com/
> > 
> > So I assume you mean that I shouldn't do this:
> > 
> > clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
> >      <&rpmhcc RPMH_QLINK_CLK>,
> >      <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
> >      <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
> > clock-names = "aux", "ref", "com_aux", "usb3_pipe";
> > 
> > But for "ref" use GCC_USB3_PRIM_CLKREF_CLK? That also seems to work
> > fine, also if RPMH_QLINK_CLK is not used from Linux-side (checked in
> > debugfs).
>
> Exactly. Since the vendor dts describes RPMH_QLINK_CLK as parent of ref,
> I'd suggest modelling that in the clock driver. Perhaps it has just been
> left on by the boot firmware. Someone with access to docs may be able
> explain how it is supposed to be used.

RPMH_QLINK_CLK is also in msm-4.19 ref_clk_src for
GCC_UFS_MEM_CLKREF_CLK (ufsphy_mem) and also ref_clk (ufshc_mem).

Honestly since it works fine without adding this to gcc driver and I
don't really know much about clk (and have no docs for this) would it be
okay to just ignore RPMH_QLINK_CLK?

>
> > And for the driver patch, I've discovered that this phy doesn't have
> > separate txa/tbx region, so dts was also wrong there. Do you know if
> > there's a way to test DP phy initialization without having all the USB-C
> > plumbing in place? Might be good to validate at least phy init works if
> > we're already touching all of this.
>
> Do you mean that it appears to work as sc8280xp with txa/txb shared by
> both the USB and DP parts?

Yes, looks like it. Can't find any evidence pointing in any other
direction at least, everything I've seen shows .txa = 0x1200 & .txb =
0x1600.

>
> I guess you need a proper setup to test it properly. Not sure what
> you'll be able to learn otherwise, apart from whether it passes basic
> smoke testing.

Currently it's not even smoke testing because dp phy is never getting
enabled because there's no consumer. That's why I guess it was never
noticed it's wrongly described in dts.

Regards
Luca

>
> Johan