From: Michael Walle <michael@walle.cc>
To: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
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
Date: Thu, 15 Jun 2023 14:18:59 +0200 [thread overview]
Message-ID: <fe5ebc619350c378a14e88275e5dab3b@walle.cc> (raw)
In-Reply-To: <20230615111649.36344-3-amit.kumar-mahapatra@amd.com>
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 <amit.kumar-mahapatra@amd.com>
> ---
> 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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2023-06-15 12:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 11:16 [PATCH 0/2] mtd: spi-nor: Avoid setting SRWD bit in SR Amit Kumar Mahapatra
2023-06-15 11:16 ` [PATCH 1/2] dt-bindings: mtd: jedec, spi-nor: Add DT property to avoid setting SRWD bit in status register Amit Kumar Mahapatra
2023-06-15 12:08 ` Michael Walle
2023-06-15 19:13 ` Conor Dooley
2023-06-15 11:16 ` [PATCH 2/2] mtd: spi-nor: Avoid setting SRWD bit in SR if WP signal not connected Amit Kumar Mahapatra
2023-06-15 12:18 ` Michael Walle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fe5ebc619350c378a14e88275e5dab3b@walle.cc \
--to=michael@walle.cc \
--cc=amit.kumar-mahapatra@amd.com \
--cc=amitrkcian2002@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=git@amd.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox