From: David Gibson <david@gibson.dropbear.id.au>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
Date: Fri, 10 Aug 2007 11:07:23 +1000 [thread overview]
Message-ID: <20070810010723.GB17370@localhost.localdomain> (raw)
In-Reply-To: <019ae19815eb3301065ba732e3e72f44@kernel.crashing.org>
On Thu, Aug 09, 2007 at 09:53:41PM +0200, Segher Boessenkool wrote:
> >>>> I haven't heard or thought of anything better either. Using
> >>>> "ranges"
> >>>> is conceptually wrong, even ignoring the technical problems that
> >>>> come
> >>>> with it.
> >>>
> >>> Why is "ranges" conceptually wrong?
> >>
> >> The flash partitions aren't separate devices sitting on a
> >> "flash bus", they are "sub-devices" of their parent.
> >
> > Well, yes, but nonetheless the partitions show up as part of the
> > overall physical address space. How do you encode that other than in
> > 'ranges'?
>
> All that address space shows up in the flash node already. To
> access the partitions you have to go via that "master" node
> anyway (some commands have to be sent to address 0 on the flash,
> or similar).
Hrm, I suppose. Although for read-only access that's not relevant.
> It is a very nice feature to not only be able to translate addresses
> "up" the device tree, but also "down".
I don't follow, sorry.
> Also, it mimics reality, just like a good OF citizen should:
> those partitions aren't actually devices at all, so they
> certainly shouldn't be assigned a part of the host address
> space.
Hrm. I'm not entirely convinced that the distinction between
"actually a device" and "not actually a device" is really as clear cut
as you imply.
> >>> To be honest this looks rather to me like another case where having
> >>> overlapping 'reg' and 'ranges' would actually make sense.
> >>
> >> It never makes sense. You should give the "master" device
> >> the full "reg" range it covers, and have it define its own
> >> address space; "sub-devices" can carve out their little hunk
> >> from that. You don't want more than one device owning the
> >> same address range in the same address space.
> >
> > Why not? After all, the physical address ranges of the flash
> > partitions really do overlap with that of the flash device as a whole.
>
> They don't overlap, a partition is a proper subset of the flash.
A proper subset is a form of overlapping (indeed cases of being a
proper subset form a proper subset of cases of overlapping, to be
gratuitously meta-set-theoretic).
> Which as usual is shown as "reg" in the child node and #a,#s in
> the parent node.
That in no way encodes that the child addresses are a subset of the
parent address space. Instead #a and #s establish a new, separate
address space for the children, and without 'ranges', there's no
information about any sort of connection, overlapping, proper-subset
or otherwise, with the parent address space.
--
David Gibson | 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
next prev parent reply other threads:[~2007-08-10 1:07 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 15:06 [PATCH 2/6] PowerPC 440EPx: Sequoia DTS Valentine Barshak
2007-08-01 2:08 ` David Gibson
2007-08-01 4:57 ` Segher Boessenkool
2007-08-01 5:04 ` David Gibson
2007-08-01 5:47 ` David Gibson
2007-08-02 15:23 ` Sergei Shtylyov
2007-08-03 3:13 ` David Gibson
2007-08-03 15:47 ` Sergei Shtylyov
2007-08-06 4:21 ` David Gibson
2007-08-06 18:37 ` Sergei Shtylyov
2007-08-06 21:03 ` Segher Boessenkool
2007-08-06 22:15 ` Benjamin Herrenschmidt
2007-08-06 23:09 ` Segher Boessenkool
2007-08-07 3:29 ` David Gibson
2007-08-07 3:28 ` David Gibson
2007-08-07 15:43 ` Scott Wood
2007-08-07 17:01 ` Segher Boessenkool
2007-08-07 16:43 ` Segher Boessenkool
2007-08-08 0:35 ` David Gibson
2007-08-19 12:59 ` Sergei Shtylyov
2007-08-06 20:54 ` Segher Boessenkool
2007-08-07 4:12 ` David Gibson
2007-08-07 16:51 ` Segher Boessenkool
2007-08-08 1:13 ` David Gibson
2007-08-09 19:53 ` Segher Boessenkool
2007-08-10 1:07 ` David Gibson [this message]
2007-08-10 20:48 ` Segher Boessenkool
2007-08-24 19:10 ` Sergei Shtylyov
2007-08-24 20:43 ` Segher Boessenkool
2007-08-06 20:35 ` Segher Boessenkool
2007-08-07 4:09 ` David Gibson
2007-08-07 16:58 ` Segher Boessenkool
2007-08-08 0:48 ` David Gibson
2007-08-06 20:20 ` Segher Boessenkool
2007-08-07 3:35 ` David Gibson
2007-08-06 20:12 ` Segher Boessenkool
2007-08-02 20:18 ` Josh Boyer
2007-08-03 0:49 ` David Gibson
2007-08-03 16:29 ` Sergei Shtylyov
2007-08-06 4:31 ` David Gibson
2007-08-06 20:55 ` Segher Boessenkool
2007-08-06 20:41 ` Segher Boessenkool
2007-08-06 19:59 ` Segher Boessenkool
2007-08-07 3:41 ` David Gibson
2007-08-07 16:33 ` Segher Boessenkool
2007-08-08 1:51 ` David Gibson
2007-08-09 20:00 ` Segher Boessenkool
2007-08-10 1:11 ` David Gibson
2007-08-02 20:16 ` Josh Boyer
2007-08-01 14:13 ` Valentine Barshak
2007-08-02 1:00 ` David Gibson
2007-08-02 20:15 ` Josh Boyer
2007-08-06 20:15 ` Segher Boessenkool
2007-08-07 4:11 ` 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=20070810010723.GB17370@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=segher@kernel.crashing.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).