@@ -1018,6 +1018,10 @@ int eeh_init(void)
} else if ((ret = eeh_ops->init()))
return ret;
+ /* Initialize PHB PEs */
+ list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
+ eeh_dev_phb_init_dynamic(hose);
+
/* Initialize EEH event */
ret = eeh_event_init();
if (ret)
@@ -83,21 +83,3 @@ void eeh_dev_phb_init_dynamic(struct pci_controller *phb)
/* EEH PE for PHB */
eeh_phb_pe_create(phb);
}
-
-/**
- * eeh_dev_phb_init - Create EEH devices for devices included in existing PHBs
- *
- * Scan all the existing PHBs and create EEH devices for their OF
- * nodes and their children OF nodes
- */
-static int __init eeh_dev_phb_init(void)
-{
- struct pci_controller *phb, *tmp;
-
- list_for_each_entry_safe(phb, tmp, &hose_list, list_node)
- eeh_dev_phb_init_dynamic(phb);
-
- return 0;
-}
-
-core_initcall(eeh_dev_phb_init);
Otherwise we end up not yet having computed the right diag data size on powernv where EEH initialization is delayed, thus causing memory corruption later on when calling OPAL. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- Russell, what do you think ? The end result is that the PEs for the PHBs are created much later. I suppose that might cause changes of behaviour if, for example, we hit EEH while probing before we call eeh_init() again. Hopefully we have all the appropriate NULL checks to deal with it though... Another option would be to break up eeh_init() between calling the backend init, which we would unconditionally do early (ie removing the special powernv test) and a new eeh_create_pe()'s which would explicitely be called by the backend at the "right" time... Without either fix, we are currently corrupting kernel memory when hitting EEH on a PHB PE (fences for example). If this ends up being the right approach, then we need a CC stable as well. arch/powerpc/kernel/eeh.c | 4 ++++ arch/powerpc/kernel/eeh_dev.c | 18 ------------------ 2 files changed, 4 insertions(+), 18 deletions(-)