Re: Ranges - Intended use case

--rA3yM6Rw9LKJ2/zG
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 12, 2026 at 01:14:33PM +0000, Kyle Bonnici wrote:
> Hi=20
>=20
> I have been trying to understand how ranges should/should not be used.
>=20
> Looking at the spec=20
>=20
> > The ranges property provides a means of defining a mapping or translati=
on between the address space of the
> bus (the child address space) and the address space of the bus node=E2=80=
=99s parent (the parent address space).
>=20
> This to me the spec leave some space for interpretation on if ranges shou=
ld be used on just buses or not. Below are some examples to try to get a be=
tter understanding.
>=20
> ```
> / {
> 	foo { // not a bus
> 		#address-cells =3D <1>;
> 		#size-cells =3D <1>;
> 		ranges; // does this ranges have any meaning?

An empty ranges property is a special case, which means there is an
identity mapping between parent and child.  In this case, this is
invalid - / has no #address-cells or #size-cells properties, meaning
the parent bus has the default values of 2 and 1 respectively.  Since
#address-cells is different from the child bus, you can't use an empty
ranges property here.

> 		bar@10 {
> 			reg<0x10 =E2=80=A6>=20
> 		};
> 	};
> };
> ```
>=20
> ```
> / {
> 	foo { // not a bus

I'm not sure that there's really any hard distinction between a "bus"
and "not a bus".

> 		#address-cells =3D <1>;
> 		#size-cells =3D <1>;
> 		reg =3D <0x100 0x50>;
> 		ranges =3D <0x0 0x100 0x50>; // is this an intended use case?

It's a perfectly valid use case.  In this case again, the format is
invalid since the parent's #address-cells defaults to 2.  It should be:
	ranges =3D <0x0 0x0 0x100 0x50>;

> 		bar@10 {
> 			reg<0x10 =E2=80=A6> // hence abs address is 0x110.=20
> 		};
> 	};
> };
> ```
>=20
> ```
> / {
> 	foo { // bus
> 		compatible =3D <simple-bus>;
> 		#address-cells =3D <1>;
> 		#size-cells =3D <1>;
> 		ranges; // this I understand to declare that children will have direct =
mapping
>=20
> 		bar {
> 			ranges; // is this needed? Or is it implied that the foobar is in the =
same address space of bar?

It is needed.  If there is no ranges property, the child registers are
not directly accessible from the parent address space (they might be
indirectly accessible via registers in the bus bridge).

This is again technically invalid: bar has no #address-cells so it
defaults to 2, which differs from the parent.

> 			foobar@10 {
> 				reg<0x10 =E2=80=A6>  // hence abs address is 0x10.=20
> 			};
> 		};
> 	};
> };
> ```
>=20
> ```
> / {
> 	soc { // bus
> 		compatible =3D <simple-bus>;
> 		#address-cells =3D <1>;
> 		#size-cells =3D <1>;
> 		ranges; // this I understand to declare that children will have direct =
mapping
>=20
> 		flash@1000 {
> 			reg<0x1000 =E2=80=A6>=20
> 			ranges =3D <0x0 0x1000 =E2=80=A6>;
> 	=09
> 			partitions {
> 				ranges;  // is this needed? Or is it implied that the partition1 is i=
n the same address space of partitions?
>=20
> 				partition1@10 {
> 					reg<0x10 =E2=80=A6>   // hence abs address is 0x1010.=20
> 				};
> 			};
> 		};
> 	};
> };
> ```
>=20
> Looking forward to explanations on this topic to extend my understanding =
of devicetree
>=20
> Regards
> Kyle

--=20
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

--rA3yM6Rw9LKJ2/zG
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmmOsvoACgkQzQJF27ox
2Gcepw/8DDvgp+wZmpxJsQ588VhpwiLrF2ldgxkophiGEX8zCsfElkMFNT4HYaCp
IOUOUwAdayIyZIsT4XPMyij6ePDwsyKr/uqwQXWUVn1dfES6byNEKK+GAdk1SKxJ
+Y3fxUFIxlwcdXJOZuSEdkZVa6x+6kFrO0jl3pi2h0CtjcEj5SiyO+ZzDjklEX2u
jjctcnK8Cn+4JG7U+y0FB1ZSIePbzFH4wvz9jR5/PAEBNnwpVYg7R48bHyHtmbwJ
uJgmM+LbTNXSv0eLgVc3n80k60IgNANeKjzm5qBcTSJrYPFPsWyXeclPAOihaHAF
I7BAGXNtB1Uf2MG2+FE2MxmdEuP9bZ5gXg19t5Ux+z9d/02M36UIpq9cLmWug+3O
DvE7E2970iSvSF6bb2LT7WWBH89bAphfDJcLeRL1JG33NCX422vv3XrgOptBiS3d
fbmImzBEypUBPjt9O5ig0Dpf8pwcBocEO++7IvEeKwtY+Cu8ViB2Jlhihn3ecDR/
8sXDt0W4W7w0yervMxNSu4BOOaaNGiJO91zYRrtBirvpKLNh8xNMveq+Qtloua3K
yvny40BjXnFWrvErAh0qZ14vLTWOvVPzufAjf1PffAZOKQhCrOMdQLrHtvmDYRea
cBkZGlcRVwQ3XUSL4AtF5NzP+W5GNjzk4u2hud8mBJa9efzCmNk=
=LnPG
-----END PGP SIGNATURE-----

--rA3yM6Rw9LKJ2/zG--