SPI, _sz fields in struct spi_command

[Patrick Kelsey]

On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter <ticso at cicely7.cicely.de> wrote:
> On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote:

>> In (1) and (3) above, the drivers for those chips could usefully tell
>> the SPI bus interface that they aren't interested in received data
>> when transmitting to the SPI-attached devices, and certainly it would
>> be at least a small convenience to such SPI interface consumers to
>> have the lower level driver handle it.  Since not all host-side SPI
>> interface hardware supports discarding received data, to allow a
>> zero-sized receive buffer in the command passed down, at least some
>> SPI interface hardware drivers will have to dynamically allocate or
>> maintain a static discard buffer and provide error responses for
>> allocation-failure or transfer-too-large.
>
> If it is SPI hardware drivers decision you at least nee to take into
> account that in some RX-only cases you need 0xff dummy data.
> The slave chip driver knows if the device parses received data, but
> the master chip driver won't.
>
>> Example (2) is equally easy to handle on either side of the SPI bus
>> interface by pointing the transmit buffer pointer at the receive
>> buffer.
>
> This destroys the send data, which is not always welcome behavour.
>

My comments are in the overall context of extending the functionality
of the existing SPI bus interface in ways that provide programming
conveniences to those who wish to use them.  I am not suggesting in
any way that the current interface be narrowed based on any set of
assumptions, so in my view, there will always be a facility for fully
independent transmit and receive buffers specified by the caller.

My example (2) was for a slave device that does not have a data input
pin and thus is oblivious to any data sent.  Certainly, if you have a
device that can receive data sent by the master and your code design
calls for preserving the send data across bus transactions, you would
continue to use two separate buffers.

-Patrick