[PATCH, 1/2] mtd: m25p80: Let m25p80_read() fallback to spi transfer

[Michal Suchanek]

On 20 January 2017 at 23:38, Marek Vasut <marex at denx.de> wrote:
> On 01/20/2017 10:50 PM, Kamal Dasu wrote:
>> In m25p80_read() even though spi_flash_read() is supported
>> by some drivers, under certain circumstances like unaligned
>> buffer, address or address range limitations on certain SoCs
>> let it fallback to core spi reads. Such drivers are expected
>> to return -EINVAL so that the m25p80_read() uses standard
>> spi transfer.
>>
>> Signed-off-by: Kamal Dasu <kdasu.kdev at gmail.com>
>> ---
>>  drivers/mtd/devices/m25p80.c | 11 +++++++++--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index 9cf7fcd..7b7f2cc 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -155,9 +155,16 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t from, size_t len,
>>               msg.data_nbits = m25p80_rx_nbits(nor);
>>
>>               ret = spi_flash_read(spi, &msg);
>> -             if (ret < 0)
>> +
>> +             if (ret >= 0)
>> +                     return msg.retlen;
>
> ret can never be > 0 , it is only 0 or negative .
>
>> +             /*
>> +              * some spi master drivers might need to fallback to
>> +              * normal spi transfer
>> +              */
>> +             if (ret != -EINVAL)
>>                       return ret;
>
> This looks really fragile and special-casing EINVAL here doesn't scale.
> But still, if your controller driver is buggy, fix the driver, do not
> pollute core code with workarounds. If you do support this sort of
> accelerated read and it fails, it means something is seriously wrong.
> If you need to invoke regular SPI reads to complete under some obscure
> circumstances, do it from the driver, not here.

I guess the other half of m25p80_read can be factored out and used as
fallback from either m25p80_read or the controller driver.

Thanks

Michal