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

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

[Alexander A Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@nokia.com>

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.

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;
 
 		/* Alignment is not mandatory for overlaid regions */
 		if (region->offset & SNOR_OVERLAID_REGION &&
-- 
2.10.2

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

[Alexander A Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@nokia.com>

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.

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;
 
 		/* Alignment is not mandatory for overlaid regions */
 		if (region->offset & SNOR_OVERLAID_REGION &&
-- 
2.10.2


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

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

[Tudor.Ambarus]

On 11/19/21 10:14 AM, Alexander A Sverdlin wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Alexander Sverdlin <alexander.sverdlin@nokia.com>

Hi, nice to hear from you again!

> 
> 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?
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.

Cheers,
ta

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

[Tudor.Ambarus]

On 11/19/21 10:14 AM, Alexander A Sverdlin wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Alexander Sverdlin <alexander.sverdlin@nokia.com>

Hi, nice to hear from you again!

> 
> 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?
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.

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

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

[Alexander Sverdlin]

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.

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

[Alexander Sverdlin]

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.

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

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

[Tudor.Ambarus]

On 12/20/21 11:46 AM, Alexander Sverdlin wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hello Tudor,

Hi!

> 
> 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

Sorry about this, I don't see it in patchwork, it probably has its status changed.
https://patchwork.ozlabs.org/project/linux-mtd/list/?series=&submitter=&state=&q=spi-nor&archive=&delegate=

Next time when you feel a patch is not deserving the attention it needs,
feel free to resend it with "RESEND PATCH" in the commit's subject.

Will you resend it? Do the upper layers complain if you use the best erase sequence?
Have you tried ubifs on top of your ignored patch?

> 
> 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'm not yet convinced that this is the best way to fix it. Should we update
the erase mask to cover this case?

Cheers,
ta
> 
>> 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.
> 

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

[Tudor.Ambarus]

On 12/20/21 11:46 AM, Alexander Sverdlin wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hello Tudor,

Hi!

> 
> 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

Sorry about this, I don't see it in patchwork, it probably has its status changed.
https://patchwork.ozlabs.org/project/linux-mtd/list/?series=&submitter=&state=&q=spi-nor&archive=&delegate=

Next time when you feel a patch is not deserving the attention it needs,
feel free to resend it with "RESEND PATCH" in the commit's subject.

Will you resend it? Do the upper layers complain if you use the best erase sequence?
Have you tried ubifs on top of your ignored patch?

> 
> 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'm not yet convinced that this is the best way to fix it. Should we update
the erase mask to cover this case?

Cheers,
ta
> 
>> 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.
> 

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

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

[Alexander Sverdlin]

Hi!

On 20/12/2021 12:28, Tudor.Ambarus@microchip.com wrote:
>> 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'm not yet convinced that this is the best way to fix it. Should we update
> the erase mask to cover this case?

Well, let's wait until the maintainers form their opinion. I've listed the functions which
zero the size (spi_nor_parse_4bait() or spi_nor_init_non_uniform_erase_map()), there are
already functions which check for zero:
spi_nor_select_uniform_erase()
spi_nor_select_erase()

-- 
Best regards,
Alexander Sverdlin.

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

[Alexander Sverdlin]

Hi!

On 20/12/2021 12:28, Tudor.Ambarus@microchip.com wrote:
>> 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'm not yet convinced that this is the best way to fix it. Should we update
> the erase mask to cover this case?

Well, let's wait until the maintainers form their opinion. I've listed the functions which
zero the size (spi_nor_parse_4bait() or spi_nor_init_non_uniform_erase_map()), there are
already functions which check for zero:
spi_nor_select_uniform_erase()
spi_nor_select_erase()

-- 
Best regards,
Alexander Sverdlin.

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

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

[Tudor Ambarus]

On Fri, 19 Nov 2021 09:14:12 +0100, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
> 
> 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.
> 
> [...]

Applied to spi-nor/next, thanks!

[1/1] mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase_type()
      https://git.kernel.org/mtd/c/2ebc336be081

Best regards,
-- 
Tudor Ambarus <tudor.ambarus@microchip.com>

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

[Tudor Ambarus]

On Fri, 19 Nov 2021 09:14:12 +0100, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
> 
> 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.
> 
> [...]

Applied to spi-nor/next, thanks!

[1/1] mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase_type()
      https://git.kernel.org/mtd/c/2ebc336be081

Best regards,
-- 
Tudor Ambarus <tudor.ambarus@microchip.com>

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