linux-kernel - RE: [PATCH V2 4/6] pinctrl: API changes to support multiple states per device

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, 29 Feb 2012 09:22:42 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Dong Aisheng <aisheng.dong@...escale.com>
CC:	Linus Walleij <linus.walleij@...ricsson.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"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 V2 4/6] pinctrl: API changes to support multiple states
 per device

Dong Aisheng wrote at Tuesday, February 28, 2012 11:47 PM:
> On Tue, Feb 28, 2012 at 01:27:30PM -0700, Stephen Warren wrote:
...
> > +static struct pinctrl *find_pinctrl(struct device *dev)
> > +{
> > +	struct pinctrl *p;
> > +
> > +	list_for_each_entry(p, &pinctrldev_list, node)
>
> s/pinctrldev_list/pinctrl_list ?

Uggh. I could have sworn I fixed that before. Perhaps I had the same
silly error somewhere else too. Thanks for catching it.
> 
> > +static int pinctrl_select_state_locked(struct pinctrl *p,
> > +				       struct pinctrl_state *state)
...
> > +	if (p->state) {
> > +		/*
> > +		 * The set of groups with a mux configuration in the old state
> > +		 * may not be identical to the set of groups with a mux setting
> > +		 * in the new state. While this might be unusual, it's entirely
> > +		 * possible for the "user"-supplied mapping table to be written
> > +		 * that way. For each group that was configured in the old state
> > +		 * but not in the new state, this code puts that group into a
> > +		 * safe/disabled state.
>
> It means the old state function of some groups may not have been disabled before
> enabling the new function mode.
> May it be a little error-prone?
> Maybe we can not depend on user to disable a function before enable another for
> a group when doing pinmux_enable_setting considering they may be different
> registers.

The idea here is that there are two cases:

1) (hopefully the typical case)

Group X HAS a mux function set in OLD state
Group X HAS a mux function set in NEW state

In this case, we simply call pinmux_enable_setting(new state).

We do this so that we can transition directly from the old state to the
new state without going through any artificial intermediate states, to
make the mux switching as glitchless as possible.

If the HW has some restriction where it has to operate like:

Old state -> idle -> new state

Rather than:

Old state -> new state

Then I think that should be taken care of within the individual driver;
given most mux selection is just a register field that feeds into a simple
signal mux in HW, such a requirement seems pretty unlikely to me, but you
never know.

2)

Group X HAS a mux function set in OLD state
Group X DOES NOT have a mux function set in NEW state

In this case, we call pinmux_disable_setting(old state) to ensure that
the pin is put into some idle state that can't interfere with any other
pin.

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