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]
Message-ID: <53712D10.40003@wwwdotorg.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ