From: Boris Brezillon <boris.brezillon@bootlin.com>
To: <Tudor.Ambarus@microchip.com>
Cc: <alexander.sverdlin@nokia.com>, <linux-mtd@lists.infradead.org>,
<marek.vasut@gmail.com>, <dwmw2@infradead.org>,
<computersforpeace@gmail.com>, <richard@nod.at>,
<Cristian.Birsan@microchip.com>
Subject: Re: [RFC] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Date: Thu, 15 Nov 2018 11:46:20 +0100 [thread overview]
Message-ID: <20181115114620.36ff32c7@bbrezillon> (raw)
In-Reply-To: <a38ad0f7-e51a-158e-e074-2b1cdabecd16@microchip.com>
On Wed, 14 Nov 2018 08:00:44 +0000
<Tudor.Ambarus@microchip.com> wrote:
> Hi, Alexander,
>
> On 11/13/2018 06:58 PM, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
> > Hello Tudor and all,
> >
> > first of all, thank you for your work on SFDP support in Linux!
> >
> > Unfortunately, I'm debugging a regression caused by 5390a8df769ec
> > "mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories"
> > in [out of tree] support for S25FS128S.
> >
> > The culprit is the following part of your patch:
> >
> > /*
> > * For non-uniform SPI flash memory, set mtd->erasesize to the
> > * maximum erase sector size. No need to set nor->erase_opcode.
> > */
> > for (i = SNOR_ERASE_TYPE_MAX - 1; i >= 0; i--) {
> > if (map->erase_type[i].size) {
> > erase = &map->erase_type[i];
> > break;
> > }
> > }
> >
> > The problem in our case is, we have existing partitioning with 128k partitions
> > (the Flash itself supports 256k and 64k erasesize, depending on configuration).
> > The chip is configured for 64k erasesize, non-uniform mapping.
> >
> > The mapping itself is being detected correctly, but when it comes to the code
> > snippet above, it selects the biggest erasesize from all sizes advertised in
> > SFDP, including 256k, which is not applicable to the current configuration.
>
> The fix would be to save the supported erase types when parsing the SFDP SMPT
> table and use those instead.
Alexander, Tudor, can one of you work on such a fix?
next prev parent reply other threads:[~2018-11-15 10:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 16:58 [RFC] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories Sverdlin, Alexander (Nokia - DE/Ulm)
2018-11-14 8:00 ` Tudor.Ambarus
2018-11-14 9:10 ` Boris Brezillon
2018-11-15 10:46 ` Boris Brezillon [this message]
2018-11-15 11:36 ` Sverdlin, Alexander (Nokia - DE/Ulm)
2018-11-16 11:43 ` Tudor.Ambarus
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=20181115114620.36ff32c7@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=Cristian.Birsan@microchip.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=alexander.sverdlin@nokia.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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.