From: Pratyush Yadav <p.yadav@ti.com>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Boris Brezillon <bbrezillon@kernel.org>,
Richard Weinberger <richard@nod.at>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
linux-mtd@lists.infradead.org,
Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: [PATCH] mtd: spi-nor: sfdp: Fix SMPT parsing when 4BAIT table is before SMPT
Date: Fri, 18 Dec 2020 19:45:50 +0530 [thread overview]
Message-ID: <20201218141550.f2ik6lw65ly4lca5@ti.com> (raw)
In-Reply-To: <20201212115817.5122-1-vigneshr@ti.com>
Hi Vignesh,
On 12/12/20 05:28PM, Vignesh Raghavendra wrote:
> If 4BAIT table appears before SMPT then, nor->addr_width is set to 4 before
> SMPT table is parsed. This causes SMPT parser code to use addr_width of 4
> for reading current sector map configuration in spi_nor_get_map_in_use()
> if SMPT_CMD_ADDRESS_LEN reads SMPT_CMD_ADDRESS_LEN_USE_CURRENT (see
> spi_nor_smpt_addr_width()). Instead code should be using the value
> presented by BFPT_DWORD1_ADDRESS_BYTES field. On S28HS family of devices
> this bug leads to selection of invalid sector mapping thus causing erase
> and write failures.
>
> Fix this by parsing 4BAIT address table at the very end after all other
> parameter tables are parsed.
I'm not convinced this is the best way to go about this. What if we have
another table tomorrow that introduces some other side effect? Will we
special-case all those as well? IMO a better way of going about this
would be to make these parsers not affect the current state of the
flash, but instead store that information as a possible future state of
the flash. Then we can use that to finally decide what we want to do in
spi_nor_set_addr_width(). In fact, that information is already stored
via SNOR_F_HAS_4BAIT (though I'm not too opposed to adding a
nor->params->addr_width).
I see this as a cleaner alternative to your approach. We do need to be
careful about any obscure bugs here like with [0] though.
[0] https://lore.kernel.org/linux-mtd/20201006132346.12652-1-bert@biot.com/
--
Regards,
Pratyush Yadav
Texas Instruments India
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2020-12-18 14:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-12 11:58 [PATCH] mtd: spi-nor: sfdp: Fix SMPT parsing when 4BAIT table is before SMPT Vignesh Raghavendra
2020-12-18 14:15 ` Pratyush Yadav [this message]
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=20201218141550.f2ik6lw65ly4lca5@ti.com \
--to=p.yadav@ti.com \
--cc=bbrezillon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=tudor.ambarus@microchip.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