On Sun, Jan 16, 2022 at 11:45 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote: > > On 16/01/2022 22:38, Linus Walleij wrote: > > On Sun, Jan 16, 2022 at 6:10 PM Krzysztof Kozlowski > > <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote: > > > >> Anyway DTS and dtschema will have to wait for one release, because they > >> depend on samsung pinctrl driver change (patch #2). > > > > What about I put that (and maybe this schema) on an immutable > > branch so you can pull the commit into your for-arm-soc branch and > > put the DTS changes on top? > > That would be a solution if not a policy for arm-soc of keeping DTS > separate. Arnd and Olof since some time are not happy when DTS branch > receives any driver updates. > > Arnd, Olof, > This is a set of dtschema conversion + DTS alignment with new schema: > 1. Driver change necessary to accept new DTS (driver depends on node > names and this has to change because of dtschema), > 2. DTS commits depending on above, which convert node name to new format, > 3. Finally dtschema requiring new naming of the GPIO nodes. > > If I got correctly, the policy of not mixing drivers and DTS requires > that #2 above (DTS changes) will wait for one more release. During the > time, if dtschema (#3 above) is applied, there will be new warnings > about non-compliant DTS. > > Do you see any chance of merging driver + DTS + dtschema via same tree > in same release? Our general guidance to separate DTS and driver changes is to avoid large entangled changes between the two, and to discourage a developer mentality of "the implementation is the binding". I think this is a good example of when it makes sense to bring in what is a fairly small and clean driver change to deal with this. So the right answer here is to stage such a stable branch and merge into both arm-soc and the pinctrl subsystem trees as proposed. -Olof
