Re: [PATCH v3 2/3] mtd: spi-nor: add 4bit block protection support

[<Tudor.Ambarus@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx:
> > 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/