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

[Heiner Kallweit]

Am 06.06.2016 um 21:46 schrieb Geert Uytterhoeven:
> Hi Heiner,
> 
> On Mon, Jun 6, 2016 at 8:53 PM, Heiner Kallweit <hkallweit1 at gmail.com> wrote:
>> Am 06.06.2016 um 19:40 schrieb Mark Brown:
>>> 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.
>>>
>> 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.
> 
> And you can't use pinmux to configure the pin used for hardware CS
> to become a GPIO?
> 
Sadly enough, no. Only the complete block of SPI signals can be switched
to GPIO mode. But then we'd have to use bitbanging and would loose all
features of the integrated SPI controller (FIFO's etc.)

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
>