Re: [PATCH 1/3] mtd: spi-nor: reimplement block protection handling

[Jungseung Lee <js07.lee@xxxxxxxxx>]

Hi, Tudor,

On Sat, Mar 14, 2020 at 12:22 AM <Tudor.Ambarus@xxxxxxxxxxxxx> wrote:
>
> Hi, Jungseung,
>
> I'm going to respin your patches on top on the what will be the manufacturer
> move v2 series, https://patchwork.ozlabs.org/cover/1247794/, I want both
> included for next.
>
> On Wednesday, March 4, 2020 1:07:58 PM EET Jungseung Lee wrote:
> > The current mainline locking was restricted and could only be applied
> > to flashes that has 3 block protection bit and fixed locking ratio.
> >
> > A new method of normalization was reached at the end of the discussion [1].
> >
> >     (1) - if bp slot is insufficient.
> >     (2) - if bp slot is sufficient.
> >
> >     if (bp_slots_needed > bp_slots)    // (1)
> >         min_prot_length = sector_size << (bp_slots_needed - bp_slots);
> >     else                               // (2)
> >         min_prot_length = sector_size;
> >
> > This patch changes block protection handling logic based on min_prot_length.
> > It is suitable for the overall flashes with exception of some corner case
>
> What corner case, do you refer to EON? Are you aware of other corner cases? We
> should be more precise, for easier review and understanding.
>

Yes, that is eon. eon is the only corner case I've ever seen in 3 bit
and 4 bit block protection.

In 2 bit block protection case, a significant number of flash fully
use available bp_slots (2 bit = 4) regardless of the above rule.
That is the case with microchip, catalyst and more..

Of course, none of the 2 bit block protection flash has been set to
lockable so far.

Thanks,

> Cheers,
> ta
>
> > and easy to extend and apply for the case of 2bit or 4bit block protection.
> >
> > [1] http://lists.infradead.org/pipermail/linux-mtd/2020-February/093934.html
>
>
>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/