public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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,
	Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Subject: Re: [PATCH v3 2/2] mtd: spi-nor: Avoid setting SRWD bit in SR if WP# signal not connected
Date: Tue, 27 Jun 2023 08:14:57 +0200	[thread overview]
Message-ID: <5e5fe22aebe17da4f9ad2c4eaaa8985f@walle.cc> (raw)
In-Reply-To: <20230625100251.31589-3-amit.kumar-mahapatra@amd.com>

Am 2023-06-25 12:02, schrieb Amit Kumar Mahapatra:
> Setting the status register write disable (SRWD) bit in the status
> register (SR) with WP# signal of the flash left floating or wrongly 
> tied to
> GND (that includes internal pull-downs), will configure the SR 
> permanently
> as read-only. If WP# signal is left floating or wrongly tied to GND, 
> 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  | 9 +++++++--
>  3 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 0bb0ad14a2fc..520f5ab86d2b 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, "no-wp"))
> +		nor->flags |= SNOR_F_NO_WP;
> +

Please put it below the of_property_read_bool() which is already
there, just to keep things sorted.

>  	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..55b5e7abce6e 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_NO_WP		= BIT(16),

See the comment right above this enum :/

>  };
> 
>  struct spi_nor_read_command {
> diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
> index 0ba716e84377..cfaba41d74d6 100644
> --- a/drivers/mtd/spi-nor/swp.c
> +++ b/drivers/mtd/spi-nor/swp.c
> @@ -214,8 +214,13 @@ 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 neither left floating nor
> +	 * wrongly tied to GND(that includes internal pull-downs).

nit: space missing

Otherwise looks good.

Thanks,
-michael

> +	 * WP# pin hard strapped to GND can be a valid use case.
> +	 */
> +	if (!(nor->flags & SNOR_F_NO_WP))
> +		status_new |= SR_SRWD;
> 
>  	if (!use_top)
>  		status_new |= tb_mask;

  reply	other threads:[~2023-06-27  6:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-25 10:02 [PATCH v3 0/2] mtd: spi-nor: Avoid setting SRWD bit in SR Amit Kumar Mahapatra
2023-06-25 10:02 ` [PATCH v3 1/2] dt-bindings: mtd: jedec, spi-nor: Add DT property to avoid setting SRWD bit in status register Amit Kumar Mahapatra
2023-06-26 17:23   ` Conor Dooley
2023-06-26 17:35   ` Rob Herring
2023-06-27  6:08   ` Michael Walle
2023-06-25 10:02 ` [PATCH v3 2/2] mtd: spi-nor: Avoid setting SRWD bit in SR if WP# signal not connected Amit Kumar Mahapatra
2023-06-27  6:14   ` Michael Walle [this message]
2023-06-30  8:48     ` Tudor Ambarus
2023-06-30 10:59       ` Mahapatra, Amit Kumar

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=5e5fe22aebe17da4f9ad2c4eaaa8985f@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