[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230913163823.7880-8-james.morse@arm.com>
Date: Wed, 13 Sep 2023 16:37:55 +0000
From: James Morse <james.morse@....com>
To: linux-pm@...r.kernel.org, loongarch@...ts.linux.dev,
linux-acpi@...r.kernel.org, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-riscv@...ts.infradead.org, kvmarm@...ts.linux.dev
Cc: x86@...nel.org, Salil Mehta <salil.mehta@...wei.com>,
Russell King <linux@...linux.org.uk>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
jianyong.wu@....com, justin.he@....com
Subject: [RFC PATCH v2 07/35] x86: intel_epb: Don't rely on link order
intel_epb_init() is called as a subsys_initcall() to register cpuhp
callbacks. The callbacks make use of get_cpu_device() which will return
NULL unless register_cpu() has been called. register_cpu() is called
from topology_init(), which is also a subsys_initcall().
This is fragile. Moving the register_cpu() to a different
subsys_initcall() leads to a NULL derefernce during boot.
Make intel_epb_init() a late_initcall(), user-space can't provide a
policy before this point anyway.
Signed-off-by: James Morse <james.morse@....com>
---
subsys_initcall_sync() would be an option, but moving the register_cpu()
calls into ACPI also means adding a safety net for CPUs that are online
but not described properly by firmware. This lives in subsys_initcall_sync().
---
arch/x86/kernel/cpu/intel_epb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/intel_epb.c b/arch/x86/kernel/cpu/intel_epb.c
index e4c3ba91321c..f18d35fe27a9 100644
--- a/arch/x86/kernel/cpu/intel_epb.c
+++ b/arch/x86/kernel/cpu/intel_epb.c
@@ -237,4 +237,4 @@ static __init int intel_epb_init(void)
cpuhp_remove_state(CPUHP_AP_X86_INTEL_EPB_ONLINE);
return ret;
}
-subsys_initcall(intel_epb_init);
+late_initcall(intel_epb_init);
--
2.39.2
Powered by blists - more mailing lists