RfC: Handle SPI controller limitations like maximum message length

[Mark Brown]

On Fri, Nov 20, 2015 at 11:06:47AM +0100, Heiner Kallweit wrote:
> On Fri, Nov 20, 2015 at 7:59 AM, Heiner Kallweit <hkallweit1 at gmail.com> wrote:

> > It would be sufficient if it's a valid case that spi_master returns 0
> > and an actual_length < requested_length as this is some kind of error
> > situation.

> I had one more look at the SPI core and e.g. spi_write_then_read
> calls spi_sync w/o checking actual_length afterwards.
> This can mean the discussed case is not valid, however it also could be
> simply a bug.

We can't assume that users of spi_write_then_read() will cope with a
restarted transfer - the usual use case is things like register I/O
where restarting a partial transfer wouldn't produce the desired result
so it's just a plain error for users of that interface.  Anything that
is able to cope needs to be using the core API directly.

> If the discussed case is valid a clear hint to all users of spi_sync and
> friends should be added that the caller can not rely on status code 0
> only but must check actual_length to verify that the complete message
> was transferred.

You'll get an error on truncation.  It may be possible to recover.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20151120/03785fd1/attachment.sig>