Messages in this thread | | | Date | Thu, 18 Apr 2024 11:57:27 +0200 | Subject | Re: [RFC PATCH v1 6/6] mtd: spi-nor: introduce support for displaying deprecation message | From | "Michael Walle" <> |
| |
Hi,
On Wed Apr 17, 2024 at 5:52 PM CEST, Pratyush Yadav wrote: > On Wed, Apr 17 2024, Michael Walle wrote: > > 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? > > How about a simple string to flash_info?
Ahh, I was rather asking if you already had a time frame in mind.
Besides that, should it be a date or a (future) kernel version? Roughly about two/three kernel releases?
> /** > * struct flash_info - SPI NOR flash_info entry. > * @id: pointer to struct spi_nor_id or NULL, which means "no ID" (mostly > * older chips). > * @name: (obsolete) the name of the flash. Do not set it for new additions. > * @size: the size of the flash in bytes. > * @deprecation_date: The date after which the support for this flash will be > * removed. > * [...] > */ > struct flash_info { > char *name; > const struct spi_nor_id *id; > char *deprecation_date; > [...] > } > > And then in everspin.c for example, > > { > .name = "mr25h128", > .size = SZ_16K, > .sector_size = SZ_16K, > .addr_nbytes = 2, > .flags = SPI_NOR_NO_ERASE | SPI_NOR_NO_FR, > .deprecation_date = "2025-01-01", > }, { > > And in spi_nor_get_flash_info() (changed some wording of the message): > > info = jinfo ?: info; > > if (info->deprecation_date) > pr_warn("Your board or device tree is using a SPI NOR flash (%s) with\n" > "deprecated driver support. It can be removed in any kernel\n" > "version after %s. If you feel this shouldn't be the case, please contact\n" > "us at linux-mtd@lists.infradead.org\n", info->name, > info->deprecation_date); > > return info; > > This would also remove the need for SPI_NOR_DEPRECATED. But it would > make the flash_info 4 or 8 bytes larger. > > What do you think?
Looks good.
-michael [unhandled content-type:application/pgp-signature] | |