From: Pratyush Yadav <p.yadav@ti.com>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: <michael@walle.cc>, <vigneshr@ti.com>, <figgyc@figgyc.uk>,
<mail@david-bauer.net>, <linux@rasmusvillemoes.dk>,
<esben@geanix.com>, <knaerzche@gmail.com>,
<code@reto-schneider.ch>, <zhengxunli@mxic.com.tw>,
<jaimeliao@mxic.com.tw>, <heiko.thiery@gmail.com>,
<macromorgan@hotmail.com>, <sr@denx.de>,
<miquel.raynal@bootlin.com>, <richard@nod.at>,
<linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 1/7] mtd: spi-nor: core: Introduce SPI_NOR_PARSE_SFDP
Date: Mon, 5 Jul 2021 18:28:01 +0530 [thread overview]
Message-ID: <20210705125759.lgk4qrps6pc2exsg@ti.com> (raw)
In-Reply-To: <20210702144110.250481-2-tudor.ambarus@microchip.com>
Hi Tudor,
I only have small commit message nitpicks/improvements for this patch.
On 02/07/21 05:41PM, Tudor Ambarus wrote:
> SPI NOR flashes that statically declare one of the
> SPI_NOR_{DUAL, QUAD, OCTAL, OCTAL_DTR}_READ flags, and do not support
> the RDSFDP command, are gratuiously receiving the RDSFDP command,
I think you should drop all the commas in this sentence. They seem
unnecessary to me.
> in the attempt of parsing the SFDP tables. It is not desirable to issue
> comands that are not supported, so introduce a flag to help on this
s/comands/commands/
> situation.
>
> New flash additions that support the SFDP standard should be declared
> using SPI_NOR_PARSE_SFDP. Support that can be discovered when parsing
> SFDP should not be duplicated by explicit flags at flash declaration.
> All the flash parameters will be discovered when parsing SFDP.
> Sometimes manufacturers wrongly define some fields in the SFDP tables.
> If that's the case, SFDP data can be ammended with the fixups() hooks.
s/ammended/amended/
> It is not common, but if the SFDP tables are entirely wrong, and it
> does not worth the hassle to tweak the SFDP parameters by using the
> fixups hooks, or if the flash does not define the SFDP tables at all,
> then statically init the flash with the SPI_NOR_SKIP_SFDP flag and
> specify the reset of flash capabilities with the flash info flags.
s/reset/rest/ ?
>
> With time, we want to convert all flashes to SPI_NOR_PARSE_SFDP and
> stop triggering the SFDP parsing with the
> SPI_NOR_{DUAL, QUAD, OCTAL*}_READ flags. Getting rid of the
> SPI_NOR_{OCTAL, OCTAL_DTR}_READ trigger is easy achievable, the reset
s/easy/easily/
s/reset/rest/ ?
> are a long term goal.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
> drivers/mtd/spi-nor/core.c | 3 ++-
> drivers/mtd/spi-nor/core.h | 4 ++++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index cc08bd707378..3d9f3698fb7b 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2726,7 +2726,8 @@ static int spi_nor_init_params(struct spi_nor *nor)
>
> spi_nor_manufacturer_init_params(nor);
>
> - if ((nor->info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> + if ((nor->info->flags & (SPI_NOR_PARSE_SFDP |
> + SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
Ok.
> SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ)) &&
> !(nor->info->flags & SPI_NOR_SKIP_SFDP))
> spi_nor_sfdp_init_params(nor);
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 3348e1dd1445..55fceb0ec894 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -382,6 +382,10 @@ struct flash_info {
> * protection bits. Usually these will
> * power-up in a write-protected state.
> */
> +#define SPI_NOR_PARSE_SFDP BIT(23) /*
> + * Flash initialized based on the SFDP
> + * tables.
> + */
We will be running out of bits to use soon at this rate. But I don't
think it is too much of a worry since it should be easy to make flags
u64.
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
>
> const struct spi_nor_otp_organization otp_org;
>
> --
> 2.25.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-07-05 12:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 14:41 [PATCH 0/7] mtd: spi-nor: Handle flash ID collisions Tudor Ambarus
2021-07-02 14:41 ` [PATCH 1/7] mtd: spi-nor: core: Introduce SPI_NOR_PARSE_SFDP Tudor Ambarus
2021-07-04 13:11 ` Heiko Thiery
2021-07-05 12:58 ` Pratyush Yadav [this message]
2021-07-02 14:41 ` [PATCH 2/7] mtd: spi-nor: core: Report correct name in case of ID collisions Tudor Ambarus
2021-07-04 13:11 ` Heiko Thiery
2021-07-05 13:13 ` Pratyush Yadav
2021-07-05 13:24 ` Tudor.Ambarus
2021-07-05 13:27 ` Tudor.Ambarus
2021-07-05 16:09 ` Pratyush Yadav
2021-07-06 5:19 ` Tudor.Ambarus
2021-07-06 6:39 ` Pratyush Yadav
2021-07-02 14:41 ` [PATCH 3/7] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D Tudor Ambarus
2021-07-06 6:14 ` Pratyush Yadav
2021-07-02 14:41 ` [PATCH 4/7] mtd: spi-nor: macronix: Handle ID collision b/w MX25L12805D and MX25L12835F Tudor Ambarus
2021-07-04 13:11 ` Heiko Thiery
2021-07-05 7:51 ` Tudor.Ambarus
2021-07-05 10:45 ` Heiko Thiery
2021-07-05 10:59 ` Michael Walle
2021-07-05 11:12 ` Heiko Thiery
2021-07-05 11:51 ` Tudor.Ambarus
2021-07-06 6:17 ` Pratyush Yadav
2021-07-02 14:41 ` [PATCH 5/7] mtd: spi-nor: Introduce Manufacturer ID collisions driver Tudor Ambarus
2021-07-06 6:34 ` Pratyush Yadav
2021-07-06 6:46 ` Tudor.Ambarus
2021-07-02 14:41 ` [PATCH 6/7] mtd: spi-nor: manuf-id-collisions: Add support for xt25f128b Tudor Ambarus
2021-07-06 6:28 ` Pratyush Yadav
2021-07-06 6:39 ` Tudor.Ambarus
2021-07-06 6:41 ` Pratyush Yadav
2021-07-06 17:49 ` Chris Morgan
2021-07-02 14:41 ` [PATCH 7/7] mtd: spi-nor: manuf-id-collisions: Add support for xm25qh64c Tudor Ambarus
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=20210705125759.lgk4qrps6pc2exsg@ti.com \
--to=p.yadav@ti.com \
--cc=code@reto-schneider.ch \
--cc=esben@geanix.com \
--cc=figgyc@figgyc.uk \
--cc=heiko.thiery@gmail.com \
--cc=jaimeliao@mxic.com.tw \
--cc=knaerzche@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=macromorgan@hotmail.com \
--cc=mail@david-bauer.net \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=sr@denx.de \
--cc=tudor.ambarus@microchip.com \
--cc=vigneshr@ti.com \
--cc=zhengxunli@mxic.com.tw \
/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