linux-kernel - [PATCH 6/6] [RFC] firmware: arm_scmi: Add SCMI PM driver remove routine

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:   Wed, 17 Aug 2022 18:27:31 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc:     sudeep.holla@....com, cristian.marussi@....com
Subject: [PATCH 6/6] [RFC] firmware: arm_scmi: Add SCMI PM driver remove routine

Currently, when removing the SCMI PM driver not all the resources
registered with GenPD subsystem are currently properly de-registered.

As a side effect of this after a driver unload/load cycle you get a splat
with a few warnings like this:

debugfs: Directory 'BIG_CPU0' with parent 'pm_genpd' already present!
debugfs: Directory 'BIG_CPU1' with parent 'pm_genpd' already present!
debugfs: Directory 'LITTLE_CPU0' with parent 'pm_genpd' already present!
debugfs: Directory 'LITTLE_CPU1' with parent 'pm_genpd' already present!
debugfs: Directory 'LITTLE_CPU2' with parent 'pm_genpd' already present!
debugfs: Directory 'LITTLE_CPU3' with parent 'pm_genpd' already present!
debugfs: Directory 'BIG_SSTOP' with parent 'pm_genpd' already present!
debugfs: Directory 'LITTLE_SSTOP' with parent 'pm_genpd' already present!
debugfs: Directory 'DBGSYS' with parent 'pm_genpd' already present!
debugfs: Directory 'GPUTOP' with parent 'pm_genpd' already present!

Add a proper scmi_pm_domain_remove callback to the driver in order to
take care of all the needed cleanups not handled already by devres.

Signed-off-by: Cristian Marussi <cristian.marussi@....com>
---
The patch is marked as RFC since this solution can be controversial: what
about any 3rd party consumer of the above unregistered genpd domain ?
Should we even ever allow a PM driver like to be unloaded ?
---
 drivers/firmware/arm_scmi/scmi_pm_domain.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/firmware/arm_scmi/scmi_pm_domain.c b/drivers/firmware/arm_scmi/scmi_pm_domain.c
index 581d34c95769..4e27c3d66a83 100644
--- a/drivers/firmware/arm_scmi/scmi_pm_domain.c
+++ b/drivers/firmware/arm_scmi/scmi_pm_domain.c
@@ -138,9 +138,28 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
 	scmi_pd_data->domains = domains;
 	scmi_pd_data->num_domains = num_domains;

+	dev_set_drvdata(dev, scmi_pd_data);
+
 	return of_genpd_add_provider_onecell(np, scmi_pd_data);
 }

+static void scmi_pm_domain_remove(struct scmi_device *sdev)
+{
+	int i;
+	struct genpd_onecell_data *scmi_pd_data;
+	struct device *dev = &sdev->dev;
+	struct device_node *np = dev->of_node;
+
+	of_genpd_del_provider(np);
+
+	scmi_pd_data = dev_get_drvdata(dev);
+	for (i = 0; i < scmi_pd_data->num_domains; i++) {
+		if (!scmi_pd_data->domains[i])
+			continue;
+		pm_genpd_remove(scmi_pd_data->domains[i]);
+	}
+}
+
 static const struct scmi_device_id scmi_id_table[] = {
 	{ SCMI_PROTOCOL_POWER, "genpd" },
 	{ },
@@ -150,6 +169,7 @@ MODULE_DEVICE_TABLE(scmi, scmi_id_table);
 static struct scmi_driver scmi_power_domain_driver = {
 	.name = "scmi-power-domain",
 	.probe = scmi_pm_domain_probe,
+	.remove = scmi_pm_domain_remove,
 	.id_table = scmi_id_table,
 };
 module_scmi_driver(scmi_power_domain_driver);
-- 
2.32.0