[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200427172336.ihezwq3wn75m7k3l@yadavpratyush.com>
Date: Mon, 27 Apr 2020 22:53:36 +0530
From: Pratyush Yadav <me@...avpratyush.com>
To: Yicong Yang <yangyicong@...ilicon.com>
Cc: Pratyush Yadav <p.yadav@...com>,
Tudor Ambarus <tudor.ambarus@...rochip.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Mark Brown <broonie@...nel.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Ludovic Desroches <ludovic.desroches@...rochip.com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-spi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Sekhar Nori <nsekhar@...com>
Subject: Re: [PATCH v4 05/16] mtd: spi-nor: default to address width of 3 for
configurable widths
Hi Yicong,
On 26/04/20 11:53AM, Yicong Yang wrote:
> On 2020/4/25 2:43, Pratyush Yadav wrote:
> > JESD216D.01 says that when the address width can be 3 or 4, it defaults
> > to 3 and enters 4-byte mode when given the appropriate command. So, when
> > we see a configurable width, default to 3 and let flash that default to
> > 4 change it in a post-bfpt fixup.
> >
> > This fixes SMPT parsing for flashes with configurable address width. If
> > the SMPT descriptor advertises variable address width, we use
> > nor->addr_width as the address width. But since it was not set to any
> > value from the SFDP table, the read command uses an address width of 0,
> > resulting in an incorrect read being issued.
> >
> > Signed-off-by: Pratyush Yadav <p.yadav@...com>
> > ---
> > drivers/mtd/spi-nor/sfdp.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> > index f917631c8110..5cecc4ba2141 100644
> > --- a/drivers/mtd/spi-nor/sfdp.c
> > +++ b/drivers/mtd/spi-nor/sfdp.c
> > @@ -460,6 +460,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> > /* Number of address bytes. */
> > switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
> > case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
> > + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
> > nor->addr_width = 3;
> > break;
>
> Should we also assign address width to 3 in default condition. At least we should not
> leave it uninitialized here.
The default condition would be taken when this field is 3. The value 3
is reserved, and so no current device should use this value. That said,
I don't see any downsides of doing so. If the value 3 means something
else in later revisions of the standard, this code would need to change
anyway. If not, we would use a relatively sane default for devices with
a faulty BFPT.
I haven't received any comments on my series so far. If end up having to
re-roll it, I will add this change. Otherwise, I'm not sure if it is a
good idea to re-roll a 16-patch series for a one liner that isn't fixing
some major bug. In that case, maybe you can send an independent patch
that does this after mine is merged?
--
Regards,
Pratyush Yadav
Powered by blists - more mailing lists