From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>
Cc: js07.lee@gmail.com, linux-mtd@lists.infradead.org,
vigneshr@ti.com, js07.lee@samsung.com
Subject: Re: [PATCH v3 2/3] mtd: spi-nor: add 4bit block protection support
Date: Mon, 10 Feb 2020 15:50:27 +0000 [thread overview]
Message-ID: <2666242.fqR9HCI5eq@localhost.localdomain> (raw)
In-Reply-To: <3eb14c9f46fde4d232ed5d1c6295ca91@walle.cc>
On Monday, February 10, 2020 2:14:48 PM EET Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> Am 2020-02-10 12:27, schrieb Tudor.Ambarus@microchip.com:
> > On Monday, February 10, 2020 12:40:59 PM EET Michael Walle wrote:
> >> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> >> the
> >> content is safe
> >>
> >> Am 2020-02-10 10:59, schrieb Tudor.Ambarus@microchip.com:
> >> > On Monday, February 10, 2020 11:47:23 AM EET Tudor Ambarus wrote:
> >> >> > btw. we should catch the two special cases:
> >> >> > - lock none -> 0 (that was already the case)
> >> >> > - lock all -> all BP bits
> >> >> >
> >> >> > The latter is important if "bp_slots_needed < bp_slots_available"
> >> >> > because there
> >> >> > are multiple settings for protect all. Most flashes will define any
> >> >> > remaining
> >> >> > setting for "protect all", but I've also seen flashes where the
> >> >> > in-between ones
> >> >> > were undefined (not mentioned) and only the "all bit set" was
> >> >> > protect
> >> >> > all.
> >> >
> >> > I re-read this. Do you have such an example of flash? Aren't the BP
> >> > bits in
> >> > this case marked with "X", i.e. don't care? If not, probably we can
> >> > mask out
> >> > those undefined slots.
> >>
> >> There was definetly some datasheet where the remaining ones wasn't
> >> described
> >> _and_ there was no X (don't care) bits. Unfortunately, I don't find it
> >> right
> >> now. That datasheed made me wonder what the other "undefinded" cases
> >> would be.
> >> Probably it will also be "protect all"; I just mentioned it because it
> >> would
> >> be an easy special case to handle. I don't think we should mask out
> >> anything,
> >> either use the slot in between (ie the one which the formula gives us)
> >> to
> >> protect all or use the largest setting (ie [TB3 |] TB2 | TB1 | TB0).
> >> And
> >> given the reasons above, I'd prefer the latter.
> >
> > I'm fine with using the largest setting, but we'll need the proof
> > before going
> > this way.
>
> have a look at 7.1.11:
> https://www.winbond.com/resource-files/w25q80dv_revg_07212015.pdf
>
> BP[2:0]=0b101 and 0b110 is not defined.
>
Good enough for me. Thanks, Michael!
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-02-10 15:50 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200113055910epcas1p4f97dfeb465b00d66649d6321cffc7b5a@epcas1p4.samsung.com>
2020-01-13 5:59 ` [PATCH v3 1/3] mtd: spi-nor: introduce SR_BP_SHIFT define Jungseung Lee
2020-01-13 5:59 ` [PATCH v3 2/3] mtd: spi-nor: add 4bit block protection support Jungseung Lee
2020-01-14 10:49 ` Tudor.Ambarus
2020-01-17 15:06 ` Jungseung Lee
2020-01-22 11:42 ` Jungseung Lee
2020-01-22 14:31 ` Tudor.Ambarus
2020-01-22 17:14 ` Michael Walle
2020-01-23 3:59 ` Jungseung Lee
2020-01-23 8:15 ` Michael Walle
2020-02-11 7:52 ` chenxiang (M)
2020-03-04 5:20 ` Jungseung Lee
2020-03-04 8:36 ` chenxiang (M)
2020-03-07 7:40 ` Jungseung Lee
2020-01-22 19:36 ` Michael Walle
2020-01-23 6:22 ` Jungseung Lee
2020-01-23 8:10 ` Michael Walle
2020-01-23 8:53 ` Jungseung Lee
2020-01-23 9:31 ` Michael Walle
2020-01-28 11:01 ` Jungseung Lee
2020-01-28 12:29 ` [SPAM] " Michael Walle
2020-01-30 8:17 ` Jungseung Lee
2020-01-30 8:36 ` [SPAM] " Michael Walle
2020-01-30 10:07 ` Jungseung Lee
2020-02-03 13:56 ` Vignesh Raghavendra
2020-02-03 14:38 ` [SPAM] " Michael Walle
2020-02-03 14:58 ` Jungseung Lee
2020-02-03 17:31 ` Vignesh Raghavendra
2020-02-07 12:17 ` Tudor.Ambarus
2020-02-10 8:33 ` Michael Walle
2020-02-10 9:47 ` Tudor.Ambarus
2020-02-10 9:59 ` Tudor.Ambarus
2020-02-10 10:40 ` Michael Walle
2020-02-10 11:27 ` Tudor.Ambarus
2020-02-10 12:14 ` Michael Walle
2020-02-10 15:50 ` Tudor.Ambarus [this message]
2020-02-10 10:29 ` Michael Walle
2020-02-10 11:26 ` Tudor.Ambarus
2020-02-19 10:50 ` Jungseung Lee
2020-02-19 11:08 ` Michael Walle
2020-02-19 11:23 ` Jungseung Lee
2020-02-19 11:36 ` Michael Walle
2020-02-20 19:09 ` Michael Walle
2020-02-21 9:30 ` Tudor.Ambarus
2020-02-25 8:20 ` Tudor.Ambarus
2020-02-25 9:25 ` Jungseung Lee
2020-01-13 5:59 ` [PATCH v3 3/3] mtd: spi-nor: support lock/unlock for a few Micron chips Jungseung Lee
2020-01-13 12:30 ` John Garry
2020-01-13 12:40 ` Jungseung Lee
2020-01-13 12:45 ` Jungseung Lee
2020-01-13 13:00 ` John Garry
2020-02-17 0:18 ` [PATCH v3 1/3] mtd: spi-nor: introduce SR_BP_SHIFT define Tudor.Ambarus
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=2666242.fqR9HCI5eq@localhost.localdomain \
--to=tudor.ambarus@microchip.com \
--cc=js07.lee@gmail.com \
--cc=js07.lee@samsung.com \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--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 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.