On Fri, 9 Jul 2010 14:59:09 +0200
Segher Boessenkool [off-list ref] wrote:

quoted

quoted

quoted

Actually, this is something which might need closer attention -
and maybe some support in the device tree indicating which read or
write width a device can accept?

There already is "device-width"; the drivers never should use any
other access width unless they *know* that will work.

Wouldn't you want to use "bank-width" instead?

We were talking about single devices.  But, sure, when you have
multiple devices in parallel the driver needs to know about that.

quoted

It would be nice to have a device tree property that can specify
that all access widths supported by the CPU will work, though.

Oh please no.  A device binding should not depend on what CPU there
is in the system.  There could be multiple CPUs of different
architectures, even.

What I meant by that was that the flash interface was claiming that it
is not the limiting factor in which access widths are useable -- it
would be a way to claim that it is as flexible as ordinary memory in
that regard.

If there is a transaction size that is capable of being presented to
this component that it cannot handle, it would not present this
property.

To figure out how to access a device, the driver looks at the device's
node, and all its parent nodes (or asks generic code to do that, or
platform code).

"looks" or "should look"? :-)

If there are transaction sizes supported by the CPU that won't work
with a given device through no fault of that device (or the interface
to that device for which we don't have a separate node), then in
theory, yes, it should be described at a higher level.

In reality, device tree parsing code is not AI, so rather than say "the
driver looks at this and figures it out" it would be better to provide
a more specific proposal of how a device tree might express this and
what the driver would look for, if you think the simple solution is
not expressive enough.

-Scott