Re: [PATCH v3 1/5] mtd: spi-nor: Fix gap in SR block protection locking

[<Tudor.Ambarus@xxxxxxxxxxxxx>]

On Tuesday, March 24, 2020 12:35:30 AM EET Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> Am 2020-03-23 22:30, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> > On Monday, March 23, 2020 11:14:05 PM EET Michael Walle wrote:
> >> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> >> the
> >> content is safe
> >> 
> >> Am 2020-03-23 21:26, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> >> > On Monday, March 23, 2020 9:54:38 PM EET Michael Walle wrote:
> >> >> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> >> >> the
> >> >> content is safe
> >> >> 
> >> >> Am 2020-03-23 20:20, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> >> >> > On Monday, March 23, 2020 8:27:13 PM EET Michael Walle wrote:
> >> >> >> EXTERNAL EMAIL: Do not click links or open attachments unless you
> >> >> >> know
> >> >> >> the
> >> >> >> content is safe
> >> >> >> 
> >> >> >> Hi,
> >> >> >> 
> >> >> >> Am 2020-03-23 10:24, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> >> >> >> > From: Tudor Ambarus <tudor.ambarus@xxxxxxxxxxxxx>
> >> >> >> > 
> >> >> >> > Fix the gap for the SR block protection, the BP bits were set
> >> >> >> > with
> >> >> >> > a +1 value than actually needed. This patch does not change the
> >> >> >> > behavior of the locking operations, just fixes the protected
> >> >> >> > areas.
> >> >> >> 
> >> >> >> So instead of rounding up, it does round down now?
> >> >> > 
> >> >> > No. Why do you say that it rounds up? The behavior is not changed,
> >> >> > the
> >> >> > patch
> >> >> > merely fix the protected area, which was wrong before. The round
> >> >> > down
> >> >> > is
> >> >> > present before this patch.
> >> >> 
> >> >> TBH I don't understand what this patch should do. Could you give an
> >> >> example?
> >> > 
> >> > sure, let me try to be more explicit.
> >> > 
> >> >> >> > On a 16Mbit flash with 64KByte erase sector, the following
> >> >> >> > changed
> >> >> 
> >> >> >> > for the lock operation:
> >> >> 16MBit is a bad example, because it is broken anyway, isn't it? We use
> >> >> a
> >> > 
> >> > it's not.
> >> 
> >> If I'm not mistaken this falls into the same category like the new
> >> 4bits
> >> BP
> >> flashes, because there are more slots free than needed. Ie. the last
> >> one
> >> "protect all" is either 110b or 111b and thus don't work with the old
> >> formula. This was actually my reason why there is no new formula for
> >> the
> >> 4 bits BP flashes; but the current one is not working with flashes
> >> <32Mbit.
> >> See the old long thread.

You're right, I was trying to fix a dead horse. 16Mbit BP0:2 flashes are fixed 
with the generic formula. I'm going to respin without this patch.

Thanks!


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