All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
To: Josh Cartwright <joshc@codeaurora.org>
Cc: Courtney Cavin <courtney.cavin@sonymobile.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	David Collins <collinsd@codeaurora.org>
Subject: Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
Date: Fri, 09 May 2014 15:45:30 +0300	[thread overview]
Message-ID: <1399639530.8165.32.camel@iivanov-dev> (raw)
In-Reply-To: <20140424181829.GA19254@joshc.qualcomm.com>


Hi, 

On Thu, 2014-04-24 at 13:18 -0500, Josh Cartwright wrote:
> On Wed, Apr 23, 2014 at 04:36:22PM -0700, Courtney Cavin wrote:
> > On Wed, Apr 23, 2014 at 11:46:26PM +0200, Josh Cartwright wrote:
> > > On Tue, Apr 22, 2014 at 05:31:49PM -0700, Courtney Cavin wrote:
> [..]

<snip>
> 
> 	$ git grep spmi-slave-container arch/arm/boot/dts
> 	arch/arm/boot/dts/qcom/msm-pm8019.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8019.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8110.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8110.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8226.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8226.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8841.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8841.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8916.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8916.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8941.dtsi:	spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pm8941.dtsi:	spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pma8084.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pma8084.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmd9635.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmd9635.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmi8962.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmi8962.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmiplutonium.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmiplutonium.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmplutonium.dtsi:		spmi-slave-container;
> 	arch/arm/boot/dts/qcom/msm-pmplutonium.dtsi:		spmi-slave-container;
> 
> [..]
> > > > +static const struct of_device_id pm8x41_id_table[] = {
> > > > +	{ .compatible = "qcom,pm8841", },
> > > > +	{ .compatible = "qcom,pm8941", },
> > > > +	{},
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, pm8x41_id_table);
> > > 
> > > I'm thinking we should probably have a generic compatible entry as well,
> > > "qcom,pmic-qpnp" or similar.  We should still specify in the binding
> > > that PMIC slaves specify a version-specific string as well as the
> > > generic string.  That is, a slave should have:
> > > 
> > > 	compatible = "qcom,pm8841", "qcom,pmic-qpnp";
> > > 
> > > ...in case we would ever need to differentiate in the future.
> > > 
> > > (I recall that in a previous version I had done this, but I don't
> > > remember why I had changed it..)
> >
> > I gave this some thought but came to the conclusion that there is no
> > benefit of adding a generic compatible to a new binding.  Please clarify
> > a use-case where this would be ... useful.
> 
> Having a generic compatible entry allows for easily supporting new PMICs
> without having to add yet another vacuous entry in the ID table.  In
> this case I think it's perfectly acceptable given that this driver isn't
> really defining a programming model for a specific device, but rather
> acting much more like a bus.
> 
> Requiring a specific PMIC listed before a generic one allows us an
> escape hatch in the future if for some reason we need to add a quirk for
> a specific PMIC.

Is there a conclusion on this issue? I am voting for generic name :-)
"qcom,pm-qpnp".

Further complication is that several sub function drivers expect to
runtime detect the exact version of the controller ("qcom, qpnp-iadc",
"qcom, qpnp-vadc", "qcom, qpnp-linear-charger").  This is realized by the
exported function of the driver "qcom, qpnp-revid". Would it be good
idea to merge qpnp-revid and "qcom,pm-qpnp" driver?

Regards,
Ivan

> 
>   Josh
> 
> [1]: git://codeaurora.org/quic/la/kernel/msm-3.10#msm-3.10
> 

  reply	other threads:[~2014-05-09 12:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23  0:31 [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs Courtney Cavin
2014-04-23  0:31 ` Courtney Cavin
2014-04-23  0:31 ` [PATCH 2/2] mfd: pm8x41: document device tree bindings Courtney Cavin
2014-04-23  0:31   ` Courtney Cavin
2014-04-23 10:50 ` [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs Lee Jones
2014-04-23 17:38   ` Courtney Cavin
2014-04-23 13:19 ` Ivan T. Ivanov
2014-04-23 18:16   ` Courtney Cavin
2014-04-23 20:34     ` Ivan T. Ivanov
2014-04-23 22:12       ` Courtney Cavin
2014-04-24  2:45   ` Rob Herring
2014-04-26  0:28   ` Frank Rowand
2014-04-26  0:40     ` Courtney Cavin
2014-04-26  0:53       ` Frank Rowand
2014-04-28  7:11     ` Ivan T. Ivanov
2014-05-07 18:35   ` Rob Herring
2014-04-23 21:46 ` Josh Cartwright
2014-04-23 23:36   ` Courtney Cavin
2014-04-24 18:18     ` Josh Cartwright
2014-05-09 12:45       ` Ivan T. Ivanov [this message]
2014-05-09 20:30         ` Courtney Cavin
2014-05-10  8:06           ` Ivan T. Ivanov
2014-04-26  1:38     ` David Collins

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=1399639530.8165.32.camel@iivanov-dev \
    --to=iivanov@mm-sol.com \
    --cc=collinsd@codeaurora.org \
    --cc=courtney.cavin@sonymobile.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=joshc@codeaurora.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sameo@linux.intel.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 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.