From: b29396@freescale.com (Dong Aisheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/7] mfd: add syscon driver based on regmap
Date: Mon, 3 Sep 2012 10:31:03 +0800 [thread overview]
Message-ID: <20120903023102.GA11891@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <20120831012626.GA7726@r65073-Latitude-D630>
On Fri, Aug 31, 2012 at 09:26:29AM +0800, Shawn Guo wrote:
> On Wed, Aug 29, 2012 at 06:56:52PM +0800, Dong Aisheng wrote:
> > +config MFD_SYSCON
> > + bool "System Controller Register R/W Based on Regmap"
>
> If the driver only compiles and works for device tree probe, we should
> have the following?
>
> depends on OF
>
Correct.
For currently it only supports dt.
> > + select REGMAP_MMIO
> > + help
> > + Select this option to enable accessing system control registers
> > + via regmap.
> > +
>
> <snip>
>
> > +struct regmap *syscon_node_to_regmap(struct device_node *np)
> > +{
> > + struct syscon *syscon;
> > + struct device *dev;
> > +
> > + dev = driver_find_device(&syscon_driver.driver, NULL, np,
> > + syscon_match);
> > + of_node_put(np);
>
> This looks a little unnatural to me. Function syscon_node_to_regmap
> becomes an API visible to clients, who might never know that np will
> be put inside the API. I'm saying the client may also call of_node_put
> to put the node they get.
We probably could add a comment here for the API to avoid this happen.
>
> I think of_node_put should be moved out from here and put into
> syscon_node_to_regmap and syscon_regmap_lookup_by_compatible.
>
I guess no, if you want to move of_node_put into syscon_regmap_lookup_by_phandle,
then syscon_regmap_lookup_by_phandle has the same issue.
Actually i had considered your concern when writing this API...
The original purpose of doing like that is saving some duplicated 'of_node_put'
and make the API easy to use.
I searched the kernel dt code and found it existed some similar cases.
e.g: of_irq_find_parent, of_get_next_parent
So it looks to me that it may be usually to do like that for the cases that
the conversion from a node to other thing since the client may only care
about the things converted. For our case, it's regmap.
So i can't think it make too much sense for all client driver have to write
duplicated and meaningless 'of_node_put' code.
Regards
Dong Aisheng
> > +
> > + if (!dev)
> > + return ERR_PTR(-EPROBE_DEFER);
> > +
> > + syscon = dev_get_drvdata(dev);
> > +
> > + return syscon->regmap;
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
> > +
> > +struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_find_compatible_node(NULL, NULL, s);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> > +
> > +struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
> > + const char *property)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_parse_phandle(np, property, 0);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
WARNING: multiple messages have this Message-ID (diff)
From: Dong Aisheng <b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Zhao Richard-B20223
<B20223-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org"
<linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org"
<s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
"broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org"
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org"
<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
"kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org"
<kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
"lrg-l0cyMroinI0@public.gmane.org"
<lrg-l0cyMroinI0@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org"
<sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Subject: Re: [PATCH v4 1/7] mfd: add syscon driver based on regmap
Date: Mon, 3 Sep 2012 10:31:03 +0800 [thread overview]
Message-ID: <20120903023102.GA11891@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <20120831012626.GA7726@r65073-Latitude-D630>
On Fri, Aug 31, 2012 at 09:26:29AM +0800, Shawn Guo wrote:
> On Wed, Aug 29, 2012 at 06:56:52PM +0800, Dong Aisheng wrote:
> > +config MFD_SYSCON
> > + bool "System Controller Register R/W Based on Regmap"
>
> If the driver only compiles and works for device tree probe, we should
> have the following?
>
> depends on OF
>
Correct.
For currently it only supports dt.
> > + select REGMAP_MMIO
> > + help
> > + Select this option to enable accessing system control registers
> > + via regmap.
> > +
>
> <snip>
>
> > +struct regmap *syscon_node_to_regmap(struct device_node *np)
> > +{
> > + struct syscon *syscon;
> > + struct device *dev;
> > +
> > + dev = driver_find_device(&syscon_driver.driver, NULL, np,
> > + syscon_match);
> > + of_node_put(np);
>
> This looks a little unnatural to me. Function syscon_node_to_regmap
> becomes an API visible to clients, who might never know that np will
> be put inside the API. I'm saying the client may also call of_node_put
> to put the node they get.
We probably could add a comment here for the API to avoid this happen.
>
> I think of_node_put should be moved out from here and put into
> syscon_node_to_regmap and syscon_regmap_lookup_by_compatible.
>
I guess no, if you want to move of_node_put into syscon_regmap_lookup_by_phandle,
then syscon_regmap_lookup_by_phandle has the same issue.
Actually i had considered your concern when writing this API...
The original purpose of doing like that is saving some duplicated 'of_node_put'
and make the API easy to use.
I searched the kernel dt code and found it existed some similar cases.
e.g: of_irq_find_parent, of_get_next_parent
So it looks to me that it may be usually to do like that for the cases that
the conversion from a node to other thing since the client may only care
about the things converted. For our case, it's regmap.
So i can't think it make too much sense for all client driver have to write
duplicated and meaningless 'of_node_put' code.
Regards
Dong Aisheng
> > +
> > + if (!dev)
> > + return ERR_PTR(-EPROBE_DEFER);
> > +
> > + syscon = dev_get_drvdata(dev);
> > +
> > + return syscon->regmap;
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
> > +
> > +struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_find_compatible_node(NULL, NULL, s);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> > +
> > +struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
> > + const char *property)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_parse_phandle(np, property, 0);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
WARNING: multiple messages have this Message-ID (diff)
From: Dong Aisheng <b29396@freescale.com>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linus.walleij@stericsson.com" <linus.walleij@stericsson.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"sameo@linux.intel.com" <sameo@linux.intel.com>,
"lrg@ti.com" <lrg@ti.com>,
"broonie@opensource.wolfsonmicro.com"
<broonie@opensource.wolfsonmicro.com>,
Zhao Richard-B20223 <B20223@freescale.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>
Subject: Re: [PATCH v4 1/7] mfd: add syscon driver based on regmap
Date: Mon, 3 Sep 2012 10:31:03 +0800 [thread overview]
Message-ID: <20120903023102.GA11891@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <20120831012626.GA7726@r65073-Latitude-D630>
On Fri, Aug 31, 2012 at 09:26:29AM +0800, Shawn Guo wrote:
> On Wed, Aug 29, 2012 at 06:56:52PM +0800, Dong Aisheng wrote:
> > +config MFD_SYSCON
> > + bool "System Controller Register R/W Based on Regmap"
>
> If the driver only compiles and works for device tree probe, we should
> have the following?
>
> depends on OF
>
Correct.
For currently it only supports dt.
> > + select REGMAP_MMIO
> > + help
> > + Select this option to enable accessing system control registers
> > + via regmap.
> > +
>
> <snip>
>
> > +struct regmap *syscon_node_to_regmap(struct device_node *np)
> > +{
> > + struct syscon *syscon;
> > + struct device *dev;
> > +
> > + dev = driver_find_device(&syscon_driver.driver, NULL, np,
> > + syscon_match);
> > + of_node_put(np);
>
> This looks a little unnatural to me. Function syscon_node_to_regmap
> becomes an API visible to clients, who might never know that np will
> be put inside the API. I'm saying the client may also call of_node_put
> to put the node they get.
We probably could add a comment here for the API to avoid this happen.
>
> I think of_node_put should be moved out from here and put into
> syscon_node_to_regmap and syscon_regmap_lookup_by_compatible.
>
I guess no, if you want to move of_node_put into syscon_regmap_lookup_by_phandle,
then syscon_regmap_lookup_by_phandle has the same issue.
Actually i had considered your concern when writing this API...
The original purpose of doing like that is saving some duplicated 'of_node_put'
and make the API easy to use.
I searched the kernel dt code and found it existed some similar cases.
e.g: of_irq_find_parent, of_get_next_parent
So it looks to me that it may be usually to do like that for the cases that
the conversion from a node to other thing since the client may only care
about the things converted. For our case, it's regmap.
So i can't think it make too much sense for all client driver have to write
duplicated and meaningless 'of_node_put' code.
Regards
Dong Aisheng
> > +
> > + if (!dev)
> > + return ERR_PTR(-EPROBE_DEFER);
> > +
> > + syscon = dev_get_drvdata(dev);
> > +
> > + return syscon->regmap;
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
> > +
> > +struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_find_compatible_node(NULL, NULL, s);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> > +
> > +struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
> > + const char *property)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_parse_phandle(np, property, 0);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
next prev parent reply other threads:[~2012-09-03 2:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-29 10:56 [PATCH v4 0/7] add syscon driver based on regmap for general registers access Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` [PATCH v4 1/7] mfd: add syscon driver based on regmap Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-31 1:26 ` Shawn Guo
2012-08-31 1:26 ` Shawn Guo
2012-08-31 1:26 ` Shawn Guo
2012-09-03 2:31 ` Dong Aisheng [this message]
2012-09-03 2:31 ` Dong Aisheng
2012-09-03 2:31 ` Dong Aisheng
2012-09-03 3:09 ` Shawn Guo
2012-09-03 3:09 ` Shawn Guo
2012-09-03 8:02 ` Dong Aisheng
2012-09-03 8:02 ` Dong Aisheng
2012-09-03 8:02 ` Dong Aisheng
2012-08-29 10:56 ` [PATCH v4 2/7] ARM: imx6q: add iomuxc gpr support into syscon Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-31 2:02 ` Shawn Guo
2012-08-31 2:02 ` Shawn Guo
2012-08-31 2:02 ` Shawn Guo
2012-09-03 2:46 ` Dong Aisheng
2012-09-03 2:46 ` Dong Aisheng
2012-09-03 2:46 ` Dong Aisheng
2012-08-29 10:56 ` [PATCH v4 3/7] ARM: imx6q: add anatop " Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` [PATCH v4 4/7] regulator: anatop-regulator: convert to use syscon to access anatop register Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` [PATCH v4 5/7] ARM: imx6q: convert to use syscon to access anatop registers Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` [PATCH v4 6/7] ARM: dts: imx6q: add simple-bus compatible string for anatop Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` [PATCH v4 7/7] mfd: anatop-mfd: remove anatop driver Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-29 10:56 ` Dong Aisheng
2012-08-31 1:39 ` Shawn Guo
2012-08-31 1:39 ` Shawn Guo
2012-08-31 1:39 ` Shawn Guo
2012-09-03 2:34 ` Dong Aisheng
2012-09-03 2:34 ` Dong Aisheng
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=20120903023102.GA11891@shlinux2.ap.freescale.net \
--to=b29396@freescale.com \
--cc=linux-arm-kernel@lists.infradead.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.