All of lore.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: [RFC PATCH v1 6/6] mtd: spi-nor: introduce support for displaying deprecation message
Date: Wed, 17 Apr 2024 16:52:42 +0200	[thread overview]
Message-ID: <D0MHEH8OOS44.2PPBZ3LFU4QG3@kernel.org> (raw)
In-Reply-To: <mafs0jzkw6oq1.fsf@kernel.org>


[-- Attachment #1.1: Type: text/plain, Size: 4046 bytes --]

Hi,

On Wed Apr 17, 2024 at 4:36 PM CEST, Pratyush Yadav wrote:
> 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.

Mh, yes I agree. That also means that this flag will not have any
users (most) of the time (hopefully ;) ).

> 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.

This is just an RFC to see if whether you Tudor agree with me :) But
I was about to add it to the evervision/cypress FRAMs.

> I like the idea in general. Do you think we should also print a rough
> date for the deprecation as well?

Might make sense, any suggestions?

> > 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(...);

Actually, I had that, *but* I was thinking we might only check the
detected flash and not the one specified in the device tree. But
thinking about that again, I guess it makes sense because:
 - that's the actually used flash driver
 - having jinfo != info will print that other warning, thus this
   case is hopefully very unlikely.

>
> 	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).

Or just BIT(7) and avoid any code churn :)

-michael

>
> >  
> >  	u8 no_sfdp_flags;
> >  #define SPI_NOR_SKIP_SFDP		BIT(0)


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

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

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

WARNING: multiple messages have this Message-ID (diff)
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: [RFC PATCH v1 6/6] mtd: spi-nor: introduce support for displaying deprecation message
Date: Wed, 17 Apr 2024 16:52:42 +0200	[thread overview]
Message-ID: <D0MHEH8OOS44.2PPBZ3LFU4QG3@kernel.org> (raw)
In-Reply-To: <mafs0jzkw6oq1.fsf@kernel.org>

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

Hi,

On Wed Apr 17, 2024 at 4:36 PM CEST, Pratyush Yadav wrote:
> 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.

Mh, yes I agree. That also means that this flag will not have any
users (most) of the time (hopefully ;) ).

> 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.

This is just an RFC to see if whether you Tudor agree with me :) But
I was about to add it to the evervision/cypress FRAMs.

> I like the idea in general. Do you think we should also print a rough
> date for the deprecation as well?

Might make sense, any suggestions?

> > 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(...);

Actually, I had that, *but* I was thinking we might only check the
detected flash and not the one specified in the device tree. But
thinking about that again, I guess it makes sense because:
 - that's the actually used flash driver
 - having jinfo != info will print that other warning, thus this
   case is hopefully very unlikely.

>
> 	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).

Or just BIT(7) and avoid any code churn :)

-michael

>
> >  
> >  	u8 no_sfdp_flags;
> >  #define SPI_NOR_SKIP_SFDP		BIT(0)


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

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

Thread overview: 62+ 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:43 ` 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:44   ` Michael Walle
2024-04-12 13:53   ` Tudor Ambarus
2024-04-12 13:53     ` Tudor Ambarus
2024-04-12 14:01     ` Michael Walle
2024-04-12 14:01       ` Michael Walle
2024-04-15 15:26       ` Pratyush Yadav
2024-04-15 15:26         ` Pratyush Yadav
2024-04-16  4:45         ` Tudor Ambarus
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:44   ` Michael Walle
2024-04-12 13:58   ` Tudor Ambarus
2024-04-12 13:58     ` Tudor Ambarus
2024-04-15 15:49   ` Pratyush Yadav
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 13:44   ` Michael Walle
2024-04-12 14:00   ` Tudor Ambarus
2024-04-12 14:00     ` Tudor Ambarus
2024-04-12 14:03     ` Michael Walle
2024-04-12 14:03       ` Michael Walle
2024-04-16  4:47       ` Tudor Ambarus
2024-04-16  4:47         ` Tudor Ambarus
2024-04-17 13:39   ` Pratyush Yadav
2024-04-17 13:39     ` Pratyush Yadav
2024-04-17 14:43     ` Michael Walle
2024-04-17 14:43       ` Michael Walle
2024-04-17 15:37       ` Pratyush Yadav
2024-04-17 15:37         ` Pratyush Yadav
2024-04-17 15:45         ` Michael Walle
2024-04-17 15:45           ` Michael Walle
2024-04-17 15:54           ` Pratyush Yadav
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 13:44   ` Michael Walle
2024-04-12 14:02   ` Tudor Ambarus
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-12 13:44   ` Michael Walle
2024-04-17 14:18   ` Pratyush Yadav
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 13:44   ` Michael Walle
2024-04-12 14:10   ` Tudor Ambarus
2024-04-12 14:10     ` Tudor Ambarus
2024-04-17 14:36   ` Pratyush Yadav
2024-04-17 14:36     ` Pratyush Yadav
2024-04-17 14:52     ` Michael Walle [this message]
2024-04-17 14:52       ` Michael Walle
2024-04-17 15:52       ` Pratyush Yadav
2024-04-17 15:52         ` Pratyush Yadav
2024-04-18  9:57         ` Michael Walle
2024-04-18  9:57           ` Michael Walle
2024-04-18 11:20           ` Pratyush Yadav
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-16  4:57   ` Tudor Ambarus
2024-04-17 15:02   ` Michael Walle
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=D0MHEH8OOS44.2PPBZ3LFU4QG3@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 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.