[PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Pratyush Yadav]

Hi,

The Cypress Semper S28 flash family uses 2-bit ECC by default. Under
this ECC scheme, multi-pass page programs result in a program error.
This means that unlike many other SPI NOR flashes, bit-walking cannot be
done. In other words, once a page is programmed, its bits cannot then be
flipped to 0 without an erase in between.

This causes problems with UBIFS because it uses bit-walking to clear EC
and VID magic numbers from a PEB before issuing an erase to preserve the
file system correctness in case of power cuts.

This series fixes that problem by introducing a flag
MTD_NO_MULTI_PASS_WRITE that tells the file system layer that it can't
do multi-pass writes. It also sets the writesize to the page size for
such flashes to make sure file systems know that they should write the
entire page in one go.

It is based on the xSPI/8D series that adds support for Cypress S28
flash [0]. The patches themselves are independent of that series in the
sense that they don't rely on 8D support. But since S28 flash is not
supported without that series, these patches don't make much sense
without it.

Tested on Cypress S28HS512T and MT35XU512ABA on J7200 and J721E
respectively.

[0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/

Pratyush Yadav (3):
  mtd: abi: Introduce MTD_NO_MULTI_PASS_WRITE
  UBI: Do not zero out EC and VID when multi-pass writes are not
    supported
  mtd: spi-nor: core: Introduce SPI_NOR_NO_MULTI_PASS_PP

 drivers/mtd/spi-nor/core.c     | 5 +++++
 drivers/mtd/spi-nor/core.h     | 6 ++++++
 drivers/mtd/spi-nor/spansion.c | 2 +-
 drivers/mtd/ubi/io.c           | 2 +-
 include/uapi/mtd/mtd-abi.h     | 1 +
 5 files changed, 14 insertions(+), 2 deletions(-)

--
2.28.0


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

[PATCH 1/3] mtd: abi: Introduce MTD_NO_MULTI_PASS_WRITE

[Pratyush Yadav]

Some flashes like the Semper S28 family do not support multi-pass page
programming. Introduce the flag MTD_NO_MULTI_PASS_WRITE to allow telling
upper layers this information so they can issue write commands with this
limitation in mind.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
 include/uapi/mtd/mtd-abi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 65b9db936557..a2cab30adac5 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -105,6 +105,7 @@ struct mtd_write_req {
 #define MTD_NO_ERASE		0x1000	/* No erase necessary */
 #define MTD_POWERUP_LOCK	0x2000	/* Always locked after reset */
 #define MTD_SLC_ON_MLC_EMULATION 0x4000	/* Emulate SLC behavior on MLC NANDs */
+#define MTD_NO_MULTI_PASS_WRITE	0x8000
 
 /* Some common devices / combinations of capabilities */
 #define MTD_CAP_ROM		0
-- 
2.28.0


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

[PATCH 2/3] UBI: Do not zero out EC and VID when multi-pass writes are not supported

[Pratyush Yadav]

For NOR flashes EC and VID are zeroed out before an erase is issued to
make sure UBI does not mistakenly treat the PEB as used and associate it
with an LEB.

But on some flashes, like the Cypress Semper S28 SPI NOR flash family,
multi-pass page programming is not allowed on the default ECC scheme.
This means zeroing out these magic numbers will result in the flash
throwing a page programming error.

Do not zero out EC and VID when multi-pass writes are not supported.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
 drivers/mtd/ubi/io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index 14d890b00d2c..4023fc4886e3 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -535,7 +535,7 @@ int ubi_io_sync_erase(struct ubi_device *ubi, int pnum, int torture)
 		return -EROFS;
 	}
 
-	if (ubi->nor_flash) {
+	if (ubi->nor_flash && !(ubi->mtd->flags & MTD_NO_MULTI_PASS_WRITE)) {
 		err = nor_erase_prepare(ubi, pnum);
 		if (err)
 			return err;
-- 
2.28.0


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

Re: [PATCH 2/3] UBI: Do not zero out EC and VID when multi-pass writes are not supported

[Vignesh Raghavendra]

On 10/12/20 11:34 PM, Pratyush Yadav wrote:
> For NOR flashes EC and VID are zeroed out before an erase is issued to
> make sure UBI does not mistakenly treat the PEB as used and associate it
> with an LEB.
> 
> But on some flashes, like the Cypress Semper S28 SPI NOR flash family,
> multi-pass page programming is not allowed on the default ECC scheme.
> This means zeroing out these magic numbers will result in the flash
> throwing a page programming error.
> 
> Do not zero out EC and VID when multi-pass writes are not supported.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> ---
>  drivers/mtd/ubi/io.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index 14d890b00d2c..4023fc4886e3 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -535,7 +535,7 @@ int ubi_io_sync_erase(struct ubi_device *ubi, int pnum, int torture)
>  		return -EROFS;
>  	}
>  
> -	if (ubi->nor_flash) {
> +	if (ubi->nor_flash && !(ubi->mtd->flags & MTD_NO_MULTI_PASS_WRITE)) {
>  		err = nor_erase_prepare(ubi, pnum);
>  		if (err)
>  			return err;
> 

You may want to get rid of assertion for mtd->writesize != 1 in case of
MTD_NORFLASH.

See drivers/mtd/ubi/build.c::631

        if (ubi->mtd->type == MTD_NORFLASH) {
                ubi_assert(ubi->mtd->writesize == 1);
                ubi->nor_flash = 1;
        }

Regards
Vignesh

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

Re: [PATCH 2/3] UBI: Do not zero out EC and VID when multi-pass writes are not supported

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Vignesh Raghavendra" <vigneshr@ti.com>
>
> You may want to get rid of assertion for mtd->writesize != 1 in case of
> MTD_NORFLASH.

Agreed. I hope nothing else breaks if NOR has suddenly a writesize >= 1.

Thanks,
//richard

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

Re: [PATCH 2/3] UBI: Do not zero out EC and VID when multi-pass writes are not supported

[Pratyush Yadav]

On 03/11/20 12:59PM, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "Vignesh Raghavendra" <vigneshr@ti.com>
> >
> > You may want to get rid of assertion for mtd->writesize != 1 in case of
> > MTD_NORFLASH.
> 
> Agreed. I hope nothing else breaks if NOR has suddenly a writesize >= 1.

Please see my response on the cover letter which explains why I think 
setting mtd->writesize = nor->page_size is wrong.

-- 
Regards,
Pratyush Yadav
Texas Instruments India

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

[PATCH 3/3] mtd: spi-nor: core: Introduce SPI_NOR_NO_MULTI_PASS_PP

[Pratyush Yadav]

The Cypress Semper S28 flash family uses 2-bit ECC by default. Under
this ECC scheme, multi-pass page programs result in a program error.
This means that unlike many other SPI NOR flashes, bit-walking cannot be
done. In other words, once a page is programmed, its bits cannot then be
flipped to 0 without an erase in between.

This causes problems with UBIFS because it uses bit-walking to clear EC
and VID magic numbers from a PEB before issuing an erase to preserve the
file system correctness in case of power cuts.

Use SPI_NOR_NO_MULTI_PASS_PP to set MTD_NO_MULTI_PASS_WRITE, telling
upper layers to avoid multi-pass page programming. In addition, update
mtd->writesize to match the page size to make sure upper layers make the
changes they need in one single go.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
 drivers/mtd/spi-nor/core.c     | 5 +++++
 drivers/mtd/spi-nor/core.h     | 6 ++++++
 drivers/mtd/spi-nor/spansion.c | 2 +-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ff592468cc15..16d4bcfe7b10 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3469,6 +3469,11 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
 	nor->page_size = nor->params->page_size;
 	mtd->writebufsize = nor->page_size;
 
+	if (info->flags & SPI_NOR_NO_MULTI_PASS_PP) {
+		mtd->flags |= MTD_NO_MULTI_PASS_WRITE;
+		mtd->writesize = nor->page_size;
+	}
+
 	if (of_property_read_bool(np, "broken-flash-reset"))
 		nor->flags |= SNOR_F_BROKEN_RESET;
 
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 0a775a7b5606..3394b7474c08 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -329,6 +329,12 @@ struct flash_info {
 						 * available I/O mode via a
 						 * volatile bit.
 						 */
+#define SPI_NOR_NO_MULTI_PASS_PP	BIT(22) /*
+						 * Once a page is programmed it
+						 * cannot be programmed again
+						 * without an erase operation in
+						 * between.
+						 */
 
 	/* Part specific fixup hooks. */
 	const struct spi_nor_fixups *fixups;
diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 2c5c0f69dc5c..72430cd4e6af 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -275,7 +275,7 @@ static const struct flash_info spansion_parts[] = {
 			      SPI_NOR_NO_ERASE) },
 	{ "s28hs512t",   INFO(0x345b1a,      0, 256 * 1024, 256,
 			     SECT_4K | SPI_NOR_OCTAL_DTR_READ |
-			      SPI_NOR_OCTAL_DTR_PP)
+			      SPI_NOR_OCTAL_DTR_PP | SPI_NOR_NO_MULTI_PASS_PP)
 	  .fixups = &s28hs512t_fixups,
 	},
 };
-- 
2.28.0


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

Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Pratyush Yadav]

On 12/10/20 11:34PM, Pratyush Yadav wrote:
> Hi,
> 
> The Cypress Semper S28 flash family uses 2-bit ECC by default. Under
> this ECC scheme, multi-pass page programs result in a program error.
> This means that unlike many other SPI NOR flashes, bit-walking cannot be
> done. In other words, once a page is programmed, its bits cannot then be
> flipped to 0 without an erase in between.
> 
> This causes problems with UBIFS because it uses bit-walking to clear EC
> and VID magic numbers from a PEB before issuing an erase to preserve the
> file system correctness in case of power cuts.
> 
> This series fixes that problem by introducing a flag
> MTD_NO_MULTI_PASS_WRITE that tells the file system layer that it can't
> do multi-pass writes. It also sets the writesize to the page size for
> such flashes to make sure file systems know that they should write the
> entire page in one go.
> 
> It is based on the xSPI/8D series that adds support for Cypress S28
> flash [0]. The patches themselves are independent of that series in the
> sense that they don't rely on 8D support. But since S28 flash is not
> supported without that series, these patches don't make much sense
> without it.
> 
> Tested on Cypress S28HS512T and MT35XU512ABA on J7200 and J721E
> respectively.
> 
> [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/

Ping. Any comments on the series?
 
> Pratyush Yadav (3):
>   mtd: abi: Introduce MTD_NO_MULTI_PASS_WRITE
>   UBI: Do not zero out EC and VID when multi-pass writes are not
>     supported
>   mtd: spi-nor: core: Introduce SPI_NOR_NO_MULTI_PASS_PP
> 
>  drivers/mtd/spi-nor/core.c     | 5 +++++
>  drivers/mtd/spi-nor/core.h     | 6 ++++++
>  drivers/mtd/spi-nor/spansion.c | 2 +-
>  drivers/mtd/ubi/io.c           | 2 +-
>  include/uapi/mtd/mtd-abi.h     | 1 +
>  5 files changed, 14 insertions(+), 2 deletions(-)
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments India

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

Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Richard Weinberger]

On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav <p.yadav@ti.com> wrote:
> > [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/
>
> Ping. Any comments on the series?

From the UBIFS point of view I'd like to avoid as many device specific
settings as possible.
We check already for NOR flash, checking for NOR *and* SPI_NOR_NO_MULTI_PASS_PP
feels a bit clumsy.

Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP?
This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail
in the mtd framework?

-- 
Thanks,
//richard

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

Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Vignesh Raghavendra]

On 11/1/20 3:14 AM, Richard Weinberger wrote:
> On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav <p.yadav@ti.com> wrote:
>>> [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/
>>
>> Ping. Any comments on the series?
> 
> From the UBIFS point of view I'd like to avoid as many device specific
> settings as possible.
> We check already for NOR flash, checking for NOR *and* SPI_NOR_NO_MULTI_PASS_PP
> feels a bit clumsy.
> 
> Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP?
> This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail
> in the mtd framework?
> 

Agree with Richard. I don't see need for SPI_NOR_NO_MULTI_PASS_PP. From
MTD point of view setting mtd->writesize to be equal to pagesize should
be enough. Its upto clients of MTD devices to ensure there is no multi
pass programming within a "writesize" block.

If this is not clear in the current documentation of struct mtd, then
that can be updated.

Regards
Vignesh

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

Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Pratyush Yadav]

On 03/11/20 05:05PM, Vignesh Raghavendra wrote:
> 
> 
> On 11/1/20 3:14 AM, Richard Weinberger wrote:
> > On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav <p.yadav@ti.com> wrote:
> >>> [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/
> >>
> >> Ping. Any comments on the series?
> > 
> > From the UBIFS point of view I'd like to avoid as many device specific
> > settings as possible.
> > We check already for NOR flash, checking for NOR *and* SPI_NOR_NO_MULTI_PASS_PP
> > feels a bit clumsy.
> > 
> > Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP?
> > This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail
> > in the mtd framework?
> > 
> 
> Agree with Richard. I don't see need for SPI_NOR_NO_MULTI_PASS_PP. From
> MTD point of view setting mtd->writesize to be equal to pagesize should
> be enough. Its upto clients of MTD devices to ensure there is no multi
> pass programming within a "writesize" block.

That is what I initially thought too but then I realized that multi-pass 
programming is completely different from page-size programming. Instead 
of writing 4 bytes twice, you can zero out the entire page in one single 
operation. You would be compliant with the write size requirement but 
you still do multi-pass programming because you did not erase the page 
before this operation.

It is also not completely correct to say the Cypress S28 flash has a 
write size of 256. You _can_ write one byte if you want. You just can't 
write to that page again without erasing it first. For example, if a 
file system only wants to write 128 bytes on a page, it can do so 
without having to write the whole page. It just needs to make sure it 
doesn't write to it again without erasing first.

nor_erase_prepare() was written to handle quirks of some specific 
devices. Not every device starts filling zeroes from the end of a page. 
So we have device-specific code in UBIFS already. You will obviously 
need device-specific settings to have control over that code.

One might argue that we should move nor_erase_prepare() out of UBIFS. 
But requiring a flash to start erasing from the start of the page is a 
UBIFS-specific requirement. Other users of a flash might not care about 
it at all.

And so we have ourselves a bit of a conundrum. Adding 
SPI_NOR_NO_MULTI_PASS_PP is IMHO the least disruptive answer. If the 
file system wants to do multi-pass page programming on NOR flashes, how 
else do we tell it not to do it for this specific flash?

> If this is not clear in the current documentation of struct mtd, then
> that can be updated.

-- 
Regards,
Pratyush Yadav
Texas Instruments India

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

Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Vignesh Raghavendra]

On 11/3/20 6:15 PM, Pratyush Yadav wrote:
> On 03/11/20 05:05PM, Vignesh Raghavendra wrote:
>>
>>
>> On 11/1/20 3:14 AM, Richard Weinberger wrote:
>>> On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav <p.yadav@ti.com> wrote:
>>>>> [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/
>>>>
>>>> Ping. Any comments on the series?
>>>
>>> From the UBIFS point of view I'd like to avoid as many device specific
>>> settings as possible.
>>> We check already for NOR flash, checking for NOR *and* SPI_NOR_NO_MULTI_PASS_PP
>>> feels a bit clumsy.
>>>
>>> Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP?
>>> This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail
>>> in the mtd framework?
>>>
>>
>> Agree with Richard. I don't see need for SPI_NOR_NO_MULTI_PASS_PP. From
>> MTD point of view setting mtd->writesize to be equal to pagesize should
>> be enough. Its upto clients of MTD devices to ensure there is no multi
>> pass programming within a "writesize" block.
> 
> That is what I initially thought too but then I realized that multi-pass 
> programming is completely different from page-size programming. Instead 
> of writing 4 bytes twice, you can zero out the entire page in one single 
> operation. You would be compliant with the write size requirement but 
> you still do multi-pass programming because you did not erase the page 
> before this operation.
> 

Right...

> It is also not completely correct to say the Cypress S28 flash has a 
> write size of 256. You _can_ write one byte if you want. You just can't 
> write to that page again without erasing it first. For example, if a 
> file system only wants to write 128 bytes on a page, it can do so 
> without having to write the whole page. It just needs to make sure it 
> doesn't write to it again without erasing first.
> 

As per documentation:
mtd_info::writesize: "In case of ECC-ed NOR it is of ECC block size"

This means, it is block on which ECC is calculated on ECC-ed NOR and
thus needs to be erased every time before being updated.

Looking at flash datasheet, this seems to be 16 bytes.

So mtd->writesize = 16 and not 256 (or pagesize)


Also, It does not imply length of data being written has to be multiple
of it. At least NAND subsystem does not seem to care that during  writes
len < mtd->writesize[1].

> nor_erase_prepare() was written to handle quirks of some specific 
> devices. Not every device starts filling zeroes from the end of a page. 
> So we have device-specific code in UBIFS already. You will obviously 
> need device-specific settings to have control over that code.
> 

UBIFS intends to be robust against rogue power cuts and therefore would
need to ensure some consistency during erase which explains flash
specific quirk here.

> One might argue that we should move nor_erase_prepare() out of UBIFS. 
> But requiring a flash to start erasing from the start of the page is a 
> UBIFS-specific requirement. Other users of a flash might not care about 
> it at all.
> 

Yes. But I don't see much harm done.

> And so we have ourselves a bit of a conundrum. Adding 
> SPI_NOR_NO_MULTI_PASS_PP is IMHO the least disruptive answer. If the 
> file system wants to do multi-pass page programming on NOR flashes, how 
> else do we tell it not to do it for this specific flash?
> 

I see don't see need for SPI_NOR_NO_MULTI_PASS_PP as
SPI_NOR_NO_MULTI_PASS_PP is implied within a ECC block and writesize is
supposed to represent the same.

>> If this is not clear in the current documentation of struct mtd, then
>> that can be updated.
> 

[1]
https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_base.c#L4166

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

Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Pratyush Yadav]

On 05/11/20 05:51PM, Vignesh Raghavendra wrote:
> 
> 
> On 11/3/20 6:15 PM, Pratyush Yadav wrote:
> > On 03/11/20 05:05PM, Vignesh Raghavendra wrote:
> >>
> >>
> >> On 11/1/20 3:14 AM, Richard Weinberger wrote:
> >>> On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav <p.yadav@ti.com> wrote:
> >>>>> [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/
> >>>>
> >>>> Ping. Any comments on the series?
> >>>
> >>> From the UBIFS point of view I'd like to avoid as many device specific
> >>> settings as possible.
> >>> We check already for NOR flash, checking for NOR *and* SPI_NOR_NO_MULTI_PASS_PP
> >>> feels a bit clumsy.
> >>>
> >>> Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP?
> >>> This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail
> >>> in the mtd framework?
> >>>
> >>
> >> Agree with Richard. I don't see need for SPI_NOR_NO_MULTI_PASS_PP. From
> >> MTD point of view setting mtd->writesize to be equal to pagesize should
> >> be enough. Its upto clients of MTD devices to ensure there is no multi
> >> pass programming within a "writesize" block.
> > 
> > That is what I initially thought too but then I realized that multi-pass 
> > programming is completely different from page-size programming. Instead 
> > of writing 4 bytes twice, you can zero out the entire page in one single 
> > operation. You would be compliant with the write size requirement but 
> > you still do multi-pass programming because you did not erase the page 
> > before this operation.
> > 
> 
> Right...
> 
> > It is also not completely correct to say the Cypress S28 flash has a 
> > write size of 256. You _can_ write one byte if you want. You just can't 
> > write to that page again without erasing it first. For example, if a 
> > file system only wants to write 128 bytes on a page, it can do so 
> > without having to write the whole page. It just needs to make sure it 
> > doesn't write to it again without erasing first.
> > 
> 
> As per documentation:
> mtd_info::writesize: "In case of ECC-ed NOR it is of ECC block size"
> 
> This means, it is block on which ECC is calculated on ECC-ed NOR and
> thus needs to be erased every time before being updated.
> 
> Looking at flash datasheet, this seems to be 16 bytes.
> 
> So mtd->writesize = 16 and not 256 (or pagesize)

Ok.
 
> Also, It does not imply length of data being written has to be multiple
> of it. At least NAND subsystem does not seem to care that during  writes
> len < mtd->writesize[1].

Ok.
 
> > nor_erase_prepare() was written to handle quirks of some specific 
> > devices. Not every device starts filling zeroes from the end of a page. 
> > So we have device-specific code in UBIFS already. You will obviously 
> > need device-specific settings to have control over that code.
> > 
> 
> UBIFS intends to be robust against rogue power cuts and therefore would
> need to ensure some consistency during erase which explains flash
> specific quirk here.

Yes. There is no arguing if this is needed. The only question is how to 
skip it on flashes that don't support doing this.
 
> > One might argue that we should move nor_erase_prepare() out of UBIFS. 
> > But requiring a flash to start erasing from the start of the page is a 
> > UBIFS-specific requirement. Other users of a flash might not care about 
> > it at all.
> > 
> 
> Yes. But I don't see much harm done.
> 
> > And so we have ourselves a bit of a conundrum. Adding 
> > SPI_NOR_NO_MULTI_PASS_PP is IMHO the least disruptive answer. If the 
> > file system wants to do multi-pass page programming on NOR flashes, how 
> > else do we tell it not to do it for this specific flash?
> > 
> 
> I see don't see need for SPI_NOR_NO_MULTI_PASS_PP as
> SPI_NOR_NO_MULTI_PASS_PP is implied within a ECC block and writesize is
> supposed to represent the same.

Ok. So we can control the execution of nor_erase_prepare() with 
mtd->writesize. Will re-roll. Thanks.
 
> >> If this is not clear in the current documentation of struct mtd, then
> >> that can be updated.
> > 
> 
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_base.c#L4166

-- 
Regards,
Pratyush Yadav
Texas Instruments India

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