Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2] printk: Add a short description string to kmsg_dump()
From: Jocelyn Falempe @ 2024-07-12  9:59 UTC (permalink / raw)
  To: Michael Ellerman, Nicholas Piggin, Christophe Leroy,
	Naveen N. Rao, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, David Airlie, Daniel Vetter, K. Y. Srinivasan,
	Haiyang Zhang, Wei Liu, Dexuan Cui, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Kees Cook, Tony Luck,
	Guilherme G. Piccoli, Petr Mladek, Steven Rostedt, John Ogness,
	Sergey Senozhatsky, Andrew Morton, Jani Nikula,
	Greg Kroah-Hartman, Kefeng Wang, Thomas Gleixner, Uros Bizjak,
	linuxppc-dev, linux-kernel, dri-devel, linux-hyperv, linux-mtd,
	linux-hardening
In-Reply-To: <20240702122639.248110-1-jfalempe@redhat.com>

On 02/07/2024 14:26, Jocelyn Falempe wrote:
> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
> callback.
> This patch adds a new struct kmsg_dump_detail, that will hold the
> reason and description, and pass it to the dump() callback.
> 
> To avoid updating all kmsg_dump() call, it adds a kmsg_dump_desc()
> function and a macro for backward compatibility.
> 
> I've written this for drm_panic, but it can be useful for other
> kmsg_dumper.
> It allows to see the panic reason, like "sysrq triggered crash"
> or "VFS: Unable to mount root fs on xxxx" on the drm panic screen.
> 
> v2:
>   * Use a struct kmsg_dump_detail to hold the reason and description
>     pointer, for more flexibility if we want to add other parameters.
>     (Kees Cook)
>   * Fix powerpc/nvram_64 build, as I didn't update the forward
>     declaration of oops_to_nvram()
> 
> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
> ---
>   arch/powerpc/kernel/nvram_64.c             |  8 ++++----
>   arch/powerpc/platforms/powernv/opal-kmsg.c |  4 ++--
>   arch/um/kernel/kmsg_dump.c                 |  2 +-
>   drivers/gpu/drm/drm_panic.c                |  4 ++--
>   drivers/hv/hv_common.c                     |  4 ++--
>   drivers/mtd/mtdoops.c                      |  2 +-
>   fs/pstore/platform.c                       | 10 +++++-----
>   include/linux/kmsg_dump.h                  | 22 +++++++++++++++++++---
>   kernel/panic.c                             |  2 +-
>   kernel/printk/printk.c                     | 11 ++++++++---
>   10 files changed, 45 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
> index e385d3164648..f9c6568a9137 100644
> --- a/arch/powerpc/kernel/nvram_64.c
> +++ b/arch/powerpc/kernel/nvram_64.c
> @@ -73,7 +73,7 @@ static const char *nvram_os_partitions[] = {
>   };
>   
>   static void oops_to_nvram(struct kmsg_dumper *dumper,
> -			  enum kmsg_dump_reason reason);
> +			  struct kmsg_dump_detail *detail);
>   
>   static struct kmsg_dumper nvram_kmsg_dumper = {
>   	.dump = oops_to_nvram
> @@ -643,7 +643,7 @@ void __init nvram_init_oops_partition(int rtas_partition_exists)
>    * partition.  If that's too much, go back and capture uncompressed text.
>    */
>   static void oops_to_nvram(struct kmsg_dumper *dumper,
> -			  enum kmsg_dump_reason reason)
> +			  struct kmsg_dump_detail *detail)
>   {
>   	struct oops_log_info *oops_hdr = (struct oops_log_info *)oops_buf;
>   	static unsigned int oops_count = 0;
> @@ -655,7 +655,7 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
>   	unsigned int err_type = ERR_TYPE_KERNEL_PANIC_GZ;
>   	int rc = -1;
>   
> -	switch (reason) {
> +	switch (detail->reason) {
>   	case KMSG_DUMP_SHUTDOWN:
>   		/* These are almost always orderly shutdowns. */
>   		return;
> @@ -671,7 +671,7 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
>   		break;
>   	default:
>   		pr_err("%s: ignoring unrecognized KMSG_DUMP_* reason %d\n",
> -		       __func__, (int) reason);
> +		       __func__, (int) detail->reason);
>   		return;
>   	}
>   
> diff --git a/arch/powerpc/platforms/powernv/opal-kmsg.c b/arch/powerpc/platforms/powernv/opal-kmsg.c
> index 6c3bc4b4da98..bb4218fa796e 100644
> --- a/arch/powerpc/platforms/powernv/opal-kmsg.c
> +++ b/arch/powerpc/platforms/powernv/opal-kmsg.c
> @@ -20,13 +20,13 @@
>    * message, it just ensures that OPAL completely flushes the console buffer.
>    */
>   static void kmsg_dump_opal_console_flush(struct kmsg_dumper *dumper,
> -				     enum kmsg_dump_reason reason)
> +				     struct kmsg_dump_detail *detail)
>   {
>   	/*
>   	 * Outside of a panic context the pollers will continue to run,
>   	 * so we don't need to do any special flushing.
>   	 */
> -	if (reason != KMSG_DUMP_PANIC)
> +	if (detail->reason != KMSG_DUMP_PANIC)
>   		return;
>   
>   	opal_flush_console(0);
> diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c
> index 4382cf02a6d1..419021175272 100644
> --- a/arch/um/kernel/kmsg_dump.c
> +++ b/arch/um/kernel/kmsg_dump.c
> @@ -8,7 +8,7 @@
>   #include <os.h>
>   
>   static void kmsg_dumper_stdout(struct kmsg_dumper *dumper,
> -				enum kmsg_dump_reason reason)
> +				struct kmsg_dump_detail *detail)
>   {
>   	static struct kmsg_dump_iter iter;
>   	static DEFINE_SPINLOCK(lock);
> diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
> index 948aed00595e..8794c7f6c0ee 100644
> --- a/drivers/gpu/drm/drm_panic.c
> +++ b/drivers/gpu/drm/drm_panic.c
> @@ -655,11 +655,11 @@ static struct drm_plane *to_drm_plane(struct kmsg_dumper *kd)
>   	return container_of(kd, struct drm_plane, kmsg_panic);
>   }
>   
> -static void drm_panic(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason)
> +static void drm_panic(struct kmsg_dumper *dumper, struct kmsg_dump_detail *detail)
>   {
>   	struct drm_plane *plane = to_drm_plane(dumper);
>   
> -	if (reason == KMSG_DUMP_PANIC)
> +	if (detail->reason == KMSG_DUMP_PANIC)
>   		draw_panic_plane(plane);
>   }
>   
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index 9c452bfbd571..7a35c82976e0 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -207,13 +207,13 @@ static int hv_die_panic_notify_crash(struct notifier_block *self,
>    * buffer and call into Hyper-V to transfer the data.
>    */
>   static void hv_kmsg_dump(struct kmsg_dumper *dumper,
> -			 enum kmsg_dump_reason reason)
> +			 struct kmsg_dump_detail *detail)
>   {
>   	struct kmsg_dump_iter iter;
>   	size_t bytes_written;
>   
>   	/* We are only interested in panics. */
> -	if (reason != KMSG_DUMP_PANIC || !sysctl_record_panic_msg)
> +	if (detail->reason != KMSG_DUMP_PANIC || !sysctl_record_panic_msg)
>   		return;
>   
>   	/*
> diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
> index 2f11585b5613..86d49db9196d 100644
> --- a/drivers/mtd/mtdoops.c
> +++ b/drivers/mtd/mtdoops.c
> @@ -298,7 +298,7 @@ static void find_next_position(struct mtdoops_context *cxt)
>   }
>   
>   static void mtdoops_do_dump(struct kmsg_dumper *dumper,
> -			    enum kmsg_dump_reason reason)
> +			    struct kmsg_dump_detail *detail)
>   {
>   	struct mtdoops_context *cxt = container_of(dumper,
>   			struct mtdoops_context, dump);
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index 3497ede88aa0..9c6b7c97fa3c 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -275,7 +275,7 @@ void pstore_record_init(struct pstore_record *record,
>    * end of the buffer.
>    */
>   static void pstore_dump(struct kmsg_dumper *dumper,
> -			enum kmsg_dump_reason reason)
> +			struct kmsg_dump_detail *detail)
>   {
>   	struct kmsg_dump_iter iter;
>   	unsigned long	total = 0;
> @@ -285,9 +285,9 @@ static void pstore_dump(struct kmsg_dumper *dumper,
>   	int		saved_ret = 0;
>   	int		ret;
>   
> -	why = kmsg_dump_reason_str(reason);
> +	why = kmsg_dump_reason_str(detail->reason);
>   
> -	if (pstore_cannot_block_path(reason)) {
> +	if (pstore_cannot_block_path(detail->reason)) {
>   		if (!spin_trylock_irqsave(&psinfo->buf_lock, flags)) {
>   			pr_err("dump skipped in %s path because of concurrent dump\n",
>   					in_nmi() ? "NMI" : why);
> @@ -311,7 +311,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
>   		pstore_record_init(&record, psinfo);
>   		record.type = PSTORE_TYPE_DMESG;
>   		record.count = oopscount;
> -		record.reason = reason;
> +		record.reason = detail->reason;
>   		record.part = part;
>   		record.buf = psinfo->buf;
>   
> @@ -352,7 +352,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
>   		}
>   
>   		ret = psinfo->write(&record);
> -		if (ret == 0 && reason == KMSG_DUMP_OOPS) {
> +		if (ret == 0 && detail->reason == KMSG_DUMP_OOPS) {
>   			pstore_new_entry = 1;
>   			pstore_timer_kick();
>   		} else {
> diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h
> index 906521c2329c..65f5a47727bc 100644
> --- a/include/linux/kmsg_dump.h
> +++ b/include/linux/kmsg_dump.h
> @@ -39,6 +39,17 @@ struct kmsg_dump_iter {
>   	u64	next_seq;
>   };
>   
> +/**
> + *struct kmsg_dump_detail - kernel crash detail
> + * @reason: reason for the crash, see kmsg_dump_reason.
> + * @description: optional short string, to provide additional information.
> + */
> +
> +struct kmsg_dump_detail {
> +	enum kmsg_dump_reason reason;
> +	const char *description;
> +};
> +
>   /**
>    * struct kmsg_dumper - kernel crash message dumper structure
>    * @list:	Entry in the dumper list (private)
> @@ -49,13 +60,13 @@ struct kmsg_dump_iter {
>    */
>   struct kmsg_dumper {
>   	struct list_head list;
> -	void (*dump)(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason);
> +	void (*dump)(struct kmsg_dumper *dumper, struct kmsg_dump_detail *detail);
>   	enum kmsg_dump_reason max_reason;
>   	bool registered;
>   };
>   
>   #ifdef CONFIG_PRINTK
> -void kmsg_dump(enum kmsg_dump_reason reason);
> +void kmsg_dump_desc(enum kmsg_dump_reason reason, const char *desc);
>   
>   bool kmsg_dump_get_line(struct kmsg_dump_iter *iter, bool syslog,
>   			char *line, size_t size, size_t *len);
> @@ -71,7 +82,7 @@ int kmsg_dump_unregister(struct kmsg_dumper *dumper);
>   
>   const char *kmsg_dump_reason_str(enum kmsg_dump_reason reason);
>   #else
> -static inline void kmsg_dump(enum kmsg_dump_reason reason)
> +static inline void kmsg_dump_desc(enum kmsg_dump_reason reason, const char *desc)
>   {
>   }
>   
> @@ -107,4 +118,9 @@ static inline const char *kmsg_dump_reason_str(enum kmsg_dump_reason reason)
>   }
>   #endif
>   
> +static inline void kmsg_dump(enum kmsg_dump_reason reason)
> +{
> +	kmsg_dump_desc(reason, NULL);
> +}
> +
>   #endif /* _LINUX_KMSG_DUMP_H */
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 0843a275531a..0a8b29c44f3c 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -378,7 +378,7 @@ void panic(const char *fmt, ...)
>   
>   	panic_print_sys_info(false);
>   
> -	kmsg_dump(KMSG_DUMP_PANIC);
> +	kmsg_dump_desc(KMSG_DUMP_PANIC, buf);
>   
>   	/*
>   	 * If you doubt kdump always works fine in any situation,
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 5dcc05e1aa56..19bc414be5f0 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -4272,16 +4272,21 @@ const char *kmsg_dump_reason_str(enum kmsg_dump_reason reason)
>   EXPORT_SYMBOL_GPL(kmsg_dump_reason_str);
>   
>   /**
> - * kmsg_dump - dump kernel log to kernel message dumpers.
> + * kmsg_dump_desc - dump kernel log to kernel message dumpers.
>    * @reason: the reason (oops, panic etc) for dumping
> + * @desc: a short string to describe what caused the panic or oops. Can be NULL
> + * if no additional description is available.
>    *
>    * Call each of the registered dumper's dump() callback, which can
>    * retrieve the kmsg records with kmsg_dump_get_line() or
>    * kmsg_dump_get_buffer().
>    */
> -void kmsg_dump(enum kmsg_dump_reason reason)
> +void kmsg_dump_desc(enum kmsg_dump_reason reason, const char *desc)
>   {
>   	struct kmsg_dumper *dumper;
> +	struct kmsg_dump_detail detail = {
> +		.reason = reason,
> +		.description = desc};
>   
>   	rcu_read_lock();
>   	list_for_each_entry_rcu(dumper, &dump_list, list) {
> @@ -4299,7 +4304,7 @@ void kmsg_dump(enum kmsg_dump_reason reason)
>   			continue;
>   
>   		/* invoke dumper which will iterate over records */
> -		dumper->dump(dumper, reason);
> +		dumper->dump(dumper, &detail);
>   	}
>   	rcu_read_unlock();
>   }
> 
> base-commit: 82e4255305c554b0bb18b7ccf2db86041b4c8b6e

Gentle ping, I need reviews from powerpc, usermod linux, mtd, pstore and 
hyperv, to be able to push it in the drm-misc tree.

Best regards,

-- 

Jocelyn


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

^ permalink raw reply

* Re: [PATCH v3 00/15] mtd: spi-nor: macronix: workaround for device id re-use
From: Michael Walle @ 2024-07-12  9:55 UTC (permalink / raw)
  To: Esben Haabendal, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>


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

Hi,

On Thu Jul 11, 2024 at 3:00 PM CEST, Esben Haabendal wrote:
> As a consequence, the SPI_NOR_SKIP_SFDP flag is no more, and all
> drivers that have been doing optional SFDP is now marked explicitly to
> do that using the SPI_NOR_TRY_SFDP.

First, I haven't looked at your patchset at the moment. But I'd like
to take the opportunity to discuss the following (and excuse me that
I didn't had this idea before all your work on this).

First, I'd like to see it the other way around, that is, doing SFDP
by default and let the driver opt-out instead of opt-in. This will
also align with the current "SFDP only driver", i.e. if a flash is
not known we try SFDP anyway. Going forward, I'd say this is also
the sane behavior and we don't have to add any flags if someone want
to add support for an (older) flash with the same ID but without
SFDP. With the current approach, we'd have to add the TRY_SFDP flag.

Now we might play it safe and add that SPI_NOR_SKIP_SFDP to any
flash which doesn't do the SFDP parsing (because it has size != 0
and not any of the magic flags set) - or we might just go ahead and
do the probing first for *any* flashes. Yes we might issue an
unsupported opcode, but we already do that with the generic SFDP
flash driver. So no big deal maybe (?). Vendors where we know for a
fact that they don't have any SFDP (Everspin I'm looking at you),
would of course set the SKIP_SFDP flag.

-michael

[-- 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/

^ permalink raw reply

* Re: [PATCH v3 15/15] mtd: spi-nor: spansion: Drop redundant SPI_NOR_SKIP_SFDP flag
From: Esben Haabendal @ 2024-07-12  9:26 UTC (permalink / raw)
  To: Tudor Ambarus
  Cc: Pratyush Yadav, Michael Walle, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Nicolas Ferre, Alexandre Belloni,
	Claudiu Beznea, linux-mtd, linux-kernel, Rasmus Villemoes,
	linux-arm-kernel
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-15-99353461dd2d@geanix.com>

Esben Haabendal <esben@geanix.com> writes:

> With the implementation of SPI_NOR_TRY_SFDP flag, the removal of the
> deprecated mechanism for trying SFDP parsing, and the alignment of
> ->default_init() hooks handling, the SPI_NOR_SKIP_SFDP flag has become a
> no-op, so it can safely be removed.
>
> Signed-off-by: Esben Haabendal <esben@geanix.com>

Should I split this into a commit for the spansion change, and one for
the core change?

/Esben

> ---
>  drivers/mtd/spi-nor/core.c     | 2 +-
>  drivers/mtd/spi-nor/core.h     | 5 +----
>  drivers/mtd/spi-nor/spansion.c | 2 +-
>  3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index d58f107f62ec..518b2707ce80 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3024,7 +3024,7 @@ static int spi_nor_init_params(struct spi_nor *nor)
>  	if (spi_nor_needs_sfdp(nor)) {
>  		ret = spi_nor_parse_sfdp(nor);
>  		if (ret) {
> -			dev_err(nor->dev, "BFPT parsing failed. Please consider using SPI_NOR_SKIP_SFDP or SPI_NOR_TRY_SFDP when declaring the flash\n");
> +			dev_err(nor->dev, "BFPT parsing failed. Please consider using SPI_NOR_TRY_SFDP when declaring the flash\n");
>  			return ret;
>  		}
>  	} else {
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index f4a76f42051a..ae10e12e9078 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -485,9 +485,7 @@ struct spi_nor_id {
>   *
>   * @no_sfdp_flags:  flags that indicate support that can be discovered via SFDP.
>   *                  Used when SFDP tables are not defined in the flash. These
> - *                  flags are used together with the SPI_NOR_SKIP_SFDP or
> - *                  SPI_NOR_TRY_SFDP flag.
> - *   SPI_NOR_SKIP_SFDP:       skip parsing of SFDP tables.
> + *                  flags are used together with the SPI_NOR_TRY_SFDP flag.
>   *   SECT_4K:                 SPINOR_OP_BE_4K works uniformly.
>   *   SPI_NOR_TRY_SFDP:        try parsing SFDP tables before using the
>   *                            parameters specified in this struct.
> @@ -536,7 +534,6 @@ struct flash_info {
>  #define SPI_NOR_RWW			BIT(9)
>  
>  	u8 no_sfdp_flags;
> -#define SPI_NOR_SKIP_SFDP		BIT(0)
>  #define SECT_4K				BIT(1)
>  #define SPI_NOR_TRY_SFDP		BIT(2)
>  #define SPI_NOR_DUAL_READ		BIT(3)
> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
> index a58c0229003d..afcb684ffe4d 100644
> --- a/drivers/mtd/spi-nor/spansion.c
> +++ b/drivers/mtd/spi-nor/spansion.c
> @@ -793,7 +793,7 @@ static const struct flash_info spansion_nor_parts[] = {
>  		.name = "s25fl256s0",
>  		.size = SZ_32M,
>  		.sector_size = SZ_256K,
> -		.no_sfdp_flags = SPI_NOR_SKIP_SFDP | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
> +		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
>  		.mfr_flags = USE_CLSR,
>  	}, {
>  		.id = SNOR_ID(0x01, 0x02, 0x19, 0x4d, 0x00, 0x81),

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

^ permalink raw reply

* Re: [PATCH v3 14/15] mtd: spi-nor: Drop deprecated mechanism for optional SFDP parsing
From: Esben Haabendal @ 2024-07-12  9:23 UTC (permalink / raw)
  To: Tudor Ambarus
  Cc: Pratyush Yadav, Michael Walle, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Nicolas Ferre, Alexandre Belloni,
	Claudiu Beznea, linux-mtd, linux-kernel, Rasmus Villemoes,
	linux-arm-kernel
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-14-99353461dd2d@geanix.com>

Esben Haabendal <esben@geanix.com> writes:

> With all drivers converted to the new SPI_NOR_TRY_SFDP flag, we can remove
> the old deprecated mechanism for triggering optional SFDP parsing.
>
> New flashes must use SPI_NOR_TRY_SFDP to get this behavior. Hopefully, all
> new drivers will be fore pure SFDP flashes, so no or at least very few new
> users of this flag is expected.
>
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> ---
>  drivers/mtd/spi-nor/core.h | 19 +------------------
>  1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index dfc81716e068..f4a76f42051a 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -719,24 +719,7 @@ static inline bool spi_nor_needs_sfdp(const struct spi_nor *nor)
>   */
>  static inline bool spi_nor_try_sfdp(const struct spi_nor *nor)
>  {
> -	if (nor->info->no_sfdp_flags & SPI_NOR_SKIP_SFDP)
> -		return false;
> -	if (nor->info->no_sfdp_flags & SPI_NOR_TRY_SFDP)
> -		return true;
> -
> -	/* Deprecated/legacy way for triggering optional SFDP parsing.
> -	 * If one of the no_sfdp_flags indicating dual, quad or octal read is
> -	 * set, SFDP parsing will be tried.
> -	 * When all drivers have been converted to set SPI_NOR_TRY_SFDP where
> -	 * needed, this deprecated mechanism can be removed.
> -	 */
> -	if (nor->info->no_sfdp_flags & (SPI_NOR_DUAL_READ |
> -					SPI_NOR_QUAD_READ |
> -					SPI_NOR_OCTAL_READ |
> -					SPI_NOR_OCTAL_DTR_READ))
> -		return true;
> -
> -	return false;
> +	return (nor->info->no_sfdp_flags & SPI_NOR_TRY_SFDP)

Sorry. Bad cherry-pick here. Due to other reasons, I am testing out of
tree :(  The missing semicolon will be added in v4.

I assume we can still discuss the idea here in this version.

/Esben

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

^ permalink raw reply

* Re: [PATCH v3 14/15] mtd: spi-nor: Drop deprecated mechanism for optional SFDP parsing
From: kernel test robot @ 2024-07-12  8:33 UTC (permalink / raw)
  To: Esben Haabendal, Tudor Ambarus, Pratyush Yadav, Michael Walle,
	Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Nicolas Ferre, Alexandre Belloni, Claudiu Beznea
  Cc: llvm, oe-kbuild-all, linux-mtd, linux-kernel, Rasmus Villemoes,
	linux-arm-kernel, Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-14-99353461dd2d@geanix.com>

Hi Esben,

kernel test robot noticed the following build errors:

[auto build test ERROR on a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6]

url:    https://github.com/intel-lab-lkp/linux/commits/Esben-Haabendal/mtd-spi-nor-core-add-flag-for-doing-optional-SFDP-parsing/20240711-224454
base:   a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
patch link:    https://lore.kernel.org/r/20240711-macronix-mx25l3205d-fixups-v3-14-99353461dd2d%40geanix.com
patch subject: [PATCH v3 14/15] mtd: spi-nor: Drop deprecated mechanism for optional SFDP parsing
config: s390-allmodconfig (https://download.01.org/0day-ci/archive/20240712/202407121629.O2ykn94e-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project a0c6b8aef853eedaa0980f07c0a502a5a8a9740e)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240712/202407121629.O2ykn94e-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202407121629.O2ykn94e-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/mtd/spi-nor/core.c:13:
   In file included from include/linux/device.h:32:
   In file included from include/linux/device/driver.h:21:
   In file included from include/linux/module.h:19:
   In file included from include/linux/elf.h:6:
   In file included from arch/s390/include/asm/elf.h:173:
   In file included from arch/s390/include/asm/mmu_context.h:11:
   In file included from arch/s390/include/asm/pgalloc.h:18:
   In file included from include/linux/mm.h:2210:
   include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
     508 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
         |                            ~~~~~~~~~~~~~~~~~~~~~ ^
     509 |                            item];
         |                            ~~~~
   include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
     515 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
         |                            ~~~~~~~~~~~~~~~~~~~~~ ^
     516 |                            NR_VM_NUMA_EVENT_ITEMS +
         |                            ~~~~~~~~~~~~~~~~~~~~~~
   include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
     522 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
         |                               ~~~~~~~~~~~ ^ ~~~
   include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
     527 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
         |                            ~~~~~~~~~~~~~~~~~~~~~ ^
     528 |                            NR_VM_NUMA_EVENT_ITEMS +
         |                            ~~~~~~~~~~~~~~~~~~~~~~
   include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
     536 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
         |                            ~~~~~~~~~~~~~~~~~~~~~ ^
     537 |                            NR_VM_NUMA_EVENT_ITEMS +
         |                            ~~~~~~~~~~~~~~~~~~~~~~
   In file included from drivers/mtd/spi-nor/core.c:17:
   In file included from include/linux/mtd/spi-nor.h:11:
   In file included from include/linux/spi/spi-mem.h:14:
   In file included from include/linux/spi/spi.h:17:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/s390/include/asm/io.h:78:
   include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     547 |         val = __raw_readb(PCI_IOBASE + addr);
         |                           ~~~~~~~~~~ ^
   include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     560 |         val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
         |                                                         ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro '__le16_to_cpu'
      37 | #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
         |                                                           ^
   include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16'
     102 | #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
         |                                                      ^
   In file included from drivers/mtd/spi-nor/core.c:17:
   In file included from include/linux/mtd/spi-nor.h:11:
   In file included from include/linux/spi/spi-mem.h:14:
   In file included from include/linux/spi/spi.h:17:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/s390/include/asm/io.h:78:
   include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     573 |         val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
         |                                                         ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/big_endian.h:35:59: note: expanded from macro '__le32_to_cpu'
      35 | #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
         |                                                           ^
   include/uapi/linux/swab.h:115:54: note: expanded from macro '__swab32'
     115 | #define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
         |                                                      ^
   In file included from drivers/mtd/spi-nor/core.c:17:
   In file included from include/linux/mtd/spi-nor.h:11:
   In file included from include/linux/spi/spi-mem.h:14:
   In file included from include/linux/spi/spi.h:17:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/s390/include/asm/io.h:78:
   include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     584 |         __raw_writeb(value, PCI_IOBASE + addr);
         |                             ~~~~~~~~~~ ^
   include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     594 |         __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
         |                                                       ~~~~~~~~~~ ^
   include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     604 |         __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
         |                                                       ~~~~~~~~~~ ^
   include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     692 |         readsb(PCI_IOBASE + addr, buffer, count);
         |                ~~~~~~~~~~ ^
   include/asm-generic/io.h:700:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     700 |         readsw(PCI_IOBASE + addr, buffer, count);
         |                ~~~~~~~~~~ ^
   include/asm-generic/io.h:708:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     708 |         readsl(PCI_IOBASE + addr, buffer, count);
         |                ~~~~~~~~~~ ^
   include/asm-generic/io.h:717:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     717 |         writesb(PCI_IOBASE + addr, buffer, count);
         |                 ~~~~~~~~~~ ^
   include/asm-generic/io.h:726:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     726 |         writesw(PCI_IOBASE + addr, buffer, count);
         |                 ~~~~~~~~~~ ^
   include/asm-generic/io.h:735:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     735 |         writesl(PCI_IOBASE + addr, buffer, count);
         |                 ~~~~~~~~~~ ^
   In file included from drivers/mtd/spi-nor/core.c:25:
>> drivers/mtd/spi-nor/core.h:722:54: error: expected ';' after return statement
     722 |         return (nor->info->no_sfdp_flags & SPI_NOR_TRY_SFDP)
         |                                                             ^
         |                                                             ;
   17 warnings and 1 error generated.


vim +722 drivers/mtd/spi-nor/core.h

   712	
   713	/**
   714	 * spi_nor_try_sfdp() - returns true if optional SFDP parsing should be tried
   715	 * for this flash, with fallback to static parameters and settings based on
   716	 * flash ID if SFDP parsing fails.
   717	 *
   718	 * Return: true if optional SFDP parsing should be tried
   719	 */
   720	static inline bool spi_nor_try_sfdp(const struct spi_nor *nor)
   721	{
 > 722		return (nor->info->no_sfdp_flags & SPI_NOR_TRY_SFDP)
   723	}
   724	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

^ permalink raw reply

* Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
From: Esben Haabendal @ 2024-07-12  8:20 UTC (permalink / raw)
  To: Erez
  Cc: Michael Walle, Tudor Ambarus, Jaime Liao, leoyu, Alvin Zhou,
	Julien Su, Erez Geva, linux-mtd, Pratyush Yadav, linux-kernel,
	Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <CANeKEMNtXb4ZV7kcLbHY+Mti6dPV9UZ2wTyUq5z0qtmtNNqSVA@mail.gmail.com>

Erez <erezgeva2@gmail.com> writes:

> On Thu, 11 Jul 2024 at 21:57, Michael Walle <mwalle@kernel.org> wrote:
>> On Thu Jul 11, 2024 at 8:57 PM CEST, Erez wrote:
>> > Yes, I think we should.
>> >
>> > Reading the specification provided publicly by Macronix.
>> > For all the JEDEC IDs with the no SFDP flag in drivers/mtd/spi-nor/macronix.c
>> > All of them have a new version or a new chip with the same JEDEC ID
>> > that supports SFDP.
>> > There are 2 chips that Macronix does not provide spec. in public.
>> > I can ask Macronix technical support on these 2 chips.
>>
>> We don't add flashes we cannot test.
>
> I did not suggest adding anything new.
> I refer to the list of chips we already have in drivers/mtd/spi-nor/macronix.c
> I presume someone tested them before adding them to the list in the past.
> And probably the old chip did not have the SFDP table back then.
>
> What I checked with the chip specifications is that all Macronix chips
> since 2010 have SFDP.
>
> The situation today is that all Macronix chips that are NOT in the
> Macronix table work based on the SFDP table.
> But new chips that use a JEDEC found in the Macronix table, skip the
> SFDP table and use the setting of the old chip.

Not entirely true.

Those that entries in the Macronix table that has SPI_NOR_DUAL_READ
and/or SPI_NOR_QUAD_READ in no_sfdp_flags is caught by
the magic flags matching in spi_nor_init_params_deprecated() and will
have spi_nor_parse_sfdp() called from
spi_nor_sfdp_init_params_deprecated(). So flashes reusing ID for these
will have the SFDP tables parsed.

The rest of the entries in the Macronix table is not so lucky. When a
replacement chip (with the same ID) is used, it will not be configured
with the values found in SFDP table.

> So I suggest we read the SFDP table for all Macronix chips.

Based on their strategy of re-using flash ID, I think this is a sane
approach.

> Old Macronix chips that do not have SFDP will use the setting from the
> Macronix table. i.e backward compatible.
> While new chips which do have an SFDP table will work with the new
> setting we find in the table.

Yes, if we apply the new SPI_NOR_TRY_SFDP flag to the matching table
entries.

> Of course, we might have issues in parsing the SFDP table itself.
> So we fix them as developers report and send chip ID and part number
> with the SFDP table content.
> I do not see the point of "hiding" with the old setting.
> Anyhow, as we do not like the IDs table and keep it for backward-compatible,
> so it only makes sense we should use the SFDP table as much as possible.
>
> My check was to ensure Tudor that all Macronix chips have SFDP whether
> they are in the IDs table or not and we are not wasting a no-op on a
> chip which can not have an SFDP table.
>
> All I suggest is we add the new 'SPI_NOR_TRY_SFDP' flag, to all
> Macronix chips.. Which will try to read the SFDP to any Macronix chip.

Makes sense. But obviously comes with a risk as we won't be able to
test all chips for regression when doing that.

/Esben

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

^ permalink raw reply

* Re: [PATCH 0/2] ubifs: Fix deadlock between inode reclaiming and host inode writing
From: Zhihao Cheng @ 2024-07-12  6:40 UTC (permalink / raw)
  To: richard; +Cc: linux-mtd
In-Reply-To: <20240710022628.1227996-1-chengzhihao1@huawei.com>

在 2024/7/10 10:26, Zhihao Cheng 写道:
> Patch 1 optimizes logic process in function ubifs_jnl_write_inode().
> Patch 2 fixes an ABBA deadlock problem based on the process by applying
> patch 1.
> 
> Zhihao Cheng (2):
>    ubifs: ubifs_jnl_write_inode: Only check once for the limitation of
>      xattr count
>    ubifs: Fix ABBA deadlock between inode reclaiming and deleted inode
>      writing
> 
>   fs/ubifs/journal.c | 106 ++++++++++++++++++++++++++++-----------------
>   1 file changed, 66 insertions(+), 40 deletions(-)
> 

Please ignore this series of patches, the v2 version can be found here:
[1] 
https://lore.kernel.org/linux-mtd/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/T/#u
[2] 
https://lore.kernel.org/linux-mtd/20240712063625.3363974-1-chengzhihao1@huawei.com/T/#t

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

^ permalink raw reply

* [PATCH 0/2] ubifs: Two cleanups for xattr handling in host inode evicting process
From: Zhihao Cheng @ 2024-07-12  6:36 UTC (permalink / raw)
  To: richard; +Cc: linux-mtd

Zhihao Cheng (2):
  ubifs: ubifs_jnl_write_inode: Only check once for the limitation of
    xattr count
  ubifs: Remove ineffective function ubifs_evict_xattr_inode()

 fs/ubifs/journal.c | 12 ++++++------
 fs/ubifs/tnc.c     |  2 --
 fs/ubifs/ubifs.h   |  3 ---
 fs/ubifs/xattr.c   | 22 ----------------------
 4 files changed, 6 insertions(+), 33 deletions(-)

-- 
2.39.2


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

^ permalink raw reply

* [PATCH 2/2] ubifs: Remove ineffective function ubifs_evict_xattr_inode()
From: Zhihao Cheng @ 2024-07-12  6:36 UTC (permalink / raw)
  To: richard; +Cc: linux-mtd
In-Reply-To: <20240712063625.3363974-1-chengzhihao1@huawei.com>

Function ubifs_evict_xattr_inode() is imported by commit 272eda8298dc
("ubifs: Correctly evict xattr inodes") to reclaim xattr inode when
the host inode is deleted.
The xattr inode is evicted in the host inode deleting process since
commit 7959cf3a7506 ("ubifs: journal: Handle xattrs like files").
So the ineffective function ubifs_evict_xattr_inode() can be deleted
safely.

Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
---
 fs/ubifs/tnc.c   |  2 --
 fs/ubifs/ubifs.h |  3 ---
 fs/ubifs/xattr.c | 22 ----------------------
 3 files changed, 27 deletions(-)

diff --git a/fs/ubifs/tnc.c b/fs/ubifs/tnc.c
index 0fabecd9d379..8f38e33eb928 100644
--- a/fs/ubifs/tnc.c
+++ b/fs/ubifs/tnc.c
@@ -2905,8 +2905,6 @@ int ubifs_tnc_remove_ino(struct ubifs_info *c, ino_t inum)
 		dbg_tnc("xent '%s', ino %lu", xent->name,
 			(unsigned long)xattr_inum);
 
-		ubifs_evict_xattr_inode(c, xattr_inum);
-
 		fname_name(&nm) = xent->name;
 		fname_len(&nm) = le16_to_cpu(xent->nlen);
 		err = ubifs_tnc_remove_nm(c, &key1, &nm);
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 12216a159227..84dd7900d3f0 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -2049,13 +2049,10 @@ ssize_t ubifs_xattr_get(struct inode *host, const char *name, void *buf,
 #ifdef CONFIG_UBIFS_FS_XATTR
 extern const struct xattr_handler * const ubifs_xattr_handlers[];
 ssize_t ubifs_listxattr(struct dentry *dentry, char *buffer, size_t size);
-void ubifs_evict_xattr_inode(struct ubifs_info *c, ino_t xattr_inum);
 int ubifs_purge_xattrs(struct inode *host);
 #else
 #define ubifs_listxattr NULL
 #define ubifs_xattr_handlers NULL
-static inline void ubifs_evict_xattr_inode(struct ubifs_info *c,
-					   ino_t xattr_inum) { }
 static inline int ubifs_purge_xattrs(struct inode *host)
 {
 	return 0;
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index f734588b224a..c673fd03d9b4 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -570,28 +570,6 @@ int ubifs_purge_xattrs(struct inode *host)
 	return err;
 }
 
-/**
- * ubifs_evict_xattr_inode - Evict an xattr inode.
- * @c: UBIFS file-system description object
- * @xattr_inum: xattr inode number
- *
- * When an inode that hosts xattrs is being removed we have to make sure
- * that cached inodes of the xattrs also get removed from the inode cache
- * otherwise we'd waste memory. This function looks up an inode from the
- * inode cache and clears the link counter such that iput() will evict
- * the inode.
- */
-void ubifs_evict_xattr_inode(struct ubifs_info *c, ino_t xattr_inum)
-{
-	struct inode *inode;
-
-	inode = ilookup(c->vfs_sb, xattr_inum);
-	if (inode) {
-		clear_nlink(inode);
-		iput(inode);
-	}
-}
-
 static int ubifs_xattr_remove(struct inode *host, const char *name)
 {
 	struct inode *inode;
-- 
2.39.2


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

^ permalink raw reply related

* [PATCH 1/2] ubifs: ubifs_jnl_write_inode: Only check once for the limitation of xattr count
From: Zhihao Cheng @ 2024-07-12  6:36 UTC (permalink / raw)
  To: richard; +Cc: linux-mtd
In-Reply-To: <20240712063625.3363974-1-chengzhihao1@huawei.com>

No need to check the limitation of xattr count every time in function
ubifs_jnl_write_inode(), because the 'ui->xattr_cnt' won't be modified
by others in the inode evicting process.

Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
---
 fs/ubifs/journal.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
index 4a35f9e8f668..8e98be642371 100644
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -981,6 +981,12 @@ int ubifs_jnl_write_inode(struct ubifs_info *c, const struct inode *inode)
 
 	dbg_jnl("ino %lu, nlink %u", inode->i_ino, inode->i_nlink);
 
+	if (kill_xattrs && ui->xattr_cnt > ubifs_xattr_max_cnt(c)) {
+		ubifs_err(c, "Cannot delete inode, it has too much xattrs!");
+		ubifs_ro_mode(c, err);
+		return -EPERM;
+	}
+
 	/*
 	 * If the inode is being deleted, do not write the attached data. No
 	 * need to synchronize the write-buffer either.
@@ -1012,12 +1018,6 @@ int ubifs_jnl_write_inode(struct ubifs_info *c, const struct inode *inode)
 		struct inode *xino;
 		struct ubifs_dent_node *xent, *pxent = NULL;
 
-		if (ui->xattr_cnt > ubifs_xattr_max_cnt(c)) {
-			err = -EPERM;
-			ubifs_err(c, "Cannot delete inode, it has too much xattrs!");
-			goto out_release;
-		}
-
 		lowest_xent_key(c, &key, inode->i_ino);
 		while (1) {
 			xent = ubifs_tnc_next_ent(c, &key, &nm);
-- 
2.39.2


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

^ permalink raw reply related

* [BUG REPORT] potential deadlock in inode evicting under the inode lru traversing context on ext4 and ubifs
From: Zhihao Cheng @ 2024-07-12  6:27 UTC (permalink / raw)
  To: linux-fsdevel, linux-ext4, LKML, Ted Tso, Jan Kara,
	Christoph Hellwig, linux-mtd, Richard Weinberger, zhangyi (F),
	yangerkun, wangzhaolong (A)

Hi. Recently, we found a deadlock in inode recliaiming process caused by 
circular dependence between file inode and file's xattr inode.

Problem description
===================

The inode reclaiming process(See function prune_icache_sb) collects all 
reclaimable inodes and mark them with I_FREEING flag at first, at that 
time, other processes will be stuck if they try getting these inodes(See 
function find_inode_fast), then the reclaiming process destroy the 
inodes by function dispose_list().
Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may 
do inode lookup in the inode evicting callback function, if the inode 
lookup is operated under the inode lru traversing context, deadlock 
problems may happen.

Case 1: In function ext4_evict_inode(), the ea inode lookup could happen 
if ea_inode feature is enabled, the lookup process will be stuck under 
the evicting context like this:

  1. File A has inode i_reg and an ea inode i_ea
  2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
  3. Then, following three processes running like this:

     PA                              PB
  echo 2 > /proc/sys/vm/drop_caches
   shrink_slab
    prune_dcache_sb
    // i_reg is added into lru, lru->i_ea->i_reg
    prune_icache_sb
     list_lru_walk_one
      inode_lru_isolate
       i_ea->i_state |= I_FREEING // set inode state
      inode_lru_isolate
       __iget(i_reg)
       spin_unlock(&i_reg->i_lock)
       spin_unlock(lru_lock)
                                      rm file A
                                       i_reg->nlink = 0
       iput(i_reg) // i_reg->nlink is 0, do evict
        ext4_evict_inode
         ext4_xattr_delete_inode
          ext4_xattr_inode_dec_ref_all
       ext4_xattr_inode_iget
            ext4_iget(i_ea->i_ino)
             iget_locked
              find_inode_fast
               __wait_on_freeing_inode(i_ea) ----→ AA deadlock
     dispose_list // cannot be executed by prune_icache_sb
      wake_up_bit(&i_ea->i_state)

Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file 
deleting process holds BASEHD's wbuf->io_mutex while getting the xattr 
inode, which could race with inode reclaiming process(The reclaiming 
process could try locking BASEHD's wbuf->io_mutex in inode evicting 
function), then an ABBA deadlock problem would happen as following:

  1. File A has inode ia and a xattr(with inode ixa), regular file B has
     inode ib and a xattr.
  2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
  3. Then, following three processes running like this:

         PA                PB                        PC
                 echo 2 > /proc/sys/vm/drop_caches
                  shrink_slab
           prune_dcache_sb
           // ib and ia are added into lru, lru->ixa->ib->ia
                   prune_icache_sb
                    list_lru_walk_one
                     inode_lru_isolate
                      ixa->i_state |= I_FREEING // set inode state
                     inode_lru_isolate
                      __iget(ib)
                      spin_unlock(&ib->i_lock)
                      spin_unlock(lru_lock)
                                                    rm file B
                                                     ib->nlink = 0
  rm file A
   iput(ia)
    ubifs_evict_inode(ia)
     ubifs_jnl_delete_inode(ia)
      ubifs_jnl_write_inode(ia)
       make_reservation(BASEHD) // Lock wbuf->io_mutex
       ubifs_iget(ixa->i_ino)
        iget_locked
         find_inode_fast
          __wait_on_freeing_inode(ixa)
           |          iput(ib) // ib->nlink is 0, do evict
           |           ubifs_evict_inode
           |            ubifs_jnl_delete_inode(ib)
          ↓             ubifs_jnl_write_inode
      ABBA deadlock ←-----make_reservation(BASEHD)
                    dispose_list // cannot be executed by prune_icache_sb
                     wake_up_bit(&ixa->i_state)

Reproducer:
===========

https://bugzilla.kernel.org/show_bug.cgi?id=219022

About solutions
===============

We have thought some solutions, but all of them will import new influence.

Solution 1: Don't cache xattr inode, make drop_inode callback return 
true for xattr inode. It will make getting xattr slower.
Test code:
     gettimeofday(&s, NULL);
     for (i = 0; i < 10000; ++i)
         if (getxattr("/root/temp/file_a", "user.a", buf, 4098) < 0)
             perror("getxattr");
     gettimeofday(&e, NULL);
     printf("cost %ld us\n", 1000000 * (e.tv_sec - s.tv_sec) + e.tv_usec 
- s.tv_usec);
Result:
ext4:
cost 151068 us // without fix
cost 321594 us // with fix
ubifs:
134125 us // without fix
371023 us // with fix

Solution 2: Don't put xattr inode into lru, which is implemented by 
holding xattr inode's refcnt until the file inode is evicted, besides 
that, make drop_inode callback return true for xattr inode. The solution 
pins xattr inode in memory until the file inode is evicted, file inode 
won't be evicted if it has pagecahes, specifically:
inode_lru_isolate
  if (inode_has_buffers(inode) || !mapping_empty(&inode->i_data)) { // 
file inode won't be evicted, so its' xattr inode won't be reclaimed too, 
which will increase the memory noise.
   __iget(inode);
   if (remove_inode_buffers(inode))
   ...
   iput(inode);
  }

Solution 3: Forbid inode evicting under the inode lru traversing 
context. Specifically, mark inode with 'I_FREEING' instead of getting 
its' refcnt to eliminate the inode getting chance in 
inode_lru_isolate(). The solution is wrong, because the pagecahes may 
still alive after invalidate_mapping_pages(), so we cannot destroy the 
file inode after clearing I_WILL_FREE.
diff --git a/fs/inode.c b/fs/inode.c
index 3a41f83a4ba5..c649be22f841 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -843,7 +844,7 @@ static enum lru_status inode_lru_isolate(struct 
list_head *item,
       * be under pressure before the cache inside the highmem zone.
       */
      if (inode_has_buffers(inode) || !mapping_empty(&inode->i_data)) {
-        __iget(inode);
+        inode->i_state |= I_WILL_FREE;
          spin_unlock(&inode->i_lock);
          spin_unlock(lru_lock);
          if (remove_inode_buffers(inode)) {
@@ -855,9 +856,9 @@ static enum lru_status inode_lru_isolate(struct 
list_head *item,
                  __count_vm_events(PGINODESTEAL, reap);
              mm_account_reclaimed_pages(reap);
          }
-        iput(inode);
+        spin_lock(&inode->i_lock);
+        inode->i_state &= ~I_WILL_FREE;
          spin_lock(lru_lock);
-        return LRU_RETRY;
      }

Solution 4: Break the circular dependence between file inode and file's 
xattr inode, for example, after comparing 
inode_lru_isolate(prune_icache_sb) with invalidate_inodes, we found that 
invalidate_mapping_pages is not invoked by invalidate_inodes, can we 
directly remove the branch 'if (inode_has_buffers(inode) || 
!mapping_empty(&inode->i_data))' from inode_lru_isolate?

Any better solutions?


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

^ permalink raw reply related

* Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
From: Erez @ 2024-07-12  5:13 UTC (permalink / raw)
  To: Michael Walle
  Cc: Esben Haabendal, Tudor Ambarus, Jaime Liao, leoyu, Alvin Zhou,
	Julien Su, Erez Geva, linux-mtd, Pratyush Yadav, linux-kernel,
	Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <D2N20HB4BIC4.O13SZINCMJ9P@kernel.org>

On Fri, 12 Jul 2024 at 00:13, Michael Walle <mwalle@kernel.org> wrote:
>
> On Fri Jul 12, 2024 at 12:09 AM CEST, Erez wrote:
> > On Thu, 11 Jul 2024 at 21:57, Michael Walle <mwalle@kernel.org> wrote:
> > >
> > > Hi Erez,
> > >
> > > No top posting please, see also
> > > https://subspace.kernel.org/etiquette.html
> >
> > It was a single question. Which I think can be answered in one reply.
> > In cases where there are different parts in the mail, it makes sense
> > to avoid top posting.
> > I do not believe we need to be pedantic.
> > The guidance is not holy, it is aimed to make communication more comprehensive.
> >
> > >
> > > On Thu Jul 11, 2024 at 8:57 PM CEST, Erez wrote:
> > > > Yes, I think we should.
>
> Regarding top posting, what was the question here?
>
> I don't see any context. So don't expect any reply from me.

Fair point.
I'll try better next time and write more comprehen answers.
I do hope my reply on the second part was more informative.

Erez

>
> -michael

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

^ permalink raw reply

* [PATCH v2 1/1] mtd: slram: insert break after errors in parsing the map
From: Mirsad Todorovac @ 2024-07-11 23:43 UTC (permalink / raw)
  To: Mirsad Todorovac, linux-mtd, linux-kernel
  Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra

GCC 12.3.0 compiler on linux-next next-20240709 tree found the execution
path in which, due to lazy evaluation, devlength isn't initialised with the
parsed string:

   289		while (map) {
   290			devname = devstart = devlength = NULL;
   291
   292			if (!(devname = strsep(&map, ","))) {
   293				E("slram: No devicename specified.\n");
   294				break;
   295			}
   296			T("slram: devname = %s\n", devname);
   297			if ((!map) || (!(devstart = strsep(&map, ",")))) {
   298				E("slram: No devicestart specified.\n");
   299			}
   300			T("slram: devstart = %s\n", devstart);
 → 301			if ((!map) || (!(devlength = strsep(&map, ",")))) {
   302				E("slram: No devicelength / -end specified.\n");
   303			}
 → 304			T("slram: devlength = %s\n", devlength);
   305			if (parse_cmdline(devname, devstart, devlength) != 0) {
   306				return(-EINVAL);
   307			}

Parsing should be finished after map == NULL, so a break is best inserted after
each E("slram: ... \n") error message.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Mirsad Todorovac <mtodorovac69@gmail.com>
---
v1:
 initial patch proposal.

v2:
 re-sent using git send-email + oauth2 (fixing T-Bird TAB problem).

 drivers/mtd/devices/slram.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 28131a127d06..8297b366a066 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -296,10 +296,12 @@ static int __init init_slram(void)
 		T("slram: devname = %s\n", devname);
 		if ((!map) || (!(devstart = strsep(&map, ",")))) {
 			E("slram: No devicestart specified.\n");
+			break;
 		}
 		T("slram: devstart = %s\n", devstart);
 		if ((!map) || (!(devlength = strsep(&map, ",")))) {
 			E("slram: No devicelength / -end specified.\n");
+			break;
 		}
 		T("slram: devlength = %s\n", devlength);
 		if (parse_cmdline(devname, devstart, devlength) != 0) {
-- 
2.34.1


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

^ permalink raw reply related

* [PATCH v1 1/1] mtd: slram: insert break after errors in parsing the map
From: Mirsad Todorovac @ 2024-07-11 23:07 UTC (permalink / raw)
  To: linux-mtd
  Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Linux Kernel Mailing List

The GCC 12.3.0 compiler on linux-next next-20240709 tree found the execution
path in which, due to lazy evaluation, devlength isn't initialised with the
parsed string:

   289          while (map) {
   290                  devname = devstart = devlength = NULL;
   291
   292                  if (!(devname = strsep(&map, ","))) {
   293                          E("slram: No devicename specified.\n");
   294                          break;
   295                  }
   296                  T("slram: devname = %s\n", devname);
   297                  if ((!map) || (!(devstart = strsep(&map, ",")))) {
   298                          E("slram: No devicestart specified.\n");
   299                  }
   300                  T("slram: devstart = %s\n", devstart);
 → 301                  if ((!map) || (!(devlength = strsep(&map, ",")))) {
   302                          E("slram: No devicelength / -end specified.\n");
   303                  }
 → 304                  T("slram: devlength = %s\n", devlength);
   305                  if (parse_cmdline(devname, devstart, devlength) != 0) {
   306                          return(-EINVAL);
   307                  }

Parsing should be finished after map == NULL, so a break is best inserted after
each E("slram: ... \n") error message.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Mirsad Todorovac <mtodorovac69@gmail.com>
---
 drivers/mtd/devices/slram.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 28131a127d06..8297b366a066 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -296,10 +296,12 @@ static int __init init_slram(void)
                T("slram: devname = %s\n", devname);
                if ((!map) || (!(devstart = strsep(&map, ",")))) {
                        E("slram: No devicestart specified.\n");
+                       break;
                }
                T("slram: devstart = %s\n", devstart);
                if ((!map) || (!(devlength = strsep(&map, ",")))) {
                        E("slram: No devicelength / -end specified.\n");
+                       break;
                }
                T("slram: devlength = %s\n", devlength);
                if (parse_cmdline(devname, devstart, devlength) != 0) {
-- 
2.34.1

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

^ permalink raw reply related

* Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
From: Michael Walle @ 2024-07-11 22:13 UTC (permalink / raw)
  To: Erez
  Cc: Esben Haabendal, Tudor Ambarus, Jaime Liao, leoyu, Alvin Zhou,
	Julien Su, Erez Geva, linux-mtd, Pratyush Yadav, linux-kernel,
	Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <CANeKEMNtXb4ZV7kcLbHY+Mti6dPV9UZ2wTyUq5z0qtmtNNqSVA@mail.gmail.com>

On Fri Jul 12, 2024 at 12:09 AM CEST, Erez wrote:
> On Thu, 11 Jul 2024 at 21:57, Michael Walle <mwalle@kernel.org> wrote:
> >
> > Hi Erez,
> >
> > No top posting please, see also
> > https://subspace.kernel.org/etiquette.html
>
> It was a single question. Which I think can be answered in one reply.
> In cases where there are different parts in the mail, it makes sense
> to avoid top posting.
> I do not believe we need to be pedantic.
> The guidance is not holy, it is aimed to make communication more comprehensive.
>
> >
> > On Thu Jul 11, 2024 at 8:57 PM CEST, Erez wrote:
> > > Yes, I think we should.

Regarding top posting, what was the question here?

I don't see any context. So don't expect any reply from me.

-michael

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

^ permalink raw reply

* Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
From: Erez @ 2024-07-11 22:09 UTC (permalink / raw)
  To: Michael Walle
  Cc: Esben Haabendal, Tudor Ambarus, Jaime Liao, leoyu, Alvin Zhou,
	Julien Su, Erez Geva, linux-mtd, Pratyush Yadav, linux-kernel,
	Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <D2MZ405LVTN8.3LTVN3KTUD6A3@kernel.org>

On Thu, 11 Jul 2024 at 21:57, Michael Walle <mwalle@kernel.org> wrote:
>
> Hi Erez,
>
> No top posting please, see also
> https://subspace.kernel.org/etiquette.html

It was a single question. Which I think can be answered in one reply.
In cases where there are different parts in the mail, it makes sense
to avoid top posting.
I do not believe we need to be pedantic.
The guidance is not holy, it is aimed to make communication more comprehensive.

>
> On Thu Jul 11, 2024 at 8:57 PM CEST, Erez wrote:
> > Yes, I think we should.
> >
> > Reading the specification provided publicly by Macronix.
> > For all the JEDEC IDs with the no SFDP flag in drivers/mtd/spi-nor/macronix.c
> > All of them have a new version or a new chip with the same JEDEC ID
> > that supports SFDP.
> > There are 2 chips that Macronix does not provide spec. in public.
> > I can ask Macronix technical support on these 2 chips.
>
> We don't add flashes we cannot test.

I did not suggest adding anything new.
I refer to the list of chips we already have in drivers/mtd/spi-nor/macronix.c
I presume someone tested them before adding them to the list in the past.
And probably the old chip did not have the SFDP table back then.

What I checked with the chip specifications is that all Macronix chips
since 2010 have SFDP.

The situation today is that all Macronix chips that are NOT in the
Macronix table work based on the SFDP table.
But new chips that use a JEDEC found in the Macronix table, skip the
SFDP table and
 use the setting of the old chip.

So I suggest we read the SFDP table for all Macronix chips.
Old Macronix chips that do not have SFDP will use the setting from the
Macronix table. i.e backward compatible.
While new chips which do have an SFDP table will work with the new
setting we find in the table.

Of course, we might have issues in parsing the SFDP table itself.
So we fix them as developers report and send chip ID and part number
with the SFDP table content.
I do not see the point of "hiding" with the old setting.
Anyhow, as we do not like the IDs table and keep it for backward-compatible,
  so it only makes sense we should use the SFDP table as much as possible.

My check was to ensure Tudor that all Macronix chips have SFDP whether
they are in the IDs table or not
 and we are not wasting a no-op on a chip which can not have an SFDP table.

All I suggest is we add the new 'SPI_NOR_TRY_SFDP' flag, to all Macronix chips..
Which will try to read the SFDP to any Macronix chip.

Erez

>
> -michael

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

^ permalink raw reply

* Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
From: Michael Walle @ 2024-07-11 19:57 UTC (permalink / raw)
  To: Erez, Esben Haabendal
  Cc: Tudor Ambarus, Jaime Liao, leoyu, Alvin Zhou, Julien Su,
	Erez Geva, linux-mtd, Pratyush Yadav, linux-kernel, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, devicetree, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <CANeKEMNJ3_ET5pQo2wg7_GSLX+vE+dqW-CV=v2DnG10xcgSdzQ@mail.gmail.com>

Hi Erez,

No top posting please, see also
https://subspace.kernel.org/etiquette.html

On Thu Jul 11, 2024 at 8:57 PM CEST, Erez wrote:
> Yes, I think we should.
>
> Reading the specification provided publicly by Macronix.
> For all the JEDEC IDs with the no SFDP flag in drivers/mtd/spi-nor/macronix.c
> All of them have a new version or a new chip with the same JEDEC ID
> that supports SFDP.
> There are 2 chips that Macronix does not provide spec. in public.
> I can ask Macronix technical support on these 2 chips.

We don't add flashes we cannot test.

-michael

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

^ permalink raw reply

* Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
From: Erez @ 2024-07-11 18:57 UTC (permalink / raw)
  To: Esben Haabendal
  Cc: Tudor Ambarus, Jaime Liao, leoyu, Alvin Zhou, Julien Su,
	Erez Geva, linux-mtd, Pratyush Yadav, Michael Walle, linux-kernel,
	Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <875xtd48ps.fsf@geanix.com>

Yes, I think we should.

Reading the specification provided publicly by Macronix.
For all the JEDEC IDs with the no SFDP flag in drivers/mtd/spi-nor/macronix.c
All of them have a new version or a new chip with the same JEDEC ID
that supports SFDP.
There are 2 chips that Macronix does not provide spec. in public.
I can ask Macronix technical support on these 2 chips.

Erez

"RDID"    "Part."         "Size"              "Status"          "SFDP
status according to spec. or new chip replacing with same RDID and
SFDP supported according to spec."
c22012  MX25L2005(A)  SZ_256K =  2Mb    EOL             MX25L2006E
c22013  MX25L4005A    SZ_512K =  4Mb    EOL             MX25L4006E
c22533  MX25U4035     SZ_512K =  4Mb    EOL             MX25U4033E
c22534  MX25U8035     SZ_1M   =  8Mb    EOL             MX25U8033E
c22016  MX25L3205D    SZ_4M   =  32Mb   EOL             MX25L3233F
c22017  MX25L6405D    SZ_8M   =  64Mb   EOL             MX25L6406E / MX25L6433F
c22018  MX25L12805D   SZ_16M  =  128Mb  EOL             MX25L12833F
c22538  MX25U12835F   SZ_16M  =  128Mb  EOL             MX25U12832F
c2253a  MX66U51235F   SZ_64M  =  512Mb  EOL             MX25U51245G
c22532  MX25U2033E    SZ_256K =  2Mb    EOL             Have-SFDP!
c22010  MX25L512E     SZ_64K  =  512Kb  NO_REC          Have-SFDP!
c22015  MX25L1606E    SZ_2M   =  16Mb   NO_REC          Have-SFDP!
c22536  MX25U3235F    SZ_4M   =  32Mb   NO_REC          Have-SFDP!
c22816  MX25R3235F    SZ_4M   =  32Mb   NO_REC          Have-SFDP!
c22537  MX25U6435F    SZ_8M   =  64Mb   NO_REC          Have-SFDP!
c22019  MX25L25635E   SZ_32M  =  256Mb  NO_REC          Have-SFDP!
c22539  MX25U25635F   SZ_32M  =  256Mb  NO_REC          Have-SFDP!
c2201a  MX66L51235F   SZ_64M  =  512Mb  NO_REC          Have-SFDP!
c2253a  MX25U51245G   SZ_64M  =  512Mb  PROD            Have-SFDP!
c22314  MX25V8035F    SZ_1M   =  8Mb    PROD            Have-SFDP!
c22815  MX25R1635F    SZ_2M   =  16Mb   PROD            Have-SFDP!
c2201b  MX66L1G45G    SZ_128M =  1Gb    PROD            Have-SFDP!
c2253c  MX66U2G45G    SZ_256M =  2Gb    PROD            Have-SFDP!
c2261b  MX66L1G55G    SZ_128M =  1Gb    NO_REC          Spec. is not public
c29e16  MX25L3255E    SZ_4M   =  32Mb   PROD            Spec. is not public

EOL     End of Life
PROD    Production
NO_REC  Not recommend


On Wed, 10 Jul 2024 at 16:34, Esben Haabendal <esben@geanix.com> wrote:
>
> Erez <erezgeva2@gmail.com> writes:
>
> > On Wed, 3 Jul 2024 at 09:12, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >> On 7/3/24 12:16 AM, Erez wrote:
> >>> On Tue, 2 Jul 2024 at 07:00, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>
> >>> The table below uses fixed width characters.
> >>>
> >>> ID      Part.         Size              Status          SFDP status
> >>> according to spec.
> >>>                                                         New chip with
> >>> SFDP for EOL
> >>> c22012  MX25L2005(A)  SZ_256K =  2Mb    EOL             MX25L2006E
> >>> c22532  MX25U2033E    SZ_256K =  2Mb    EOL
> >>> c22013  MX25L4005A    SZ_512K =  4Mb    EOL
> >>> c22533  MX25U4035     SZ_512K =  4Mb    EOL
> >>> c22534  MX25U8035     SZ_1M   =  8Mb    EOL
> >>> c22016  MX25L3205D    SZ_4M   =  32Mb   EOL             MX25L3233F
> >>> c29e16  MX25L3255E    SZ_4M   =  32Mb   EOL
> >>> c22017  MX25L6405D    SZ_8M   =  64Mb   EOL
> >>> c22018  MX25L12805D   SZ_16M  =  128Mb  EOL             MX25L12833F
> >>> c22538  MX25U12835F   SZ_16M  =  128Mb  EOL
> >>> c2253a  MX66U51235F   SZ_64M  =  512Mb  EOL             MX25U51245G
> >>> c22010  MX25L512E     SZ_64K  =  512Kb  NO_REC          Have-SFDP!
> >>> c22015  MX25L1606E    SZ_2M   =  16Mb   NO_REC          Have-SFDP!
> >>> c22536  MX25U3235F    SZ_4M   =  32Mb   NO_REC          Have-SFDP!
> >>> c22816  MX25R3235F    SZ_4M   =  32Mb   NO_REC          Have-SFDP!
> >>> c22537  MX25U6435F    SZ_8M   =  64Mb   NO_REC          Have-SFDP!
> >>> c22019  MX25L25635E   SZ_32M  =  256Mb  NO_REC          Have-SFDP!
> >>> c22539  MX25U25635F   SZ_32M  =  256Mb  NO_REC          Have-SFDP!
> >>> c2201a  MX66L51235F   SZ_64M  =  512Mb  NO_REC          Have-SFDP!
> >>> c2261b  MX66L1G55G    SZ_128M =  1Gb    NO_REC          Spec. is not public
> >>> c22314  MX25V8035F    SZ_1M   =  8Mb    PROD            Have-SFDP!
> >>> c22815  MX25R1635F    SZ_2M   =  16Mb   PROD            Have-SFDP!
> >>> c2201b  MX66L1G45G    SZ_128M =  1Gb    PROD            Have-SFDP!
> >>> c2253c  MX66U2G45G    SZ_256M =  2Gb    PROD            Have-SFDP!
> >>> c2253a  MX25U51245G   SZ_64M  =  512Mb  PROD            Have-SFDP!
> >>>
> >>> EOL     End of Life
> >>> PROD    Normal Production
> >>> NO_REC  Not recommend for new design
> >>>
> >>>
> >>
> >> not sure what you want me to do with these.
> >
> > That we can read SFDP for all chips from Macronix.
> > Only old chips before 2010 do not have SFDP.
>
> So, should we try and identify new chips (with SFDP) that re-use the ID of all the
> above mentioned EOL chips that does not have SFDP?
>
> As I read the communication from Macronix, then we should expect new
> chips re-using the ID for all of them. It is just a matter of digging.
>
> /Esben

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

^ permalink raw reply

* [PATCH v3 15/15] mtd: spi-nor: spansion: Drop redundant SPI_NOR_SKIP_SFDP flag
From: Esben Haabendal @ 2024-07-11 13:00 UTC (permalink / raw)
  To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel,
	Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>

With the implementation of SPI_NOR_TRY_SFDP flag, the removal of the
deprecated mechanism for trying SFDP parsing, and the alignment of
->default_init() hooks handling, the SPI_NOR_SKIP_SFDP flag has become a
no-op, so it can safely be removed.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/mtd/spi-nor/core.c     | 2 +-
 drivers/mtd/spi-nor/core.h     | 5 +----
 drivers/mtd/spi-nor/spansion.c | 2 +-
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index d58f107f62ec..518b2707ce80 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3024,7 +3024,7 @@ static int spi_nor_init_params(struct spi_nor *nor)
 	if (spi_nor_needs_sfdp(nor)) {
 		ret = spi_nor_parse_sfdp(nor);
 		if (ret) {
-			dev_err(nor->dev, "BFPT parsing failed. Please consider using SPI_NOR_SKIP_SFDP or SPI_NOR_TRY_SFDP when declaring the flash\n");
+			dev_err(nor->dev, "BFPT parsing failed. Please consider using SPI_NOR_TRY_SFDP when declaring the flash\n");
 			return ret;
 		}
 	} else {
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index f4a76f42051a..ae10e12e9078 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -485,9 +485,7 @@ struct spi_nor_id {
  *
  * @no_sfdp_flags:  flags that indicate support that can be discovered via SFDP.
  *                  Used when SFDP tables are not defined in the flash. These
- *                  flags are used together with the SPI_NOR_SKIP_SFDP or
- *                  SPI_NOR_TRY_SFDP flag.
- *   SPI_NOR_SKIP_SFDP:       skip parsing of SFDP tables.
+ *                  flags are used together with the SPI_NOR_TRY_SFDP flag.
  *   SECT_4K:                 SPINOR_OP_BE_4K works uniformly.
  *   SPI_NOR_TRY_SFDP:        try parsing SFDP tables before using the
  *                            parameters specified in this struct.
@@ -536,7 +534,6 @@ struct flash_info {
 #define SPI_NOR_RWW			BIT(9)
 
 	u8 no_sfdp_flags;
-#define SPI_NOR_SKIP_SFDP		BIT(0)
 #define SECT_4K				BIT(1)
 #define SPI_NOR_TRY_SFDP		BIT(2)
 #define SPI_NOR_DUAL_READ		BIT(3)
diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index a58c0229003d..afcb684ffe4d 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -793,7 +793,7 @@ static const struct flash_info spansion_nor_parts[] = {
 		.name = "s25fl256s0",
 		.size = SZ_32M,
 		.sector_size = SZ_256K,
-		.no_sfdp_flags = SPI_NOR_SKIP_SFDP | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x19, 0x4d, 0x00, 0x81),

-- 
2.45.2


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

^ permalink raw reply related

* [PATCH v3 14/15] mtd: spi-nor: Drop deprecated mechanism for optional SFDP parsing
From: Esben Haabendal @ 2024-07-11 13:00 UTC (permalink / raw)
  To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel,
	Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>

With all drivers converted to the new SPI_NOR_TRY_SFDP flag, we can remove
the old deprecated mechanism for triggering optional SFDP parsing.

New flashes must use SPI_NOR_TRY_SFDP to get this behavior. Hopefully, all
new drivers will be fore pure SFDP flashes, so no or at least very few new
users of this flag is expected.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/mtd/spi-nor/core.h | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index dfc81716e068..f4a76f42051a 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -719,24 +719,7 @@ static inline bool spi_nor_needs_sfdp(const struct spi_nor *nor)
  */
 static inline bool spi_nor_try_sfdp(const struct spi_nor *nor)
 {
-	if (nor->info->no_sfdp_flags & SPI_NOR_SKIP_SFDP)
-		return false;
-	if (nor->info->no_sfdp_flags & SPI_NOR_TRY_SFDP)
-		return true;
-
-	/* Deprecated/legacy way for triggering optional SFDP parsing.
-	 * If one of the no_sfdp_flags indicating dual, quad or octal read is
-	 * set, SFDP parsing will be tried.
-	 * When all drivers have been converted to set SPI_NOR_TRY_SFDP where
-	 * needed, this deprecated mechanism can be removed.
-	 */
-	if (nor->info->no_sfdp_flags & (SPI_NOR_DUAL_READ |
-					SPI_NOR_QUAD_READ |
-					SPI_NOR_OCTAL_READ |
-					SPI_NOR_OCTAL_DTR_READ))
-		return true;
-
-	return false;
+	return (nor->info->no_sfdp_flags & SPI_NOR_TRY_SFDP)
 }
 
 #ifdef CONFIG_DEBUG_FS

-- 
2.45.2


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

^ permalink raw reply related

* [PATCH v3 13/15] mtd: spi-nor: xmc: Use new SPI_NOR_TRY_SFDP flag
From: Esben Haabendal @ 2024-07-11 13:00 UTC (permalink / raw)
  To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel,
	Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>

This converts from the old (deprecated) implicit way of triggering an
optional SFDP parse with fallback to the static configuration in the
matching struct flash_info entry.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/mtd/spi-nor/xmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/xmc.c b/drivers/mtd/spi-nor/xmc.c
index d5a06054b0dd..527468630b99 100644
--- a/drivers/mtd/spi-nor/xmc.c
+++ b/drivers/mtd/spi-nor/xmc.c
@@ -13,12 +13,12 @@ static const struct flash_info xmc_nor_parts[] = {
 		.id = SNOR_ID(0x20, 0x70, 0x17),
 		.name = "XM25QH64A",
 		.size = SZ_8M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x20, 0x70, 0x18),
 		.name = "XM25QH128A",
 		.size = SZ_16M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	},
 };
 

-- 
2.45.2


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

^ permalink raw reply related

* [PATCH v3 12/15] mtd: spi-nor: winbond: Use new SPI_NOR_TRY_SFDP flag
From: Esben Haabendal @ 2024-07-11 13:00 UTC (permalink / raw)
  To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel,
	Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>

This converts from the old (deprecated) implicit way of triggering an
optional SFDP parse with fallback to the static configuration in the
matching struct flash_info entry.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/mtd/spi-nor/winbond.c | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index 142fb27b2ea9..42160257e270 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -101,7 +101,7 @@ static const struct flash_info winbond_nor_parts[] = {
 		.id = SNOR_ID(0xef, 0x40, 0x17),
 		.name = "w25q64",
 		.size = SZ_8M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x40, 0x18),
 		.name = "w25q128",
@@ -110,13 +110,13 @@ static const struct flash_info winbond_nor_parts[] = {
 		.id = SNOR_ID(0xef, 0x40, 0x19),
 		.name = "w25q256",
 		.size = SZ_32M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixups = &w25q256_fixups,
 	}, {
 		.id = SNOR_ID(0xef, 0x40, 0x20),
 		.name = "w25q512jvq",
 		.size = SZ_64M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x50, 0x12),
 		.name = "w25q20bw",
@@ -137,31 +137,31 @@ static const struct flash_info winbond_nor_parts[] = {
 		.name = "w25q16dw",
 		.size = SZ_2M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x60, 0x16),
 		.name = "w25q32dw",
 		.size = SZ_4M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.otp = SNOR_OTP(256, 3, 0x1000, 0x1000),
 	}, {
 		.id = SNOR_ID(0xef, 0x60, 0x17),
 		.name = "w25q64dw",
 		.size = SZ_8M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x60, 0x18),
 		.name = "w25q128fw",
 		.size = SZ_16M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x60, 0x19),
 		.name = "w25q256jw",
 		.size = SZ_32M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x60, 0x20),
 		.name = "w25q512nwq",
@@ -171,13 +171,13 @@ static const struct flash_info winbond_nor_parts[] = {
 		.name = "w25q16jv-im/jm",
 		.size = SZ_2M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x70, 0x16),
 		.name = "w25q32jv",
 		.size = SZ_4M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x70, 0x17),
 		.name = "w25q64jvm",
@@ -188,7 +188,7 @@ static const struct flash_info winbond_nor_parts[] = {
 		.name = "w25q128jv",
 		.size = SZ_16M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x70, 0x19),
 		.name = "w25q256jvm",
@@ -196,32 +196,32 @@ static const struct flash_info winbond_nor_parts[] = {
 		.id = SNOR_ID(0xef, 0x71, 0x19),
 		.name = "w25m512jv",
 		.size = SZ_64M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x80, 0x16),
 		.name = "w25q32jwm",
 		.size = SZ_4M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.otp = SNOR_OTP(256, 3, 0x1000, 0x1000),
 	}, {
 		.id = SNOR_ID(0xef, 0x80, 0x17),
 		.name = "w25q64jwm",
 		.size = SZ_8M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x80, 0x18),
 		.name = "w25q128jwm",
 		.size = SZ_16M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x80, 0x19),
 		.name = "w25q256jwm",
 		.size = SZ_32M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x80, 0x20),
 		.name = "w25q512nwm",

-- 
2.45.2


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

^ permalink raw reply related

* [PATCH v3 11/15] mtd: spi-nor: sst: Use new SPI_NOR_TRY_SFDP flag
From: Esben Haabendal @ 2024-07-11 13:00 UTC (permalink / raw)
  To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel,
	Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>

This converts from the old (deprecated) implicit way of triggering an
optional SFDP parse with fallback to the static configuration in the
matching struct flash_info entry.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/mtd/spi-nor/sst.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
index 180b7390690c..bfebef62dd36 100644
--- a/drivers/mtd/spi-nor/sst.c
+++ b/drivers/mtd/spi-nor/sst.c
@@ -146,7 +146,7 @@ static const struct flash_info sst_nor_parts[] = {
 		.id = SNOR_ID(0xbf, 0x26, 0x41),
 		.name = "sst26vf016b",
 		.size = SZ_2M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xbf, 0x26, 0x42),
 		.name = "sst26vf032b",
@@ -157,13 +157,13 @@ static const struct flash_info sst_nor_parts[] = {
 		.name = "sst26vf064b",
 		.size = SZ_8M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixups = &sst26vf_nor_fixups,
 	}, {
 		.id = SNOR_ID(0xbf, 0x26, 0x51),
 		.name = "sst26wf016b",
 		.size = SZ_2M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}
 };
 

-- 
2.45.2


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

^ permalink raw reply related

* [PATCH v3 10/15] mtd: spi-nor: spansion: Use new SPI_NOR_TRY_SFDP flag
From: Esben Haabendal @ 2024-07-11 13:00 UTC (permalink / raw)
  To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel,
	Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>

This converts from the old (deprecated) implicit way of triggering an
optional SFDP parse with fallback to the static configuration in the
matching struct flash_info entry.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/mtd/spi-nor/spansion.c | 44 +++++++++++++++++++++---------------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 6cc237c24e07..a58c0229003d 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -774,7 +774,7 @@ static const struct flash_info spansion_nor_parts[] = {
 		.id = SNOR_ID(0x01, 0x02, 0x15, 0x4d, 0x00),
 		.name = "s25sl032p",
 		.size = SZ_4M,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x15),
 		.name = "s25sl032a",
@@ -783,7 +783,7 @@ static const struct flash_info spansion_nor_parts[] = {
 		.id = SNOR_ID(0x01, 0x02, 0x16, 0x4d, 0x00),
 		.name = "s25sl064p",
 		.size = SZ_8M,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x16),
 		.name = "s25sl064a",
@@ -800,19 +800,19 @@ static const struct flash_info spansion_nor_parts[] = {
 		.name = "s25fs256s0",
 		.size = SZ_32M,
 		.sector_size = SZ_256K,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x19, 0x4d, 0x01, 0x80),
 		.name = "s25fl256s1",
 		.size = SZ_32M,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x19, 0x4d, 0x01, 0x81),
 		.name = "s25fs256s1",
 		.size = SZ_32M,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x20, 0x4d, 0x00, 0x80),
@@ -820,14 +820,14 @@ static const struct flash_info spansion_nor_parts[] = {
 		.size = SZ_64M,
 		.sector_size = SZ_256K,
 		.flags = SPI_NOR_HAS_LOCK,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x20, 0x4d, 0x00, 0x81),
 		.name = "s25fs512s",
 		.size = SZ_64M,
 		.sector_size = SZ_256K,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 		.fixups = &s25fs_s_nor_fixups,
 	}, {
@@ -844,49 +844,49 @@ static const struct flash_info spansion_nor_parts[] = {
 		.name = "s25fl128s0",
 		.size = SZ_16M,
 		.sector_size = SZ_256K,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x20, 0x18, 0x4d, 0x00),
 		.name = "s25fl129p0",
 		.size = SZ_16M,
 		.sector_size = SZ_256K,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x20, 0x18, 0x4d, 0x01, 0x80),
 		.name = "s25fl128s1",
 		.size = SZ_16M,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x20, 0x18, 0x4d, 0x01, 0x81),
 		.name = "s25fs128s1",
 		.size = SZ_16M,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 		.fixups = &s25fs_s_nor_fixups,
 	}, {
 		.id = SNOR_ID(0x01, 0x20, 0x18, 0x4d, 0x01),
 		.name = "s25fl129p1",
 		.size = SZ_16M,
-		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x40, 0x13),
 		.name = "s25fl204k",
 		.size = SZ_512K,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x01, 0x40, 0x14),
 		.name = "s25fl208k",
 		.size = SZ_1M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x01, 0x40, 0x15),
 		.name = "s25fl116k",
 		.size = SZ_2M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x01, 0x40, 0x16),
 		.name = "s25fl132k",
@@ -901,19 +901,19 @@ static const struct flash_info spansion_nor_parts[] = {
 		.id = SNOR_ID(0x01, 0x60, 0x17),
 		.name = "s25fl064l",
 		.size = SZ_8M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixup_flags = SPI_NOR_4B_OPCODES,
 	}, {
 		.id = SNOR_ID(0x01, 0x60, 0x18),
 		.name = "s25fl128l",
 		.size = SZ_16M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixup_flags = SPI_NOR_4B_OPCODES,
 	}, {
 		.id = SNOR_ID(0x01, 0x60, 0x19),
 		.name = "s25fl256l",
 		.size = SZ_32M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixup_flags = SPI_NOR_4B_OPCODES,
 	}, {
 		.id = SNOR_ID(0x04, 0x2c, 0xc2, 0x7f, 0x7f, 0x7f),
@@ -985,22 +985,22 @@ static const struct flash_info spansion_nor_parts[] = {
 		.id = SNOR_ID(0xef, 0x40, 0x13),
 		.name = "s25fl004k",
 		.size = SZ_512K,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x40, 0x14),
 		.name = "s25fl008k",
 		.size = SZ_1M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x40, 0x15),
 		.name = "s25fl016k",
 		.size = SZ_2M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0xef, 0x40, 0x17),
 		.name = "s25fl064k",
 		.size = SZ_8M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}
 };
 

-- 
2.45.2


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

^ permalink raw reply related

* [PATCH v3 09/15] mtd: spi-nor: micron-st: Use new SPI_NOR_TRY_SFDP flag
From: Esben Haabendal @ 2024-07-11 13:00 UTC (permalink / raw)
  To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea
  Cc: linux-mtd, linux-kernel, Rasmus Villemoes, linux-arm-kernel,
	Esben Haabendal
In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com>

This converts from the old (deprecated) implicit way of triggering an
optional SFDP parse with fallback to the static configuration in the
matching struct flash_info entry.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/mtd/spi-nor/micron-st.c | 41 +++++++++++++++++++++--------------------
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 3c6499fdb712..c40e02b4f030 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -166,7 +166,8 @@ static const struct flash_info micron_nor_parts[] = {
 		.sector_size = SZ_128K,
 		.size = SZ_64M,
 		.no_sfdp_flags = SECT_4K | SPI_NOR_OCTAL_READ |
-				 SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP,
+				 SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP |
+				 SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 		.fixup_flags = SPI_NOR_4B_OPCODES | SPI_NOR_IO_MODE_EN_VOLATILE,
 		.fixups = &mt35xu512aba_fixups,
@@ -175,7 +176,7 @@ static const struct flash_info micron_nor_parts[] = {
 		.name = "mt35xu02g",
 		.sector_size = SZ_128K,
 		.size = SZ_256M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_OCTAL_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 		.fixup_flags = SPI_NOR_4B_OPCODES,
 	},
@@ -364,38 +365,38 @@ static const struct flash_info st_nor_parts[] = {
 		.id = SNOR_ID(0x20, 0xba, 0x16),
 		.name = "n25q032",
 		.size = SZ_4M,
-		.no_sfdp_flags = SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x20, 0xba, 0x17),
 		.name = "n25q064",
 		.size = SZ_8M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x20, 0xba, 0x18),
 		.name = "n25q128a13",
 		.size = SZ_16M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
 			 SPI_NOR_BP3_SR_BIT6,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xba, 0x19, 0x10, 0x44, 0x00),
 		.name = "mt25ql256a",
 		.size = SZ_32M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixup_flags = SPI_NOR_4B_OPCODES,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xba, 0x19),
 		.name = "n25q256a",
 		.size = SZ_32M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xba, 0x20, 0x10, 0x44, 0x00),
 		.name = "mt25ql512a",
 		.size = SZ_64M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixup_flags = SPI_NOR_4B_OPCODES,
 		.mfr_flags = USE_FSR,
 	}, {
@@ -404,7 +405,7 @@ static const struct flash_info st_nor_parts[] = {
 		.size = SZ_64M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
 			 SPI_NOR_BP3_SR_BIT6,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xba, 0x21),
@@ -412,38 +413,38 @@ static const struct flash_info st_nor_parts[] = {
 		.size = SZ_128M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
 			 SPI_NOR_BP3_SR_BIT6,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 		.fixups = &n25q00_fixups,
 	}, {
 		.id = SNOR_ID(0x20, 0xba, 0x22),
 		.name = "mt25ql02g",
 		.size = SZ_256M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 		.fixups = &mt25q02_fixups,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x15),
 		.name = "n25q016a",
 		.size = SZ_2M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x16),
 		.name = "n25q032a",
 		.size = SZ_4M,
-		.no_sfdp_flags = SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x17),
 		.name = "n25q064a",
 		.size = SZ_8M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x18),
 		.name = "n25q128a11",
 		.size = SZ_16M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
 			 SPI_NOR_BP3_SR_BIT6,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x19, 0x10, 0x44, 0x00),
@@ -451,14 +452,14 @@ static const struct flash_info st_nor_parts[] = {
 		.size = SZ_32M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
 			 SPI_NOR_BP3_SR_BIT6,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.fixup_flags = SPI_NOR_4B_OPCODES,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x19),
 		.name = "n25q256ax1",
 		.size = SZ_32M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x20, 0x10, 0x44, 0x00),
@@ -473,7 +474,7 @@ static const struct flash_info st_nor_parts[] = {
 		.size = SZ_64M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
 			 SPI_NOR_BP3_SR_BIT6,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x21, 0x10, 0x44, 0x00),
@@ -484,14 +485,14 @@ static const struct flash_info st_nor_parts[] = {
 		.id = SNOR_ID(0x20, 0xbb, 0x21),
 		.name = "n25q00a",
 		.size = SZ_128M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 		.fixups = &n25q00_fixups,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x22),
 		.name = "mt25qu02g",
 		.size = SZ_256M,
-		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_TRY_SFDP,
 		.mfr_flags = USE_FSR,
 		.fixups = &mt25q02_fixups,
 	}

-- 
2.45.2


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

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox