On 12/8/20 7:46 PM, Bjorn Helgaas wrote:
[...]
+static int __init rcar_pcie_init(void)
+{
+ if (of_find_matching_node(NULL, rcar_pcie_abort_handler_of_match)) {
+#ifdef CONFIG_ARM_LPAE
+ hook_fault_code(17, rcar_pcie_aarch32_abort_handler, SIGBUS, 0,
+ "asynchronous external abort");
+#else
+ hook_fault_code(22, rcar_pcie_aarch32_abort_handler, SIGBUS, 0,
+ "imprecise external abort");
+#endif
+ }
+
+ return platform_driver_register(&rcar_pcie_driver);
+}
+device_initcall(rcar_pcie_init);
+#else
builtin_platform_driver(rcar_pcie_driver);
+#endif
Is the device_initcall() vs builtin_platform_driver() something
related to the hook_fault_code()? What would break if this were
always builtin_platform_driver()?
rcar_pcie_init() would not be called before probe.
Sorry to be slow, but why does it need to be called before probe?
Obviously software isn't putting the controller in D3 or enabling ASPM
before probe.
The hook_fault_code() is marked __init, so if probe() was deferred and
the kernel __init memory was free'd, attempt to call hook_fault_code()
from probe would lead to a crash.
