From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 2B7E532B107 for ; Thu, 6 Aug 2026 07:38:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786001943; cv=none; b=Ru84eOhp5ihwHjqKG/nXTvhD91UXUFn0lv8sDp3q03K2+JePsWgUeSQdw1zI2bTsVf9YPlOwX0pjLg8ypienDuD9LjhT2N808grFsUgiwclH3Ik4F/FBfuV8i3s4Fy2Mcsm3A0zFyHu/QN//nAAQYOa4mLCQIJ6pjwRGUxfz4uA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786001943; c=relaxed/simple; bh=QIpNJGDYu2wZCVnPTESRZf6oFiqJiFOUQMFU1NQbBq4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=sREKspld0jenBW/H4nHhmkjUVB+vQpqu7Gzp75dnZ5n8bzRNYGdjDvOP0qdOobi0Oy7hUzP0nMEyWQ6gXVEeCxhk1/Xyi9vA5qzHAcsCetKusqGbnwzjTDM30VK5aRcD+D7PtYnVy0+S4dYxMJjAjh84B3oWTWARlIFpBhd0ijM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=DwL0rzdX; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="DwL0rzdX" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id F1E781A1463; Thu, 6 Aug 2026 07:38:56 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id C23C7602B8; Thu, 6 Aug 2026 07:38:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id D1D0111C35B4E; Thu, 6 Aug 2026 09:38:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1786001936; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=QIpNJGDYu2wZCVnPTESRZf6oFiqJiFOUQMFU1NQbBq4=; b=DwL0rzdXpbyZjZlyFIANEjiJii3OqpE1w9gWtP+xSGzuZf8WBXo8Zf0XKP00Lwu2Lz2Kf2 QakD2hT3EM8vt1EDbbm/OhFIuO/s7p2injKXw96ciew1qKWqHbIUW8eYxkp2IW6dKi/J+8 9XqTlmxKD+O6H2bY3b5eUkn/AUGtcZfzTRK8JSHSrkUB3CaF+aZpVxiEMbRHA6K2kDpnOX EnzPG6+eI4JGvLfUNbvtSjrf14deK0sS3XhlT7haV8UoUIS4oS0pAybe0Arydv52+WYpjp L1reV7b4KyLh6KBsJcjlvTM2sjEOfAR6q7njQqOfagrrqC125aey+i6Vwro/xg== From: Miquel Raynal To: "Michael Walle" Cc: "Pratyush Yadav" , "Takahiro Kuwano" , "Richard Weinberger" , "Vignesh Raghavendra" , "Nicolas Ferre" , "Alexandre Belloni" , "Claudiu Beznea" , "Steam Lin" , "Hsin-Yi Wang" , "Thomas Petazzoni" , , , Subject: Re: [PATCH 1/5] mtd: spi-nor: Refactor Read Status/Write Status support In-Reply-To: <87mrv2exwp.fsf@bootlin.com> (Miquel Raynal's message of "Tue, 04 Aug 2026 16:57:26 +0200") References: <20260529-winbond-v7-1-spi-nor-rv-addition-v1-0-f3ae18502d5a@bootlin.com> <20260529-winbond-v7-1-spi-nor-rv-addition-v1-1-f3ae18502d5a@bootlin.com> <87mrv2exwp.fsf@bootlin.com> User-Agent: mu4e 1.12.12; emacs 30.2 Date: Thu, 06 Aug 2026 09:38:50 +0200 Message-ID: <87se4rem0l.fsf@bootlin.com> 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 X-Last-TLS-Session-Version: TLSv1.3 Hello Michael, >> One thing that comes to mind is hardware write protection. If >> there's nothing before that code which checks it, the verify might >> fail if the hardware write protection is enabled. So we should >> somehow check for that and drop the verify here. > > But how do you think we should handle it? Will the QE bit writing > verification fail if HW WP is enabled? Looking into this further: we shall return an error if the QE bit is not set. It just tells the caller that quad mode cannot be used. Then up to the caller to either hard fail or just degrade into single mode (maybe because of a strapped WP). What we should do is to propose a DT property to flag when WP is strapped in hardware, this would make the content of the status registers immutable and we would just skip the entire write operation in the first place, instead of deliberately trying and get a 100% failure rate. Nevertheless, the changes introduced here are kind of orthogonal and do not alter the current behaviour; we shall however listen if people start complaining about this and perhaps implement the solution proposed above. Thanks! Miqu=C3=A8l