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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?


> 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
32Mbit flash where 2MB are locked and the second 2MB are unlocked. Eg. a
50/50 split. I haven't seen any issued. Shouldn't it be then completely
locked according this the following example?

>
> Number of blocks | BP2:0 before | BP2:0 now |
>
>                1 | 010b         | 001b      |
>                2 | 110b         | 010b      |
>                3 | 110b         | 010b      |
>                4 | 100b         | 011b      |
>                5 | 100b         | 011b      |
>                6 | 100b         | 011b      |
>                7 | 100b         | 011b      |
>                8 | 101b         | 100b      |
>                9 | 101b         | 100b      |
>
>              ... | ...          | ...       |
>
> For the lock operation, if one requests to lock an area that is not
> matching the upper boundary of a BP protected area, we round down
> the total length and lock less than the user requested, in order to
> not lock more than the user actually requested.

I don't know if that is really what a user really want. Because you'd
end up with regions which the user believes are locked but are not.

True. I'm thinking of how we can improve this, but it's not in the scope of
this patch set, because the behavior is not changed.

ok, agreed,


IMHO if you'd have to make a choice I'd prefer to have the remainder
locked. Not the other way around. Esp. since the user explicitly
express to have a region locked.


We can still talk about this. Please notice that the formula that we want to
introduce does the same thing as described in this commit message: for
unaligned locks, it round down the length, and for unaligned unlocks it rounds
up the length.

ok

-michael


I'm waiting for a reply.
ta

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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux