Re: RfC: Handle SPI controller limitations like maximum message length

[Michal Suchanek <hramrach@xxxxxxxxx>]

On 20 November 2015 at 20:21, Mark Brown <broonie@xxxxxxxxxx> wrote:
> On Fri, Nov 20, 2015 at 08:05:48PM +0100, Michal Suchanek wrote:
>
>> I don't think ignoring errors in general is good idea.
>
>> 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.
>
> Fundamentally callers just shouldn't be trying to do excessively large
> transfers in the first place, this is why we want capability reporting.
> *Any* error code could indicate a truncation, we may have truncated due
> to some length limitation but it could also be that there was some
> hardware problem that occurred mid transfer or something similar.

Indeed, and in the case the SPI master driver truncated the message
due to known limitation before it even attempted a transfer it can
assure with as much certainty as is possible with SPI bus that this
much data was transferred, no more and no less. In contrast, a DMA
failure that is detected after the fact can leave the hardware in
unknown state. So I see a difference here.

And yes, for some driver protocols transferring less data than was
initially requested is not acceptable. For example, if you transferred
Ethernet frames to an Ethernet controller the frames must be
transferred fully.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html