From: Pratyush Yadav <pratyush@kernel.org>
To: Michael Walle <mwalle@kernel.org>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
Pratyush Yadav <pratyush@kernel.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: [RFC PATCH v1 6/6] mtd: spi-nor: introduce support for displaying deprecation message
Date: Wed, 17 Apr 2024 16:36:06 +0200 [thread overview]
Message-ID: <mafs0jzkw6oq1.fsf@kernel.org> (raw)
In-Reply-To: <20240412134405.381832-7-mwalle@kernel.org> (Michael Walle's message of "Fri, 12 Apr 2024 15:44:05 +0200")
On Fri, Apr 12 2024, Michael Walle wrote:
> SPI-NOR will automatically detect the attached flash device most of the
> time. We cannot easily find out if boards are using a given flash.
> Therefore, introduce a (temporary) flag to display a message on boot if
Why temporary? There will always be a need to deprecate one flash or
another. Might as well keep the flag around.
Also, this patch/series does not add any users of the deprecated flag.
If you have some flashes in mind, it would be good to add them to the
patch/series.
I like the idea in general. Do you think we should also print a rough
date for the deprecation as well?
> support for a given flash device is scheduled to be removed in the
> future.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> drivers/mtd/spi-nor/core.c | 12 ++++++++++++
> drivers/mtd/spi-nor/core.h | 1 +
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 58d310427d35..a294eef2e34a 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3312,6 +3312,7 @@ static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
> const char *name)
> {
> const struct flash_info *jinfo = NULL, *info = NULL;
> + const char *deprecated = NULL;
>
> if (name)
> info = spi_nor_match_name(nor, name);
> @@ -3326,6 +3327,17 @@ static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
> return jinfo;
> }
>
> + if (info && (info->flags & SPI_NOR_DEPRECATED))
> + deprecated = info->name;
> + else if (jinfo && (jinfo->flags & SPI_NOR_DEPRECATED))
> + deprecated = jinfo->name;
> +
> + if (deprecated)
> + pr_warn("Your board or device tree is using a SPI NOR flash (%s) with\n"
> + "deprecated driver support. It will be removed in future kernel\n"
Nit: "removed in a future kernel version"
> + "version. If you feel this shouldn't be the case, please contact\n"
> + "us at linux-mtd@lists.infradead.org\n", deprecated);
> +
Hmm, this isn't so nice. I'd suggest doing something like:
/*
* If caller has specified name of flash model that can normally be
* ...
*/
info = jinfo ?: info;
if (info->flags & SPI_NOR_DEPRECATED)
pr_warn(...);
return info;
> /*
> * If caller has specified name of flash model that can normally be
> * detected using JEDEC, let's verify it.
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 8552e31b1b07..0317d8e253f4 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -524,6 +524,7 @@ struct flash_info {
> #define SPI_NOR_NO_ERASE BIT(6)
> #define SPI_NOR_QUAD_PP BIT(8)
> #define SPI_NOR_RWW BIT(9)
> +#define SPI_NOR_DEPRECATED BIT(15)
If you do agree with my suggestion of making it permanent, would it make
more sense to make it BIT(10) instead. Or BIT(9) once you move up the
others because we no longer have BIT(7).
>
> u8 no_sfdp_flags;
> #define SPI_NOR_SKIP_SFDP BIT(0)
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2024-04-17 14:36 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
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 [this message]
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=mafs0jzkw6oq1.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@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