lkml.org 
[lkml]   [2022]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mtd: spi-nor: handle unsupported FSR opcodes properly
On Wed, Jun 15, 2022 at 08:10:13PM +0200, Michael Walle wrote:
> Am 15. Juni 2022 11:49:22 OEZ schrieb Mika Westerberg <mika.westerberg@linux.intel.com>:
> >Hi,
> >
> >On Tue, Jun 14, 2022 at 05:56:54PM +0000, Oleksandr Ocheretnyi -X (oocheret - GLOBALLOGIC INC at Cisco) wrote:
> >> Hello Mika,
> >>
> >> in my case (I work with memory chip n25q128a13 for recent kernels) I'm
> >> getting return value -ENOTSUPP from spi_mem_exec_op() call in the
> >> micron_st_nor_read_fsr() method
> >> [[1]https://elixir.bootlin.com/linux/v5.19-rc2/source/drivers/spi/spi-m
> >> em.c#L326]. So I decided to provide the same errorcode to
> >> intel_spi_hw_cycle() method because older kernel versions throw the
> >> error there. It is fine to use -EOPNOTSUPP return value instead.
> >>
> >> I suspect we need to cover both cases to check -ENOTSUPP as well as
> >> -EOPNOTSUPP to let the driver work properly.
> >>
> >> if (ret == -ENOTSUPP || ret == -EOPNOTSUPP)
> >
> >I think we should follow the same in the Intel driver and return
> >-ENOTSUPP too.
>
> AFAIK ENOTSUPP is for nfs and shouldn't be used.

Yes, but that's what the SPI-NOR core is using so I think we want to be
consistent with it.

\
 
 \ /
  Last update: 2022-06-16 07:29    [W:0.098 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site