Re: [GIT PULL] mtd: spi-nor: Changes for 4.11

[Brian Norris <computersforpeace@gmail.com>]

On Wed, Feb 08, 2017 at 07:22:36PM +0000, Mark Brown wrote:
> On Wed, Feb 08, 2017 at 11:09:39AM -0800, Brian Norris wrote:
> 
> > But one question: *why* exactly is the transfer or message limit so
> > fixed? If a SPI controller allows manual control over the CS line, then
> > why would anybody care if a sequence of data gets split up into multiple
> > HW sequences (e.g., for a long spi_transfer, why can't we split it into
> > 2 sub-transfers, while keeping the CS asserted?).
> 
> Not every device will provide software control of the chip select line
> so it's possible you might hit limits there.  If a device does allow
> software control then yes, we should be handling this transparently in
> the core and splitting up longer transfers into chunks the device can
> handle

Thanks for the info. Then it sounds like that really should be the
dividing line; driver-visible limitations ideally should only happen
when CS is not software-controllable. (As Heiner points out, it seems
FSL ESPI is one such case.) All other cases can be handled by some form
of splitting, in the SPI core.

So that actually sounds like drivers like m25p80 should never have to
account for spi_max_transfer_size(), but instead should have to account
for only spi_max_message_size().

But that's all only a "should" -- nobody has done the work to do this
properly, and so right now, we need to check for both.

> and in fact this is already done in spi_split_transfers_maxsize(). 
> 
> We're missing masking that out in spi_max_transfer_size() though so
> clients won't know if we can handle things, it's overly conservative.

Huh, I've never noticed spi_split_transfers_maxsize(). That looks like
work for it got dropped on the floor somewhere though; nobody is using
it yet, and it's over a year since its introduction.

Brian