From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 4DE2A374E5A for ; Mon, 10 Aug 2026 06:30:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786343417; cv=none; b=PgCHKNi/4+yejhh5bnAVSHb/F4QujrsBNAs/5+3jVuKmQkGjglgsX0uMYqy4S+aQMTmkpWCFx/i2PrnVWV/ge2Hhgb3D44PDFJdJcqMngWKE2fjcl7n/spXtuzXwdIJuoimsTWFtAaR7O3IxYE43RDg/eK7mr9738al3B1wDOcY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786343417; c=relaxed/simple; bh=VnI5n9/9FCO3BiP6Y8j7XBxV6Cjsd1/x5doq9DeepRQ=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:From:To: References:In-Reply-To; b=gA3s4yxOhm5M1raG/f4/6E60XnbcDvxyhmNlF4ZRT+TE4Dcw5YqrgVZL8dBmF+xo8jFWPrpU7GHMUmVL5PMANHO++w5JieWQq7r/i2qNcFnZ8Wmg6Ej5rSO0C+TnvjhPwRWtJY4uhGm+Fp+q07A9s9H2wlPDeMrgj8UpBpn1c14= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jSSVEqm3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jSSVEqm3" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id 778541F000E9; Mon, 10 Aug 2026 06:30:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786343415; bh=bMbqWLJ+xQ+0ueSURHl638U6qP2j2ips3hDRe4p2Etw=; h=Date:Subject:Cc:From:To:References:In-Reply-To; b=jSSVEqm3DTTfRBLdBkRpPfj2gkzmu5dPycNv1U4xsmRwep1lnTYAlP86PurPHDTdN YVzzJdAgDQdlktMZIZcNibY7NQBdMBspeYUkNvxAYL1Ru9fRr8QBeT5bJvSxYbiMy4 /bHJmHxgTnscExcb1mW9eJVaQMsdzwH7oPgbrIHNWKnOpBnoohStQ7kImXriBvKur4 +CgNo8cCrol4YgEpFuo9u4XhG1QFNalxckO1xVtAtIogA59jHxqk44BIWRMwc9a/Ta OTlow/ye+m+20rkUwMoWwPoIKYXUeAsI5Awc3k0/zFxIhSonNE4g8KWaW9pA90Nkwa 6zvIi/uPVKaYA== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: multipart/signed; boundary=0a6fe17bf19ad5a12e68b66b0165d1da9fb2afb6bb7e78bdaf4e15f2febd; micalg=pgp-sha384; protocol="application/pgp-signature" Date: Mon, 10 Aug 2026 08:30:11 +0200 Message-Id: Subject: Re: [PATCH] mtd: spi-nor: allow force unlocking via DT property Cc: "Takahiro Kuwano" , , From: "Michael Walle" To: "Chen Minqiang" , "Pratyush Yadav" , "Miquel Raynal" , "Richard Weinberger" , "Vignesh Raghavendra" X-Mailer: aerc 0.20.0 References: <2026-08-05171214.2934-1-ptpt52@gmail.com> <20260806112418.14695-1-ptpt52@gmail.com> In-Reply-To: <20260806112418.14695-1-ptpt52@gmail.com> --0a6fe17bf19ad5a12e68b66b0165d1da9fb2afb6bb7e78bdaf4e15f2febd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Thu Aug 6, 2026 at 1:24 PM CEST, Chen Minqiang wrote: > Hi, > > Thank you for your valuable insight! > > You are completely right that for unlisted/generic chips that feature a 4= -bit > BP layout (BP3 at bit 5 or bit 6) or a CMP (Complement Protect) bit in SR= 2, > spi_nor_unlock() won't clear those extra bits without the corresponding f= lags > (SNOR_F_HAS_4BIT_BP / SNOR_F_HAS_SR2_CMP_BIT6) set by the ID database or = SFDP. Is this AI assisted? > However, in practice: > 1. The vast majority of 3.3V/1.8V generic SPI NOR flashes (e.g. 4MB-16MB = chips > commonly found in vendor devices like Tenda AX12L Pro) use the standar= d > 3-bit BP (BP0-BP2, SR1 bits 2..4). > 2. The current main issue is that even for these standard 3-bit BP chips,= the > kernel currently skips spi_nor_try_unlock_all() completely at boot tim= e if > CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE is set (for non-volatile ch= ips) > or if SNOR_F_HAS_LOCK is not set in chip flags. As a result, status re= gisters > locked by factory bootloaders are never cleared. > > `linux,force-sr-unlock` serves as a pragmatic DT override to force the un= lock > attempt at probe time. > > To address your point regarding 4-bit BP and CMP bits for unlisted chips,= we > have two potential options: > > Option A (Current Best-Effort): > Keep the patch as-is, treating `linux,force-sr-unlock` as a best-effort D= T > trigger to invoke standard spi_nor_unlock(). It successfully unlocks the = vast > majority of standard 3-bit BP generic chips. For rare unlisted chips with= 4-bit > BP or CMP bits, explicit entries can still be added to the ID database wh= en > discovered. > > Option B (Aggressive Force-Clear): > When `linux,force-sr-unlock` is present in DT, enhance spi_nor_try_unlock= _all() > to perform a broader clear operation on SR1 (masking bits 2..6 to clear B= P0-BP3/TB) > and SR2 (clearing CMP bit if SR2 is readable). > > Which approach would you prefer? I'd be happy to revise the patch based o= n your > guidance. This patch won't fly as is. You're missing the dt-bindings patch (which I doubt will be accepted) and I really don't like this approach. First, why would you unlock a flash automatically? I've worked hard, to get rid of that anti-feature. Second, what if you still loose the flash "lottery"? -michael --0a6fe17bf19ad5a12e68b66b0165d1da9fb2afb6bb7e78bdaf4e15f2febd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iKgEABMJADAWIQTIVZIcOo5wfU/AngkSJzzuPgIf+AUCanlv9BIcbXdhbGxlQGtl cm5lbC5vcmcACgkQEic87j4CH/juFQF/dXsh8cSiNnGne85mZGpo+2JHGY8HXFhH uwWOpJgBxTcdNxegYfswC6XtkDhYH81iAX9JH42fJujdSujtuqXdTL48JVlIc7cm jllnaZj/VHKwOJSbycKZZV9Txkm86eAKJIw= =S1Jn -----END PGP SIGNATURE----- --0a6fe17bf19ad5a12e68b66b0165d1da9fb2afb6bb7e78bdaf4e15f2febd--