[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141128150729.GP7712@sirena.org.uk>
Date: Fri, 28 Nov 2014 15:07:29 +0000
From: Mark Brown <broonie@...nel.org>
To: Krzysztof Kozlowski <k.kozlowski@...sung.com>
Cc: Lee Jones <lee.jones@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-samsung-soc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Kukjin Kim <kgene@...nel.org>,
Kyungmin Park <kyungmin.park@...sung.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic
regulator bindings
On Fri, Nov 28, 2014 at 03:14:04PM +0100, Krzysztof Kozlowski wrote:
> On piÄ…, 2014-11-28 at 11:38 +0000, Mark Brown wrote:
> > This sort of thing is a sign that we're not saving much by moving the
> > parsing to the core and perhaps there's more flexiblity here...
> The driver receive callbacks (or exposes other kind of interface) for
> other core-generalized code. Recent example is parsing regulator mode
> (added by Javier) and .of_map_mode() callback.
Right, but that's actually doing some device specific translation and
successfully factoring out the bulk of the code - the fact that it's
taking parameters and returning data is a good sign. This is a callback
placed randomly away from any other related code (adding to the
confusion - it's not integrated into the rest of the flow around this at
all) without a clear purpose.
> I thought how to do this without this additional set_ena_gpio() call.
> One way would be to extend the regulator modes (FAST/IDLE/STANDBY/ and
> GPIO) but this would look somehow unnatural.
Yes, that's absolutely hideous.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists