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.51]) (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 AD23A3D902F for ; Wed, 18 Mar 2026 13:45:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=85.215.255.51 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773841509; cv=pass; b=ttHOFbCkYVH/kF4j7L19IICH37JtmBKzTBTK2Nz/RC8cxPAKNgD3spi9RcrKuvqV91OggowXnH9sh6GHwrNvF3hsznh2lkTl2sChZ9gbMUd+de3AI+vKmS01dsk+TK6X3s5nZQOs8t91OcJjk9xAawAH9eg27orclAR2/sG2Fyo= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773841509; c=relaxed/simple; bh=jsmoyK+B2YB/YkbVuYJHRq42N4JC/CiZsxNbnFBvEPQ=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=GESs2fr6LdTHh74XUgZgk6+x42c+U9IH/vQyXakYPe1H02RMOFwTzwlDpQfbvom3w4s/NTMybPxGvl+sKVW0O4xRQtJHsZipEo93CqPdFsrdNbdAG/L1LzAhxBCsX58eV3d1ugiU7m73wT9sasvkYs6bOEnlhxtoHECqo8SpW/M= 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=WkWrV69u; dkim=permerror (0-bit key) header.d=iokpp.de header.i=@iokpp.de header.b=IFpBefrV; arc=pass smtp.client-ip=85.215.255.51 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="WkWrV69u"; dkim=permerror (0-bit key) header.d=iokpp.de header.i=@iokpp.de header.b="IFpBefrV" ARC-Seal: i=1; a=rsa-sha256; t=1773841497; cv=none; d=strato.com; s=strato-dkim-0002; b=JM5NMtptFV7kW+rHzGnODRLSleLJ8ehWQ5+QIDQ+88wkwhoHKtE+OjwD0HwpxPjnkC 3CdwBMjV3vgq2MLcJOfmDATVNHnl9lr7GoMKiVQs3gUJh1LBrwhclH12O2ayopNWYzWB +KzwcssxRgz4/sanljo+1AAw6xB94q/jVTstpS9x5gxOmEOuq7EimKY9ULMj0au7O1QK mS3InUjcbm7SpjGz/xwreX14O6sQXX9pxMf3PfyLE9lf09eFR89Q+1GJmGunQPNBJu4i oi8+fHpz2Lav+tKNsGZ1VP3/63Y4B/tiEvvlFv+NS6cuSZfakBDdqUG03DkZ1KDj5LXo nfqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1773841497; 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=m6pCCyTLH/R/upQpHKKOxNO9tql4wMirFmnQbXLSPIc=; b=MfXe0zweFIKg3fN7en7Q8u6J6I7edRYgokW26q7oZAACBvlPQ+mFCgxtO24IXSe09j mAeGorNp5rHfeFDXvVB9b18h1/0AI/nFlZqXNAtG0cSrtcv4PkRyYR0Krrkf/feLP9NN 306zNGYrxksB1C6VPlt5oVyC57bDf2CVzMx97ADUAY0a/NehFdyOYZxtan4HinLzcjE+ N6QOkERdFWJ2A+9NKn9GHuXWzWkP/hsj2w1I4gmZD4YoK/cEP2ltZ77Bg7pkgrpiRGJ6 y+8DynmbjCpyKLgw+qWDW8BbHQOe45w78n2Yjz76f4jg0+BBkam2KCoX25/W9wBUnZJZ 4BnA== 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=1773841497; 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=m6pCCyTLH/R/upQpHKKOxNO9tql4wMirFmnQbXLSPIc=; b=WkWrV69uLWXDFdtKoIDBklGSeBQyfIQKVDGu2fOs+ZK7JeF3iZq0PdwP9VaHeg8/eM CFNOBX7ePM886ftCpUG4nAQDoz/xvviscLHHlZ8J/FeimUtT13JWvJRKqIe5QdD4Z5l4 DYD3ggedahc5V8CHHf05RI3BnRAIRLxaxsl9dPuLcC6+OwY9cxOY0DehU6WT8fUC2kRj uexI1tBP+Ynt3+MIVfQmSXPsauxPS+mpRyOMs6ZLDoxthj5WKABTc8PtaC7lNgV/SLKd s0pIgb8yjHL3Blb1lQSjatWp6QVVXV/c7srSJyIHZh2A2vtk2SJWBFWtsLpvlIubkkcR LVag== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1773841497; 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=m6pCCyTLH/R/upQpHKKOxNO9tql4wMirFmnQbXLSPIc=; b=IFpBefrVzHBV9RPq85szZjFosyFJ87rTvMNtL5qQd89whxWOD26PAJQy/ddGNRlIIJ jsxO/kk1PIRqX9P8knAg== X-RZG-AUTH: ":LmkFe0i9dN8c2t4QQyGBB/NDXvjDB6pBSe9tgBDSDt0V0DBslXBtZUxPOub3IZqk" Received: from [10.176.235.211] by smtp.strato.de (RZmta 55.0.1 AUTH) with ESMTPSA id z7934522IDiu9PR (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 18 Mar 2026 14:44:56 +0100 (CET) Message-ID: <3c94f0e1c5a8bf184d7a81f49b7beb999355dcd3.camel@iokpp.de> Subject: Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP From: Bean Huo To: Tudor Ambarus , pratyush@kernel.org, mwalle@kernel.org Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, zaizhang@cisco.com, Bean Huo Date: Wed, 18 Mar 2026 14:44:56 +0100 In-Reply-To: <639bd964-b499-4e9f-9035-0010fecfb17c@linaro.org> References: <20260318131857.2685004-1-beanhuo@iokpp.de> <639bd964-b499-4e9f-9035-0010fecfb17c@linaro.org> 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 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-inter= nal > > -ENOTSUPP (524) for the same condition.=C2=A0 The two codes carry ident= ical >=20 > Isn't it a better fix to update the spi controllers to use EOPNOTSUPP? Hi Zailiang Zhang,=20 Can you forward this to your colleagues and check if the SPI master driver = can be fixed to return -EOPNOTSUPP instead of -ENOTSUPP? Hi Tudor, = =20 Thank you for the review. = =20 You are right that fixing the spi controller to return -EOPNOTSUPP is the i= deal solution, and I have reached out to the reporter to investigate on their en= d. =20 = =20 However, I would suggest keeping this fix in micron-st.c for the following reasons: =20 =20 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 t= hat we are not aware of. A defensive fix here costs nothing and prevents future reports.=20 I am happy to drop this patch if you feel strongly that the fix belongs onl= y in the controller driver and the reporter confirms they can fix it on their sp= i nor master driver. Kind regards, Bean