On 07:14-20240520, Nishanth Menon wrote: > On 08:53-20240520, Krzysztof Kozlowski wrote: > > On 19/05/2024 22:27, Francesco Dolcini wrote: > > [...] > > > If it's not the case we'll send the patch later on, however some > > > DT files maintainers (e.g. arch/arm64/boot/dts/ti/) have a policy to > > > just accept DT file in which the binding changes are already merged > > > therefore I was trying to be a little bit proactive here. > > > > TI? Never heard something like this from them... Such requirement would > > seriously slow down any work, so it's not really reasonable. Expectation > > is to post both binding change and an user, so DTS, in case of USB in > > separate patchsets. > > There is a reason we have set that "soft rule": > - Driver subsystem merges have known to be broken from time to time and > the dt maintainer is left holding compatibles that have not made to > master. > - ARM subsystem merges prefers not to see checkpatch warnings - > typically, this happens with new compatibles in the driver subsystem. > - Off chance that driver subsystem maintainer picks up the dt changes as > well (should not happen, but has happened) > > We have however flexed the rule when: > a) driver maintainer is willing to provide us an immutable tag that we > can merge in and base the dts on top. > b) We felt that the chances of the driver not making it is very very low > (typically after 1+ month in next) and the dts change is in the wider > interest of the community. In such case, we have to explicitly take > the action of letting the patch submitter, driver subsystem to let us > know if something bad happens to the PR, also in our PR to SoC > maintainers, we have to call it out along with rationale why this is > OK. This is a bunch of work from a lot of folks, so prefer only to > trigger this path in case of exceptional cases - there have been a > few far in between. > > Again, the default rule (driver in one window, binding in next) has That went out wrong :( - correction: s/driver in one window, binding in next/driver and binding in one window, dts in the next window/ Apologies on the confusion. > kept us out of trouble for a few years now at the detriment of pace > of merges, but that took care of a lot of conflicts that we had seen > during initial days of k3 - there are few chains in the lakml list > where this was the direction we ended up in after discussion. > > But, yes - as you mentioned, send the patches of the "user" of the dt > binding and driver gives the subsystem and dt maintainers a chance to > review in the context of usage prior to the driver and binding merge. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
