Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1050024rwd; Thu, 15 Jun 2023 05:52:17 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7Epy+PTOv1YLL9YPI/4h5Q6PTkUIr9I/8fe8FcbK3grwlYwwtuHHqr2+2yCvYJHcxhhY35 X-Received: by 2002:a05:6a20:1605:b0:10b:f590:5a1f with SMTP id l5-20020a056a20160500b0010bf5905a1fmr4697108pzj.0.1686833537312; Thu, 15 Jun 2023 05:52:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686833537; cv=none; d=google.com; s=arc-20160816; b=Ldkk3sbYXV+it0o3MVdTJ1ElO9iysflc+C1uVc83NZOuGX7K/FeQnWmExmBwz9fNZV 8lflOeYhrXOiBr0aoO+keKiSXKGs/WTyFUGAF08qlrvHEsT54d8IkfaF+NYDSzhQ7wNx vAs5+8HtQKejzqBUAjQMNIEGrRwXGUsf4fFTbJKVBBsm1VClLsdrbDhquBn0Unn6zyr/ sjqVlX9sm94VmkGELRDXVbZ6SHyOM3z0wL90K8rnOhuRLM9s3QWARp+KKTaBlmq/49wx 6cPsrIHU9NTmUxME2OjVPWV/3h6Jv4ksZzn88obnMNctb0rBAUBVd5d0a09niEuPSvX3 zh8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version :dkim-signature; bh=/Caj3WcHVhXv2orGAS3eW5p0U6TifL7MgYmHT2thsXY=; b=sQPLObfknJJEzWiMl7d0VbTntO6IGec+w9Td+vqz313Rg7/ap1WDwHvdfvMWGCrLbE eqilOd1OJgccz7JszfeSyly4k7F2SLUj5dTNnXUJYjtQDDrTT6otxvvpFnMNSKYTRa/G sl75OuLo+cLbrV6jO9gju5riEoc8+y2AbLPOG3G4znGwQ0uBP3BFDK91Z48ThUlgJ4HT 1nyutexmxcEWJZUBNS+YtEFGBjCtDAmuPmu3qPBf48iNVy5y2O8n2NqPlNuTMSmCDlV9 s1sSFzDb5CKxeuiWP3A00jSOEGqtBo48SqQZVJAf0q22qXrpzJU/tc7Yzz4ECYm5vLjE 09tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2022082101 header.b=zeqVvJFr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=walle.cc Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q7-20020a170902dac700b001a1ee8ceedcsi13801619plx.495.2023.06.15.05.52.02; Thu, 15 Jun 2023 05:52:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2022082101 header.b=zeqVvJFr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=walle.cc Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344037AbjFOMVe (ORCPT + 99 others); Thu, 15 Jun 2023 08:21:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343949AbjFOMVN (ORCPT ); Thu, 15 Jun 2023 08:21:13 -0400 X-Greylist: delayed 635 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 15 Jun 2023 05:19:26 PDT Received: from mail.3ffe.de (0001.3ffe.de [159.69.201.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 477253580; Thu, 15 Jun 2023 05:19:26 -0700 (PDT) Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id AD4479F4; Thu, 15 Jun 2023 14:18:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1686831539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Caj3WcHVhXv2orGAS3eW5p0U6TifL7MgYmHT2thsXY=; b=zeqVvJFr2EAj1fuB6oUIj/6PEbDQDew4ofZWxW4UM3mB8WsZlzMAr4y55a3nE8GYqd9c0Y Lft6AlIGpRxl+Oio0ZWRV951mmWmXdzuRYz1SbnT7Ws+k1te97Bna5/TI4oBCVGPsyvfqN OGXn34D27nvQ1gvvQwkuwItw52UYLro8d4oEhzkrkDQK+zvHz6lKsLrglo745Xbo5fwuVO Kth6/H8GjAMdoltgrkr9IOXrgZVkGwNB5McisG5eATfUi5OJEsqbKyURLmobLMoJV6yZLH Kr1bh2UDOwElBSnvFM+hPAIIxWTUCQW5h2JTHta2T7zu5ET2JZcKvhwWSoNKhA== MIME-Version: 1.0 Date: Thu, 15 Jun 2023 14:18:59 +0200 From: Michael Walle To: Amit Kumar Mahapatra Cc: tudor.ambarus@linaro.org, pratyush@kernel.org, miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, git@amd.com, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, amitrkcian2002@gmail.com Subject: Re: [PATCH 2/2] mtd: spi-nor: Avoid setting SRWD bit in SR if WP signal not connected In-Reply-To: <20230615111649.36344-3-amit.kumar-mahapatra@amd.com> References: <20230615111649.36344-1-amit.kumar-mahapatra@amd.com> <20230615111649.36344-3-amit.kumar-mahapatra@amd.com> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: michael@walle.cc Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2023-06-15 13:16, schrieb Amit Kumar Mahapatra: > Setting the status register write disable (SRWD) bit in the status > register (SR) with WP signal of the flash not connected will configure > the > SR permanently as read-only. If WP signal is not connected, avoid > setting > SRWD bit while writing the SR during flash protection. > > Signed-off-by: Amit Kumar Mahapatra > --- > drivers/mtd/spi-nor/core.c | 3 +++ > drivers/mtd/spi-nor/core.h | 1 + > drivers/mtd/spi-nor/swp.c | 5 +++-- > 3 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index 0bb0ad14a2fc..81b57c51f41c 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -2864,6 +2864,9 @@ static void spi_nor_init_flags(struct spi_nor > *nor) > if (flags & NO_CHIP_ERASE) > nor->flags |= SNOR_F_NO_OP_CHIP_ERASE; > > + if (of_property_read_bool(np, "broken-wp")) > + nor->flags |= SNOR_F_BROKEN_WP; > + > if (flags & SPI_NOR_RWW && nor->info->n_banks > 1 && > !nor->controller_ops) > nor->flags |= SNOR_F_RWW; > diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h > index 4fb5ff09c63a..6ac932eba913 100644 > --- a/drivers/mtd/spi-nor/core.h > +++ b/drivers/mtd/spi-nor/core.h > @@ -132,6 +132,7 @@ enum spi_nor_option_flags { > SNOR_F_SWP_IS_VOLATILE = BIT(13), > SNOR_F_RWW = BIT(14), > SNOR_F_ECC = BIT(15), > + SNOR_F_BROKEN_WP = BIT(16), > }; > > struct spi_nor_read_command { > diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c > index 0ba716e84377..074f3bce2034 100644 > --- a/drivers/mtd/spi-nor/swp.c > +++ b/drivers/mtd/spi-nor/swp.c > @@ -214,8 +214,9 @@ static int spi_nor_sr_lock(struct spi_nor *nor, > loff_t ofs, uint64_t len) > > status_new = (status_old & ~mask & ~tb_mask) | val; > > - /* Disallow further writes if WP pin is asserted */ > - status_new |= SR_SRWD; > + /* Disallow further writes if WP pin is connected */ "is not broken" or similar. Maybe descibe what is broken. Like I said, this might also be a valid use case. Thinking more about this, maybe we should make this configurable. I.e. make it possible to set the locking region without disabling further writes. Although I'm not sure how. Right now, we always enable both the software and hardware write protection. (winbond distiguish between software and hardware write protection here; software here means not linux/kernel but just setting the protection bits without the locking bit). And in the case WP# is tied to low, one should not use the hardware write protection. Although I'm not really sure, how to do that in a backwards compatible way. -michael