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
