@@ -280,6 +280,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
struct of_phandle_args args;
struct device_node *cpu_np;
struct device *cpu_dev;
+ struct resource *res;
void __iomem *base;
struct qcom_cpufreq_data *data;
int ret, index;
@@ -303,9 +304,13 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
index = args.args[0];
- base = devm_platform_ioremap_resource(pdev, index);
- if (IS_ERR(base))
- return PTR_ERR(base);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, index);
+ if (!res)
+ return -ENODEV;
+
+ base = devm_ioremap(dev, res->start, resource_size(res));
+ if (!base)
+ return -ENOMEM;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data) {
This reverts commit f17b3e44320b4079e69135c63d1e416b0703a21e. This commit introduces a regression on platforms using the driver, by failing to initialise a policy, when one is created post hotplug. When all the CPUs of a policy are hoptplugged out, the call to .exit() and later to devm_iounmap() does not release the memory region that was requested during devm_platform_ioremap_resource(). Therefore, a subsequent call to .init() will result in the following error, which will prevent a new policy to be initialised: qcom-cpufreq-hw 17d43000.cpufreq: can't request region for resource [mem 0x17d43000-0x17d443ff] Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> --- Hi guys, I noticed the issue described in the commit message on DB845c platforms on 5.11-rc2. I tried to fix this, rather than revert it, but I did not find any better way to fix this, other than possibly calling devm_release_mem_region() directly in the cpufreq driver or reworking some of the resource management functions. But in comparison, reverting the patch still seemed the cleaner solution to me. Hope it helps, Ionela. drivers/cpufreq/qcom-cpufreq-hw.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) base-commit: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62 prerequisite-patch-id: a6b26dcf2cc7750362150ced269bc05a6cbd0a05