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

[Michal Suchanek]

On 8 February 2017 at 20:09, Brian Norris <computersforpeace at gmail.com> wrote:
> + Mark, as the disagreement touches his area
>
> Hi,
>
> On Wed, Feb 08, 2017 at 11:36:10AM +0100, Cyrille Pitchen wrote:
>> Le 08/02/2017 à 06:52, Heiner Kallweit a écrit :
>> > Am 08.02.2017 um 02:09 schrieb Marek Vasut:
>> >> On 02/07/2017 04:31 PM, Cyrille Pitchen wrote:
>> [...]
>> >>> Heiner Kallweit (1):
>> >>>       mtd: m25p80: consider max message size in m25p80_read
[...]
> One example that shows both sides of this coin:
>
> 5185a81c02d4 "spi: rockchip: limit transfers to (64K - 1) bytes"
>
> The hardware has a hard limit on transfers, at least, which can only be
> 64K. For some reason there's an off-by-one error (probably a driver
> bug?), so I cheated and made it one smaller.
>
> [...]
>
> (snip the rest about trying to split spi_messages within the SPI driver;
> I agree that would be awful.)
>
> 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?).
>
> For the above rockchip SPI controller, AIUI we could actually support
> the "transfer limit" by doing this. And in fact, it could probably be
> done within the SPI core code, instead either the SPI driver or the MTD
> driver.

Yes, this is something repeatedly open-coded in SPI drivers, unfortunately.

In this case limiting the transfer size to 64k rather than doing
another clone of the manual CS handling actually looks reasonable.
It's not like anything but mtd_debug normally triggers that limit.

>
> Now, in this case, *transfer* vs. *message* seems to have a difference,
> in whether or not you have guarantees about the CS line. The CS must
> stay asserted (barring the 'cs_change' flag) between transfers, but not
> between messages.
>
> So the one thing I can see that might support Marek's disagreement here:
> does the FSL ESPI hardware support controlling the CS line? It seems
> like currently, the driver just uses a few fixed settings for its CSMODE
> register fields, whereas it might be able to support ->transfer_one()
> (and flexible CS assertion, and splitting large transactions into
> smaller chunks) if you handled that differently...

It was argued that while this is the case with most SPI controllers it
is not the case with FSL ESPI. I do not recall anybody producing any
datasheet/manual supporting this, though. It's not like this is a
confidential piece of hardware, right?

Thanks

Michal