Re: [PATCH] checks: Document possible false warning for graph child addresses

David Gibson <[email protected]>
Newsgroups org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-renesas-soc
Message-ID <aHnrTCiDdQ9wq_lA@zatzit>
On Tue, Jul 08, 2025 at 09:51:55AM +0200, Niklas Söderlund wrote:
> Hi David,
> 
> Thanks for your comments.
> 
> On 2025-07-08 13:07:12 +1000, David Gibson wrote:
> > On Sun, Jul 06, 2025 at 02:26:38PM +0200, Niklas Söderlund wrote:
> > > The dtc graph_child_address check can't distinguish between bindings
> > > where there can only be a single endpoint, and cases where there can be
> > > multiple endpoints.
> > > 
> > > In cases where the bindings allow for multiple endpoints but only one is
> > > described false warnings about unnecessary #address-cells/#size-cells
> > > can be generated, but only if the endpoint described have an address of
> > > 0 (A), for single endpoints with a non-zero address (B) no warnings are
> > > generated.
> > > 
> > > A)
> > >     ports {
> > > 	#address-cells = <1>;
> > > 	#size-cells = <0>;
> > > 
> > > 	port@0 {
> > > 	    #address-cells = <1>;
> > > 	    #size-cells = <0>;
> > > 
> > > 	    sourceA: endpoint@0 {
> > > 		reg = <0>
> > > 	    };
> > > 	};
> > >     };
> > > 
> > > B)
> > >     ports {
> > > 	#address-cells = <1>;
> > > 	#size-cells = <0>;
> > > 
> > > 	port@0 {
> > > 	    #address-cells = <1>;
> > > 	    #size-cells = <0>;
> > > 
> > > 	    sourceB: endpoint@1 {
> > > 		reg = <1>
> > > 	    };
> > > 	};
> > >     };
> > > 
> > > Add a comment in the check to document this.
> > 
> > Hm.  I don't know the graph bindings at all well, so I'll take your
> > word for it on what's happening here.  But simply documenting this
> > within the code doesn't seem particularly useful.  Someone running dtc
> > will still see the bogus error, and they'd have a pretty long way to
> > go to find this explanation.
> 
> It would have been useful for me, I spent a lot of time questioning 
> myself on why my dts files produced warnings and where incorrect. I even 
> submitted patches to try and work around this issue before learning 
> these where false positives. A comment here would have saved me that 
> work :-)

Well, true, but you obviously had the wherewithal to track this to the
source in the first place, putting you well ahead of most people, I
think

> I think if the check stays the comment bring some value.

True, but I think we can do better.

> > Probably better to simply remove the check (and maybe comment that it
> > would be nice to check further, but we can't adequately it from a
> > valid case).
> 
> I'm OK with removing the check too. This comment was first posted 
> together with a change to demote this check to W=2 (instead of W=1) that 
> have now been posted separately [1]. I will wait for feedback on that 
> and let smarter people then me pick the best way forward.
> 
> 1.
> https://lore.kernel.org/all/20250706123243.1050718-1-niklas.soderlund%[email protected]/

Right, that's more useful from the point of view of someone building
the kernel.  But the underlying fact here is that the check is Just
Plain Wrong - it's giving a warning on a perfectly valid situation.
It should go.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmh56zkACgkQzQJF27ox
2GfoaQ//XXwEQX3NdjTMeWxtiCJ/uKxpkiD5nZ0eQP39UazBr1bcvfK+Iv0+k++O
Bzc0vo7Wfaq0ZlxQ/epP5iRo1W5bcRxY5zoxPmXlZH2dff4/zzjbGoKZCzxJgSZg
PENCb8Lpl3MMAnsRJ3OZ9ep0WV2npP96ks1DUE30btHPAq08rlYzvDbWhLWvN7q0
Ckn38wqGVpafy2hGqBdOoUpNh5hD2srB2Uw1AKn+90aE1jpaDLp/YPb42TWKURF+
/FhLezGtx5ZUNTtm2Mc3Hz6tNPUlq5tL4Nbhr9x4f42aN6unlQT7uEHI/pEjF50a
CQXW9q0oZNnsybBfV/3Gnjdo1nrvSylZutaxOdP/3W+5ujeXwVWvCZBsWWqAo/Uj
o1inFc4XzXyHirkTvlj/xd+p+jk/gb+mqW/eWWHmU7VB/vo8ttM8vPLXdz4wW/4l
mB+FoNQg1J6QBjyRDYa49DET1n9uz6VippGliaB5wtPurCttWDmfUro8pe0S0NCV
wzNKGmefaD+JQgELbSIQF8ty7NyvN28Y2uuQo1FXRD1D7iGUS6JN6L2T1UryPqso
rjBn76t4jqGgPuXnfJ3schACQod8Zz+/W9dIYZ237tcUQc+TKva9qS9+R/caF3wC
fjxB07eNIrlh9NuYsG0kPwvHYdfBNUS/2lx81sVFsbJI6iH4UdM=
=H116
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.