linux-kernel - Re: [PATCH] regulator: do not balance 'boot-on' coupled regulators without constraints

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:   Fri, 5 Jun 2020 12:24:39 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Marek Szyprowski <m.szyprowski@...sung.com>, saravanak@...gle.com
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Mark Brown <broonie@...nel.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Krzysztof Kozlowski <krzk@...nel.org>, peron.clem@...il.com,
        Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        linux-samsung-soc@...r.kernel.org,
        Chanwoo Choi <cw00.choi@...sung.com>
Subject: Re: [PATCH] regulator: do not balance 'boot-on' coupled regulators
 without constraints

+Saravana,

On 05-06-20, 08:37, Marek Szyprowski wrote:
> Balancing of the 'boot-on' coupled regulators must wait until the clients
> set their constraints, otherwise the balancing code might change the
> voltage of the not-yet-constrained regulator to the value below the
> bootloader-configured operation point, what might cause a system crash.
> This is achieved by assuming that, the minimal voltage allowed for the
> given 'boot-on' regulator is equal to it's current voltage until
> consumers apply their constraints.
> 
> Suggested-by: Dmitry Osipenko <digetx@...il.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@...sung.com>
> ---
> This is yet another approach to fix the regulator coupling on
> Exynos5800/5422 SoCs in the regulator core. I agree with Dmitry that this
> issue is generic and if possible it should be handled in the core.
> 
> This patchset is another attempt to fix the regulator coupling on
> Exynos5800/5422 SoCs. Here are links to the previous attempts and
> discussions:
> 
> https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/
> https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@samsung.com/
> https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@linaro.org/
> https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@samsung.com/
> https://lore.kernel.org/linux-samsung-soc/57cf3a15-5d9b-7636-4c69-60742e8cfae6@samsung.com/
> 
> The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid
> XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is
> handled by devfreq. CPUfreq initialized quite early during boot and it
> starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during
> boot goes down and some low-frequency OPPs are selected, what in turn
> causes lowering "vdd_arm". This happens before devfreq applies its
> requirements on "vdd_int". Regulator balancing code reduces "vdd_arm"
> voltage value, what in turn causes lowering "vdd_int" value to the lowest
> possible value. This is much below the operation point of the wcore bus,
> which still runs at the highest frequency.
> 
> The issue was hard to notice because in the most cases the board managed
> to boot properly, even when the regulator was set to lowest value allowed
> by the regulator constraints. However, it caused some random issues,
> which can be observed as "Unhandled prefetch abort" or low USB stability.
> 
> Best regards
> Marek Szyprowski
> ---
>  drivers/regulator/core.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 03154f5b939f..7e9af7ea4bdf 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -3553,6 +3553,17 @@ static int regulator_get_optimal_voltage(struct regulator_dev *rdev,
>  		if (ret < 0)
>  			return ret;
>  
> +		/*
> +		 * If no constraints set yet and regulator has boot-on flag,
> +		 * keep its voltage unchanged
> +		 */
> +		if (tmp_min == 0 && c_rdevs[i]->constraints->boot_on) {
> +			ret = regulator_get_voltage_rdev(c_rdevs[i]);
> +			if (ret < 0)
> +				return ret;
> +			tmp_min = ret;
> +		}
> +
>  		ret = regulator_check_voltage(c_rdevs[i], &tmp_min, &tmp_max);
>  		if (ret < 0)
>  			return ret;

This is exactly what Saravana tried to solve earlier AFAIR, lets see what he has
to say here.

-- 
viresh