[PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading

[Brian Norris]

On Mon, Jun 06, 2016 at 06:40:03PM +0100, Mark Brown wrote:
> On Sat, Jun 04, 2016 at 12:22:37AM +0200, Heiner Kallweit wrote:
> > Am 06.05.2016 um 14:14 schrieb Mark Brown:
> 
> > > Yes, it's called the maximum transfer size because it is the maximum
> > > size of a transfer, not because it's the maximum size of a message.
> 
> > I'd like to come back to this discussion. You said best would be to fix
> > the chip driver. To do this and calculate an appropriate value for
> > max_transfer_size the chip driver would have to know that the spi_device
> > is a spi-nor device.
> 
> That doesn't make any sense, the controller hardware doesn't magically
> change based on what is connected to it.

I believe Heiner has an (unstated here, but stated elsewhere?)
assumption that his driver has a maximum *message* size, not *transfer*
size. So he's explaining how to work around that by implicitly figuring
out what the message size would be based on a transfer size, I think.

What I don't understand yet is whether there's some HW limitation, or
just a SW limitation, for handling *transfers* as large as
SPCOM_TRANLEN_MAX in drivers/spi/spi-fsl-espi.c, with potentially
multiple of those transfers in a single message. I would think that each
SPI transfer can mostly be handled individually. But if not, then as
mentioned previously, we'd need a new API for that: ->max_msg_size().

Brian