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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox