Searched hist:c035ff1d2eaa03ab40839041e955a86a8e412eb4 (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/arch/powerpc/kernel/ |
| H A D | pci_dn.c | diff c035ff1d2eaa03ab40839041e955a86a8e412eb4 Tue Mar 17 00:15:04 CDT 2015 Gavin Shan <gwshan@linux.vnet.ibm.com> powerpc/pci: Trace more information from pci_dn
Originally, EEH probes on device_node or pci_dev and populates the
corresponding eeh_dev. In the subsequent patches, EEH will probes
on pci_dn and populates the corresponding eeh_dev. So we have to
cache some information in pci_dn, either from device_node or SRIOV
PF's enablement platform hook, to populate the eeh_dev properly.
The motivation to probe pci_dn, instead of device node or pci_dev,
to populate eeh_dev is SRIOV VFs are dynamically created and we
don't have the corresponding device nodes for them.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
| /openbmc/linux/arch/powerpc/include/asm/ |
| H A D | pci-bridge.h | diff c035ff1d2eaa03ab40839041e955a86a8e412eb4 Tue Mar 17 00:15:04 CDT 2015 Gavin Shan <gwshan@linux.vnet.ibm.com> powerpc/pci: Trace more information from pci_dn
Originally, EEH probes on device_node or pci_dev and populates the
corresponding eeh_dev. In the subsequent patches, EEH will probes
on pci_dn and populates the corresponding eeh_dev. So we have to
cache some information in pci_dn, either from device_node or SRIOV
PF's enablement platform hook, to populate the eeh_dev properly.
The motivation to probe pci_dn, instead of device node or pci_dev,
to populate eeh_dev is SRIOV VFs are dynamically created and we
don't have the corresponding device nodes for them.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|