[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180624220003.5faaae8c@bbrezillon>
Date: Sun, 24 Jun 2018 22:00:03 +0200
From: Boris Brezillon <boris.brezillon@...tlin.com>
To: Tudor Ambarus <tudor.ambarus@...rochip.com>
Cc: <marek.vasut@...il.com>, <cyrille.pitchen@...rochip.com>,
<dwmw2@...radead.org>, <computersforpeace@...il.com>,
<richard@....at>, linux-mtd@...ts.infradead.org,
linux-kernel@...r.kernel.org, Cristian.Birsan@...rochip.com,
nicolas.ferre@...rochip.com
Subject: Re: [PATCH] mtd: spi-nor: add support to non-uniform SFDP SPI NOR
flash memories
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@...rochip.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
Powered by blists - more mailing lists