public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael Walle" <mwalle@kernel.org>
To: "Pratyush Yadav" <pratyush@kernel.org>
Cc: "Tudor Ambarus" <tudor.ambarus@linaro.org>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v1 3/6] mtd: spi-nor: get rid of SPI_NOR_NO_FR
Date: Wed, 17 Apr 2024 16:43:15 +0200	[thread overview]
Message-ID: <D0MH78KYG87L.ETRH24X6MK6X@kernel.org> (raw)
In-Reply-To: <mafs0sezk6rcr.fsf@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 5740 bytes --]

Hi,

On Wed Apr 17, 2024 at 3:39 PM CEST, Pratyush Yadav wrote:
> On Fri, Apr 12 2024, Michael Walle wrote:
>
> > The evervision FRAM devices are the only user of the NO_FR flag. Drop
> > the global flag and instead use a manufacturer fixup for the evervision
> > flashes to drop the fast read support.
> >
> > Signed-off-by: Michael Walle <mwalle@kernel.org>
> > ---
> > Please note, that the fast read opcode will still be set in
> > spi_nor_init_default_params(), but the selection of the read opcodes
> > just depends on the mask.
>
> Since that is the case now, might as well drop the
>
>     if (params->hwcaps.mask & SNOR_HWCAPS_READ_FAST)
>
> in spi_nor_init_default_params().

I want to address that in another patch where I'll do that for all
the opcodes. Just doing it for the fast read looks odd.

> > That is also something I want to fix soon: the opcodes can always
> > be set and the drivers/SFDP will only set the mask. Opcodes then can be
> > switched between 3b and 4b ones if necessary.
> > ---
> >  drivers/mtd/spi-nor/core.c     | 12 +++++-------
> >  drivers/mtd/spi-nor/core.h     |  2 --
> >  drivers/mtd/spi-nor/everspin.c | 19 +++++++++++++++----
> >  3 files changed, 20 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index fb76e0522665..65e6531ada0a 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> > @@ -2952,14 +2952,12 @@ static void spi_nor_init_default_params(struct spi_nor *nor)
> >  	params->page_size = info->page_size ?: SPI_NOR_DEFAULT_PAGE_SIZE;
> >  	params->n_banks = info->n_banks ?: SPI_NOR_DEFAULT_N_BANKS;
> >  
> > -	if (!(info->flags & SPI_NOR_NO_FR)) {
> > -		/* Default to Fast Read for DT and non-DT platform devices. */
> > -		params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> > +	/* Default to Fast Read for DT and non-DT platform devices. */
> > +	params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> >  
> > -		/* Mask out Fast Read if not requested at DT instantiation. */
> > -		if (np && !of_property_read_bool(np, "m25p,fast-read"))
> > -			params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
> > -	}
> > +	/* Mask out Fast Read if not requested at DT instantiation. */
> > +	if (np && !of_property_read_bool(np, "m25p,fast-read"))
> > +		params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
>
> Nit: move this above where SNOR_CMD_READ_FAST is set up.
>
> Also, I think this is a bit clearer:
>
> 	/* Default to Fast Read for non-DT and enable it if requested by DT. */
> 	if (!np || of_property_read_bool(np, "m25p,fast-read"))
> 		params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;

Will do.

> >  	/* (Fast) Read settings. */
> >  	params->hwcaps.mask |= SNOR_HWCAPS_READ;
> > diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> > index 072c69b0d06c..9aa7d6399c8a 100644
> > --- a/drivers/mtd/spi-nor/core.h
> > +++ b/drivers/mtd/spi-nor/core.h
> > @@ -479,7 +479,6 @@ struct spi_nor_id {
> >   *                            Usually these will power-up in a write-protected
> >   *                            state.
> >   *   SPI_NOR_NO_ERASE:        no erase command needed.
> > - *   SPI_NOR_NO_FR:           can't do fastread.
> >   *   SPI_NOR_QUAD_PP:         flash supports Quad Input Page Program.
> >   *   SPI_NOR_RWW:             flash supports reads while write.
> >   *
> > @@ -528,7 +527,6 @@ struct flash_info {
> >  #define SPI_NOR_BP3_SR_BIT6		BIT(4)
> >  #define SPI_NOR_SWP_IS_VOLATILE		BIT(5)
> >  #define SPI_NOR_NO_ERASE		BIT(6)
> > -#define SPI_NOR_NO_FR			BIT(7)
> >  #define SPI_NOR_QUAD_PP			BIT(8)
> >  #define SPI_NOR_RWW			BIT(9)
>
> Move the other bits up since the slot is now free.

Mhh can't decide what's better here. On one hand I'd really like to
avoid too much code churn because it's already hard enough to follow
the development using git blame. OTOH, a new flag would need to be
added in between the existing flags. Not sure.. Or we if we run out
of free spots at the end we might get rid of the free slots.

-michael

> > diff --git a/drivers/mtd/spi-nor/everspin.c b/drivers/mtd/spi-nor/everspin.c
> > index 5f321e24ae7d..0720a61947e7 100644
> > --- a/drivers/mtd/spi-nor/everspin.c
> > +++ b/drivers/mtd/spi-nor/everspin.c
> > @@ -14,28 +14,39 @@ static const struct flash_info everspin_nor_parts[] = {
> >  		.size = SZ_16K,
> >  		.sector_size = SZ_16K,
> >  		.addr_nbytes = 2,
> > -		.flags = SPI_NOR_NO_ERASE | SPI_NOR_NO_FR,
> > +		.flags = SPI_NOR_NO_ERASE,
> >  	}, {
> >  		.name = "mr25h256",
> >  		.size = SZ_32K,
> >  		.sector_size = SZ_32K,
> >  		.addr_nbytes = 2,
> > -		.flags = SPI_NOR_NO_ERASE | SPI_NOR_NO_FR,
> > +		.flags = SPI_NOR_NO_ERASE,
> >  	}, {
> >  		.name = "mr25h10",
> >  		.size = SZ_128K,
> >  		.sector_size = SZ_128K,
> > -		.flags = SPI_NOR_NO_ERASE | SPI_NOR_NO_FR,
> > +		.flags = SPI_NOR_NO_ERASE,
> >  	}, {
> >  		.name = "mr25h40",
> >  		.size = SZ_512K,
> >  		.sector_size = SZ_512K,
> > -		.flags = SPI_NOR_NO_ERASE | SPI_NOR_NO_FR,
> > +		.flags = SPI_NOR_NO_ERASE,
> >  	}
> >  };
> >  
> > +static void evervision_nor_default_init(struct spi_nor *nor)
> > +{
> > +	/* Everspin FRAMs don't support the fast read opcode. */
> > +	nor->params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
> > +}
> > +
> > +static const struct spi_nor_fixups evervision_nor_fixups = {
> > +	.default_init = evervision_nor_default_init,
> > +};
> > +
> >  const struct spi_nor_manufacturer spi_nor_everspin = {
> >  	.name = "everspin",
> >  	.parts = everspin_nor_parts,
> >  	.nparts = ARRAY_SIZE(everspin_nor_parts),
> > +	.fixups = &evervision_nor_fixups,
> >  };


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

  reply	other threads:[~2024-04-17 14:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-12 13:43 [PATCH v1 0/6] mtd: spi-nor: spring cleaning Michael Walle
2024-04-12 13:44 ` [PATCH v1 1/6] mtd: spi-nor: Remove support for Xilinx S3AN flashes Michael Walle
2024-04-12 13:53   ` Tudor Ambarus
2024-04-12 14:01     ` Michael Walle
2024-04-15 15:26       ` Pratyush Yadav
2024-04-16  4:45         ` Tudor Ambarus
2024-04-12 13:44 ` [PATCH v1 2/6] mtd: spi-nor: get rid of non-power-of-2 page size handling Michael Walle
2024-04-12 13:58   ` Tudor Ambarus
2024-04-15 15:49   ` Pratyush Yadav
2024-04-12 13:44 ` [PATCH v1 3/6] mtd: spi-nor: get rid of SPI_NOR_NO_FR Michael Walle
2024-04-12 14:00   ` Tudor Ambarus
2024-04-12 14:03     ` Michael Walle
2024-04-16  4:47       ` Tudor Ambarus
2024-04-17 13:39   ` Pratyush Yadav
2024-04-17 14:43     ` Michael Walle [this message]
2024-04-17 15:37       ` Pratyush Yadav
2024-04-17 15:45         ` Michael Walle
2024-04-17 15:54           ` Pratyush Yadav
2024-04-12 13:44 ` [PATCH v1 4/6] mtd: spi-nor: remove .setup() callback Michael Walle
2024-04-12 14:02   ` Tudor Ambarus
2024-04-12 13:44 ` [PATCH v1 5/6] mtd: spi-nor: simplify spi_nor_get_flash_info() Michael Walle
2024-04-17 14:18   ` Pratyush Yadav
2024-04-12 13:44 ` [RFC PATCH v1 6/6] mtd: spi-nor: introduce support for displaying deprecation message Michael Walle
2024-04-12 14:10   ` Tudor Ambarus
2024-04-17 14:36   ` Pratyush Yadav
2024-04-17 14:52     ` Michael Walle
2024-04-17 15:52       ` Pratyush Yadav
2024-04-18  9:57         ` Michael Walle
2024-04-18 11:20           ` Pratyush Yadav
2024-04-16  4:57 ` [PATCH v1 0/6] mtd: spi-nor: spring cleaning Tudor Ambarus
2024-04-17 15:02   ` Michael Walle

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=D0MH78KYG87L.ETRH24X6MK6X@kernel.org \
    --to=mwalle@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --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