From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: <marek.vasut@gmail.com>, <cyrille.pitchen@microchip.com>,
<dwmw2@infradead.org>, <computersforpeace@gmail.com>,
<richard@nod.at>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Cristian.Birsan@microchip.com, nicolas.ferre@microchip.com
Subject: Re: [PATCH] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Date: Sun, 24 Jun 2018 22:00:03 +0200 [thread overview]
Message-ID: <20180624220003.5faaae8c@bbrezillon> (raw)
In-Reply-To: <20180608134818.21387-2-tudor.ambarus@microchip.com>
Hi Tudor,
Just one minor comment, I'll let Marek review the patch in more details.
On Fri, 8 Jun 2018 16:48:18 +0300
Tudor Ambarus <tudor.ambarus@microchip.com> wrote:
> /*
> * Erase an address range on the nor chip. The address range may extend
> * one or more erase sectors. Return an error is there is a problem erasing.
> @@ -511,9 +721,11 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
> dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
> (long long)instr->len);
>
> - div_u64_rem(instr->len, mtd->erasesize, &rem);
> - if (rem)
> - return -EINVAL;
> + if (likely(spi_nor_has_uniform_erase(nor))) {
To be honest, I don't think the likely() makes any difference here,
given the time it takes to actually erase the block. Can we just drop
it?
> + div_u64_rem(instr->len, mtd->erasesize, &rem);
> + if (rem)
> + return -EINVAL;
> + }
Regards,
Boris
next prev parent reply other threads:[~2018-06-24 20:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-08 13:48 [PATCH] add support to non-uniform SFDP SPI NOR flash memories Tudor Ambarus
2018-06-08 13:48 ` [PATCH] mtd: spi-nor: " Tudor Ambarus
2018-06-24 20:00 ` Boris Brezillon [this message]
2018-07-09 14:48 ` Tudor Ambarus
2018-06-08 13:54 ` [PATCH] " Cyrille Pitchen
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=20180624220003.5faaae8c@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=Cristian.Birsan@microchip.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@microchip.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=nicolas.ferre@microchip.com \
--cc=richard@nod.at \
--cc=tudor.ambarus@microchip.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