All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Quentin Schulz <quentin.schulz@cherry.de>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Diederik de Haas <didi.debian@cknow.org>
Cc: Dragan Simic <dsimic@manjaro.org>,
	Johan Jonker <jbx6244@gmail.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/8] arm64: dts: rockchip: Refactor DSI nodes on rk3399 boards
Date: Fri, 27 Jun 2025 20:25:07 +0200	[thread overview]
Message-ID: <5121698.88bMQJbFj6@diego> (raw)
In-Reply-To: <DAXGZG0DEKS2.7RLXKSDO0C9T@cknow.org>

Am Freitag, 27. Juni 2025, 18:52:08 Mitteleuropäische Sommerzeit schrieb Diederik de Haas:
> Hi Quentin,
> 
> Thanks for taking a look.
> 
> 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.


> > The change for RK3399 Puma Haikou Video Demo DTSO is fine for me.
> 
> Thanks :)
> 
> Cheers,
>   Diederik
> 






WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Quentin Schulz <quentin.schulz@cherry.de>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Diederik de Haas <didi.debian@cknow.org>
Cc: Dragan Simic <dsimic@manjaro.org>,
	Johan Jonker <jbx6244@gmail.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/8] arm64: dts: rockchip: Refactor DSI nodes on rk3399 boards
Date: Fri, 27 Jun 2025 20:25:07 +0200	[thread overview]
Message-ID: <5121698.88bMQJbFj6@diego> (raw)
In-Reply-To: <DAXGZG0DEKS2.7RLXKSDO0C9T@cknow.org>

Am Freitag, 27. Juni 2025, 18:52:08 Mitteleuropäische Sommerzeit schrieb Diederik de Haas:
> Hi Quentin,
> 
> Thanks for taking a look.
> 
> 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.


> > The change for RK3399 Puma Haikou Video Demo DTSO is fine for me.
> 
> Thanks :)
> 
> Cheers,
>   Diederik
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-06-27 19:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-27 15:16 [PATCH 0/8] Fix several DTB validation issues Diederik de Haas
2025-06-27 15:16 ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 1/8] arm64: dts: rockchip: Refactor DSI nodes on px30 boards Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 2/8] arm64: dts: rockchip: Refactor DSI nodes on rk3399 boards Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas
2025-06-27 16:10   ` Quentin Schulz
2025-06-27 16:10     ` Quentin Schulz
2025-06-27 16:52     ` Diederik de Haas
2025-06-27 16:52       ` Diederik de Haas
2025-06-27 18:25       ` Heiko Stübner [this message]
2025-06-27 18:25         ` Heiko Stübner
2025-06-28  8:57         ` Diederik de Haas
2025-06-28  8:57           ` Diederik de Haas
2025-06-29  0:32   ` kernel test robot
2025-06-29  0:32     ` kernel test robot
2025-06-29 10:09     ` Diederik de Haas
2025-06-29 10:09       ` Diederik de Haas
2025-06-30  5:57       ` Krzysztof Kozlowski
2025-06-30  5:57         ` Krzysztof Kozlowski
2025-06-30 13:12         ` Diederik de Haas
2025-06-30 13:12           ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 3/8] dt-bindings: display: rockchip,dw-mipi-dsi: Drop address/size cells Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 4/8] arm64: dts: rockchip: Simplify VOP port definition on rk3328 Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 5/8] arm64: dts: rockchip: Simplify edp endpoints on several rk3399 boards Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 6/8] arm64: dts: rockchip: Fix LCD panel port on rk3566-pinetab2 Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 7/8] arm64: dts: rockchip: Drop unneeded address+size-cells on px30 Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas
2025-06-27 15:16 ` [PATCH 8/8] arm64: dts: rockchip: Drop regulator-compatible property on rk3399 Diederik de Haas
2025-06-27 15:16   ` Diederik de Haas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5121698.88bMQJbFj6@diego \
    --to=heiko@sntech.de \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.org \
    --cc=dsimic@manjaro.org \
    --cc=jbx6244@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=quentin.schulz@cherry.de \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.