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]

Message-ID: <Y07OfmfQgQWFzHZY@hovoldconsulting.com>
Date:   Tue, 18 Oct 2022 18:04:14 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        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>,
        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:32:07AM -0400, Krzysztof Kozlowski wrote:
> On 18/10/2022 07:37, Dmitry Baryshkov wrote:
> > 
> >>> And yes, I think we should also upgrade
> >>> older DTs, keeping drivers backwards compatible (for some time?).
> >>
> >> Possibly, but I'm not sure it's worth the dts churn. As I mentioned
> >> elsewhere, supporting both the old and new binding in the driver is
> >> mostly trivial, while encoding the deprecated bindings in DT schema
> >> sounds like it would be painful.
> > 
> > This is probably the time where Krzysztof can advise us. I'm still not
> > sure when it is expected to encode both old and new bindings in the
> > schema and when we can update both the schema and the DT.
> 
> I do not follow what exactly the proposal is. Are you asking whether to:
> 1. keep existing DTS compatible with old driver?
> or
> 2. update existing DTS so it is working only with new driver (and not
> compatible with old driver thus having ABI break)?
> 
> If so, it is less question to bindings but more to the usage of DTS in
> other projects (like bootloaders, firmware, BSD) and generic
> recommendation is: do not break other users, if possible. It is however
> up to the platform maintainer (Bjorn) to decide on this, not on me.

The question is whether to convert also the current bindings and DTS to
the new (sc8280xp) scheme (e.g. drop the child nodes and register
subregions).

The driver can support both binding schemes using the same compatible
strings for a transition period (or in theory forever) by checking for
the existence of a child node.

Converting the DTS to use the new bindings would obviously prevent using
them with an old kernel (i.e. 2 above), but I don't think that's a
problem (unlike backward compatibility during at least a transition
period).

My concern was how to describe the deprecation in DT schema if we were
convert them. By instead just keeping the old bindings as-is in a
separate file and continuing to support them in the driver we can have a
nice and clean description of the new bindings (sc8280xp) without the
legacy cruft.

If we were to start introducing conditionals on existence of child
nodes, and marking the old bindings as deprecated in one large schema,
then that sounds like it would be very messy and hard to read and
maintain. But perhaps there is some way to do this without such
downsides that I'm not aware of.

Johan