Hi Heiko & Quentin,

On Fri Jun 27, 2025 at 8:25 PM CEST, Heiko Stübner wrote:
> Am Freitag, 27. Juni 2025, 18:52:08 Mitteleuropäische Sommerzeit schrieb Diederik de Haas:
>> On Fri Jun 27, 2025 at 6:10 PM CEST, Quentin Schulz wrote:
>> > On 6/27/25 5:16 PM, Diederik de Haas wrote:
>> >> The #address-cells and #size-cells properties are not useful on the DSI
>> >> controller nodes; they are only useful/required on ports and panel(s).
>> >> So remove them from the controller node and add them where actually
>> >> needed on the various rk3399 based boards.
>> >> 
>> >> Next to that, there were several (exact) redefinitions of nodes which
>> >> are already present in rk3399-base.dtsi to add a mipi_out endpoint.
>> >> Simplify that by referencing the mipi_out phandle and add the endpoint
>> >> to that, which allows the removeal of the ports redefinition.
>> >> 
>> >> And fix 1 instance where the mipi_out referenced node was not sorted
>> >> correctly.
>> >> 
>> >> This fixes the following DTB validation warnings:
>> >> 
>> >>    unnecessary #address-cells/#size-cells without "ranges",
>> >>    "dma-ranges" or child "reg" property
>> >> 
>> >
>> > Too many unrelated changes in this commit, please split into multiple 
>> > commits.
>> >
>> > I could identify:
>> >
>> > - moving address-cells/size-cells from SoC.dtsi to board dts(i)s,
>> > - reordering properties to better match DT coding style 
>> > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node
>> > - use phandle to directly access ports,
>> > - reorder DT node to better match DT coding style 
>> > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes
>> 
>> I initially had it as several commits, but that resulted in (f.e.) 1
>> issue being fixed, but 1 (or more) others would pop up.
>> Those were then fixed in follow-up commits, but I assumed I'd get Rob's
>> bot screaming at me for introducing new warnings (first).
>> 
>> And as they all relate(d) to fixing the dsi node, I then choose to
>> combine them (but still separated by SoC).
>> IMO there are several ways to organize the commits and each would have
>> their pros and cons, so I 'settled' for this arrangement.
>> 
>> So I prefer to wait for other people's opinion first before reorganizing
>> the commits again (if there's a different consensus).
>
> personally, I can live with the current setup here, because as you said
> it's all DSI related, and also not a functional change ;-) .
>
> I guess you _could_ move the clock-master + status moves into a separate
> patch, as that should not trigger any warnings.

After having thought a bit more about it, I actually agree that the
moving of address/size-cells from SoC to board dts[i] should be separate
from extracting the ports/endpoints into a node with a phandle
reference. This patch set is actually from 2 branches:
- dtb-fixes-dsi
- dtb-fixes-ports-endpoints (although I now use 'dtb-fixes-fruit')

ports-endpoints is on top of dsi and came forth as it made sense to do
the ports/endpoints extraction in more places.
I'll then also put the DT node movement in a separate patch.

I'm not a fan of putting clock-master + status property move into a
separate patch as then the address/size patch would look weird (to me)
as you'd see how those properties were inconsistently sorted ... just so
that can be fixed in a separate patch.

Cheers,
  Diederik