From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 39F6C3C73F9 for ; Thu, 19 Mar 2026 11:20:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773919202; cv=none; b=o8/+COD4iI/NjRNH3y7aEXBFR6R8WoMxfdncPI4mBMxF28od+bCd0d+vHplx/1QMPXsk+dqsshVE+cQ6cFGkaJ5ao0yOPtgv3u6ciA/lwP9mpCfevx8AF0ZHKjkzWooqYOSv52kuXG7c+yT5AAo0v7p5mZWMDospGWl7HrxXpCo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773919202; c=relaxed/simple; bh=rPGCScFkKKklOwGyPYozRiKe7JFfv9zlARAYV3PpNXE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ZDPf4ADMz8VXTkT7ttev1JujqnQMv3858srPxu5jnPNV6bQtuFU9uxz53Uopmm6pOkopL8f3QJG0C2fkFLTeO6JopSWmFtEWsZT89hlhXCRTQzNxSIQrtj7GtM5w4oeRNBMU4bXJq8QqyqqYIpXG5yNnFzpe1B7mJZBRNfpEETM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CNojlXk/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CNojlXk/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45846C19424; Thu, 19 Mar 2026 11:20:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773919202; bh=rPGCScFkKKklOwGyPYozRiKe7JFfv9zlARAYV3PpNXE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CNojlXk/H1O2BzNEvxp3/c8NaAYCupGKEnEaoB/gqVzT/RmnKY20iQnNhOzMqLmgx xD44/uQR2o3l2mmYY+s9ektOxCGdmHAgNxYmuXVzAoybBRNJESa/QuwzF4qqmyTSc4 RVr/d4U6qNCyqxalOjK7zhHugSzF8vB/AWSRjMDJJ8xomaeONDCGiH931aOFcnfflA sm6VcYCu4lVbHL+pLThEzpIRMVJzUvsrw4LxD+FnPpNWvj1MXdWuPx0ENzXRZensTY oW4U2rvcIpLnKeX8wKaZtxyiWklvH5mtWRAW3ZtN+dZVB5EcKiUcOTyGi3PNApagpj qmi31fi4naztw== From: Pratyush Yadav To: Tudor Ambarus Cc: Bean Huo , "Zailiang Zhang (zaizhang)" , "pratyush@kernel.org" , "mwalle@kernel.org" , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Bean Huo Subject: Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP In-Reply-To: <36e65648-707c-4b45-a429-1ea7f9f65f07@linaro.org> (Tudor Ambarus's message of "Thu, 19 Mar 2026 11:10:56 +0200") References: <20260318131857.2685004-1-beanhuo@iokpp.de> <639bd964-b499-4e9f-9035-0010fecfb17c@linaro.org> <3c94f0e1c5a8bf184d7a81f49b7beb999355dcd3.camel@iokpp.de> <4223576d9f55b2a3ae18cf148765a1a5487367df.camel@iokpp.de> <36e65648-707c-4b45-a429-1ea7f9f65f07@linaro.org> Date: Thu, 19 Mar 2026 11:19:58 +0000 Message-ID: <2vxz7br8cbhd.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 19 2026, Tudor Ambarus wrote: > On 3/18/26 7:17 PM, Bean Huo wrote: >> On Wed, 2026-03-18 at 17:04 +0000, Zailiang Zhang (zaizhang) wrote: >>> Hi, >>> >>> Our platform is using Intel Raptorlake CPU, so it=E2=80=99s not our own= spi 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 m= ay not >>> use the same handling code. >>=20 >>=20 >> Hi Zailiang,=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >> You are correct. the commit cff49d58f57e ("spi: Unify error codes by rep= lacing - >> ENOTSUPP with -EOPNOTSUPP"), merged upstream on November 29, 2023, which= changed >> spi_mem_exec_op() to return -EOPNOTSUPP instead of -ENOTSUPP when an ope= ration >> is not supported. Kernel 6.6.21 predates this fix, which is why you see = -NOTSUPP >> on your platform with Intel Raptor Lake.=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 >>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >> This changes the picture. The -ENOTSUPP Zailiang observed is coming dire= ctly >> 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 ha= ve been >> backported to all stable trees.=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 >>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=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= receive >> cff49d58f57e as a backport.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 >>=20 > > I advise against this, otherwise we'll carry dead weight on our shoulders. +1 There is little sense in carrying a fix for a bug we don't have. > >> That said, I am happy to follow your guidance on how to proceed.=C2=A0 > > I would backport the patch to the stable kernel if that fixes things for = you. > Then I would follow up with a patch and replace -ENOTSUPP/-EOPNOTSUPP in > spi-mem and spi. +1 here too. You would need to backport a patch to your kernel anyway. Better to backport one that is already upstream and is a more general fix. --=20 Regards, Pratyush Yadav