mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vignesh Raghavendra" <vigneshr@ti.com>,
	"Michael Walle" <mwalle@kernel.org>,
	"Pratyush Yadav" <pratyush@kernel.org>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Takahiro Kuwano" <takahiro.kuwano@infineon.com>
Cc: "Steam Lin" <STLin2@winbond.com>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v2 10/17] mtd: spi-nor: winbond: Prepare the introduction of W35TxxNW parts
Date: Sun, 04 Oct 2026 21:45:30 +0000	[thread overview]
Message-ID: <20261004214530.837371F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261004-winbond-master-spi-nor-w35t-v2-10-592f3300a70f@bootlin.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtd: spi-nor: winbond: missing Flag Register polling ignores P/E errors
--

commit eef1bdae97bf8ec6c5ee8f47f2358cc4351e258b
Author: Miquel Raynal <miquel.raynal@bootlin.com>

mtd: spi-nor: winbond: Prepare the introduction of W35TxxNW parts

This commit prepares for a new octal DTR family by adding callbacks for octal
DTR modes and dummy cycles configuration. It also mentions these chips feature
SECDEC and lack SR2, but they do have a flag register.

> diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
> index 51f6bcd3f8e5b..058a2951c184e 100644
> --- a/drivers/mtd/spi-nor/winbond.c
> +++ b/drivers/mtd/spi-nor/winbond.c
> @@ -11,6 +11,13 @@
>  #define WINBOND_NOR_OP_RDEAR	0xc8	/* Read Extended Address Register */
>  #define WINBOND_NOR_OP_WREAR	0xc5	/* Write Extended Address Register */
>  #define WINBOND_NOR_OP_SELDIE	0xc2	/* Select active die */
> +#define WINBOND_NOR_OP_WR_VCR	0x81	/* Write VCR registers */
> +#define   WINBOND_NOR_VCR_IO_MODE_CFG_REG 0x00 /* IO mode configuration address (VCR) */
> +#define     WINBOND_NOR_VCR_IO_MODE_SSDR 0xFF
> +#define     WINBOND_NOR_VCR_IO_MODE_ODDR 0xE7
> +#define   WINBOND_NOR_VCR_DUMMY_CFG_REG 0x01 /* Dummy cycle configuration address (VCR) */
> +#define WINBOND_NOR_OP_RD_FR	0x70	/* Read Flag registers */
> +#define WINBOND_NOR_OP_CL_FR	0x50	/* Clear Flag registers */

[Severity: High]
Are these flag register opcodes omitted from the driver logic?

The opcodes WINBOND_NOR_OP_RD_FR and WINBOND_NOR_OP_CL_FR are defined here
for interacting with the Flag Register, but they do not appear to be used
anywhere.

[ ... ]

> @@ -252,6 +265,87 @@ static const struct spi_nor_fixups winbond_nor_ecc_configuration_fixups = {
>  	.post_sfdp = winbond_nor_ecc_configuration_post_sfdp_fixups,
>  };
>  

[ ... ]

> +static int winbond_w35txxnw_nor_late_init(struct spi_nor *nor)
> +{
> +	nor->params->set_octal_dtr = winbond_w35txxnw_nor_set_octal_dtr;
> +	nor->params->set_dummy = winbond_w35txxnw_nor_set_dummy;
> +	nor->params->opcodes.read_sr2 = 0;
> +	nor->params->opcodes.write_sr1_and_sr2 = 0;

[Severity: High]
Should a custom ready callback be assigned here to poll the Flag Register?

Since no custom callback is assigned, the driver falls back to the default
spi_nor_sr_ready, which only checks the SR1 WIP bit and does not check the 
Flag Register for errors.

Could this cause a regression where any program or erase operation that fails
on a W35TxxNW part (e.g., from wear or protection), as well as ECC errors,
are silently ignored? In some cases, uncleared errors leave the flash stuck,
and the OS will incorrectly assume data is persisted, leading to data
corruption.

Could we assign a custom ready callback (such as winbond_w35txxnw_nor_ready)
to correctly utilize the Flag Register?

> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261004-winbond-master-spi-nor-w35t-v2-0-592f3300a70f@bootlin.com?part=10

  reply	other threads:[~2026-10-04 21:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-04 21:31 [PATCH v2 00/17] mtd: spi-nor: winbond: Add support for the W35TxxNW family Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 01/17] mtd: spi-nor: Only switch to ODTR if the chip has a callback for it Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 02/17] mtd: spi-nor: swp: Fix SR2 initialization Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 03/17] mtd: spi-nor: Fix spacing between arguments Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 04/17] mtd: spi-nor: Fix comment indentation to clarify the intent Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 05/17] mtd: spi-nor: sfdp: Enhance a comment Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 06/17] mtd: spi-nor: Drop stale values Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 07/17] mtd: spi-nor: Fix WRSR with ODTR chips Miquel Raynal
2026-10-04 21:43   ` sashiko-bot
2026-10-04 21:31 ` [PATCH v2 08/17] mtd: spi-nor: Allow configuring the actual number of dummy cycles Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 09/17] mtd: spi-nor: Fix SWP for octal DTR chips Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 10/17] mtd: spi-nor: winbond: Prepare the introduction of W35TxxNW parts Miquel Raynal
2026-10-04 21:45   ` sashiko-bot [this message]
2026-10-04 21:31 ` [PATCH v2 11/17] mtd: spi-nor: winbond: Add support for W35T64NW-C Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 12/17] mtd: spi-nor: winbond: Add support for W35T12NW-C Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 13/17] mtd: spi-nor: winbond: Add support for W35T25NW-C/E Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 14/17] mtd: spi-nor: winbond: Add support for W35T51NW-C/E Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 15/17] mtd: spi-nor: winbond: Add support for W35T01NW-C/E Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 16/17] mtd: spi-nor: winbond: Add support for W35T02NW-C/E Miquel Raynal
2026-10-04 21:31 ` [PATCH v2 17/17] mtd: spi-nor: Fix the meaning of a comment Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261004214530.837371F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=STLin2@winbond.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=takahiro.kuwano@infineon.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®