On Fri, 9 Jul 2010 14:59:09 +0200 Segher Boessenkool <seg...@kernel.crashing.org> wrote:
> >>> 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. > > > 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev