2022-02-02 17:05:07

by Michael Walle

Subject: [PATCH v1 03/14] mtd: spi-nor: allow a flash to define its own ready() function

Xilinx and Micron flashes have their own implementation of the
spi_nor_ready() function. At the moment, the core will figure out
which one to call according to some flags. Lay the foundation to
make it possible that a flash can register its own ready()
function.

Signed-off-by: Michael Walle <[email protected]>
---
drivers/mtd/spi-nor/core.c | 4 ++++
drivers/mtd/spi-nor/core.h | 4 ++++
2 files changed, 8 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index c8cc906cf771..c181f2680df2 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -794,6 +794,10 @@ static int spi_nor_ready(struct spi_nor *nor)
{
int sr, fsr;

+ /* flashes might override our standard routine */
+ if (nor->params->ready)
+ return nor->params->ready(nor);
+
if (nor->flags & SNOR_F_READY_XSR_RDY)
sr = spi_nor_xsr_ready(nor);
else
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 10f478547dc2..446218b0e017 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -261,6 +261,9 @@ struct spi_nor_otp {
* SPI NOR flashes that have peculiarities to the SPI NOR
* standard e.g. different opcodes, specific address
* calculation, page size, etc.
+ * @ready: (optional) flashes might use a different mechanism
+ * than reading the status register to indicate they
+ * are ready for a new command
* @locking_ops: SPI NOR locking methods.
*/
struct spi_nor_flash_parameter {
@@ -282,6 +285,7 @@ struct spi_nor_flash_parameter {
int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
int (*setup)(struct spi_nor *nor, const struct spi_nor_hwcaps *hwcaps);
+ int (*ready)(struct spi_nor *nor);

const struct spi_nor_locking_ops *locking_ops;
};
--
2.30.2

2022-02-10 03:17:39

by Tudor Ambarus

Subject: Re: [PATCH v1 03/14] mtd: spi-nor: allow a flash to define its own ready() function

On 2/2/22 16:58, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Xilinx and Micron flashes have their own implementation of the
> spi_nor_ready() function. At the moment, the core will figure out
> which one to call according to some flags. Lay the foundation to
> make it possible that a flash can register its own ready()
> function.
>
> Signed-off-by: Michael Walle <[email protected]>
> ---
> drivers/mtd/spi-nor/core.c | 4 ++++
> drivers/mtd/spi-nor/core.h | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index c8cc906cf771..c181f2680df2 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -794,6 +794,10 @@ static int spi_nor_ready(struct spi_nor *nor)
> {
> int sr, fsr;
>
> + /* flashes might override our standard routine */

let's start comments with capital letter and put a dot at the end of
the sentence. s/our/the

Reviewed-by: Tudor Ambarus <[email protected]>
> + if (nor->params->ready)
> + return nor->params->ready(nor);
> +
> if (nor->flags & SNOR_F_READY_XSR_RDY)
> sr = spi_nor_xsr_ready(nor);
> else
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 10f478547dc2..446218b0e017 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -261,6 +261,9 @@ struct spi_nor_otp {
> * SPI NOR flashes that have peculiarities to the SPI NOR
> * standard e.g. different opcodes, specific address
> * calculation, page size, etc.
> + * @ready: (optional) flashes might use a different mechanism
> + * than reading the status register to indicate they
> + * are ready for a new command
> * @locking_ops: SPI NOR locking methods.
> */
> struct spi_nor_flash_parameter {
> @@ -282,6 +285,7 @@ struct spi_nor_flash_parameter {
> int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
> u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
> int (*setup)(struct spi_nor *nor, const struct spi_nor_hwcaps *hwcaps);
> + int (*ready)(struct spi_nor *nor);
>
> const struct spi_nor_locking_ops *locking_ops;
> };
> --
> 2.30.2
>

2022-02-16 06:38:03

by Pratyush Yadav

Subject: Re: [PATCH v1 03/14] mtd: spi-nor: allow a flash to define its own ready() function

On 10/02/22 03:05AM, [email protected] wrote:
> On 2/2/22 16:58, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Xilinx and Micron flashes have their own implementation of the
> > spi_nor_ready() function. At the moment, the core will figure out
> > which one to call according to some flags. Lay the foundation to
> > make it possible that a flash can register its own ready()
> > function.
> >
> > Signed-off-by: Michael Walle <[email protected]>
> > ---
> > drivers/mtd/spi-nor/core.c | 4 ++++
> > drivers/mtd/spi-nor/core.h | 4 ++++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index c8cc906cf771..c181f2680df2 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> > @@ -794,6 +794,10 @@ static int spi_nor_ready(struct spi_nor *nor)
> > {
> > int sr, fsr;
> >
> > + /* flashes might override our standard routine */
>
> let's start comments with capital letter and put a dot at the end of
> the sentence. s/our/the

+1

>
> Reviewed-by: Tudor Ambarus <[email protected]>

With that fixed,

Reviewed-by: Pratyush Yadav <[email protected]>

> > + if (nor->params->ready)
> > + return nor->params->ready(nor);
> > +
> > if (nor->flags & SNOR_F_READY_XSR_RDY)
> > sr = spi_nor_xsr_ready(nor);
> > else
> > diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> > index 10f478547dc2..446218b0e017 100644
> > --- a/drivers/mtd/spi-nor/core.h
> > +++ b/drivers/mtd/spi-nor/core.h
> > @@ -261,6 +261,9 @@ struct spi_nor_otp {
> > * SPI NOR flashes that have peculiarities to the SPI NOR
> > * standard e.g. different opcodes, specific address
> > * calculation, page size, etc.
> > + * @ready: (optional) flashes might use a different mechanism
> > + * than reading the status register to indicate they
> > + * are ready for a new command
> > * @locking_ops: SPI NOR locking methods.
> > */
> > struct spi_nor_flash_parameter {
> > @@ -282,6 +285,7 @@ struct spi_nor_flash_parameter {
> > int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
> > u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
> > int (*setup)(struct spi_nor *nor, const struct spi_nor_hwcaps *hwcaps);
> > + int (*ready)(struct spi_nor *nor);
> >
> > const struct spi_nor_locking_ops *locking_ops;
> > };
> > --
> > 2.30.2
> >
>

--
Regards,
Pratyush Yadav
Texas Instruments Inc.