* [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ 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: linux-pci, linux-fpga, dri-devel, linux-ide, linux-mtd,
linux-i2c, linux-rdma, linux-atm-general, linux-kernel-mentees,
intel-gfx, linux-gpio, skhan, bjorn, linux-edac, linux-hwmon,
Saheed O. Bolarinwa, linux-wireless, linux-kernel, iommu,
linux-crypto, netdev, dmaengine
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ 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: linux-pci, linux-fpga, dri-devel, linux-ide, linux-mtd,
linux-i2c, linux-rdma, linux-atm-general, linux-kernel-mentees,
intel-gfx, linux-gpio, skhan, bjorn, linux-edac, linux-hwmon,
Saheed O. Bolarinwa, linux-wireless, linux-kernel, iommu,
linux-crypto, netdev, dmaengine
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ 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: linux-pci, linux-fpga, dri-devel, linux-ide, linux-mtd,
linux-i2c, linux-rdma, linux-atm-general, linux-kernel-mentees,
intel-gfx, linux-gpio, linux-edac, linux-hwmon,
Saheed O. Bolarinwa, linux-wireless, linux-kernel, iommu,
linux-crypto, netdev, dmaengine
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ 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: linux-pci, linux-fpga, dri-devel, linux-ide, linux-mtd,
linux-i2c, linux-rdma, linux-atm-general, linux-kernel-mentees,
intel-gfx, linux-gpio, skhan, bjorn, linux-edac, linux-hwmon,
Saheed O. Bolarinwa, linux-wireless, linux-kernel, iommu,
linux-crypto, netdev, dmaengine
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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ 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: linux-pci, linux-fpga, dri-devel, linux-ide, linux-mtd,
linux-i2c, linux-rdma, linux-atm-general, linux-kernel-mentees,
intel-gfx, linux-gpio, skhan, bjorn, linux-edac, linux-hwmon,
Saheed O. Bolarinwa, linux-wireless, linux-kernel, iommu,
linux-crypto, netdev, dmaengine
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 01/17] ata: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Jens Axboe
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-ide
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.
drivers/ata/pata_cs5536.c cs5536_read() :
None of the callers of cs5536_read() uses the return value. The obtained
value can be checked for validity to confirm success.
Change the return type of cs5536_read() to void.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com>
---
drivers/ata/pata_cs5536.c | 6 +++---
drivers/ata/pata_rz1000.c | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c
index 760ac6e65216..c204215e239f 100644
--- a/drivers/ata/pata_cs5536.c
+++ b/drivers/ata/pata_cs5536.c
@@ -83,16 +83,16 @@ static const struct dmi_system_id udma_quirk_dmi_table[] = {
{ }
};
-static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
+static void cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
{
if (unlikely(use_msr)) {
u32 dummy __maybe_unused;
rdmsr(MSR_IDE_CFG + reg, *val, dummy);
- return 0;
+ return;
}
- return pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
+ pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
}
static int cs5536_write(struct pci_dev *pdev, int reg, int val)
diff --git a/drivers/ata/pata_rz1000.c b/drivers/ata/pata_rz1000.c
index 3722a67083fd..e0b3de376357 100644
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -64,7 +64,8 @@ static int rz1000_fifo_disable(struct pci_dev *pdev)
{
u16 reg;
/* Be exceptionally paranoid as we must be sure to apply the fix */
- if (pci_read_config_word(pdev, 0x40, ®) != 0)
+ pci_read_config_word(pdev, 0x40, ®);
+ if (reg == (u16)~0)
return -1;
reg &= 0xDFFF;
if (pci_write_config_word(pdev, 0x40, reg) != 0)
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 01/17] ata: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Jens Axboe
Cc: Saheed O. Bolarinwa, linux-kernel, linux-ide, linux-pci,
linux-kernel-mentees
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.
drivers/ata/pata_cs5536.c cs5536_read() :
None of the callers of cs5536_read() uses the return value. The obtained
value can be checked for validity to confirm success.
Change the return type of cs5536_read() to void.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com>
---
drivers/ata/pata_cs5536.c | 6 +++---
drivers/ata/pata_rz1000.c | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c
index 760ac6e65216..c204215e239f 100644
--- a/drivers/ata/pata_cs5536.c
+++ b/drivers/ata/pata_cs5536.c
@@ -83,16 +83,16 @@ static const struct dmi_system_id udma_quirk_dmi_table[] = {
{ }
};
-static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
+static void cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
{
if (unlikely(use_msr)) {
u32 dummy __maybe_unused;
rdmsr(MSR_IDE_CFG + reg, *val, dummy);
- return 0;
+ return;
}
- return pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
+ pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
}
static int cs5536_write(struct pci_dev *pdev, int reg, int val)
diff --git a/drivers/ata/pata_rz1000.c b/drivers/ata/pata_rz1000.c
index 3722a67083fd..e0b3de376357 100644
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -64,7 +64,8 @@ static int rz1000_fifo_disable(struct pci_dev *pdev)
{
u16 reg;
/* Be exceptionally paranoid as we must be sure to apply the fix */
- if (pci_read_config_word(pdev, 0x40, ®) != 0)
+ pci_read_config_word(pdev, 0x40, ®);
+ if (reg == (u16)~0)
return -1;
reg &= 0xDFFF;
if (pci_write_config_word(pdev, 0x40, reg) != 0)
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 02/17] atm: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Chas Williams
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-atm-general, 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/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 +++++----
7 files changed, 50 insertions(+), 36 deletions(-)
diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index 17d47ad03ab7..5beed8a25fa2 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -1585,7 +1585,8 @@ static char * const media_name[] = {
} })
#define GET_SEPROM \
({ if (!error && !pci_error) { \
- pci_error = pci_read_config_byte(eni_dev->pci_dev,PCI_TONGA_CTRL,&tonga); \
+ pci_read_config_byte(eni_dev->pci_dev, PCI_TONGA_CTRL, &tonga); \
+ pci_error = (tonga == (u8)~0) ? -1 : 0; \
udelay(10); /* 10 usecs */ \
} })
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 8af793f5e811..8727ae7746fb 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -995,7 +995,8 @@ static int he_start(struct atm_dev *dev)
*/
/* 4.3 pci bus controller-specific initialization */
- if (pci_read_config_dword(pci_dev, GEN_CNTL_0, &gen_cntl_0) != 0) {
+ pci_read_config_dword(pci_dev, GEN_CNTL_0, &gen_cntl_0);
+ if (gen_cntl_0 == (u32)~0) {
hprintk("can't read GEN_CNTL_0\n");
return -EINVAL;
}
@@ -1005,7 +1006,8 @@ static int he_start(struct atm_dev *dev)
return -EINVAL;
}
- if (pci_read_config_word(pci_dev, PCI_COMMAND, &command) != 0) {
+ pci_read_config_word(pci_dev, PCI_COMMAND, &command);
+ if (command == (u16)~0) {
hprintk("can't read PCI_COMMAND.\n");
return -EINVAL;
}
@@ -1016,7 +1018,8 @@ static int he_start(struct atm_dev *dev)
return -EINVAL;
}
- if (pci_read_config_byte(pci_dev, PCI_CACHE_LINE_SIZE, &cache_size)) {
+ pci_read_config_byte(pci_dev, PCI_CACHE_LINE_SIZE, &cache_size);
+ if (cache_size == (u8)~0) {
hprintk("can't read cache line size?\n");
return -EINVAL;
}
@@ -1027,7 +1030,8 @@ static int he_start(struct atm_dev *dev)
hprintk("can't set cache line size to %d\n", cache_size);
}
- if (pci_read_config_byte(pci_dev, PCI_LATENCY_TIMER, &timer)) {
+ pci_read_config_byte(pci_dev, PCI_LATENCY_TIMER, &timer);
+ if (timer == (u8)~0) {
hprintk("can't read latency timer?\n");
return -EINVAL;
}
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index df51680e8931..f4b0c2ecae62 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -3271,7 +3271,8 @@ static int init_card(struct atm_dev *dev)
/* Set PCI Retry-Timeout and TRDY timeout */
IPRINTK("%s: Checking PCI retries.\n", card->name);
- if (pci_read_config_byte(pcidev, 0x40, &pci_byte) != 0) {
+ pci_read_config_byte(pcidev, 0x40, &pci_byte);
+ if (pci_byte == (u_char)~0) {
printk("%s: can't read PCI retry timeout.\n", card->name);
deinit_card(card);
return -1;
@@ -3287,7 +3288,8 @@ static int init_card(struct atm_dev *dev)
}
}
IPRINTK("%s: Checking PCI TRDY.\n", card->name);
- if (pci_read_config_byte(pcidev, 0x41, &pci_byte) != 0) {
+ pci_read_config_byte(pcidev, 0x41, &pci_byte);
+ if (pci_byte == (u_char)~0) {
printk("%s: can't read PCI TRDY timeout.\n", card->name);
deinit_card(card);
return -1;
@@ -3535,7 +3537,8 @@ static int idt77252_preset(struct idt77252_dev *card)
XPRINTK("%s: Enable PCI master and memory access for SAR.\n",
card->name);
- if (pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command)) {
+ pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command);
+ if (pci_command == (u16)~0) {
printk("%s: can't read PCI_COMMAND.\n", card->name);
deinit_card(card);
return -1;
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index 8c7a996d1f16..d3f2fac3a7d1 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -2287,25 +2287,29 @@ static int get_esi(struct atm_dev *dev)
return 0;
}
-static int reset_sar(struct atm_dev *dev)
-{
- IADEV *iadev;
- int i, error = 1;
- unsigned int pci[64];
-
- iadev = INPH_IA_DEV(dev);
- for(i=0; i<64; i++)
- if ((error = pci_read_config_dword(iadev->pci,
- i*4, &pci[i])) != PCIBIOS_SUCCESSFUL)
- return error;
- writel(0, iadev->reg+IPHASE5575_EXT_RESET);
- for(i=0; i<64; i++)
- if ((error = pci_write_config_dword(iadev->pci,
- i*4, pci[i])) != PCIBIOS_SUCCESSFUL)
- return error;
- udelay(5);
- return 0;
-}
+static int reset_sar(struct atm_dev *dev)
+{
+ IADEV *iadev;
+ int i, error = 1;
+ unsigned int pci[64];
+
+ iadev = INPH_IA_DEV(dev);
+ for (i = 0; i < 64; i++) {
+ pci_read_config_dword(iadev->pci, i*4, &pci[i]);
+ if (pci[i] == (u32)~0)
+ return error;
+ }
+
+ writel(0, iadev->reg+IPHASE5575_EXT_RESET);
+ for (i = 0; i < 64; i++) {
+ error = pci_write_config_dword(iadev->pci, i*4, pci[i]);
+ if (error != PCIBIOS_SUCCESSFUL)
+ return error;
+ }
+
+ udelay(5);
+ return 0;
+}
static int ia_init(struct atm_dev *dev)
@@ -2328,8 +2332,8 @@ static int ia_init(struct atm_dev *dev)
real_base = pci_resource_start (iadev->pci, 0);
iadev->irq = iadev->pci->irq;
- error = pci_read_config_word(iadev->pci, PCI_COMMAND, &command);
- if (error) {
+ pci_read_config_word(iadev->pci, PCI_COMMAND, &command);
+ if (command == (u16)~0) {
printk(KERN_ERR DEV_LABEL "(itf %d): init error 0x%x\n",
dev->number,error);
return -EINVAL;
diff --git a/drivers/atm/lanai.c b/drivers/atm/lanai.c
index 645a6bc1df88..aafe1f934385 100644
--- a/drivers/atm/lanai.c
+++ b/drivers/atm/lanai.c
@@ -1097,8 +1097,8 @@ static void pcistatus_check(struct lanai_dev *lanai, int clearonly)
{
u16 s;
int result;
- result = pci_read_config_word(lanai->pci, PCI_STATUS, &s);
- if (result != PCIBIOS_SUCCESSFUL) {
+ pci_read_config_word(lanai->pci, PCI_STATUS, &s);
+ if (s == (u16)~0) {
printk(KERN_ERR DEV_LABEL "(itf %d): can't read PCI_STATUS: "
"%d\n", lanai->number, result);
return;
diff --git a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c
index 7af74fb450a0..74f49f54e024 100644
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -399,7 +399,8 @@ static int ns_init_card(int i, struct pci_dev *pcidev)
pci_set_master(pcidev);
- if (pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency) != 0) {
+ pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency);
+ if (pci_latency == (u8)~0) {
printk("nicstar%d: can't read PCI latency timer.\n", i);
error = 6;
ns_init_card_error(card, error);
diff --git a/drivers/atm/zatm.c b/drivers/atm/zatm.c
index 57f97b95a453..8106ee20a94c 100644
--- a/drivers/atm/zatm.c
+++ b/drivers/atm/zatm.c
@@ -1112,11 +1112,11 @@ static void eprom_set(struct zatm_dev *zatm_dev, unsigned long value,
static unsigned long eprom_get(struct zatm_dev *zatm_dev, unsigned short cmd)
{
unsigned int value;
- int error;
- if ((error = pci_read_config_dword(zatm_dev->pci_dev,cmd,&value)))
+ pci_read_config_dword(zatm_dev->pci_dev, cmd, &value);
+ if (value == (u64)~0)
printk(KERN_ERR DEV_LABEL ": PCI read failed (0x%02x)\n",
- error);
+ value);
return value;
}
@@ -1197,7 +1197,8 @@ static int zatm_init(struct atm_dev *dev)
pci_dev = zatm_dev->pci_dev;
zatm_dev->base = pci_resource_start(pci_dev, 0);
zatm_dev->irq = pci_dev->irq;
- if ((error = pci_read_config_word(pci_dev,PCI_COMMAND,&command))) {
+ pci_read_config_word(pci_dev, PCI_COMMAND, &command);
+ if (command == (u16)~0) {
printk(KERN_ERR DEV_LABEL "(itf %d): init error 0x%02x\n",
dev->number,error);
return -EINVAL;
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 02/17] atm: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Chas Williams
Cc: linux-atm-general, Saheed O. Bolarinwa, linux-kernel, netdev,
linux-pci, linux-kernel-mentees
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/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 +++++----
7 files changed, 50 insertions(+), 36 deletions(-)
diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index 17d47ad03ab7..5beed8a25fa2 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -1585,7 +1585,8 @@ static char * const media_name[] = {
} })
#define GET_SEPROM \
({ if (!error && !pci_error) { \
- pci_error = pci_read_config_byte(eni_dev->pci_dev,PCI_TONGA_CTRL,&tonga); \
+ pci_read_config_byte(eni_dev->pci_dev, PCI_TONGA_CTRL, &tonga); \
+ pci_error = (tonga == (u8)~0) ? -1 : 0; \
udelay(10); /* 10 usecs */ \
} })
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 8af793f5e811..8727ae7746fb 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -995,7 +995,8 @@ static int he_start(struct atm_dev *dev)
*/
/* 4.3 pci bus controller-specific initialization */
- if (pci_read_config_dword(pci_dev, GEN_CNTL_0, &gen_cntl_0) != 0) {
+ pci_read_config_dword(pci_dev, GEN_CNTL_0, &gen_cntl_0);
+ if (gen_cntl_0 == (u32)~0) {
hprintk("can't read GEN_CNTL_0\n");
return -EINVAL;
}
@@ -1005,7 +1006,8 @@ static int he_start(struct atm_dev *dev)
return -EINVAL;
}
- if (pci_read_config_word(pci_dev, PCI_COMMAND, &command) != 0) {
+ pci_read_config_word(pci_dev, PCI_COMMAND, &command);
+ if (command == (u16)~0) {
hprintk("can't read PCI_COMMAND.\n");
return -EINVAL;
}
@@ -1016,7 +1018,8 @@ static int he_start(struct atm_dev *dev)
return -EINVAL;
}
- if (pci_read_config_byte(pci_dev, PCI_CACHE_LINE_SIZE, &cache_size)) {
+ pci_read_config_byte(pci_dev, PCI_CACHE_LINE_SIZE, &cache_size);
+ if (cache_size == (u8)~0) {
hprintk("can't read cache line size?\n");
return -EINVAL;
}
@@ -1027,7 +1030,8 @@ static int he_start(struct atm_dev *dev)
hprintk("can't set cache line size to %d\n", cache_size);
}
- if (pci_read_config_byte(pci_dev, PCI_LATENCY_TIMER, &timer)) {
+ pci_read_config_byte(pci_dev, PCI_LATENCY_TIMER, &timer);
+ if (timer == (u8)~0) {
hprintk("can't read latency timer?\n");
return -EINVAL;
}
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index df51680e8931..f4b0c2ecae62 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -3271,7 +3271,8 @@ static int init_card(struct atm_dev *dev)
/* Set PCI Retry-Timeout and TRDY timeout */
IPRINTK("%s: Checking PCI retries.\n", card->name);
- if (pci_read_config_byte(pcidev, 0x40, &pci_byte) != 0) {
+ pci_read_config_byte(pcidev, 0x40, &pci_byte);
+ if (pci_byte == (u_char)~0) {
printk("%s: can't read PCI retry timeout.\n", card->name);
deinit_card(card);
return -1;
@@ -3287,7 +3288,8 @@ static int init_card(struct atm_dev *dev)
}
}
IPRINTK("%s: Checking PCI TRDY.\n", card->name);
- if (pci_read_config_byte(pcidev, 0x41, &pci_byte) != 0) {
+ pci_read_config_byte(pcidev, 0x41, &pci_byte);
+ if (pci_byte == (u_char)~0) {
printk("%s: can't read PCI TRDY timeout.\n", card->name);
deinit_card(card);
return -1;
@@ -3535,7 +3537,8 @@ static int idt77252_preset(struct idt77252_dev *card)
XPRINTK("%s: Enable PCI master and memory access for SAR.\n",
card->name);
- if (pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command)) {
+ pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command);
+ if (pci_command == (u16)~0) {
printk("%s: can't read PCI_COMMAND.\n", card->name);
deinit_card(card);
return -1;
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index 8c7a996d1f16..d3f2fac3a7d1 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -2287,25 +2287,29 @@ static int get_esi(struct atm_dev *dev)
return 0;
}
-static int reset_sar(struct atm_dev *dev)
-{
- IADEV *iadev;
- int i, error = 1;
- unsigned int pci[64];
-
- iadev = INPH_IA_DEV(dev);
- for(i=0; i<64; i++)
- if ((error = pci_read_config_dword(iadev->pci,
- i*4, &pci[i])) != PCIBIOS_SUCCESSFUL)
- return error;
- writel(0, iadev->reg+IPHASE5575_EXT_RESET);
- for(i=0; i<64; i++)
- if ((error = pci_write_config_dword(iadev->pci,
- i*4, pci[i])) != PCIBIOS_SUCCESSFUL)
- return error;
- udelay(5);
- return 0;
-}
+static int reset_sar(struct atm_dev *dev)
+{
+ IADEV *iadev;
+ int i, error = 1;
+ unsigned int pci[64];
+
+ iadev = INPH_IA_DEV(dev);
+ for (i = 0; i < 64; i++) {
+ pci_read_config_dword(iadev->pci, i*4, &pci[i]);
+ if (pci[i] == (u32)~0)
+ return error;
+ }
+
+ writel(0, iadev->reg+IPHASE5575_EXT_RESET);
+ for (i = 0; i < 64; i++) {
+ error = pci_write_config_dword(iadev->pci, i*4, pci[i]);
+ if (error != PCIBIOS_SUCCESSFUL)
+ return error;
+ }
+
+ udelay(5);
+ return 0;
+}
static int ia_init(struct atm_dev *dev)
@@ -2328,8 +2332,8 @@ static int ia_init(struct atm_dev *dev)
real_base = pci_resource_start (iadev->pci, 0);
iadev->irq = iadev->pci->irq;
- error = pci_read_config_word(iadev->pci, PCI_COMMAND, &command);
- if (error) {
+ pci_read_config_word(iadev->pci, PCI_COMMAND, &command);
+ if (command == (u16)~0) {
printk(KERN_ERR DEV_LABEL "(itf %d): init error 0x%x\n",
dev->number,error);
return -EINVAL;
diff --git a/drivers/atm/lanai.c b/drivers/atm/lanai.c
index 645a6bc1df88..aafe1f934385 100644
--- a/drivers/atm/lanai.c
+++ b/drivers/atm/lanai.c
@@ -1097,8 +1097,8 @@ static void pcistatus_check(struct lanai_dev *lanai, int clearonly)
{
u16 s;
int result;
- result = pci_read_config_word(lanai->pci, PCI_STATUS, &s);
- if (result != PCIBIOS_SUCCESSFUL) {
+ pci_read_config_word(lanai->pci, PCI_STATUS, &s);
+ if (s == (u16)~0) {
printk(KERN_ERR DEV_LABEL "(itf %d): can't read PCI_STATUS: "
"%d\n", lanai->number, result);
return;
diff --git a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c
index 7af74fb450a0..74f49f54e024 100644
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -399,7 +399,8 @@ static int ns_init_card(int i, struct pci_dev *pcidev)
pci_set_master(pcidev);
- if (pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency) != 0) {
+ pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency);
+ if (pci_latency == (u8)~0) {
printk("nicstar%d: can't read PCI latency timer.\n", i);
error = 6;
ns_init_card_error(card, error);
diff --git a/drivers/atm/zatm.c b/drivers/atm/zatm.c
index 57f97b95a453..8106ee20a94c 100644
--- a/drivers/atm/zatm.c
+++ b/drivers/atm/zatm.c
@@ -1112,11 +1112,11 @@ static void eprom_set(struct zatm_dev *zatm_dev, unsigned long value,
static unsigned long eprom_get(struct zatm_dev *zatm_dev, unsigned short cmd)
{
unsigned int value;
- int error;
- if ((error = pci_read_config_dword(zatm_dev->pci_dev,cmd,&value)))
+ pci_read_config_dword(zatm_dev->pci_dev, cmd, &value);
+ if (value == (u64)~0)
printk(KERN_ERR DEV_LABEL ": PCI read failed (0x%02x)\n",
- error);
+ value);
return value;
}
@@ -1197,7 +1197,8 @@ static int zatm_init(struct atm_dev *dev)
pci_dev = zatm_dev->pci_dev;
zatm_dev->base = pci_resource_start(pci_dev, 0);
zatm_dev->irq = pci_dev->irq;
- if ((error = pci_read_config_word(pci_dev,PCI_COMMAND,&command))) {
+ pci_read_config_word(pci_dev, PCI_COMMAND, &command);
+ if (command == (u16)~0) {
printk(KERN_ERR DEV_LABEL "(itf %d): init error 0x%02x\n",
dev->number,error);
return -EINVAL;
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 02/17] atm: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
(?)
@ 2020-08-05 10:51 ` kernel test robot
-1 siblings, 0 replies; 97+ messages in thread
From: kernel test robot @ 2020-08-05 10:51 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 8316 bytes --]
Hi "Saheed,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on linus/master ide/master v5.8 next-20200804]
[cannot apply to ras/edac-for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Saheed-O-Bolarinwa/Drop-uses-of-pci_read_config_-return-value/20200801-202925
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: x86_64-randconfig-r032-20200805 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project e8b7edafc3dd0ab85903eebdfdb3bb7cc2d66743)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/atm/zatm.c:1117:12: warning: result of comparison of constant 18446744073709551615 with expression of type 'unsigned int' is always false [-Wtautological-constant-out-of-range-compare]
if (value == (u64)~0)
~~~~~ ^ ~~~~~~~
>> drivers/atm/zatm.c:1203:19: warning: variable 'error' is uninitialized when used here [-Wuninitialized]
dev->number,error);
^~~~~
drivers/atm/zatm.c:1191:11: note: initialize the variable 'error' to silence this warning
int error,i,last;
^
= 0
2 warnings generated.
--
>> drivers/atm/lanai.c:1103:30: warning: variable 'result' is uninitialized when used here [-Wuninitialized]
"%d\n", lanai->number, result);
^~~~~~
drivers/atm/lanai.c:1099:12: note: initialize the variable 'result' to silence this warning
int result;
^
= 0
1 warning generated.
vim +1117 drivers/atm/zatm.c
1110
1111
1112 static unsigned long eprom_get(struct zatm_dev *zatm_dev, unsigned short cmd)
1113 {
1114 unsigned int value;
1115
1116 pci_read_config_dword(zatm_dev->pci_dev, cmd, &value);
> 1117 if (value == (u64)~0)
1118 printk(KERN_ERR DEV_LABEL ": PCI read failed (0x%02x)\n",
1119 value);
1120 return value;
1121 }
1122
1123
1124 static void eprom_put_bits(struct zatm_dev *zatm_dev, unsigned long data,
1125 int bits, unsigned short cmd)
1126 {
1127 unsigned long value;
1128 int i;
1129
1130 for (i = bits-1; i >= 0; i--) {
1131 value = ZEPROM_CS | (((data >> i) & 1) ? ZEPROM_DI : 0);
1132 eprom_set(zatm_dev,value,cmd);
1133 eprom_set(zatm_dev,value | ZEPROM_SK,cmd);
1134 eprom_set(zatm_dev,value,cmd);
1135 }
1136 }
1137
1138
1139 static void eprom_get_byte(struct zatm_dev *zatm_dev, unsigned char *byte,
1140 unsigned short cmd)
1141 {
1142 int i;
1143
1144 *byte = 0;
1145 for (i = 8; i; i--) {
1146 eprom_set(zatm_dev,ZEPROM_CS,cmd);
1147 eprom_set(zatm_dev,ZEPROM_CS | ZEPROM_SK,cmd);
1148 *byte <<= 1;
1149 if (eprom_get(zatm_dev,cmd) & ZEPROM_DO) *byte |= 1;
1150 eprom_set(zatm_dev,ZEPROM_CS,cmd);
1151 }
1152 }
1153
1154
1155 static int eprom_try_esi(struct atm_dev *dev, unsigned short cmd, int offset,
1156 int swap)
1157 {
1158 unsigned char buf[ZEPROM_SIZE];
1159 struct zatm_dev *zatm_dev;
1160 int i;
1161
1162 zatm_dev = ZATM_DEV(dev);
1163 for (i = 0; i < ZEPROM_SIZE; i += 2) {
1164 eprom_set(zatm_dev,ZEPROM_CS,cmd); /* select EPROM */
1165 eprom_put_bits(zatm_dev,ZEPROM_CMD_READ,ZEPROM_CMD_LEN,cmd);
1166 eprom_put_bits(zatm_dev,i >> 1,ZEPROM_ADDR_LEN,cmd);
1167 eprom_get_byte(zatm_dev,buf+i+swap,cmd);
1168 eprom_get_byte(zatm_dev,buf+i+1-swap,cmd);
1169 eprom_set(zatm_dev,0,cmd); /* deselect EPROM */
1170 }
1171 memcpy(dev->esi,buf+offset,ESI_LEN);
1172 return memcmp(dev->esi,"\0\0\0\0\0",ESI_LEN); /* assumes ESI_LEN == 6 */
1173 }
1174
1175
1176 static void eprom_get_esi(struct atm_dev *dev)
1177 {
1178 if (eprom_try_esi(dev,ZEPROM_V1_REG,ZEPROM_V1_ESI_OFF,1)) return;
1179 (void) eprom_try_esi(dev,ZEPROM_V2_REG,ZEPROM_V2_ESI_OFF,0);
1180 }
1181
1182
1183 /*--------------------------------- entries ---------------------------------*/
1184
1185
1186 static int zatm_init(struct atm_dev *dev)
1187 {
1188 struct zatm_dev *zatm_dev;
1189 struct pci_dev *pci_dev;
1190 unsigned short command;
1191 int error,i,last;
1192 unsigned long t0,t1,t2;
1193
1194 DPRINTK(">zatm_init\n");
1195 zatm_dev = ZATM_DEV(dev);
1196 spin_lock_init(&zatm_dev->lock);
1197 pci_dev = zatm_dev->pci_dev;
1198 zatm_dev->base = pci_resource_start(pci_dev, 0);
1199 zatm_dev->irq = pci_dev->irq;
1200 pci_read_config_word(pci_dev, PCI_COMMAND, &command);
1201 if (command == (u16)~0) {
1202 printk(KERN_ERR DEV_LABEL "(itf %d): init error 0x%02x\n",
> 1203 dev->number,error);
1204 return -EINVAL;
1205 }
1206 if ((error = pci_write_config_word(pci_dev,PCI_COMMAND,
1207 command | PCI_COMMAND_IO | PCI_COMMAND_MASTER))) {
1208 printk(KERN_ERR DEV_LABEL "(itf %d): can't enable IO (0x%02x)"
1209 "\n",dev->number,error);
1210 return -EIO;
1211 }
1212 eprom_get_esi(dev);
1213 printk(KERN_NOTICE DEV_LABEL "(itf %d): rev.%d,base=0x%x,irq=%d,",
1214 dev->number,pci_dev->revision,zatm_dev->base,zatm_dev->irq);
1215 /* reset uPD98401 */
1216 zout(0,SWR);
1217 while (!(zin(GSR) & uPD98401_INT_IND));
1218 zout(uPD98401_GMR_ONE /*uPD98401_BURST4*/,GMR);
1219 last = MAX_CRAM_SIZE;
1220 for (i = last-RAM_INCREMENT; i >= 0; i -= RAM_INCREMENT) {
1221 zpokel(zatm_dev,0x55555555,i);
1222 if (zpeekl(zatm_dev,i) != 0x55555555) last = i;
1223 else {
1224 zpokel(zatm_dev,0xAAAAAAAA,i);
1225 if (zpeekl(zatm_dev,i) != 0xAAAAAAAA) last = i;
1226 else zpokel(zatm_dev,i,i);
1227 }
1228 }
1229 for (i = 0; i < last; i += RAM_INCREMENT)
1230 if (zpeekl(zatm_dev,i) != i) break;
1231 zatm_dev->mem = i << 2;
1232 while (i) zpokel(zatm_dev,0,--i);
1233 /* reset again to rebuild memory pointers */
1234 zout(0,SWR);
1235 while (!(zin(GSR) & uPD98401_INT_IND));
1236 zout(uPD98401_GMR_ONE | uPD98401_BURST8 | uPD98401_BURST4 |
1237 uPD98401_BURST2 | uPD98401_GMR_PM | uPD98401_GMR_DR,GMR);
1238 /* TODO: should shrink allocation now */
1239 printk("mem=%dkB,%s (",zatm_dev->mem >> 10,zatm_dev->copper ? "UTP" :
1240 "MMF");
1241 for (i = 0; i < ESI_LEN; i++)
1242 printk("%02X%s",dev->esi[i],i == ESI_LEN-1 ? ")\n" : "-");
1243 do {
1244 unsigned long flags;
1245
1246 spin_lock_irqsave(&zatm_dev->lock, flags);
1247 t0 = zpeekl(zatm_dev,uPD98401_TSR);
1248 udelay(10);
1249 t1 = zpeekl(zatm_dev,uPD98401_TSR);
1250 udelay(1010);
1251 t2 = zpeekl(zatm_dev,uPD98401_TSR);
1252 spin_unlock_irqrestore(&zatm_dev->lock, flags);
1253 }
1254 while (t0 > t1 || t1 > t2); /* loop if wrapping ... */
1255 zatm_dev->khz = t2-2*t1+t0;
1256 printk(KERN_NOTICE DEV_LABEL "(itf %d): uPD98401 %d.%d at %d.%03d "
1257 "MHz\n",dev->number,
1258 (zin(VER) & uPD98401_MAJOR) >> uPD98401_MAJOR_SHIFT,
1259 zin(VER) & uPD98401_MINOR,zatm_dev->khz/1000,zatm_dev->khz % 1000);
1260 return uPD98402_init(dev);
1261 }
1262
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 42104 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 03/17] bcma: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 03/17] bcma: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Rafał Miłecki
Cc: Saheed O. Bolarinwa, linux-wireless, linux-kernel, linux-pci,
linux-kernel-mentees
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 04/17] hwrng: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-crypto
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/char/hw_random/amd-rng.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 9959c762da2f..e7bf17eedaa0 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -141,9 +141,9 @@ static int __init mod_init(void)
return -ENODEV;
found:
- err = pci_read_config_dword(pdev, 0x58, &pmbase);
- if (err)
- return err;
+ pci_read_config_dword(pdev, 0x58, &pmbase);
+ if (pmbase == (u32)~0)
+ return -ENODEV;
pmbase &= 0x0000FF00;
if (pmbase == 0)
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 04/17] hwrng: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman
Cc: Saheed O. Bolarinwa, linux-kernel, linux-crypto, linux-pci,
linux-kernel-mentees
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/char/hw_random/amd-rng.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 9959c762da2f..e7bf17eedaa0 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -141,9 +141,9 @@ static int __init mod_init(void)
return -ENODEV;
found:
- err = pci_read_config_dword(pdev, 0x58, &pmbase);
- if (err)
- return err;
+ pci_read_config_dword(pdev, 0x58, &pmbase);
+ if (pmbase == (u32)~0)
+ return -ENODEV;
pmbase &= 0x0000FF00;
if (pmbase == 0)
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 05/17] dmaengine: ioat: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Vinod Koul, Dan Williams
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, dmaengine
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/dma/ioat/dma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index fd782aee02d9..e51418cf93b6 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -1016,12 +1016,12 @@ int ioat_reset_hw(struct ioatdma_chan *ioat_chan)
if (ioat_dma->version < IOAT_VER_3_3) {
/* clear any pending errors */
- err = pci_read_config_dword(pdev,
+ pci_read_config_dword(pdev,
IOAT_PCI_CHANERR_INT_OFFSET, &chanerr);
- if (err) {
+ if (chanerr == (u32)~0) {
dev_err(&pdev->dev,
"channel error register unreachable\n");
- return err;
+ return -ENODEV;
}
pci_write_config_dword(pdev,
IOAT_PCI_CHANERR_INT_OFFSET, chanerr);
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 05/17] dmaengine: ioat: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Vinod Koul, Dan Williams
Cc: Saheed O. Bolarinwa, linux-kernel, dmaengine, linux-pci,
linux-kernel-mentees
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/dma/ioat/dma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index fd782aee02d9..e51418cf93b6 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -1016,12 +1016,12 @@ int ioat_reset_hw(struct ioatdma_chan *ioat_chan)
if (ioat_dma->version < IOAT_VER_3_3) {
/* clear any pending errors */
- err = pci_read_config_dword(pdev,
+ pci_read_config_dword(pdev,
IOAT_PCI_CHANERR_INT_OFFSET, &chanerr);
- if (err) {
+ if (chanerr == (u32)~0) {
dev_err(&pdev->dev,
"channel error register unreachable\n");
- return err;
+ return -ENODEV;
}
pci_write_config_dword(pdev,
IOAT_PCI_CHANERR_INT_OFFSET, chanerr);
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 06/17] edac: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Borislav Petkov, Mauro Carvalho Chehab, Tony Luck
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, James Morse, Robert Richter, linux-edac
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.
drivers/edac/amd8111_edac.c edac_pci_read_dword() :
None of the callers of edac_pci_read_dword() uses the return value. The
obtained value can be checked for validity to confirm success.
Change the return type of edac_pci_read_dword() to void.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com>
---
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 ++++++++++++------
6 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 6262f6370c5d..f798eb17cb23 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -57,14 +57,12 @@ static const struct scrubrate {
int __amd64_read_pci_cfg_dword(struct pci_dev *pdev, int offset,
u32 *val, const char *func)
{
- int err = 0;
-
- err = pci_read_config_dword(pdev, offset, val);
- if (err)
+ pci_read_config_dword(pdev, offset, val);
+ if (*val == (u32)~0)
amd64_warn("%s: error reading F%dx%03x.\n",
func, PCI_FUNC(pdev->devfn), offset);
- return err;
+ return -ENODEV;
}
int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int offset,
diff --git a/drivers/edac/amd8111_edac.c b/drivers/edac/amd8111_edac.c
index 7508aa416ddb..ebf6deaf1d3d 100644
--- a/drivers/edac/amd8111_edac.c
+++ b/drivers/edac/amd8111_edac.c
@@ -34,24 +34,18 @@ enum amd8111_edac_pcis {
};
/* Wrapper functions for accessing PCI configuration space */
-static int edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
+static void edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
{
- int ret;
-
- ret = pci_read_config_dword(dev, reg, val32);
- if (ret != 0)
+ pci_read_config_dword(dev, reg, val32);
+ if (val32 == (u32)~0)
printk(KERN_ERR AMD8111_EDAC_MOD_STR
" PCI Access Read Error at 0x%x\n", reg);
-
- return ret;
}
static void edac_pci_read_byte(struct pci_dev *dev, int reg, u8 *val8)
{
- int ret;
-
- ret = pci_read_config_byte(dev, reg, val8);
- if (ret != 0)
+ pci_read_config_byte(dev, reg, val8);
+ if (val8 == (u8)~0)
printk(KERN_ERR AMD8111_EDAC_MOD_STR
" PCI Access Read Error at 0x%x\n", reg);
}
diff --git a/drivers/edac/amd8131_edac.c b/drivers/edac/amd8131_edac.c
index 169353710982..6df98c05391d 100644
--- a/drivers/edac/amd8131_edac.c
+++ b/drivers/edac/amd8131_edac.c
@@ -26,10 +26,8 @@
/* Wrapper functions for accessing PCI configuration space */
static void edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
{
- int ret;
-
- ret = pci_read_config_dword(dev, reg, val32);
- if (ret != 0)
+ pci_read_config_dword(dev, reg, val32);
+ if (val32 == (u32)~0)
printk(KERN_ERR AMD8131_EDAC_MOD_STR
" PCI Access Read Error at 0x%x\n", reg);
}
diff --git a/drivers/edac/i82443bxgx_edac.c b/drivers/edac/i82443bxgx_edac.c
index a2ca929e2168..d6797ed7ac65 100644
--- a/drivers/edac/i82443bxgx_edac.c
+++ b/drivers/edac/i82443bxgx_edac.c
@@ -243,7 +243,8 @@ static int i82443bxgx_edacmc_probe1(struct pci_dev *pdev, int dev_idx)
/* Something is really hosed if PCI config space reads from
* the MC aren't working.
*/
- if (pci_read_config_dword(pdev, I82443BXGX_NBXCFG, &nbxcfg))
+ pci_read_config_dword(pdev, I82443BXGX_NBXCFG, &nbxcfg);
+ if (nbxcfg == (u32)~0)
return -EIO;
layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index d414698ca324..e56a06d68a4e 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1697,13 +1697,15 @@ static int get_dimm_config(struct mem_ctl_info *mci)
if (knl_get_dimm_capacity(pvt, knl_mc_sizes) != 0)
return -1;
- if (pci_read_config_dword(pvt->pci_ta, KNL_MCMTR, &pvt->info.mcmtr)) {
+ pci_read_config_dword(pvt->pci_ta, KNL_MCMTR, &pvt->info.mcmtr);
+ if (pvt->info.mcmtr == (u32)~0) {
edac_dbg(0, "Failed to read KNL_MCMTR register\n");
return -ENODEV;
}
} else {
if (pvt->info.type == HASWELL || pvt->info.type == BROADWELL) {
- if (pci_read_config_dword(pvt->pci_ha, HASWELL_HASYSDEFEATURE2, ®)) {
+ pci_read_config_dword(pvt->pci_ha, HASWELL_HASYSDEFEATURE2, ®);
+ if (reg == (u32)~0) {
edac_dbg(0, "Failed to read HASWELL_HASYSDEFEATURE2 register\n");
return -ENODEV;
}
@@ -1714,7 +1716,8 @@ static int get_dimm_config(struct mem_ctl_info *mci)
goto next;
}
}
- if (pci_read_config_dword(pvt->pci_ras, RASENABLES, ®)) {
+ pci_read_config_dword(pvt->pci_ras, RASENABLES, ®);
+ if (reg == (u32)~0) {
edac_dbg(0, "Failed to read RASENABLES register\n");
return -ENODEV;
}
@@ -1727,7 +1730,8 @@ static int get_dimm_config(struct mem_ctl_info *mci)
}
next:
- if (pci_read_config_dword(pvt->pci_ta, MCMTR, &pvt->info.mcmtr)) {
+ pci_read_config_dword(pvt->pci_ta, MCMTR, &pvt->info.mcmtr);
+ if (pvt->info.mcmtr == (u32)~0) {
edac_dbg(0, "Failed to read MCMTR register\n");
return -ENODEV;
}
diff --git a/drivers/edac/skx_common.c b/drivers/edac/skx_common.c
index 6d8d6dc626bf..7956c75c289f 100644
--- a/drivers/edac/skx_common.c
+++ b/drivers/edac/skx_common.c
@@ -161,7 +161,8 @@ int skx_get_src_id(struct skx_dev *d, int off, u8 *id)
{
u32 reg;
- if (pci_read_config_dword(d->util_all, off, ®)) {
+ pci_read_config_dword(d->util_all, off, ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read src id\n");
return -ENODEV;
}
@@ -174,7 +175,8 @@ int skx_get_node_id(struct skx_dev *d, u8 *id)
{
u32 reg;
- if (pci_read_config_dword(d->util_all, 0xf4, ®)) {
+ pci_read_config_dword(d->util_all, 0xf4, ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read node id\n");
return -ENODEV;
}
@@ -220,7 +222,8 @@ int skx_get_all_bus_mappings(struct res_config *cfg, struct list_head **list)
return -ENOMEM;
}
- if (pci_read_config_dword(pdev, cfg->busno_cfg_offset, ®)) {
+ pci_read_config_dword(pdev, cfg->busno_cfg_offset, ®);
+ if (reg == (u32)~0) {
kfree(d);
pci_dev_put(pdev);
skx_printk(KERN_ERR, "Failed to read bus idx\n");
@@ -259,19 +262,22 @@ int skx_get_hi_lo(unsigned int did, int off[], u64 *tolm, u64 *tohm)
return -ENODEV;
}
- if (pci_read_config_dword(pdev, off[0], ®)) {
+ pci_read_config_dword(pdev, off[0], ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read tolm\n");
goto fail;
}
skx_tolm = reg;
- if (pci_read_config_dword(pdev, off[1], ®)) {
+ pci_read_config_dword(pdev, off[1], ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read lower tohm\n");
goto fail;
}
skx_tohm = reg;
- if (pci_read_config_dword(pdev, off[2], ®)) {
+ pci_read_config_dword(pdev, off[2], ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read upper tohm\n");
goto fail;
}
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 06/17] edac: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Borislav Petkov, Mauro Carvalho Chehab, Tony Luck
Cc: Saheed O. Bolarinwa, linux-kernel, Robert Richter, James Morse,
linux-pci, linux-kernel-mentees, linux-edac
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.
drivers/edac/amd8111_edac.c edac_pci_read_dword() :
None of the callers of edac_pci_read_dword() uses the return value. The
obtained value can be checked for validity to confirm success.
Change the return type of edac_pci_read_dword() to void.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com>
---
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 ++++++++++++------
6 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 6262f6370c5d..f798eb17cb23 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -57,14 +57,12 @@ static const struct scrubrate {
int __amd64_read_pci_cfg_dword(struct pci_dev *pdev, int offset,
u32 *val, const char *func)
{
- int err = 0;
-
- err = pci_read_config_dword(pdev, offset, val);
- if (err)
+ pci_read_config_dword(pdev, offset, val);
+ if (*val == (u32)~0)
amd64_warn("%s: error reading F%dx%03x.\n",
func, PCI_FUNC(pdev->devfn), offset);
- return err;
+ return -ENODEV;
}
int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int offset,
diff --git a/drivers/edac/amd8111_edac.c b/drivers/edac/amd8111_edac.c
index 7508aa416ddb..ebf6deaf1d3d 100644
--- a/drivers/edac/amd8111_edac.c
+++ b/drivers/edac/amd8111_edac.c
@@ -34,24 +34,18 @@ enum amd8111_edac_pcis {
};
/* Wrapper functions for accessing PCI configuration space */
-static int edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
+static void edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
{
- int ret;
-
- ret = pci_read_config_dword(dev, reg, val32);
- if (ret != 0)
+ pci_read_config_dword(dev, reg, val32);
+ if (val32 == (u32)~0)
printk(KERN_ERR AMD8111_EDAC_MOD_STR
" PCI Access Read Error at 0x%x\n", reg);
-
- return ret;
}
static void edac_pci_read_byte(struct pci_dev *dev, int reg, u8 *val8)
{
- int ret;
-
- ret = pci_read_config_byte(dev, reg, val8);
- if (ret != 0)
+ pci_read_config_byte(dev, reg, val8);
+ if (val8 == (u8)~0)
printk(KERN_ERR AMD8111_EDAC_MOD_STR
" PCI Access Read Error at 0x%x\n", reg);
}
diff --git a/drivers/edac/amd8131_edac.c b/drivers/edac/amd8131_edac.c
index 169353710982..6df98c05391d 100644
--- a/drivers/edac/amd8131_edac.c
+++ b/drivers/edac/amd8131_edac.c
@@ -26,10 +26,8 @@
/* Wrapper functions for accessing PCI configuration space */
static void edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
{
- int ret;
-
- ret = pci_read_config_dword(dev, reg, val32);
- if (ret != 0)
+ pci_read_config_dword(dev, reg, val32);
+ if (val32 == (u32)~0)
printk(KERN_ERR AMD8131_EDAC_MOD_STR
" PCI Access Read Error at 0x%x\n", reg);
}
diff --git a/drivers/edac/i82443bxgx_edac.c b/drivers/edac/i82443bxgx_edac.c
index a2ca929e2168..d6797ed7ac65 100644
--- a/drivers/edac/i82443bxgx_edac.c
+++ b/drivers/edac/i82443bxgx_edac.c
@@ -243,7 +243,8 @@ static int i82443bxgx_edacmc_probe1(struct pci_dev *pdev, int dev_idx)
/* Something is really hosed if PCI config space reads from
* the MC aren't working.
*/
- if (pci_read_config_dword(pdev, I82443BXGX_NBXCFG, &nbxcfg))
+ pci_read_config_dword(pdev, I82443BXGX_NBXCFG, &nbxcfg);
+ if (nbxcfg == (u32)~0)
return -EIO;
layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index d414698ca324..e56a06d68a4e 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1697,13 +1697,15 @@ static int get_dimm_config(struct mem_ctl_info *mci)
if (knl_get_dimm_capacity(pvt, knl_mc_sizes) != 0)
return -1;
- if (pci_read_config_dword(pvt->pci_ta, KNL_MCMTR, &pvt->info.mcmtr)) {
+ pci_read_config_dword(pvt->pci_ta, KNL_MCMTR, &pvt->info.mcmtr);
+ if (pvt->info.mcmtr == (u32)~0) {
edac_dbg(0, "Failed to read KNL_MCMTR register\n");
return -ENODEV;
}
} else {
if (pvt->info.type == HASWELL || pvt->info.type == BROADWELL) {
- if (pci_read_config_dword(pvt->pci_ha, HASWELL_HASYSDEFEATURE2, ®)) {
+ pci_read_config_dword(pvt->pci_ha, HASWELL_HASYSDEFEATURE2, ®);
+ if (reg == (u32)~0) {
edac_dbg(0, "Failed to read HASWELL_HASYSDEFEATURE2 register\n");
return -ENODEV;
}
@@ -1714,7 +1716,8 @@ static int get_dimm_config(struct mem_ctl_info *mci)
goto next;
}
}
- if (pci_read_config_dword(pvt->pci_ras, RASENABLES, ®)) {
+ pci_read_config_dword(pvt->pci_ras, RASENABLES, ®);
+ if (reg == (u32)~0) {
edac_dbg(0, "Failed to read RASENABLES register\n");
return -ENODEV;
}
@@ -1727,7 +1730,8 @@ static int get_dimm_config(struct mem_ctl_info *mci)
}
next:
- if (pci_read_config_dword(pvt->pci_ta, MCMTR, &pvt->info.mcmtr)) {
+ pci_read_config_dword(pvt->pci_ta, MCMTR, &pvt->info.mcmtr);
+ if (pvt->info.mcmtr == (u32)~0) {
edac_dbg(0, "Failed to read MCMTR register\n");
return -ENODEV;
}
diff --git a/drivers/edac/skx_common.c b/drivers/edac/skx_common.c
index 6d8d6dc626bf..7956c75c289f 100644
--- a/drivers/edac/skx_common.c
+++ b/drivers/edac/skx_common.c
@@ -161,7 +161,8 @@ int skx_get_src_id(struct skx_dev *d, int off, u8 *id)
{
u32 reg;
- if (pci_read_config_dword(d->util_all, off, ®)) {
+ pci_read_config_dword(d->util_all, off, ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read src id\n");
return -ENODEV;
}
@@ -174,7 +175,8 @@ int skx_get_node_id(struct skx_dev *d, u8 *id)
{
u32 reg;
- if (pci_read_config_dword(d->util_all, 0xf4, ®)) {
+ pci_read_config_dword(d->util_all, 0xf4, ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read node id\n");
return -ENODEV;
}
@@ -220,7 +222,8 @@ int skx_get_all_bus_mappings(struct res_config *cfg, struct list_head **list)
return -ENOMEM;
}
- if (pci_read_config_dword(pdev, cfg->busno_cfg_offset, ®)) {
+ pci_read_config_dword(pdev, cfg->busno_cfg_offset, ®);
+ if (reg == (u32)~0) {
kfree(d);
pci_dev_put(pdev);
skx_printk(KERN_ERR, "Failed to read bus idx\n");
@@ -259,19 +262,22 @@ int skx_get_hi_lo(unsigned int did, int off[], u64 *tolm, u64 *tohm)
return -ENODEV;
}
- if (pci_read_config_dword(pdev, off[0], ®)) {
+ pci_read_config_dword(pdev, off[0], ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read tolm\n");
goto fail;
}
skx_tolm = reg;
- if (pci_read_config_dword(pdev, off[1], ®)) {
+ pci_read_config_dword(pdev, off[1], ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read lower tohm\n");
goto fail;
}
skx_tohm = reg;
- if (pci_read_config_dword(pdev, off[2], ®)) {
+ pci_read_config_dword(pdev, off[2], ®);
+ if (reg == (u32)~0) {
skx_printk(KERN_ERR, "Failed to read upper tohm\n");
goto fail;
}
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 06/17] edac: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
(?)
@ 2020-08-01 21:38 ` kernel test robot
-1 siblings, 0 replies; 97+ messages in thread
From: kernel test robot @ 2020-08-01 21:38 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
Hi "Saheed,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on linus/master v5.8-rc7 next-20200731]
[cannot apply to ras/edac-for-next ide/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Saheed-O-Bolarinwa/Drop-uses-of-pci_read_config_-return-value/20200801-202925
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/edac/amd8111_edac.c: In function 'edac_pci_read_dword':
>> drivers/edac/amd8111_edac.c:40:12: warning: comparison between pointer and integer
40 | if (val32 == (u32)~0)
| ^~
drivers/edac/amd8111_edac.c: In function 'edac_pci_read_byte':
drivers/edac/amd8111_edac.c:48:11: warning: comparison between pointer and integer
48 | if (val8 == (u8)~0)
| ^~
--
drivers/edac/amd8131_edac.c: In function 'edac_pci_read_dword':
>> drivers/edac/amd8131_edac.c:30:12: warning: comparison between pointer and integer
30 | if (val32 == (u32)~0)
| ^~
vim +40 drivers/edac/amd8111_edac.c
35
36 /* Wrapper functions for accessing PCI configuration space */
37 static void edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
38 {
39 pci_read_config_dword(dev, reg, val32);
> 40 if (val32 == (u32)~0)
41 printk(KERN_ERR AMD8111_EDAC_MOD_STR
42 " PCI Access Read Error at 0x%x\n", reg);
43 }
44
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 69760 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 07/17] fpga: altera-cvp: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Moritz Fischer
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-fpga
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/fpga/altera-cvp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
index 4e0edb60bfba..99c6e0754f8b 100644
--- a/drivers/fpga/altera-cvp.c
+++ b/drivers/fpga/altera-cvp.c
@@ -96,15 +96,15 @@ struct cvp_priv {
static int altera_read_config_byte(struct altera_cvp_conf *conf,
int where, u8 *val)
{
- return pci_read_config_byte(conf->pci_dev, conf->vsec_offset + where,
- val);
+ pci_read_config_byte(conf->pci_dev, conf->vsec_offset + where, val);
+ return (val == (u8)~0) ? -ENODEV : 0;
}
static int altera_read_config_dword(struct altera_cvp_conf *conf,
int where, u32 *val)
{
- return pci_read_config_dword(conf->pci_dev, conf->vsec_offset + where,
- val);
+ pci_read_config_dword(conf->pci_dev, conf->vsec_offset + where, val);
+ return (val == (u32)~0) ? -ENODEV : 0;
}
static int altera_write_config_dword(struct altera_cvp_conf *conf,
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 07/17] fpga: altera-cvp: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Moritz Fischer
Cc: Saheed O. Bolarinwa, linux-fpga, linux-kernel, linux-pci,
linux-kernel-mentees
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/fpga/altera-cvp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
index 4e0edb60bfba..99c6e0754f8b 100644
--- a/drivers/fpga/altera-cvp.c
+++ b/drivers/fpga/altera-cvp.c
@@ -96,15 +96,15 @@ struct cvp_priv {
static int altera_read_config_byte(struct altera_cvp_conf *conf,
int where, u8 *val)
{
- return pci_read_config_byte(conf->pci_dev, conf->vsec_offset + where,
- val);
+ pci_read_config_byte(conf->pci_dev, conf->vsec_offset + where, val);
+ return (val == (u8)~0) ? -ENODEV : 0;
}
static int altera_read_config_dword(struct altera_cvp_conf *conf,
int where, u32 *val)
{
- return pci_read_config_dword(conf->pci_dev, conf->vsec_offset + where,
- val);
+ pci_read_config_dword(conf->pci_dev, conf->vsec_offset + where, val);
+ return (val == (u32)~0) ? -ENODEV : 0;
}
static int altera_write_config_dword(struct altera_cvp_conf *conf,
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 07/17] fpga: altera-cvp: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
(?)
@ 2020-08-01 22:32 ` kernel test robot
-1 siblings, 0 replies; 97+ messages in thread
From: kernel test robot @ 2020-08-01 22:32 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2634 bytes --]
Hi "Saheed,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on linus/master v5.8-rc7 next-20200731]
[cannot apply to ras/edac-for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Saheed-O-Bolarinwa/Drop-uses-of-pci_read_config_-return-value/20200801-202925
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: arm64-randconfig-r032-20200801 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 9f21947a331203ee2579db87f1d1ec22a949e20a)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/fpga/altera-cvp.c:100:14: warning: comparison between pointer and integer ('u8 *' (aka 'unsigned char *') and 'u8' (aka 'unsigned char')) [-Wpointer-integer-compare]
return (val == (u8)~0) ? -ENODEV : 0;
~~~ ^ ~~~~~~
>> drivers/fpga/altera-cvp.c:107:14: warning: comparison between pointer and integer ('u32 *' (aka 'unsigned int *') and 'u32' (aka 'unsigned int')) [-Wpointer-integer-compare]
return (val == (u32)~0) ? -ENODEV : 0;
~~~ ^ ~~~~~~~
2 warnings generated.
vim +100 drivers/fpga/altera-cvp.c
95
96 static int altera_read_config_byte(struct altera_cvp_conf *conf,
97 int where, u8 *val)
98 {
99 pci_read_config_byte(conf->pci_dev, conf->vsec_offset + where, val);
> 100 return (val == (u8)~0) ? -ENODEV : 0;
101 }
102
103 static int altera_read_config_dword(struct altera_cvp_conf *conf,
104 int where, u32 *val)
105 {
106 pci_read_config_dword(conf->pci_dev, conf->vsec_offset + where, val);
> 107 return (val == (u32)~0) ? -ENODEV : 0;
108 }
109
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 34591 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 07/17] fpga: altera-cvp: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
(?)
(?)
@ 2020-08-05 12:31 ` kernel test robot
-1 siblings, 0 replies; 97+ messages in thread
From: kernel test robot @ 2020-08-05 12:31 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]
Hi "Saheed,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on linus/master ide/master v5.8 next-20200805]
[cannot apply to ras/edac-for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Saheed-O-Bolarinwa/Drop-uses-of-pci_read_config_-return-value/20200801-202925
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: i386-randconfig-s001-20200805 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-117-g8c7aee71-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/fpga/altera-cvp.c:100:21: sparse: sparse: incompatible types for operation (==):
>> drivers/fpga/altera-cvp.c:100:21: sparse: unsigned char [usertype] *val
>> drivers/fpga/altera-cvp.c:100:21: sparse: unsigned char [usertype]
drivers/fpga/altera-cvp.c:107:21: sparse: sparse: incompatible types for operation (==):
>> drivers/fpga/altera-cvp.c:107:21: sparse: unsigned int [usertype] *val
>> drivers/fpga/altera-cvp.c:107:21: sparse: unsigned int [usertype]
vim +100 drivers/fpga/altera-cvp.c
95
96 static int altera_read_config_byte(struct altera_cvp_conf *conf,
97 int where, u8 *val)
98 {
99 pci_read_config_byte(conf->pci_dev, conf->vsec_offset + where, val);
> 100 return (val == (u8)~0) ? -ENODEV : 0;
101 }
102
103 static int altera_read_config_dword(struct altera_cvp_conf *conf,
104 int where, u32 *val)
105 {
106 pci_read_config_dword(conf->pci_dev, conf->vsec_offset + where, val);
> 107 return (val == (u32)~0) ? -ENODEV : 0;
108 }
109
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 26068 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 08/17] gpio: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Bartosz Golaszewski, Linus Walleij
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-gpio
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/gpio/gpio-amd8111.c | 7 +++++--
drivers/gpio/gpio-rdc321x.c | 21 ++++++++++++---------
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c
index fdcebe59510d..7b9882380cbc 100644
--- a/drivers/gpio/gpio-amd8111.c
+++ b/drivers/gpio/gpio-amd8111.c
@@ -198,9 +198,12 @@ static int __init amd_gpio_init(void)
goto out;
found:
- err = pci_read_config_dword(pdev, 0x58, &gp.pmbase);
- if (err)
+ pci_read_config_dword(pdev, 0x58, &gp.pmbase);
+ if (gp.pmbase == (u32)~0) {
+ err = -ENODEV;
goto out;
+ }
+
err = -EIO;
gp.pmbase &= 0x0000FF00;
if (gp.pmbase == 0)
diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c
index 01ed2517e9fd..03f1ff07b844 100644
--- a/drivers/gpio/gpio-rdc321x.c
+++ b/drivers/gpio/gpio-rdc321x.c
@@ -85,10 +85,13 @@ static int rdc_gpio_config(struct gpio_chip *chip,
gpch = gpiochip_get_data(chip);
spin_lock(&gpch->lock);
- err = pci_read_config_dword(gpch->sb_pdev, gpio < 32 ?
- gpch->reg1_ctrl_base : gpch->reg2_ctrl_base, ®);
- if (err)
+ pci_read_config_dword(gpch->sb_pdev,
+ (gpio < 32) ? gpch->reg1_ctrl_base
+ : gpch->reg2_ctrl_base, ®);
+ if (reg == (u32)~0) {
+ err = -ENODEV;
goto unlock;
+ }
reg |= 1 << (gpio & 0x1f);
@@ -166,17 +169,17 @@ static int rdc321x_gpio_probe(struct platform_device *pdev)
/* This might not be, what others (BIOS, bootloader, etc.)
wrote to these registers before, but it's a good guess. Still
better than just using 0xffffffff. */
- err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
+ pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
rdc321x_gpio_dev->reg1_data_base,
&rdc321x_gpio_dev->data_reg[0]);
- if (err)
- return err;
+ if (rdc321x_gpio_dev->data_reg[0] == (u32)~0)
+ return -ENODEV;
- err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
+ pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
rdc321x_gpio_dev->reg2_data_base,
&rdc321x_gpio_dev->data_reg[1]);
- if (err)
- return err;
+ if (rdc321x_gpio_dev->data_reg[1] == (u32)~0)
+ return -ENODEV;
dev_info(&pdev->dev, "registering %d GPIOs\n",
rdc321x_gpio_dev->chip.ngpio);
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 08/17] gpio: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Bartosz Golaszewski, Linus Walleij
Cc: Saheed O. Bolarinwa, linux-kernel, linux-gpio, linux-pci,
linux-kernel-mentees
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/gpio/gpio-amd8111.c | 7 +++++--
drivers/gpio/gpio-rdc321x.c | 21 ++++++++++++---------
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c
index fdcebe59510d..7b9882380cbc 100644
--- a/drivers/gpio/gpio-amd8111.c
+++ b/drivers/gpio/gpio-amd8111.c
@@ -198,9 +198,12 @@ static int __init amd_gpio_init(void)
goto out;
found:
- err = pci_read_config_dword(pdev, 0x58, &gp.pmbase);
- if (err)
+ pci_read_config_dword(pdev, 0x58, &gp.pmbase);
+ if (gp.pmbase == (u32)~0) {
+ err = -ENODEV;
goto out;
+ }
+
err = -EIO;
gp.pmbase &= 0x0000FF00;
if (gp.pmbase == 0)
diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c
index 01ed2517e9fd..03f1ff07b844 100644
--- a/drivers/gpio/gpio-rdc321x.c
+++ b/drivers/gpio/gpio-rdc321x.c
@@ -85,10 +85,13 @@ static int rdc_gpio_config(struct gpio_chip *chip,
gpch = gpiochip_get_data(chip);
spin_lock(&gpch->lock);
- err = pci_read_config_dword(gpch->sb_pdev, gpio < 32 ?
- gpch->reg1_ctrl_base : gpch->reg2_ctrl_base, ®);
- if (err)
+ pci_read_config_dword(gpch->sb_pdev,
+ (gpio < 32) ? gpch->reg1_ctrl_base
+ : gpch->reg2_ctrl_base, ®);
+ if (reg == (u32)~0) {
+ err = -ENODEV;
goto unlock;
+ }
reg |= 1 << (gpio & 0x1f);
@@ -166,17 +169,17 @@ static int rdc321x_gpio_probe(struct platform_device *pdev)
/* This might not be, what others (BIOS, bootloader, etc.)
wrote to these registers before, but it's a good guess. Still
better than just using 0xffffffff. */
- err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
+ pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
rdc321x_gpio_dev->reg1_data_base,
&rdc321x_gpio_dev->data_reg[0]);
- if (err)
- return err;
+ if (rdc321x_gpio_dev->data_reg[0] == (u32)~0)
+ return -ENODEV;
- err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
+ pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
rdc321x_gpio_dev->reg2_data_base,
&rdc321x_gpio_dev->data_reg[1]);
- if (err)
- return err;
+ if (rdc321x_gpio_dev->data_reg[1] == (u32)~0)
+ return -ENODEV;
dev_info(&pdev->dev, "registering %d GPIOs\n",
rdc321x_gpio_dev->chip.ngpio);
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 08/17] gpio: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
@ 2020-08-18 19:59 ` Bartosz Golaszewski
-1 siblings, 0 replies; 97+ messages in thread
From: Bartosz Golaszewski @ 2020-08-18 19:59 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Linus Walleij, Saheed O. Bolarinwa, bjorn, Shuah Khan,
linux-kernel-mentees, linux-pci, LKML, linux-gpio
On Sat, Aug 1, 2020 at 2:24 PM Saheed O. Bolarinwa
<refactormyself@gmail.com> 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.
>
> 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/gpio/gpio-amd8111.c | 7 +++++--
> drivers/gpio/gpio-rdc321x.c | 21 ++++++++++++---------
> 2 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c
> index fdcebe59510d..7b9882380cbc 100644
> --- a/drivers/gpio/gpio-amd8111.c
> +++ b/drivers/gpio/gpio-amd8111.c
> @@ -198,9 +198,12 @@ static int __init amd_gpio_init(void)
> goto out;
>
> found:
> - err = pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> - if (err)
> + pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> + if (gp.pmbase == (u32)~0) {
> + err = -ENODEV;
> goto out;
> + }
> +
> err = -EIO;
> gp.pmbase &= 0x0000FF00;
> if (gp.pmbase == 0)
> diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c
> index 01ed2517e9fd..03f1ff07b844 100644
> --- a/drivers/gpio/gpio-rdc321x.c
> +++ b/drivers/gpio/gpio-rdc321x.c
> @@ -85,10 +85,13 @@ static int rdc_gpio_config(struct gpio_chip *chip,
> gpch = gpiochip_get_data(chip);
>
> spin_lock(&gpch->lock);
> - err = pci_read_config_dword(gpch->sb_pdev, gpio < 32 ?
> - gpch->reg1_ctrl_base : gpch->reg2_ctrl_base, ®);
> - if (err)
> + pci_read_config_dword(gpch->sb_pdev,
> + (gpio < 32) ? gpch->reg1_ctrl_base
> + : gpch->reg2_ctrl_base, ®);
> + if (reg == (u32)~0) {
> + err = -ENODEV;
> goto unlock;
> + }
>
> reg |= 1 << (gpio & 0x1f);
>
> @@ -166,17 +169,17 @@ static int rdc321x_gpio_probe(struct platform_device *pdev)
> /* This might not be, what others (BIOS, bootloader, etc.)
> wrote to these registers before, but it's a good guess. Still
> better than just using 0xffffffff. */
> - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> rdc321x_gpio_dev->reg1_data_base,
> &rdc321x_gpio_dev->data_reg[0]);
> - if (err)
> - return err;
> + if (rdc321x_gpio_dev->data_reg[0] == (u32)~0)
> + return -ENODEV;
>
> - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> rdc321x_gpio_dev->reg2_data_base,
> &rdc321x_gpio_dev->data_reg[1]);
> - if (err)
> - return err;
> + if (rdc321x_gpio_dev->data_reg[1] == (u32)~0)
> + return -ENODEV;
>
> dev_info(&pdev->dev, "registering %d GPIOs\n",
> rdc321x_gpio_dev->chip.ngpio);
> --
> 2.18.4
>
Bjorn,
I don't know the pci sub-system at all. Does this look good to you?
Bartosz
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 08/17] gpio: Drop uses of pci_read_config_*() return value
@ 2020-08-18 19:59 ` Bartosz Golaszewski
0 siblings, 0 replies; 97+ messages in thread
From: Bartosz Golaszewski @ 2020-08-18 19:59 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Saheed O. Bolarinwa, Linus Walleij, LKML, linux-gpio, linux-pci,
linux-kernel-mentees
On Sat, Aug 1, 2020 at 2:24 PM Saheed O. Bolarinwa
<refactormyself@gmail.com> 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.
>
> 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/gpio/gpio-amd8111.c | 7 +++++--
> drivers/gpio/gpio-rdc321x.c | 21 ++++++++++++---------
> 2 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c
> index fdcebe59510d..7b9882380cbc 100644
> --- a/drivers/gpio/gpio-amd8111.c
> +++ b/drivers/gpio/gpio-amd8111.c
> @@ -198,9 +198,12 @@ static int __init amd_gpio_init(void)
> goto out;
>
> found:
> - err = pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> - if (err)
> + pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> + if (gp.pmbase == (u32)~0) {
> + err = -ENODEV;
> goto out;
> + }
> +
> err = -EIO;
> gp.pmbase &= 0x0000FF00;
> if (gp.pmbase == 0)
> diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c
> index 01ed2517e9fd..03f1ff07b844 100644
> --- a/drivers/gpio/gpio-rdc321x.c
> +++ b/drivers/gpio/gpio-rdc321x.c
> @@ -85,10 +85,13 @@ static int rdc_gpio_config(struct gpio_chip *chip,
> gpch = gpiochip_get_data(chip);
>
> spin_lock(&gpch->lock);
> - err = pci_read_config_dword(gpch->sb_pdev, gpio < 32 ?
> - gpch->reg1_ctrl_base : gpch->reg2_ctrl_base, ®);
> - if (err)
> + pci_read_config_dword(gpch->sb_pdev,
> + (gpio < 32) ? gpch->reg1_ctrl_base
> + : gpch->reg2_ctrl_base, ®);
> + if (reg == (u32)~0) {
> + err = -ENODEV;
> goto unlock;
> + }
>
> reg |= 1 << (gpio & 0x1f);
>
> @@ -166,17 +169,17 @@ static int rdc321x_gpio_probe(struct platform_device *pdev)
> /* This might not be, what others (BIOS, bootloader, etc.)
> wrote to these registers before, but it's a good guess. Still
> better than just using 0xffffffff. */
> - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> rdc321x_gpio_dev->reg1_data_base,
> &rdc321x_gpio_dev->data_reg[0]);
> - if (err)
> - return err;
> + if (rdc321x_gpio_dev->data_reg[0] == (u32)~0)
> + return -ENODEV;
>
> - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> rdc321x_gpio_dev->reg2_data_base,
> &rdc321x_gpio_dev->data_reg[1]);
> - if (err)
> - return err;
> + if (rdc321x_gpio_dev->data_reg[1] == (u32)~0)
> + return -ENODEV;
>
> dev_info(&pdev->dev, "registering %d GPIOs\n",
> rdc321x_gpio_dev->chip.ngpio);
> --
> 2.18.4
>
Bjorn,
I don't know the pci sub-system at all. Does this look good to you?
Bartosz
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 08/17] gpio: Drop uses of pci_read_config_*() return value
2020-08-18 19:59 ` [Linux-kernel-mentees] " Bartosz Golaszewski
@ 2020-08-19 2:21 ` Bjorn Helgaas
-1 siblings, 0 replies; 97+ messages in thread
From: Bjorn Helgaas @ 2020-08-19 2:21 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Linus Walleij, Saheed O. Bolarinwa, bjorn, Shuah Khan,
linux-kernel-mentees, linux-pci, LKML, linux-gpio
On Tue, Aug 18, 2020 at 09:59:50PM +0200, Bartosz Golaszewski wrote:
> On Sat, Aug 1, 2020 at 2:24 PM Saheed O. Bolarinwa
> <refactormyself@gmail.com> 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.
> >
> > 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/gpio/gpio-amd8111.c | 7 +++++--
> > drivers/gpio/gpio-rdc321x.c | 21 ++++++++++++---------
> > 2 files changed, 17 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c
> > index fdcebe59510d..7b9882380cbc 100644
> > --- a/drivers/gpio/gpio-amd8111.c
> > +++ b/drivers/gpio/gpio-amd8111.c
> > @@ -198,9 +198,12 @@ static int __init amd_gpio_init(void)
> > goto out;
> >
> > found:
> > - err = pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> > - if (err)
> > + pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> > + if (gp.pmbase == (u32)~0) {
> > + err = -ENODEV;
> > goto out;
> > + }
> > +
> > err = -EIO;
> > gp.pmbase &= 0x0000FF00;
> > if (gp.pmbase == 0)
> > diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c
> > index 01ed2517e9fd..03f1ff07b844 100644
> > --- a/drivers/gpio/gpio-rdc321x.c
> > +++ b/drivers/gpio/gpio-rdc321x.c
> > @@ -85,10 +85,13 @@ static int rdc_gpio_config(struct gpio_chip *chip,
> > gpch = gpiochip_get_data(chip);
> >
> > spin_lock(&gpch->lock);
> > - err = pci_read_config_dword(gpch->sb_pdev, gpio < 32 ?
> > - gpch->reg1_ctrl_base : gpch->reg2_ctrl_base, ®);
> > - if (err)
> > + pci_read_config_dword(gpch->sb_pdev,
> > + (gpio < 32) ? gpch->reg1_ctrl_base
> > + : gpch->reg2_ctrl_base, ®);
> > + if (reg == (u32)~0) {
> > + err = -ENODEV;
> > goto unlock;
> > + }
> >
> > reg |= 1 << (gpio & 0x1f);
> >
> > @@ -166,17 +169,17 @@ static int rdc321x_gpio_probe(struct platform_device *pdev)
> > /* This might not be, what others (BIOS, bootloader, etc.)
> > wrote to these registers before, but it's a good guess. Still
> > better than just using 0xffffffff. */
> > - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > rdc321x_gpio_dev->reg1_data_base,
> > &rdc321x_gpio_dev->data_reg[0]);
> > - if (err)
> > - return err;
> > + if (rdc321x_gpio_dev->data_reg[0] == (u32)~0)
> > + return -ENODEV;
> >
> > - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > rdc321x_gpio_dev->reg2_data_base,
> > &rdc321x_gpio_dev->data_reg[1]);
> > - if (err)
> > - return err;
> > + if (rdc321x_gpio_dev->data_reg[1] == (u32)~0)
> > + return -ENODEV;
> >
> > dev_info(&pdev->dev, "registering %d GPIOs\n",
> > rdc321x_gpio_dev->chip.ngpio);
> > --
> > 2.18.4
> >
>
> Bjorn,
>
> I don't know the pci sub-system at all. Does this look good to you?
I wouldn't apply this at this point. It's definitely true that when
pci_read_config_dword() returns an error, it's likely an alignment
problem or some other programming error, not an actual PCI error.
If an actual PCI error occurs (device failed to respond, transaction
failed because of noise or electrical issue, etc),
pci_read_config_dword() will *not* return an error; the data it reads,
e.g., rdc321x_gpio_dev->data_reg[1], will be ~0.
So with the current pci_read_config_dword() implementation, we really
need to test *both* the return value and the read data to be
completely, obsessively correct. But that's really not practical,
hence this RFC patch where we're considering getting rid of the return
value and just making it set the read data to ~0 for all errors.
We might still get there someday, but we don't yet set the read data
to ~0 on all errors, and if/when we do that, we should have some sort
of descriptive macro that we can grep for instead of open-coding "~0"
everywhere.
Bjorn
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 08/17] gpio: Drop uses of pci_read_config_*() return value
@ 2020-08-19 2:21 ` Bjorn Helgaas
0 siblings, 0 replies; 97+ messages in thread
From: Bjorn Helgaas @ 2020-08-19 2:21 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Saheed O. Bolarinwa, Linus Walleij, LKML, linux-gpio, linux-pci,
linux-kernel-mentees
On Tue, Aug 18, 2020 at 09:59:50PM +0200, Bartosz Golaszewski wrote:
> On Sat, Aug 1, 2020 at 2:24 PM Saheed O. Bolarinwa
> <refactormyself@gmail.com> 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.
> >
> > 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/gpio/gpio-amd8111.c | 7 +++++--
> > drivers/gpio/gpio-rdc321x.c | 21 ++++++++++++---------
> > 2 files changed, 17 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c
> > index fdcebe59510d..7b9882380cbc 100644
> > --- a/drivers/gpio/gpio-amd8111.c
> > +++ b/drivers/gpio/gpio-amd8111.c
> > @@ -198,9 +198,12 @@ static int __init amd_gpio_init(void)
> > goto out;
> >
> > found:
> > - err = pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> > - if (err)
> > + pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> > + if (gp.pmbase == (u32)~0) {
> > + err = -ENODEV;
> > goto out;
> > + }
> > +
> > err = -EIO;
> > gp.pmbase &= 0x0000FF00;
> > if (gp.pmbase == 0)
> > diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c
> > index 01ed2517e9fd..03f1ff07b844 100644
> > --- a/drivers/gpio/gpio-rdc321x.c
> > +++ b/drivers/gpio/gpio-rdc321x.c
> > @@ -85,10 +85,13 @@ static int rdc_gpio_config(struct gpio_chip *chip,
> > gpch = gpiochip_get_data(chip);
> >
> > spin_lock(&gpch->lock);
> > - err = pci_read_config_dword(gpch->sb_pdev, gpio < 32 ?
> > - gpch->reg1_ctrl_base : gpch->reg2_ctrl_base, ®);
> > - if (err)
> > + pci_read_config_dword(gpch->sb_pdev,
> > + (gpio < 32) ? gpch->reg1_ctrl_base
> > + : gpch->reg2_ctrl_base, ®);
> > + if (reg == (u32)~0) {
> > + err = -ENODEV;
> > goto unlock;
> > + }
> >
> > reg |= 1 << (gpio & 0x1f);
> >
> > @@ -166,17 +169,17 @@ static int rdc321x_gpio_probe(struct platform_device *pdev)
> > /* This might not be, what others (BIOS, bootloader, etc.)
> > wrote to these registers before, but it's a good guess. Still
> > better than just using 0xffffffff. */
> > - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > rdc321x_gpio_dev->reg1_data_base,
> > &rdc321x_gpio_dev->data_reg[0]);
> > - if (err)
> > - return err;
> > + if (rdc321x_gpio_dev->data_reg[0] == (u32)~0)
> > + return -ENODEV;
> >
> > - err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > + pci_read_config_dword(rdc321x_gpio_dev->sb_pdev,
> > rdc321x_gpio_dev->reg2_data_base,
> > &rdc321x_gpio_dev->data_reg[1]);
> > - if (err)
> > - return err;
> > + if (rdc321x_gpio_dev->data_reg[1] == (u32)~0)
> > + return -ENODEV;
> >
> > dev_info(&pdev->dev, "registering %d GPIOs\n",
> > rdc321x_gpio_dev->chip.ngpio);
> > --
> > 2.18.4
> >
>
> Bjorn,
>
> I don't know the pci sub-system at all. Does this look good to you?
I wouldn't apply this at this point. It's definitely true that when
pci_read_config_dword() returns an error, it's likely an alignment
problem or some other programming error, not an actual PCI error.
If an actual PCI error occurs (device failed to respond, transaction
failed because of noise or electrical issue, etc),
pci_read_config_dword() will *not* return an error; the data it reads,
e.g., rdc321x_gpio_dev->data_reg[1], will be ~0.
So with the current pci_read_config_dword() implementation, we really
need to test *both* the return value and the read data to be
completely, obsessively correct. But that's really not practical,
hence this RFC patch where we're considering getting rid of the return
value and just making it set the read data to ~0 for all errors.
We might still get there someday, but we don't yet set the read data
to ~0 on all errors, and if/when we do that, we should have some sort
of descriptive macro that we can grep for instead of open-coding "~0"
everywhere.
Bjorn
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 09/17] drm/i915/vga: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
(?)
(?)
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, David Airlie, Daniel Vetter
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, dri-devel, intel-gfx
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/gpu/drm/i915/display/intel_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c
index be333699c515..6f9406699c9d 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -99,7 +99,8 @@ intel_vga_set_state(struct drm_i915_private *i915, bool enable_decode)
unsigned int reg = INTEL_GEN(i915) >= 6 ? SNB_GMCH_CTRL : INTEL_GMCH_CTRL;
u16 gmch_ctrl;
- if (pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl)) {
+ pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl);
+ if (gmch_ctrl == (u16)~0) {
drm_err(&i915->drm, "failed to read control word\n");
return -EIO;
}
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Intel-gfx] [RFC PATCH 09/17] drm/i915/vga: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, David Airlie, Daniel Vetter
Cc: Saheed O. Bolarinwa, intel-gfx, skhan, linux-kernel, dri-devel,
linux-pci, bjorn, linux-kernel-mentees
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/gpu/drm/i915/display/intel_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c
index be333699c515..6f9406699c9d 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -99,7 +99,8 @@ intel_vga_set_state(struct drm_i915_private *i915, bool enable_decode)
unsigned int reg = INTEL_GEN(i915) >= 6 ? SNB_GMCH_CTRL : INTEL_GMCH_CTRL;
u16 gmch_ctrl;
- if (pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl)) {
+ pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl);
+ if (gmch_ctrl == (u16)~0) {
drm_err(&i915->drm, "failed to read control word\n");
return -EIO;
}
--
2.18.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 09/17] drm/i915/vga: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, David Airlie, Daniel Vetter
Cc: Saheed O. Bolarinwa, intel-gfx, skhan, linux-kernel,
Rodrigo Vivi, dri-devel, linux-pci, bjorn, linux-kernel-mentees
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/gpu/drm/i915/display/intel_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c
index be333699c515..6f9406699c9d 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -99,7 +99,8 @@ intel_vga_set_state(struct drm_i915_private *i915, bool enable_decode)
unsigned int reg = INTEL_GEN(i915) >= 6 ? SNB_GMCH_CTRL : INTEL_GMCH_CTRL;
u16 gmch_ctrl;
- if (pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl)) {
+ pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl);
+ if (gmch_ctrl == (u16)~0) {
drm_err(&i915->drm, "failed to read control word\n");
return -EIO;
}
--
2.18.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 09/17] drm/i915/vga: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, David Airlie, Daniel Vetter
Cc: Joonas Lahtinen, Saheed O. Bolarinwa, intel-gfx, linux-kernel,
Jani Nikula, Rodrigo Vivi, dri-devel, linux-pci,
linux-kernel-mentees
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/gpu/drm/i915/display/intel_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c
index be333699c515..6f9406699c9d 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -99,7 +99,8 @@ intel_vga_set_state(struct drm_i915_private *i915, bool enable_decode)
unsigned int reg = INTEL_GEN(i915) >= 6 ? SNB_GMCH_CTRL : INTEL_GMCH_CTRL;
u16 gmch_ctrl;
- if (pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl)) {
+ pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl);
+ if (gmch_ctrl == (u16)~0) {
drm_err(&i915->drm, "failed to read control word\n");
return -EIO;
}
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 10/17] hwmon: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Jean Delvare, Guenter Roeck
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-hwmon
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/hwmon/i5k_amb.c | 12 ++++++++----
drivers/hwmon/vt8231.c | 8 ++++----
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/hwmon/i5k_amb.c b/drivers/hwmon/i5k_amb.c
index eeac4b04df27..b7497510323c 100644
--- a/drivers/hwmon/i5k_amb.c
+++ b/drivers/hwmon/i5k_amb.c
@@ -427,11 +427,13 @@ static int i5k_find_amb_registers(struct i5k_amb_data *data,
if (!pcidev)
return -ENODEV;
- if (pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32))
+ pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32);
+ if (val32 == (u32)~0)
goto out;
data->amb_base = val32;
- if (pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32))
+ pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32);
+ if (val32 == (u32)~0)
goto out;
data->amb_len = val32;
@@ -458,11 +460,13 @@ static int i5k_channel_probe(u16 *amb_present, unsigned long dev_id)
if (!pcidev)
return -ENODEV;
- if (pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16))
+ pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16);
+ if (val16 == (u16)~0)
goto out;
amb_present[0] = val16;
- if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16))
+ pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16);
+ if (val16 == (u16)~0)
goto out;
amb_present[1] = val16;
diff --git a/drivers/hwmon/vt8231.c b/drivers/hwmon/vt8231.c
index 2335d440f72d..6603727e15a0 100644
--- a/drivers/hwmon/vt8231.c
+++ b/drivers/hwmon/vt8231.c
@@ -992,8 +992,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
return -ENODEV;
}
- if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_BASE_REG,
- &val))
+ pci_read_config_word(dev, VT8231_BASE_REG, &val);
+ if (val == (u16)~0)
return -ENODEV;
address = val & ~(VT8231_EXTENT - 1);
@@ -1002,8 +1002,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
return -ENODEV;
}
- if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_ENABLE_REG,
- &val))
+ pci_read_config_word(dev, VT8231_ENABLE_REG, &val);
+ if (val == (u16)~0)
return -ENODEV;
if (!(val & 0x0001)) {
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 10/17] hwmon: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Jean Delvare, Guenter Roeck
Cc: linux-hwmon, Saheed O. Bolarinwa, linux-kernel, linux-pci,
linux-kernel-mentees
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/hwmon/i5k_amb.c | 12 ++++++++----
drivers/hwmon/vt8231.c | 8 ++++----
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/hwmon/i5k_amb.c b/drivers/hwmon/i5k_amb.c
index eeac4b04df27..b7497510323c 100644
--- a/drivers/hwmon/i5k_amb.c
+++ b/drivers/hwmon/i5k_amb.c
@@ -427,11 +427,13 @@ static int i5k_find_amb_registers(struct i5k_amb_data *data,
if (!pcidev)
return -ENODEV;
- if (pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32))
+ pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32);
+ if (val32 == (u32)~0)
goto out;
data->amb_base = val32;
- if (pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32))
+ pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32);
+ if (val32 == (u32)~0)
goto out;
data->amb_len = val32;
@@ -458,11 +460,13 @@ static int i5k_channel_probe(u16 *amb_present, unsigned long dev_id)
if (!pcidev)
return -ENODEV;
- if (pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16))
+ pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16);
+ if (val16 == (u16)~0)
goto out;
amb_present[0] = val16;
- if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16))
+ pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16);
+ if (val16 == (u16)~0)
goto out;
amb_present[1] = val16;
diff --git a/drivers/hwmon/vt8231.c b/drivers/hwmon/vt8231.c
index 2335d440f72d..6603727e15a0 100644
--- a/drivers/hwmon/vt8231.c
+++ b/drivers/hwmon/vt8231.c
@@ -992,8 +992,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
return -ENODEV;
}
- if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_BASE_REG,
- &val))
+ pci_read_config_word(dev, VT8231_BASE_REG, &val);
+ if (val == (u16)~0)
return -ENODEV;
address = val & ~(VT8231_EXTENT - 1);
@@ -1002,8 +1002,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
return -ENODEV;
}
- if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_ENABLE_REG,
- &val))
+ pci_read_config_word(dev, VT8231_ENABLE_REG, &val);
+ if (val == (u16)~0)
return -ENODEV;
if (!(val & 0x0001)) {
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 10/17] hwmon: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
@ 2020-08-04 21:26 ` Guenter Roeck
-1 siblings, 0 replies; 97+ messages in thread
From: Guenter Roeck @ 2020-08-04 21:26 UTC (permalink / raw)
To: Saheed O. Bolarinwa
Cc: helgaas, Jean Delvare, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-hwmon
On Sat, Aug 01, 2020 at 01:24:39PM +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.
>
> 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>
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/i5k_amb.c | 12 ++++++++----
> drivers/hwmon/vt8231.c | 8 ++++----
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwmon/i5k_amb.c b/drivers/hwmon/i5k_amb.c
> index eeac4b04df27..b7497510323c 100644
> --- a/drivers/hwmon/i5k_amb.c
> +++ b/drivers/hwmon/i5k_amb.c
> @@ -427,11 +427,13 @@ static int i5k_find_amb_registers(struct i5k_amb_data *data,
> if (!pcidev)
> return -ENODEV;
>
> - if (pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32))
> + pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32);
> + if (val32 == (u32)~0)
> goto out;
> data->amb_base = val32;
>
> - if (pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32))
> + pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32);
> + if (val32 == (u32)~0)
> goto out;
> data->amb_len = val32;
>
> @@ -458,11 +460,13 @@ static int i5k_channel_probe(u16 *amb_present, unsigned long dev_id)
> if (!pcidev)
> return -ENODEV;
>
> - if (pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16))
> + pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16);
> + if (val16 == (u16)~0)
> goto out;
> amb_present[0] = val16;
>
> - if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16))
> + pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16);
> + if (val16 == (u16)~0)
> goto out;
> amb_present[1] = val16;
>
> diff --git a/drivers/hwmon/vt8231.c b/drivers/hwmon/vt8231.c
> index 2335d440f72d..6603727e15a0 100644
> --- a/drivers/hwmon/vt8231.c
> +++ b/drivers/hwmon/vt8231.c
> @@ -992,8 +992,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
> return -ENODEV;
> }
>
> - if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_BASE_REG,
> - &val))
> + pci_read_config_word(dev, VT8231_BASE_REG, &val);
> + if (val == (u16)~0)
> return -ENODEV;
>
> address = val & ~(VT8231_EXTENT - 1);
> @@ -1002,8 +1002,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
> return -ENODEV;
> }
>
> - if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_ENABLE_REG,
> - &val))
> + pci_read_config_word(dev, VT8231_ENABLE_REG, &val);
> + if (val == (u16)~0)
> return -ENODEV;
>
> if (!(val & 0x0001)) {
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 10/17] hwmon: Drop uses of pci_read_config_*() return value
@ 2020-08-04 21:26 ` Guenter Roeck
0 siblings, 0 replies; 97+ messages in thread
From: Guenter Roeck @ 2020-08-04 21:26 UTC (permalink / raw)
To: Saheed O. Bolarinwa
Cc: linux-hwmon, Jean Delvare, linux-pci, linux-kernel, helgaas,
linux-kernel-mentees
On Sat, Aug 01, 2020 at 01:24:39PM +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.
>
> 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>
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/i5k_amb.c | 12 ++++++++----
> drivers/hwmon/vt8231.c | 8 ++++----
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwmon/i5k_amb.c b/drivers/hwmon/i5k_amb.c
> index eeac4b04df27..b7497510323c 100644
> --- a/drivers/hwmon/i5k_amb.c
> +++ b/drivers/hwmon/i5k_amb.c
> @@ -427,11 +427,13 @@ static int i5k_find_amb_registers(struct i5k_amb_data *data,
> if (!pcidev)
> return -ENODEV;
>
> - if (pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32))
> + pci_read_config_dword(pcidev, I5K_REG_AMB_BASE_ADDR, &val32);
> + if (val32 == (u32)~0)
> goto out;
> data->amb_base = val32;
>
> - if (pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32))
> + pci_read_config_dword(pcidev, I5K_REG_AMB_LEN_ADDR, &val32);
> + if (val32 == (u32)~0)
> goto out;
> data->amb_len = val32;
>
> @@ -458,11 +460,13 @@ static int i5k_channel_probe(u16 *amb_present, unsigned long dev_id)
> if (!pcidev)
> return -ENODEV;
>
> - if (pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16))
> + pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, &val16);
> + if (val16 == (u16)~0)
> goto out;
> amb_present[0] = val16;
>
> - if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16))
> + pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16);
> + if (val16 == (u16)~0)
> goto out;
> amb_present[1] = val16;
>
> diff --git a/drivers/hwmon/vt8231.c b/drivers/hwmon/vt8231.c
> index 2335d440f72d..6603727e15a0 100644
> --- a/drivers/hwmon/vt8231.c
> +++ b/drivers/hwmon/vt8231.c
> @@ -992,8 +992,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
> return -ENODEV;
> }
>
> - if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_BASE_REG,
> - &val))
> + pci_read_config_word(dev, VT8231_BASE_REG, &val);
> + if (val == (u16)~0)
> return -ENODEV;
>
> address = val & ~(VT8231_EXTENT - 1);
> @@ -1002,8 +1002,8 @@ static int vt8231_pci_probe(struct pci_dev *dev,
> return -ENODEV;
> }
>
> - if (PCIBIOS_SUCCESSFUL != pci_read_config_word(dev, VT8231_ENABLE_REG,
> - &val))
> + pci_read_config_word(dev, VT8231_ENABLE_REG, &val);
> + if (val == (u16)~0)
> return -ENODEV;
>
> if (!(val & 0x0001)) {
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 11/17] intel_th: pci: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Alexander Shishkin
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel
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/hwtracing/intel_th/pci.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hwtracing/intel_th/pci.c b/drivers/hwtracing/intel_th/pci.c
index 21fdf0b93516..176c9088038e 100644
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -32,13 +32,13 @@ static int intel_th_pci_activate(struct intel_th *th)
{
struct pci_dev *pdev = to_pci_dev(th->dev);
u32 npkdsc;
- int err;
+ int err = -ENODEV;
if (!INTEL_TH_CAP(th, tscu_enable))
return 0;
- err = pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
- if (!err) {
+ pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
+ if (npkdsc != (u32)~0) {
npkdsc |= NPKDSC_TSACT;
err = pci_write_config_dword(pdev, PCI_REG_NPKDSC, npkdsc);
}
@@ -53,13 +53,13 @@ static void intel_th_pci_deactivate(struct intel_th *th)
{
struct pci_dev *pdev = to_pci_dev(th->dev);
u32 npkdsc;
- int err;
+ int err = -ENODEV;
if (!INTEL_TH_CAP(th, tscu_enable))
return;
- err = pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
- if (!err) {
+ pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
+ if (npkdsc != (u32)~0) {
npkdsc |= NPKDSC_TSACT;
err = pci_write_config_dword(pdev, PCI_REG_NPKDSC, npkdsc);
}
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 11/17] intel_th: pci: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Alexander Shishkin
Cc: Saheed O. Bolarinwa, linux-kernel, linux-pci, linux-kernel-mentees
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/hwtracing/intel_th/pci.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hwtracing/intel_th/pci.c b/drivers/hwtracing/intel_th/pci.c
index 21fdf0b93516..176c9088038e 100644
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -32,13 +32,13 @@ static int intel_th_pci_activate(struct intel_th *th)
{
struct pci_dev *pdev = to_pci_dev(th->dev);
u32 npkdsc;
- int err;
+ int err = -ENODEV;
if (!INTEL_TH_CAP(th, tscu_enable))
return 0;
- err = pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
- if (!err) {
+ pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
+ if (npkdsc != (u32)~0) {
npkdsc |= NPKDSC_TSACT;
err = pci_write_config_dword(pdev, PCI_REG_NPKDSC, npkdsc);
}
@@ -53,13 +53,13 @@ static void intel_th_pci_deactivate(struct intel_th *th)
{
struct pci_dev *pdev = to_pci_dev(th->dev);
u32 npkdsc;
- int err;
+ int err = -ENODEV;
if (!INTEL_TH_CAP(th, tscu_enable))
return;
- err = pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
- if (!err) {
+ pci_read_config_dword(pdev, PCI_REG_NPKDSC, &npkdsc);
+ if (npkdsc != (u32)~0) {
npkdsc |= NPKDSC_TSACT;
err = pci_write_config_dword(pdev, PCI_REG_NPKDSC, npkdsc);
}
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 12/17] i2c: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Wolfram Sang
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-i2c
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/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 ++++++-----
6 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
index 02185a1cfa77..fa103131746d 100644
--- a/drivers/i2c/busses/i2c-ali15x3.c
+++ b/drivers/i2c/busses/i2c-ali15x3.c
@@ -171,9 +171,11 @@ static int ali15x3_setup(struct pci_dev *ALI15X3_dev)
SMBBA,
ali15x3_smba))
goto error;
- if (PCIBIOS_SUCCESSFUL != pci_read_config_word(ALI15X3_dev,
- SMBBA, &a))
+
+ pci_read_config_word(ALI15X3_dev, SMBBA, &a);
+ if (a == (u16)~0)
goto error;
+
if ((a & ~(ALI15X3_SMB_IOSIZE - 1)) != ali15x3_smba) {
/* make sure it works */
dev_err(&ALI15X3_dev->dev,
diff --git a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
index 140426db28df..82c8d6d55561 100644
--- a/drivers/i2c/busses/i2c-elektor.c
+++ b/drivers/i2c/busses/i2c-elektor.c
@@ -207,7 +207,8 @@ static int elektor_match(struct device *dev, unsigned int id)
if (cy693_dev) {
unsigned char config;
/* yeap, we've found cypress, let's check config */
- if (!pci_read_config_byte(cy693_dev, 0x47, &config)) {
+ pci_read_config_byte(cy693_dev, 0x47, &config);
+ if (config != (u8)~0) {
dev_dbg(dev, "found cy82c693, config "
"register 0x47 = 0x%02x\n", config);
diff --git a/drivers/i2c/busses/i2c-nforce2.c b/drivers/i2c/busses/i2c-nforce2.c
index 777278386f58..dc5d032c5a1d 100644
--- a/drivers/i2c/busses/i2c-nforce2.c
+++ b/drivers/i2c/busses/i2c-nforce2.c
@@ -327,8 +327,8 @@ static int nforce2_probe_smb(struct pci_dev *dev, int bar, int alt_reg,
/* Older incarnations of the device used non-standard BARs */
u16 iobase;
- if (pci_read_config_word(dev, alt_reg, &iobase)
- != PCIBIOS_SUCCESSFUL) {
+ pci_read_config_word(dev, alt_reg, &iobase);
+ if (iobase == (u16)~0) {
dev_err(&dev->dev, "Error reading PCI config for %s\n",
name);
return -EIO;
diff --git a/drivers/i2c/busses/i2c-sis5595.c b/drivers/i2c/busses/i2c-sis5595.c
index c793a5c14cda..9b3fbde9cd9c 100644
--- a/drivers/i2c/busses/i2c-sis5595.c
+++ b/drivers/i2c/busses/i2c-sis5595.c
@@ -178,9 +178,11 @@ static int sis5595_setup(struct pci_dev *SIS5595_dev)
if (pci_write_config_word(SIS5595_dev, ACPI_BASE, sis5595_base)
!= PCIBIOS_SUCCESSFUL)
goto error;
- if (pci_read_config_word(SIS5595_dev, ACPI_BASE, &a)
- != PCIBIOS_SUCCESSFUL)
+
+ pci_read_config_word(SIS5595_dev, ACPI_BASE, &a);
+ if (a == (u16)~0)
goto error;
+
if ((a & ~(SIS5595_EXTENT - 1)) != sis5595_base) {
/* doesn't work for some chips! */
dev_err(&SIS5595_dev->dev, "force address failed - not supported?\n");
@@ -188,17 +190,20 @@ static int sis5595_setup(struct pci_dev *SIS5595_dev)
}
}
- if (pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val)
- != PCIBIOS_SUCCESSFUL)
+ pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val);
+ if (val == (u8)~0)
goto error;
+
if ((val & 0x80) == 0) {
dev_info(&SIS5595_dev->dev, "enabling ACPI\n");
if (pci_write_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, val | 0x80)
!= PCIBIOS_SUCCESSFUL)
goto error;
- if (pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val)
- != PCIBIOS_SUCCESSFUL)
+
+ pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val);
+ if (val == (u8)~0)
goto error;
+
if ((val & 0x80) == 0) {
/* doesn't work for some chips? */
dev_err(&SIS5595_dev->dev, "ACPI enable failed - not supported?\n");
diff --git a/drivers/i2c/busses/i2c-sis630.c b/drivers/i2c/busses/i2c-sis630.c
index cfb8e04a2a83..73b17436f964 100644
--- a/drivers/i2c/busses/i2c-sis630.c
+++ b/drivers/i2c/busses/i2c-sis630.c
@@ -430,7 +430,8 @@ static int sis630_setup(struct pci_dev *sis630_dev)
Enable ACPI first , so we can accsess reg 74-75
in acpi io space and read acpi base addr
*/
- if (pci_read_config_byte(sis630_dev, SIS630_BIOS_CTL_REG, &b)) {
+ pci_read_config_byte(sis630_dev, SIS630_BIOS_CTL_REG, &b);
+ if (b == (u8)~0) {
dev_err(&sis630_dev->dev, "Error: Can't read bios ctl reg\n");
retval = -ENODEV;
goto exit;
@@ -444,8 +445,8 @@ static int sis630_setup(struct pci_dev *sis630_dev)
}
/* Determine the ACPI base address */
- if (pci_read_config_word(sis630_dev,
- SIS630_ACPI_BASE_REG, &acpi_base)) {
+ pci_read_config_word(sis630_dev, SIS630_ACPI_BASE_REG, &acpi_base);
+ if (acpi_base == (u16)~0) {
dev_err(&sis630_dev->dev,
"Error: Can't determine ACPI base address\n");
retval = -ENODEV;
diff --git a/drivers/i2c/busses/i2c-viapro.c b/drivers/i2c/busses/i2c-viapro.c
index 4abc7771af06..14bfa5401845 100644
--- a/drivers/i2c/busses/i2c-viapro.c
+++ b/drivers/i2c/busses/i2c-viapro.c
@@ -321,12 +321,13 @@ static int vt596_probe(struct pci_dev *pdev,
goto found;
}
- if ((pci_read_config_word(pdev, id->driver_data, &vt596_smba)) ||
- !(vt596_smba & 0x0001)) {
+ pci_read_config_word(pdev, id->driver_data, &vt596_smba);
+ if ((vt596_smba == (u16)~0) || !(vt596_smba & 0x0001)) {
/* try 2nd address and config reg. for 596 */
- if (id->device == PCI_DEVICE_ID_VIA_82C596_3 &&
- !pci_read_config_word(pdev, SMBBA2, &vt596_smba) &&
- (vt596_smba & 0x0001)) {
+ pci_read_config_word(pdev, SMBBA2, &vt596_smba);
+ if ((id->device == PCI_DEVICE_ID_VIA_82C596_3) &&
+ (vt596_smba != (u16)~0) &&
+ (vt596_smba & 0x0001)) {
SMBHSTCFG = 0x84;
} else {
/* no matches at all */
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 12/17] i2c: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Wolfram Sang
Cc: Saheed O. Bolarinwa, linux-kernel, linux-i2c, linux-pci,
linux-kernel-mentees
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/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 ++++++-----
6 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
index 02185a1cfa77..fa103131746d 100644
--- a/drivers/i2c/busses/i2c-ali15x3.c
+++ b/drivers/i2c/busses/i2c-ali15x3.c
@@ -171,9 +171,11 @@ static int ali15x3_setup(struct pci_dev *ALI15X3_dev)
SMBBA,
ali15x3_smba))
goto error;
- if (PCIBIOS_SUCCESSFUL != pci_read_config_word(ALI15X3_dev,
- SMBBA, &a))
+
+ pci_read_config_word(ALI15X3_dev, SMBBA, &a);
+ if (a == (u16)~0)
goto error;
+
if ((a & ~(ALI15X3_SMB_IOSIZE - 1)) != ali15x3_smba) {
/* make sure it works */
dev_err(&ALI15X3_dev->dev,
diff --git a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
index 140426db28df..82c8d6d55561 100644
--- a/drivers/i2c/busses/i2c-elektor.c
+++ b/drivers/i2c/busses/i2c-elektor.c
@@ -207,7 +207,8 @@ static int elektor_match(struct device *dev, unsigned int id)
if (cy693_dev) {
unsigned char config;
/* yeap, we've found cypress, let's check config */
- if (!pci_read_config_byte(cy693_dev, 0x47, &config)) {
+ pci_read_config_byte(cy693_dev, 0x47, &config);
+ if (config != (u8)~0) {
dev_dbg(dev, "found cy82c693, config "
"register 0x47 = 0x%02x\n", config);
diff --git a/drivers/i2c/busses/i2c-nforce2.c b/drivers/i2c/busses/i2c-nforce2.c
index 777278386f58..dc5d032c5a1d 100644
--- a/drivers/i2c/busses/i2c-nforce2.c
+++ b/drivers/i2c/busses/i2c-nforce2.c
@@ -327,8 +327,8 @@ static int nforce2_probe_smb(struct pci_dev *dev, int bar, int alt_reg,
/* Older incarnations of the device used non-standard BARs */
u16 iobase;
- if (pci_read_config_word(dev, alt_reg, &iobase)
- != PCIBIOS_SUCCESSFUL) {
+ pci_read_config_word(dev, alt_reg, &iobase);
+ if (iobase == (u16)~0) {
dev_err(&dev->dev, "Error reading PCI config for %s\n",
name);
return -EIO;
diff --git a/drivers/i2c/busses/i2c-sis5595.c b/drivers/i2c/busses/i2c-sis5595.c
index c793a5c14cda..9b3fbde9cd9c 100644
--- a/drivers/i2c/busses/i2c-sis5595.c
+++ b/drivers/i2c/busses/i2c-sis5595.c
@@ -178,9 +178,11 @@ static int sis5595_setup(struct pci_dev *SIS5595_dev)
if (pci_write_config_word(SIS5595_dev, ACPI_BASE, sis5595_base)
!= PCIBIOS_SUCCESSFUL)
goto error;
- if (pci_read_config_word(SIS5595_dev, ACPI_BASE, &a)
- != PCIBIOS_SUCCESSFUL)
+
+ pci_read_config_word(SIS5595_dev, ACPI_BASE, &a);
+ if (a == (u16)~0)
goto error;
+
if ((a & ~(SIS5595_EXTENT - 1)) != sis5595_base) {
/* doesn't work for some chips! */
dev_err(&SIS5595_dev->dev, "force address failed - not supported?\n");
@@ -188,17 +190,20 @@ static int sis5595_setup(struct pci_dev *SIS5595_dev)
}
}
- if (pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val)
- != PCIBIOS_SUCCESSFUL)
+ pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val);
+ if (val == (u8)~0)
goto error;
+
if ((val & 0x80) == 0) {
dev_info(&SIS5595_dev->dev, "enabling ACPI\n");
if (pci_write_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, val | 0x80)
!= PCIBIOS_SUCCESSFUL)
goto error;
- if (pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val)
- != PCIBIOS_SUCCESSFUL)
+
+ pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, &val);
+ if (val == (u8)~0)
goto error;
+
if ((val & 0x80) == 0) {
/* doesn't work for some chips? */
dev_err(&SIS5595_dev->dev, "ACPI enable failed - not supported?\n");
diff --git a/drivers/i2c/busses/i2c-sis630.c b/drivers/i2c/busses/i2c-sis630.c
index cfb8e04a2a83..73b17436f964 100644
--- a/drivers/i2c/busses/i2c-sis630.c
+++ b/drivers/i2c/busses/i2c-sis630.c
@@ -430,7 +430,8 @@ static int sis630_setup(struct pci_dev *sis630_dev)
Enable ACPI first , so we can accsess reg 74-75
in acpi io space and read acpi base addr
*/
- if (pci_read_config_byte(sis630_dev, SIS630_BIOS_CTL_REG, &b)) {
+ pci_read_config_byte(sis630_dev, SIS630_BIOS_CTL_REG, &b);
+ if (b == (u8)~0) {
dev_err(&sis630_dev->dev, "Error: Can't read bios ctl reg\n");
retval = -ENODEV;
goto exit;
@@ -444,8 +445,8 @@ static int sis630_setup(struct pci_dev *sis630_dev)
}
/* Determine the ACPI base address */
- if (pci_read_config_word(sis630_dev,
- SIS630_ACPI_BASE_REG, &acpi_base)) {
+ pci_read_config_word(sis630_dev, SIS630_ACPI_BASE_REG, &acpi_base);
+ if (acpi_base == (u16)~0) {
dev_err(&sis630_dev->dev,
"Error: Can't determine ACPI base address\n");
retval = -ENODEV;
diff --git a/drivers/i2c/busses/i2c-viapro.c b/drivers/i2c/busses/i2c-viapro.c
index 4abc7771af06..14bfa5401845 100644
--- a/drivers/i2c/busses/i2c-viapro.c
+++ b/drivers/i2c/busses/i2c-viapro.c
@@ -321,12 +321,13 @@ static int vt596_probe(struct pci_dev *pdev,
goto found;
}
- if ((pci_read_config_word(pdev, id->driver_data, &vt596_smba)) ||
- !(vt596_smba & 0x0001)) {
+ pci_read_config_word(pdev, id->driver_data, &vt596_smba);
+ if ((vt596_smba == (u16)~0) || !(vt596_smba & 0x0001)) {
/* try 2nd address and config reg. for 596 */
- if (id->device == PCI_DEVICE_ID_VIA_82C596_3 &&
- !pci_read_config_word(pdev, SMBBA2, &vt596_smba) &&
- (vt596_smba & 0x0001)) {
+ pci_read_config_word(pdev, SMBBA2, &vt596_smba);
+ if ((id->device == PCI_DEVICE_ID_VIA_82C596_3) &&
+ (vt596_smba != (u16)~0) &&
+ (vt596_smba & 0x0001)) {
SMBHSTCFG = 0x84;
} else {
/* no matches at all */
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 13/17] ide: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, David S. Miller
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-ide
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.
drivers/ide/cs5536.c cs5536_read() :
None of the callers of cs5536_read() uses the return value. The obtained
value can be checked for validity to confirm success.
Change the return type of cs5536_read() to void.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com>
---
drivers/ide/cs5536.c | 6 +++---
drivers/ide/rz1000.c | 3 ++-
drivers/ide/setup-pci.c | 26 ++++++++++++++++----------
3 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/ide/cs5536.c b/drivers/ide/cs5536.c
index 8b5ca145191b..58d1cf37c013 100644
--- a/drivers/ide/cs5536.c
+++ b/drivers/ide/cs5536.c
@@ -55,16 +55,16 @@ enum {
static int use_msr;
-static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
+static void cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
{
if (unlikely(use_msr)) {
u32 dummy;
rdmsr(MSR_IDE_CFG + reg, *val, dummy);
- return 0;
+ return;
}
- return pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
+ pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
}
static int cs5536_write(struct pci_dev *pdev, int reg, int val)
diff --git a/drivers/ide/rz1000.c b/drivers/ide/rz1000.c
index fce2b7de5a19..19ac4328e707 100644
--- a/drivers/ide/rz1000.c
+++ b/drivers/ide/rz1000.c
@@ -27,7 +27,8 @@ static int rz1000_disable_readahead(struct pci_dev *dev)
{
u16 reg;
- if (!pci_read_config_word (dev, 0x40, ®) &&
+ pci_read_config_word(dev, 0x40, ®);
+ if ((reg != (u16)~0) &&
!pci_write_config_word(dev, 0x40, reg & 0xdfff)) {
printk(KERN_INFO "%s: disabled chipset read-ahead "
"(buggy RZ1000/RZ1001)\n", pci_name(dev));
diff --git a/drivers/ide/setup-pci.c b/drivers/ide/setup-pci.c
index fdc8e813170c..a7b93ccd55d1 100644
--- a/drivers/ide/setup-pci.c
+++ b/drivers/ide/setup-pci.c
@@ -37,7 +37,8 @@ static int ide_setup_pci_baseregs(struct pci_dev *dev, const char *name)
/*
* Place both IDE interfaces into PCI "native" mode:
*/
- if (pci_read_config_byte(dev, PCI_CLASS_PROG, &progif) ||
+ pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
+ if ((progif == (u8)~0) ||
(progif & 5) != 5) {
if ((progif & 0xa) != 0xa) {
printk(KERN_INFO "%s %s: device not capable of full "
@@ -47,7 +48,8 @@ static int ide_setup_pci_baseregs(struct pci_dev *dev, const char *name)
printk(KERN_INFO "%s %s: placing both ports into native PCI "
"mode\n", name, pci_name(dev));
(void) pci_write_config_byte(dev, PCI_CLASS_PROG, progif|5);
- if (pci_read_config_byte(dev, PCI_CLASS_PROG, &progif) ||
+ pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
+ if ((progif == (u8)~0) ||
(progif & 5) != 5) {
printk(KERN_ERR "%s %s: rewrite of PROGIF failed, "
"wanted 0x%04x, got 0x%04x\n",
@@ -251,7 +253,8 @@ static int ide_pci_configure(struct pci_dev *dev, const struct ide_port_info *d)
d->name, pci_name(dev));
return -ENODEV;
}
- if (pci_read_config_word(dev, PCI_COMMAND, &pcicmd)) {
+ pci_read_config_word(dev, PCI_COMMAND, &pcicmd);
+ if (pcicmd == (u16)~0) {
printk(KERN_ERR "%s %s: error accessing PCI regs\n",
d->name, pci_name(dev));
return -EIO;
@@ -415,8 +418,8 @@ static int ide_setup_pci_controller(struct pci_dev *dev, int bars,
if (ret < 0)
goto out;
- ret = pci_read_config_word(dev, PCI_COMMAND, &pcicmd);
- if (ret < 0) {
+ pci_read_config_word(dev, PCI_COMMAND, &pcicmd);
+ if (pcicmd == (u16)~0) {
printk(KERN_ERR "%s %s: error accessing PCI regs\n",
d->name, pci_name(dev));
goto out_free_bars;
@@ -466,11 +469,14 @@ void ide_pci_setup_ports(struct pci_dev *dev, const struct ide_port_info *d,
for (port = 0; port < channels; ++port) {
const struct ide_pci_enablebit *e = &d->enablebits[port];
- if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) ||
- (tmp & e->mask) != e->val)) {
- printk(KERN_INFO "%s %s: IDE port disabled\n",
- d->name, pci_name(dev));
- continue; /* port not enabled */
+ if (e->reg) {
+ pci_read_config_byte(dev, e->reg, &tmp);
+
+ if ((tmp == (u8)~0) || ((tmp & e->mask) != e->val)) {
+ printk(KERN_INFO "%s %s: IDE port disabled\n",
+ d->name, pci_name(dev));
+ continue; /* port not enabled */
+ }
}
if (ide_hw_configure(dev, d, port, hw + port))
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 13/17] ide: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, David S. Miller
Cc: Saheed O. Bolarinwa, linux-kernel, linux-ide, linux-pci,
linux-kernel-mentees
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.
drivers/ide/cs5536.c cs5536_read() :
None of the callers of cs5536_read() uses the return value. The obtained
value can be checked for validity to confirm success.
Change the return type of cs5536_read() to void.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com>
---
drivers/ide/cs5536.c | 6 +++---
drivers/ide/rz1000.c | 3 ++-
drivers/ide/setup-pci.c | 26 ++++++++++++++++----------
3 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/ide/cs5536.c b/drivers/ide/cs5536.c
index 8b5ca145191b..58d1cf37c013 100644
--- a/drivers/ide/cs5536.c
+++ b/drivers/ide/cs5536.c
@@ -55,16 +55,16 @@ enum {
static int use_msr;
-static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
+static void cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
{
if (unlikely(use_msr)) {
u32 dummy;
rdmsr(MSR_IDE_CFG + reg, *val, dummy);
- return 0;
+ return;
}
- return pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
+ pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
}
static int cs5536_write(struct pci_dev *pdev, int reg, int val)
diff --git a/drivers/ide/rz1000.c b/drivers/ide/rz1000.c
index fce2b7de5a19..19ac4328e707 100644
--- a/drivers/ide/rz1000.c
+++ b/drivers/ide/rz1000.c
@@ -27,7 +27,8 @@ static int rz1000_disable_readahead(struct pci_dev *dev)
{
u16 reg;
- if (!pci_read_config_word (dev, 0x40, ®) &&
+ pci_read_config_word(dev, 0x40, ®);
+ if ((reg != (u16)~0) &&
!pci_write_config_word(dev, 0x40, reg & 0xdfff)) {
printk(KERN_INFO "%s: disabled chipset read-ahead "
"(buggy RZ1000/RZ1001)\n", pci_name(dev));
diff --git a/drivers/ide/setup-pci.c b/drivers/ide/setup-pci.c
index fdc8e813170c..a7b93ccd55d1 100644
--- a/drivers/ide/setup-pci.c
+++ b/drivers/ide/setup-pci.c
@@ -37,7 +37,8 @@ static int ide_setup_pci_baseregs(struct pci_dev *dev, const char *name)
/*
* Place both IDE interfaces into PCI "native" mode:
*/
- if (pci_read_config_byte(dev, PCI_CLASS_PROG, &progif) ||
+ pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
+ if ((progif == (u8)~0) ||
(progif & 5) != 5) {
if ((progif & 0xa) != 0xa) {
printk(KERN_INFO "%s %s: device not capable of full "
@@ -47,7 +48,8 @@ static int ide_setup_pci_baseregs(struct pci_dev *dev, const char *name)
printk(KERN_INFO "%s %s: placing both ports into native PCI "
"mode\n", name, pci_name(dev));
(void) pci_write_config_byte(dev, PCI_CLASS_PROG, progif|5);
- if (pci_read_config_byte(dev, PCI_CLASS_PROG, &progif) ||
+ pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
+ if ((progif == (u8)~0) ||
(progif & 5) != 5) {
printk(KERN_ERR "%s %s: rewrite of PROGIF failed, "
"wanted 0x%04x, got 0x%04x\n",
@@ -251,7 +253,8 @@ static int ide_pci_configure(struct pci_dev *dev, const struct ide_port_info *d)
d->name, pci_name(dev));
return -ENODEV;
}
- if (pci_read_config_word(dev, PCI_COMMAND, &pcicmd)) {
+ pci_read_config_word(dev, PCI_COMMAND, &pcicmd);
+ if (pcicmd == (u16)~0) {
printk(KERN_ERR "%s %s: error accessing PCI regs\n",
d->name, pci_name(dev));
return -EIO;
@@ -415,8 +418,8 @@ static int ide_setup_pci_controller(struct pci_dev *dev, int bars,
if (ret < 0)
goto out;
- ret = pci_read_config_word(dev, PCI_COMMAND, &pcicmd);
- if (ret < 0) {
+ pci_read_config_word(dev, PCI_COMMAND, &pcicmd);
+ if (pcicmd == (u16)~0) {
printk(KERN_ERR "%s %s: error accessing PCI regs\n",
d->name, pci_name(dev));
goto out_free_bars;
@@ -466,11 +469,14 @@ void ide_pci_setup_ports(struct pci_dev *dev, const struct ide_port_info *d,
for (port = 0; port < channels; ++port) {
const struct ide_pci_enablebit *e = &d->enablebits[port];
- if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) ||
- (tmp & e->mask) != e->val)) {
- printk(KERN_INFO "%s %s: IDE port disabled\n",
- d->name, pci_name(dev));
- continue; /* port not enabled */
+ if (e->reg) {
+ pci_read_config_byte(dev, e->reg, &tmp);
+
+ if ((tmp == (u8)~0) || ((tmp & e->mask) != e->val)) {
+ printk(KERN_INFO "%s %s: IDE port disabled\n",
+ d->name, pci_name(dev));
+ continue; /* port not enabled */
+ }
}
if (ide_hw_configure(dev, d, port, hw + port))
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 14/17] IB: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Mike Marciniszyn, Dennis Dalessandro, Doug Ledford,
Jason Gunthorpe
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-rdma
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/infiniband/hw/hfi1/pcie.c | 38 +++++++++++------------
drivers/infiniband/hw/mthca/mthca_reset.c | 19 ++++++------
2 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/pcie.c b/drivers/infiniband/hw/hfi1/pcie.c
index 1a6268d61977..11cf7dde873d 100644
--- a/drivers/infiniband/hw/hfi1/pcie.c
+++ b/drivers/infiniband/hw/hfi1/pcie.c
@@ -392,24 +392,24 @@ int restore_pci_variables(struct hfi1_devdata *dd)
/* Save BARs and command to rewrite after device reset */
int save_pci_variables(struct hfi1_devdata *dd)
{
- int ret = 0;
+ int ret = -ENODEV;
- ret = pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_0,
+ pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_0,
&dd->pcibar0);
- if (ret)
+ if (dd->pcibar0 == (u32)~0)
goto error;
- ret = pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_1,
+ pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_1,
&dd->pcibar1);
- if (ret)
+ if (dd->pcibar1 == (u32)~0)
goto error;
- ret = pci_read_config_dword(dd->pcidev, PCI_ROM_ADDRESS, &dd->pci_rom);
- if (ret)
+ pci_read_config_dword(dd->pcidev, PCI_ROM_ADDRESS, &dd->pci_rom);
+ if (dd->pci_rom == (u32)~0)
goto error;
- ret = pci_read_config_word(dd->pcidev, PCI_COMMAND, &dd->pci_command);
- if (ret)
+ pci_read_config_word(dd->pcidev, PCI_COMMAND, &dd->pci_command);
+ if (dd->pci_command == (u16)~0)
goto error;
ret = pcie_capability_read_word(dd->pcidev, PCI_EXP_DEVCTL,
@@ -427,14 +427,14 @@ int save_pci_variables(struct hfi1_devdata *dd)
if (ret)
goto error;
- ret = pci_read_config_dword(dd->pcidev, PCI_CFG_MSIX0, &dd->pci_msix0);
- if (ret)
+ pci_read_config_dword(dd->pcidev, PCI_CFG_MSIX0, &dd->pci_msix0);
+ if (dd->pci_command == (u32)~0)
goto error;
if (pci_find_ext_capability(dd->pcidev, PCI_EXT_CAP_ID_TPH)) {
- ret = pci_read_config_dword(dd->pcidev, PCIE_CFG_TPH2,
+ pci_read_config_dword(dd->pcidev, PCIE_CFG_TPH2,
&dd->pci_tph2);
- if (ret)
+ if (dd->pci_tph2 == (u32)~0)
goto error;
}
return 0;
@@ -783,9 +783,9 @@ static int load_eq_table(struct hfi1_devdata *dd, const u8 eq[11][3], u8 fs,
pci_write_config_dword(pdev, PCIE_CFG_REG_PL102,
eq_value(c_minus1, c0, c_plus1));
/* check if these coefficients violate EQ rules */
- ret = pci_read_config_dword(dd->pcidev,
+ pci_read_config_dword(dd->pcidev,
PCIE_CFG_REG_PL105, &violation);
- if (ret) {
+ if (violation == (32)~0) {
dd_dev_err(dd, "Unable to read from PCI config\n");
hit_error = 1;
break;
@@ -1322,8 +1322,8 @@ int do_pcie_gen3_transition(struct hfi1_devdata *dd)
/* step 10: decide what to do next */
/* check if we can read PCI space */
- ret = pci_read_config_word(dd->pcidev, PCI_VENDOR_ID, &vendor);
- if (ret) {
+ pci_read_config_word(dd->pcidev, PCI_VENDOR_ID, &vendor);
+ if (vendor == (u16)~0) {
dd_dev_info(dd,
"%s: read of VendorID failed after SBR, err %d\n",
__func__, ret);
@@ -1376,8 +1376,8 @@ int do_pcie_gen3_transition(struct hfi1_devdata *dd)
setextled(dd, 0);
/* check for any per-lane errors */
- ret = pci_read_config_dword(dd->pcidev, PCIE_CFG_SPCIE2, ®32);
- if (ret) {
+ pci_read_config_dword(dd->pcidev, PCIE_CFG_SPCIE2, ®32);
+ if (reg32 == (u32)~0) {
dd_dev_err(dd, "Unable to read from PCI config\n");
return_error = 1;
goto done;
diff --git a/drivers/infiniband/hw/mthca/mthca_reset.c b/drivers/infiniband/hw/mthca/mthca_reset.c
index 2a6979e4ae1c..5f09d5312472 100644
--- a/drivers/infiniband/hw/mthca/mthca_reset.c
+++ b/drivers/infiniband/hw/mthca/mthca_reset.c
@@ -102,7 +102,10 @@ int mthca_reset(struct mthca_dev *mdev)
for (i = 0; i < 64; ++i) {
if (i == 22 || i == 23)
continue;
- if (pci_read_config_dword(mdev->pdev, i * 4, hca_header + i)) {
+
+ pci_read_config_dword(mdev->pdev, i * 4,
+ hca_header + i);
+ if (*(hca_header + i) == (u32)~0) {
err = -ENODEV;
mthca_err(mdev, "Couldn't save HCA "
"PCI header, aborting.\n");
@@ -123,7 +126,10 @@ int mthca_reset(struct mthca_dev *mdev)
for (i = 0; i < 64; ++i) {
if (i == 22 || i == 23)
continue;
- if (pci_read_config_dword(bridge, i * 4, bridge_header + i)) {
+
+ pci_read_config_dword(bridge, i * 4,
+ bridge_header + i);
+ if (*(bridge_header + i) == (u32)~0) {
err = -ENODEV;
mthca_err(mdev, "Couldn't save HCA bridge "
"PCI header, aborting.\n");
@@ -164,13 +170,8 @@ int mthca_reset(struct mthca_dev *mdev)
int c = 0;
for (c = 0; c < 100; ++c) {
- if (pci_read_config_dword(bridge ? bridge : mdev->pdev, 0, &v)) {
- err = -ENODEV;
- mthca_err(mdev, "Couldn't access HCA after reset, "
- "aborting.\n");
- goto free_bh;
- }
-
+ pci_read_config_dword(bridge ? bridge : mdev->pdev, 0,
+ &v);
if (v != 0xffffffff)
goto good;
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 14/17] IB: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Mike Marciniszyn, Dennis Dalessandro, Doug Ledford,
Jason Gunthorpe
Cc: linux-rdma, Saheed O. Bolarinwa, linux-kernel, linux-pci,
linux-kernel-mentees
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/infiniband/hw/hfi1/pcie.c | 38 +++++++++++------------
drivers/infiniband/hw/mthca/mthca_reset.c | 19 ++++++------
2 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/pcie.c b/drivers/infiniband/hw/hfi1/pcie.c
index 1a6268d61977..11cf7dde873d 100644
--- a/drivers/infiniband/hw/hfi1/pcie.c
+++ b/drivers/infiniband/hw/hfi1/pcie.c
@@ -392,24 +392,24 @@ int restore_pci_variables(struct hfi1_devdata *dd)
/* Save BARs and command to rewrite after device reset */
int save_pci_variables(struct hfi1_devdata *dd)
{
- int ret = 0;
+ int ret = -ENODEV;
- ret = pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_0,
+ pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_0,
&dd->pcibar0);
- if (ret)
+ if (dd->pcibar0 == (u32)~0)
goto error;
- ret = pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_1,
+ pci_read_config_dword(dd->pcidev, PCI_BASE_ADDRESS_1,
&dd->pcibar1);
- if (ret)
+ if (dd->pcibar1 == (u32)~0)
goto error;
- ret = pci_read_config_dword(dd->pcidev, PCI_ROM_ADDRESS, &dd->pci_rom);
- if (ret)
+ pci_read_config_dword(dd->pcidev, PCI_ROM_ADDRESS, &dd->pci_rom);
+ if (dd->pci_rom == (u32)~0)
goto error;
- ret = pci_read_config_word(dd->pcidev, PCI_COMMAND, &dd->pci_command);
- if (ret)
+ pci_read_config_word(dd->pcidev, PCI_COMMAND, &dd->pci_command);
+ if (dd->pci_command == (u16)~0)
goto error;
ret = pcie_capability_read_word(dd->pcidev, PCI_EXP_DEVCTL,
@@ -427,14 +427,14 @@ int save_pci_variables(struct hfi1_devdata *dd)
if (ret)
goto error;
- ret = pci_read_config_dword(dd->pcidev, PCI_CFG_MSIX0, &dd->pci_msix0);
- if (ret)
+ pci_read_config_dword(dd->pcidev, PCI_CFG_MSIX0, &dd->pci_msix0);
+ if (dd->pci_command == (u32)~0)
goto error;
if (pci_find_ext_capability(dd->pcidev, PCI_EXT_CAP_ID_TPH)) {
- ret = pci_read_config_dword(dd->pcidev, PCIE_CFG_TPH2,
+ pci_read_config_dword(dd->pcidev, PCIE_CFG_TPH2,
&dd->pci_tph2);
- if (ret)
+ if (dd->pci_tph2 == (u32)~0)
goto error;
}
return 0;
@@ -783,9 +783,9 @@ static int load_eq_table(struct hfi1_devdata *dd, const u8 eq[11][3], u8 fs,
pci_write_config_dword(pdev, PCIE_CFG_REG_PL102,
eq_value(c_minus1, c0, c_plus1));
/* check if these coefficients violate EQ rules */
- ret = pci_read_config_dword(dd->pcidev,
+ pci_read_config_dword(dd->pcidev,
PCIE_CFG_REG_PL105, &violation);
- if (ret) {
+ if (violation == (32)~0) {
dd_dev_err(dd, "Unable to read from PCI config\n");
hit_error = 1;
break;
@@ -1322,8 +1322,8 @@ int do_pcie_gen3_transition(struct hfi1_devdata *dd)
/* step 10: decide what to do next */
/* check if we can read PCI space */
- ret = pci_read_config_word(dd->pcidev, PCI_VENDOR_ID, &vendor);
- if (ret) {
+ pci_read_config_word(dd->pcidev, PCI_VENDOR_ID, &vendor);
+ if (vendor == (u16)~0) {
dd_dev_info(dd,
"%s: read of VendorID failed after SBR, err %d\n",
__func__, ret);
@@ -1376,8 +1376,8 @@ int do_pcie_gen3_transition(struct hfi1_devdata *dd)
setextled(dd, 0);
/* check for any per-lane errors */
- ret = pci_read_config_dword(dd->pcidev, PCIE_CFG_SPCIE2, ®32);
- if (ret) {
+ pci_read_config_dword(dd->pcidev, PCIE_CFG_SPCIE2, ®32);
+ if (reg32 == (u32)~0) {
dd_dev_err(dd, "Unable to read from PCI config\n");
return_error = 1;
goto done;
diff --git a/drivers/infiniband/hw/mthca/mthca_reset.c b/drivers/infiniband/hw/mthca/mthca_reset.c
index 2a6979e4ae1c..5f09d5312472 100644
--- a/drivers/infiniband/hw/mthca/mthca_reset.c
+++ b/drivers/infiniband/hw/mthca/mthca_reset.c
@@ -102,7 +102,10 @@ int mthca_reset(struct mthca_dev *mdev)
for (i = 0; i < 64; ++i) {
if (i == 22 || i == 23)
continue;
- if (pci_read_config_dword(mdev->pdev, i * 4, hca_header + i)) {
+
+ pci_read_config_dword(mdev->pdev, i * 4,
+ hca_header + i);
+ if (*(hca_header + i) == (u32)~0) {
err = -ENODEV;
mthca_err(mdev, "Couldn't save HCA "
"PCI header, aborting.\n");
@@ -123,7 +126,10 @@ int mthca_reset(struct mthca_dev *mdev)
for (i = 0; i < 64; ++i) {
if (i == 22 || i == 23)
continue;
- if (pci_read_config_dword(bridge, i * 4, bridge_header + i)) {
+
+ pci_read_config_dword(bridge, i * 4,
+ bridge_header + i);
+ if (*(bridge_header + i) == (u32)~0) {
err = -ENODEV;
mthca_err(mdev, "Couldn't save HCA bridge "
"PCI header, aborting.\n");
@@ -164,13 +170,8 @@ int mthca_reset(struct mthca_dev *mdev)
int c = 0;
for (c = 0; c < 100; ++c) {
- if (pci_read_config_dword(bridge ? bridge : mdev->pdev, 0, &v)) {
- err = -ENODEV;
- mthca_err(mdev, "Couldn't access HCA after reset, "
- "aborting.\n");
- goto free_bh;
- }
-
+ pci_read_config_dword(bridge ? bridge : mdev->pdev, 0,
+ &v);
if (v != 0xffffffff)
goto good;
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 14/17] IB: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
(?)
@ 2020-08-01 14:18 ` kernel test robot
-1 siblings, 0 replies; 97+ messages in thread
From: kernel test robot @ 2020-08-01 14:18 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3762 bytes --]
Hi "Saheed,
[FYI, it's a private test report for your RFC patch.]
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on linus/master v5.8-rc7]
[cannot apply to ras/edac-for-next ide/master next-20200731]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Saheed-O-Bolarinwa/Drop-uses-of-pci_read_config_-return-value/20200801-202925
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/infiniband/hw/hfi1/pcie.c: In function 'load_eq_table':
>> drivers/infiniband/hw/hfi1/pcie.c:788:24: error: expected ')' before '~' token
788 | if (violation == (32)~0) {
| ~ ^
| )
drivers/infiniband/hw/hfi1/pcie.c:774:6: warning: unused variable 'ret' [-Wunused-variable]
774 | int ret;
| ^~~
vim +788 drivers/infiniband/hw/hfi1/pcie.c
754
755 /* helper to format the value to write to hardware */
756 #define eq_value(pre, curr, post) \
757 ((((u32)(pre)) << \
758 PCIE_CFG_REG_PL102_GEN3_EQ_PRE_CURSOR_PSET_SHIFT) \
759 | (((u32)(curr)) << PCIE_CFG_REG_PL102_GEN3_EQ_CURSOR_PSET_SHIFT) \
760 | (((u32)(post)) << \
761 PCIE_CFG_REG_PL102_GEN3_EQ_POST_CURSOR_PSET_SHIFT))
762
763 /*
764 * Load the given EQ preset table into the PCIe hardware.
765 */
766 static int load_eq_table(struct hfi1_devdata *dd, const u8 eq[11][3], u8 fs,
767 u8 div)
768 {
769 struct pci_dev *pdev = dd->pcidev;
770 u32 hit_error = 0;
771 u32 violation;
772 u32 i;
773 u8 c_minus1, c0, c_plus1;
774 int ret;
775
776 for (i = 0; i < 11; i++) {
777 /* set index */
778 pci_write_config_dword(pdev, PCIE_CFG_REG_PL103, i);
779 /* write the value */
780 c_minus1 = eq[i][PREC] / div;
781 c0 = fs - (eq[i][PREC] / div) - (eq[i][POST] / div);
782 c_plus1 = eq[i][POST] / div;
783 pci_write_config_dword(pdev, PCIE_CFG_REG_PL102,
784 eq_value(c_minus1, c0, c_plus1));
785 /* check if these coefficients violate EQ rules */
786 pci_read_config_dword(dd->pcidev,
787 PCIE_CFG_REG_PL105, &violation);
> 788 if (violation == (32)~0) {
789 dd_dev_err(dd, "Unable to read from PCI config\n");
790 hit_error = 1;
791 break;
792 }
793
794 if (violation
795 & PCIE_CFG_REG_PL105_GEN3_EQ_VIOLATE_COEF_RULES_SMASK){
796 if (hit_error == 0) {
797 dd_dev_err(dd,
798 "Gen3 EQ Table Coefficient rule violations\n");
799 dd_dev_err(dd, " prec attn post\n");
800 }
801 dd_dev_err(dd, " p%02d: %02x %02x %02x\n",
802 i, (u32)eq[i][0], (u32)eq[i][1],
803 (u32)eq[i][2]);
804 dd_dev_err(dd, " %02x %02x %02x\n",
805 (u32)c_minus1, (u32)c0, (u32)c_plus1);
806 hit_error = 1;
807 }
808 }
809 if (hit_error)
810 return -EINVAL;
811 return 0;
812 }
813
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 75819 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* [RFC PATCH 15/17] iommu/vt-d: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
(?)
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Joerg Roedel
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, David Woodhouse, Lu Baolu, iommu
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/iommu/intel/iommu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index d759e7234e98..aad3c065e4a0 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -6165,7 +6165,8 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
if (risky_device(dev))
return;
- if (pci_read_config_word(dev, GGC, &ggc))
+ pci_read_config_word(dev, GGC, &ggc);
+ if (ggc == (u16)~0)
return;
if (!(ggc & GGC_MEMORY_VT_ENABLED)) {
@@ -6218,7 +6219,8 @@ static void __init check_tylersburg_isoch(void)
return;
}
- if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
+ pci_read_config_dword(pdev, 0x188, &vtisochctrl);
+ if (vtisochctrl == (uint32_t)~0) {
pci_dev_put(pdev);
return;
}
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 15/17] iommu/vt-d: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Joerg Roedel
Cc: Saheed O. Bolarinwa, linux-kernel, iommu, linux-pci,
linux-kernel-mentees, David Woodhouse, Lu Baolu
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/iommu/intel/iommu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index d759e7234e98..aad3c065e4a0 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -6165,7 +6165,8 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
if (risky_device(dev))
return;
- if (pci_read_config_word(dev, GGC, &ggc))
+ pci_read_config_word(dev, GGC, &ggc);
+ if (ggc == (u16)~0)
return;
if (!(ggc & GGC_MEMORY_VT_ENABLED)) {
@@ -6218,7 +6219,8 @@ static void __init check_tylersburg_isoch(void)
return;
}
- if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
+ pci_read_config_dword(pdev, 0x188, &vtisochctrl);
+ if (vtisochctrl == (uint32_t)~0) {
pci_dev_put(pdev);
return;
}
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 15/17] iommu/vt-d: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Joerg Roedel
Cc: Saheed O. Bolarinwa, skhan, linux-kernel, iommu, linux-pci,
bjorn, linux-kernel-mentees, David Woodhouse
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/iommu/intel/iommu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index d759e7234e98..aad3c065e4a0 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -6165,7 +6165,8 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
if (risky_device(dev))
return;
- if (pci_read_config_word(dev, GGC, &ggc))
+ pci_read_config_word(dev, GGC, &ggc);
+ if (ggc == (u16)~0)
return;
if (!(ggc & GGC_MEMORY_VT_ENABLED)) {
@@ -6218,7 +6219,8 @@ static void __init check_tylersburg_isoch(void)
return;
}
- if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
+ pci_read_config_dword(pdev, 0x188, &vtisochctrl);
+ if (vtisochctrl == (uint32_t)~0) {
pci_dev_put(pdev);
return;
}
--
2.18.4
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 16/17] mtd: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
(?)
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
Cc: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
linux-pci, linux-kernel, linux-mtd
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/mtd/maps/ichxrom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/maps/ichxrom.c b/drivers/mtd/maps/ichxrom.c
index fda72c5fd8f9..04728d902e49 100644
--- a/drivers/mtd/maps/ichxrom.c
+++ b/drivers/mtd/maps/ichxrom.c
@@ -61,8 +61,8 @@ static void ichxrom_cleanup(struct ichxrom_window *window)
int ret;
/* Disable writes through the rom window */
- ret = pci_read_config_word(window->pdev, BIOS_CNTL, &word);
- if (!ret)
+ pci_read_config_word(window->pdev, BIOS_CNTL, &word);
+ if (word != (u16)~0)
pci_write_config_word(window->pdev, BIOS_CNTL, word & ~1);
pci_dev_put(window->pdev);
--
2.18.4
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 16/17] mtd: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
Cc: Saheed O. Bolarinwa, linux-kernel, linux-mtd, linux-pci,
linux-kernel-mentees
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/mtd/maps/ichxrom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/maps/ichxrom.c b/drivers/mtd/maps/ichxrom.c
index fda72c5fd8f9..04728d902e49 100644
--- a/drivers/mtd/maps/ichxrom.c
+++ b/drivers/mtd/maps/ichxrom.c
@@ -61,8 +61,8 @@ static void ichxrom_cleanup(struct ichxrom_window *window)
int ret;
/* Disable writes through the rom window */
- ret = pci_read_config_word(window->pdev, BIOS_CNTL, &word);
- if (!ret)
+ pci_read_config_word(window->pdev, BIOS_CNTL, &word);
+ if (word != (u16)~0)
pci_write_config_word(window->pdev, BIOS_CNTL, word & ~1);
pci_dev_put(window->pdev);
--
2.18.4
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 16/17] mtd: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed O. Bolarinwa @ 2020-08-01 11:24 UTC (permalink / raw)
To: helgaas, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
Cc: Saheed O. Bolarinwa, skhan, linux-kernel, linux-mtd, linux-pci,
bjorn, linux-kernel-mentees
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/mtd/maps/ichxrom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/maps/ichxrom.c b/drivers/mtd/maps/ichxrom.c
index fda72c5fd8f9..04728d902e49 100644
--- a/drivers/mtd/maps/ichxrom.c
+++ b/drivers/mtd/maps/ichxrom.c
@@ -61,8 +61,8 @@ static void ichxrom_cleanup(struct ichxrom_window *window)
int ret;
/* Disable writes through the rom window */
- ret = pci_read_config_word(window->pdev, BIOS_CNTL, &word);
- if (!ret)
+ pci_read_config_word(window->pdev, BIOS_CNTL, &word);
+ if (word != (u16)~0)
pci_write_config_word(window->pdev, BIOS_CNTL, word & ~1);
pci_dev_put(window->pdev);
--
2.18.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 97+ messages in thread
* [RFC PATCH 17/17] net: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* [Linux-kernel-mentees] [RFC PATCH 17/17] net: Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
0 siblings, 0 replies; 97+ 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, linux-wireless, linux-kernel, netdev,
linux-pci, linux-kernel-mentees
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 17/17] net: Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
(?)
@ 2020-08-01 14:58 ` kernel test robot
-1 siblings, 0 replies; 97+ messages in thread
From: kernel test robot @ 2020-08-01 14:58 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 16567 bytes --]
Hi "Saheed,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on linus/master v5.8-rc7]
[cannot apply to ras/edac-for-next ide/master next-20200731]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Saheed-O-Bolarinwa/Drop-uses-of-pci_read_config_-return-value/20200801-202925
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: arc-allyesconfig (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/net/wireless/intel/iwlwifi/pcie/trans.c: In function 'iwl_trans_pcie_dump_regs':
>> drivers/net/wireless/intel/iwlwifi/pcie/trans.c:124:2: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
124 | for (i = 0, ptr = buf; i < PCI_DUMP_SIZE; i += 4, ptr++)
| ^~~
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:126:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
126 | if (*ptr == (u32)~0)
| ^~
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:138:3: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
138 | for (i = 0, ptr = buf; i < PCI_ERR_ROOT_COMMAND; i += 4, ptr++)
| ^~~
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:140:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
140 | if (*ptr == (u32)~0)
| ^~
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:155:2: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
155 | for (i = 0, ptr = buf; i < PCI_PARENT_DUMP_SIZE; i += 4, ptr++)
| ^~~
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:157:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
157 | if (*ptr == (u32)~0)
| ^~
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:170:3: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
170 | for (i = 0, ptr = buf; i <= PCI_ERR_ROOT_ERR_SRC; i += 4, ptr++)
| ^~~
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:172:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
172 | if (*ptr == (u32)~0)
| ^~
vim +/for +124 drivers/net/wireless/intel/iwlwifi/pcie/trans.c
fe45773b5baa154 drivers/net/wireless/iwlwifi/pcie/trans.c Arik Nemtsov 2014-11-17 88
4290eaad7a8a716 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Johannes Berg 2018-04-11 89 void iwl_trans_pcie_dump_regs(struct iwl_trans *trans)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 90 {
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 91 #define PCI_DUMP_SIZE 352
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 92 #define PCI_MEM_DUMP_SIZE 64
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 93 #define PCI_PARENT_DUMP_SIZE 524
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 94 #define PREFIX_LEN 32
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 95 struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 96 struct pci_dev *pdev = trans_pcie->pci_dev;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 97 u32 i, pos, alloc_size, *ptr, *buf;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 98 char *prefix;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 99
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 100 if (trans_pcie->pcie_dbg_dumped_once)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 101 return;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 102
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 103 /* Should be a multiple of 4 */
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 104 BUILD_BUG_ON(PCI_DUMP_SIZE > 4096 || PCI_DUMP_SIZE & 0x3);
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 105 BUILD_BUG_ON(PCI_MEM_DUMP_SIZE > 4096 || PCI_MEM_DUMP_SIZE & 0x3);
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 106 BUILD_BUG_ON(PCI_PARENT_DUMP_SIZE > 4096 || PCI_PARENT_DUMP_SIZE & 0x3);
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 107
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 108 /* Alloc a max size buffer */
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 109 alloc_size = PCI_ERR_ROOT_ERR_SRC + 4 + PREFIX_LEN;
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 110 alloc_size = max_t(u32, alloc_size, PCI_DUMP_SIZE + PREFIX_LEN);
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 111 alloc_size = max_t(u32, alloc_size, PCI_MEM_DUMP_SIZE + PREFIX_LEN);
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 112 alloc_size = max_t(u32, alloc_size, PCI_PARENT_DUMP_SIZE + PREFIX_LEN);
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 113
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 114 buf = kmalloc(alloc_size, GFP_ATOMIC);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 115 if (!buf)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 116 return;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 117 prefix = (char *)buf + alloc_size - PREFIX_LEN;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 118
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 119 IWL_ERR(trans, "iwlwifi transaction failed, dumping registers\n");
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 120
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 121 /* Print wifi device registers */
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 122 sprintf(prefix, "iwlwifi %s: ", pci_name(pdev));
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 123 IWL_ERR(trans, "iwlwifi device config registers:\n");
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 @124 for (i = 0, ptr = buf; i < PCI_DUMP_SIZE; i += 4, ptr++)
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 125 pci_read_config_dword(pdev, i, ptr);
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 126 if (*ptr == (u32)~0)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 127 goto err_read;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 128 print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 129
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 130 IWL_ERR(trans, "iwlwifi device memory mapped registers:\n");
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 131 for (i = 0, ptr = buf; i < PCI_MEM_DUMP_SIZE; i += 4, ptr++)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 132 *ptr = iwl_read32(trans, i);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 133 print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 134
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 135 pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 136 if (pos) {
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 137 IWL_ERR(trans, "iwlwifi device AER capability structure:\n");
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 138 for (i = 0, ptr = buf; i < PCI_ERR_ROOT_COMMAND; i += 4, ptr++)
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 139 pci_read_config_dword(pdev, pos + i, ptr);
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 140 if (*ptr == (u32)~0)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 141 goto err_read;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 142 print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET,
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 143 32, 4, buf, i, 0);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 144 }
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 145
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 146 /* Print parent device registers next */
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 147 if (!pdev->bus->self)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 148 goto out;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 149
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 150 pdev = pdev->bus->self;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 151 sprintf(prefix, "iwlwifi %s: ", pci_name(pdev));
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 152
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 153 IWL_ERR(trans, "iwlwifi parent port (%s) config registers:\n",
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 154 pci_name(pdev));
c4d3f2ee66a8dd5 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Luca Coelho 2019-05-15 155 for (i = 0, ptr = buf; i < PCI_PARENT_DUMP_SIZE; i += 4, ptr++)
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 156 pci_read_config_dword(pdev, i, ptr);
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 157 if (*ptr == (u32)~0)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 158 goto err_read;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 159 print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 160
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 161 /* Print root port AER registers */
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 162 pos = 0;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 163 pdev = pcie_find_root_port(pdev);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 164 if (pdev)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 165 pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 166 if (pos) {
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 167 IWL_ERR(trans, "iwlwifi root port (%s) AER cap structure:\n",
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 168 pci_name(pdev));
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 169 sprintf(prefix, "iwlwifi %s: ", pci_name(pdev));
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 170 for (i = 0, ptr = buf; i <= PCI_ERR_ROOT_ERR_SRC; i += 4, ptr++)
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 171 pci_read_config_dword(pdev, pos + i, ptr);
31b06e689bc2e78 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Saheed O. Bolarinwa 2020-08-01 172 if (*ptr == (u32)~0)
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 173 goto err_read;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 174 print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32,
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 175 4, buf, i, 0);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 176 }
f3402d6d8eb084f drivers/net/wireless/intel/iwlwifi/pcie/trans.c Sara Sharon 2017-11-20 177 goto out;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 178
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 179 err_read:
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 180 print_hex_dump(KERN_ERR, prefix, DUMP_PREFIX_OFFSET, 32, 4, buf, i, 0);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 181 IWL_ERR(trans, "Read failed@0x%X\n", i);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 182 out:
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 183 trans_pcie->pcie_dbg_dumped_once = 1;
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 184 kfree(buf);
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 185 }
a6d24fad00d98e2 drivers/net/wireless/intel/iwlwifi/pcie/trans.c Rajat Jain 2017-08-17 186
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 64667 bytes --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
2020-08-01 11:24 ` Saheed O. Bolarinwa
` (3 preceding siblings ...)
(?)
@ 2020-08-01 12:56 ` Borislav Petkov
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 12:56 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-01 12:56 UTC (permalink / raw)
To: Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 12:56 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-01 12:56 UTC (permalink / raw)
To: Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 12:56 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-01 12:56 UTC (permalink / raw)
To: Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, Kalle Valo, linux-edac,
linux-hwmon, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 12:56 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-01 12:56 UTC (permalink / raw)
To: Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, linux-atm-general, helgaas, Jakub Kicinski,
linux-kernel-mentees, Wolfgang Grandegger, intel-gfx, linux-gpio,
Marc Kleine-Budde, skhan, bjorn, Kalle Valo, linux-edac,
linux-hwmon, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 12:56 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-01 12:56 UTC (permalink / raw)
To: Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
2020-08-01 12:56 ` Borislav Petkov
` (3 preceding siblings ...)
(?)
@ 2020-08-02 14:53 ` Tom Rix
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 14:53 ` Tom Rix
0 siblings, 0 replies; 97+ messages in thread
From: Tom Rix @ 2020-08-02 14:53 UTC (permalink / raw)
To: Borislav Petkov, Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 14:53 ` Tom Rix
0 siblings, 0 replies; 97+ messages in thread
From: Tom Rix @ 2020-08-02 14:53 UTC (permalink / raw)
To: Borislav Petkov, Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 14:53 ` Tom Rix
0 siblings, 0 replies; 97+ messages in thread
From: Tom Rix @ 2020-08-02 14:53 UTC (permalink / raw)
To: Borislav Petkov, Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, Kalle Valo, linux-edac,
linux-hwmon, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 14:53 ` Tom Rix
0 siblings, 0 replies; 97+ messages in thread
From: Tom Rix @ 2020-08-02 14:53 UTC (permalink / raw)
To: Borislav Petkov, Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, linux-atm-general, helgaas, Jakub Kicinski,
linux-kernel-mentees, Wolfgang Grandegger, intel-gfx, linux-gpio,
Marc Kleine-Budde, skhan, bjorn, Kalle Valo, linux-edac,
linux-hwmon, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 14:53 ` Tom Rix
0 siblings, 0 replies; 97+ messages in thread
From: Tom Rix @ 2020-08-02 14:53 UTC (permalink / raw)
To: Borislav Petkov, Saheed O. Bolarinwa
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
2020-08-01 12:56 ` Borislav Petkov
` (3 preceding siblings ...)
(?)
@ 2020-08-02 17:28 ` Saheed Bolarinwa
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 17:28 ` Saheed Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed Bolarinwa @ 2020-08-02 17:28 UTC (permalink / raw)
To: Borislav Petkov, trix
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 17:28 ` Saheed Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed Bolarinwa @ 2020-08-02 17:28 UTC (permalink / raw)
To: Borislav Petkov, trix
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 17:28 ` Saheed Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed Bolarinwa @ 2020-08-02 17:28 UTC (permalink / raw)
To: Borislav Petkov, trix
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, Kalle Valo, linux-edac,
linux-hwmon, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 17:28 ` Saheed Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed Bolarinwa @ 2020-08-02 17:28 UTC (permalink / raw)
To: Borislav Petkov, trix
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, linux-atm-general, helgaas, Jakub Kicinski,
linux-kernel-mentees, Wolfgang Grandegger, intel-gfx, linux-gpio,
Marc Kleine-Budde, skhan, bjorn, Kalle Valo, linux-edac,
linux-hwmon, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 17:28 ` Saheed Bolarinwa
0 siblings, 0 replies; 97+ messages in thread
From: Saheed Bolarinwa @ 2020-08-02 17:28 UTC (permalink / raw)
To: Borislav Petkov, trix
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
2020-08-02 17:28 ` Saheed Bolarinwa
` (3 preceding siblings ...)
(?)
@ 2020-08-02 18:46 ` Borislav Petkov
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 18:46 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 18:46 UTC (permalink / raw)
To: Saheed Bolarinwa
Cc: Vignesh Raghavendra, trix, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
linux-pci, Jakub Kicinski, linux-kernel-mentees,
Wolfgang Grandegger, intel-gfx, linux-gpio, Marc Kleine-Budde,
skhan, bjorn, Kalle Valo, linux-edac, linux-hwmon, netdev,
linux-wireless, linux-kernel, iommu, linux-crypto, dmaengine,
David S. Miller
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 18:46 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 18:46 UTC (permalink / raw)
To: Saheed Bolarinwa
Cc: Vignesh Raghavendra, trix, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
linux-pci, Jakub Kicinski, linux-kernel-mentees,
Wolfgang Grandegger, intel-gfx, linux-gpio, Marc Kleine-Budde,
skhan, bjorn, Kalle Valo, linux-edac, linux-hwmon, netdev,
linux-wireless, linux-kernel, iommu, linux-crypto, dmaengine,
David S. Miller
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 18:46 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 18:46 UTC (permalink / raw)
To: Saheed Bolarinwa
Cc: Vignesh Raghavendra, trix, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
linux-pci, Jakub Kicinski, linux-kernel-mentees,
Wolfgang Grandegger, intel-gfx, linux-gpio, Marc Kleine-Budde,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 18:46 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 18:46 UTC (permalink / raw)
To: Saheed Bolarinwa
Cc: Vignesh Raghavendra, trix, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, linux-atm-general, helgaas, linux-pci,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, netdev, linux-wireless,
linux-kernel, iommu, linux-crypto, dmaengine, David S. Miller
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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 18:46 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 18:46 UTC (permalink / raw)
To: Saheed Bolarinwa
Cc: Vignesh Raghavendra, trix, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, helgaas,
linux-pci, Jakub Kicinski, linux-kernel-mentees,
Wolfgang Grandegger, intel-gfx, linux-gpio, Marc Kleine-Budde,
skhan, bjorn, Kalle Valo, linux-edac, linux-hwmon, netdev,
linux-wireless, linux-kernel, iommu, linux-crypto, dmaengine,
David S. Miller
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
2020-08-02 18:46 ` Borislav Petkov
` (3 preceding siblings ...)
(?)
@ 2020-08-02 19:14 ` Bjorn Helgaas
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 19:14 ` Bjorn Helgaas
0 siblings, 0 replies; 97+ messages in thread
From: Bjorn Helgaas @ 2020-08-02 19:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, Saheed Bolarinwa,
linux-wireless, linux-kernel, iommu, linux-crypto, netdev,
dmaengine, David S. Miller
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 19:14 ` Bjorn Helgaas
0 siblings, 0 replies; 97+ messages in thread
From: Bjorn Helgaas @ 2020-08-02 19:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, Saheed Bolarinwa,
linux-wireless, linux-kernel, iommu, linux-crypto, netdev,
dmaengine, David S. Miller
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 19:14 ` Bjorn Helgaas
0 siblings, 0 replies; 97+ messages in thread
From: Bjorn Helgaas @ 2020-08-02 19:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, Kalle Valo, linux-edac,
linux-hwmon, Saheed Bolarinwa, linux-wireless, linux-kernel,
iommu, linux-crypto, netdev, dmaengine, David S. Miller
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 19:14 ` Bjorn Helgaas
0 siblings, 0 replies; 97+ messages in thread
From: Bjorn Helgaas @ 2020-08-02 19:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, linux-atm-general, trix, Jakub Kicinski,
linux-kernel-mentees, Wolfgang Grandegger, intel-gfx, linux-gpio,
Marc Kleine-Budde, skhan, bjorn, Kalle Valo, linux-edac,
linux-hwmon, Saheed Bolarinwa, linux-wireless, linux-kernel,
iommu, linux-crypto, netdev, dmaengine, David S. Miller
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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 19:14 ` Bjorn Helgaas
0 siblings, 0 replies; 97+ messages in thread
From: Bjorn Helgaas @ 2020-08-02 19:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, Saheed Bolarinwa,
linux-wireless, linux-kernel, iommu, linux-crypto, netdev,
dmaengine, David S. Miller
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
2020-08-02 19:14 ` Bjorn Helgaas
` (3 preceding siblings ...)
(?)
@ 2020-08-02 20:18 ` Borislav Petkov
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 20:18 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 20:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, Saheed Bolarinwa,
linux-wireless, linux-kernel, iommu, linux-crypto, netdev,
dmaengine, David S. Miller
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 20:18 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 20:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, Saheed Bolarinwa,
linux-wireless, linux-kernel, iommu, linux-crypto, netdev,
dmaengine, David S. Miller
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 20:18 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 20:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, Kalle Valo, linux-edac,
linux-hwmon, Saheed Bolarinwa, linux-wireless, linux-kernel,
iommu, linux-crypto, netdev, dmaengine, David S. Miller
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 20:18 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 20:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, linux-atm-general, trix, Jakub Kicinski,
linux-kernel-mentees, Wolfgang Grandegger, intel-gfx, linux-gpio,
Marc Kleine-Budde, skhan, bjorn, Kalle Valo, linux-edac,
linux-hwmon, Saheed Bolarinwa, linux-wireless, linux-kernel,
iommu, linux-crypto, netdev, dmaengine, David S. Miller
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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-02 20:18 ` Borislav Petkov
0 siblings, 0 replies; 97+ messages in thread
From: Borislav Petkov @ 2020-08-02 20:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Marc Kleine-Budde, skhan, bjorn,
Kalle Valo, linux-edac, linux-hwmon, Saheed Bolarinwa,
linux-wireless, linux-kernel, iommu, linux-crypto, netdev,
dmaengine, David S. Miller
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
2020-08-02 19:14 ` Bjorn Helgaas
` (2 preceding siblings ...)
(?)
@ 2020-08-03 6:56 ` Christoph Hellwig
-1 siblings, 0 replies; 97+ 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] 97+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-03 6:56 ` Christoph Hellwig
0 siblings, 0 replies; 97+ messages in thread
From: Christoph Hellwig @ 2020-08-03 6:56 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Borislav Petkov, skhan, bjorn, Kalle Valo,
linux-edac, linux-hwmon, Saheed Bolarinwa, linux-wireless,
linux-kernel, iommu, linux-crypto, netdev, dmaengine,
Marc Kleine-Budde, David S. Miller
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)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [Linux-kernel-mentees] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-03 6:56 ` Christoph Hellwig
0 siblings, 0 replies; 97+ messages in thread
From: Christoph Hellwig @ 2020-08-03 6:56 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Borislav Petkov, Kalle Valo, linux-edac,
linux-hwmon, Saheed Bolarinwa, linux-wireless, linux-kernel,
iommu, linux-crypto, netdev, dmaengine, Marc Kleine-Budde,
David S. Miller
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)
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-03 6:56 ` Christoph Hellwig
0 siblings, 0 replies; 97+ messages in thread
From: Christoph Hellwig @ 2020-08-03 6:56 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, linux-atm-general, trix, Jakub Kicinski,
linux-kernel-mentees, Wolfgang Grandegger, intel-gfx, linux-gpio,
Borislav Petkov, skhan, bjorn, Kalle Valo, linux-edac,
linux-hwmon, Saheed Bolarinwa, linux-wireless, linux-kernel,
iommu, linux-crypto, netdev, dmaengine, Marc Kleine-Budde,
David S. Miller
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)
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-03 6:56 ` Christoph Hellwig
0 siblings, 0 replies; 97+ messages in thread
From: Christoph Hellwig @ 2020-08-03 6:56 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vignesh Raghavendra, linux-pci, linux-fpga, dri-devel, linux-ide,
linux-mtd, linux-i2c, Miquel Raynal, linux-rdma,
Richard Weinberger, Joerg Roedel, linux-atm-general, trix,
Jakub Kicinski, linux-kernel-mentees, Wolfgang Grandegger,
intel-gfx, linux-gpio, Borislav Petkov, skhan, bjorn, Kalle Valo,
linux-edac, linux-hwmon, Saheed Bolarinwa, linux-wireless,
linux-kernel, iommu, linux-crypto, netdev, dmaengine,
Marc Kleine-Budde, David S. Miller
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)
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 97+ messages in thread