All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Rob Herring <robh@kernel.org>
Cc: Yao Zi <me@ziyao.cc>, Kyle Bonnici <kylebonnici@hotmail.com>,
	"devicetree-spec@vger.kernel.org"
	<devicetree-spec@vger.kernel.org>
Subject: Re: Ranges - Intended use case
Date: Fri, 13 Feb 2026 16:16:35 +1100	[thread overview]
Message-ID: <aY6zs4_vvemGd5eK@zatzit> (raw)
In-Reply-To: <CAL_JsqJOO9c5HVmHcFC5COE6nJQ4wDrpvwhtTPXvGmFYjL2ySA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Thu, Feb 12, 2026 at 01:24:20PM -0600, Rob Herring wrote:
> On Thu, Feb 12, 2026 at 9:33 AM Yao Zi <me@ziyao.cc> 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 translation between the address space of the
> > > bus (the child address space) and the address space of the bus node’s parent (the parent address space).
> > >
> > > This to me the spec leave some space for interpretation on if ranges should 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.

That's the most common case, but others exist.  You can encode cases
where a device's registers are mapped into its parent's bus address
space, but that parent address space is never mapped into the CPU MMIO
space.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-02-13  6:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 13:14 Ranges - Intended use case Kyle Bonnici
2026-02-12 15:33 ` Yao Zi
2026-02-12 19:24   ` Rob Herring
2026-02-13  5:16     ` David Gibson [this message]
2026-02-13  9:04     ` McCrae, Jamie
2026-02-14  2:02       ` David Gibson
2026-02-13  5:13 ` David Gibson

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=aY6zs4_vvemGd5eK@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=devicetree-spec@vger.kernel.org \
    --cc=kylebonnici@hotmail.com \
    --cc=me@ziyao.cc \
    --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.