From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Dahl <ada@thorsis.com>
Cc: linux-mtd@lists.infradead.org,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: mtd: nand: raw: Possible bug in nand_onfi_detect()?
Date: Mon, 25 Mar 2024 10:09:16 +0100 [thread overview]
Message-ID: <20240325100917.502c75b7@xps-13> (raw)
In-Reply-To: <20240307181931.440c9c3f@xps-13>
Hello Alexander,
> > > > The condition is true and nand_change_read_column_op() returns with
> > > > -EINVAL, because mtd->writesize and mtd->oobsize are not set yet in
> > > > that code path. Those are probably initialized later, maybe with
> > > > parameters read from that ONFI param page?
> > > >
> > > > Returning with error from nand_change_read_column_op() leads to
> > > > jumping out of nand_onfi_detect() early, and no ONFI param page is
> > > > evaluated at all, although the second or third page could be intact.
> > > >
> > > > I guess this would also fail with any other reason for not matching
> > > > CRCs in the first page, but I have not faulty NAND flash chip to
> > > > confirm that.
> > >
> > > Thanks for the whole report, it is interesting and should lead to fixes:
> > > - why does the controller refuses the datain op?
> >
> > See above.
> >
> > > - why nand_soft_waitrdy is not enough?
> >
> > I don't know. That's one reason I asked here.
> >
> > > - changing the condition in nand_change_read_column_op()
> > >
> > > Can you take care of these?
Now would be a perfect time to send these fixes. Could you work on them?
Thanks!
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Dahl <ada@thorsis.com>
Cc: linux-mtd@lists.infradead.org,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: mtd: nand: raw: Possible bug in nand_onfi_detect()?
Date: Mon, 25 Mar 2024 10:09:16 +0100 [thread overview]
Message-ID: <20240325100917.502c75b7@xps-13> (raw)
In-Reply-To: <20240307181931.440c9c3f@xps-13>
Hello Alexander,
> > > > The condition is true and nand_change_read_column_op() returns with
> > > > -EINVAL, because mtd->writesize and mtd->oobsize are not set yet in
> > > > that code path. Those are probably initialized later, maybe with
> > > > parameters read from that ONFI param page?
> > > >
> > > > Returning with error from nand_change_read_column_op() leads to
> > > > jumping out of nand_onfi_detect() early, and no ONFI param page is
> > > > evaluated at all, although the second or third page could be intact.
> > > >
> > > > I guess this would also fail with any other reason for not matching
> > > > CRCs in the first page, but I have not faulty NAND flash chip to
> > > > confirm that.
> > >
> > > Thanks for the whole report, it is interesting and should lead to fixes:
> > > - why does the controller refuses the datain op?
> >
> > See above.
> >
> > > - why nand_soft_waitrdy is not enough?
> >
> > I don't know. That's one reason I asked here.
> >
> > > - changing the condition in nand_change_read_column_op()
> > >
> > > Can you take care of these?
Now would be a perfect time to send these fixes. Could you work on them?
Thanks!
Miquèl
next prev parent reply other threads:[~2024-03-25 9:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 14:36 mtd: nand: raw: Possible bug in nand_onfi_detect()? Alexander Dahl
2024-03-06 14:36 ` Alexander Dahl
2024-03-06 15:48 ` Miquel Raynal
2024-03-06 15:48 ` Miquel Raynal
2024-03-07 16:02 ` Alexander Dahl
2024-03-07 16:02 ` Alexander Dahl
2024-03-07 17:19 ` Miquel Raynal
2024-03-07 17:19 ` Miquel Raynal
2024-03-25 9:09 ` Miquel Raynal [this message]
2024-03-25 9:09 ` Miquel Raynal
2024-03-25 9:59 ` Alexander Dahl
2024-03-25 9:59 ` Alexander Dahl
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=20240325100917.502c75b7@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=ada@thorsis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.