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, 15 Apr 2013 22:11:36 +0800
From:	Axel Lin <axel.lin@...ics.com>
To:	Bengt Jönsson <bengt.g.jonsson@...ricsson.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Lee Jones <lee.jones@...aro.org>,
	Yvan FILLION <yvan.fillion@...ricsson.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: ab8500: Fix get_mode for shared mode regulators

2013/4/15 Bengt Jönsson <bengt.g.jonsson@...ricsson.com>:
> On 04/15/2013 02:13 PM, Axel Lin wrote:
>>>
>>> I guess what you don't like with the current approach is that the driver
>>> returns REGULATOR_MODE_IDLE in some cases where the mode register is set
>>> to
>>> LP. But I think, with patch applied, the control may be wrong in some
>>> cases
>>> because the regulator framework will call get_mode and see that the mode
>>> is
>>> already correct and not call set_mode so lp_mode_req will not get
>>> updated. I
>>
>> I got your point now.
>>
>> My point is get_mode() should always return "correct" status by
>> reading register value.
>> And as you mentioned, regulator_set_mode() did check current mode and
>> won't call
>> set_mode callback if current mode is the same as the target mode.
>> And that is why this patch won't work.
>>
>> However, Make get_mode() return "incorrect" status to avoid above
>> issue looks wrong to me.
>>
>> Regards,
>> Axel
>
> I understand your point of view, but I think that the framework (as it is
> currently implemented) expects to get the requested mode of the regulator in
> this case, not the actual mode (in the shared mode register).The alternative
> could be to change the framework in some way.
>
> Any ideas? Otherwise I propose to keep the code and maybe add a comment.

It looks to me a simple fix is to just get rid of the check of old mode with
new mode setting.

Something like reverse of commit 500b4ac90d1103
"regulator: return set_mode is same mode is requested" would work.

Regards,
Axel
--
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