From: Courtney Cavin <courtney.cavin@sonymobile.com>
To: Rob Herring <robh@kernel.org>
Cc: Stanimir Varbanov <svarbanov@mm-sol.com>,
Grant Likely <grant.likely@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"Ivan T. Ivanov" <iivanov@mm-sol.com>,
Josh Cartwright <joshc@codeaurora.org>,
Stephen Boyd <sboyd@codeaurora.org>
Subject: Re: [RFC PATCH 0/6] Support for QPNP PMIC's
Date: Wed, 25 Jun 2014 14:28:11 -0700 [thread overview]
Message-ID: <20140625212811.GD10905@sonymobile.com> (raw)
In-Reply-To: <CAL_Jsq+m0=L_JBF3_kqUdPUWUh38MEiw2zpTJawk9Xpk_kH2Xw@mail.gmail.com>
On Wed, Jun 25, 2014 at 11:18:57PM +0200, Rob Herring wrote:
> On Wed, Jun 25, 2014 at 1:04 PM, Courtney Cavin
> <courtney.cavin@sonymobile.com> wrote:
> > On Wed, Jun 25, 2014 at 01:07:13PM +0200, Stanimir Varbanov wrote:
> >> On 06/25/2014 01:36 AM, Courtney Cavin wrote:
> > Greg, Grant, Rob? What's the law?
>
> Generally sub-blocks of a device are handled as platform devices. If
> there is a good enough reason then creating a new device type may be
> okay, but we certainly wouldn't want every PMIC or MFD driver to go
> off and define their own bus. Probably not each vendor doing a bus
> either.
Thanks for the clarification!
> > On a related note, it would probably be a good idea to move much of the
> > platform resource stuff out of the platform code... so we don't
> > re-implement it over-and-over again.
>
> Which part is implemented over-and-over?
These two, and all the convenient wrapper/population functions:
struct resource *resource;
u32 num_resources;
-Courtney
next prev parent reply other threads:[~2014-06-25 21:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-20 12:21 [RFC PATCH 0/6] Support for QPNP PMIC's Stanimir Varbanov
2014-06-20 12:21 ` [RFC PATCH 1/6] dt: qpnp: add binding description of Qualcomm QPNP PMICs Stanimir Varbanov
2014-06-20 12:21 ` [RFC PATCH 2/6] qpnp: add support for " Stanimir Varbanov
2014-06-20 12:21 ` [RFC PATCH 3/6] dt: qcom: msm8974: add qpnp-spmi device nodes Stanimir Varbanov
2014-06-20 12:21 ` [RFC PATCH 4/6] rtc: add qpnp rtc driver Stanimir Varbanov
2014-06-20 12:21 ` [RFC PATCH 5/6] dt: msm8974: add qpnp rtc device node Stanimir Varbanov
2014-06-20 12:21 ` [RFC PATCH 6/6] dt: rtc: add binding document for rtc-qpnp Stanimir Varbanov
2014-06-24 22:36 ` [RFC PATCH 0/6] Support for QPNP PMIC's Courtney Cavin
2014-06-25 11:07 ` Stanimir Varbanov
2014-06-25 18:04 ` Courtney Cavin
2014-06-25 21:18 ` Rob Herring
2014-06-25 21:28 ` Courtney Cavin [this message]
2014-06-26 15:12 ` Stanimir Varbanov
2014-06-26 15:48 ` Stanimir Varbanov
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=20140625212811.GD10905@sonymobile.com \
--to=courtney.cavin@sonymobile.com \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=iivanov@mm-sol.com \
--cc=joshc@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=svarbanov@mm-sol.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox