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 14:41:14 +0200
From:	Bengt Jönsson <bengt.g.jonsson@...ricsson.com>
To:	Axel Lin <axel.lin@...ics.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

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.

Regards,

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