RfC: Handle SPI controller limitations like maximum message length

[Mark Brown]

On Wed, Nov 18, 2015 at 11:50:00PM +0100, Heiner Kallweit wrote:
> Am 18.11.2015 um 22:57 schrieb Mark Brown:
> > On Wed, Nov 18, 2015 at 10:19:29PM +0100, Heiner Kallweit wrote:

> >> There have been few discussions in the past about how to handle SPI controller
> >> limitations like max message length. However they don't seem to have resulted
> >> in accepted patches yet.

> > No, they've resulted in people writing code.  We've got a bunch of
> > things in the spi_master struct like the limits on speeds and bits per
> > word.

> Sure, I'm aware of this. To you it might sound obvious to handle such
> limitations in the SPI core, however there have been several attempts
> to deal with such limitations in controller or protocol drivers.

They're documented using terms like "limits" and "constraints" - it's
hard to see what we're missing there.

> >> Maybe a better approach would be to introduce a new member of spi_master
> >> dealing with controller limitations.

> > That's what we've been doing...

> Primary addressees of my comment were users of the SPI core trying to deal
> in their own code with things which might be better dealt with in the core.

Well, we do to the extent we can do anything useful in the core we have
code to deal with them - we constrain clocks and we have error checking
for the bits per word settings for example.

> In case there should be more need to reflect such limitations in spi_master
> it might be good to encapsulate them in a separate struct instead of adding
> more such members to spi_master directly.

It's going to be annoying to move everything over and TBH I'm not sure
it really helps much.  This is honestly the first time I can recall
anyone expressing any confusion here.
-------------- 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/20151119/b3bc9ef0/attachment-0001.sig>