linux-kernel - Re: [Pinctrl] A suggestion to avoid duplicated enabling operation on a pin's setting

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:	Mon, 12 May 2014 14:20:32 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	FanWu <fwu@...vell.com>
CC:	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org,
	"swarren@...dia.com" <swarren@...dia.com>,
	Chao Xie <cxie4@...vell.com>, Yilu Mao <ylmao@...vell.com>,
	Ning Jiang <njiang1@...vell.com>,
	Xiaofan Tian <tianxf@...vell.com>,
	Fangsuo Wu <fswu@...vell.com>
Subject: Re: [Pinctrl] A suggestion to avoid duplicated enabling operation
 on a pin's setting

On 05/07/2014 02:02 AM, FanWu wrote:
...
> I think the glitch you mentioned is indeed a problem for the vendors who
> define the "pinctrl-single,function-off" which will be activated when
> disabling setting.

"pinctrl-single,function-off" is one specific driver's way of
configuring what happens when a mux option is disabled. The issue
applies to all drivers that implement a mux option disable function.

...
> I considered my previous option 1 of avoiding duplicated calling
> enable_setting. If we want to avoid too much iteration in this solution,
> some mark variables need to be introduced, which may make code more
> complicated than the previous one.

Probably the best thing is to just remove the concept of "disable a mux
option". It doesn't make sense. All you can do with mux options is to
select some specific mux option. Disabling a mux option isn't something
that's logically possible. On some HW, perhaps you can do something
similar by tri-stating the pin or something, but that should be an
explicit part of the pinctrl state definition rather than an automatic
side-effect.

...
> Maybe another topic:
> In the original code, the Pin setting will be changed to the
> disabled/safe state when Pin state is switched if the old setting is not
> existed in new state rather than directly switched to the new Pin
> setting. Also a possible glitch?

That's not a glitch, since it's not a temporary state. The mux setting
starts out as configured by the old state, then switches one time to
whatever the disable function sets it to. After that, it won't switch
again, unless there's an explicit SW action to enable a new state.
--
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/