RfC: Handle SPI controller limitations like maximum message length

[Brian Norris]

On Fri, Nov 20, 2015 at 08:05:48PM +0100, Michal Suchanek wrote:
> On 20 November 2015 at 19:59, Heiner Kallweit <hkallweit1 at gmail.com> wrote:
> > Am 20.11.2015 um 13:35 schrieb Mark Brown:
> >> On Fri, Nov 20, 2015 at 11:06:47AM +0100, Heiner Kallweit wrote:
> >>> 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.
> >>
> > OK, I interpret this as:
> > Controller drivers shall return 0 only if the complete message was
> > transferred successfully.
> > If  a controller driver returns an error it has the option to set
> > actual_length to what was transferred successfully.
> >
> > This means we can't use patch 4 from Michal because it bails out as soon
> > as the underlying SPI transfer returns an error.

Right (although you meant patch 7).

> > Instead something like the spi-nor patch I sent on Oct 6th would be needed:
> > [PATCH] mtd: spi-nor: handle controller driver limitations in spi_nor_read

I don't think your patch is good either...

> > It loops over nor->read and ignores errors as long as at least something
> > was read.
> >
> 
> I don't think ignoring errors in general is good idea.

...for this reason, at least.

> If it's desirable that a partial transfer is reported as error then a
> particular error value should be defined for this case and drivers
> that can continue the transfer in a driver-specific way (such as
> spi-nor) can check for this error and handle it appropriately and pass
> through any other error.

Based on Mark's further comments (and my own intuition), I'd rather not
try to interpret different error codes to mean "truncated but keep
going" vs. "truncated for other reason, stop now", unless we really have
to.

I think if we do what Heiner was proposing from the beginning -- expose
a reasonable max SPI message length -- then I think we'll cover the bulk
of what we want. SPI NOR drivers can then try "small enough" transfers,
and if we see any errors, those are unexpected, and we abort.

Sound OK?

Brian