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

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

>> You make no sense to me. It's like saying that knowing that a 8250 
>> chip
>> on ISA cannot be accessed if you don't know it's IO ports so it
>> shouldn't say "8250" in compatible property ?!?!?!?
>
>    No, it's a completely different case.  Base address and even flash 
> size are not the only things that matter.  There's bus width

Bus width is an (inherent) property of the _parent_
node.  Device width is normally equal to that, and
if not, it is obvious from the device model.

Also, you need to know if the devices are byte-addressable
or only per natural unit; and even more importantly,
the same question for the flash bus.

> and interleave factors

Not a property of the flash chips really.

> that influence the access (and possibly, byte-swapping too, although 
> this is unlikely to happen in PPC world).

Byte swapping?  1) This should _never_ be necessary,
just swap the data on the device itself, duh; 2) more
likely this would be determined by the flash bus, not
per flash device.

And, 3) why would you want to include this in the flash
binding while we don't yet have a reasonable overview
of in what circumstances byte swap is needed/used?

>> Also, whatever shortcomings of the linux MTD drivers are totally
>> irrelevant to what is correct to have in a device-tree. While we do
>> tailor our device-tree specification around linux needs in most cases,
>> there are cases like this one where common sense should be enough to
>> understand that it's not because the linux MTD subsystem, as of today,
>> cannot be told what programming interface to use, that we shouldn't
>> provide that information in the tree.
>
>    We did provide it, in the form of probing hints ("probe-type" prop).

Which is 103% redundant.  That same information (and
more!) is required in the "compatible" property, already.


Segher