Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 15 Jun 2022 20:10:13 +0200
From:   Michael Walle <michael@walle.cc>
To:     Mika Westerberg <mika.westerberg@linux.intel.com>,
        "Oleksandr Ocheretnyi -X (oocheret - GLOBALLOGIC INC at Cisco)" 
        <oocheret@cisco.com>
CC:     "tudor.ambarus@microchip.com" <tudor.ambarus@microchip.com>,
        "miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
        "p.yadav@ti.com" <p.yadav@ti.com>,
        "richard@nod.at" <richard@nod.at>,
        "vigneshr@ti.com" <vigneshr@ti.com>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
        "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
        "mauro.lima@eclypsium.com" <mauro.lima@eclypsium.com>,
        "lee.jones@linaro.org" <lee.jones@linaro.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "xe-linux-external(mailer list)" <xe-linux-external@cisco.com>
Subject: Re: [PATCH] mtd: spi-nor: handle unsupported FSR opcodes properly
User-Agent: K-9 Mail for Android
In-Reply-To: <YqmrIsOEsFoKTwEK@lahna>
References: <YmZUCIE/ND82BlNh@lahna> <20220610191548.3626218-1-oocheret@cisco.com> <YqbWt9f3of+7Z76e@lahna> <BYAPR11MB27570F2863F7BCDFE629B3DFCDAA9@BYAPR11MB2757.namprd11.prod.outlook.com> <YqmrIsOEsFoKTwEK@lahna>
Message-ID: <6A852B9E-D84C-4F80-9C17-62BFBB98CC8A@walle.cc>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Am 15=2E Juni 2022 11:49:22 OEZ schrieb Mika Westerberg <mika=2Ewesterberg@=
linux=2Eintel=2Ecom>:
>Hi,
>
>On Tue, Jun 14, 2022 at 05:56:54PM +0000, Oleksandr Ocheretnyi -X (oocher=
et - GLOBALLOGIC INC at Cisco) wrote:
>>    Hello Mika,
>>=20
>>    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=2Ebootlin=2Ecom/linux/v5=2E19-rc2/source/drivers/=
spi/spi-m
>>    em=2Ec#L326]=2E So I decided to provide the same errorcode to
>>    intel_spi_hw_cycle() method because older kernel versions throw the
>>    error there=2E It is fine to use -EOPNOTSUPP return value instead=2E
>>=20
>>    I suspect we need to cover both cases to check -ENOTSUPP as well as
>>    -EOPNOTSUPP to let the driver work properly=2E
>>=20
>>    if (ret =3D=3D -ENOTSUPP || ret =3D=3D -EOPNOTSUPP)
>
>I think we should follow the same in the Intel driver and return
>-ENOTSUPP too=2E

AFAIK ENOTSUPP is for nfs and shouldn't be used=2E

-michael