RfC: Handle SPI controller limitations like maximum message length

[Mark Brown]

On Fri, Nov 20, 2015 at 01:56:13PM +0100, Martin Sperl wrote:

> > Every line of code that's in a driver that could be in the core is a
> > maintainence burden, people will want to start doing things like
> > combining functions in fun ways and if we want to try to do things like
> > figure out if we can coalesce adjacent transfers in the core (which we
> > really ought to) it won't know what the limitations that exist are.

> this “colaesce” of transfers into one could be one of those 
> “transformation” I am talking about - and this one would be implemented
> in core making certain assumptions (like starting on a page, ...)

Why would we want to force that assumption?  It massively reduces the
utility for DMA controllers that don't have such limitations.

> >> I wonder if such a variant-construct does not create more headaches in
> >> the long run as each spi_driver wanting to do something “something”
> >> special would then need to get updated for any additional constraint…

> > I'm sorry but I don't understand what you mean here.  However we
> > implement things anything that wants to know about constraints is going
> > to need to be updated to use them.

> That is what I want to avoid if possible - the one thing that may come
> handy (at least from my perspective) could be to give some hints to
> make optimal use of the HW
> Say:
> * preferred alignment on X byte boundry
> * preferred max spi_transfer.length

> All the other possible constraints parameters should be opaque to 
> a spi_device driver, so I would not want to include those inside the
> spi_master structure, as _then_ these get used.

You're conflating two unrelated design decisions here.  Yes, it's
unfortunate that the SPI API was written to allow client drivers to see
the master structure but that doesn't mean that converting data into
code is a good idea, that's still a bad pattern independently of the
visibility issue.

> Also the “restrictions” on the spi HW need to get defined inside the
> driver, so there will not be a new “restriction” that applies to
> an existing piece of HW just because we incorporate new options.

That's what I was saying?
-------------- 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/20151121/dfef5570/attachment.sig>