From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE6872BE04C for ; Wed, 18 Mar 2026 17:18:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=85.215.255.54 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773854291; cv=pass; b=NTdal8u9dOljt/bDpKBnR2b50xtU6R5rofocJl/ZS16S3+wJbjeUfAGpW+hlhaqpXAfwRGUTXJYn8LHVZenkk+2UH3FkXxXVgehn2sNj76XOfQlFr7HKE+t7HMZSYuuVIZT27a4FBhGGOc9pxwNcXkJN+7Wt7AFT2iA9m22njSk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773854291; c=relaxed/simple; bh=iskugDkAiko+nEO5kWQZliWBqxYUnu4eB1ohXju3DxE=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=sO3nM6DlZkTbsLb/KX1OFe+L2IVLU12+JyG3Rddtqd8tYvBl2I8s4hbAOLGNterDQEg+gIRO3i4KLb3CCOSQuKQitGfuRjS+BAq0kTm33gKU9Xv4188KdDSmZ5zk48ONMtp5SOPpwDvkZgkZq4K8Q/rQUG8H7V94aC0lFLdOl4w= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=iokpp.de; spf=none smtp.mailfrom=iokpp.de; dkim=pass (2048-bit key) header.d=iokpp.de header.i=@iokpp.de header.b=brSCnAKo; dkim=permerror (0-bit key) header.d=iokpp.de header.i=@iokpp.de header.b=SZJj+Gcu; arc=pass smtp.client-ip=85.215.255.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=iokpp.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=iokpp.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=iokpp.de header.i=@iokpp.de header.b="brSCnAKo"; dkim=permerror (0-bit key) header.d=iokpp.de header.i=@iokpp.de header.b="SZJj+Gcu" ARC-Seal: i=1; a=rsa-sha256; t=1773854279; cv=none; d=strato.com; s=strato-dkim-0002; b=fdWgoq00iYlVwG8KDGC7mViZDq8QSDGdVUpNQmzWDOKDAFXr+iQstbpoYOzgDJuVvl LErcN/2+X0z40c64OVDFSkvVjUSgQUpHpLP0RreqtNZ5qBqMk7rI6a6UztkaSAKjYTRL g/U1q8lkkhY4KM5t0Gr7IWOm4CHrwPIoIjlQ6OiRjVhqiEvDkBD13SzexznQphMKHvHZ 86j3o2TykBsubI3tFMErSVLOvtIOGmXQd5XGDaLG/lN/1BnRSk8fgEecdEg9Txll8B08 yQEW296P9JHLpdpg244O8JdXV4h+EAuBoVnAkudBiIqWurv4YVigXhg5vxnM5bo90f6d zGFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1773854279; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Cc:Date: From:Subject:Sender; bh=eJG9igU4GgFHQQXkfYhJX4fK62Mj6n93ilY2UUcXHSk=; b=XGfV0thahFhnOdgXc4xQ3MfvhIAdSptnCf1Mh0+glBNmSJh9W7pPqzwLHAiMX2UMSI eT+WrJAPDpZKiHtyhVrl1Mj/+CeF5xMJZ++T/G1bf4RgtXmfW099lMao9/3+hbZTi2Md hMkb1+bOufl7HVSBNYxFSxp/BztVyHvpmwUcwkMpdE7K2ny2noo8pcWzubpjcSFlbpWz tKFDI5fk6/Zue2dwqQqu9/C/reeETQB2D9pvvOUXe47y9B1DY3TtJB1qMD33Qskaa2Oj sQnWCFo3xExNB+atrM2+V23Lfsb/zKN6n8XY+NMCuVVfhRDOWSFpW0h2nPhWitZZsmcf mjCA== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1773854279; s=strato-dkim-0002; d=iokpp.de; h=References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Cc:Date: From:Subject:Sender; bh=eJG9igU4GgFHQQXkfYhJX4fK62Mj6n93ilY2UUcXHSk=; b=brSCnAKoN8pM7b0ykmTIVIY6AICsnLc54uXtNtl26lmIObXWbI05tM6xvQ/rcPd41E gyBpBILacN3d4ud8puvJQPat9Y+EM49HzyWdl1/5eJpzgtZCrmRphze0aCkr6MF5Y19D CVIwaI1FIKqpu7F+F23MgD9095XZApfZulFqYvAunoeKFiDd0uImIzhFA9ZW5iWFVNWX TzVXt0UNpTmyhwGh7nLBl1OdYChumyljgjRJNdVlEyKBCPKTH4zfT83GphH4RYjEnuoJ aHIrdKZqgUdoIw49YuY3O0dI9T5LJHA1GvfMG6QETWmw30cUDZxHdskb7xvFudZZK3GJ XsKw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1773854279; s=strato-dkim-0003; d=iokpp.de; h=References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Cc:Date: From:Subject:Sender; bh=eJG9igU4GgFHQQXkfYhJX4fK62Mj6n93ilY2UUcXHSk=; b=SZJj+Gcu19rztr9SrjZcHMUn/THEBLUgHlVs8bBchPOsRZ7xpO/PrieR71A0QI2x4h KiIC7Ge9nUqoBpKVOSBg== X-RZG-AUTH: ":LmkFe0i9dN8c2t4QQyGBB/NDXvjDB6pBSe9tgBDSDt0V0DBslXBtZUxPOub3IZqk" Received: from [10.176.235.211] by smtp.strato.de (RZmta 55.0.1 AUTH) with ESMTPSA id z7934522IHHwARL (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 18 Mar 2026 18:17:58 +0100 (CET) Message-ID: <4223576d9f55b2a3ae18cf148765a1a5487367df.camel@iokpp.de> Subject: Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP From: Bean Huo To: "Zailiang Zhang (zaizhang)" , Tudor Ambarus , "pratyush@kernel.org" , "mwalle@kernel.org" Cc: "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Bean Huo Date: Wed, 18 Mar 2026 18:17:58 +0100 In-Reply-To: References: <20260318131857.2685004-1-beanhuo@iokpp.de> <639bd964-b499-4e9f-9035-0010fecfb17c@linaro.org> <3c94f0e1c5a8bf184d7a81f49b7beb999355dcd3.camel@iokpp.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-03-18 at 17:04 +0000, Zailiang Zhang (zaizhang) wrote: > Hi, >=20 > Our platform is using Intel Raptorlake CPU, so it=E2=80=99s not our own s= pi master > driver. > The kernel version we are using is 6.6.21. > I think when micron read fsr function calls spi_mem_exec_op(), it has > following return: > > if=C2=A0(!spi_mem_internal_supports_op(mem,=C2=A0op)) > > =C2=A0 =C2=A0 return=C2=A0-ENOTSUPP; > Please correct me if I am wrong here. Also the latest upstream kernel may= not > use the same handling code. Hi Zailiang, = =20 = =20 You are correct. the commit cff49d58f57e ("spi: Unify error codes by replac= ing - ENOTSUPP with -EOPNOTSUPP"), merged upstream on November 29, 2023, which ch= anged spi_mem_exec_op() to return -EOPNOTSUPP instead of -ENOTSUPP when an operat= ion is not supported. Kernel 6.6.21 predates this fix, which is why you see -NO= TSUPP on your platform with Intel Raptor Lake. = =20 =20 =20 Hi Tudor, = =20 =C2=A0 This changes the picture. The -ENOTSUPP Zailiang observed is coming directl= y from spi_mem_exec_op() in kernel 6.6.21, before commit cff49d58f57e was in place. That commit fixed the SPI mem framework itself, but it may not have = been backported to all stable trees. = =20 =20 I would therefore argue that our micron-st.c fix is still worth keeping for= the the reason that it provides a safety net for stable kernels that did not re= ceive cff49d58f57e as a backport. =20 That said, I am happy to follow your guidance on how to proceed.=C2=A0 =20 Kind regards, = =20 Bean >=20 > Please decide the fixup accordingly. >=20 > Thanks, > Zailiang >=20 > From: Bean Huo > Date: Wednesday, March 18, 2026 at 6:45=E2=80=AFAM > To: Tudor Ambarus , pratyush@kernel.org > , mwalle@kernel.org > Cc: linux-mtd@lists.infradead.org , > linux-kernel@vger.kernel.org , Zailiang Zha= ng > (zaizhang) , Bean Huo > Subject: Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for > controllers returning -ENOTSUPP >=20 > On Wed, 2026-03-18 at 15:26 +0200, Tudor Ambarus wrote: > > Hi, Bean! > >=20 > > On 3/18/26 3:18 PM, Bean Huo wrote: > > > From: Bean Huo > > >=20 > > > micron_st_nor_ready() falls back to SR-only polling when the SPI > > > controller does not support low-level FSR reads, but only checks for > > > -EOPNOTSUPP (95).=C2=A0 Some SPI master drivers return the kernel-int= ernal > > > -ENOTSUPP (524) for the same condition.=C2=A0 The two codes carry ide= ntical > >=20 > > Isn't it a better fix to update the spi controllers to use EOPNOTSUPP? >=20 >=20 > Hi Zailiang Zhang, >=20 > Can you forward this to your colleagues and check if the SPI master drive= r can > be fixed to return -EOPNOTSUPP instead of -ENOTSUPP? >=20 >=20 > Hi Tudor, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > Thank you for the review. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > You are right that fixing the spi controller to return -EOPNOTSUPP is the > ideal > solution, and I have reached out to the reporter to investigate on their = end.=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > However, I would suggest keeping this fix in micron-st.c for the followin= g > reasons:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0 > 1, The offending SPI master driver appears to be out-of-tree/downstream, = so we > cannot guarantee an upstream fix will reach all affected platforms. > 2, spi-mem.c already treats both -ENOTSUPP and -EOPNOTSUPP as equivalent = in > spi_mem_exec_op() so this one-liner aligns micron_st_nor_ready() with the > convention already established in the SPI mem framework. > 3, there may be other SPI controllers in the field with the same behavior= that > we are not aware of. A defensive fix here costs nothing and prevents futu= re > reports. >=20 > I am happy to drop this patch if you feel strongly that the fix belongs o= nly > in > the controller driver and the reporter confirms they can fix it on their = spi > nor > master driver. >=20 > Kind regards, > Bean