lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 22 Feb 2012 10:05:20 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Dong Aisheng <aisheng.dong@...escale.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	"B29396@...escale.com" <B29396@...escale.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"dongas86@...il.com" <dongas86@...il.com>,
	"shawn.guo@...aro.org" <shawn.guo@...aro.org>,
	"thomas.abraham@...aro.org" <thomas.abraham@...aro.org>,
	"tony@...mide.com" <tony@...mide.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 08/20] pinctrl: Assume map table entries can't have a
 NULL name field

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ