RE: [PATCH 08/20] pinctrl: Assume map table entries can't have aNULL name field

From: Stephen Warren
Date: Wed Feb 22 2012 - 13:05:49 EST


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.

> 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?

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.

--
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/