Linux-EDAC Archive on lore.kernel.org
 help / color / Atom feed
* [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
@ 2020-08-01 11:24 Saheed O. Bolarinwa
  2020-08-01 11:24 ` [RFC PATCH 06/17] edac: " Saheed O. Bolarinwa
  2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov
  0 siblings, 2 replies; 9+ 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] 9+ messages in thread

* [RFC PATCH 06/17] edac: Drop uses of pci_read_config_*() return value
  2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa
@ 2020-08-01 11:24 ` Saheed O. Bolarinwa
  2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov
  1 sibling, 0 replies; 9+ 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	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
  2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa
  2020-08-01 11:24 ` [RFC PATCH 06/17] edac: " Saheed O. Bolarinwa
@ 2020-08-01 12:56 ` Borislav Petkov
  2020-08-02 14:53   ` Tom Rix
  2020-08-02 17:28   ` Saheed Bolarinwa
  1 sibling, 2 replies; 9+ 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] 9+ messages in thread

* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
  2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov
@ 2020-08-02 14:53   ` Tom Rix
  2020-08-02 17:28   ` Saheed Bolarinwa
  1 sibling, 0 replies; 9+ 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] 9+ messages in thread

* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
  2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov
  2020-08-02 14:53   ` Tom Rix
@ 2020-08-02 17:28   ` Saheed Bolarinwa
  2020-08-02 18:46     ` Borislav Petkov
  1 sibling, 1 reply; 9+ 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] 9+ messages in thread

* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
  2020-08-02 17:28   ` Saheed Bolarinwa
@ 2020-08-02 18:46     ` Borislav Petkov
  2020-08-02 19:14       ` Bjorn Helgaas
  0 siblings, 1 reply; 9+ 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] 9+ messages in thread

* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
  2020-08-02 18:46     ` Borislav Petkov
@ 2020-08-02 19:14       ` Bjorn Helgaas
  2020-08-02 20:18         ` Borislav Petkov
  2020-08-03  6:56         ` Christoph Hellwig
  0 siblings, 2 replies; 9+ 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] 9+ messages in thread

* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
  2020-08-02 19:14       ` Bjorn Helgaas
@ 2020-08-02 20:18         ` Borislav Petkov
  2020-08-03  6:56         ` Christoph Hellwig
  1 sibling, 0 replies; 9+ 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] 9+ messages in thread

* Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
  2020-08-02 19:14       ` Bjorn Helgaas
  2020-08-02 20:18         ` Borislav Petkov
@ 2020-08-03  6:56         ` Christoph Hellwig
  1 sibling, 0 replies; 9+ 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] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-01 11:24 [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value Saheed O. Bolarinwa
2020-08-01 11:24 ` [RFC PATCH 06/17] edac: " Saheed O. Bolarinwa
2020-08-01 12:56 ` [RFC PATCH 00/17] " Borislav Petkov
2020-08-02 14:53   ` Tom Rix
2020-08-02 17:28   ` Saheed Bolarinwa
2020-08-02 18:46     ` Borislav Petkov
2020-08-02 19:14       ` Bjorn Helgaas
2020-08-02 20:18         ` Borislav Petkov
2020-08-03  6:56         ` Christoph Hellwig

Linux-EDAC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-edac/0 linux-edac/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-edac linux-edac/ https://lore.kernel.org/linux-edac \
		linux-edac@vger.kernel.org
	public-inbox-index linux-edac

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-edac


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git