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.
>
>>> 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.
Best regards,
Krzysztof
