devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vignesh Raghavendra <vigneshr@ti.com>
To: Michael Walle <michael@walle.cc>, <linux-mtd@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>
Subject: Re: [PATCH 1/2] dt-bindings: mtd: spi-nor: document new flag
Date: Mon, 16 Dec 2019 14:24:15 +0530	[thread overview]
Message-ID: <556fe468-0080-ad05-8228-5ff8f1b3dac6@ti.com> (raw)
In-Reply-To: <20191214191943.3679-1-michael@walle.cc>

Hi,

On 15/12/19 12:49 am, Michael Walle wrote:
> Document the new flag "no-unlock".
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> Does the property need a prefix? I couldn't find any hint. If so, what
> should it be? "m25p," or "spi-nor," ?
> 
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> index f03be904d3c2..2d305c893ed7 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> @@ -78,6 +78,12 @@ Optional properties:
>  		   cannot reboot properly if the flash is left in the "wrong"
>  		   state. This boolean flag can be used on such systems, to
>  		   denote the absence of a reliable reset mechanism.
> +- no-unlock : By default, linux unlocks the whole flash because there
> +		   are legacy flash devices which are locked by default
> +		   after reset. Set this flag if you don't want linux to
> +		   unlock the whole flash automatically. In this case you
> +		   can control the non-volatile bits by the
> +		   flash_lock/flash_unlock tools.
>  

Current SPI NOR framework unconditionally unlocks entire flash which
I agree is not the best thing to do, but I don't think we need
new DT property here. MTD cmdline partitions and DT partitions already 
provide a way to specify that a partition should remain locked[1][2]

SPI NOR framework should instead set MTD_POWERUP_LOCK flags in mtd->flags
for flash devices that power up with lock bits set. And MTD core will 
take care of unlocking flash regions while taking into account partition
flags defined by user as part of MTD partitions defined in DT or
via cmdline args.

So that change should to be set MTD_POWERUP_LOCK for
in SPI NOR core. Can you check below[3] (untested) diff helps?
This should prevent unlocking partitions that are to remain locked 
as specified in DT/cmdline 

[1] Documentation/devicetree/bindings/mtd/partition.txt
[2] drivers/mtd/parsers/cmdlinepart.c (see "lk" parameter)

[3]

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 1082b6bb1393..6adb950849f6 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4914,23 +4914,6 @@ static int spi_nor_quad_enable(struct spi_nor *nor)
 	return nor->params.quad_enable(nor);
 }
 
-/**
- * spi_nor_unlock_all() - Unlocks the entire flash memory array.
- * @nor:	pointer to a 'struct spi_nor'.
- *
- * Some SPI NOR flashes are write protected by default after a power-on reset
- * cycle, in order to avoid inadvertent writes during power-up. Backward
- * compatibility imposes to unlock the entire flash memory array at power-up
- * by default.
- */
-static int spi_nor_unlock_all(struct spi_nor *nor)
-{
-	if (nor->flags & SNOR_F_HAS_LOCK)
-		return spi_nor_unlock(&nor->mtd, 0, nor->params.size);
-
-	return 0;
-}
-
 static int spi_nor_init(struct spi_nor *nor)
 {
 	int err;
@@ -4941,11 +4924,11 @@ static int spi_nor_init(struct spi_nor *nor)
 		return err;
 	}
 
-	err = spi_nor_unlock_all(nor);
-	if (err) {
-		dev_dbg(nor->dev, "Failed to unlock the entire flash memory array\n");
-		return err;
-	}
+	/*
+	 * Flashes may power up locked. Set this flag so that MTD core
+	 * takes care of unlocking partitions as required.
+	 */
+	nor->mtd.flags |= MTD_POWERUP_LOCK;
 
 	if (nor->addr_width == 4 && !(nor->flags & SNOR_F_4B_OPCODES)) {
 		/*




-- 
Regards
Vignesh

  parent reply	other threads:[~2019-12-16  8:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-14 19:19 [PATCH 1/2] dt-bindings: mtd: spi-nor: document new flag Michael Walle
2019-12-14 19:19 ` [PATCH 2/2] mtd: spi-nor: add option to keep lock bits Michael Walle
2019-12-16  8:54 ` Vignesh Raghavendra [this message]
2019-12-16 10:29   ` [PATCH 1/2] dt-bindings: mtd: spi-nor: document new flag Michael Walle
2019-12-19  5:33     ` Vignesh Raghavendra
2019-12-20 12:46       ` Michael Walle

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=556fe468-0080-ad05-8228-5ff8f1b3dac6@ti.com \
    --to=vigneshr@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=tudor.ambarus@microchip.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;
as well as URLs for NNTP newsgroup(s).