From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>, <miquel.raynal@bootlin.com>, <richard@nod.at>,
<vigneshr@ti.com>, <linux-mtd@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] mtd: spi-nor: core: Allow flashes to specify MTD writesize
Date: Sat, 28 Nov 2020 10:59:30 +0000 [thread overview]
Message-ID: <939dcad9-b556-ea3e-9eca-c008a86fd01b@microchip.com> (raw)
In-Reply-To: <20201118182459.18197-3-p.yadav@ti.com>
On 11/18/20 8:24 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Some flashes like the Cypress S28 family use ECC. Under this ECC scheme,
> multi-pass writes to an ECC block is not allowed. In other words, once
> data is programmed to an ECC block, it can't be programmed again without
> erasing it first.
>
> Upper layers like file systems need to be given this information so they
> do not cause error conditions on the flash by attempting multi-pass
> programming. This can be done by setting 'writesize' in 'struct
> mtd_info'.
>
> Set the default to 1 but allow flashes to modify it in fixup hooks. If
> more flashes show up with this constraint in the future it might be
> worth it to add it to 'struct flash_info', but for now increasing its
> size is not worth it.
>
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> ---
>
> Notes:
> New in v2.
>
> drivers/mtd/spi-nor/core.c | 4 +++-
> drivers/mtd/spi-nor/core.h | 3 +++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 5bee7c8da4dc..80fbcb9c0828 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3054,6 +3054,8 @@ static int spi_nor_init_params(struct spi_nor *nor)
> if (!nor->params)
> return -ENOMEM;
>
> + nor->params->writesize = 1;
> +
please do default inits in spi_nor_info_init_params(). A good place would be:
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2885,6 +2885,7 @@ static void spi_nor_info_init_params(struct spi_nor *nor)
nor->flags |= SNOR_F_HAS_16BIT_SR;
/* Set SPI NOR sizes. */
+ params->writesize = 1;
params->size = (u64)info->sector_size * info->n_sectors;
params->page_size = info->page_size;
> spi_nor_info_init_params(nor);
>
> spi_nor_manufacturer_init_params(nor);
> @@ -3430,7 +3432,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> mtd->name = dev_name(dev);
> mtd->priv = nor;
> mtd->type = MTD_NORFLASH;
> - mtd->writesize = 1;
> + mtd->writesize = nor->params->writesize;
> mtd->flags = MTD_CAP_NORFLASH;
> mtd->size = nor->params->size;
> mtd->_erase = spi_nor_erase;
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 0a775a7b5606..413ea311e632 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -197,6 +197,8 @@ struct spi_nor_locking_ops {
> * @rdsr_dummy: dummy cycles needed for Read Status Register command.
> * @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register
> * command.
> + * @writesize Minimal writable flash unit size. Defaults to 1. Set to
> + * ECC unit size for ECC-ed flashes.
> * @hwcaps: describes the read and page program hardware
> * capabilities.
> * @reads: read capabilities ordered by priority: the higher index
> @@ -222,6 +224,7 @@ struct spi_nor_flash_parameter {
> u32 page_size;
I would put writesize before or after page_size, because they are related.
Also, it would probably avoid padding.
With these addressed, one can add:
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> u8 rdsr_dummy;
> u8 rdsr_addr_nbytes;
> + u32 writesize;
>
> struct spi_nor_hwcaps hwcaps;
> struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
> --
> 2.28.0
>
next prev parent reply other threads:[~2020-11-28 22:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 18:24 [PATCH v2 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it Pratyush Yadav
2020-11-18 18:24 ` [PATCH v2 1/3] UBI: Do not zero out EC and VID on ECC-ed NOR flashes Pratyush Yadav
2020-11-28 10:58 ` Tudor.Ambarus
2020-11-30 13:20 ` Pratyush Yadav
2020-11-18 18:24 ` [PATCH v2 2/3] mtd: spi-nor: core: Allow flashes to specify MTD writesize Pratyush Yadav
2020-11-28 10:59 ` Tudor.Ambarus [this message]
2020-11-30 13:13 ` Pratyush Yadav
2020-11-18 18:24 ` [PATCH v2 3/3] mtd: spi-nor: spansion: Set ECC block size Pratyush Yadav
2020-11-28 11:00 ` Tudor.Ambarus
2020-11-24 13:46 ` [PATCH v2 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it Pratyush Yadav
2020-11-27 12:55 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=939dcad9-b556-ea3e-9eca-c008a86fd01b@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome