linux-kernel - Re: [PATCH 09/15] dt-bindings: phy: qcom,qmp-pcie: mark current bindings as legacy

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]

Date:   Tue, 18 Oct 2022 17:49:33 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...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>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/15] dt-bindings: phy: qcom,qmp-pcie: mark current
 bindings as legacy

On Tue, Oct 18, 2022 at 11:27:35AM -0400, Krzysztof Kozlowski wrote:
> On 18/10/2022 03:06, Johan Hovold wrote:
> > On Mon, Oct 17, 2022 at 01:15:45PM -0400, Krzysztof Kozlowski wrote:
> >> On 17/10/2022 10:53, Johan Hovold wrote:
> >>> The current QMP PCIe PHY bindings are based on the original MSM8996
> >>> binding which provided multiple PHYs per IP block and these in turn were
> >>> described by child nodes.

> >>> In preparation for adding new bindings for SC8280XP which further
> >>> bindings can be based on, mark the current bindings as "legacy".
> >>>
> >>> Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> >>> ---
> >>>  .../{qcom,qmp-pcie-phy.yaml => qcom,qmp-pcie-phy-legacy.yaml} | 4 ++--
> >>
> >> I don't think we should rename anything as legacy. These are "normal"
> >> platforms, not legacy ones. SM8450 is not even that old.
> > 
> > I'm not really referring to the platforms as legacy, but the rather the
> > format of the bindings. The intent is that by marking the current ones
> > as such, people will not base new bindings on the old scheme.
> > 
> > There's no problem supporting both schemes in the driver also for the
> > current compatibles, but expressing such a deprecation in DT schema
> > sounds like it would be painful. We instead decided to simple draw the
> > line at SC8280XP and have future bindings be based on its binding.
> > 
> >> The recommendation is to keep names matching the compatibles, not adding
> >> some legacy/newer/newest suffixes.
> > 
> > Yeah, I know, but that's not what the current bindings do. And if we
> > keep 
> > 
> > 	qcom,qmp-pcie-phy.yaml
> > 
> > and add
> > 
> > 	qcom,sc8280xp-qmp-pcie-phy.yaml
> > 
> > then I fear that people will base their bindings on the former rather
> > than the latter.
> 
> Then how about renaming this file to something matching the oldest
> supported SoC? Like: qcom,msm8998-qmp-pcie-phy.yaml
> (I don't know which one is the oldest there)
> 
> Or ipq6018 as the first one appearing in the list.

Sounds good. :)

> > I could also rename the old schema file after one of the old platforms
> > platforms therein (e.g. qcom,msm8998-qmp-pcie-phy) to make it sounds
> > less like a generic schema for new bindings.
> 
> Oh, we thought about the same.
> 
> > 
> > That is
> > 
> > 	qcom,msm8998-qmp-pcie-phy.yaml + comment (for current bindings)
> > 	qcom,sc8280xp-qmp-pcie-phy.yaml (for new bindings)
> 
> Yes, please.

I'll go with that then. Thanks!

Johan