linux-kernel - Re: [PATCH v1 2/3] arm64: dts: ti: Add Aquila AM69 Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251110094716.GA7356@francesco-nb>
Date: Mon, 10 Nov 2025 10:47:16 +0100
From: Francesco Dolcini <francesco@...cini.it>
To: Vignesh Raghavendra <vigneshr@...com>
Cc: Francesco Dolcini <francesco@...cini.it>, Andrew Davis <afd@...com>,
	Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Parth Pancholi <parth.pancholi@...adex.com>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Emanuele Ghidoli <emanuele.ghidoli@...adex.com>,
	Ernest Van Hoecke <ernest.vanhoecke@...adex.com>,
	João Paulo Gonçalves <joao.goncalves@...adex.com>,
	Francesco Dolcini <francesco.dolcini@...adex.com>
Subject: Re: [PATCH v1 2/3] arm64: dts: ti: Add Aquila AM69 Support

Hi Vignesh,

On Mon, Nov 10, 2025 at 10:06:58AM +0530, Vignesh Raghavendra wrote:
> On 06/11/25 15:49, Francesco Dolcini wrote:
> >>> Yes, known. Is this an issue?
> >>>
> >>> This node must be disabled, no matter what is present in any included
> >>> dtsi file, it's a deliberate decision.
> >>>
> >>> This dtsi file describes a SoM, the used pins/functions are defined on
> >>> the pinout, but this node cannot be enabled unless the SoM is mated with
> >>> a carrier board that is exposing it.
> >> Same as my point above, you shouldn't enable nodes that are not used
> >> or have anything attached. The SoM only has some edge connectors so
> >> it should not be enabled at the SoM level, that we seem to agree, but
> >> the carrier board doesn't connect those lines to anything either. They
> >> just run to a pin header with nothing attached, how is that header
> >> any different than the pins on the edge of the SoM?
> > You are commenting something unrelated here, or I am not understanding
> > you.
> > 
> > You commented that the status = "disabled" is redundant. We both agree
> > that this node needs to be disabled in the SoM dtsi, and it is already
> > like that.
> > 
> > I would prefer to keep the redundant "disabled", because I see value on
> > not having to rely on what is done on any included dtsi, where the
> > original node is defined. 
> 
> 
> One can always reverse compile the DTB to see if a node is enabled or not.

Sure. My reason for having it explicitly disabled here is not to have to
depend on anything that is happening on the included dtsi on this
regard, given that we really want those disabled in the SoM.

See for example https://lore.kernel.org/all/20251015111344.3639415-1-s-vadapalli@ti.com/
where you can see that our verdin am62 was not impacted by this change
at all. 

To me this is just a benefit, without any drawback.

> > I see this as a common pattern in multiple
> > dts/dtsi file and is what I would prefer to have (and I do not see any
> > kind of maintenance  overhead on having it nor this being in conflict
> > with dts-coding-style.rst).
> 
> I cannot seem to find any precedence to such a pattern (adding status =
> "disabled" for nodes that are already disabled at SoC level dtsi.) Could
> you point me to some?

Just a couple of examples, you can easily find more if needed

  k3-am62-verdin.dtsi:&main_spi1
  nxp/imx/imx6qdl-phytec-phycore-som.dtsi:&fec


> > Vignesh, Nishanth, what is your expectation on this redundant
> > `status = "disabled"` property?
> > 	
> 
> Assuming such pattern exists, please add a note in the commit message in
> the next version.

With that said, it's a small thing, if you prefer me to change it just
let me know and I'll send a v2 with this changed.

Vignesh: do you prefer a v2 with a mention in the commit message on the
`disabled` node, or that I just get rid of those? Anything else that you
spotted on this patch and that should be changed?

Francesco