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

[Segher Boessenkool <segher@kernel.crashing.org>]

>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>
>>> The compatible is supposed to be useable to find and match a driver
>>> without regard to the name of the node.  Perhaps direct-mapped-rom?
>>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>
>> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
>> like a good start.
>
>    No, it doesn't -- since that info is almost *absolutely* useless 
> (the only exception is "cfi") in the context of Linux MTD subsys.
>    Please, try to understand that knowing that chip is CFI compatible 
> in itself doesn't yet guarantee that you can access the chip -- it all 
> depends on its mapping to the real physical address range, therefore 
> this group IMO cannot even constitute a valid "compatible" property.

You obviously completely misunderstand the semantics
of the "compatible" property.

>> People here tried to create a generic "flash" device binding.
>> It didn't work out (part of the problem is its scope was way
>> too big; another problem is it was too Linux-mtd specific).
>
>    And that's why its worked, and the abstaractly "correct" scheme 
> wouldn't have.

Ha.  Ha.  Ha.  Great joke :-)

>> Now since the probing is done in platform-specific code here,
>> you don't *need* an "official" binding -- just get your
>> "compatible" prop right so you can correctly probe the device
>> node, and then maybe add some node-specific properties if you
>> need them.
>
>    I wonder what are you trying to get us to do: directly call stuff 
> from drivers/mtd/ or what (that's especially starnge because we now 
> have an OF driver for simply mapped NOR flashes)?

I am pointing out how to do a flash node in a platform-
specific way, in platform-specific code, since there is
no working "generic" way yet (and very likely there will
never be).


Segher