From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f47.google.com (mail-yx1-f47.google.com [74.125.224.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FDDF353A8F for ; Thu, 6 Aug 2026 11:24:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786015469; cv=none; b=pJFi1wiro+hpIGqC5P4AHaP382S/ZaUaKGJ7waN0/tOLjQZRcEt1bNsk5mX/PU071gKABaONnZmDe/CYPeebwo00mqNP9MpqeNI8EcBXP8FSQ1WcSgq7auF5tpA3LRv8i5QNCPbn3XHko2f5p4r5BmYV5yIPy4MKxdpntqlCIuU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786015469; c=relaxed/simple; bh=4u1+eG5V9t+0UY5zkWvrVqkWOTAnoaGQ1MVIA9WJTHM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References; b=sWZCtuE06NRDUKKTxFPZN4K4HflAQm2ncdHmt9tK+tYlqG6DrU17OipuZ3gLOGfRPHDx5Os8l5gR9/2KHWKouk8f4xxpWFmay7CstMg1hcNBr165hUEKtHzVUu78I9SL5ZLvQ4KZJhaksEiclyNqWHAtcPZoNqeeexjQw44kKWs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PkMbN9lF; arc=none smtp.client-ip=74.125.224.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PkMbN9lF" Received: by mail-yx1-f47.google.com with SMTP id 956f58d0204a3-669944f5ef1so2339851d50.1 for ; Thu, 06 Aug 2026 04:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786015466; x=1786620266; darn=vger.kernel.org; h=references:in-reply-to:message-id:date:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=htlXA2vE3OGvFfG4HYdtHC6yn1LF5Ww06gH8IET7fdM=; b=PkMbN9lFOT/nwYtz8oQlWRr0c2AO+YWqX/ratFaCeYJAUJRnw8ITVk0vkVf+fORnqo V5+toLd41uL2tI4tr1fNztm7jr2LGOiQKZKbsp2p7E5jvHmaRx6G0MFaKThqnyBGTvX4 31FWbqWm3sYw/Nm7EM8+uVYkgz8b3hGnxKS9QVjznBkuG9fhUS9rjE2rR6RraT3dcy3F E5Ol9lGYp/v1Fj7TLxRtYQ8hhT17eC0dJ7ATYzEntqt/lHllovV6JPltnFcQT5boKmbF CUCtUbk8XM6MzXHm3epOThHkld+sMxIt+4zyGM/WYbKDoNkABBabFUVluXEgXGde2F0Q lpPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786015466; x=1786620266; h=references:in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=htlXA2vE3OGvFfG4HYdtHC6yn1LF5Ww06gH8IET7fdM=; b=srgeIsqJfZHGuuWNmuDV7vSmQQyJJNPIBzlikU1oxxzBDz4o4ATB2cw/LtLzSVgrHp TQ2cL82Aoo12KqGzkzTpTaSrvRd+VZepVVQQYlohMF5sytCLKag1hKpEZh3aqmhg5Jmn KdBqNSD7iX0B9LISmQa4euByiW6Nap1Avdl4d3VsVxXiCvPqBvfRFntO48zgb3SBOc4T TAb7ztYCNZpWbDazaHEBixjJ1MDaw/FepiJ+ZGmZ1jbw6Zc0vtqaMpsoDvSHJ83yOtzj V8QbNwJHFNJ6fCcGOPcT4wmNH9KAIWJCFvlYTyFnuWwUaBUF6XjfGqWuCXTDrbRvUDIa dVtA== X-Forwarded-Encrypted: i=1; AHgh+RrEKFQP7LvzNPUEbxPhNuogX+Dw26rl/WdBZc5sh4+bFBMpqSikT1HfVFwh6xHytozcka1MV1/1iE6Gk1U=@vger.kernel.org X-Gm-Message-State: AOJu0Yxnl8qN9C0NbSXcpsECit4k08pQxMemk7i5oLVFUlsbwjKnqpwT pqIVQfj4mDvXmT1DQawjBsuK+oGpvAuRj+a31HakcmfnWz00ln+cXSTT X-Gm-Gg: AR+sD12q/3rYFR89eBDOn4Cip1SBx1M0pqRO9kxwzIPx7q6wHrciTakoeW/h4IupMN7 06zfXLYJ7iSKRvUVTsyZXMDCi8XZh1O2R5paZeBBC16LVpRGeh3wetYxo5nRk9G6yU12+U71BsN DnXsrcbjmca/zPRqZ7Cuy1RCv9PL5R5TZBwwwRen3UYInMJ6nxt5M/hm9Ao4G7e/R7awcbBGbzg dAsqdQPA9r4dX2mavy/2OVz4mkF4TbM8w4XpoPYd9SlzbhdX4VwyL09BfSBEw1Vi89WYPeuyOmT Eo9XS6SKRgrqMVLmoMJy7gzsctM1wA3qTcTc/Nw3kSVf6NP1jfTK9+GC8s7yTIrRCvTx9CnanOG WBaagMMo9DOQcbKX0D2sfc9rBNXDDtqo+n7+31K0mCFvH0X/U1CZ4paxZPmvgDap/gXG3RlBVBZ 1nDFieU1JGT72UDivG4vZJ+dWnV6pGruTRQ5gQ/htY3vLHQXilaEvNj00Cz7V4zbncnw== X-Received: by 2002:a05:690c:6d8e:b0:81f:2479:16da with SMTP id 00721157ae682-8202232ce68mr90001897b3.16.1786015466392; Thu, 06 Aug 2026 04:24:26 -0700 (PDT) Received: from SC-GAME.lan ([104.28.245.40]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8210fa3fe27sm16628097b3.37.2026.08.06.04.24.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 04:24:25 -0700 (PDT) From: Chen Minqiang To: Pratyush Yadav , Michael Walle , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra Cc: Takahiro Kuwano , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: spi-nor: allow force unlocking via DT property Date: Thu, 6 Aug 2026 19:24:18 +0800 Message-Id: <20260806112418.14695-1-ptpt52@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <2026-08-05171214.2934-1-ptpt52@gmail.com> References: <2026-08-05171214.2934-1-ptpt52@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 SR2, spi_nor_unlock() won't clear those extra bits without the corresponding flags (SNOR_F_HAS_4BIT_BP / SNOR_F_HAS_SR2_CMP_BIT6) set by the ID database or SFDP. 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 standard 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 time if CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE is set (for non-volatile chips) or if SNOR_F_HAS_LOCK is not set in chip flags. As a result, status registers locked by factory bootloaders are never cleared. `linux,force-sr-unlock` serves as a pragmatic DT override to force the unlock 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 DT 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 when 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 BP0-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 on your guidance. Best regards, Chen Minqiang