On Tue, May 16, 2023 at 11:06:41AM +0200, Krzysztof Kozlowski wrote: > On 16/05/2023 10:57, Conor Dooley wrote: > > On Tue, May 16, 2023 at 10:31:19AM +0200, Krzysztof Kozlowski wrote: > >> On 15/05/2023 21:20, Conor Dooley wrote: > >>> + - Defer the devicetree changes to a release after the binding and driver have > >>> + already been merged > >>> + > >>> + - Change the bindings in a shared immutable branch that is used as the base for > >>> + both the driver change and the devicetree changes > >> > >> The policy told to me some time ago was that no merges from driver > >> branch or tree are allowed towards DTS branch, even if they come only > >> with binding header change. There are exceptions for this, e.g. [1], but > >> that would mean we need to express here rules for cross-tree merges. > > > > I've got away with having an immutable branch for dt-binding headers! > > Of course, all is in an immutable branch, but in which tree? For example: - dt-bindings & header with the clock defines in the base/immutable branch on top of -rc1 - driver patches on top of the immutable branch, in a PR to Stephen - dts patches on top of the immutable branch, PR to Arnd So, clock tree doesn't get the dts, soc tree doesn't get the driver. Hopefully that clarifies what I meant. > I talk about a case when driver tree, e.g. different clock maintainer, > takes the binding. If the other tree just "takes the binding", without some coordination, then you're SOOL and have to wait a release. > > That said, Arnd did actually have a look at this (and suggested some > > changes) before I sent it & did not cry fowl about this section. IIRC, > > this is actually his wording, not mine. Probably worth Arnd chiming in & just telling us what he is okay with taking. Cheers, Conor.
Attachment:
signature.asc
Description: PGP signature
