linux-kernel - Re: [PATCH 1/2] regulators: Add definition of regulator_set_voltage_time() for !CONFIG

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: <CAKohpomS24eoqJ7h9d_5mPsyXhmnRSMW4fiCT0JnLRy5U6ARgw@mail.gmail.com>
Date:	Wed, 4 Jun 2014 16:27:48 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arvind Chauhan <arvind.chauhan@....com>,
	Eduardo Valentin <edubezval@...il.com>,
	Pavel Machek <pavel@....cz>,
	Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH 1/2] regulators: Add definition of regulator_set_voltage_time()
 for !CONFIG_REGULATOR

On 4 June 2014 16:08, Mark Brown <broonie@...nel.org> wrote:
> Please, go and *think* about what's going on here.  I've repeatedly
> asked you to consider the case where we need to raise the voltage prior
> to raising the frequency for cpufreq but you've not responded to these
> requests either directly or in showing any sign of having understood the
> issue.

I replied to that only when I said:

- For platforms with regulators support, we _must_ check if the voltage
change is successful or not and fail if regulator_set_voltage() failed.

And what you wrote earlier was correct, we may end up with unstable
systems if we ramp frequencies even when changing voltage failed.

> If the code fails to change the voltage it needs to handle that
> (including remembering that attempts to lower the voltage fail); if the
> code handles the errors sensibly I would expect that to handle
> everything.

That's what I was asking, how should the code handle it? Code also
has to take care of platforms which haven't configured regulators
in kernel and want to use this generic driver.

Sorry if I still didn't answer it properly :(
--
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/