[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120123193259.GC26409@opensource.wolfsonmicro.com>
Date: Mon, 23 Jan 2012 19:33:00 +0000
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Karol Lewandowski <lmctlx@...il.com>
Cc: Karol Lewandowski <k.lewandowsk@...sung.com>,
Thomas Abraham <thomas.abraham@...aro.org>,
linux-kernel@...r.kernel.org, rpurdie@...ys.net,
rob.herring@...xeda.com, grant.likely@...retlab.ca,
kgene.kim@...sung.com, myungjoo.ham@...sung.com,
kyungmin.park@...sung.com, dg77.kim@...sung.com,
linux-arm-kernel@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org, Rajendra Nayak <rnayak@...com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Sylwester Nawrocki <s.nawrocki@...sung.com>
Subject: Re: [PATCH v2 2/2] regulator: add device tree support for max8997
On Mon, Jan 23, 2012 at 08:21:48PM +0100, Karol Lewandowski wrote:
> On 01/23/2012 07:20 PM, Mark Brown wrote:
> >Documentation/SubmittingPatches please...
> I should have stated explicitly that purpose of this patch (I should
> have called it sniplet) was to show my point only.
> IMHO it's still up to debate how above problem should be solved.
It looks like a reasonable solution to me, and it wouldn't conflict with
any better solution that does come along.
> I'm not entirely sure that we really need things like e.g. "EN32KHz
> AP" in DT (nor in platform data, for that matter). I would like to
> see Thomas' opinion first.
The 32kHz crystals are a bit of an odd case, really those should be
handled by the clock API but obviously that's stalled and has been for
quite some time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists