On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote:
[...]

quoted

Ah.  I understand what you're doing now.   Hmmm.  This approach
concerns me because it relies on firmware or platform code to get CS
gpios set up properly before the driver is probed.

Yes, that was said at the very beginning of this thread.

quoted

 Firmware doesn't
always get it right, and I prefer to avoid platform specific setups as
much as possible.  Why can't the CS polarity be encoded into the
device tree so the driver *does* have the polarity data at probe time?

We have the spi-cs-high property, but it duplicates compatible
property. 'compatible' is enough to tell whether some device has
cs-high or cs-low (device's driver knows that already).

The problem is that SPI bus master doesn't know all the devices,
so it can't extract that information from the compatible string.
To workaround that we can use 'spi-cs-high', but that's ugly
workaround.

SPI modes (0,1,2,3) is another matter, some devices can work in
several modes, so 'spi-cpol' and 'spi-cpha' are actually useful.

To get a sane initial state the needed GPIOs can be set to be inputs during 
the driver's initialization.
This requires pull-up/pull-down resistors connected to the chip select 
lines. I think we can assume that they exist, because the GPIOs are all inputs 
after the controller's hardware reset and the resistors are needed to have a 
well-defined voltage level on the chip select lines. Normally the level is set 
so that the devices are disabled.

Therefore, it doesn't matter if the firmware sets the GPIOs wrong.