From: Pratyush Yadav <p.yadav@ti.com>
To: <Tudor.Ambarus@microchip.com>
Cc: <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: Mon, 30 Nov 2020 18:43:52 +0530 [thread overview]
Message-ID: <20201130131350.spqvde2al4ajf4fz@ti.com> (raw)
In-Reply-To: <939dcad9-b556-ea3e-9eca-c008a86fd01b@microchip.com>
On 28/11/20 10:59AM, Tudor.Ambarus@microchip.com wrote:
> 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;
Ok.
>
> > 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.
Ok.
> With these addressed, one can add:
>
> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Thanks.
> > 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
> >
>
--
Regards,
Pratyush Yadav
Texas Instruments India
next prev parent reply other threads:[~2020-11-30 13:16 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
2020-11-30 13:13 ` Pratyush Yadav [this message]
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=20201130131350.spqvde2al4ajf4fz@ti.com \
--to=p.yadav@ti.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.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