linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dong Aisheng <aisheng.dong@freescale.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Linus Walleij <linus.walleij@stericsson.com>,
	"B29396@freescale.com" <B29396@freescale.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"dongas86@gmail.com" <dongas86@gmail.com>,
	"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
	"thomas.abraham@linaro.org" <thomas.abraham@linaro.org>,
	"tony@atomide.com" <tony@atomide.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 08/20] pinctrl: Assume map table entries can't have a NULL name field
Date: Thu, 23 Feb 2012 11:56:41 +0800	[thread overview]
Message-ID: <20120223035640.GC9141@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC8E3@HQMAIL01.nvidia.com>

On Wed, Feb 22, 2012 at 07:39:42PM -0800, Stephen Warren wrote:
> Dong Aisheng wrote at Wednesday, February 22, 2012 8:35 PM:
> > On Wed, Feb 22, 2012 at 10:05:20AM -0800, Stephen Warren wrote:
> > > Dong Aisheng wrote at Tuesday, February 21, 2012 11:35 PM:
> > > > On Tue, Feb 21, 2012 at 09:46:01AM -0800, Stephen Warren wrote:
> > > > ....
> > > > > > we might just
> > > > > >
> > > > > > #define PIN_MAP_NAME_DEFAULT "default"
> > > > > > In <linux/pinctrl/consumer.h> and <linux/pinctrl/machine.h> alike,
> > > > > > maybe in some <linux/pinctrl/mapnames.h> that both of these
> > > > > > include?
> > > > > >
> > > > > > the have the driver ask for:
> > > > > >
> > > > > > sirfport->p = pinctrl_get(&pdev->dev, PIN_MAP_NAME_DEFAULT);
> > > > > >
> > > > > > (Similar changes can be done for U300, naming all its map
> > > > > > "default".)
> > > > >
> > > > > I guess we could just modify pinmux_get() such that if NULL is passed as
> > > > > the state name, it uses "default" instead internally. The disadvantage I
> > > > > see here is that someone reading the client driver and writing the mapping
> > > > > table then has to know that pinmux_get() does that internally, rather than
> > > > > it being obvious right in the client driver code.
> > > >
> > > > It looks like a way out.
> > >
> > > > The left problem seems to be that we may force the mapping table writer to
> > > > specify "default" name for map at least.
> > > > Is there any way to avoid it?
> > >
> > > That specific restriction has been present since the very first patch
> > > that created the pinctrl subsystem.
> >
> > Since i saw some code in pinctrl subsystem formerly like:
> > /*
> >  * If we're looking for a specific named map, this must match,
> >  * else we loop and look for the next.
> >  */
> > if (name != NULL) {
> > 	if (map->name == NULL)
> > 		continue;
> > 	if (strcmp(map->name, name))
> > 		continue;
> > }
> > So i guessed the map->name could be NULL in the original design.
> > Of course, if we used the convenience macro to define map, there's no
> > chance to make map name NULL.
> 
> Admittedly, the code is a little inconsistent. I was thinking of:
> 
> +int __init pinmux_register_mappings(struct pinmux_map const *maps,
> ...
> +       for (i = 0; i < num_maps; i++) {
> +               /* Sanity check the mapping */
> +               if (!maps[i].name) {
> +                       pr_err("failed to register map %d: "
> +                              "no map name given\n", i);
> +                       return -EINVAL;
> +               }
> 
> > We did not force users to must convenience macros, right?
> 
> No. In fact, my patches for Tegra's board file didn't always use them.
> 
> > > > I just think it may be better if we do not have such restriction.
> > >
> > > Given that all map entries have a name, I'd really prefer that all drivers
> > > had to request a specific matching name, rather than saying "just give me
> > > whatever is in the mapping table".
> > >
> > > I don't see this as a restriction, but more of a correctness issue;
> > > every mapping table entry has a name and drivers (or device tree bindings)
> > > define what that name must be, so why shouldn't drivers be required to
> > > request that specific name, and experience an error if the mapping table
> > > author didn't create that name?
> >
> > Yes, i agree.
> > Based on this point, i feel maybe internally convert NULL to a "default" name for
> > pinctrl_get does not make too much sense.
> > 
> > > regulator_get(dev, id) requires id != NULL.
> > >
> > > clk_get(dev, con_id) requires con_id != NULL in order to match a clock
> > > that has a non-NULL con_id defined (although clocks with a NULL con_id
> > > are also legal, in which case, the con_id parameter to clk_get is
> > > ignored)
> > >
> > > So pinctrl_get(dev, state) requiring state != NULL seems consistent
> > > with existing practice.
> >
> > Yes, it's true if given all map entries have a name.
> > 
> > Now i'm intend to the way you mentioned at:
> > https://lkml.org/lkml/2012/2/21/213
> > 
> > And i agree with the way you said:
> > If we continue to allow NULL names, I think we should change that to:
> > if name:
> >     match = map->name && !strcmp(name, map->name)
> > else:
> >     match = !map->name
> > 
> > And i think allowing map name to be NULL will make life easy for those
> > devices who do not support multi states.
> 
> It does make it a little convenient for board files, but isn't really
> practical to implement for device-tree unless we modify the binding to
> have something that means "no name". I'd rather not allow more options
> in the binding though.
> 
> What's wrong with writing e.g. PINCTRL_DEFAULT instead of NULL when calling
> pinctrl_get() or pinctrl_lookup_state() though? Given pinctrl.h having:
> 
> #define PINCTRL_DEFAULT "default"
> 
First, map writer needs know this logic.
Second, all as you said:
> > > every mapping table entry has a name and drivers (or device tree bindings)
> > > define what that name must be, so why shouldn't drivers be required to
> > > request that specific name, and experience an error if the mapping table
> > > author didn't create that name?
if want to keep align with regulator and clock,
i just feel a little that it does not make too much sense to
internally convert NULL to "default", right?

Regards
Dong Aisheng


  reply	other threads:[~2012-02-23  3:49 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-20  6:45 [PATCH 00/20] pinctrl: API change, config in mapping table Stephen Warren
2012-02-20  6:45 ` [PATCH 01/20] pinctrl: pinctrl_register_mappings() shouldn't be __init Stephen Warren
2012-02-20 21:01   ` Linus Walleij
2012-02-20  6:45 ` [PATCH 02/20] pinctrl: use list_add_tail instead of list_add Stephen Warren
2012-02-20 21:03   ` Linus Walleij
2012-02-20  6:45 ` [PATCH 03/20] pinctrl: Store mapping table as a list of chunks Stephen Warren
2012-02-20 21:08   ` Linus Walleij
2012-02-20  6:45 ` [PATCH 04/20] pinctrl: Record a pin owner, not mux function, when requesting pins Stephen Warren
2012-02-20 21:15   ` Linus Walleij
2012-02-21 17:23     ` Stephen Warren
2012-02-22  6:17       ` Linus Walleij
2012-02-20  6:45 ` [PATCH 05/20] pinctrl: Re-order pinmux.[ch] to match each-other Stephen Warren
2012-02-20 21:17   ` Linus Walleij
2012-02-20  6:45 ` [PATCH 06/20] pinctrl: Re-order pinconf.[ch] " Stephen Warren
2012-02-20 21:18   ` Linus Walleij
2012-02-20  6:45 ` [PATCH 07/20] pinctrl: core.c/h cleanups Stephen Warren
2012-02-20 21:20   ` Linus Walleij
2012-02-20  6:45 ` [PATCH 08/20] pinctrl: Assume map table entries can't have a NULL name field Stephen Warren
2012-02-20 21:42   ` Linus Walleij
2012-02-21 13:09     ` Dong Aisheng
2012-02-21 13:12       ` Linus Walleij
2012-02-21 17:46     ` Stephen Warren
2012-02-22  6:13       ` Linus Walleij
2012-02-22  6:34       ` Dong Aisheng
2012-02-22 18:05         ` Stephen Warren
2012-02-23  3:35           ` Dong Aisheng
2012-02-23  3:39             ` Stephen Warren
2012-02-23  3:56               ` Dong Aisheng [this message]
2012-02-23  3:53                 ` Stephen Warren
2012-02-23  4:48                   ` Dong Aisheng
2012-02-23 16:39                     ` Stephen Warren
2012-02-24  8:40                       ` Dong Aisheng
2012-02-21 13:08   ` Dong Aisheng
2012-02-21 17:38     ` Stephen Warren
2012-02-22  6:21       ` Dong Aisheng
2012-02-20  6:45 ` [PATCH 09/20] pinctrl: Disallow map table entries with NULL dev_name field Stephen Warren
2012-02-20 21:49   ` Linus Walleij
2012-02-22  6:46   ` Dong Aisheng
2012-02-20  6:45 ` [PATCH 10/20] pinctrl: Assume map table entries can't have a NULL ctrl_dev_name field Stephen Warren
2012-02-21 13:36   ` Linus Walleij
2012-02-22  6:49   ` Dong Aisheng
2012-02-20  6:45 ` [PATCH 11/20] pinctrl: Downgrade pinctrl_get warning when no maps are found Stephen Warren
2012-02-21 13:51   ` Linus Walleij
2012-02-22  5:54     ` Shawn Guo
2012-02-22  6:56     ` Dong Aisheng
2012-02-22 17:21       ` Stephen Warren
2012-02-23  3:48         ` Dong Aisheng
2012-02-20  6:45 ` [PATCH 12/20] pinctrl: Use dev_*() instead of pr_*(), add some msgs, minor cleanups Stephen Warren
2012-02-22  6:23   ` Linus Walleij
2012-02-22  7:01   ` Dong Aisheng
2012-02-20  6:45 ` [PATCH 13/20] pinctrl: Error if mapping table's control dev can't be found Stephen Warren
2012-02-21 13:58   ` Linus Walleij
2012-02-21 17:50     ` Stephen Warren
2012-02-20  6:45 ` [PATCH 14/20] pinctrl: Allocate sizeof(*p) instead of sizeof(struct foo) Stephen Warren
2012-02-22  6:25   ` Linus Walleij
2012-02-22  7:04   ` Dong Aisheng
2012-02-20  6:45 ` [PATCH 15/20] pinctrl: Fix and simplify locking Stephen Warren
2012-02-22 17:38   ` Linus Walleij
2012-02-22 18:26     ` Stephen Warren
2012-02-23  0:18       ` Stephen Warren
2012-02-20  6:45 ` [PATCH 16/20] pinctrl: Refactor struct pinctrl handling in core.c vs pinmux.c Stephen Warren
2012-02-22 17:18   ` Linus Walleij
2012-02-24 16:55   ` Dong Aisheng
2012-02-20  6:45 ` [PATCH 17/20] pinctrl: Add usecount to pins for muxing Stephen Warren
2012-02-22 17:21   ` Linus Walleij
2012-02-27  7:11   ` Dong Aisheng
2012-02-27 18:21     ` Stephen Warren
2012-02-20  6:45 ` [PATCH 18/20] pinctrl: Fix pinconf_groups_show() to emit newline Stephen Warren
2012-02-22 17:43   ` Linus Walleij
2012-02-20  6:45 ` [PATCH 19/20] pinctrl: API changes to support multiple states per device Stephen Warren
2012-02-23  5:54   ` Linus Walleij
2012-02-23 16:46     ` Stephen Warren
2012-02-27  9:07   ` Dong Aisheng
2012-02-27 18:37     ` Stephen Warren
2012-02-28  3:18       ` Dong Aisheng
2012-02-28 17:04         ` Stephen Warren
2012-02-29  2:26           ` Dong Aisheng
2012-02-20  6:46 ` [PATCH 20/20] pinctrl: Enhance mapping table to support pin config operations Stephen Warren
2012-02-23  6:08   ` Linus Walleij
2012-02-23 16:48     ` Stephen Warren
2012-02-23 21:13     ` Stephen Warren
2012-02-27 12:21   ` Dong Aisheng
2012-02-27 19:02     ` Stephen Warren
2012-02-28  3:41       ` Dong Aisheng
2012-02-20 21:51 ` [PATCH 00/20] pinctrl: API change, config in mapping table Linus Walleij

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=20120223035640.GC9141@shlinux2.ap.freescale.net \
    --to=aisheng.dong@freescale.com \
    --cc=B29396@freescale.com \
    --cc=dongas86@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawn.guo@linaro.org \
    --cc=swarren@nvidia.com \
    --cc=thomas.abraham@linaro.org \
    --cc=tony@atomide.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;
as well as URLs for NNTP newsgroup(s).