| Message ID | 1468444634-1866-7-git-send-email-imunsie@au.ibm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Wed, 2016-13-07 at 21:17:05 UTC, Ian Munsie wrote: > From: Ian Munsie <imunsie@au1.ibm.com> > > The vPHB model of the cxl kernel API is a hierarchy where the AFU is > represented by the vPHB, and it's AFU configuration records are exposed > as functions under that vPHB. If there are no AFU configuration records > we will create a vPHB with nothing under it, which is a waste of > resources and will opt us into EEH handling despite not having anything > special to handle. > > This also does not make sense for cards using the peer model of the cxl > kernel API, where the other functions of the device are exposed via > additional peer physical functions rather than AFU configuration > records. This model will also not work with the existing EEH handling in > the cxl driver, as that is designed around the vPHB model. > > Skip creating the vPHB for AFUs without any AFU configuration records, > and opt out of EEH handling for them. > > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> > Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e4f5fc001a6cb82bef91037245 cheers
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c index deef9c7..dd7ff22 100644 --- a/drivers/misc/cxl/pci.c +++ b/drivers/misc/cxl/pci.c @@ -1572,6 +1572,9 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev, */ for (i = 0; i < adapter->slices; i++) { afu = adapter->afu[i]; + /* Only participate in EEH if we are on a virtual PHB */ + if (afu->phb == NULL) + return PCI_ERS_RESULT_NONE; cxl_vphb_error_detected(afu, state); } return PCI_ERS_RESULT_DISCONNECT; diff --git a/drivers/misc/cxl/vphb.c b/drivers/misc/cxl/vphb.c index c8a759f..8865e8d 100644 --- a/drivers/misc/cxl/vphb.c +++ b/drivers/misc/cxl/vphb.c @@ -188,6 +188,17 @@ int cxl_pci_vphb_add(struct cxl_afu *afu) struct device_node *vphb_dn; struct device *parent; + /* + * If there are no AFU configuration records we won't have anything to + * expose under the vPHB, so skip creating one, returning success since + * this is still a valid case. This will also opt us out of EEH + * handling since we won't have anything special to do if there are no + * kernel drivers attached to the vPHB, and EEH handling is not yet + * supported in the peer model. + */ + if (!afu->crs_num) + return 0; + /* The parent device is the adapter. Reuse the device node of * the adapter. * We don't seem to care what device node is used for the vPHB,