[PATCH] powerpc: Create "rom" (MTD) device prpmc2800

[Segher Boessenkool]

>>>    No! It doesn't have anything to do with "ranges" of parent (don't 
>>> even know why it would). :-O
>
>> So learn about it please?  "ranges" means exactly that:
>> child nodes' address space is direct mapped.
>
>    Well, now we certainly need a parent node -- which would be static 
> bus controller?

I have no clue what a "static bus controller" is.  Your
flash node obviously needs _some_ parent node though --
this is a tree after all.

> But those have multiple chips selects, so we should know which range 
> to use. Ugh...

That is described in the "reg" property of the flash
node, just like for any other node.

>> Because that is a) not what you are supposed to do according
>> to the standard (so it might very well not work with a
>> "third-party" device tree that equally conforms to the standard);
>> b) "device_type" describes some other information (namely, the
>> OF programming model for the device node) that is completely
>> unrelated to the process of driver matching; and c) it is wholly
>> redundant to the information in "compatible" *ANYWAY*.
>
>    Hm, well. Than changing "compatible" prop would make sense.

Yes.

>>> And why you haven't complained at MPC5200 IDE driver
>
>> Since no one paid me to review the code?  Please don't try
>
>    Sigh, nobody pays me for that too. :-)

Yeah it's a shame isn't it?

>>> which does the same (well, maybe you have :-) or at PowerMac IDE 
>>> driver which matches wither by "name" or "device_type"? Well, quite 
>>> a lot of drivers are doing this...
>
>> See before why that may be.  Short answer is "history".
>
>    Well, at least that's cleared.

Okido, good to hear.

>>>    Anyway, reasonable suggestions on how to make MTD nodes more 
>>> viable are always welcome. I just haven't seen reasonable enough 
>>> yet. ;-)
>
>> I suggest you read, and try to understand, some of the base
>> device tree specifications first.
>
>    Read them some months ago -- do you think I would have plunged into 
> that not reading anything first? :-/

It seems we really need more howto-style docs...


Segher