Re: [PATCH v2] mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase_type()

[Alexander Sverdlin <alexander.sverdlin@nokia.com>]

Hello Tudor,

On 18/12/2021 02:31, Tudor.Ambarus@microchip.com wrote:
>> Erase can be zeroed in spi_nor_parse_4bait() or
>> spi_nor_init_non_uniform_erase_map(). In practice it happened with
>> mt25qu256a, which supports 4K, 32K, 64K erases with 3b address commands,
>> but only 4K and 64K erase with 4b address commands.
> 
> :D
> 
>>
>> Fixes: dc92843159a7 ("mtd: spi-nor: fix erase_type array to indicate current map conf")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
>> ---
>> Changes in v2:
>> erase->opcode -> erase->size
>>
>>  drivers/mtd/spi-nor/core.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 88dd090..183ea9d 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -1400,6 +1400,8 @@ spi_nor_find_best_erase_type(const struct spi_nor_erase_map *map,
>>                         continue;
>>
>>                 erase = &map->erase_type[i];
>> +               if (!erase->size)
>> +                       continue;
> 
> I need a bit of context here. Does mt25qu256a has a uniform erase layout?

You caught me, the bug will not be visible with this flash type without the patch
which has been ignored for long time:
https://www.spinics.net/lists/linux-mtd/msg11510.html

I however run the above patch because of the reasons described in the commit message.
Nevertheless, the bug fixed now remains a bug no matter what triggers it.

> i.e. Does your flash has sectors of more than one size or does not allow
> the 4K and 64K erase types to be applied on all sectors in the 4B case?
> If no, you should have been in the spi_nor_has_uniform_erase() case, and
> if this case does not suit you, maybe we should update the code for this
> specific case instead.
> 
> On a short look I see that this flash defines just BFPT and 4BAIT table,
> so no SMPT. It looks like you're forcing the flash to behave as it had defined
> SMPT. Am I wrong?
> 
> Also, should we update the region's erase mask instead and mask out the
> unsupported erase type? I would love to hear more about your use case.

-- 
Best regards,
Alexander Sverdlin.