On Tue, Aug 12, 2025 at 12:28:28PM +0200, Krzysztof Kozlowski wrote: > On 12/08/2025 11:39, Laurent Pinchart wrote: > >>>> > >>>> [12/72] arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: Replace clock-frequency in camera sensor node > >>>> commit: 5433560caa5e7e677a8d4310bbec08312be765b4 > >>> > >>> I'm afraid that's too soon. This will introduce a breakage without a > >>> corresponding change to the camera sensor driver. > >>> > >>> I will post a v2 with the patches reordered. We could merge the V4L2 > >>> side in a rc1-based stable branch and merge than in the arm-soc tree as > >> > >> You cannot ("cannot" as not following the process) merge drivers into > >> DTS branch. > > > > Ah, I wasn't aware of that. DTS trees don't allow merging stable > > branches shared with other subsystems ? Does it mean that a DTS change > > Not with driver subsystems. Why? Because it breaks encapsulation of > hardware description being entirely independent of given Linux driver > implementation. > > BTW, it is already documented in maintainer-soc in ABI stability (I will > fix "devicetree" ambiguity to DTS) and driver branch dependencies. I've just read that document, and didn't interpret it as stricly forbidding merging a driver branch in the arm-soc tree. The rule makes sense though, as it makes it easier to ensure that backward compatibility isn't broken by accident. The downside is that it can slow down merging patches in some cases. > > that depends on a driver change always need to be delayed by one kernel > > version ? > > This is one solution, although as I mentioned later it still affects all > other users of DTS, so it has its own drawbacks. > > Other solution is to keep both properties for more than one cycle. > > >>> well, but I think we can also delay the .dts changes to the next kernel > >> > >> All users of DTS will be anyway affected and commit msg should address that. > > > > Which commit message, the one for the driver changes or the one for the > > DTS changes ? I plan in the next version to indicate that the DT changes > > depend on the driver changes. > > DTS changes, so the soc maintainers can judge whether they care about > other DTS users or they do not. -- Regards, Laurent Pinchart