* [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value @ 2020-08-01 11:24 Saheed O. Bolarinwa 2020-08-01 11:24 ` [RFC PATCH 03/17] bcma: " Saheed O. Bolarinwa ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw) To: helgaas, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general The return value of pci_read_config_*() may not indicate a device error. However, the value read by these functions is more likely to indicate this kind of error. This presents two overlapping ways of reporting errors and complicates error checking. It is possible to move to one single way of checking for error if the dependencies on the return value of these functions are removed, then it can later be made to return void. Remove all uses of the return value of pci_read_config_*(). Check the actual value read for ~0. In this case, ~0 is an invalid value thus it indicates some kind of error. In some cases it madkes sence to make the calling function return void without causing any bug. Future callers can use the value obtained from these functions for validation. This case pertain to cs5536_read() and edac_pci_read_dword() MERGE: There is no dependency. Merge individually Saheed O. Bolarinwa (17): ata: Drop uses of pci_read_config_*() return value atm: Drop uses of pci_read_config_*() return value bcma: Drop uses of pci_read_config_*() return value hwrng: Drop uses of pci_read_config_*() return value dmaengine: ioat: Drop uses of pci_read_config_*() return value edac: Drop uses of pci_read_config_*() return value fpga: altera-cvp: Drop uses of pci_read_config_*() return value gpio: Drop uses of pci_read_config_*() return value drm/i915/vga: Drop uses of pci_read_config_*() return value hwmon: Drop uses of pci_read_config_*() return value intel_th: pci: Drop uses of pci_read_config_*() return value i2c: Drop uses of pci_read_config_*() return value ide: Drop uses of pci_read_config_*() return value IB: Drop uses of pci_read_config_*() return value iommu/vt-d: Drop uses of pci_read_config_*() return value mtd: Drop uses of pci_read_config_*() return value net: Drop uses of pci_read_config_*() return value drivers/ata/pata_cs5536.c | 6 +-- drivers/ata/pata_rz1000.c | 3 +- drivers/atm/eni.c | 3 +- drivers/atm/he.c | 12 +++-- drivers/atm/idt77252.c | 9 ++-- drivers/atm/iphase.c | 46 ++++++++++--------- drivers/atm/lanai.c | 4 +- drivers/atm/nicstar.c | 3 +- drivers/atm/zatm.c | 9 ++-- drivers/bcma/host_pci.c | 6 ++- drivers/char/hw_random/amd-rng.c | 6 +-- drivers/dma/ioat/dma.c | 6 +-- drivers/edac/amd64_edac.c | 8 ++-- drivers/edac/amd8111_edac.c | 16 ++----- drivers/edac/amd8131_edac.c | 6 +-- drivers/edac/i82443bxgx_edac.c | 3 +- drivers/edac/sb_edac.c | 12 +++-- drivers/edac/skx_common.c | 18 +++++--- drivers/fpga/altera-cvp.c | 8 ++-- drivers/gpio/gpio-amd8111.c | 7 ++- drivers/gpio/gpio-rdc321x.c | 21 +++++---- drivers/gpu/drm/i915/display/intel_vga.c | 3 +- drivers/hwmon/i5k_amb.c | 12 +++-- drivers/hwmon/vt8231.c | 8 ++-- drivers/hwtracing/intel_th/pci.c | 12 ++--- drivers/i2c/busses/i2c-ali15x3.c | 6 ++- drivers/i2c/busses/i2c-elektor.c | 3 +- drivers/i2c/busses/i2c-nforce2.c | 4 +- drivers/i2c/busses/i2c-sis5595.c | 17 ++++--- drivers/i2c/busses/i2c-sis630.c | 7 +-- drivers/i2c/busses/i2c-viapro.c | 11 +++-- drivers/ide/cs5536.c | 6 +-- drivers/ide/rz1000.c | 3 +- drivers/ide/setup-pci.c | 26 +++++++---- drivers/infiniband/hw/hfi1/pcie.c | 38 +++++++-------- drivers/infiniband/hw/mthca/mthca_reset.c | 19 ++++---- drivers/iommu/intel/iommu.c | 6 ++- drivers/mtd/maps/ichxrom.c | 4 +- drivers/net/can/peak_canfd/peak_pciefd_main.c | 6 ++- drivers/net/can/sja1000/peak_pci.c | 6 ++- drivers/net/ethernet/agere/et131x.c | 11 +++-- .../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 5 +- .../cavium/liquidio/cn23xx_pf_device.c | 4 +- drivers/net/ethernet/marvell/sky2.c | 5 +- drivers/net/ethernet/mellanox/mlx4/catas.c | 7 +-- drivers/net/ethernet/mellanox/mlx4/reset.c | 10 ++-- .../net/ethernet/myricom/myri10ge/myri10ge.c | 4 +- drivers/net/wan/farsync.c | 5 +- .../broadcom/brcm80211/brcmfmac/pcie.c | 4 +- .../net/wireless/intel/iwlwifi/pcie/trans.c | 15 ++++-- 50 files changed, 270 insertions(+), 209 deletions(-) -- 2.18.4 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH 03/17] bcma: Drop uses of pci_read_config_*() return value 2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa @ 2020-08-01 11:24 ` Saheed O. Bolarinwa 2020-08-01 11:24 ` [RFC PATCH 17/17] net: " Saheed O. Bolarinwa 2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov 2 siblings, 0 replies; 10+ messages in thread From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw) To: helgaas, Rafał Miłecki Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless The return value of pci_read_config_*() may not indicate a device error. However, the value read by these functions is more likely to indicate this kind of error. This presents two overlapping ways of reporting errors and complicates error checking. It is possible to move to one single way of checking for error if the dependency on the return value of these functions is removed, then it can later be made to return void. Remove all uses of the return value of pci_read_config_*(). Check the actual value read for ~0. In this case, ~0 is an invalid value thus it indicates some kind of error. Suggested-by: Bjorn Helgaas <bjorn@helgaas.com> Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com> --- drivers/bcma/host_pci.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c index 69c10a7b7c61..912d5311a444 100644 --- a/drivers/bcma/host_pci.c +++ b/drivers/bcma/host_pci.c @@ -372,9 +372,11 @@ int bcma_host_pci_irq_ctl(struct bcma_bus *bus, struct bcma_device *core, pdev = bus->host_pci; - err = pci_read_config_dword(pdev, BCMA_PCI_IRQMASK, &tmp); - if (err) + pci_read_config_dword(pdev, BCMA_PCI_IRQMASK, &tmp); + if (tmp == (u32)~0) { + err = -ENODEV; goto out; + } coremask = BIT(core->core_index) << 8; if (enable) -- 2.18.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RFC PATCH 17/17] net: Drop uses of pci_read_config_*() return value 2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa 2020-08-01 11:24 ` [RFC PATCH 03/17] bcma: " Saheed O. Bolarinwa @ 2020-08-01 11:24 ` Saheed O. Bolarinwa 2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov 2 siblings, 0 replies; 10+ messages in thread From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw) To: helgaas, David S. Miller, Kalle Valo, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev The return value of pci_read_config_*() may not indicate a device error. However, the value read by these functions is more likely to indicate this kind of error. This presents two overlapping ways of reporting errors and complicates error checking. It is possible to move to one single way of checking for error if the dependency on the return value of these functions is removed, then it can later be made to return void. Remove all uses of the return value of pci_read_config_*(). Check the actual value read for ~0. In this case, ~0 is an invalid value thus it indicates some kind of error. Suggested-by: Bjorn Helgaas <bjorn@helgaas.com> Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com> --- drivers/net/can/peak_canfd/peak_pciefd_main.c | 6 ++++-- drivers/net/can/sja1000/peak_pci.c | 6 ++++-- drivers/net/ethernet/agere/et131x.c | 11 +++++++---- .../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 5 +++-- .../ethernet/cavium/liquidio/cn23xx_pf_device.c | 4 ++-- drivers/net/ethernet/marvell/sky2.c | 5 +++-- drivers/net/ethernet/mellanox/mlx4/catas.c | 7 +------ drivers/net/ethernet/mellanox/mlx4/reset.c | 10 ++++++---- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 4 ++-- drivers/net/wan/farsync.c | 5 +++-- .../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++-- drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 15 ++++++++++----- 12 files changed, 47 insertions(+), 35 deletions(-) diff --git a/drivers/net/can/peak_canfd/peak_pciefd_main.c b/drivers/net/can/peak_canfd/peak_pciefd_main.c index 6ad83a881039..484a214fc1f1 100644 --- a/drivers/net/can/peak_canfd/peak_pciefd_main.c +++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c @@ -730,9 +730,11 @@ static int peak_pciefd_probe(struct pci_dev *pdev, goto err_disable_pci; /* the number of channels depends on sub-system id */ - err = pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &sub_sys_id); - if (err) + pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &sub_sys_id); + if (sub_sys_id == (u16)~0) { + err = -ENODEV; goto err_release_regions; + } dev_dbg(&pdev->dev, "probing device %04x:%04x:%04x\n", pdev->vendor, pdev->device, sub_sys_id); diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c index 8c0244f51059..d25a99ad08da 100644 --- a/drivers/net/can/sja1000/peak_pci.c +++ b/drivers/net/can/sja1000/peak_pci.c @@ -560,9 +560,11 @@ static int peak_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (err) goto failure_disable_pci; - err = pci_read_config_word(pdev, 0x2e, &sub_sys_id); - if (err) + pci_read_config_word(pdev, 0x2e, &sub_sys_id); + if (sub_sys_id == (u16)~0) { + err = -ENODEV; goto failure_release_regions; + } dev_dbg(&pdev->dev, "probing device %04x:%04x:%04x\n", pdev->vendor, pdev->device, sub_sys_id); diff --git a/drivers/net/ethernet/agere/et131x.c b/drivers/net/ethernet/agere/et131x.c index 865892c1f23f..6b0e5f193e73 100644 --- a/drivers/net/ethernet/agere/et131x.c +++ b/drivers/net/ethernet/agere/et131x.c @@ -505,7 +505,8 @@ static int eeprom_wait_ready(struct pci_dev *pdev, u32 *status) * to 1 prior to starting a single byte read/write */ for (i = 0; i < MAX_NUM_REGISTER_POLLS; i++) { - if (pci_read_config_dword(pdev, LBCIF_DWORD1_GROUP, ®)) + pci_read_config_dword(pdev, LBCIF_DWORD1_GROUP, ®); + if (reg == (u32)~0) return -EIO; /* I2C idle and Phy Queue Avail both true */ @@ -679,7 +680,8 @@ static int et131x_init_eeprom(struct et131x_adapter *adapter) * function, because I thought there could be some time conditions * but it didn't work. Call the whole function twice also work. */ - if (pci_read_config_byte(pdev, ET1310_PCI_EEPROM_STATUS, &eestatus)) { + pci_read_config_byte(pdev, ET1310_PCI_EEPROM_STATUS, &eestatus); + if (eestatus == (u8)~0) { dev_err(&pdev->dev, "Could not read PCI config space for EEPROM Status\n"); return -EIO; @@ -3059,8 +3061,9 @@ static int et131x_pci_init(struct et131x_adapter *adapter, } for (i = 0; i < ETH_ALEN; i++) { - if (pci_read_config_byte(pdev, ET1310_PCI_MAC_ADDRESS + i, - adapter->rom_addr + i)) { + pci_read_config_byte(pdev, ET1310_PCI_MAC_ADDRESS + i, + adapter->rom_addr + i); + if (*(adapter->rom_addr + i) == (u8)~0) { dev_err(&pdev->dev, "Could not read PCI config space for MAC address\n"); goto err_out; } diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c index 7cea33803f7f..5962a1d2dffc 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c @@ -1463,14 +1463,15 @@ static int bnx2x_nvram_read32(struct bnx2x *bp, u32 offset, u32 *buf, static bool bnx2x_is_nvm_accessible(struct bnx2x *bp) { - int rc = 1; + bool rc = true; u16 pm = 0; struct net_device *dev = pci_get_drvdata(bp->pdev); if (bp->pdev->pm_cap) - rc = pci_read_config_word(bp->pdev, + pci_read_config_word(bp->pdev, bp->pdev->pm_cap + PCI_PM_CTRL, &pm); + rc = (pm == (u16)~0); if ((rc && !netif_running(dev)) || (!rc && ((pm & PCI_PM_CTRL_STATE_MASK) != (__force u16)PCI_D0))) return false; diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c index 43d11c38b38a..cf52d6cc2a46 100644 --- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c +++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c @@ -1162,8 +1162,8 @@ static int cn23xx_get_pf_num(struct octeon_device *oct) ret = 0; /** Read Function Dependency Link reg to get the function number */ - if (pci_read_config_dword(oct->pci_dev, CN23XX_PCIE_SRIOV_FDL, - &fdl_bit) == 0) { + pci_read_config_dword(oct->pci_dev, CN23XX_PCIE_SRIOV_FDL, &fdl_bit); + if (fdl_bit != (u32)~0) { oct->pf_num = ((fdl_bit >> CN23XX_PCIE_SRIOV_FDL_BIT_POS) & CN23XX_PCIE_SRIOV_FDL_MASK); } else { diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c index fe54764caea9..1042bfd0ff70 100644 --- a/drivers/net/ethernet/marvell/sky2.c +++ b/drivers/net/ethernet/marvell/sky2.c @@ -4964,8 +4964,9 @@ static int sky2_probe(struct pci_dev *pdev, const struct pci_device_id *ent) * other PCI access through shared memory for speed and to * avoid MMCONFIG problems. */ - err = pci_read_config_dword(pdev, PCI_DEV_REG2, ®); - if (err) { + pci_read_config_dword(pdev, PCI_DEV_REG2, ®); + if (reg == (u32)~0) { + err = -ENODEV; dev_err(&pdev->dev, "PCI read config failed\n"); goto err_out_disable; } diff --git a/drivers/net/ethernet/mellanox/mlx4/catas.c b/drivers/net/ethernet/mellanox/mlx4/catas.c index 5b11557f1ae4..1e774a181133 100644 --- a/drivers/net/ethernet/mellanox/mlx4/catas.c +++ b/drivers/net/ethernet/mellanox/mlx4/catas.c @@ -52,12 +52,7 @@ static int read_vendor_id(struct mlx4_dev *dev) u16 vendor_id = 0; int ret; - ret = pci_read_config_word(dev->persist->pdev, 0, &vendor_id); - if (ret) { - mlx4_err(dev, "Failed to read vendor ID, ret=%d\n", ret); - return ret; - } - + pci_read_config_word(dev->persist->pdev, 0, &vendor_id); if (vendor_id == 0xffff) { mlx4_err(dev, "PCI can't be accessed to read vendor id\n"); return -EINVAL; diff --git a/drivers/net/ethernet/mellanox/mlx4/reset.c b/drivers/net/ethernet/mellanox/mlx4/reset.c index 0076d88587ca..f0b9af99aa26 100644 --- a/drivers/net/ethernet/mellanox/mlx4/reset.c +++ b/drivers/net/ethernet/mellanox/mlx4/reset.c @@ -81,8 +81,9 @@ int mlx4_reset(struct mlx4_dev *dev) for (i = 0; i < 64; ++i) { if (i == 22 || i == 23) continue; - if (pci_read_config_dword(dev->persist->pdev, i * 4, - hca_header + i)) { + pci_read_config_dword(dev->persist->pdev, i * 4, + hca_header + i); + if (*(hca_header + i) == (u32)~0) { err = -ENODEV; mlx4_err(dev, "Couldn't save HCA PCI header, aborting\n"); goto out; @@ -124,8 +125,9 @@ int mlx4_reset(struct mlx4_dev *dev) end = jiffies + MLX4_RESET_TIMEOUT_JIFFIES; do { - if (!pci_read_config_word(dev->persist->pdev, PCI_VENDOR_ID, - &vendor) && vendor != 0xffff) + pci_read_config_word(dev->persist->pdev, PCI_VENDOR_ID, + &vendor); + if (vendor != 0xffff) break; msleep(1); diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c index e1e1f4e3639e..b1b055f8ac47 100644 --- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c +++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c @@ -3090,8 +3090,8 @@ static void myri10ge_enable_ecrc(struct myri10ge_priv *mgp) if (!cap) return; - ret = pci_read_config_dword(bridge, cap + PCI_ERR_CAP, &err_cap); - if (ret) { + pci_read_config_dword(bridge, cap + PCI_ERR_CAP, &err_cap); + if (err_cap == (u32)~0) { dev_err(dev, "failed reading ext-conf-space of %s\n", pci_name(bridge)); dev_err(dev, "\t pci=nommconf in use? " diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c index 7916efce7188..8981334d9f82 100644 --- a/drivers/net/wan/farsync.c +++ b/drivers/net/wan/farsync.c @@ -678,8 +678,9 @@ fst_cpureset(struct fst_card_info *card) unsigned int regval; if (card->family == FST_FAMILY_TXU) { - if (pci_read_config_byte - (card->device, PCI_INTERRUPT_LINE, &interrupt_line_register)) { + pci_read_config_byte + (card->device, PCI_INTERRUPT_LINE, &interrupt_line_register); + if (interrupt_line_register == (u8)~0) { dbg(DBG_ASS, "Error in reading interrupt line register\n"); } diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c index 39381cbde89e..f501b4759630 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c @@ -544,8 +544,8 @@ brcmf_pcie_select_core(struct brcmf_pciedev_info *devinfo, u16 coreid) if (core) { bar0_win = core->base; pci_write_config_dword(pdev, BRCMF_PCIE_BAR0_WINDOW, bar0_win); - if (pci_read_config_dword(pdev, BRCMF_PCIE_BAR0_WINDOW, - &bar0_win) == 0) { + pci_read_config_dword(pdev, BRCMF_PCIE_BAR0_WINDOW, &bar0_win); + if (bar0_win != (u32)~0) { if (bar0_win != core->base) { bar0_win = core->base; pci_write_config_dword(pdev, diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c index e5160d620868..caafad424aa7 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c @@ -122,7 +122,8 @@ void iwl_trans_pcie_dump_regs(struct iwl_trans *trans) sprintf(prefix, "iwlwifi %s: ", pci_name(pdev)); IWL_ERR(trans, "iwlwifi device config registers:\n"); for (i = 0, ptr = buf; i < PCI_DUMP_SIZE; i += 4, ptr++) - if (pci_read_config_dword(pdev, i, ptr)) + pci_read_config_dword(pdev, i, ptr); + if (*ptr == (u32)~0) goto err_read; print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0); @@ -135,7 +136,8 @@ void iwl_trans_pcie_dump_regs(struct iwl_trans *trans) if (pos) { IWL_ERR(trans, "iwlwifi device AER capability structure:\n"); for (i = 0, ptr = buf; i < PCI_ERR_ROOT_COMMAND; i += 4, ptr++) - if (pci_read_config_dword(pdev, pos + i, ptr)) + pci_read_config_dword(pdev, pos + i, ptr); + if (*ptr == (u32)~0) goto err_read; print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0); @@ -151,7 +153,8 @@ void iwl_trans_pcie_dump_regs(struct iwl_trans *trans) IWL_ERR(trans, "iwlwifi parent port (%s) config registers:\n", pci_name(pdev)); for (i = 0, ptr = buf; i < PCI_PARENT_DUMP_SIZE; i += 4, ptr++) - if (pci_read_config_dword(pdev, i, ptr)) + pci_read_config_dword(pdev, i, ptr); + if (*ptr == (u32)~0) goto err_read; print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0); @@ -165,7 +168,8 @@ void iwl_trans_pcie_dump_regs(struct iwl_trans *trans) pci_name(pdev)); sprintf(prefix, "iwlwifi %s: ", pci_name(pdev)); for (i = 0, ptr = buf; i <= PCI_ERR_ROOT_ERR_SRC; i += 4, ptr++) - if (pci_read_config_dword(pdev, pos + i, ptr)) + pci_read_config_dword(pdev, pos + i, ptr); + if (*ptr == (u32)~0) goto err_read; print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0); @@ -2191,8 +2195,9 @@ static int iwl_trans_pcie_write_mem(struct iwl_trans *trans, u32 addr, static int iwl_trans_pcie_read_config32(struct iwl_trans *trans, u32 ofs, u32 *val) { - return pci_read_config_dword(IWL_TRANS_GET_PCIE_TRANS(trans)->pci_dev, + pci_read_config_dword(IWL_TRANS_GET_PCIE_TRANS(trans)->pci_dev, ofs, val); + return (*val == (u32)~0) ? -ENODEV : 0; } static void iwl_trans_pcie_freeze_txq_timer(struct iwl_trans *trans, -- 2.18.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value 2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa 2020-08-01 11:24 ` [RFC PATCH 03/17] bcma: " Saheed O. Bolarinwa 2020-08-01 11:24 ` [RFC PATCH 17/17] net: " Saheed O. Bolarinwa @ 2020-08-01 12:56 ` Borislav Petkov 2020-08-02 14:53 ` Tom Rix 2020-08-02 17:28 ` Saheed Bolarinwa 2 siblings, 2 replies; 10+ messages in thread From: Borislav Petkov @ 2020-08-01 12:56 UTC (permalink / raw) To: Saheed O. Bolarinwa Cc: helgaas, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote: > The return value of pci_read_config_*() may not indicate a device error. > However, the value read by these functions is more likely to indicate > this kind of error. This presents two overlapping ways of reporting > errors and complicates error checking. So why isn't the *value check done in the pci_read_config_* functions instead of touching gazillion callers? For example, pci_conf{1,2}_read() could check whether the u32 *value it just read depending on the access method, whether that value is ~0 and return proper PCIBIOS_ error in that case. The check you're replicating if (val32 == (u32)~0) everywhere, instead, is just ugly and tests a naked value ~0 which doesn't mean anything... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value 2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov @ 2020-08-02 14:53 ` Tom Rix 2020-08-02 17:28 ` Saheed Bolarinwa 1 sibling, 0 replies; 10+ messages in thread From: Tom Rix @ 2020-08-02 14:53 UTC (permalink / raw) To: Borislav Petkov, Saheed O. Bolarinwa Cc: helgaas, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general On 8/1/20 5:56 AM, Borislav Petkov wrote: > On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote: >> The return value of pci_read_config_*() may not indicate a device error. >> However, the value read by these functions is more likely to indicate >> this kind of error. This presents two overlapping ways of reporting >> errors and complicates error checking. > So why isn't the *value check done in the pci_read_config_* functions > instead of touching gazillion callers? > > For example, pci_conf{1,2}_read() could check whether the u32 *value it > just read depending on the access method, whether that value is ~0 and > return proper PCIBIOS_ error in that case. > > The check you're replicating > > if (val32 == (u32)~0) > > everywhere, instead, is just ugly and tests a naked value ~0 which > doesn't mean anything... > I agree, if there is a change, it should be in the pci_read_* functions. Anything returning void should not fail and likely future users of the proposed change will not do the extra checks. Tom ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value 2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov 2020-08-02 14:53 ` Tom Rix @ 2020-08-02 17:28 ` Saheed Bolarinwa 2020-08-02 18:46 ` Borislav Petkov 1 sibling, 1 reply; 10+ messages in thread From: Saheed Bolarinwa @ 2020-08-02 17:28 UTC (permalink / raw) To: Borislav Petkov, trix Cc: helgaas, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general On 8/1/20 2:56 PM, Borislav Petkov wrote: > On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote: >> The return value of pci_read_config_*() may not indicate a device error. >> However, the value read by these functions is more likely to indicate >> this kind of error. This presents two overlapping ways of reporting >> errors and complicates error checking. > So why isn't the *value check done in the pci_read_config_* functions > instead of touching gazillion callers? Because the value ~0 has a meaning to some drivers and only drivers have this knowledge. For those cases more checks will be needed to ensure that it is an error that has actually happened. > For example, pci_conf{1,2}_read() could check whether the u32 *value it > just read depending on the access method, whether that value is ~0 and > return proper PCIBIOS_ error in that case. The primary goal is to make pci_config_read*() return void, so that there is *only* one way to check for error i.e. through the obtained value. Again, only the drivers can determine if ~0 is a valid value. This information is not available inside pci_config_read*(). - Saheed ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value 2020-08-02 17:28 ` Saheed Bolarinwa @ 2020-08-02 18:46 ` Borislav Petkov 2020-08-02 19:14 ` Bjorn Helgaas 0 siblings, 1 reply; 10+ messages in thread From: Borislav Petkov @ 2020-08-02 18:46 UTC (permalink / raw) To: Saheed Bolarinwa Cc: trix, helgaas, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote: > Because the value ~0 has a meaning to some drivers and only No, ~0 means that the PCI read failed. For *every* PCI device I know. Here's me reading from 0xf0 offset of my hostbridge: # setpci -s 00:00.0 0xf0.l 01000000 That device doesn't have extended config space, so the last valid byte is 0xff. Let's read beyond that: # setpci -s 00:00.0 0x100.l ffffffff > Again, only the drivers can determine if ~0 is a valid value. This > information is not available inside pci_config_read*(). Of course it is. *every* change you've done in 6/17 - this is the only patch I have received - checks for == ~0. So that check can just as well be moved inside pci_config_read_*(). Here's how one could do it: #define PCI_OP_READ(size, type, len) \ int noinline pci_bus_read_config_##size \ (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \ { \ int res; \ unsigned long flags; \ u32 data = 0; \ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \ pci_lock_config(flags); \ res = bus->ops->read(bus, devfn, pos, len, &data); \ /* Check we actually read something which is not all 1s.*/ if (data == ~0) return PCIBIOS_READ_FAILED; *value = (type)data; \ pci_unlock_config(flags); \ return res; \ } Also, I'd prefer a function to *not* return void but return either an error or success. In the success case, the @value argument can be consumed by the caller and otherwise not. In any case, that change is a step in the wrong direction and I don't like it, sorry. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value 2020-08-02 18:46 ` Borislav Petkov @ 2020-08-02 19:14 ` Bjorn Helgaas 2020-08-02 20:18 ` Borislav Petkov 2020-08-03 6:56 ` Christoph Hellwig 0 siblings, 2 replies; 10+ messages in thread From: Bjorn Helgaas @ 2020-08-02 19:14 UTC (permalink / raw) To: Borislav Petkov Cc: Saheed Bolarinwa, trix, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general On Sun, Aug 02, 2020 at 08:46:48PM +0200, Borislav Petkov wrote: > On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote: > > Because the value ~0 has a meaning to some drivers and only > > No, ~0 means that the PCI read failed. For *every* PCI device I know. Wait, I'm not convinced yet. I know that if a PCI read fails, you normally get ~0 data because the host bridge fabricates it to complete the CPU load. But what guarantees that a PCI config register cannot contain ~0? If there's something about that in the spec I'd love to know where it is because it would simplify a lot of things. I don't think we should merge any of these patches as-is. If we *do* want to go this direction, we at least need some kind of macro or function that tests for ~0 so we have a clue about what's happening and can grep for it. Bjorn ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value 2020-08-02 19:14 ` Bjorn Helgaas @ 2020-08-02 20:18 ` Borislav Petkov 2020-08-03 6:56 ` Christoph Hellwig 1 sibling, 0 replies; 10+ messages in thread From: Borislav Petkov @ 2020-08-02 20:18 UTC (permalink / raw) To: Bjorn Helgaas Cc: Saheed Bolarinwa, trix, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote: > Wait, I'm not convinced yet. I know that if a PCI read fails, you > normally get ~0 data because the host bridge fabricates it to complete > the CPU load. > > But what guarantees that a PCI config register cannot contain ~0? Well, I don't think you can differentiate that case, right? I guess this is where the driver knowledge comes into play: if the read returns ~0, the pci_read_config* should probably return in that case something like: PCIBIOS_READ_MAYBE_FAILED to denote it is all 1s and then the caller should be able to determine, based on any of domain:bus:slot.func and whatever else the driver knows about its hardware, whether the 1s are a valid value or an error. Hopefully. Or something better of which I cannot think of right now... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value 2020-08-02 19:14 ` Bjorn Helgaas 2020-08-02 20:18 ` Borislav Petkov @ 2020-08-03 6:56 ` Christoph Hellwig 1 sibling, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2020-08-03 6:56 UTC (permalink / raw) To: Bjorn Helgaas Cc: Borislav Petkov, Saheed Bolarinwa, trix, Kalle Valo, David S. Miller, Jakub Kicinski, Wolfgang Grandegger, Marc Kleine-Budde, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Joerg Roedel, bjorn, skhan, linux-kernel-mentees, linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd, iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel, intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine, linux-crypto, linux-atm-general On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote: > But what guarantees that a PCI config register cannot contain ~0? > If there's something about that in the spec I'd love to know where it > is because it would simplify a lot of things. There isn't. An we even have cases like the NVMe controller memory buffer and persistent memory region, which are BARs that store abritrary values for later retreival, so it can't. (now those features have a major issue with error detection, but that is another issue) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-08-03 6:57 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa 2020-08-01 11:24 ` [RFC PATCH 03/17] bcma: " Saheed O. Bolarinwa 2020-08-01 11:24 ` [RFC PATCH 17/17] net: " Saheed O. Bolarinwa 2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov 2020-08-02 14:53 ` Tom Rix 2020-08-02 17:28 ` Saheed Bolarinwa 2020-08-02 18:46 ` Borislav Petkov 2020-08-02 19:14 ` Bjorn Helgaas 2020-08-02 20:18 ` Borislav Petkov 2020-08-03 6:56 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).