From: Miquel Raynal <miquel.raynal@bootlin.com>
To: sashiko-bot@kernel.org
Cc: "Pratyush Yadav" <pratyush@kernel.org>,
"Michael Walle" <mwalle@kernel.org>,
"Takahiro Kuwano" <takahiro.kuwano@infineon.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
sashiko-reviews@lists.linux.dev,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Steam Lin" <STLin2@winbond.com>,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH v3 09/17] mtd: spi-nor: Allow configuring the actual number of dummy cycles
Date: Wed, 14 Oct 2026 11:09:01 +0200 [thread overview]
Message-ID: <874ieozm1e.fsf@bootlin.com> (raw)
In-Reply-To: <sashiko-outbox-170162@kernel.org> (sashiko-bot@kernel.org's message of "Tue, 13 Oct 2026 16:49:52 +0000")
>> @@ -3100,6 +3118,10 @@ static int spi_nor_init(struct spi_nor *nor)
>> struct spi_nor_flash_parameter *params = nor->params;
>> int err;
>>
>> + err = spi_nor_set_dummy(nor);
>> + if (err)
>> + return err;
>> +
>> err = spi_nor_set_octal_dtr(nor, true);
>> if (err) {
>> dev_dbg(nor->dev, "octal mode not supported\n");
>> return err;
>> }
>
> [Severity: High]
> If spi_nor_set_octal_dtr() returns an error, does this leave the flash chip
> in a non-default hardware state?
>
> It appears that if entering octal mode fails, the function returns immediately
> without undoing the just-applied spi_nor_set_dummy() configuration.
>
> Similarly, if a memory allocation fails later during driver probe after
> spi_nor_scan() has successfully mutated the flash state:
>
> drivers/mtd/spi-nor/core.c:spi_nor_probe() {
> ...
> err = spi_nor_scan(nor, name, &hwcaps);
> if (err)
> return err;
>
> if (nor->bouncebuf_size) {
> nor->bouncebuf = devm_kmalloc(dev, nor->bouncebuf_size,
> GFP_KERNEL);
> if (!nor->bouncebuf)
> return -ENOMEM;
> ...
> }
>
> Does the driver return here without calling spi_nor_restore() to undo the
> dummy cycles configuration?
>
> If the flash chip is left expecting the newly configured dummy cycles,
> reads using default SPI parameters (e.g., standard dummy cycles) during a warm
> reboot might return garbage, potentially hanging the boot process.
There is no "default" hardware state regarding dummy cycles. This is a
state that must be negociated at every "boot" (when relevant), warm or
not, so there is no breakage here since next warm boot the same dance
will happen again from scratch. In case octal is not reachable we
already recalculate the dummy cycles for the SSDR case when relevant.
So: won't fix either.
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-10-14 9:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 16:33 [PATCH v3 00/17] mtd: spi-nor: winbond: Add support for the W35TxxNW family Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 01/17] mtd: spi-nor: Only switch to ODTR if the chip has a callback for it Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 02/17] mtd: spi-nor: swp: Fix SR2 initialization Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 03/17] mtd: spi-nor: Fix spacing between arguments Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 04/17] mtd: spi-nor: Fix comment indentation to clarify the intent Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 05/17] mtd: spi-nor: sfdp: Enhance a comment Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 06/17] mtd: spi-nor: Fix the meaning of " Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 07/17] mtd: spi-nor: Drop stale values Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 08/17] mtd: spi-nor: Fix WRSR with ODTR chips Miquel Raynal
2026-10-13 16:51 ` sashiko-bot
2026-10-14 8:56 ` Miquel Raynal
2026-10-13 16:33 ` [PATCH v3 09/17] mtd: spi-nor: Allow configuring the actual number of dummy cycles Miquel Raynal
2026-10-13 16:49 ` sashiko-bot
2026-10-14 9:09 ` Miquel Raynal [this message]
2026-10-13 16:34 ` [PATCH v3 10/17] mtd: spi-nor: Fix SWP for octal DTR chips Miquel Raynal
2026-10-13 16:34 ` [PATCH v3 11/17] mtd: spi-nor: winbond: Prepare the introduction of W35TxxNW parts Miquel Raynal
2026-10-13 16:34 ` [PATCH v3 12/17] mtd: spi-nor: winbond: Add support for W35T64NW-C Miquel Raynal
2026-10-13 16:34 ` [PATCH v3 13/17] mtd: spi-nor: winbond: Add support for W35T12NW-C Miquel Raynal
2026-10-13 16:34 ` [PATCH v3 14/17] mtd: spi-nor: winbond: Add support for W35T25NW-C/E Miquel Raynal
2026-10-13 16:34 ` [PATCH v3 15/17] mtd: spi-nor: winbond: Add support for W35T51NW-C/E Miquel Raynal
2026-10-13 16:34 ` [PATCH v3 16/17] mtd: spi-nor: winbond: Add support for W35T01NW-C/E Miquel Raynal
2026-10-13 16:34 ` [PATCH v3 17/17] mtd: spi-nor: winbond: Add support for W35T02NW-C/E Miquel Raynal
2026-10-14 9:12 ` [PATCH v3 00/17] mtd: spi-nor: winbond: Add support for the W35TxxNW family 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=874ieozm1e.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=STLin2@winbond.com \
--cc=linux-mtd@lists.infradead.org \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=sashiko-bot@kernel.org \
--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