From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Karol Lewandowski <lmctlx@gmail.com>
Cc: Karol Lewandowski <k.lewandowsk@samsung.com>,
Thomas Abraham <thomas.abraham@linaro.org>,
linux-kernel@vger.kernel.org, rpurdie@rpsys.net,
rob.herring@calxeda.com, grant.likely@secretlab.ca,
kgene.kim@samsung.com, myungjoo.ham@samsung.com,
kyungmin.park@samsung.com, dg77.kim@samsung.com,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, Rajendra Nayak <rnayak@ti.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>
Subject: Re: [PATCH v2 2/2] regulator: add device tree support for max8997
Date: Mon, 23 Jan 2012 19:33:00 +0000 [thread overview]
Message-ID: <20120123193259.GC26409@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F1DB34C.4030103@gmail.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] regulator: add device tree support for max8997
Date: Mon, 23 Jan 2012 19:33:00 +0000 [thread overview]
Message-ID: <20120123193259.GC26409@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F1DB34C.4030103@gmail.com>
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.
next prev parent reply other threads:[~2012-01-23 19:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 7:35 [PATCH v2 0/2] Add device tree support for MAX8997 Thomas Abraham
2012-01-12 7:35 ` Thomas Abraham
2012-01-12 7:35 ` [PATCH v2 1/2] mfd: add irq domain support for max8997 interrupts Thomas Abraham
2012-01-12 7:35 ` Thomas Abraham
2012-01-12 7:35 ` [PATCH v2 2/2] regulator: add device tree support for max8997 Thomas Abraham
2012-01-12 7:35 ` Thomas Abraham
2012-01-12 9:49 ` MyungJoo Ham
2012-01-12 9:49 ` MyungJoo Ham
2012-01-12 10:39 ` Thomas Abraham
2012-01-12 10:39 ` Thomas Abraham
2012-01-23 17:50 ` Karol Lewandowski
2012-01-23 17:50 ` Karol Lewandowski
2012-01-23 17:50 ` Karol Lewandowski
2012-01-23 18:20 ` Mark Brown
2012-01-23 18:20 ` Mark Brown
2012-01-23 19:21 ` Karol Lewandowski
2012-01-23 19:21 ` Karol Lewandowski
2012-01-23 19:33 ` Mark Brown [this message]
2012-01-23 19:33 ` Mark Brown
2012-01-25 9:55 ` Karol Lewandowski
2012-01-25 9:55 ` Karol Lewandowski
2012-01-25 11:26 ` Mark Brown
2012-01-25 11:26 ` Mark Brown
2012-01-25 12:02 ` Karol Lewandowski
2012-01-25 12:02 ` Karol Lewandowski
2012-01-25 13:32 ` Mark Brown
2012-01-25 13:32 ` Mark Brown
2012-01-26 15:28 ` Karol Lewandowski
2012-01-26 15:28 ` Karol Lewandowski
2012-01-26 16:17 ` Mark Brown
2012-01-26 16:17 ` Mark Brown
2012-01-27 9:58 ` Karol Lewandowski
2012-01-27 9:58 ` Karol Lewandowski
2012-01-27 11:19 ` Mark Brown
2012-01-27 11:19 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120123193259.GC26409@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=dg77.kim@samsung.com \
--cc=grant.likely@secretlab.ca \
--cc=k.lewandowsk@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=lmctlx@gmail.com \
--cc=m.szyprowski@samsung.com \
--cc=myungjoo.ham@samsung.com \
--cc=rnayak@ti.com \
--cc=rob.herring@calxeda.com \
--cc=rpurdie@rpsys.net \
--cc=s.nawrocki@samsung.com \
--cc=thomas.abraham@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.