Segher Boessenkool wrote:

quoted

quoted

address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;

quoted

Yes, I was contemplating something like that.

Let's not define this until we need it though :-)

    Let's ot even think of it, since this will end up in a "catch all" driver, 
and yet this may be not enough when the flash doesn't support 8-but R/W, for 
example (I've already quoted it...

quoted

quoted

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

    Yeah, that's why I decided not to go that from the very start... though 
wait: I didn't do this simply because they'renot devices.
That lead me to interesting question: do device tree have something for the 
disk partitions?

"flash bus", they are "sub-devices" of their parent.

    They're quite an abstaction of a device -- althogh Linux treats them as 
separate devices indeed.

quoted

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.

    So, no "ranges" prop in MTD node is necessary? Phew... :-)

Segher

WBR, Sergei