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

[Mark Brown]

On Mon, Jun 06, 2016 at 08:53:10PM +0200, Heiner Kallweit wrote:
> Am 06.06.2016 um 19:40 schrieb Mark Brown:

> > That doesn't make any sense, the controller hardware doesn't 
> > magically change based on what is connected to it.

> The issue with fsl-espi is that the controller deactivates CS after
> each physical transfer. And a lot of HW designs use the hardware CS,
> therefore the advise to use a GPIO instead doesn't really help.

There's no pinmux to fix the broken behaviour?  The Freescale SPI
controllers really are terrible :(

> In case of SPI NOR CS needs to stay active between command and data

In the case of *all* SPI transactions this needs to happen.  This is
*not* optional, it's not some weird requirement of NOR, it's one of the
most basic requirements for a SPI driver on Linux.

> Well, we could reduce the max_transfer_size exposed by the driver by
> the max length of a m25p80 read command in general.

No!  Apart from anything else this would be a complete and total
abstraction failure.  This is a driver for a SPI controller, not a
driver for a flash controller, which means that it should not have flash
specific hacks in it.

> Then we might be too strict for other SPI devices, but this may
> be acceptable as the current fsl-espi driver is usable with SPI NOR
> devices only anyway.

What makes you say this?  I'm guessing that the driver is just broken
but it would be good to understand the specifics.
-------------- 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/20160607/6ac613c5/attachment.sig>