Re: Ranges - Intended use case

Rob Herring <[email protected]> Thu, 12 Feb 2026 13:24:20 -0600
Newsgroups org.kernel.vger.devicetree-spec
Message-ID <CAL_JsqJOO9c5HVmHcFC5COE6nJQ4wDrpvwhtTPXvGmFYjL2ySA@mail.gmail.com>
On Thu, Feb 12, 2026 at 9:33=E2=80=AFAM Yao Zi <[email protected]> wrote:
>
> On Thu, Feb 12, 2026 at 01:14:33PM +0000, Kyle Bonnici wrote:
> > Hi
> >
> > I have been trying to understand how ranges should/should not be used.
> >
> > Looking at the spec
> >
> > > The ranges property provides a means of defining a mapping or transla=
tion 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).
> >
> > This to me the spec leave some space for interpretation on if ranges sh=
ould be used on just buses or not. Below are some examples to try to get a =
better understanding.
>
> I'd like to say ranges literally specifies the translation process
> between the children address space and the parent one, regardless
> whether the parent is a "bus".

Yes.

To put it simply, "ranges" should be used whenever the child nodes
have memory-mapped CPU addresses.

> For example, reserved-memory nodes aren't really "buses", but often
> come with ranges property, as shown in the example of dt-schema[1].
>
> However it might be a signature of bad device-tree model designs if you
> have to use a ranges property for a random non-bus node.
>
> >
> > ```
> > / {
> >       foo { // not a bus
> >               #address-cells =3D <1>;
> >               #size-cells =3D <1>;
> >               ranges; // does this ranges have any meaning?
>
> I'd like to say, yes.
>
> >               bar@10 {
> >                       reg<0x10 =E2=80=A6>
> >               };
> >       };
> > };
> > ```
> >
> > ```
> > / {
> >       foo { // 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 c=
ase?
>
> Depending on what the child node represents, but IMHO it comes with a
> clear meaning.
>
> >               bar@10 {
> >                       reg<0x10 =E2=80=A6> // hence abs address is 0x110=
.
> >               };
> >       };
> > };
> > ```
> >
> > ```
> > / {
> >       foo { // bus
> >               compatible =3D <simple-bus>;
> >               #address-cells =3D <1>;
> >               #size-cells =3D <1>;
> >               ranges; // this I understand to declare that children wil=
l have direct mapping
> >
> >               bar {
> >                       ranges; // is this needed? Or is it implied that =
the foobar is in the same address space of bar?
>
> It's necessary. I don't think ranges property is ever implied.
>
> >                       foobar@10 {
> >                               reg<0x10 =E2=80=A6>  // hence abs address=
 is 0x10.
> >                       };
> >               };
> >       };
> > };
> > ```
> >
> > ```
> > / {
> >       soc { // bus
> >               compatible =3D <simple-bus>;
> >               #address-cells =3D <1>;
> >               #size-cells =3D <1>;
> >               ranges; // this I understand to declare that children wil=
l have direct mapping
> >
> >               flash@1000 {
> >                       reg<0x1000 =E2=80=A6>
> >                       ranges =3D <0x0 0x1000 =E2=80=A6>;
> >
> >                       partitions {
> >                               ranges;  // is this needed? Or is it impl=
ied that the partition1 is in the same address space of partitions?
>
> Personally I think it SHOULD be needed, though existing dt-bindings for
> fixed partition layout don't enforce such.
>
> I'm not very familiar with flash partitions and their dt patterns, so
> will leave the question for others :)

It depends. Usually no, because the partition addresses are just
offsets in the flash device. They are their own address space and not
part of the CPU address space. An exception would be a parallel
nor-flash device that is memory-mapped into the CPU's address space.
Even then, it may not be all that useful to be able to translate a
specific partition address into a CPU address.

> >                               partition1@10 {
> >                                       reg<0x10 =E2=80=A6>   // hence ab=
s address is 0x1010.
> >                               };