RfC: Handle SPI controller limitations like maximum message length

[Mark Brown]

On Thu, Nov 19, 2015 at 04:02:26PM -0800, Brian Norris wrote:
> On Wed, Nov 18, 2015 at 10:19:29PM +0100, Heiner Kallweit wrote:

> > I also add an example how a protocol driver could use this extension.
> > Appreciate any comment.

> One question I have: is it necessary to push the handling out into the
> protocol driver? I feel like I've seen a partial answer to this: the
> 'actual_legnth' return field suggests that the protocol driver already
> has to deal with shorter-than-desired transfers.

It should be possible to use actual_length if the hardware doesn't mind
the transfer being curtailed unexpectedly.

> Then I have another one: is the 'actual_length' field really
> insufficient? For instance, is it non-kosher for a spi_master to just
> cutoff the message at (for instance) 64K, and expect the protocol
> driver to handle that (e.g., with Michal's patch from [1])? And if that
> is kosher, then is there a good reason for the protocol driver to know
> the exact maximum for its spi_master?

It really depends if the hardware is able to cope with the error
handling (and ideally the SPI core will be able to transparently split
the transfer up into chunks the controller can cope with anyway).
-------------- 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/e91a953c/attachment.sig>