linux-kernel - [PATCH] regulator: Lookup unresolved parent supplies before regulators cleanup

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-next>] [day] [month] [year] [list]

Date:	Sun, 20 Mar 2016 23:39:46 -0300
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	linux-kernel@...r.kernel.org
Cc:	Javier Martinez Canillas <javier@....samsung.com>,
	<stable@...r.kernel.org>, Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>
Subject: [PATCH] regulator: Lookup unresolved parent supplies before regulators cleanup

Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
moved the regulator supplies lookup logic from the regulators registration
to the regulators get time.

Unfortunately, that changed the behavior of the regulator core since now a
parent supply with a child regulator marked as always-on, won't be enabled
unless a client driver attempts to get the child regulator during boot.

This patch makes the unresolved parent supplies to be looked up before the
regulators late cleanup, so those with a child marked as always on will be
enabled regardless if a driver attempted to get the child regulator or not.

That was the behavior before the mentioned commit, since parent supplies
were looked up at regulator registration time instead of during child get.

Cc: <stable@...r.kernel.org> # 4.3+
Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
Signed-off-by: Javier Martinez Canillas <javier@....samsung.com>

---
Hello,

The commit that caused this issue landed into v4.1 but $SUBJECT can't be
cherry-picked to older kernel versions than v4.3 without causing a merge
conflict. So I added v4.3+ to stable, please let me know if isn't right.

Best regards,
Javier

 drivers/regulator/core.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 6dd63523bcfe..15dbb771e1d8 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4376,6 +4376,11 @@ static int __init regulator_init(void)
 /* init early to allow our consumers to complete system booting */
 core_initcall(regulator_init);

+static int __init regulator_late_resolve_supply(struct device *dev, void *data)
+{
+	return regulator_resolve_supply(dev_to_rdev(dev));
+}
+
 static int __init regulator_late_cleanup(struct device *dev, void *data)
 {
 	struct regulator_dev *rdev = dev_to_rdev(dev);
@@ -4436,6 +4441,14 @@ static int __init regulator_init_complete(void)
 	if (of_have_populated_dt())
 		has_full_constraints = true;

+	/* At this point there may be regulators that were not looked
+	 * up by a client driver, so its parent supply was not resolved
+	 * and could be wrongly disabled when needed to remain enabled
+	 * to meet their child constraints.
+	 */
+	class_for_each_device(&regulator_class, NULL, NULL,
+			      regulator_late_resolve_supply);
+
 	/* If we have a full configuration then disable any regulators
 	 * we have permission to change the status for and which are
 	 * not in use or always_on.  This is effectively the default
-- 
2.5.0