Message-ID: <e334e265-fde0-29df-d905-c3ec4941f152@linaro.org>
Date:   Tue, 18 Oct 2022 12:44:22 -0400
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Johan Hovold <johan@...nel.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 18/10/2022 12:04, Johan Hovold wrote:
> 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).

It is still not nice towards any other users of DTS, because this will
break all of them. I agree this won't be ABI type of break. It is
discouraged though, unless there are clear benefits from this or one
totally does not care about other DTS users...

As I said it is up to platform maintainer.

> 
> 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.

You cannot have one compatible in two schemas, so for old bindings (and
DTS):
1. Don't convert them,
2. Convert with keeping old properties - as you pointed this might be
full of conditionals/allOf, so difficult to maintain and read,
3. Convert dropping old stuff.

For the option 3. for sure Rob will ask why. :)

> 
> 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.


Best regards,
Krzysztof

Powered by blists - more mailing lists