>>>> address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>; > >>> Yes, I was contemplating something like that. > >> Let's not define this until we need it though :-) > > Let's ot even think of it,
It is good to think about it, for the simple reason that it validates whether the current design is future-proof or not. > since this will end up in a "catch all" driver, Yeah, we shouldn't _define_ anything like this, not until it is needed anyway. > and yet this may be not enough when the flash doesn't support 8-but > R/W, for example (I've already quoted it... Yeah. There is no need to future-proof to insane designs anyway; whatever can not fit in the "generic" framework can bloody well just do its own binding, no need to pollute the generic thing. >>>> 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? Some do. Most don't. There is no standardised binding I know of. The big huge difference here is that disks typically do contain partitioning information on the disk itself, and flash doesn't. >> "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. Sure, it's a pseudo-device. Nothing new there. >>> 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... :-) Yeah, it would be positively harmful. They are pseudo-devices only, the kernel device driver needs to always access the real device. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
