[PATCH 0/3] mtd: rawnand: brcmnand: Convert to exec_op()

From: Boris Brezillon <boris.brezillon@collabora.com>
To: Kamal Dasu <kdasu.kdev@gmail.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	linux-mtd@lists.infradead.org
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Scott Branden <sbranden@broadcom.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Ray Jui <rjui@broadcom.com>, Lee Jones <lee@kernel.org>,
	Eric Anholt <eric@anholt.net>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org,
	Richard Weinberger <richard@nod.at>
Subject: [PATCH 0/3] mtd: rawnand: brcmnand: Convert to exec_op()
Date: Sat,  2 May 2020 18:34:29 +0200	[thread overview]
Message-ID: <20200502163432.1543243-1-boris.brezillon@collabora.com> (raw)

Hello,

A bit of context to explain the motivation behind those conversions
I've been sending for the last couple of weeks. The raw NAND subsystem
carries a lot of history which makes any rework not only painful, but
also subject to regressions which we only detect when someone dares to
update its kernel on one of those ancient HW (I'm not saying brcmnand
is one of those ancient hardware BTW, but others in the NAND directory
are pretty old). While carrying drivers for old HW is not a problem per
se, carrying ancient and unmaintained drivers that are not converted to
new APIs is a maintenance burden (again, that does not really apply to
brcmnand, as Kamal as always prompt to reply to patches targeting this
driver), hence this massive conversion attempt I'm conducting here.

So here is a series converting the brcmnand NAND controller driver to
exec_op(). It's worth noting that I took the simplest path for this
implementation, using low-level operations for everything that's passed
to exec_op(). There are 2 reasons to that, the first one is that I
don't have the hardware to test and also don't know how this series
will be received so, I decided to take the quickest approach. But even
if we put that aside, I'm not sure the extra complexity implied by
the specialized operation handlers would be worth it, given that the
read/write page paths (those where performance really matters) are
already optimized (see the {read,write}_page[_raw]() implementations).
That leaves us with things that are only executed at boot time (ID,
PARAM_PAGE reads), or things that are simple enough (STATUS read,
ERASE) to not generate to much overhead if we don't use the dedicated
hardware functions. I'm of course open to reworking that part if someone
can validate my changes and come up with numbers showing that the
dedicated functions approach improves perfs.

Regards,

Boris

Boris Brezillon (3):
  mtd: rawnand: Add the concept of destructive operation
  mtd: rawnand: bcrmnand: Add exec_op() support
  mtd: rawnand: brcmnand: Get rid of the legacy interface implementation

 drivers/mtd/nand/raw/brcmnand/brcmnand.c | 248 +++++------------------
 include/linux/mtd/rawnand.h              |  11 +
 2 files changed, 66 insertions(+), 193 deletions(-)

-- 
2.25.3

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/