mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: sashiko-bot@kernel.org
Cc: "Vignesh Raghavendra" <vigneshr@ti.com>,
	 "Pratyush Yadav" <pratyush@kernel.org>,
	 "Michael Walle" <mwalle@kernel.org>,
	 "Takahiro Kuwano" <takahiro.kuwano@infineon.com>,
	 "Richard Weinberger" <richard@nod.at>,
	 sashiko-reviews@lists.linux.dev,
	 "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	 linux-kernel@vger.kernel.org,  "Steam Lin" <STLin2@winbond.com>,
	 linux-mtd@lists.infradead.org,
	 "Jon Hunter" <jonathanh@nvidia.com>
Subject: Re: [PATCH v2] mtd: spi-nor: Fix quad-enable for flashes with QER bit in SR1
Date: Fri, 11 Sep 2026 14:45:19 +0200	[thread overview]
Message-ID: <877bksq7mo.fsf@bootlin.com> (raw)
In-Reply-To: <20260911105245.408171F00893@smtp.kernel.org> (sashiko-bot@kernel.org's message of "Fri, 11 Sep 2026 10:52:44 +0000")

Hello Michael,

On 11/09/2026 at 10:52:44 GMT, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] spi_nor_read_sr1_and_sr2() leaves sr[1] uninitialized when
> read_sr2 is unsupported, leading to uninitialized stack memory use in
> callers and spurious -EIO errors.

The annoyingly right Sashiko robot is correct :-)

The best way I see to make sure this does not appear, is to just add
this fallback to make sure when we read both registers we just get zero
instead of random data in the buffer. Again, the idea is to make sure
callers do not need to be "QER aware".

--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -867,6 +867,8 @@ int spi_nor_read_sr1_and_sr2(struct spi_nor *nor, u8 *sr)
 
        if (nor->params->opcodes.read_sr2)
                ret = spi_nor_read_sr2(nor, &sr[1]);
+       else
+               sr[1] = 0;
 
        return ret;
 }

What do you think?

Thanks,
Miquèl

  reply	other threads:[~2026-09-11 12:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 10:42 Miquel Raynal
2026-09-11 10:52 ` sashiko-bot
2026-09-11 12:45   ` Miquel Raynal [this message]
2026-09-11 13:18     ` Michael Walle
2026-09-11 13:37       ` 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=877bksq7mo.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=STLin2@winbond.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®