From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Brian Norris <computersforpeace@gmail.com>
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 v2 7/8] mtd: spi-nor: add TB (Top/Bottom) protect support
Date: Mon, 29 Feb 2016 17:35:02 -0300 [thread overview]
Message-ID: <20160229203502.GA13477@laptop.cereza> (raw)
In-Reply-To: <1454095537-130536-8-git-send-email-computersforpeace@gmail.com>
Hi Brian,
On 29 January 2016 at 16:25, Brian Norris <computersforpeace@gmail.com> wrote:
> Some flash support a bit in the status register that inverts protection
> so that it applies to the bottom of the flash, not the top. This yields
> additions to the protection range table, as noted in the comments.
>
> Because this feature is not universal to all flash that support
> lock/unlock, control it via a new flag.
>
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> ---
> v2:
> * Rewrite the bounds checking for top/bottom support, since there were some
> bad corner cases. Now lock/unlock are more symmetric.
>
> drivers/mtd/spi-nor/spi-nor.c | 70 ++++++++++++++++++++++++++++++++++++++-----
> include/linux/mtd/spi-nor.h | 2 ++
> 2 files changed, 65 insertions(+), 7 deletions(-)
>
[..]
> @@ -476,12 +484,14 @@ static int stm_is_unlocked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
>
> /*
> * Lock a region of the flash. Compatible with ST Micro and similar flash.
> - * Supports only the block protection bits BP{0,1,2} in the status register
> + * Supports the block protection bits BP{0,1,2} in the status register
> * (SR). Does not support these features found in newer SR bitfields:
> - * - TB: top/bottom protect - only handle TB=0 (top protect)
> * - SEC: sector/block protect - only handle SEC=0 (block protect)
While reviewing and testing this patchset, I realised that *no* Micron device
define BIT(6) as SEC (sector/block) bit. Instead, it's used as BP3, to extend
the region defined by BP0-BP2.
I've checked the following:
N25Q256A
N25Q128A
N25Q064A
N25Q032A
N25Q016A
M25Pxx
So I believe we need to separate stm_{lock,unlock), from
winbond_{lock,unlock}. We might want to explicitly mark devices that
currently support locking with the new _HAS_LOCK flag.
Also, I wonder if we can really separate based on vendor, or if we'll need
more flags to distinguish the lock implementation per device.
Of course, all the devices that define a BP3 are broken with respect to flash
locking. I can try to cook some patches for this, once we are decided on how
to do it.
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
next prev parent reply other threads:[~2016-02-29 20:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 19:25 [PATCH v2 0/8] mtd: spi-nor: locking fixes and updates Brian Norris
2016-01-29 19:25 ` [PATCH v2 1/8] mtd: spi-nor: wait for SR_WIP to clear on initial unlock Brian Norris
2016-01-29 19:25 ` [PATCH v2 2/8] mtd: spi-nor: silently drop lock/unlock for already locked/unlocked region Brian Norris
2016-01-29 19:25 ` [PATCH v2 3/8] mtd: spi-nor: make lock/unlock bounds checks more obvious and robust Brian Norris
2016-01-29 19:25 ` [PATCH v2 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low Brian Norris
2016-01-29 19:25 ` [PATCH v2 5/8] mtd: spi-nor: use BIT() for flash_info flags Brian Norris
2016-01-29 19:25 ` [PATCH v2 6/8] mtd: spi-nor: add SPI_NOR_HAS_LOCK flag Brian Norris
2016-02-28 19:23 ` Ezequiel Garcia
2016-01-29 19:25 ` [PATCH v2 7/8] mtd: spi-nor: add TB (Top/Bottom) protect support Brian Norris
2016-02-29 20:35 ` Ezequiel Garcia [this message]
2016-03-08 2:12 ` Brian Norris
2016-01-29 19:25 ` [PATCH v2 8/8] mtd: spi-nor: support lock/unlock for a few Winbond chips Brian Norris
2016-02-27 2:04 ` [PATCH v2 0/8] mtd: spi-nor: locking fixes and updates Ezequiel Garcia
2016-03-08 2:18 ` Brian Norris
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=20160229203502.GA13477@laptop.cereza \
--to=ezequiel@vanguardiasur.com.ar \
--cc=bayi.cheng@mediatek.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=djkurtz@chromium.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox