| Message ID | 20190415032516.3633-1-oohall@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | core/pci: Prefer ibm, slot-label when finding loc codes | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch master (ff79070d1c4cdc38f2ecb42e45b8322cb1efb819) |
| snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot | success | Test snowpatch/job/snowpatch-skiboot on branch master |
| snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot-dco | success | Signed-off-by present |
"Oliver O'Halloran" <oohall@gmail.com> writes: > On OpenPower systems the ibm,slot-label property is used to identify > slots rather than the more verbose ibm,slot-location-code. The > slot-label lookup is currently broken since it assumes that the > ibm,slot-label is in the PCI device node rather than in the node of the > device that provides the slot (e.g. root port or switch downstream > port). > > This patch corrects the lookup code to search the parent node (and > possibly it's grandparents), similar to how we search for > ibm,slot-location-code. > > Fixes: 1c3baae4f2b3 ("hdata/iohub: Look for IOVPD on P9") > Signed-off-by: Oliver O'Halloran <oohall@gmail.com> > --- > The Fixes: here is a bit mis-leading. It's been pretty much always > broken, but we never really noticed because on most systems the > slot-label and the slot-location-code are identical. 1c3baae4f2b3 > caused them to differ because the PHB's base location code was > added to the DT which changes the generated slot-location-code to > include the PHB location code. So, I think this all ends up being what fixes the reported problem (which, amusingly enough, we'd never actually hit in tests because of tedious reasons involving GPUs and NVIDIA drivers)... I'm more convinced by the internal testing than anything else tbh. Merged to master as of ff960a77a192efd90d1be370c67c85cb82ce0e2e
diff --git a/core/pci.c b/core/pci.c index 57154b07474d..ee563c2fc577 100644 --- a/core/pci.c +++ b/core/pci.c @@ -1423,15 +1423,20 @@ static void pci_add_loc_code(struct dt_node *np, struct pci_device *pd) uint8_t class, sub; uint8_t pos, len; - /* If there is a label assigned to the function, use it on openpower machines */ - if (pd->slot) - blcode = dt_prop_get_def(np, "ibm,slot-label", NULL); + while (p) { + /* if we have a slot label (i.e. openpower) use that */ + blcode = dt_prop_get_def(p, "ibm,slot-label", NULL); + if (blcode) + break; - /* Look for a parent with a slot-location-code */ - while (!blcode && p) { + /* otherwise use the fully qualified location code */ blcode = dt_prop_get_def(p, "ibm,slot-location-code", NULL); + if (blcode) + break; + p = p->parent; } + if (!blcode) return;
On OpenPower systems the ibm,slot-label property is used to identify slots rather than the more verbose ibm,slot-location-code. The slot-label lookup is currently broken since it assumes that the ibm,slot-label is in the PCI device node rather than in the node of the device that provides the slot (e.g. root port or switch downstream port). This patch corrects the lookup code to search the parent node (and possibly it's grandparents), similar to how we search for ibm,slot-location-code. Fixes: 1c3baae4f2b3 ("hdata/iohub: Look for IOVPD on P9") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> --- The Fixes: here is a bit mis-leading. It's been pretty much always broken, but we never really noticed because on most systems the slot-label and the slot-location-code are identical. 1c3baae4f2b3 caused them to differ because the PHB's base location code was added to the DT which changes the generated slot-location-code to include the PHB location code. --- core/pci.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)