All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Cc: <p.yadav@ti.com>, <miquel.raynal@bootlin.com>, <richard@nod.at>,
	<vigneshr@ti.com>
Subject: Re: [PATCH v1 03/14] mtd: spi-nor: allow a flash to define its own ready() function
Date: Thu, 10 Feb 2022 03:05:01 +0000	[thread overview]
Message-ID: <399c8ea5-e534-9da4-43c0-199e1b88bfae@microchip.com> (raw)
In-Reply-To: <20220202145853.4187726-4-michael@walle.cc>

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 <michael@walle.cc>
> ---
>  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 <tudor.ambarus@microchip.com>
> +       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
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Cc: <p.yadav@ti.com>, <miquel.raynal@bootlin.com>, <richard@nod.at>,
	<vigneshr@ti.com>
Subject: Re: [PATCH v1 03/14] mtd: spi-nor: allow a flash to define its own ready() function
Date: Thu, 10 Feb 2022 03:05:01 +0000	[thread overview]
Message-ID: <399c8ea5-e534-9da4-43c0-199e1b88bfae@microchip.com> (raw)
In-Reply-To: <20220202145853.4187726-4-michael@walle.cc>

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 <michael@walle.cc>
> ---
>  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 <tudor.ambarus@microchip.com>
> +       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
> 


  reply	other threads:[~2022-02-10  3:06 UTC|newest]

Thread overview: 126+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02 14:58 [PATCH v1 00/14] mtd: spi-nor: move vendor specific code into vendor modules Michael Walle
2022-02-02 14:58 ` Michael Walle
2022-02-02 14:58 ` [PATCH v1 01/14] mtd: spi-nor: export more function to be used in " Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:13   ` Tudor.Ambarus
2022-02-10  3:13     ` Tudor.Ambarus
2022-02-15 18:30     ` Pratyush Yadav
2022-02-15 18:30       ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 02/14] mtd: spi-nor: slightly refactor the spi_nor_setup() Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:00   ` Tudor.Ambarus
2022-02-10  3:00     ` Tudor.Ambarus
2022-02-10  8:01     ` Michael Walle
2022-02-10  8:01       ` Michael Walle
2022-02-10  8:05       ` Tudor.Ambarus
2022-02-10  8:05         ` Tudor.Ambarus
2022-02-15 18:32   ` Pratyush Yadav
2022-02-15 18:32     ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 03/14] mtd: spi-nor: allow a flash to define its own ready() function Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:05   ` Tudor.Ambarus [this message]
2022-02-10  3:05     ` Tudor.Ambarus
2022-02-15 18:36     ` Pratyush Yadav
2022-02-15 18:36       ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 04/14] mtd: spi-nor: move all xilinx specifics into xilinx.c Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:04   ` Tudor.Ambarus
2022-02-10  3:04     ` Tudor.Ambarus
2022-02-15 18:57   ` Pratyush Yadav
2022-02-15 18:57     ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 05/14] mtd: spi-nor: xilinx: rename vendor specific functions and defines Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-02 17:14   ` kernel test robot
2022-02-02 17:14     ` kernel test robot
2022-02-02 17:14     ` kernel test robot
2022-02-02 20:07   ` kernel test robot
2022-02-02 20:07     ` kernel test robot
2022-02-02 20:07     ` kernel test robot
2022-02-10  3:08   ` Tudor.Ambarus
2022-02-10  3:08     ` Tudor.Ambarus
2022-02-10  8:04     ` Michael Walle
2022-02-10  8:04       ` Michael Walle
2022-02-10  8:06       ` Tudor.Ambarus
2022-02-10  8:06         ` Tudor.Ambarus
2022-02-15  8:25         ` Michael Walle
2022-02-15  8:25           ` Michael Walle
2022-02-15  8:52           ` Tudor.Ambarus
2022-02-15  8:52             ` Tudor.Ambarus
2022-02-15  9:58             ` Michael Walle
2022-02-15  9:58               ` Michael Walle
2022-02-15 10:12               ` Tudor.Ambarus
2022-02-15 10:12                 ` Tudor.Ambarus
2022-02-15 19:04   ` Pratyush Yadav
2022-02-15 19:04     ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 06/14] mtd: spi-nor: xilinx: correct the debug message Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:11   ` Tudor.Ambarus
2022-02-10  3:11     ` Tudor.Ambarus
2022-02-15 19:05     ` Pratyush Yadav
2022-02-15 19:05       ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 07/14] mtd: spi-nor: move all micron-st specifics into micron-st.c Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:18   ` Tudor.Ambarus
2022-02-10  3:18     ` Tudor.Ambarus
2022-02-15 19:13   ` Pratyush Yadav
2022-02-15 19:13     ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 08/14] mtd: spi-nor: micron-st: convert USE_FSR to a manufacturer flag Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:37   ` Tudor.Ambarus
2022-02-10  3:37     ` Tudor.Ambarus
2022-02-15 19:16     ` Pratyush Yadav
2022-02-15 19:16       ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 09/14] mtd: spi-nor: micron-st: fix micron_st prefix Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:23   ` Tudor.Ambarus
2022-02-10  3:23     ` Tudor.Ambarus
2022-02-15 19:16   ` Pratyush Yadav
2022-02-15 19:16     ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 10/14] mtd: spi-nor: micron-st: rename vendor specific functions and defines Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:23   ` Tudor.Ambarus
2022-02-10  3:23     ` Tudor.Ambarus
2022-02-02 14:58 ` [PATCH v1 11/14] mtd: spi-nor: spansion: slightly rework control flow in late_init() Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:26   ` Tudor.Ambarus
2022-02-10  3:26     ` Tudor.Ambarus
2022-02-10  8:16     ` Michael Walle
2022-02-10  8:16       ` Michael Walle
2022-02-10  8:42       ` Tudor.Ambarus
2022-02-10  8:42         ` Tudor.Ambarus
2022-02-14 18:59     ` Pratyush Yadav
2022-02-14 18:59       ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 12/14] mtd: spi-nor: move all spansion specifics into spansion.c Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-02 18:15   ` kernel test robot
2022-02-02 18:15     ` kernel test robot
2022-02-02 18:15     ` kernel test robot
2022-02-02 20:07   ` kernel test robot
2022-02-02 20:07     ` kernel test robot
2022-02-02 20:07     ` kernel test robot
2022-02-02 21:38   ` [RFC PATCH] mtd: spi-nor: spi_nor_sr_ready_and_clear() can be static kernel test robot
2022-02-02 21:38     ` kernel test robot
2022-02-02 21:38     ` kernel test robot
2022-02-02 21:48   ` [PATCH v1 12/14] mtd: spi-nor: move all spansion specifics into spansion.c kernel test robot
2022-02-02 21:48     ` kernel test robot
2022-02-02 21:48     ` kernel test robot
2022-02-10  3:32   ` Tudor.Ambarus
2022-02-10  3:32     ` Tudor.Ambarus
2022-02-15 19:23     ` Pratyush Yadav
2022-02-15 19:23       ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 13/14] mtd: spi-nor: spansion: convert USE_CLSR to a manufacturer flag Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:34   ` Tudor.Ambarus
2022-02-10  3:34     ` Tudor.Ambarus
2022-02-15 19:25     ` Pratyush Yadav
2022-02-15 19:25       ` Pratyush Yadav
2022-02-02 14:58 ` [PATCH v1 14/14] mtd: spi-nor: renumber flags Michael Walle
2022-02-02 14:58   ` Michael Walle
2022-02-10  3:38   ` Tudor.Ambarus
2022-02-10  3:38     ` Tudor.Ambarus
2022-02-15 19:27   ` Pratyush Yadav
2022-02-15 19:27     ` Pratyush Yadav
2022-02-10  3:42 ` [PATCH v1 00/14] mtd: spi-nor: move vendor specific code into vendor modules Tudor.Ambarus
2022-02-10  3:42   ` Tudor.Ambarus
2022-02-17  7:31 ` Tudor.Ambarus
2022-02-17  7:31   ` 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=399c8ea5-e534-9da4-43c0-199e1b88bfae@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.