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@xxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
