All of lore.kernel.org
 help / color / mirror / Atom feed
* [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: Saheed O. Bolarinwa, bjorn, skhan, linux-kernel-mentees,
	linux-pci, linux-kernel, linux-wireless, netdev, linux-mtd,
	iommu, linux-rdma, linux-ide, linux-i2c, linux-hwmon, dri-devel,
	intel-gfx, linux-gpio, linux-fpga, linux-edac, dmaengine,
	linux-crypto, linux-atm-general

The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.

It is possible to move to one single way of checking for error if the 
dependencies on the return value of these functions are removed, then it
can later be made to return void.

Remove all uses of the return value of pci_read_config_*().
Check the actual value read for ~0. In this case, ~0 is an invalid value
thus it indicates some kind of error.

In some cases it madkes sence to make the calling function return void
without causing any bug. Future callers can use the value obtained from
these functions for validation. This case pertain to cs5536_read() and 
edac_pci_read_dword()

MERGE:
There is no dependency.
Merge individually

Saheed O. Bolarinwa (17):
  ata: Drop uses of pci_read_config_*() return value
  atm: Drop uses of pci_read_config_*() return value
  bcma: Drop uses of pci_read_config_*() return value
  hwrng: Drop uses of pci_read_config_*() return value
  dmaengine: ioat: Drop uses of pci_read_config_*() return value
  edac: Drop uses of pci_read_config_*() return value
  fpga: altera-cvp: Drop uses of pci_read_config_*() return value
  gpio: Drop uses of pci_read_config_*() return value
  drm/i915/vga: Drop uses of pci_read_config_*() return value
  hwmon: Drop uses of pci_read_config_*() return value
  intel_th: pci: Drop uses of pci_read_config_*() return value
  i2c: Drop uses of pci_read_config_*() return value
  ide: Drop uses of pci_read_config_*() return value
  IB: Drop uses of pci_read_config_*() return value
  iommu/vt-d: Drop uses of pci_read_config_*() return value
  mtd: Drop uses of pci_read_config_*() return value
  net: Drop uses of pci_read_config_*() return value

 drivers/ata/pata_cs5536.c                     |  6 +--
 drivers/ata/pata_rz1000.c                     |  3 +-
 drivers/atm/eni.c                             |  3 +-
 drivers/atm/he.c                              | 12 +++--
 drivers/atm/idt77252.c                        |  9 ++--
 drivers/atm/iphase.c                          | 46 ++++++++++---------
 drivers/atm/lanai.c                           |  4 +-
 drivers/atm/nicstar.c                         |  3 +-
 drivers/atm/zatm.c                            |  9 ++--
 drivers/bcma/host_pci.c                       |  6 ++-
 drivers/char/hw_random/amd-rng.c              |  6 +--
 drivers/dma/ioat/dma.c                        |  6 +--
 drivers/edac/amd64_edac.c                     |  8 ++--
 drivers/edac/amd8111_edac.c                   | 16 ++-----
 drivers/edac/amd8131_edac.c                   |  6 +--
 drivers/edac/i82443bxgx_edac.c                |  3 +-
 drivers/edac/sb_edac.c                        | 12 +++--
 drivers/edac/skx_common.c                     | 18 +++++---
 drivers/fpga/altera-cvp.c                     |  8 ++--
 drivers/gpio/gpio-amd8111.c                   |  7 ++-
 drivers/gpio/gpio-rdc321x.c                   | 21 +++++----
 drivers/gpu/drm/i915/display/intel_vga.c      |  3 +-
 drivers/hwmon/i5k_amb.c                       | 12 +++--
 drivers/hwmon/vt8231.c                        |  8 ++--
 drivers/hwtracing/intel_th/pci.c              | 12 ++---
 drivers/i2c/busses/i2c-ali15x3.c              |  6 ++-
 drivers/i2c/busses/i2c-elektor.c              |  3 +-
 drivers/i2c/busses/i2c-nforce2.c              |  4 +-
 drivers/i2c/busses/i2c-sis5595.c              | 17 ++++---
 drivers/i2c/busses/i2c-sis630.c               |  7 +--
 drivers/i2c/busses/i2c-viapro.c               | 11 +++--
 drivers/ide/cs5536.c                          |  6 +--
 drivers/ide/rz1000.c                          |  3 +-
 drivers/ide/setup-pci.c                       | 26 +++++++----
 drivers/infiniband/hw/hfi1/pcie.c             | 38 +++++++--------
 drivers/infiniband/hw/mthca/mthca_reset.c     | 19 ++++----
 drivers/iommu/intel/iommu.c                   |  6 ++-
 drivers/mtd/maps/ichxrom.c                    |  4 +-
 drivers/net/can/peak_canfd/peak_pciefd_main.c |  6 ++-
 drivers/net/can/sja1000/peak_pci.c            |  6 ++-
 drivers/net/ethernet/agere/et131x.c           | 11 +++--
 .../ethernet/broadcom/bnx2x/bnx2x_ethtool.c   |  5 +-
 .../cavium/liquidio/cn23xx_pf_device.c        |  4 +-
 drivers/net/ethernet/marvell/sky2.c           |  5 +-
 drivers/net/ethernet/mellanox/mlx4/catas.c    |  7 +--
 drivers/net/ethernet/mellanox/mlx4/reset.c    | 10 ++--
 .../net/ethernet/myricom/myri10ge/myri10ge.c  |  4 +-
 drivers/net/wan/farsync.c                     |  5 +-
 .../broadcom/brcm80211/brcmfmac/pcie.c        |  4 +-
 .../net/wireless/intel/iwlwifi/pcie/trans.c   | 15 ++++--
 50 files changed, 270 insertions(+), 209 deletions(-)

-- 
2.18.4


^ permalink raw reply	[flat|nested] 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 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

* [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

_______________________________________________
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

* [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 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, &reg) != 0)
+	pci_read_config_word(pdev, 0x40, &reg);
+	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, &reg) != 0)
+	pci_read_config_word(pdev, 0x40, &reg);
+	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

* [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, &reg)) {
+			pci_read_config_dword(pvt->pci_ha, HASWELL_HASYSDEFEATURE2, &reg);
+			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, &reg)) {
+		pci_read_config_dword(pvt->pci_ras, RASENABLES, &reg);
+		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, &reg)) {
+	pci_read_config_dword(d->util_all, off, &reg);
+	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, &reg)) {
+	pci_read_config_dword(d->util_all, 0xf4, &reg);
+	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, &reg)) {
+		pci_read_config_dword(pdev, cfg->busno_cfg_offset, &reg);
+		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], &reg)) {
+	pci_read_config_dword(pdev, off[0], &reg);
+	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], &reg)) {
+	pci_read_config_dword(pdev, off[1], &reg);
+	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], &reg)) {
+	pci_read_config_dword(pdev, off[2], &reg);
+	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, &reg)) {
+			pci_read_config_dword(pvt->pci_ha, HASWELL_HASYSDEFEATURE2, &reg);
+			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, &reg)) {
+		pci_read_config_dword(pvt->pci_ras, RASENABLES, &reg);
+		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, &reg)) {
+	pci_read_config_dword(d->util_all, off, &reg);
+	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, &reg)) {
+	pci_read_config_dword(d->util_all, 0xf4, &reg);
+	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, &reg)) {
+		pci_read_config_dword(pdev, cfg->busno_cfg_offset, &reg);
+		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], &reg)) {
+	pci_read_config_dword(pdev, off[0], &reg);
+	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], &reg)) {
+	pci_read_config_dword(pdev, off[1], &reg);
+	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], &reg)) {
+	pci_read_config_dword(pdev, off[2], &reg);
+	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

* [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

* [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, &reg);
-	if (err)
+	pci_read_config_dword(gpch->sb_pdev,
+				(gpio < 32) ? gpch->reg1_ctrl_base
+					: gpch->reg2_ctrl_base, &reg);
+	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, &reg);
-	if (err)
+	pci_read_config_dword(gpch->sb_pdev,
+				(gpio < 32) ? gpch->reg1_ctrl_base
+					: gpch->reg2_ctrl_base, &reg);
+	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

* [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

* [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 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

* [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 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

* [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, &reg) &&
+	pci_read_config_word(dev, 0x40, &reg);
+	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, &reg) &&
+	pci_read_config_word(dev, 0x40, &reg);
+	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, &reg32);
-	if (ret) {
+	pci_read_config_dword(dd->pcidev, PCIE_CFG_SPCIE2, &reg32);
+	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, &reg32);
-	if (ret) {
+	pci_read_config_dword(dd->pcidev, PCIE_CFG_SPCIE2, &reg32);
+	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

* [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

* [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

* [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 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

* [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

* [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 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, &reg))
+		pci_read_config_dword(pdev, LBCIF_DWORD1_GROUP, &reg);
+		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, &reg);
-	if (err) {
+	pci_read_config_dword(pdev, PCI_DEV_REG2, &reg);
+	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, &reg))
+		pci_read_config_dword(pdev, LBCIF_DWORD1_GROUP, &reg);
+		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, &reg);
-	if (err) {
+	pci_read_config_dword(pdev, PCI_DEV_REG2, &reg);
+	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 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: [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
  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: [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, 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: [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 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

* 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 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

* 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 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: [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-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: [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, 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: [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-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: [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
  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: [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, 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: [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
                         ` (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: [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
  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: [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, 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: [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
                           ` (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: [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
  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: [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, 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: [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
                             ` (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: [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 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: [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, 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: [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 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: [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

* 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: [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: [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: [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

* 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

* 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

* 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, &reg);
> -       if (err)
> +       pci_read_config_dword(gpch->sb_pdev,
> +                               (gpio < 32) ? gpch->reg1_ctrl_base
> +                                       : gpch->reg2_ctrl_base, &reg);
> +       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, &reg);
> -       if (err)
> +       pci_read_config_dword(gpch->sb_pdev,
> +                               (gpio < 32) ? gpch->reg1_ctrl_base
> +                                       : gpch->reg2_ctrl_base, &reg);
> +       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, &reg);
> > -       if (err)
> > +       pci_read_config_dword(gpch->sb_pdev,
> > +                               (gpio < 32) ? gpch->reg1_ctrl_base
> > +                                       : gpch->reg2_ctrl_base, &reg);
> > +       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, &reg);
> > -       if (err)
> > +       pci_read_config_dword(gpch->sb_pdev,
> > +                               (gpio < 32) ? gpch->reg1_ctrl_base
> > +                                       : gpch->reg2_ctrl_base, &reg);
> > +       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

end of thread, other threads:[~2020-08-19  2:21 UTC | newest]

Thread overview: 97+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa
2020-08-01 11:24 ` [Intel-gfx] " Saheed O. Bolarinwa
2020-08-01 11:24 ` Saheed O. Bolarinwa
2020-08-01 11:24 ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` Saheed O. Bolarinwa
2020-08-01 11:24 ` Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 01/17] ata: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 02/17] atm: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-05 10:51   ` kernel test robot
2020-08-01 11:24 ` [RFC PATCH 03/17] bcma: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 04/17] hwrng: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 05/17] dmaengine: ioat: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 06/17] edac: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 21:38   ` kernel test robot
2020-08-01 11:24 ` [RFC PATCH 07/17] fpga: altera-cvp: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 22:32   ` kernel test robot
2020-08-05 12:31   ` kernel test robot
2020-08-01 11:24 ` [RFC PATCH 08/17] gpio: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-18 19:59   ` Bartosz Golaszewski
2020-08-18 19:59     ` [Linux-kernel-mentees] " Bartosz Golaszewski
2020-08-19  2:21     ` Bjorn Helgaas
2020-08-19  2:21       ` [Linux-kernel-mentees] " Bjorn Helgaas
2020-08-01 11:24 ` [RFC PATCH 09/17] drm/i915/vga: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Intel-gfx] " Saheed O. Bolarinwa
2020-08-01 11:24   ` Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 10/17] hwmon: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-04 21:26   ` Guenter Roeck
2020-08-04 21:26     ` [Linux-kernel-mentees] " Guenter Roeck
2020-08-01 11:24 ` [RFC PATCH 11/17] intel_th: pci: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 12/17] i2c: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 13/17] ide: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 14/17] IB: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 14:18   ` kernel test robot
2020-08-01 11:24 ` [RFC PATCH 15/17] iommu/vt-d: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24   ` Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 16/17] mtd: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 11:24   ` Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 17/17] net: " Saheed O. Bolarinwa
2020-08-01 11:24   ` [Linux-kernel-mentees] " Saheed O. Bolarinwa
2020-08-01 14:58   ` kernel test robot
2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov
2020-08-01 12:56   ` [Intel-gfx] " Borislav Petkov
2020-08-01 12:56   ` Borislav Petkov
2020-08-01 12:56   ` [Linux-kernel-mentees] " Borislav Petkov
2020-08-01 12:56   ` Borislav Petkov
2020-08-01 12:56   ` Borislav Petkov
2020-08-02 14:53   ` Tom Rix
2020-08-02 14:53     ` [Intel-gfx] " Tom Rix
2020-08-02 14:53     ` Tom Rix
2020-08-02 14:53     ` [Linux-kernel-mentees] " Tom Rix
2020-08-02 14:53     ` Tom Rix
2020-08-02 14:53     ` Tom Rix
2020-08-02 17:28   ` Saheed Bolarinwa
2020-08-02 17:28     ` [Intel-gfx] " Saheed Bolarinwa
2020-08-02 17:28     ` Saheed Bolarinwa
2020-08-02 17:28     ` [Linux-kernel-mentees] " Saheed Bolarinwa
2020-08-02 17:28     ` Saheed Bolarinwa
2020-08-02 17:28     ` Saheed Bolarinwa
2020-08-02 18:46     ` Borislav Petkov
2020-08-02 18:46       ` [Intel-gfx] " Borislav Petkov
2020-08-02 18:46       ` Borislav Petkov
2020-08-02 18:46       ` [Linux-kernel-mentees] " Borislav Petkov
2020-08-02 18:46       ` Borislav Petkov
2020-08-02 18:46       ` Borislav Petkov
2020-08-02 19:14       ` Bjorn Helgaas
2020-08-02 19:14         ` [Intel-gfx] " Bjorn Helgaas
2020-08-02 19:14         ` Bjorn Helgaas
2020-08-02 19:14         ` [Linux-kernel-mentees] " Bjorn Helgaas
2020-08-02 19:14         ` Bjorn Helgaas
2020-08-02 19:14         ` Bjorn Helgaas
2020-08-02 20:18         ` Borislav Petkov
2020-08-02 20:18           ` [Intel-gfx] " Borislav Petkov
2020-08-02 20:18           ` Borislav Petkov
2020-08-02 20:18           ` [Linux-kernel-mentees] " Borislav Petkov
2020-08-02 20:18           ` Borislav Petkov
2020-08-02 20:18           ` Borislav Petkov
2020-08-03  6:56         ` Christoph Hellwig
2020-08-03  6:56           ` [Intel-gfx] " Christoph Hellwig
2020-08-03  6:56           ` [Linux-kernel-mentees] " Christoph Hellwig
2020-08-03  6:56           ` Christoph Hellwig
2020-08-03  6:56           ` Christoph Hellwig

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.