RfC: Handle SPI controller limitations like maximum message length

[Heiner Kallweit]

Am 21.11.2015 um 00:22 schrieb 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.

Based on what was discussed so far I'll submit a patch series as basis
for further discussion.

Heiner
> 
> Sound OK?
> 
> Brian
>