[PATCH] powerpc: Create "rom" (MTD) device prpmc2800
Segher Boessenkool
segher at kernel.crashing.org
Sun Jun 3 13:40:57 EDT 2007
>>> 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
More information about the linux-mtd
mailing list