s390/pci: fix misleading rc in clp_set_pci_fn()
Currently clp_set_pci_fn() always returns 0 as long as the CLP request
itself succeeds even if the operation itself returns a response code
other than CLP_RC_OK or CLP_RC_SETPCIFN_ALRDY. This is highly misleading
because calling code assumes that a zero rc means that the operation was
successful.
Fix this by returning the response code or cc on failure with the
exception of the special handling for CLP_RC_SETPCIFN_ALRDY. Also let's
not assume that the returned function handle for CLP_RC_SETPCIFN_ALRDY
is 0, we don't need it anyway.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 67dc5b1..4eafa81 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -655,9 +655,10 @@ int zpci_enable_device(struct zpci_dev *zdev)
{
int rc;
- rc = clp_enable_fh(zdev, ZPCI_NR_DMA_SPACES);
- if (rc)
+ if (clp_enable_fh(zdev, ZPCI_NR_DMA_SPACES)) {
+ rc = -EIO;
goto out;
+ }
rc = zpci_dma_init_device(zdev);
if (rc)
@@ -678,7 +679,7 @@ int zpci_disable_device(struct zpci_dev *zdev)
* The zPCI function may already be disabled by the platform, this is
* detected in clp_disable_fh() which becomes a no-op.
*/
- return clp_disable_fh(zdev);
+ return clp_disable_fh(zdev) ? -EIO : 0;
}
/**
