[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20170526110602.jtvxf76abks4v3xf@sirena.org.uk>
Date: Fri, 26 May 2017 12:06:02 +0100
From: Mark Brown <broonie@...nel.org>
To: Evgeniy Polyakov <zbr@...emap.net>
Cc: "Alex A. Mihaylov" <minimumlaw@...bler.ru>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sebastian Reichel <sre@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 1/4] Introduce regmap infrastructure over Maxim/Dalas
OneWire (W1) bus
On Thu, May 25, 2017 at 11:14:39PM +0300, Evgeniy Polyakov wrote:
> Frankly saying, your non-regmap version was so much simpler, smaller and cleaner.
> I wonder why did people force you to use regmap.
> Guys, please speak up, if you want driver authors to use THIS, it is really flawed.
> Sebastien, iirc it was your idea to use regmaps, what was the reason for this?
So, this is the first I've seen of this series but in general the main
reason for using regmap is that it allows best practice to be factored
out into common code both in terms of the I/O itself and also in terms
of framework code being able to provide regmap based helpers for common
operations so drivers need less code. The cache code is also really
useful for a lot of devices, it's a performance boost for reads and is
well optimized for restoring device state if you don't care about
sequencing (this is where some of the MMIO users come from). You also
get a bunch of debug support for free, things like the tracepoints and
debugfs files (those do work better if you describe the register map).
Looking at the code in the regmap patch I have to say I'm very surprised
if this is adding much complexity, usually moving to regmap is basically
a sed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists