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 11:27:26 +0000 [thread overview]
Message-ID: <4425106.vomQgZVa01@localhost.localdomain> (raw)
In-Reply-To: <d7311f0ea1d0142a9523548bb3562f1a@walle.cc>
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.
Cheers,
ta
>
> >> This case is addressed by using bp_slot_count and bp_slots_available.
> >> We're
> >> in the else case from above. From bp_slot_count up to the
> >> bp_slots_available, those slots are "protect all".
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-02-10 11:27 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 [this message]
2020-02-10 12:14 ` Michael Walle
2020-02-10 15:50 ` Tudor.Ambarus
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=4425106.vomQgZVa01@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