Re: [PATCH v3 1/2] mtd: spi-nor: add OTP support

[Michael Walle <michael@walle.cc>]

Am 2021-03-01 18:32, schrieb Michael Walle:
> Am 2021-02-28 13:00, schrieb Tudor.Ambarus@microchip.com:
>> On 2/16/21 6:28 PM, Michael Walle wrote:
>> Does the otp memory organization matter for the end user?
>> Can't we lock/read/write past region size, for example 2 or 3 regions 
>> in a row,
>> depending on length?
> 
> Mhh tough one. I guess the question really is: Do we want
> to remap the 0x1000, 0x2000, 0x3000 offsets?
>  - 0x1000 -> 0
>  - 0x2000 -> 1 * region_size
>  - 0x3000 -> 2 * region_size
> 
> This is just an example, some devices may us other offsets.
> 
> I'd see this as a prerequsite for handling multiple regions
> in one write, because otherwise you'll have to handle the
> holes which makes it impossible I guess. For example what
> would happen with (given an otp size of 0x100):
>  (1) lock(0, 0x100)
>  (2) lock(0x100, 0xf00)
>  (3) lock(0, 0x1000)
> 
> (1) will work, (2) should return -EINVAL; but what will (3)
> return. -EINVAL too, I guess. But then, ops spanning multiple
> regions doesn't make sense at all, because they will always
> return -EINVAL.
> 
> Unfortunately, I don't know how userspace might access it.
> 
> This is how it looks like at the moment:
> 
> # flash_otp_info -u /dev/mtd1
> Number of OTP user blocks on /dev/mtd1: 3
> block  0:  offset = 0x1000  size = 256 bytes  [unlocked]
> block  1:  offset = 0x2000  size = 256 bytes  [unlocked]
> block  2:  offset = 0x3000  size = 256 bytes  [unlocked]

Hm, I just found the following in the mtd-utils [1]:
"offset and size must match on OTP region boundaries".

[1] 
http://git.infradead.org/mtd-utils.git/blob/HEAD:/misc-utils/flash_otp_lock.c#l25

-michael