From: Brian Norris <computersforpeace@gmail.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Boris Brezillon" <boris.brezillon@free-electrons.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Bayi Cheng" <bayi.cheng@mediatek.com>,
"Marek Vasut" <marex@denx.de>,
"Daniel Kurtz" <djkurtz@chromium.org>
Subject: Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low
Date: Thu, 28 Jan 2016 11:48:36 -0800 [thread overview]
Message-ID: <20160128194836.GA63180@google.com> (raw)
In-Reply-To: <CAAEAJfDHRutp1R1nKxih-4CENBsjhmFaaTnqD7S6Vub+pqE05Q@mail.gmail.com>
On Thu, Jan 28, 2016 at 04:24:50PM -0300, Ezequiel Garcia wrote:
> On 28 January 2016 at 14:59, Brian Norris <computersforpeace@gmail.com> wrote:
> > So, maybe we want to clear SR_SRWD only when we unlock the *entire*
> > flash? What do you think?
I'll paste in the relevant datasheet details from w25q32fw, to make sure
we're on the same page here, noting that 'SRP0' is our 'SR_SRWD', and
we're not touching SRP1 (i.e., SRP1=0):
"SRP1=0, SRP0=0, /WP=X: Software Protection
/WP pin has no control. The Status register can be written to after
a Write Enable instruction, WEL=1. [Factory Default]
SRP1=0, SRP0=1, /WP=0: Hardware Protected
When /WP pin is low the Status Register locked [sic] and cannot be
written to.
SRP1=0, SRP0=1, /WP=1: Hardware Unprotected
When /WP pin is high the Status register is unlocked and can be
written to after a Write Enable instruction, WEL=1."
> How about this:
>
> 1) ioctl(MEMLOCK) the entire flash (SR_SRWD is set)
> 2) ioctl(MEMUNLOCK) partially (SW_SRWD keeps set)
> 3) ioctl(MEMLOCK) the entire flash again
I might be confused; are you making a suggestion of a new behavior, or
are you just trying to clarify my proposal? Because this sounds like it
matches my proposal.
> Not sure this use case make sense,
I suppose it could make sense, if you (e.g.) have some intermediate
steps toward determining the locked regions during factory programming.
Maybe a process would start by doing #1 and #2, then decide
conditionally whether to do #3. And only after the whole process is done
does something assert /WP=0 (in my case, a factory process would tie /WP
low).
> but would (3) be allowed given
> SW_SRWD is set?
Yes, if /WP=1 (high).
Brian
next prev parent reply other threads:[~2016-01-28 19:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 5:51 [PATCH 0/8] mtd: spi-nor: locking fixes and updates Brian Norris
2016-01-28 5:51 ` [PATCH 1/8] mtd: spi-nor: wait for SR_WIP to clear on initial unlock Brian Norris
2016-01-28 5:51 ` [PATCH 2/8] mtd: spi-nor: guard against underflows in stm_is_locked_sr Brian Norris
2016-01-28 5:51 ` [PATCH 3/8] mtd: spi-nor: silently drop lock/unlock for already locked/unlocked region Brian Norris
2016-01-28 5:51 ` [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low Brian Norris
2016-01-28 14:36 ` Ezequiel Garcia
2016-01-28 17:59 ` Brian Norris
2016-01-28 19:24 ` Ezequiel Garcia
2016-01-28 19:48 ` Brian Norris [this message]
2016-01-29 13:22 ` Ezequiel Garcia
2016-01-29 19:23 ` Brian Norris
2016-01-28 5:51 ` [PATCH 5/8] mtd: spi-nor: use BIT() for flash_info flags Brian Norris
2016-01-28 5:51 ` [PATCH 6/8] mtd: spi-nor: add SPI_NOR_HAS_LOCK flag Brian Norris
2016-01-28 5:51 ` [RFC PATCH 7/8] mtd: spi-nor: add TB (Top/Bottom) protect support Brian Norris
2016-01-29 2:36 ` Brian Norris
2016-01-28 5:51 ` [PATCH 8/8] mtd: spi-nor: support lock/unlock for a few Winbond chips Brian Norris
2016-01-28 14:42 ` [PATCH 0/8] mtd: spi-nor: locking fixes and updates Ezequiel Garcia
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=20160128194836.GA63180@google.com \
--to=computersforpeace@gmail.com \
--cc=bayi.cheng@mediatek.com \
--cc=boris.brezillon@free-electrons.com \
--cc=djkurtz@chromium.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=zajec5@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.