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.
>
> > 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.
OK.
There's no urgency to merge the .dts changes, so I think delaying them
by one kernel release is the simplest option.
> >>> 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.
Thank you for the clarification. I will do that.
--
Regards,
Laurent Pinchart
