diff options
author | Stewart Smith <stewart@linux.ibm.com> | 2019-05-03 01:24:34 -0500 |
---|---|---|
committer | Stewart Smith <stewart@linux.ibm.com> | 2019-05-03 01:24:34 -0500 |
commit | 119108908e9b1de9a3f24f27a16f4efe4ca3a0b4 (patch) | |
tree | 0cb532378a9c4bab05feecc4eb946b441efba88b /core/pci.c | |
parent | 588c39adb1ec6dba11bb0d256f13103e2ff79fbb (diff) | |
download | skiboot-119108908e9b1de9a3f24f27a16f4efe4ca3a0b4.zip skiboot-119108908e9b1de9a3f24f27a16f4efe4ca3a0b4.tar.gz skiboot-119108908e9b1de9a3f24f27a16f4efe4ca3a0b4.tar.bz2 |
pci: Try harder to add meaningful ibm,loc-code
We keep the existing logic of looking to the parent for the slot-label or
slot-location-code, but we add logic to (if all that fails) we look
directly for the slot-location-code (as this should give us the correct
loc code for things directly under the PHB), and otherwise we just look
for a loc-code.
The applicable bit of PAPR here is:
R1–12.1–1. Each instance of a hardware entity (FRU) has a platform
unique location code and any node in the OF
device tree that describes a part of a hardware entity must include the
“ibm,loc-code” property with a
value that represents the location code for that hardware entity.
which we weren't really fully obeying at any recent (ever?) point in
time. Now we should do okay, at least for PCI.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Diffstat (limited to 'core/pci.c')
-rw-r--r-- | core/pci.c | 15 |
1 files changed, 15 insertions, 0 deletions
@@ -1438,6 +1438,21 @@ static void pci_add_loc_code(struct dt_node *np, struct pci_device *pd) } if (!blcode) + blcode = dt_prop_get_def(np, "ibm,slot-location-code", NULL); + + if (!blcode) { + /* Fall back to finding a ibm,loc-code */ + p = np->parent; + + while (p) { + blcode = dt_prop_get_def(p, "ibm,loc-code", NULL); + if (blcode) + break; + p = p->parent; + } + } + + if (!blcode) return; /* ethernet devices get port codes */ |