* [PATCH v2 00/24] Unify PCI error response checking
@ 2021-10-15 14:35 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:35 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
linux-arm-kernel, linux-hyperv, linux-mediatek, linuxppc-dev,
linux-renesas-soc, linux-rockchip, linux-samsung-soc,
Rob Herring, Pali Rohár
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
This patch series adds PCI_ERROR_RESPONSE definition and other helper
definition SET_PCI_ERROR_RESPONSE and RESPONSE_IS_PCI_ERROR and uses it
where appropriate to make these checks consistent and easier to find.
This helps unify PCI error response checking and make error check
consistent and easier to find.
This series also ensures that the error response fabrication now happens
in the PCI_OP_READ and PCI_USER_READ_CONFIG. This removes the
responsibility from controller drivers to do the error response setting.
Patch 1:
- Adds the PCI_ERROR_RESPONSE and other related defintions
- All other patches are dependent on this patch. This patch needs to
be applied first, before the others
Patch 2:
- Error fabrication happens in PCI_OP_READ and PCI_USER_READ_CONFIG
whenever the data read via the controller driver fails.
- This patch needs to be applied before, Patch 4/24 to Patch 15/24 are
applied.
Patch 3:
- Uses SET_PCI_ERROR_RESPONSE() when device is not found and
RESPONSE_IS_PCI_ERROR() to check hardware read from the hardware.
Patch 4 - 15:
- Removes redundant error fabrication that happens in controller
drivers when the read from a PCI device fails.
- These patches are dependent on Patch 2/24 of the series.
- These can be applied in any order.
Patch 16 - 22:
- Uses RESPONSE_IS_PCI_ERROR() to check the reads from hardware
- Patches can be applied in any order.
Patch 23 - 24:
- Edits the comments to include PCI_ERROR_RESPONSE alsong with
0xFFFFFFFF, so that it becomes easier to grep for faulty
hardware reads.
Changelog
=========
v2:
- Instead of using SET_PCI_ERROR_RESPONSE in all controller drivers
to fabricate error response, only use them in PCI_OP_READ and
PCI_USER_READ_CONFIG
Naveen Naidu (24):
[PATCH 1/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
[PATCH 2/24] PCI: Set error response in config access defines when ops->read() fails
[PATCH 3/24] PCI: Unify PCI error response checking
[PATCH 4/24] PCI: Remove redundant error fabrication when device read fails
[PATCH 5/24] PCI: thunder: Remove redundant error fabrication when device read fails
[PATCH 6/24] PCI: iproc: Remove redundant error fabrication when device read fails
[PATCH 7/24] PCI: mediatek: Remove redundant error fabrication when device read fails
[PATCH 8/24] PCI: exynos: Remove redundant error fabrication when device read fails
[PATCH 9/24] PCI: histb: Remove redundant error fabrication when device read fails
[PATCH 10/24] PCI: kirin: Remove redundant error fabrication when device read fails
[PATCH 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
[PATCH 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
[PATCH 13/24] PCI: altera: Remove redundant error fabrication when device read fails
[PATCH 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
[PATCH 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
[PATCH 16/24] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 20/24] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 21/24] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 22/24] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
[PATCH 23/24] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
[PATCH 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
drivers/pci/access.c | 36 ++++++++--------
drivers/pci/controller/dwc/pci-exynos.c | 4 +-
drivers/pci/controller/dwc/pci-keystone.c | 4 +-
drivers/pci/controller/dwc/pcie-histb.c | 4 +-
drivers/pci/controller/dwc/pcie-kirin.c | 4 +-
drivers/pci/controller/pci-aardvark.c | 10 +----
drivers/pci/controller/pci-hyperv.c | 2 +-
drivers/pci/controller/pci-mvebu.c | 8 +---
drivers/pci/controller/pci-thunder-ecam.c | 46 +++++++--------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
drivers/pci/controller/pci-xgene.c | 8 ++--
drivers/pci/controller/pcie-altera.c | 4 +-
drivers/pci/controller/pcie-iproc.c | 4 +-
drivers/pci/controller/pcie-mediatek.c | 11 +----
drivers/pci/controller/pcie-rcar-host.c | 4 +-
drivers/pci/controller/pcie-rockchip-host.c | 4 +-
drivers/pci/controller/vmd.c | 2 +-
drivers/pci/hotplug/cpqphp_ctrl.c | 4 +-
drivers/pci/hotplug/pciehp_hpc.c | 10 ++---
drivers/pci/pci.c | 10 ++---
drivers/pci/pcie/dpc.c | 4 +-
drivers/pci/pcie/pme.c | 4 +-
drivers/pci/probe.c | 10 ++---
include/linux/pci.h | 9 ++++
24 files changed, 87 insertions(+), 123 deletions(-)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH v2 00/24] Unify PCI error response checking
@ 2021-10-15 14:35 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:35 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
linux-arm-kernel, linux-hyperv, linux-mediatek, linuxppc-dev,
linux-renesas-soc, linux-rockchip, linux-samsung-soc,
Rob Herring, Pali Rohár
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
This patch series adds PCI_ERROR_RESPONSE definition and other helper
definition SET_PCI_ERROR_RESPONSE and RESPONSE_IS_PCI_ERROR and uses it
where appropriate to make these checks consistent and easier to find.
This helps unify PCI error response checking and make error check
consistent and easier to find.
This series also ensures that the error response fabrication now happens
in the PCI_OP_READ and PCI_USER_READ_CONFIG. This removes the
responsibility from controller drivers to do the error response setting.
Patch 1:
- Adds the PCI_ERROR_RESPONSE and other related defintions
- All other patches are dependent on this patch. This patch needs to
be applied first, before the others
Patch 2:
- Error fabrication happens in PCI_OP_READ and PCI_USER_READ_CONFIG
whenever the data read via the controller driver fails.
- This patch needs to be applied before, Patch 4/24 to Patch 15/24 are
applied.
Patch 3:
- Uses SET_PCI_ERROR_RESPONSE() when device is not found and
RESPONSE_IS_PCI_ERROR() to check hardware read from the hardware.
Patch 4 - 15:
- Removes redundant error fabrication that happens in controller
drivers when the read from a PCI device fails.
- These patches are dependent on Patch 2/24 of the series.
- These can be applied in any order.
Patch 16 - 22:
- Uses RESPONSE_IS_PCI_ERROR() to check the reads from hardware
- Patches can be applied in any order.
Patch 23 - 24:
- Edits the comments to include PCI_ERROR_RESPONSE alsong with
0xFFFFFFFF, so that it becomes easier to grep for faulty
hardware reads.
Changelog
=========
v2:
- Instead of using SET_PCI_ERROR_RESPONSE in all controller drivers
to fabricate error response, only use them in PCI_OP_READ and
PCI_USER_READ_CONFIG
Naveen Naidu (24):
[PATCH 1/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
[PATCH 2/24] PCI: Set error response in config access defines when ops->read() fails
[PATCH 3/24] PCI: Unify PCI error response checking
[PATCH 4/24] PCI: Remove redundant error fabrication when device read fails
[PATCH 5/24] PCI: thunder: Remove redundant error fabrication when device read fails
[PATCH 6/24] PCI: iproc: Remove redundant error fabrication when device read fails
[PATCH 7/24] PCI: mediatek: Remove redundant error fabrication when device read fails
[PATCH 8/24] PCI: exynos: Remove redundant error fabrication when device read fails
[PATCH 9/24] PCI: histb: Remove redundant error fabrication when device read fails
[PATCH 10/24] PCI: kirin: Remove redundant error fabrication when device read fails
[PATCH 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
[PATCH 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
[PATCH 13/24] PCI: altera: Remove redundant error fabrication when device read fails
[PATCH 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
[PATCH 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
[PATCH 16/24] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 20/24] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 21/24] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 22/24] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
[PATCH 23/24] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
[PATCH 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
drivers/pci/access.c | 36 ++++++++--------
drivers/pci/controller/dwc/pci-exynos.c | 4 +-
drivers/pci/controller/dwc/pci-keystone.c | 4 +-
drivers/pci/controller/dwc/pcie-histb.c | 4 +-
drivers/pci/controller/dwc/pcie-kirin.c | 4 +-
drivers/pci/controller/pci-aardvark.c | 10 +----
drivers/pci/controller/pci-hyperv.c | 2 +-
drivers/pci/controller/pci-mvebu.c | 8 +---
drivers/pci/controller/pci-thunder-ecam.c | 46 +++++++--------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
drivers/pci/controller/pci-xgene.c | 8 ++--
drivers/pci/controller/pcie-altera.c | 4 +-
drivers/pci/controller/pcie-iproc.c | 4 +-
drivers/pci/controller/pcie-mediatek.c | 11 +----
drivers/pci/controller/pcie-rcar-host.c | 4 +-
drivers/pci/controller/pcie-rockchip-host.c | 4 +-
drivers/pci/controller/vmd.c | 2 +-
drivers/pci/hotplug/cpqphp_ctrl.c | 4 +-
drivers/pci/hotplug/pciehp_hpc.c | 10 ++---
drivers/pci/pci.c | 10 ++---
drivers/pci/pcie/dpc.c | 4 +-
drivers/pci/pcie/pme.c | 4 +-
drivers/pci/probe.c | 10 ++---
include/linux/pci.h | 9 ++++
24 files changed, 87 insertions(+), 123 deletions(-)
--
2.25.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH v2 00/24] Unify PCI error response checking
@ 2021-10-15 14:35 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:35 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
linux-arm-kernel, linux-hyperv, linux-mediatek, linuxppc-dev,
linux-renesas-soc, linux-rockchip, linux-samsung-soc,
Rob Herring, Pali Rohár
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
This patch series adds PCI_ERROR_RESPONSE definition and other helper
definition SET_PCI_ERROR_RESPONSE and RESPONSE_IS_PCI_ERROR and uses it
where appropriate to make these checks consistent and easier to find.
This helps unify PCI error response checking and make error check
consistent and easier to find.
This series also ensures that the error response fabrication now happens
in the PCI_OP_READ and PCI_USER_READ_CONFIG. This removes the
responsibility from controller drivers to do the error response setting.
Patch 1:
- Adds the PCI_ERROR_RESPONSE and other related defintions
- All other patches are dependent on this patch. This patch needs to
be applied first, before the others
Patch 2:
- Error fabrication happens in PCI_OP_READ and PCI_USER_READ_CONFIG
whenever the data read via the controller driver fails.
- This patch needs to be applied before, Patch 4/24 to Patch 15/24 are
applied.
Patch 3:
- Uses SET_PCI_ERROR_RESPONSE() when device is not found and
RESPONSE_IS_PCI_ERROR() to check hardware read from the hardware.
Patch 4 - 15:
- Removes redundant error fabrication that happens in controller
drivers when the read from a PCI device fails.
- These patches are dependent on Patch 2/24 of the series.
- These can be applied in any order.
Patch 16 - 22:
- Uses RESPONSE_IS_PCI_ERROR() to check the reads from hardware
- Patches can be applied in any order.
Patch 23 - 24:
- Edits the comments to include PCI_ERROR_RESPONSE alsong with
0xFFFFFFFF, so that it becomes easier to grep for faulty
hardware reads.
Changelog
=========
v2:
- Instead of using SET_PCI_ERROR_RESPONSE in all controller drivers
to fabricate error response, only use them in PCI_OP_READ and
PCI_USER_READ_CONFIG
Naveen Naidu (24):
[PATCH 1/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
[PATCH 2/24] PCI: Set error response in config access defines when ops->read() fails
[PATCH 3/24] PCI: Unify PCI error response checking
[PATCH 4/24] PCI: Remove redundant error fabrication when device read fails
[PATCH 5/24] PCI: thunder: Remove redundant error fabrication when device read fails
[PATCH 6/24] PCI: iproc: Remove redundant error fabrication when device read fails
[PATCH 7/24] PCI: mediatek: Remove redundant error fabrication when device read fails
[PATCH 8/24] PCI: exynos: Remove redundant error fabrication when device read fails
[PATCH 9/24] PCI: histb: Remove redundant error fabrication when device read fails
[PATCH 10/24] PCI: kirin: Remove redundant error fabrication when device read fails
[PATCH 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
[PATCH 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
[PATCH 13/24] PCI: altera: Remove redundant error fabrication when device read fails
[PATCH 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
[PATCH 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
[PATCH 16/24] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 20/24] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 21/24] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 22/24] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
[PATCH 23/24] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
[PATCH 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
drivers/pci/access.c | 36 ++++++++--------
drivers/pci/controller/dwc/pci-exynos.c | 4 +-
drivers/pci/controller/dwc/pci-keystone.c | 4 +-
drivers/pci/controller/dwc/pcie-histb.c | 4 +-
drivers/pci/controller/dwc/pcie-kirin.c | 4 +-
drivers/pci/controller/pci-aardvark.c | 10 +----
drivers/pci/controller/pci-hyperv.c | 2 +-
drivers/pci/controller/pci-mvebu.c | 8 +---
drivers/pci/controller/pci-thunder-ecam.c | 46 +++++++--------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
drivers/pci/controller/pci-xgene.c | 8 ++--
drivers/pci/controller/pcie-altera.c | 4 +-
drivers/pci/controller/pcie-iproc.c | 4 +-
drivers/pci/controller/pcie-mediatek.c | 11 +----
drivers/pci/controller/pcie-rcar-host.c | 4 +-
drivers/pci/controller/pcie-rockchip-host.c | 4 +-
drivers/pci/controller/vmd.c | 2 +-
drivers/pci/hotplug/cpqphp_ctrl.c | 4 +-
drivers/pci/hotplug/pciehp_hpc.c | 10 ++---
drivers/pci/pci.c | 10 ++---
drivers/pci/pcie/dpc.c | 4 +-
drivers/pci/pcie/pme.c | 4 +-
drivers/pci/probe.c | 10 ++---
include/linux/pci.h | 9 ++++
24 files changed, 87 insertions(+), 123 deletions(-)
--
2.25.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH v2 00/24] Unify PCI error response checking
@ 2021-10-15 14:35 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:35 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, linux-hyperv, linux-samsung-soc, Pali Rohár,
linux-rockchip, linux-pci, linuxppc-dev, linux-kernel,
linux-renesas-soc, linux-mediatek, linux-kernel-mentees,
linux-arm-kernel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
This patch series adds PCI_ERROR_RESPONSE definition and other helper
definition SET_PCI_ERROR_RESPONSE and RESPONSE_IS_PCI_ERROR and uses it
where appropriate to make these checks consistent and easier to find.
This helps unify PCI error response checking and make error check
consistent and easier to find.
This series also ensures that the error response fabrication now happens
in the PCI_OP_READ and PCI_USER_READ_CONFIG. This removes the
responsibility from controller drivers to do the error response setting.
Patch 1:
- Adds the PCI_ERROR_RESPONSE and other related defintions
- All other patches are dependent on this patch. This patch needs to
be applied first, before the others
Patch 2:
- Error fabrication happens in PCI_OP_READ and PCI_USER_READ_CONFIG
whenever the data read via the controller driver fails.
- This patch needs to be applied before, Patch 4/24 to Patch 15/24 are
applied.
Patch 3:
- Uses SET_PCI_ERROR_RESPONSE() when device is not found and
RESPONSE_IS_PCI_ERROR() to check hardware read from the hardware.
Patch 4 - 15:
- Removes redundant error fabrication that happens in controller
drivers when the read from a PCI device fails.
- These patches are dependent on Patch 2/24 of the series.
- These can be applied in any order.
Patch 16 - 22:
- Uses RESPONSE_IS_PCI_ERROR() to check the reads from hardware
- Patches can be applied in any order.
Patch 23 - 24:
- Edits the comments to include PCI_ERROR_RESPONSE alsong with
0xFFFFFFFF, so that it becomes easier to grep for faulty
hardware reads.
Changelog
=========
v2:
- Instead of using SET_PCI_ERROR_RESPONSE in all controller drivers
to fabricate error response, only use them in PCI_OP_READ and
PCI_USER_READ_CONFIG
Naveen Naidu (24):
[PATCH 1/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
[PATCH 2/24] PCI: Set error response in config access defines when ops->read() fails
[PATCH 3/24] PCI: Unify PCI error response checking
[PATCH 4/24] PCI: Remove redundant error fabrication when device read fails
[PATCH 5/24] PCI: thunder: Remove redundant error fabrication when device read fails
[PATCH 6/24] PCI: iproc: Remove redundant error fabrication when device read fails
[PATCH 7/24] PCI: mediatek: Remove redundant error fabrication when device read fails
[PATCH 8/24] PCI: exynos: Remove redundant error fabrication when device read fails
[PATCH 9/24] PCI: histb: Remove redundant error fabrication when device read fails
[PATCH 10/24] PCI: kirin: Remove redundant error fabrication when device read fails
[PATCH 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
[PATCH 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
[PATCH 13/24] PCI: altera: Remove redundant error fabrication when device read fails
[PATCH 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
[PATCH 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
[PATCH 16/24] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 20/24] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 21/24] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 22/24] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
[PATCH 23/24] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
[PATCH 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
drivers/pci/access.c | 36 ++++++++--------
drivers/pci/controller/dwc/pci-exynos.c | 4 +-
drivers/pci/controller/dwc/pci-keystone.c | 4 +-
drivers/pci/controller/dwc/pcie-histb.c | 4 +-
drivers/pci/controller/dwc/pcie-kirin.c | 4 +-
drivers/pci/controller/pci-aardvark.c | 10 +----
drivers/pci/controller/pci-hyperv.c | 2 +-
drivers/pci/controller/pci-mvebu.c | 8 +---
drivers/pci/controller/pci-thunder-ecam.c | 46 +++++++--------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
drivers/pci/controller/pci-xgene.c | 8 ++--
drivers/pci/controller/pcie-altera.c | 4 +-
drivers/pci/controller/pcie-iproc.c | 4 +-
drivers/pci/controller/pcie-mediatek.c | 11 +----
drivers/pci/controller/pcie-rcar-host.c | 4 +-
drivers/pci/controller/pcie-rockchip-host.c | 4 +-
drivers/pci/controller/vmd.c | 2 +-
drivers/pci/hotplug/cpqphp_ctrl.c | 4 +-
drivers/pci/hotplug/pciehp_hpc.c | 10 ++---
drivers/pci/pci.c | 10 ++---
drivers/pci/pcie/dpc.c | 4 +-
drivers/pci/pcie/pme.c | 4 +-
drivers/pci/probe.c | 10 ++---
include/linux/pci.h | 9 ++++
24 files changed, 87 insertions(+), 123 deletions(-)
--
2.25.1
_______________________________________________
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] 95+ messages in thread* [PATCH v2 00/24] Unify PCI error response checking
@ 2021-10-15 14:35 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:35 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, linux-hyperv, linux-samsung-soc, Pali Rohár,
linux-rockchip, linux-pci, linuxppc-dev, linux-kernel,
linux-renesas-soc, Naveen Naidu, linux-mediatek,
linux-kernel-mentees, linux-arm-kernel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
This patch series adds PCI_ERROR_RESPONSE definition and other helper
definition SET_PCI_ERROR_RESPONSE and RESPONSE_IS_PCI_ERROR and uses it
where appropriate to make these checks consistent and easier to find.
This helps unify PCI error response checking and make error check
consistent and easier to find.
This series also ensures that the error response fabrication now happens
in the PCI_OP_READ and PCI_USER_READ_CONFIG. This removes the
responsibility from controller drivers to do the error response setting.
Patch 1:
- Adds the PCI_ERROR_RESPONSE and other related defintions
- All other patches are dependent on this patch. This patch needs to
be applied first, before the others
Patch 2:
- Error fabrication happens in PCI_OP_READ and PCI_USER_READ_CONFIG
whenever the data read via the controller driver fails.
- This patch needs to be applied before, Patch 4/24 to Patch 15/24 are
applied.
Patch 3:
- Uses SET_PCI_ERROR_RESPONSE() when device is not found and
RESPONSE_IS_PCI_ERROR() to check hardware read from the hardware.
Patch 4 - 15:
- Removes redundant error fabrication that happens in controller
drivers when the read from a PCI device fails.
- These patches are dependent on Patch 2/24 of the series.
- These can be applied in any order.
Patch 16 - 22:
- Uses RESPONSE_IS_PCI_ERROR() to check the reads from hardware
- Patches can be applied in any order.
Patch 23 - 24:
- Edits the comments to include PCI_ERROR_RESPONSE alsong with
0xFFFFFFFF, so that it becomes easier to grep for faulty
hardware reads.
Changelog
=========
v2:
- Instead of using SET_PCI_ERROR_RESPONSE in all controller drivers
to fabricate error response, only use them in PCI_OP_READ and
PCI_USER_READ_CONFIG
Naveen Naidu (24):
[PATCH 1/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
[PATCH 2/24] PCI: Set error response in config access defines when ops->read() fails
[PATCH 3/24] PCI: Unify PCI error response checking
[PATCH 4/24] PCI: Remove redundant error fabrication when device read fails
[PATCH 5/24] PCI: thunder: Remove redundant error fabrication when device read fails
[PATCH 6/24] PCI: iproc: Remove redundant error fabrication when device read fails
[PATCH 7/24] PCI: mediatek: Remove redundant error fabrication when device read fails
[PATCH 8/24] PCI: exynos: Remove redundant error fabrication when device read fails
[PATCH 9/24] PCI: histb: Remove redundant error fabrication when device read fails
[PATCH 10/24] PCI: kirin: Remove redundant error fabrication when device read fails
[PATCH 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
[PATCH 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
[PATCH 13/24] PCI: altera: Remove redundant error fabrication when device read fails
[PATCH 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
[PATCH 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
[PATCH 16/24] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 20/24] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 21/24] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[PATCH 22/24] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
[PATCH 23/24] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
[PATCH 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
drivers/pci/access.c | 36 ++++++++--------
drivers/pci/controller/dwc/pci-exynos.c | 4 +-
drivers/pci/controller/dwc/pci-keystone.c | 4 +-
drivers/pci/controller/dwc/pcie-histb.c | 4 +-
drivers/pci/controller/dwc/pcie-kirin.c | 4 +-
drivers/pci/controller/pci-aardvark.c | 10 +----
drivers/pci/controller/pci-hyperv.c | 2 +-
drivers/pci/controller/pci-mvebu.c | 8 +---
drivers/pci/controller/pci-thunder-ecam.c | 46 +++++++--------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
drivers/pci/controller/pci-xgene.c | 8 ++--
drivers/pci/controller/pcie-altera.c | 4 +-
drivers/pci/controller/pcie-iproc.c | 4 +-
drivers/pci/controller/pcie-mediatek.c | 11 +----
drivers/pci/controller/pcie-rcar-host.c | 4 +-
drivers/pci/controller/pcie-rockchip-host.c | 4 +-
drivers/pci/controller/vmd.c | 2 +-
drivers/pci/hotplug/cpqphp_ctrl.c | 4 +-
drivers/pci/hotplug/pciehp_hpc.c | 10 ++---
drivers/pci/pci.c | 10 ++---
drivers/pci/pcie/dpc.c | 4 +-
drivers/pci/pcie/pme.c | 4 +-
drivers/pci/probe.c | 10 ++---
include/linux/pci.h | 9 ++++
24 files changed, 87 insertions(+), 123 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH v2 01/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:28 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:28 UTC (permalink / raw)
To: bhelgaas; +Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Add a PCI_ERROR_RESPONSE definition for that and use it where
appropriate to make these checks consistent and easier to find.
Also add helper definitions SET_PCI_ERROR_RESPONSE and
RESPONSE_IS_PCI_ERROR to make the code more readable.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
include/linux/pci.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index cd8aa6fce204..928c589bb5c4 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -154,6 +154,15 @@ enum pci_interrupt_pin {
/* The number of legacy PCI INTx interrupts */
#define PCI_NUM_INTX 4
+/*
+ * Reading from a device that doesn't respond typically returns ~0. A
+ * successful read from a device may also return ~0, so you need additional
+ * information to reliably identify errors.
+ */
+#define PCI_ERROR_RESPONSE (~0ULL)
+#define SET_PCI_ERROR_RESPONSE(val) (*val = ((typeof(*val)) PCI_ERROR_RESPONSE))
+#define RESPONSE_IS_PCI_ERROR(val) (*val == ((typeof(*val)) PCI_ERROR_RESPONSE))
+
/*
* pci_power_t values must match the bits in the Capabilities PME_Support
* and Control/Status PowerState fields in the Power Management capability.
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 01/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
@ 2021-10-15 14:28 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:28 UTC (permalink / raw)
To: bhelgaas; +Cc: linux-kernel-mentees, linux-kernel, linux-pci
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Add a PCI_ERROR_RESPONSE definition for that and use it where
appropriate to make these checks consistent and easier to find.
Also add helper definitions SET_PCI_ERROR_RESPONSE and
RESPONSE_IS_PCI_ERROR to make the code more readable.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
include/linux/pci.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index cd8aa6fce204..928c589bb5c4 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -154,6 +154,15 @@ enum pci_interrupt_pin {
/* The number of legacy PCI INTx interrupts */
#define PCI_NUM_INTX 4
+/*
+ * Reading from a device that doesn't respond typically returns ~0. A
+ * successful read from a device may also return ~0, so you need additional
+ * information to reliably identify errors.
+ */
+#define PCI_ERROR_RESPONSE (~0ULL)
+#define SET_PCI_ERROR_RESPONSE(val) (*val = ((typeof(*val)) PCI_ERROR_RESPONSE))
+#define RESPONSE_IS_PCI_ERROR(val) (*val == ((typeof(*val)) PCI_ERROR_RESPONSE))
+
/*
* pci_power_t values must match the bits in the Capabilities PME_Support
* and Control/Status PowerState fields in the Power Management capability.
--
2.25.1
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 01/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
2021-10-15 14:28 ` Naveen Naidu
@ 2021-10-20 13:24 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:24 UTC (permalink / raw)
To: Naveen Naidu; +Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel
On Fri, Oct 15, 2021 at 07:58:16PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Add a PCI_ERROR_RESPONSE definition for that and use it where
> appropriate to make these checks consistent and easier to find.
>
> Also add helper definitions SET_PCI_ERROR_RESPONSE and
> RESPONSE_IS_PCI_ERROR to make the code more readable.
>
> Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> include/linux/pci.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index cd8aa6fce204..928c589bb5c4 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -154,6 +154,15 @@ enum pci_interrupt_pin {
> /* The number of legacy PCI INTx interrupts */
> #define PCI_NUM_INTX 4
>
> +/*
> + * Reading from a device that doesn't respond typically returns ~0. A
> + * successful read from a device may also return ~0, so you need additional
> + * information to reliably identify errors.
> + */
> +#define PCI_ERROR_RESPONSE (~0ULL)
> +#define SET_PCI_ERROR_RESPONSE(val) (*val = ((typeof(*val)) PCI_ERROR_RESPONSE))
> +#define RESPONSE_IS_PCI_ERROR(val) (*val == ((typeof(*val)) PCI_ERROR_RESPONSE))
No reason for val to be a pointer.
Also, macro parameters need () around them. val could be an expression
like 'ptr + 1' which would blow up for example.
> +
> /*
> * pci_power_t values must match the bits in the Capabilities PME_Support
> * and Control/Status PowerState fields in the Power Management capability.
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 01/24] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
@ 2021-10-20 13:24 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:24 UTC (permalink / raw)
To: Naveen Naidu; +Cc: bhelgaas, linux-pci, linux-kernel-mentees, linux-kernel
On Fri, Oct 15, 2021 at 07:58:16PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Add a PCI_ERROR_RESPONSE definition for that and use it where
> appropriate to make these checks consistent and easier to find.
>
> Also add helper definitions SET_PCI_ERROR_RESPONSE and
> RESPONSE_IS_PCI_ERROR to make the code more readable.
>
> Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> include/linux/pci.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index cd8aa6fce204..928c589bb5c4 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -154,6 +154,15 @@ enum pci_interrupt_pin {
> /* The number of legacy PCI INTx interrupts */
> #define PCI_NUM_INTX 4
>
> +/*
> + * Reading from a device that doesn't respond typically returns ~0. A
> + * successful read from a device may also return ~0, so you need additional
> + * information to reliably identify errors.
> + */
> +#define PCI_ERROR_RESPONSE (~0ULL)
> +#define SET_PCI_ERROR_RESPONSE(val) (*val = ((typeof(*val)) PCI_ERROR_RESPONSE))
> +#define RESPONSE_IS_PCI_ERROR(val) (*val == ((typeof(*val)) PCI_ERROR_RESPONSE))
No reason for val to be a pointer.
Also, macro parameters need () around them. val could be an expression
like 'ptr + 1' which would blow up for example.
> +
> /*
> * pci_power_t values must match the bits in the Capabilities PME_Support
> * and Control/Status PowerState fields in the Power Management capability.
> --
> 2.25.1
>
>
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:28 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:28 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Rob Herring, Pali Rohár
Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
response (~0), when the PCI device read by a host controller fails.
This ensures that the controller drivers no longer need to fabricate
(~0) value when they detect error. It also gurantees that the error
response (~0) is always set when the controller drivers fails to read a
config register from a device.
This makes error response fabrication consistent and helps in removal of
a lot of repeated code.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/access.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 46935695cfb9..b3b2006ed1d2 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -42,7 +42,10 @@ int noinline pci_bus_read_config_##size \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
pci_lock_config(flags); \
res = bus->ops->read(bus, devfn, pos, len, &data); \
- *value = (type)data; \
+ if (res) \
+ SET_PCI_ERROR_RESPONSE(value); \
+ else \
+ *value = (type)data; \
pci_unlock_config(flags); \
return res; \
}
@@ -228,7 +231,10 @@ int pci_user_read_config_##size \
ret = dev->bus->ops->read(dev->bus, dev->devfn, \
pos, sizeof(type), &data); \
raw_spin_unlock_irq(&pci_lock); \
- *val = (type)data; \
+ if (ret) \
+ SET_PCI_ERROR_RESPONSE(val); \
+ else \
+ *val = (type)data; \
return pcibios_err_to_errno(ret); \
} \
EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
@ 2021-10-15 14:28 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:28 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, linux-kernel-mentees, linux-kernel, linux-pci,
Pali Rohár
Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
response (~0), when the PCI device read by a host controller fails.
This ensures that the controller drivers no longer need to fabricate
(~0) value when they detect error. It also gurantees that the error
response (~0) is always set when the controller drivers fails to read a
config register from a device.
This makes error response fabrication consistent and helps in removal of
a lot of repeated code.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/access.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 46935695cfb9..b3b2006ed1d2 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -42,7 +42,10 @@ int noinline pci_bus_read_config_##size \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
pci_lock_config(flags); \
res = bus->ops->read(bus, devfn, pos, len, &data); \
- *value = (type)data; \
+ if (res) \
+ SET_PCI_ERROR_RESPONSE(value); \
+ else \
+ *value = (type)data; \
pci_unlock_config(flags); \
return res; \
}
@@ -228,7 +231,10 @@ int pci_user_read_config_##size \
ret = dev->bus->ops->read(dev->bus, dev->devfn, \
pos, sizeof(type), &data); \
raw_spin_unlock_irq(&pci_lock); \
- *val = (type)data; \
+ if (ret) \
+ SET_PCI_ERROR_RESPONSE(val); \
+ else \
+ *val = (type)data; \
return pcibios_err_to_errno(ret); \
} \
EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* Re: [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
2021-10-15 14:28 ` Naveen Naidu
@ 2021-10-20 13:41 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:41 UTC (permalink / raw)
To: Naveen Naidu
Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel, Pali Rohár
On Fri, Oct 15, 2021 at 07:58:17PM +0530, Naveen Naidu wrote:
> Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
> response (~0), when the PCI device read by a host controller fails.
>
> This ensures that the controller drivers no longer need to fabricate
> (~0) value when they detect error. It also gurantees that the error
> response (~0) is always set when the controller drivers fails to read a
> config register from a device.
>
> This makes error response fabrication consistent and helps in removal of
> a lot of repeated code.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
@ 2021-10-20 13:41 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:41 UTC (permalink / raw)
To: Naveen Naidu
Cc: bhelgaas, linux-pci, Pali Rohár, linux-kernel-mentees, linux-kernel
On Fri, Oct 15, 2021 at 07:58:17PM +0530, Naveen Naidu wrote:
> Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
> response (~0), when the PCI device read by a host controller fails.
>
> This ensures that the controller drivers no longer need to fabricate
> (~0) value when they detect error. It also gurantees that the error
> response (~0) is always set when the controller drivers fails to read a
> config register from a device.
>
> This makes error response fabrication consistent and helps in removal of
> a lot of repeated code.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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] 95+ messages in thread
* Re: [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
2021-10-15 14:28 ` Naveen Naidu
@ 2021-10-20 13:52 ` Pali Rohár
-1 siblings, 0 replies; 95+ messages in thread
From: Pali Rohár @ 2021-10-20 13:52 UTC (permalink / raw)
To: Naveen Naidu
Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel, Rob Herring
On Friday 15 October 2021 19:58:17 Naveen Naidu wrote:
> Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
> response (~0), when the PCI device read by a host controller fails.
>
> This ensures that the controller drivers no longer need to fabricate
> (~0) value when they detect error. It also gurantees that the error
> response (~0) is always set when the controller drivers fails to read a
> config register from a device.
>
> This makes error response fabrication consistent and helps in removal of
> a lot of repeated code.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> index 46935695cfb9..b3b2006ed1d2 100644
> --- a/drivers/pci/access.c
> +++ b/drivers/pci/access.c
> @@ -42,7 +42,10 @@ int noinline pci_bus_read_config_##size \
> if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
> pci_lock_config(flags); \
> res = bus->ops->read(bus, devfn, pos, len, &data); \
> - *value = (type)data; \
> + if (res) \
> + SET_PCI_ERROR_RESPONSE(value); \
> + else \
> + *value = (type)data; \
Hello! Just one small comment. It looks like that in this patch is
broken alignment of backslashes on the end of lines. Prior this patch
backslashes on all lines were at the same column. With this patch they
are not.
> pci_unlock_config(flags); \
> return res; \
> }
> @@ -228,7 +231,10 @@ int pci_user_read_config_##size \
> ret = dev->bus->ops->read(dev->bus, dev->devfn, \
> pos, sizeof(type), &data); \
> raw_spin_unlock_irq(&pci_lock); \
> - *val = (type)data; \
> + if (ret) \
> + SET_PCI_ERROR_RESPONSE(val); \
> + else \
> + *val = (type)data; \
> return pcibios_err_to_errno(ret); \
> } \
> EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
@ 2021-10-20 13:52 ` Pali Rohár
0 siblings, 0 replies; 95+ messages in thread
From: Pali Rohár @ 2021-10-20 13:52 UTC (permalink / raw)
To: Naveen Naidu
Cc: bhelgaas, linux-pci, linux-kernel-mentees, linux-kernel, Rob Herring
On Friday 15 October 2021 19:58:17 Naveen Naidu wrote:
> Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
> response (~0), when the PCI device read by a host controller fails.
>
> This ensures that the controller drivers no longer need to fabricate
> (~0) value when they detect error. It also gurantees that the error
> response (~0) is always set when the controller drivers fails to read a
> config register from a device.
>
> This makes error response fabrication consistent and helps in removal of
> a lot of repeated code.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> index 46935695cfb9..b3b2006ed1d2 100644
> --- a/drivers/pci/access.c
> +++ b/drivers/pci/access.c
> @@ -42,7 +42,10 @@ int noinline pci_bus_read_config_##size \
> if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
> pci_lock_config(flags); \
> res = bus->ops->read(bus, devfn, pos, len, &data); \
> - *value = (type)data; \
> + if (res) \
> + SET_PCI_ERROR_RESPONSE(value); \
> + else \
> + *value = (type)data; \
Hello! Just one small comment. It looks like that in this patch is
broken alignment of backslashes on the end of lines. Prior this patch
backslashes on all lines were at the same column. With this patch they
are not.
> pci_unlock_config(flags); \
> return res; \
> }
> @@ -228,7 +231,10 @@ int pci_user_read_config_##size \
> ret = dev->bus->ops->read(dev->bus, dev->devfn, \
> pos, sizeof(type), &data); \
> raw_spin_unlock_irq(&pci_lock); \
> - *val = (type)data; \
> + if (ret) \
> + SET_PCI_ERROR_RESPONSE(val); \
> + else \
> + *val = (type)data; \
> return pcibios_err_to_errno(ret); \
> } \
> EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
> --
> 2.25.1
>
_______________________________________________
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] 95+ messages in thread
* Re: [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
2021-10-20 13:52 ` Pali Rohár
@ 2021-10-20 15:13 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-20 15:13 UTC (permalink / raw)
To: Pali Rohár
Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel, Rob Herring
On 20/10, Pali Rohár wrote:
> On Friday 15 October 2021 19:58:17 Naveen Naidu wrote:
> > Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
> > response (~0), when the PCI device read by a host controller fails.
> >
> > This ensures that the controller drivers no longer need to fabricate
> > (~0) value when they detect error. It also gurantees that the error
> > response (~0) is always set when the controller drivers fails to read a
> > config register from a device.
> >
> > This makes error response fabrication consistent and helps in removal of
> > a lot of repeated code.
> >
> > Suggested-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> > ---
> > drivers/pci/access.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> > index 46935695cfb9..b3b2006ed1d2 100644
> > --- a/drivers/pci/access.c
> > +++ b/drivers/pci/access.c
> > @@ -42,7 +42,10 @@ int noinline pci_bus_read_config_##size \
> > if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
> > pci_lock_config(flags); \
> > res = bus->ops->read(bus, devfn, pos, len, &data); \
> > - *value = (type)data; \
> > + if (res) \
> > + SET_PCI_ERROR_RESPONSE(value); \
> > + else \
> > + *value = (type)data; \
>
> Hello! Just one small comment. It looks like that in this patch is
> broken alignment of backslashes on the end of lines. Prior this patch
> backslashes on all lines were at the same column. With this patch they
> are not.
>
Thank you for spotting this. I apologise for this. I did not configure
my editor properlly so I couldn't recognize this error. But I'll fix
this when I send the v3
> > pci_unlock_config(flags); \
> > return res; \
> > }
> > @@ -228,7 +231,10 @@ int pci_user_read_config_##size \
> > ret = dev->bus->ops->read(dev->bus, dev->devfn, \
> > pos, sizeof(type), &data); \
> > raw_spin_unlock_irq(&pci_lock); \
> > - *val = (type)data; \
> > + if (ret) \
> > + SET_PCI_ERROR_RESPONSE(val); \
> > + else \
> > + *val = (type)data; \
> > return pcibios_err_to_errno(ret); \
> > } \
> > EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
> > --
> > 2.25.1
> >
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v2 02/24] PCI: Set error response in config access defines when ops->read() fails
@ 2021-10-20 15:13 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-20 15:13 UTC (permalink / raw)
To: Pali Rohár
Cc: bhelgaas, linux-pci, linux-kernel-mentees, linux-kernel, Rob Herring
On 20/10, Pali Rohár wrote:
> On Friday 15 October 2021 19:58:17 Naveen Naidu wrote:
> > Make PCI_OP_READ and PCI_USER_READ_CONFIG set the data value with error
> > response (~0), when the PCI device read by a host controller fails.
> >
> > This ensures that the controller drivers no longer need to fabricate
> > (~0) value when they detect error. It also gurantees that the error
> > response (~0) is always set when the controller drivers fails to read a
> > config register from a device.
> >
> > This makes error response fabrication consistent and helps in removal of
> > a lot of repeated code.
> >
> > Suggested-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> > ---
> > drivers/pci/access.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> > index 46935695cfb9..b3b2006ed1d2 100644
> > --- a/drivers/pci/access.c
> > +++ b/drivers/pci/access.c
> > @@ -42,7 +42,10 @@ int noinline pci_bus_read_config_##size \
> > if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
> > pci_lock_config(flags); \
> > res = bus->ops->read(bus, devfn, pos, len, &data); \
> > - *value = (type)data; \
> > + if (res) \
> > + SET_PCI_ERROR_RESPONSE(value); \
> > + else \
> > + *value = (type)data; \
>
> Hello! Just one small comment. It looks like that in this patch is
> broken alignment of backslashes on the end of lines. Prior this patch
> backslashes on all lines were at the same column. With this patch they
> are not.
>
Thank you for spotting this. I apologise for this. I did not configure
my editor properlly so I couldn't recognize this error. But I'll fix
this when I send the v3
> > pci_unlock_config(flags); \
> > return res; \
> > }
> > @@ -228,7 +231,10 @@ int pci_user_read_config_##size \
> > ret = dev->bus->ops->read(dev->bus, dev->devfn, \
> > pos, sizeof(type), &data); \
> > raw_spin_unlock_irq(&pci_lock); \
> > - *val = (type)data; \
> > + if (ret) \
> > + SET_PCI_ERROR_RESPONSE(val); \
> > + else \
> > + *val = (type)data; \
> > return pcibios_err_to_errno(ret); \
> > } \
> > EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
> > --
> > 2.25.1
> >
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 03/24] PCI: Unify PCI error response checking
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas; +Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use SET_PCI_ERROR_RESPONSE() to set the error response and
RESPONSE_IS_PCI_ERROR() to check the error response during hardware
read.
These definitions make error checks consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/access.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index b3b2006ed1d2..03712866c818 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -417,10 +417,10 @@ int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
ret = pci_read_config_word(dev, pci_pcie_cap(dev) + pos, val);
/*
* Reset *val to 0 if pci_read_config_word() fails, it may
- * have been written as 0xFFFF if hardware error happens
- * during pci_read_config_word().
+ * have been written as 0xFFFF (PCI_ERROR_RESPONSE) if hardware error
+ * happens during pci_read_config_word().
*/
- if (ret)
+ if (RESPONSE_IS_PCI_ERROR(val))
*val = 0;
return ret;
}
@@ -452,10 +452,10 @@ int pcie_capability_read_dword(struct pci_dev *dev, int pos, u32 *val)
ret = pci_read_config_dword(dev, pci_pcie_cap(dev) + pos, val);
/*
* Reset *val to 0 if pci_read_config_dword() fails, it may
- * have been written as 0xFFFFFFFF if hardware error happens
- * during pci_read_config_dword().
+ * have been written as 0xFFFFFFFF (PCI_ERROR_RESPONSE) if hardware
+ * error happens during pci_read_config_dword().
*/
- if (ret)
+ if (RESPONSE_IS_PCI_ERROR(val))
*val = 0;
return ret;
}
@@ -529,7 +529,7 @@ EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
{
if (pci_dev_is_disconnected(dev)) {
- *val = ~0;
+ SET_PCI_ERROR_RESPONSE(val);
return PCIBIOS_DEVICE_NOT_FOUND;
}
return pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
@@ -539,7 +539,7 @@ EXPORT_SYMBOL(pci_read_config_byte);
int pci_read_config_word(const struct pci_dev *dev, int where, u16 *val)
{
if (pci_dev_is_disconnected(dev)) {
- *val = ~0;
+ SET_PCI_ERROR_RESPONSE(val);
return PCIBIOS_DEVICE_NOT_FOUND;
}
return pci_bus_read_config_word(dev->bus, dev->devfn, where, val);
@@ -550,7 +550,7 @@ int pci_read_config_dword(const struct pci_dev *dev, int where,
u32 *val)
{
if (pci_dev_is_disconnected(dev)) {
- *val = ~0;
+ SET_PCI_ERROR_RESPONSE(val);
return PCIBIOS_DEVICE_NOT_FOUND;
}
return pci_bus_read_config_dword(dev->bus, dev->devfn, where, val);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 03/24] PCI: Unify PCI error response checking
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas; +Cc: linux-kernel-mentees, linux-kernel, linux-pci
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use SET_PCI_ERROR_RESPONSE() to set the error response and
RESPONSE_IS_PCI_ERROR() to check the error response during hardware
read.
These definitions make error checks consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/access.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index b3b2006ed1d2..03712866c818 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -417,10 +417,10 @@ int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
ret = pci_read_config_word(dev, pci_pcie_cap(dev) + pos, val);
/*
* Reset *val to 0 if pci_read_config_word() fails, it may
- * have been written as 0xFFFF if hardware error happens
- * during pci_read_config_word().
+ * have been written as 0xFFFF (PCI_ERROR_RESPONSE) if hardware error
+ * happens during pci_read_config_word().
*/
- if (ret)
+ if (RESPONSE_IS_PCI_ERROR(val))
*val = 0;
return ret;
}
@@ -452,10 +452,10 @@ int pcie_capability_read_dword(struct pci_dev *dev, int pos, u32 *val)
ret = pci_read_config_dword(dev, pci_pcie_cap(dev) + pos, val);
/*
* Reset *val to 0 if pci_read_config_dword() fails, it may
- * have been written as 0xFFFFFFFF if hardware error happens
- * during pci_read_config_dword().
+ * have been written as 0xFFFFFFFF (PCI_ERROR_RESPONSE) if hardware
+ * error happens during pci_read_config_dword().
*/
- if (ret)
+ if (RESPONSE_IS_PCI_ERROR(val))
*val = 0;
return ret;
}
@@ -529,7 +529,7 @@ EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
{
if (pci_dev_is_disconnected(dev)) {
- *val = ~0;
+ SET_PCI_ERROR_RESPONSE(val);
return PCIBIOS_DEVICE_NOT_FOUND;
}
return pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
@@ -539,7 +539,7 @@ EXPORT_SYMBOL(pci_read_config_byte);
int pci_read_config_word(const struct pci_dev *dev, int where, u16 *val)
{
if (pci_dev_is_disconnected(dev)) {
- *val = ~0;
+ SET_PCI_ERROR_RESPONSE(val);
return PCIBIOS_DEVICE_NOT_FOUND;
}
return pci_bus_read_config_word(dev->bus, dev->devfn, where, val);
@@ -550,7 +550,7 @@ int pci_read_config_dword(const struct pci_dev *dev, int where,
u32 *val)
{
if (pci_dev_is_disconnected(dev)) {
- *val = ~0;
+ SET_PCI_ERROR_RESPONSE(val);
return PCIBIOS_DEVICE_NOT_FOUND;
}
return pci_bus_read_config_dword(dev->bus, dev->devfn, where, val);
--
2.25.1
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 03/24] PCI: Unify PCI error response checking
2021-10-15 14:38 ` Naveen Naidu
@ 2021-10-20 13:13 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:13 UTC (permalink / raw)
To: Naveen Naidu; +Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel
On Fri, Oct 15, 2021 at 08:08:44PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Use SET_PCI_ERROR_RESPONSE() to set the error response and
> RESPONSE_IS_PCI_ERROR() to check the error response during hardware
> read.
>
> These definitions make error checks consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> index b3b2006ed1d2..03712866c818 100644
> --- a/drivers/pci/access.c
> +++ b/drivers/pci/access.c
> @@ -417,10 +417,10 @@ int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
> ret = pci_read_config_word(dev, pci_pcie_cap(dev) + pos, val);
> /*
> * Reset *val to 0 if pci_read_config_word() fails, it may
> - * have been written as 0xFFFF if hardware error happens
> - * during pci_read_config_word().
> + * have been written as 0xFFFF (PCI_ERROR_RESPONSE) if hardware error
> + * happens during pci_read_config_word().
> */
> - if (ret)
> + if (RESPONSE_IS_PCI_ERROR(val))
What if there is no error (in ret) and the register value was actually
~0? We'd be corrupting the value.
In general, I think we should rely more on the error codes and less on
the ~0 value.
> *val = 0;
> return ret;
> }
> @@ -452,10 +452,10 @@ int pcie_capability_read_dword(struct pci_dev *dev, int pos, u32 *val)
> ret = pci_read_config_dword(dev, pci_pcie_cap(dev) + pos, val);
> /*
> * Reset *val to 0 if pci_read_config_dword() fails, it may
> - * have been written as 0xFFFFFFFF if hardware error happens
> - * during pci_read_config_dword().
> + * have been written as 0xFFFFFFFF (PCI_ERROR_RESPONSE) if hardware
> + * error happens during pci_read_config_dword().
> */
> - if (ret)
> + if (RESPONSE_IS_PCI_ERROR(val))
> *val = 0;
> return ret;
> }
> @@ -529,7 +529,7 @@ EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
> int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
> {
> if (pci_dev_is_disconnected(dev)) {
> - *val = ~0;
> + SET_PCI_ERROR_RESPONSE(val);
> return PCIBIOS_DEVICE_NOT_FOUND;
> }
> return pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
> @@ -539,7 +539,7 @@ EXPORT_SYMBOL(pci_read_config_byte);
> int pci_read_config_word(const struct pci_dev *dev, int where, u16 *val)
> {
> if (pci_dev_is_disconnected(dev)) {
> - *val = ~0;
> + SET_PCI_ERROR_RESPONSE(val);
> return PCIBIOS_DEVICE_NOT_FOUND;
> }
> return pci_bus_read_config_word(dev->bus, dev->devfn, where, val);
> @@ -550,7 +550,7 @@ int pci_read_config_dword(const struct pci_dev *dev, int where,
> u32 *val)
> {
> if (pci_dev_is_disconnected(dev)) {
> - *val = ~0;
> + SET_PCI_ERROR_RESPONSE(val);
> return PCIBIOS_DEVICE_NOT_FOUND;
> }
> return pci_bus_read_config_dword(dev->bus, dev->devfn, where, val);
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 03/24] PCI: Unify PCI error response checking
@ 2021-10-20 13:13 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:13 UTC (permalink / raw)
To: Naveen Naidu; +Cc: bhelgaas, linux-pci, linux-kernel-mentees, linux-kernel
On Fri, Oct 15, 2021 at 08:08:44PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Use SET_PCI_ERROR_RESPONSE() to set the error response and
> RESPONSE_IS_PCI_ERROR() to check the error response during hardware
> read.
>
> These definitions make error checks consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> index b3b2006ed1d2..03712866c818 100644
> --- a/drivers/pci/access.c
> +++ b/drivers/pci/access.c
> @@ -417,10 +417,10 @@ int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
> ret = pci_read_config_word(dev, pci_pcie_cap(dev) + pos, val);
> /*
> * Reset *val to 0 if pci_read_config_word() fails, it may
> - * have been written as 0xFFFF if hardware error happens
> - * during pci_read_config_word().
> + * have been written as 0xFFFF (PCI_ERROR_RESPONSE) if hardware error
> + * happens during pci_read_config_word().
> */
> - if (ret)
> + if (RESPONSE_IS_PCI_ERROR(val))
What if there is no error (in ret) and the register value was actually
~0? We'd be corrupting the value.
In general, I think we should rely more on the error codes and less on
the ~0 value.
> *val = 0;
> return ret;
> }
> @@ -452,10 +452,10 @@ int pcie_capability_read_dword(struct pci_dev *dev, int pos, u32 *val)
> ret = pci_read_config_dword(dev, pci_pcie_cap(dev) + pos, val);
> /*
> * Reset *val to 0 if pci_read_config_dword() fails, it may
> - * have been written as 0xFFFFFFFF if hardware error happens
> - * during pci_read_config_dword().
> + * have been written as 0xFFFFFFFF (PCI_ERROR_RESPONSE) if hardware
> + * error happens during pci_read_config_dword().
> */
> - if (ret)
> + if (RESPONSE_IS_PCI_ERROR(val))
> *val = 0;
> return ret;
> }
> @@ -529,7 +529,7 @@ EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
> int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
> {
> if (pci_dev_is_disconnected(dev)) {
> - *val = ~0;
> + SET_PCI_ERROR_RESPONSE(val);
> return PCIBIOS_DEVICE_NOT_FOUND;
> }
> return pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
> @@ -539,7 +539,7 @@ EXPORT_SYMBOL(pci_read_config_byte);
> int pci_read_config_word(const struct pci_dev *dev, int where, u16 *val)
> {
> if (pci_dev_is_disconnected(dev)) {
> - *val = ~0;
> + SET_PCI_ERROR_RESPONSE(val);
> return PCIBIOS_DEVICE_NOT_FOUND;
> }
> return pci_bus_read_config_word(dev->bus, dev->devfn, where, val);
> @@ -550,7 +550,7 @@ int pci_read_config_dword(const struct pci_dev *dev, int where,
> u32 *val)
> {
> if (pci_dev_is_disconnected(dev)) {
> - *val = ~0;
> + SET_PCI_ERROR_RESPONSE(val);
> return PCIBIOS_DEVICE_NOT_FOUND;
> }
> return pci_bus_read_config_dword(dev->bus, dev->devfn, where, val);
> --
> 2.25.1
>
>
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 03/24] PCI: Unify PCI error response checking
2021-10-20 13:13 ` Rob Herring
@ 2021-10-20 15:15 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-20 15:15 UTC (permalink / raw)
To: Rob Herring; +Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel
On 20/10, Rob Herring wrote:
> On Fri, Oct 15, 2021 at 08:08:44PM +0530, Naveen Naidu wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> >
> > Use SET_PCI_ERROR_RESPONSE() to set the error response and
> > RESPONSE_IS_PCI_ERROR() to check the error response during hardware
> > read.
> >
> > These definitions make error checks consistent and easier to find.
> >
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> > ---
> > drivers/pci/access.c | 18 +++++++++---------
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> > index b3b2006ed1d2..03712866c818 100644
> > --- a/drivers/pci/access.c
> > +++ b/drivers/pci/access.c
> > @@ -417,10 +417,10 @@ int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
> > ret = pci_read_config_word(dev, pci_pcie_cap(dev) + pos, val);
> > /*
> > * Reset *val to 0 if pci_read_config_word() fails, it may
> > - * have been written as 0xFFFF if hardware error happens
> > - * during pci_read_config_word().
> > + * have been written as 0xFFFF (PCI_ERROR_RESPONSE) if hardware error
> > + * happens during pci_read_config_word().
> > */
> > - if (ret)
> > + if (RESPONSE_IS_PCI_ERROR(val))
>
> What if there is no error (in ret) and the register value was actually
> ~0? We'd be corrupting the value.
>
> In general, I think we should rely more on the error codes and less on
> the ~0 value.
>
Thank you for the review. I'll fix this up when I send v3 for this patch
series.
> > *val = 0;
> > return ret;
> > }
> > @@ -452,10 +452,10 @@ int pcie_capability_read_dword(struct pci_dev *dev, int pos, u32 *val)
> > ret = pci_read_config_dword(dev, pci_pcie_cap(dev) + pos, val);
> > /*
> > * Reset *val to 0 if pci_read_config_dword() fails, it may
> > - * have been written as 0xFFFFFFFF if hardware error happens
> > - * during pci_read_config_dword().
> > + * have been written as 0xFFFFFFFF (PCI_ERROR_RESPONSE) if hardware
> > + * error happens during pci_read_config_dword().
> > */
> > - if (ret)
> > + if (RESPONSE_IS_PCI_ERROR(val))
> > *val = 0;
> > return ret;
> > }
> > @@ -529,7 +529,7 @@ EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
> > int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
> > {
> > if (pci_dev_is_disconnected(dev)) {
> > - *val = ~0;
> > + SET_PCI_ERROR_RESPONSE(val);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > return pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
> > @@ -539,7 +539,7 @@ EXPORT_SYMBOL(pci_read_config_byte);
> > int pci_read_config_word(const struct pci_dev *dev, int where, u16 *val)
> > {
> > if (pci_dev_is_disconnected(dev)) {
> > - *val = ~0;
> > + SET_PCI_ERROR_RESPONSE(val);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > return pci_bus_read_config_word(dev->bus, dev->devfn, where, val);
> > @@ -550,7 +550,7 @@ int pci_read_config_dword(const struct pci_dev *dev, int where,
> > u32 *val)
> > {
> > if (pci_dev_is_disconnected(dev)) {
> > - *val = ~0;
> > + SET_PCI_ERROR_RESPONSE(val);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > return pci_bus_read_config_dword(dev->bus, dev->devfn, where, val);
> > --
> > 2.25.1
> >
> >
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 03/24] PCI: Unify PCI error response checking
@ 2021-10-20 15:15 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-20 15:15 UTC (permalink / raw)
To: Rob Herring; +Cc: bhelgaas, linux-pci, linux-kernel-mentees, linux-kernel
On 20/10, Rob Herring wrote:
> On Fri, Oct 15, 2021 at 08:08:44PM +0530, Naveen Naidu wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> >
> > Use SET_PCI_ERROR_RESPONSE() to set the error response and
> > RESPONSE_IS_PCI_ERROR() to check the error response during hardware
> > read.
> >
> > These definitions make error checks consistent and easier to find.
> >
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> > ---
> > drivers/pci/access.c | 18 +++++++++---------
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> > index b3b2006ed1d2..03712866c818 100644
> > --- a/drivers/pci/access.c
> > +++ b/drivers/pci/access.c
> > @@ -417,10 +417,10 @@ int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
> > ret = pci_read_config_word(dev, pci_pcie_cap(dev) + pos, val);
> > /*
> > * Reset *val to 0 if pci_read_config_word() fails, it may
> > - * have been written as 0xFFFF if hardware error happens
> > - * during pci_read_config_word().
> > + * have been written as 0xFFFF (PCI_ERROR_RESPONSE) if hardware error
> > + * happens during pci_read_config_word().
> > */
> > - if (ret)
> > + if (RESPONSE_IS_PCI_ERROR(val))
>
> What if there is no error (in ret) and the register value was actually
> ~0? We'd be corrupting the value.
>
> In general, I think we should rely more on the error codes and less on
> the ~0 value.
>
Thank you for the review. I'll fix this up when I send v3 for this patch
series.
> > *val = 0;
> > return ret;
> > }
> > @@ -452,10 +452,10 @@ int pcie_capability_read_dword(struct pci_dev *dev, int pos, u32 *val)
> > ret = pci_read_config_dword(dev, pci_pcie_cap(dev) + pos, val);
> > /*
> > * Reset *val to 0 if pci_read_config_dword() fails, it may
> > - * have been written as 0xFFFFFFFF if hardware error happens
> > - * during pci_read_config_dword().
> > + * have been written as 0xFFFFFFFF (PCI_ERROR_RESPONSE) if hardware
> > + * error happens during pci_read_config_dword().
> > */
> > - if (ret)
> > + if (RESPONSE_IS_PCI_ERROR(val))
> > *val = 0;
> > return ret;
> > }
> > @@ -529,7 +529,7 @@ EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
> > int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
> > {
> > if (pci_dev_is_disconnected(dev)) {
> > - *val = ~0;
> > + SET_PCI_ERROR_RESPONSE(val);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > return pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
> > @@ -539,7 +539,7 @@ EXPORT_SYMBOL(pci_read_config_byte);
> > int pci_read_config_word(const struct pci_dev *dev, int where, u16 *val)
> > {
> > if (pci_dev_is_disconnected(dev)) {
> > - *val = ~0;
> > + SET_PCI_ERROR_RESPONSE(val);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > return pci_bus_read_config_word(dev->bus, dev->devfn, where, val);
> > @@ -550,7 +550,7 @@ int pci_read_config_dword(const struct pci_dev *dev, int where,
> > u32 *val)
> > {
> > if (pci_dev_is_disconnected(dev)) {
> > - *val = ~0;
> > + SET_PCI_ERROR_RESPONSE(val);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> > return pci_bus_read_config_dword(dev->bus, dev->devfn, where, val);
> > --
> > 2.25.1
> >
> >
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 04/24] PCI: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas; +Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/access.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 03712866c818..37258af87b0e 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -83,10 +83,8 @@ int pci_generic_config_read(struct pci_bus *bus, unsigned int devfn,
void __iomem *addr;
addr = bus->ops->map_bus(bus, devfn, where);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (size == 1)
*val = readb(addr);
@@ -125,10 +123,8 @@ int pci_generic_config_read32(struct pci_bus *bus, unsigned int devfn,
void __iomem *addr;
addr = bus->ops->map_bus(bus, devfn, where & ~0x3);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = readl(addr);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 04/24] PCI: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas; +Cc: linux-kernel-mentees, linux-kernel, linux-pci
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/access.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 03712866c818..37258af87b0e 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -83,10 +83,8 @@ int pci_generic_config_read(struct pci_bus *bus, unsigned int devfn,
void __iomem *addr;
addr = bus->ops->map_bus(bus, devfn, where);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (size == 1)
*val = readb(addr);
@@ -125,10 +123,8 @@ int pci_generic_config_read32(struct pci_bus *bus, unsigned int devfn,
void __iomem *addr;
addr = bus->ops->map_bus(bus, devfn, where & ~0x3);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = readl(addr);
--
2.25.1
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 04/24] PCI: Remove redundant error fabrication when device read fails
2021-10-15 14:38 ` Naveen Naidu
@ 2021-10-20 13:42 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:42 UTC (permalink / raw)
To: Naveen Naidu; +Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel
On Fri, Oct 15, 2021 at 08:08:45PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> The host controller drivers sets the error response values (~0) and
> returns an error when faulty hardware read occurs. But the error
> response value (~0) is already being set in PCI_OP_READ and
> PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
>
> Thus, it's no longer necessary for the host controller drivers to
> fabricate any error response.
>
> This helps unify PCI error response checking and make error check
> consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v2 04/24] PCI: Remove redundant error fabrication when device read fails
@ 2021-10-20 13:42 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-10-20 13:42 UTC (permalink / raw)
To: Naveen Naidu; +Cc: bhelgaas, linux-pci, linux-kernel-mentees, linux-kernel
On Fri, Oct 15, 2021 at 08:08:45PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> The host controller drivers sets the error response values (~0) and
> returns an error when faulty hardware read occurs. But the error
> response value (~0) is already being set in PCI_OP_READ and
> PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
>
> Thus, it's no longer necessary for the host controller drivers to
> fabricate any error response.
>
> This helps unify PCI error response checking and make error check
> consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/access.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 05/24] PCI: thunder: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
(?)
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Robert Richter, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński,
moderated list:PCIE DRIVER FOR CAVIUM THUNDERX
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-thunder-ecam.c | 46 ++++++++---------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
2 files changed, 17 insertions(+), 33 deletions(-)
diff --git a/drivers/pci/controller/pci-thunder-ecam.c b/drivers/pci/controller/pci-thunder-ecam.c
index ffd84656544f..a95bb58afd52 100644
--- a/drivers/pci/controller/pci-thunder-ecam.c
+++ b/drivers/pci/controller/pci-thunder-ecam.c
@@ -41,10 +41,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
}
if (where_a == 0x4) {
addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
v &= ~0xf;
v |= 2; /* EA entry-1. Base-L */
@@ -56,10 +55,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
u32 barl_rb;
addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
barl_orig = readl(addr + 0);
writel(0xffffffff, addr + 0);
barl_rb = readl(addr + 0);
@@ -72,10 +70,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
}
if (where_a == 0xc) {
addr = bus->ops->map_bus(bus, devfn, bar + 4); /* BAR 1 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr); /* EA entry-3. Base-H */
set_val(v, where, size, val);
return PCIBIOS_SUCCESSFUL;
@@ -104,10 +101,8 @@ static int thunder_ecam_p2_config_read(struct pci_bus *bus, unsigned int devfn,
}
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
v = readl(addr);
@@ -135,10 +130,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
int where_a = where & ~3;
addr = bus->ops->map_bus(bus, devfn, 0xc);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
v = readl(addr);
@@ -146,10 +139,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
cfg_type = (v >> 16) & 0x7f;
addr = bus->ops->map_bus(bus, devfn, 8);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
class_rev = readl(addr);
if (class_rev == 0xffffffff)
@@ -176,10 +167,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
}
addr = bus->ops->map_bus(bus, devfn, 0);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
vendor_device = readl(addr);
if (vendor_device == 0xffffffff)
@@ -196,10 +185,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
bool is_tns = (vendor_device == 0xa01f177d);
addr = bus->ops->map_bus(bus, devfn, 0x70);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
/* E_CAP */
v = readl(addr);
has_msix = (v & 0xff00) != 0;
@@ -211,10 +199,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
}
if (where_a == 0xb0) {
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
if (v & 0xff00)
pr_err("Bad MSIX cap header: %08x\n", v);
@@ -268,10 +255,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
if (where_a == 0x70) {
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
if (v & 0xff00)
pr_err("Bad PCIe cap header: %08x\n", v);
diff --git a/drivers/pci/controller/pci-thunder-pem.c b/drivers/pci/controller/pci-thunder-pem.c
index 0660b9da204f..06a9855cb431 100644
--- a/drivers/pci/controller/pci-thunder-pem.c
+++ b/drivers/pci/controller/pci-thunder-pem.c
@@ -41,10 +41,8 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
struct pci_config_window *cfg = bus->sysdata;
struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
- if (devfn != 0 || where >= 2048) {
- *val = ~0;
+ if (devfn != 0 || where >= 2048)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/*
* 32-bit accesses only. Write the address to the low order
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 05/24] PCI: thunder: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Robert Richter, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński,
moderated list:PCIE DRIVER FOR CAVIUM THUNDERX
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-thunder-ecam.c | 46 ++++++++---------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
2 files changed, 17 insertions(+), 33 deletions(-)
diff --git a/drivers/pci/controller/pci-thunder-ecam.c b/drivers/pci/controller/pci-thunder-ecam.c
index ffd84656544f..a95bb58afd52 100644
--- a/drivers/pci/controller/pci-thunder-ecam.c
+++ b/drivers/pci/controller/pci-thunder-ecam.c
@@ -41,10 +41,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
}
if (where_a == 0x4) {
addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
v &= ~0xf;
v |= 2; /* EA entry-1. Base-L */
@@ -56,10 +55,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
u32 barl_rb;
addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
barl_orig = readl(addr + 0);
writel(0xffffffff, addr + 0);
barl_rb = readl(addr + 0);
@@ -72,10 +70,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
}
if (where_a == 0xc) {
addr = bus->ops->map_bus(bus, devfn, bar + 4); /* BAR 1 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr); /* EA entry-3. Base-H */
set_val(v, where, size, val);
return PCIBIOS_SUCCESSFUL;
@@ -104,10 +101,8 @@ static int thunder_ecam_p2_config_read(struct pci_bus *bus, unsigned int devfn,
}
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
v = readl(addr);
@@ -135,10 +130,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
int where_a = where & ~3;
addr = bus->ops->map_bus(bus, devfn, 0xc);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
v = readl(addr);
@@ -146,10 +139,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
cfg_type = (v >> 16) & 0x7f;
addr = bus->ops->map_bus(bus, devfn, 8);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
class_rev = readl(addr);
if (class_rev == 0xffffffff)
@@ -176,10 +167,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
}
addr = bus->ops->map_bus(bus, devfn, 0);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
vendor_device = readl(addr);
if (vendor_device == 0xffffffff)
@@ -196,10 +185,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
bool is_tns = (vendor_device == 0xa01f177d);
addr = bus->ops->map_bus(bus, devfn, 0x70);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
/* E_CAP */
v = readl(addr);
has_msix = (v & 0xff00) != 0;
@@ -211,10 +199,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
}
if (where_a == 0xb0) {
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
if (v & 0xff00)
pr_err("Bad MSIX cap header: %08x\n", v);
@@ -268,10 +255,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
if (where_a == 0x70) {
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
if (v & 0xff00)
pr_err("Bad PCIe cap header: %08x\n", v);
diff --git a/drivers/pci/controller/pci-thunder-pem.c b/drivers/pci/controller/pci-thunder-pem.c
index 0660b9da204f..06a9855cb431 100644
--- a/drivers/pci/controller/pci-thunder-pem.c
+++ b/drivers/pci/controller/pci-thunder-pem.c
@@ -41,10 +41,8 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
struct pci_config_window *cfg = bus->sysdata;
struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
- if (devfn != 0 || where >= 2048) {
- *val = ~0;
+ if (devfn != 0 || where >= 2048)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/*
* 32-bit accesses only. Write the address to the low order
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 05/24] PCI: thunder: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Robert Richter,
Krzysztof Wilczyński, linux-pci, linux-kernel,
linux-kernel-mentees,
moderated list:PCIE DRIVER FOR CAVIUM THUNDERX
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-thunder-ecam.c | 46 ++++++++---------------
drivers/pci/controller/pci-thunder-pem.c | 4 +-
2 files changed, 17 insertions(+), 33 deletions(-)
diff --git a/drivers/pci/controller/pci-thunder-ecam.c b/drivers/pci/controller/pci-thunder-ecam.c
index ffd84656544f..a95bb58afd52 100644
--- a/drivers/pci/controller/pci-thunder-ecam.c
+++ b/drivers/pci/controller/pci-thunder-ecam.c
@@ -41,10 +41,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
}
if (where_a == 0x4) {
addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
v &= ~0xf;
v |= 2; /* EA entry-1. Base-L */
@@ -56,10 +55,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
u32 barl_rb;
addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
barl_orig = readl(addr + 0);
writel(0xffffffff, addr + 0);
barl_rb = readl(addr + 0);
@@ -72,10 +70,9 @@ static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
}
if (where_a == 0xc) {
addr = bus->ops->map_bus(bus, devfn, bar + 4); /* BAR 1 */
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr); /* EA entry-3. Base-H */
set_val(v, where, size, val);
return PCIBIOS_SUCCESSFUL;
@@ -104,10 +101,8 @@ static int thunder_ecam_p2_config_read(struct pci_bus *bus, unsigned int devfn,
}
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
v = readl(addr);
@@ -135,10 +130,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
int where_a = where & ~3;
addr = bus->ops->map_bus(bus, devfn, 0xc);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
v = readl(addr);
@@ -146,10 +139,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
cfg_type = (v >> 16) & 0x7f;
addr = bus->ops->map_bus(bus, devfn, 8);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
class_rev = readl(addr);
if (class_rev == 0xffffffff)
@@ -176,10 +167,8 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
}
addr = bus->ops->map_bus(bus, devfn, 0);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
vendor_device = readl(addr);
if (vendor_device == 0xffffffff)
@@ -196,10 +185,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
bool is_tns = (vendor_device == 0xa01f177d);
addr = bus->ops->map_bus(bus, devfn, 0x70);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
/* E_CAP */
v = readl(addr);
has_msix = (v & 0xff00) != 0;
@@ -211,10 +199,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
}
if (where_a == 0xb0) {
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
if (v & 0xff00)
pr_err("Bad MSIX cap header: %08x\n", v);
@@ -268,10 +255,9 @@ static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
if (where_a == 0x70) {
addr = bus->ops->map_bus(bus, devfn, where_a);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
+
v = readl(addr);
if (v & 0xff00)
pr_err("Bad PCIe cap header: %08x\n", v);
diff --git a/drivers/pci/controller/pci-thunder-pem.c b/drivers/pci/controller/pci-thunder-pem.c
index 0660b9da204f..06a9855cb431 100644
--- a/drivers/pci/controller/pci-thunder-pem.c
+++ b/drivers/pci/controller/pci-thunder-pem.c
@@ -41,10 +41,8 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
struct pci_config_window *cfg = bus->sysdata;
struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
- if (devfn != 0 || where >= 2048) {
- *val = ~0;
+ if (devfn != 0 || where >= 2048)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/*
* 32-bit accesses only. Write the address to the low order
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
(?)
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Ray Jui, Scott Branden,
maintainer:BROADCOM IPROC ARM ARCHITECTURE,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-iproc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
index 30ac5fbefbbf..e3d86416a4fb 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
void __iomem *addr;
addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = readl(addr);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Ray Jui, Scott Branden,
maintainer:BROADCOM IPROC ARM ARCHITECTURE,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-iproc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
index 30ac5fbefbbf..e3d86416a4fb 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
void __iomem *addr;
addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = readl(addr);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Scott Branden,
Krzysztof Wilczyński, linux-pci, linux-kernel,
maintainer:BROADCOM IPROC ARM ARCHITECTURE, Ray Jui,
linux-kernel-mentees,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-iproc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
index 30ac5fbefbbf..e3d86416a4fb 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
void __iomem *addr;
addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
- if (!addr) {
- *val = ~0;
+ if (!addr)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = readl(addr);
--
2.25.1
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
2021-10-15 14:38 ` Naveen Naidu
(?)
@ 2021-10-15 16:49 ` Ray Jui via Linux-kernel-mentees
-1 siblings, 0 replies; 95+ messages in thread
From: Ray Jui @ 2021-10-15 16:49 UTC (permalink / raw)
To: Naveen Naidu, bhelgaas
Cc: linux-kernel-mentees, linux-pci, linux-kernel, Lorenzo Pieralisi,
Rob Herring, Krzysztof Wilczyński, Ray Jui, Scott Branden,
maintainer:BROADCOM IPROC ARM ARCHITECTURE,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
On 10/15/2021 7:38 AM, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> The host controller drivers sets the error response values (~0) and
> returns an error when faulty hardware read occurs. But the error
> response value (~0) is already being set in PCI_OP_READ and
> PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
>
> Thus, it's no longer necessary for the host controller drivers to
> fabricate any error response.
>
> This helps unify PCI error response checking and make error check
> consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/controller/pcie-iproc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 30ac5fbefbbf..e3d86416a4fb 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
> void __iomem *addr;
>
> addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
> - if (!addr) {
> - *val = ~0;
> + if (!addr)
> return PCIBIOS_DEVICE_NOT_FOUND;
> - }
>
> *val = readl(addr);
>
>
I think it would be helpful if you include us in the review of the PCI
core code change (pci.h and access.c) so we get the right context to
review this change at the individual driver level.
The driver change looks fine to me, as long as the change in the core is
reviewed and approved.
Thanks,
Ray
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4194 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
@ 2021-10-15 16:49 ` Ray Jui via Linux-kernel-mentees
0 siblings, 0 replies; 95+ messages in thread
From: Ray Jui @ 2021-10-15 16:49 UTC (permalink / raw)
To: Naveen Naidu, bhelgaas
Cc: linux-kernel-mentees, linux-pci, linux-kernel, Lorenzo Pieralisi,
Rob Herring, Krzysztof Wilczyński, Ray Jui, Scott Branden,
maintainer:BROADCOM IPROC ARM ARCHITECTURE,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
[-- Attachment #1.1: Type: text/plain, Size: 1710 bytes --]
On 10/15/2021 7:38 AM, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> The host controller drivers sets the error response values (~0) and
> returns an error when faulty hardware read occurs. But the error
> response value (~0) is already being set in PCI_OP_READ and
> PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
>
> Thus, it's no longer necessary for the host controller drivers to
> fabricate any error response.
>
> This helps unify PCI error response checking and make error check
> consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/controller/pcie-iproc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 30ac5fbefbbf..e3d86416a4fb 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
> void __iomem *addr;
>
> addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
> - if (!addr) {
> - *val = ~0;
> + if (!addr)
> return PCIBIOS_DEVICE_NOT_FOUND;
> - }
>
> *val = readl(addr);
>
>
I think it would be helpful if you include us in the review of the PCI
core code change (pci.h and access.c) so we get the right context to
review this change at the individual driver level.
The driver change looks fine to me, as long as the change in the core is
reviewed and approved.
Thanks,
Ray
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4194 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
@ 2021-10-15 16:49 ` Ray Jui via Linux-kernel-mentees
0 siblings, 0 replies; 95+ messages in thread
From: Ray Jui via Linux-kernel-mentees @ 2021-10-15 16:49 UTC (permalink / raw)
To: Naveen Naidu, bhelgaas
Cc: Krzysztof Wilczyński, Lorenzo Pieralisi, Scott Branden,
Rob Herring, linux-pci, linux-kernel,
maintainer:BROADCOM IPROC ARM ARCHITECTURE, Ray Jui,
linux-kernel-mentees,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
[-- Attachment #1.1: Type: text/plain, Size: 1710 bytes --]
On 10/15/2021 7:38 AM, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> The host controller drivers sets the error response values (~0) and
> returns an error when faulty hardware read occurs. But the error
> response value (~0) is already being set in PCI_OP_READ and
> PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
>
> Thus, it's no longer necessary for the host controller drivers to
> fabricate any error response.
>
> This helps unify PCI error response checking and make error check
> consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/controller/pcie-iproc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 30ac5fbefbbf..e3d86416a4fb 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
> void __iomem *addr;
>
> addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
> - if (!addr) {
> - *val = ~0;
> + if (!addr)
> return PCIBIOS_DEVICE_NOT_FOUND;
> - }
>
> *val = readl(addr);
>
>
I think it would be helpful if you include us in the review of the PCI
core code change (pci.h and access.c) so we get the right context to
review this change at the individual driver level.
The driver change looks fine to me, as long as the change in the core is
reviewed and approved.
Thanks,
Ray
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4194 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
2021-10-15 16:49 ` Ray Jui via Linux-kernel-mentees
(?)
@ 2021-10-15 17:05 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 17:05 UTC (permalink / raw)
To: Ray Jui
Cc: Rob Herring, Lorenzo Pieralisi, Scott Branden,
Krzysztof Wilczyński, linux-pci, linux-kernel,
maintainer:BROADCOM IPROC ARM ARCHITECTURE, Ray Jui, bhelgaas,
linux-kernel-mentees,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
On 15/10, Ray Jui wrote:
>
>
> On 10/15/2021 7:38 AM, Naveen Naidu wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> >
> > The host controller drivers sets the error response values (~0) and
> > returns an error when faulty hardware read occurs. But the error
> > response value (~0) is already being set in PCI_OP_READ and
> > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> >
> > Thus, it's no longer necessary for the host controller drivers to
> > fabricate any error response.
> >
> > This helps unify PCI error response checking and make error check
> > consistent and easier to find.
> >
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> > ---
> > drivers/pci/controller/pcie-iproc.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> > index 30ac5fbefbbf..e3d86416a4fb 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
> > void __iomem *addr;
> >
> > addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
> > - if (!addr) {
> > - *val = ~0;
> > + if (!addr)
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > - }
> >
> > *val = readl(addr);
> >
> >
>
> I think it would be helpful if you include us in the review of the PCI
> core code change (pci.h and access.c) so we get the right context to
> review this change at the individual driver level.
>
I apologize for the rookie mistake ^^', I'll see to it from next time
that I always add proper recepients to the patches so that everyone
gets enough context.
> The driver change looks fine to me, as long as the change in the core is
> reviewed and approved.
>
Thank you very much for taking the time to review it.
> Thanks,
>
> Ray
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
@ 2021-10-15 17:05 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 17:05 UTC (permalink / raw)
To: Ray Jui
Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Ray Jui, Scott Branden,
maintainer:BROADCOM IPROC ARM ARCHITECTURE,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
On 15/10, Ray Jui wrote:
>
>
> On 10/15/2021 7:38 AM, Naveen Naidu wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> >
> > The host controller drivers sets the error response values (~0) and
> > returns an error when faulty hardware read occurs. But the error
> > response value (~0) is already being set in PCI_OP_READ and
> > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> >
> > Thus, it's no longer necessary for the host controller drivers to
> > fabricate any error response.
> >
> > This helps unify PCI error response checking and make error check
> > consistent and easier to find.
> >
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> > ---
> > drivers/pci/controller/pcie-iproc.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> > index 30ac5fbefbbf..e3d86416a4fb 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
> > void __iomem *addr;
> >
> > addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
> > - if (!addr) {
> > - *val = ~0;
> > + if (!addr)
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > - }
> >
> > *val = readl(addr);
> >
> >
>
> I think it would be helpful if you include us in the review of the PCI
> core code change (pci.h and access.c) so we get the right context to
> review this change at the individual driver level.
>
I apologize for the rookie mistake ^^', I'll see to it from next time
that I always add proper recepients to the patches so that everyone
gets enough context.
> The driver change looks fine to me, as long as the change in the core is
> reviewed and approved.
>
Thank you very much for taking the time to review it.
> Thanks,
>
> Ray
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails
@ 2021-10-15 17:05 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 17:05 UTC (permalink / raw)
To: Ray Jui
Cc: bhelgaas, linux-kernel-mentees, linux-pci, linux-kernel,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Ray Jui, Scott Branden,
maintainer:BROADCOM IPROC ARM ARCHITECTURE,
moderated list:BROADCOM IPROC ARM ARCHITECTURE
On 15/10, Ray Jui wrote:
>
>
> On 10/15/2021 7:38 AM, Naveen Naidu wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> >
> > The host controller drivers sets the error response values (~0) and
> > returns an error when faulty hardware read occurs. But the error
> > response value (~0) is already being set in PCI_OP_READ and
> > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> >
> > Thus, it's no longer necessary for the host controller drivers to
> > fabricate any error response.
> >
> > This helps unify PCI error response checking and make error check
> > consistent and easier to find.
> >
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> > ---
> > drivers/pci/controller/pcie-iproc.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> > index 30ac5fbefbbf..e3d86416a4fb 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
> > void __iomem *addr;
> >
> > addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
> > - if (!addr) {
> > - *val = ~0;
> > + if (!addr)
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > - }
> >
> > *val = readl(addr);
> >
> >
>
> I think it would be helpful if you include us in the review of the PCI
> core code change (pci.h and access.c) so we get the right context to
> review this change at the individual driver level.
>
I apologize for the rookie mistake ^^', I'll see to it from next time
that I always add proper recepients to the patches so that everyone
gets enough context.
> The driver change looks fine to me, as long as the change in the core is
> reviewed and approved.
>
Thank you very much for taking the time to review it.
> Thanks,
>
> Ray
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH v2 07/24] PCI: mediatek: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
(?)
(?)
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Ryder Lee, Jianjun Wang, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Matthias Brugger,
open list:PCIE DRIVER FOR MEDIATEK,
moderated list:ARM/Mediatek SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-mediatek.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 2f3f974977a3..a19f8ec5d392 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -365,19 +365,12 @@ static int mtk_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
{
struct mtk_pcie_port *port;
u32 bn = bus->number;
- int ret;
port = mtk_pcie_find_port(bus, devfn);
- if (!port) {
- *val = ~0;
+ if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- ret = mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
- if (ret)
- *val = ~0;
- return ret;
+ return mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
}
static int mtk_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 07/24] PCI: mediatek: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Ryder Lee, Jianjun Wang, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Matthias Brugger,
open list:PCIE DRIVER FOR MEDIATEK,
moderated list:ARM/Mediatek SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-mediatek.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 2f3f974977a3..a19f8ec5d392 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -365,19 +365,12 @@ static int mtk_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
{
struct mtk_pcie_port *port;
u32 bn = bus->number;
- int ret;
port = mtk_pcie_find_port(bus, devfn);
- if (!port) {
- *val = ~0;
+ if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- ret = mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
- if (ret)
- *val = ~0;
- return ret;
+ return mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
}
static int mtk_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 07/24] PCI: mediatek: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Ryder Lee, Jianjun Wang, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Matthias Brugger,
open list:PCIE DRIVER FOR MEDIATEK,
moderated list:ARM/Mediatek SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-mediatek.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 2f3f974977a3..a19f8ec5d392 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -365,19 +365,12 @@ static int mtk_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
{
struct mtk_pcie_port *port;
u32 bn = bus->number;
- int ret;
port = mtk_pcie_find_port(bus, devfn);
- if (!port) {
- *val = ~0;
+ if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- ret = mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
- if (ret)
- *val = ~0;
- return ret;
+ return mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
}
static int mtk_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
--
2.25.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 07/24] PCI: mediatek: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Ryder Lee, Krzysztof Wilczyński, linux-pci,
linux-kernel, Jianjun Wang, Lorenzo Pieralisi,
open list:PCIE DRIVER FOR MEDIATEK, Matthias Brugger,
linux-kernel-mentees, moderated list:ARM/Mediatek SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-mediatek.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 2f3f974977a3..a19f8ec5d392 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -365,19 +365,12 @@ static int mtk_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
{
struct mtk_pcie_port *port;
u32 bn = bus->number;
- int ret;
port = mtk_pcie_find_port(bus, devfn);
- if (!port) {
- *val = ~0;
+ if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- ret = mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
- if (ret)
- *val = ~0;
- return ret;
+ return mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
}
static int mtk_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 08/24] PCI: exynos: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
(?)
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Jingoo Han, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Krzysztof Kozlowski,
moderated list:PCI DRIVER FOR SAMSUNG EXYNOS,
open list:PCI DRIVER FOR SAMSUNG EXYNOS
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index c24dab383654..f9526d6de160 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -216,10 +216,8 @@ static int exynos_pcie_rd_own_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie *pci = to_dw_pcie_from_pp(bus->sysdata);
- if (PCI_SLOT(devfn)) {
- *val = ~0;
+ if (PCI_SLOT(devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = dw_pcie_read_dbi(pci, where, size);
return PCIBIOS_SUCCESSFUL;
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 08/24] PCI: exynos: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Jingoo Han, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Krzysztof Kozlowski,
moderated list:PCI DRIVER FOR SAMSUNG EXYNOS,
open list:PCI DRIVER FOR SAMSUNG EXYNOS
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index c24dab383654..f9526d6de160 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -216,10 +216,8 @@ static int exynos_pcie_rd_own_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie *pci = to_dw_pcie_from_pp(bus->sysdata);
- if (PCI_SLOT(devfn)) {
- *val = ~0;
+ if (PCI_SLOT(devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = dw_pcie_read_dbi(pci, where, size);
return PCIBIOS_SUCCESSFUL;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 08/24] PCI: exynos: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
Jingoo Han, Krzysztof Kozlowski, linux-kernel,
open list:PCI DRIVER FOR SAMSUNG EXYNOS, linux-pci,
linux-kernel-mentees,
moderated list:PCI DRIVER FOR SAMSUNG EXYNOS
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index c24dab383654..f9526d6de160 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -216,10 +216,8 @@ static int exynos_pcie_rd_own_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie *pci = to_dw_pcie_from_pp(bus->sysdata);
- if (PCI_SLOT(devfn)) {
- *val = ~0;
+ if (PCI_SLOT(devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = dw_pcie_read_dbi(pci, where, size);
return PCIBIOS_SUCCESSFUL;
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 09/24] PCI: histb: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Shawn Guo, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pcie-histb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-histb.c b/drivers/pci/controller/dwc/pcie-histb.c
index 86f9d16c50d7..410555dccb6d 100644
--- a/drivers/pci/controller/dwc/pcie-histb.c
+++ b/drivers/pci/controller/dwc/pcie-histb.c
@@ -127,10 +127,8 @@ static int histb_pcie_rd_own_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie *pci = to_dw_pcie_from_pp(bus->sysdata);
- if (PCI_SLOT(devfn)) {
- *val = ~0;
+ if (PCI_SLOT(devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = dw_pcie_read_dbi(pci, where, size);
return PCIBIOS_SUCCESSFUL;
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 09/24] PCI: histb: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, linux-kernel, Shawn Guo, linux-kernel-mentees
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pcie-histb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-histb.c b/drivers/pci/controller/dwc/pcie-histb.c
index 86f9d16c50d7..410555dccb6d 100644
--- a/drivers/pci/controller/dwc/pcie-histb.c
+++ b/drivers/pci/controller/dwc/pcie-histb.c
@@ -127,10 +127,8 @@ static int histb_pcie_rd_own_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie *pci = to_dw_pcie_from_pp(bus->sysdata);
- if (PCI_SLOT(devfn)) {
- *val = ~0;
+ if (PCI_SLOT(devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = dw_pcie_read_dbi(pci, where, size);
return PCIBIOS_SUCCESSFUL;
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 10/24] PCI: kirin: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Xiaowei Song, Binghui Wang, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pcie-kirin.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-kirin.c b/drivers/pci/controller/dwc/pcie-kirin.c
index 026fd1e42a55..56ccc5ceee50 100644
--- a/drivers/pci/controller/dwc/pcie-kirin.c
+++ b/drivers/pci/controller/dwc/pcie-kirin.c
@@ -330,10 +330,8 @@ static int kirin_pcie_rd_own_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie *pci = to_dw_pcie_from_pp(bus->sysdata);
- if (PCI_SLOT(devfn)) {
- *val = ~0;
+ if (PCI_SLOT(devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = dw_pcie_read_dbi(pci, where, size);
return PCIBIOS_SUCCESSFUL;
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 10/24] PCI: kirin: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, Binghui Wang, linux-kernel, Xiaowei Song,
linux-kernel-mentees
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pcie-kirin.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-kirin.c b/drivers/pci/controller/dwc/pcie-kirin.c
index 026fd1e42a55..56ccc5ceee50 100644
--- a/drivers/pci/controller/dwc/pcie-kirin.c
+++ b/drivers/pci/controller/dwc/pcie-kirin.c
@@ -330,10 +330,8 @@ static int kirin_pcie_rd_own_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie *pci = to_dw_pcie_from_pp(bus->sysdata);
- if (PCI_SLOT(devfn)) {
- *val = ~0;
+ if (PCI_SLOT(devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
*val = dw_pcie_read_dbi(pci, where, size);
return PCIBIOS_SUCCESSFUL;
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
(?)
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Thomas Petazzoni, Pali Rohár, Lorenzo Pieralisi,
Rob Herring, Krzysztof Wilczyński,
moderated list:PCI DRIVER FOR AARDVARK (Marvell Armada 3700)
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-aardvark.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index 596ebcfcc82d..1af772c76d06 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -893,10 +893,8 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
u32 reg;
int ret;
- if (!advk_pcie_valid_device(pcie, bus, devfn)) {
- *val = 0xffffffff;
+ if (!advk_pcie_valid_device(pcie, bus, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (pci_is_root_bus(bus))
return pci_bridge_emul_conf_read(&pcie->bridge, where,
@@ -920,7 +918,6 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
*val = CFG_RD_CRS_VAL;
return PCIBIOS_SUCCESSFUL;
}
- *val = 0xffffffff;
return PCIBIOS_SET_FAILED;
}
@@ -955,16 +952,13 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
*val = CFG_RD_CRS_VAL;
return PCIBIOS_SUCCESSFUL;
}
- *val = 0xffffffff;
return PCIBIOS_SET_FAILED;
}
/* Check PIO status and get the read result */
ret = advk_pcie_check_pio_status(pcie, allow_crs, val);
- if (ret < 0) {
- *val = 0xffffffff;
+ if (ret < 0)
return PCIBIOS_SET_FAILED;
- }
if (size == 1)
*val = (*val >> (8 * (where & 3))) & 0xff;
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Thomas Petazzoni, Pali Rohár, Lorenzo Pieralisi,
Rob Herring, Krzysztof Wilczyński,
moderated list:PCI DRIVER FOR AARDVARK (Marvell Armada 3700)
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-aardvark.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index 596ebcfcc82d..1af772c76d06 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -893,10 +893,8 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
u32 reg;
int ret;
- if (!advk_pcie_valid_device(pcie, bus, devfn)) {
- *val = 0xffffffff;
+ if (!advk_pcie_valid_device(pcie, bus, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (pci_is_root_bus(bus))
return pci_bridge_emul_conf_read(&pcie->bridge, where,
@@ -920,7 +918,6 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
*val = CFG_RD_CRS_VAL;
return PCIBIOS_SUCCESSFUL;
}
- *val = 0xffffffff;
return PCIBIOS_SET_FAILED;
}
@@ -955,16 +952,13 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
*val = CFG_RD_CRS_VAL;
return PCIBIOS_SUCCESSFUL;
}
- *val = 0xffffffff;
return PCIBIOS_SET_FAILED;
}
/* Check PIO status and get the read result */
ret = advk_pcie_check_pio_status(pcie, allow_crs, val);
- if (ret < 0) {
- *val = 0xffffffff;
+ if (ret < 0)
return PCIBIOS_SET_FAILED;
- }
if (size == 1)
*val = (*val >> (8 * (where & 3))) & 0xff;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 11/24] PCI: aardvark: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-kernel-mentees, linux-kernel, Thomas Petazzoni, linux-pci,
Pali Rohár,
moderated list:PCI DRIVER FOR AARDVARK Marvell Armada 3700
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-aardvark.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index 596ebcfcc82d..1af772c76d06 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -893,10 +893,8 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
u32 reg;
int ret;
- if (!advk_pcie_valid_device(pcie, bus, devfn)) {
- *val = 0xffffffff;
+ if (!advk_pcie_valid_device(pcie, bus, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (pci_is_root_bus(bus))
return pci_bridge_emul_conf_read(&pcie->bridge, where,
@@ -920,7 +918,6 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
*val = CFG_RD_CRS_VAL;
return PCIBIOS_SUCCESSFUL;
}
- *val = 0xffffffff;
return PCIBIOS_SET_FAILED;
}
@@ -955,16 +952,13 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
*val = CFG_RD_CRS_VAL;
return PCIBIOS_SUCCESSFUL;
}
- *val = 0xffffffff;
return PCIBIOS_SET_FAILED;
}
/* Check PIO status and get the read result */
ret = advk_pcie_check_pio_status(pcie, allow_crs, val);
- if (ret < 0) {
- *val = 0xffffffff;
+ if (ret < 0)
return PCIBIOS_SET_FAILED;
- }
if (size == 1)
*val = (*val >> (8 * (where & 3))) & 0xff;
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
(?)
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
linux-arm-kernel, Thomas Petazzoni, Lorenzo Pieralisi,
Rob Herring, Krzysztof Wilczyński
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-mvebu.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index ed13e81cd691..70a96af8cd2f 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -653,20 +653,16 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
- if (!port) {
- *val = 0xffffffff;
+ if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/* Access the emulated PCI-to-PCI bridge */
if (bus->number == 0)
return pci_bridge_emul_conf_read(&port->bridge, where,
size, val);
- if (!mvebu_pcie_link_up(port)) {
- *val = 0xffffffff;
+ if (!mvebu_pcie_link_up(port))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/* Access the real PCIe interface */
ret = mvebu_pcie_hw_rd_conf(port, bus, devfn,
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
linux-arm-kernel, Thomas Petazzoni, Lorenzo Pieralisi,
Rob Herring, Krzysztof Wilczyński
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-mvebu.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index ed13e81cd691..70a96af8cd2f 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -653,20 +653,16 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
- if (!port) {
- *val = 0xffffffff;
+ if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/* Access the emulated PCI-to-PCI bridge */
if (bus->number == 0)
return pci_bridge_emul_conf_read(&port->bridge, where,
size, val);
- if (!mvebu_pcie_link_up(port)) {
- *val = 0xffffffff;
+ if (!mvebu_pcie_link_up(port))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/* Access the real PCIe interface */
ret = mvebu_pcie_hw_rd_conf(port, bus, devfn,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 12/24] PCI: mvebu: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, linux-kernel, Thomas Petazzoni, linux-kernel-mentees,
linux-arm-kernel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-mvebu.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index ed13e81cd691..70a96af8cd2f 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -653,20 +653,16 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
- if (!port) {
- *val = 0xffffffff;
+ if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/* Access the emulated PCI-to-PCI bridge */
if (bus->number == 0)
return pci_bridge_emul_conf_read(&port->bridge, where,
size, val);
- if (!mvebu_pcie_link_up(port)) {
- *val = 0xffffffff;
+ if (!mvebu_pcie_link_up(port))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
/* Access the real PCIe interface */
ret = mvebu_pcie_hw_rd_conf(port, bus, devfn,
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 13/24] PCI: altera: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Joyce Ooi, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-altera.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-altera.c b/drivers/pci/controller/pcie-altera.c
index 2513e9363236..a6bdf9aff833 100644
--- a/drivers/pci/controller/pcie-altera.c
+++ b/drivers/pci/controller/pcie-altera.c
@@ -510,10 +510,8 @@ static int altera_pcie_cfg_read(struct pci_bus *bus, unsigned int devfn,
if (altera_pcie_hide_rc_bar(bus, devfn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- if (!altera_pcie_valid_device(pcie, bus, PCI_SLOT(devfn))) {
- *value = 0xffffffff;
+ if (!altera_pcie_valid_device(pcie, bus, PCI_SLOT(devfn)))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
return _altera_pcie_cfg_read(pcie, bus->number, devfn, where, size,
value);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 13/24] PCI: altera: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
Joyce Ooi, linux-kernel, linux-pci, linux-kernel-mentees
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-altera.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-altera.c b/drivers/pci/controller/pcie-altera.c
index 2513e9363236..a6bdf9aff833 100644
--- a/drivers/pci/controller/pcie-altera.c
+++ b/drivers/pci/controller/pcie-altera.c
@@ -510,10 +510,8 @@ static int altera_pcie_cfg_read(struct pci_bus *bus, unsigned int devfn,
if (altera_pcie_hide_rc_bar(bus, devfn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- if (!altera_pcie_valid_device(pcie, bus, PCI_SLOT(devfn))) {
- *value = 0xffffffff;
+ if (!altera_pcie_valid_device(pcie, bus, PCI_SLOT(devfn)))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
return _altera_pcie_cfg_read(pcie, bus->number, devfn, where, size,
value);
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Marek Vasut, Yoshihiro Shimoda, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński,
open list:PCI DRIVER FOR RENESAS R-CAR
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-rcar-host.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
index 8f3131844e77..1324cb984ed5 100644
--- a/drivers/pci/controller/pcie-rcar-host.c
+++ b/drivers/pci/controller/pcie-rcar-host.c
@@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
bus, devfn, where, val);
- if (ret != PCIBIOS_SUCCESSFUL) {
- *val = 0xffffffff;
+ if (ret != PCIBIOS_SUCCESSFUL)
return ret;
- }
if (size == 1)
*val = (*val >> (BITS_PER_BYTE * (where & 3))) & 0xff;
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, Yoshihiro Shimoda, linux-kernel,
open list:PCI DRIVER FOR RENESAS R-CAR, linux-kernel-mentees,
Marek Vasut
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-rcar-host.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
index 8f3131844e77..1324cb984ed5 100644
--- a/drivers/pci/controller/pcie-rcar-host.c
+++ b/drivers/pci/controller/pcie-rcar-host.c
@@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
bus, devfn, where, val);
- if (ret != PCIBIOS_SUCCESSFUL) {
- *val = 0xffffffff;
+ if (ret != PCIBIOS_SUCCESSFUL)
return ret;
- }
if (size == 1)
*val = (*val >> (BITS_PER_BYTE * (where & 3))) & 0xff;
--
2.25.1
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
2021-10-15 14:38 ` Naveen Naidu
@ 2021-10-18 11:32 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-10-18 11:32 UTC (permalink / raw)
To: Naveen Naidu
Cc: Bjorn Helgaas, linux-kernel-mentees, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Yoshihiro Shimoda,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
open list:PCI DRIVER FOR RENESAS R-CAR
Hi Naveen,
On Sat, Oct 16, 2021 at 5:33 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> The host controller drivers sets the error response values (~0) and
> returns an error when faulty hardware read occurs. But the error
> response value (~0) is already being set in PCI_OP_READ and
> PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
>
> Thus, it's no longer necessary for the host controller drivers to
> fabricate any error response.
>
> This helps unify PCI error response checking and make error check
> consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
Thanks for your patch!
> --- a/drivers/pci/controller/pcie-rcar-host.c
> +++ b/drivers/pci/controller/pcie-rcar-host.c
> @@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
>
> ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
> bus, devfn, where, val);
> - if (ret != PCIBIOS_SUCCESSFUL) {
> - *val = 0xffffffff;
I don't see the behavior you describe in PCI_OP_READ(), so dropping
this will lead to returning an uninitialized value?
> + if (ret != PCIBIOS_SUCCESSFUL)
> return ret;
> - }
>
> if (size == 1)
> *val = (*val >> (BITS_PER_BYTE * (where & 3))) & 0xff;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
@ 2021-10-18 11:32 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-10-18 11:32 UTC (permalink / raw)
To: Naveen Naidu
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, Yoshihiro Shimoda, Linux Kernel Mailing List,
open list:PCI DRIVER FOR RENESAS R-CAR, Bjorn Helgaas,
linux-kernel-mentees, Marek Vasut
Hi Naveen,
On Sat, Oct 16, 2021 at 5:33 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> The host controller drivers sets the error response values (~0) and
> returns an error when faulty hardware read occurs. But the error
> response value (~0) is already being set in PCI_OP_READ and
> PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
>
> Thus, it's no longer necessary for the host controller drivers to
> fabricate any error response.
>
> This helps unify PCI error response checking and make error check
> consistent and easier to find.
>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
Thanks for your patch!
> --- a/drivers/pci/controller/pcie-rcar-host.c
> +++ b/drivers/pci/controller/pcie-rcar-host.c
> @@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
>
> ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
> bus, devfn, where, val);
> - if (ret != PCIBIOS_SUCCESSFUL) {
> - *val = 0xffffffff;
I don't see the behavior you describe in PCI_OP_READ(), so dropping
this will lead to returning an uninitialized value?
> + if (ret != PCIBIOS_SUCCESSFUL)
> return ret;
> - }
>
> if (size == 1)
> *val = (*val >> (BITS_PER_BYTE * (where & 3))) & 0xff;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
2021-10-18 11:32 ` Geert Uytterhoeven
@ 2021-10-18 11:51 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-18 11:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bjorn Helgaas, linux-kernel-mentees, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Yoshihiro Shimoda,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
open list:PCI DRIVER FOR RENESAS R-CAR
On 18/10, Geert Uytterhoeven wrote:
> Hi Naveen,
>
> On Sat, Oct 16, 2021 at 5:33 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> >
> > The host controller drivers sets the error response values (~0) and
> > returns an error when faulty hardware read occurs. But the error
> > response value (~0) is already being set in PCI_OP_READ and
> > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> >
> > Thus, it's no longer necessary for the host controller drivers to
> > fabricate any error response.
> >
> > This helps unify PCI error response checking and make error check
> > consistent and easier to find.
> >
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
>
> Thanks for your patch!
>
> > --- a/drivers/pci/controller/pcie-rcar-host.c
> > +++ b/drivers/pci/controller/pcie-rcar-host.c
> > @@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
> >
> > ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
> > bus, devfn, where, val);
> > - if (ret != PCIBIOS_SUCCESSFUL) {
> > - *val = 0xffffffff;
>
> I don't see the behavior you describe in PCI_OP_READ(), so dropping
> this will lead to returning an uninitialized value?
>
Hello Geert,
Thank you for looking into the patch.
The described behaviour for PCI_OP_READ is part of the 01/24 [1] patch of
the series.
[1]:
https://lore.kernel.org/linux-pci/b913b4966938b7cad8c049dc34093e6c4b2fae68.1634306198.git.naveennaidu479@gmail.com/T/#u
It looks like, I did not add proper receipients for that patch and hence
is leading to confusion. I really apologize for that.
I do not know what the right approach here should be, should I resend
the entire patch series, adding proper receipients OR should I reply to
each of the patches for the drivers and add the link to the patch. I did
not want to spam people with a lot of mails so I was confused as to what
the right option is.
Thanks,
Naveen
> > + if (ret != PCIBIOS_SUCCESSFUL)
> > return ret;
> > - }
> >
> > if (size == 1)
> > *val = (*val >> (BITS_PER_BYTE * (where & 3))) & 0xff;
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
@ 2021-10-18 11:51 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-18 11:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, Yoshihiro Shimoda, Linux Kernel Mailing List,
open list:PCI DRIVER FOR RENESAS R-CAR, Bjorn Helgaas,
linux-kernel-mentees, Marek Vasut
On 18/10, Geert Uytterhoeven wrote:
> Hi Naveen,
>
> On Sat, Oct 16, 2021 at 5:33 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> >
> > The host controller drivers sets the error response values (~0) and
> > returns an error when faulty hardware read occurs. But the error
> > response value (~0) is already being set in PCI_OP_READ and
> > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> >
> > Thus, it's no longer necessary for the host controller drivers to
> > fabricate any error response.
> >
> > This helps unify PCI error response checking and make error check
> > consistent and easier to find.
> >
> > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
>
> Thanks for your patch!
>
> > --- a/drivers/pci/controller/pcie-rcar-host.c
> > +++ b/drivers/pci/controller/pcie-rcar-host.c
> > @@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
> >
> > ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
> > bus, devfn, where, val);
> > - if (ret != PCIBIOS_SUCCESSFUL) {
> > - *val = 0xffffffff;
>
> I don't see the behavior you describe in PCI_OP_READ(), so dropping
> this will lead to returning an uninitialized value?
>
Hello Geert,
Thank you for looking into the patch.
The described behaviour for PCI_OP_READ is part of the 01/24 [1] patch of
the series.
[1]:
https://lore.kernel.org/linux-pci/b913b4966938b7cad8c049dc34093e6c4b2fae68.1634306198.git.naveennaidu479@gmail.com/T/#u
It looks like, I did not add proper receipients for that patch and hence
is leading to confusion. I really apologize for that.
I do not know what the right approach here should be, should I resend
the entire patch series, adding proper receipients OR should I reply to
each of the patches for the drivers and add the link to the patch. I did
not want to spam people with a lot of mails so I was confused as to what
the right option is.
Thanks,
Naveen
> > + if (ret != PCIBIOS_SUCCESSFUL)
> > return ret;
> > - }
> >
> > if (size == 1)
> > *val = (*val >> (BITS_PER_BYTE * (where & 3))) & 0xff;
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
2021-10-18 11:51 ` Naveen Naidu
@ 2021-10-18 12:00 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-10-18 12:00 UTC (permalink / raw)
To: Naveen Naidu
Cc: Bjorn Helgaas, linux-kernel-mentees, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Yoshihiro Shimoda,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
open list:PCI DRIVER FOR RENESAS R-CAR
Hi Naveen,
On Mon, Oct 18, 2021 at 1:52 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> On 18/10, Geert Uytterhoeven wrote:
> > On Sat, Oct 16, 2021 at 5:33 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> > > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > > causes a PCI error. There's no real data to return to satisfy the
> > > CPU read, so most hardware fabricates ~0 data.
> > >
> > > The host controller drivers sets the error response values (~0) and
> > > returns an error when faulty hardware read occurs. But the error
> > > response value (~0) is already being set in PCI_OP_READ and
> > > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> > >
> > > Thus, it's no longer necessary for the host controller drivers to
> > > fabricate any error response.
> > >
> > > This helps unify PCI error response checking and make error check
> > > consistent and easier to find.
> > >
> > > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/pci/controller/pcie-rcar-host.c
> > > +++ b/drivers/pci/controller/pcie-rcar-host.c
> > > @@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
> > >
> > > ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
> > > bus, devfn, where, val);
> > > - if (ret != PCIBIOS_SUCCESSFUL) {
> > > - *val = 0xffffffff;
> >
> > I don't see the behavior you describe in PCI_OP_READ(), so dropping
> > this will lead to returning an uninitialized value?
> >
>
> Hello Geert,
>
> Thank you for looking into the patch.
>
> The described behaviour for PCI_OP_READ is part of the 01/24 [1] patch of
> the series.
>
> [1]:
> https://lore.kernel.org/linux-pci/b913b4966938b7cad8c049dc34093e6c4b2fae68.1634306198.git.naveennaidu479@gmail.com/T/#u
OK, in that case:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> It looks like, I did not add proper receipients for that patch and hence
> is leading to confusion. I really apologize for that.
Indeed. If there are dependencies, all recipients should receive all
dependencies.
> I do not know what the right approach here should be, should I resend
> the entire patch series, adding proper receipients OR should I reply to
> each of the patches for the drivers and add the link to the patch. I did
> not want to spam people with a lot of mails so I was confused as to what
> the right option is.
Probably a resend would be best.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 14/24] PCI: rcar: Remove redundant error fabrication when device read fails
@ 2021-10-18 12:00 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-10-18 12:00 UTC (permalink / raw)
To: Naveen Naidu
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, Yoshihiro Shimoda, Linux Kernel Mailing List,
open list:PCI DRIVER FOR RENESAS R-CAR, Bjorn Helgaas,
linux-kernel-mentees, Marek Vasut
Hi Naveen,
On Mon, Oct 18, 2021 at 1:52 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> On 18/10, Geert Uytterhoeven wrote:
> > On Sat, Oct 16, 2021 at 5:33 PM Naveen Naidu <naveennaidu479@gmail.com> wrote:
> > > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > > causes a PCI error. There's no real data to return to satisfy the
> > > CPU read, so most hardware fabricates ~0 data.
> > >
> > > The host controller drivers sets the error response values (~0) and
> > > returns an error when faulty hardware read occurs. But the error
> > > response value (~0) is already being set in PCI_OP_READ and
> > > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> > >
> > > Thus, it's no longer necessary for the host controller drivers to
> > > fabricate any error response.
> > >
> > > This helps unify PCI error response checking and make error check
> > > consistent and easier to find.
> > >
> > > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/pci/controller/pcie-rcar-host.c
> > > +++ b/drivers/pci/controller/pcie-rcar-host.c
> > > @@ -161,10 +161,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
> > >
> > > ret = rcar_pcie_config_access(host, RCAR_PCI_ACCESS_READ,
> > > bus, devfn, where, val);
> > > - if (ret != PCIBIOS_SUCCESSFUL) {
> > > - *val = 0xffffffff;
> >
> > I don't see the behavior you describe in PCI_OP_READ(), so dropping
> > this will lead to returning an uninitialized value?
> >
>
> Hello Geert,
>
> Thank you for looking into the patch.
>
> The described behaviour for PCI_OP_READ is part of the 01/24 [1] patch of
> the series.
>
> [1]:
> https://lore.kernel.org/linux-pci/b913b4966938b7cad8c049dc34093e6c4b2fae68.1634306198.git.naveennaidu479@gmail.com/T/#u
OK, in that case:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> It looks like, I did not add proper receipients for that patch and hence
> is leading to confusion. I really apologize for that.
Indeed. If there are dependencies, all recipients should receive all
dependencies.
> I do not know what the right approach here should be, should I resend
> the entire patch series, adding proper receipients OR should I reply to
> each of the patches for the drivers and add the link to the patch. I did
> not want to spam people with a lot of mails so I was confused as to what
> the right option is.
Probably a resend would be best.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
2021-10-15 14:35 ` Naveen Naidu
(?)
(?)
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Shawn Lin, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Heiko Stuebner,
open list:PCIE DRIVER FOR ROCKCHIP,
moderated list:ARM/Rockchip SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-rockchip-host.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index c52316d0bfd2..45a28880f322 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -221,10 +221,8 @@ static int rockchip_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
{
struct rockchip_pcie *rockchip = bus->sysdata;
- if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn))) {
- *val = 0xffffffff;
+ if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn)))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (pci_is_root_bus(bus))
return rockchip_pcie_rd_own_conf(rockchip, where, size, val);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Shawn Lin, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Heiko Stuebner,
open list:PCIE DRIVER FOR ROCKCHIP,
moderated list:ARM/Rockchip SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-rockchip-host.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index c52316d0bfd2..45a28880f322 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -221,10 +221,8 @@ static int rockchip_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
{
struct rockchip_pcie *rockchip = bus->sysdata;
- if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn))) {
- *val = 0xffffffff;
+ if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn)))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (pci_is_root_bus(bus))
return rockchip_pcie_rd_own_conf(rockchip, where, size, val);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Shawn Lin, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Heiko Stuebner,
open list:PCIE DRIVER FOR ROCKCHIP,
moderated list:ARM/Rockchip SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-rockchip-host.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index c52316d0bfd2..45a28880f322 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -221,10 +221,8 @@ static int rockchip_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
{
struct rockchip_pcie *rockchip = bus->sysdata;
- if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn))) {
- *val = 0xffffffff;
+ if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn)))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (pci_is_root_bus(bus))
return rockchip_pcie_rd_own_conf(rockchip, where, size, val);
--
2.25.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 15/24] PCI: rockchip: Remove redundant error fabrication when device read fails
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Heiko Stuebner,
Krzysztof Wilczyński, linux-pci, Shawn Lin, linux-kernel,
open list:PCIE DRIVER FOR ROCKCHIP, linux-kernel-mentees,
moderated list:ARM/Rockchip SoC support
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
The host controller drivers sets the error response values (~0) and
returns an error when faulty hardware read occurs. But the error
response value (~0) is already being set in PCI_OP_READ and
PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
Thus, it's no longer necessary for the host controller drivers to
fabricate any error response.
This helps unify PCI error response checking and make error check
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pcie-rockchip-host.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index c52316d0bfd2..45a28880f322 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -221,10 +221,8 @@ static int rockchip_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
{
struct rockchip_pcie *rockchip = bus->sysdata;
- if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn))) {
- *val = 0xffffffff;
+ if (!rockchip_pcie_valid_device(rockchip, bus, PCI_SLOT(devfn)))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
if (pci_is_root_bus(bus))
return rockchip_pcie_rd_own_conf(rockchip, where, size, val);
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 16/24] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas; +Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This unifies PCI error response checking and make error checks
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/pci.c | 10 +++++-----
drivers/pci/probe.c | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ce2ab62b64cf..c1575364d1ce 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1077,7 +1077,7 @@ static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state)
return -EIO;
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
- if (pmcsr == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&pmcsr)) {
pci_err(dev, "can't change power state from %s to %s (config space inaccessible)\n",
pci_power_name(dev->current_state),
pci_power_name(state));
@@ -1239,16 +1239,16 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
* After reset, the device should not silently discard config
* requests, but it may still indicate that it needs more time by
* responding to them with CRS completions. The Root Port will
- * generally synthesize ~0 data to complete the read (except when
- * CRS SV is enabled and the read was for the Vendor ID; in that
- * case it synthesizes 0x0001 data).
+ * generally synthesize ~0 (PCI_ERROR_RESPONSE) data to complete
+ * the read (except when CRS SV is enabled and the read was for the
+ * Vendor ID; in that case it synthesizes 0x0001 data).
*
* Wait for the device to return a non-CRS completion. Read the
* Command register instead of Vendor ID so we don't have to
* contend with the CRS SV value.
*/
pci_read_config_dword(dev, PCI_COMMAND, &id);
- while (id == ~0) {
+ while (RESPONSE_IS_PCI_ERROR(&id)) {
if (delay > timeout) {
pci_warn(dev, "not ready %dms after %s; giving up\n",
delay - 1, reset_type);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index d9fc02a71baa..55b94d689eca 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -206,14 +206,14 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
* memory BAR or a ROM, bit 0 must be clear; if it's an io BAR, bit
* 1 must be clear.
*/
- if (sz == 0xffffffff)
+ if (RESPONSE_IS_PCI_ERROR(&sz))
sz = 0;
/*
* I don't know how l can have all bits set. Copied from old code.
* Maybe it fixes a bug on some ancient platform.
*/
- if (l == 0xffffffff)
+ if (RESPONSE_IS_PCI_ERROR(&l))
l = 0;
if (type == pci_bar_unknown) {
@@ -1660,7 +1660,7 @@ static int pci_cfg_space_size_ext(struct pci_dev *dev)
if (pci_read_config_dword(dev, pos, &status) != PCIBIOS_SUCCESSFUL)
return PCI_CFG_SPACE_SIZE;
- if (status == 0xffffffff || pci_ext_cfg_is_aliased(dev))
+ if (RESPONSE_IS_PCI_ERROR(&status) || pci_ext_cfg_is_aliased(dev))
return PCI_CFG_SPACE_SIZE;
return PCI_CFG_SPACE_EXP_SIZE;
@@ -2336,8 +2336,8 @@ bool pci_bus_generic_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l))
return false;
- /* Some broken boards return 0 or ~0 if a slot is empty: */
- if (*l == 0xffffffff || *l == 0x00000000 ||
+ /* Some broken boards return 0 or ~0 (PCI_ERROR_RESPONSE) if a slot is empty: */
+ if (RESPONSE_IS_PCI_ERROR(l) || *l == 0x00000000 ||
*l == 0x0000ffff || *l == 0xffff0000)
return false;
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 16/24] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas; +Cc: linux-kernel-mentees, linux-kernel, linux-pci
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This unifies PCI error response checking and make error checks
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/pci.c | 10 +++++-----
drivers/pci/probe.c | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ce2ab62b64cf..c1575364d1ce 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1077,7 +1077,7 @@ static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state)
return -EIO;
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
- if (pmcsr == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&pmcsr)) {
pci_err(dev, "can't change power state from %s to %s (config space inaccessible)\n",
pci_power_name(dev->current_state),
pci_power_name(state));
@@ -1239,16 +1239,16 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
* After reset, the device should not silently discard config
* requests, but it may still indicate that it needs more time by
* responding to them with CRS completions. The Root Port will
- * generally synthesize ~0 data to complete the read (except when
- * CRS SV is enabled and the read was for the Vendor ID; in that
- * case it synthesizes 0x0001 data).
+ * generally synthesize ~0 (PCI_ERROR_RESPONSE) data to complete
+ * the read (except when CRS SV is enabled and the read was for the
+ * Vendor ID; in that case it synthesizes 0x0001 data).
*
* Wait for the device to return a non-CRS completion. Read the
* Command register instead of Vendor ID so we don't have to
* contend with the CRS SV value.
*/
pci_read_config_dword(dev, PCI_COMMAND, &id);
- while (id == ~0) {
+ while (RESPONSE_IS_PCI_ERROR(&id)) {
if (delay > timeout) {
pci_warn(dev, "not ready %dms after %s; giving up\n",
delay - 1, reset_type);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index d9fc02a71baa..55b94d689eca 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -206,14 +206,14 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
* memory BAR or a ROM, bit 0 must be clear; if it's an io BAR, bit
* 1 must be clear.
*/
- if (sz == 0xffffffff)
+ if (RESPONSE_IS_PCI_ERROR(&sz))
sz = 0;
/*
* I don't know how l can have all bits set. Copied from old code.
* Maybe it fixes a bug on some ancient platform.
*/
- if (l == 0xffffffff)
+ if (RESPONSE_IS_PCI_ERROR(&l))
l = 0;
if (type == pci_bar_unknown) {
@@ -1660,7 +1660,7 @@ static int pci_cfg_space_size_ext(struct pci_dev *dev)
if (pci_read_config_dword(dev, pos, &status) != PCIBIOS_SUCCESSFUL)
return PCI_CFG_SPACE_SIZE;
- if (status == 0xffffffff || pci_ext_cfg_is_aliased(dev))
+ if (RESPONSE_IS_PCI_ERROR(&status) || pci_ext_cfg_is_aliased(dev))
return PCI_CFG_SPACE_SIZE;
return PCI_CFG_SPACE_EXP_SIZE;
@@ -2336,8 +2336,8 @@ bool pci_bus_generic_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l))
return false;
- /* Some broken boards return 0 or ~0 if a slot is empty: */
- if (*l == 0xffffffff || *l == 0x00000000 ||
+ /* Some broken boards return 0 or ~0 (PCI_ERROR_RESPONSE) if a slot is empty: */
+ if (RESPONSE_IS_PCI_ERROR(l) || *l == 0x00000000 ||
*l == 0x0000ffff || *l == 0xffff0000)
return false;
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Jonathan Derrick, Nirmal Patel, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Reviewed-by: Jonathan Derrick <jonathan.derrick@linux.dev>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/vmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index a5987e52700e..db81bc4cfe8c 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -538,7 +538,7 @@ static int vmd_get_phys_offsets(struct vmd_dev *vmd, bool native_hint,
int ret;
ret = pci_read_config_dword(dev, PCI_REG_VMLOCK, &vmlock);
- if (ret || vmlock == ~0)
+ if (ret || RESPONSE_IS_PCI_ERROR(&vmlock))
return -ENODEV;
if (MB2_SHADOW_EN(vmlock)) {
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-kernel-mentees, linux-kernel, Jonathan Derrick, linux-pci,
Nirmal Patel
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Reviewed-by: Jonathan Derrick <jonathan.derrick@linux.dev>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/vmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index a5987e52700e..db81bc4cfe8c 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -538,7 +538,7 @@ static int vmd_get_phys_offsets(struct vmd_dev *vmd, bool native_hint,
int ret;
ret = pci_read_config_dword(dev, PCI_REG_VMLOCK, &vmlock);
- if (ret || vmlock == ~0)
+ if (ret || RESPONSE_IS_PCI_ERROR(&vmlock))
return -ENODEV;
if (MB2_SHADOW_EN(vmlock)) {
--
2.25.1
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:38 ` Naveen Naidu
@ 2021-10-15 14:52 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:52 UTC (permalink / raw)
To: bhelgaas
Cc: linux-kernel-mentees, linux-pci, linux-kernel, Jonathan Derrick,
Nirmal Patel, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński
On 15/10, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
> data from hardware.
>
> This helps unify PCI error response checking and make error checks
> consistent and easier to find.
>
> Reviewed-by: Jonathan Derrick <jonathan.derrick@linux.dev>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/controller/vmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index a5987e52700e..db81bc4cfe8c 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -538,7 +538,7 @@ static int vmd_get_phys_offsets(struct vmd_dev *vmd, bool native_hint,
> int ret;
>
> ret = pci_read_config_dword(dev, PCI_REG_VMLOCK, &vmlock);
> - if (ret || vmlock == ~0)
> + if (ret || RESPONSE_IS_PCI_ERROR(&vmlock))
> return -ENODEV;
>
> if (MB2_SHADOW_EN(vmlock)) {
> --
> 2.25.1
>
Jonathan, I have added your Reviewed-by tag from the first version [1] of
the patch series, since this patch did not change in the version 2. I
hope that's okay. If not, I really apologize for that and can you
please let me know how to rectify that mistake.
[1]:
https://lore.kernel.org/linux-pci/f3aca934-7dee-b294-ad3c-264e773eddda@linux.dev/T/#u
Thanks,
Naveen
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 17/24] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:52 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:52 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, linux-kernel, Jonathan Derrick, Nirmal Patel,
linux-kernel-mentees
On 15/10, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
> data from hardware.
>
> This helps unify PCI error response checking and make error checks
> consistent and easier to find.
>
> Reviewed-by: Jonathan Derrick <jonathan.derrick@linux.dev>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/controller/vmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index a5987e52700e..db81bc4cfe8c 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -538,7 +538,7 @@ static int vmd_get_phys_offsets(struct vmd_dev *vmd, bool native_hint,
> int ret;
>
> ret = pci_read_config_dword(dev, PCI_REG_VMLOCK, &vmlock);
> - if (ret || vmlock == ~0)
> + if (ret || RESPONSE_IS_PCI_ERROR(&vmlock))
> return -ENODEV;
>
> if (MB2_SHADOW_EN(vmlock)) {
> --
> 2.25.1
>
Jonathan, I have added your Reviewed-by tag from the first version [1] of
the patch series, since this patch did not change in the version 2. I
hope that's okay. If not, I really apologize for that and can you
please let me know how to rectify that mistake.
[1]:
https://lore.kernel.org/linux-pci/f3aca934-7dee-b294-ad3c-264e773eddda@linux.dev/T/#u
Thanks,
Naveen
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:38 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Lukas Wunner, Kuppuswamy Sathyanarayanan, Amey Narkhede
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Compile tested only.
Acked-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/hotplug/pciehp_hpc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 3024d7e85e6a..8a2f6bb643b5 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -89,7 +89,7 @@ static int pcie_poll_cmd(struct controller *ctrl, int timeout)
do {
pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
- if (slot_status == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&slot_status)) {
ctrl_info(ctrl, "%s: no response from device\n",
__func__);
return 0;
@@ -165,7 +165,7 @@ static void pcie_do_write_cmd(struct controller *ctrl, u16 cmd,
pcie_wait_cmd(ctrl);
pcie_capability_read_word(pdev, PCI_EXP_SLTCTL, &slot_ctrl);
- if (slot_ctrl == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&slot_ctrl)) {
ctrl_info(ctrl, "%s: no response from device\n", __func__);
goto out;
}
@@ -236,7 +236,7 @@ int pciehp_check_link_active(struct controller *ctrl)
int ret;
ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
- if (ret == PCIBIOS_DEVICE_NOT_FOUND || lnk_status == (u16)~0)
+ if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&lnk_status))
return -ENODEV;
ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
@@ -443,7 +443,7 @@ int pciehp_card_present(struct controller *ctrl)
int ret;
ret = pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
- if (ret == PCIBIOS_DEVICE_NOT_FOUND || slot_status == (u16)~0)
+ if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&slot_status))
return -ENODEV;
return !!(slot_status & PCI_EXP_SLTSTA_PDS);
@@ -621,7 +621,7 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
read_status:
pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &status);
- if (status == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&status)) {
ctrl_info(ctrl, "%s: no response from device\n", __func__);
if (parent)
pm_runtime_put(parent);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:38 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:38 UTC (permalink / raw)
To: bhelgaas
Cc: Kuppuswamy Sathyanarayanan, linux-pci, linux-kernel,
Lukas Wunner, linux-kernel-mentees
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Compile tested only.
Acked-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/hotplug/pciehp_hpc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 3024d7e85e6a..8a2f6bb643b5 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -89,7 +89,7 @@ static int pcie_poll_cmd(struct controller *ctrl, int timeout)
do {
pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
- if (slot_status == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&slot_status)) {
ctrl_info(ctrl, "%s: no response from device\n",
__func__);
return 0;
@@ -165,7 +165,7 @@ static void pcie_do_write_cmd(struct controller *ctrl, u16 cmd,
pcie_wait_cmd(ctrl);
pcie_capability_read_word(pdev, PCI_EXP_SLTCTL, &slot_ctrl);
- if (slot_ctrl == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&slot_ctrl)) {
ctrl_info(ctrl, "%s: no response from device\n", __func__);
goto out;
}
@@ -236,7 +236,7 @@ int pciehp_check_link_active(struct controller *ctrl)
int ret;
ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
- if (ret == PCIBIOS_DEVICE_NOT_FOUND || lnk_status == (u16)~0)
+ if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&lnk_status))
return -ENODEV;
ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
@@ -443,7 +443,7 @@ int pciehp_card_present(struct controller *ctrl)
int ret;
ret = pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
- if (ret == PCIBIOS_DEVICE_NOT_FOUND || slot_status == (u16)~0)
+ if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&slot_status))
return -ENODEV;
return !!(slot_status & PCI_EXP_SLTSTA_PDS);
@@ -621,7 +621,7 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
read_status:
pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &status);
- if (status == (u16) ~0) {
+ if (RESPONSE_IS_PCI_ERROR(&status)) {
ctrl_info(ctrl, "%s: no response from device\n", __func__);
if (parent)
pm_runtime_put(parent);
--
2.25.1
_______________________________________________
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] 95+ messages in thread* Re: [PATCH v2 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:38 ` Naveen Naidu
@ 2021-10-15 15:15 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 15:15 UTC (permalink / raw)
To: bhelgaas
Cc: linux-kernel-mentees, linux-pci, linux-kernel, Lukas Wunner,
Kuppuswamy Sathyanarayanan, Amey Narkhede
On 15/10, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
> data from hardware.
>
> This helps unify PCI error response checking and make error checks
> consistent and easier to find.
>
> Compile tested only.
>
> Acked-by: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/hotplug/pciehp_hpc.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
> index 3024d7e85e6a..8a2f6bb643b5 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -89,7 +89,7 @@ static int pcie_poll_cmd(struct controller *ctrl, int timeout)
>
> do {
> pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
> - if (slot_status == (u16) ~0) {
> + if (RESPONSE_IS_PCI_ERROR(&slot_status)) {
> ctrl_info(ctrl, "%s: no response from device\n",
> __func__);
> return 0;
> @@ -165,7 +165,7 @@ static void pcie_do_write_cmd(struct controller *ctrl, u16 cmd,
> pcie_wait_cmd(ctrl);
>
> pcie_capability_read_word(pdev, PCI_EXP_SLTCTL, &slot_ctrl);
> - if (slot_ctrl == (u16) ~0) {
> + if (RESPONSE_IS_PCI_ERROR(&slot_ctrl)) {
> ctrl_info(ctrl, "%s: no response from device\n", __func__);
> goto out;
> }
> @@ -236,7 +236,7 @@ int pciehp_check_link_active(struct controller *ctrl)
> int ret;
>
> ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
> - if (ret == PCIBIOS_DEVICE_NOT_FOUND || lnk_status == (u16)~0)
> + if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&lnk_status))
> return -ENODEV;
>
> ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
> @@ -443,7 +443,7 @@ int pciehp_card_present(struct controller *ctrl)
> int ret;
>
> ret = pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
> - if (ret == PCIBIOS_DEVICE_NOT_FOUND || slot_status == (u16)~0)
> + if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&slot_status))
> return -ENODEV;
>
> return !!(slot_status & PCI_EXP_SLTSTA_PDS);
> @@ -621,7 +621,7 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
>
> read_status:
> pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &status);
> - if (status == (u16) ~0) {
> + if (RESPONSE_IS_PCI_ERROR(&status)) {
> ctrl_info(ctrl, "%s: no response from device\n", __func__);
> if (parent)
> pm_runtime_put(parent);
> --
> 2.25.1
>
Lukas, I have added your Acked-by tag from the v1 [1] of patch series,
since this patch has not changed in v2. I hope that's okay. If not, I
apologize for that and can resend the patch series without the tag.
Apologies for the inconvenience.
[1]: https://lore.kernel.org/linux-pci/20211011194740.GA14357@wunner.de/
Also, regarding your comments from v1 patch series [1] about re-naming the
RESPONSE_IS_PCI_ERROR to RESPONSE_IS_PCI_TIMEOUT. We could indeed change
the change to RESPONSE_IS_PCI_TIMEOUT for pciehp, but then I'm afraid
that picehp would be the odd one out. I mean, since in all the other
places we are using RESPONE_IS_PCI_TIMEOUT to see if any error occured
while reading from a device.
RESPONSE_IS_PCI_ERROR stills gives an idea to the readers that some PCI
error occured. It was my understanding that timeout is also a kind of
PCI error (I might be horribly wrong here, given my very less experience
with PCI subsystem) so it would be okay to use RESPONSE_IS_PCI_ERROR
here.
If that is not the case please let me know. But I am not sure what to
do here? If RESPONSE_IS_PCI_ERROR does not fit here, should the right
option would be to revert/remove this patch from the series?
Thanks,
Naveen
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v2 18/24] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 15:15 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 15:15 UTC (permalink / raw)
To: bhelgaas
Cc: Kuppuswamy Sathyanarayanan, linux-pci, linux-kernel,
Lukas Wunner, linux-kernel-mentees
On 15/10, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error. There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
>
> Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
> data from hardware.
>
> This helps unify PCI error response checking and make error checks
> consistent and easier to find.
>
> Compile tested only.
>
> Acked-by: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
> ---
> drivers/pci/hotplug/pciehp_hpc.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
> index 3024d7e85e6a..8a2f6bb643b5 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -89,7 +89,7 @@ static int pcie_poll_cmd(struct controller *ctrl, int timeout)
>
> do {
> pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
> - if (slot_status == (u16) ~0) {
> + if (RESPONSE_IS_PCI_ERROR(&slot_status)) {
> ctrl_info(ctrl, "%s: no response from device\n",
> __func__);
> return 0;
> @@ -165,7 +165,7 @@ static void pcie_do_write_cmd(struct controller *ctrl, u16 cmd,
> pcie_wait_cmd(ctrl);
>
> pcie_capability_read_word(pdev, PCI_EXP_SLTCTL, &slot_ctrl);
> - if (slot_ctrl == (u16) ~0) {
> + if (RESPONSE_IS_PCI_ERROR(&slot_ctrl)) {
> ctrl_info(ctrl, "%s: no response from device\n", __func__);
> goto out;
> }
> @@ -236,7 +236,7 @@ int pciehp_check_link_active(struct controller *ctrl)
> int ret;
>
> ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
> - if (ret == PCIBIOS_DEVICE_NOT_FOUND || lnk_status == (u16)~0)
> + if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&lnk_status))
> return -ENODEV;
>
> ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
> @@ -443,7 +443,7 @@ int pciehp_card_present(struct controller *ctrl)
> int ret;
>
> ret = pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status);
> - if (ret == PCIBIOS_DEVICE_NOT_FOUND || slot_status == (u16)~0)
> + if (ret == PCIBIOS_DEVICE_NOT_FOUND || RESPONSE_IS_PCI_ERROR(&slot_status))
> return -ENODEV;
>
> return !!(slot_status & PCI_EXP_SLTSTA_PDS);
> @@ -621,7 +621,7 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
>
> read_status:
> pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &status);
> - if (status == (u16) ~0) {
> + if (RESPONSE_IS_PCI_ERROR(&status)) {
> ctrl_info(ctrl, "%s: no response from device\n", __func__);
> if (parent)
> pm_runtime_put(parent);
> --
> 2.25.1
>
Lukas, I have added your Acked-by tag from the v1 [1] of patch series,
since this patch has not changed in v2. I hope that's okay. If not, I
apologize for that and can resend the patch series without the tag.
Apologies for the inconvenience.
[1]: https://lore.kernel.org/linux-pci/20211011194740.GA14357@wunner.de/
Also, regarding your comments from v1 patch series [1] about re-naming the
RESPONSE_IS_PCI_ERROR to RESPONSE_IS_PCI_TIMEOUT. We could indeed change
the change to RESPONSE_IS_PCI_TIMEOUT for pciehp, but then I'm afraid
that picehp would be the odd one out. I mean, since in all the other
places we are using RESPONE_IS_PCI_TIMEOUT to see if any error occured
while reading from a device.
RESPONSE_IS_PCI_ERROR stills gives an idea to the readers that some PCI
error occured. It was my understanding that timeout is also a kind of
PCI error (I might be horribly wrong here, given my very less experience
with PCI subsystem) so it would be okay to use RESPONSE_IS_PCI_ERROR
here.
If that is not the case please let me know. But I am not sure what to
do here? If RESPONSE_IS_PCI_ERROR does not fit here, should the right
option would be to revert/remove this patch from the series?
Thanks,
Naveen
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:35 ` Naveen Naidu
(?)
@ 2021-10-15 14:39 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Russell Currey, Oliver O'Halloran,
open list:PCI ENHANCED ERROR HANDLING (EEH) FOR POWERPC
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Compile tested only.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/pcie/dpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index c556e7beafe3..561c44d9429c 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -79,7 +79,7 @@ static bool dpc_completed(struct pci_dev *pdev)
u16 status;
pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_STATUS, &status);
- if ((status != 0xffff) && (status & PCI_EXP_DPC_STATUS_TRIGGER))
+ if ((!RESPONSE_IS_PCI_ERROR(&status)) && (status & PCI_EXP_DPC_STATUS_TRIGGER))
return false;
if (test_bit(PCI_DPC_RECOVERING, &pdev->priv_flags))
@@ -312,7 +312,7 @@ static irqreturn_t dpc_irq(int irq, void *context)
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, &status);
- if (!(status & PCI_EXP_DPC_STATUS_INTERRUPT) || status == (u16)(~0))
+ if (!(status & PCI_EXP_DPC_STATUS_INTERRUPT) || RESPONSE_IS_PCI_ERROR(&status))
return IRQ_NONE;
pci_write_config_word(pdev, cap + PCI_EXP_DPC_STATUS,
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v2 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: linux-pci, open list:PCI ENHANCED ERROR HANDLING EEH FOR POWERPC,
linux-kernel, Naveen Naidu, Oliver O'Halloran,
linux-kernel-mentees
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Compile tested only.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/pcie/dpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index c556e7beafe3..561c44d9429c 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -79,7 +79,7 @@ static bool dpc_completed(struct pci_dev *pdev)
u16 status;
pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_STATUS, &status);
- if ((status != 0xffff) && (status & PCI_EXP_DPC_STATUS_TRIGGER))
+ if ((!RESPONSE_IS_PCI_ERROR(&status)) && (status & PCI_EXP_DPC_STATUS_TRIGGER))
return false;
if (test_bit(PCI_DPC_RECOVERING, &pdev->priv_flags))
@@ -312,7 +312,7 @@ static irqreturn_t dpc_irq(int irq, void *context)
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, &status);
- if (!(status & PCI_EXP_DPC_STATUS_INTERRUPT) || status == (u16)(~0))
+ if (!(status & PCI_EXP_DPC_STATUS_INTERRUPT) || RESPONSE_IS_PCI_ERROR(&status))
return IRQ_NONE;
pci_write_config_word(pdev, cap + PCI_EXP_DPC_STATUS,
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v2 19/24] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: linux-pci, open list:PCI ENHANCED ERROR HANDLING EEH FOR POWERPC,
linux-kernel, Oliver O'Halloran, Russell Currey,
linux-kernel-mentees
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Compile tested only.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/pcie/dpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index c556e7beafe3..561c44d9429c 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -79,7 +79,7 @@ static bool dpc_completed(struct pci_dev *pdev)
u16 status;
pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_STATUS, &status);
- if ((status != 0xffff) && (status & PCI_EXP_DPC_STATUS_TRIGGER))
+ if ((!RESPONSE_IS_PCI_ERROR(&status)) && (status & PCI_EXP_DPC_STATUS_TRIGGER))
return false;
if (test_bit(PCI_DPC_RECOVERING, &pdev->priv_flags))
@@ -312,7 +312,7 @@ static irqreturn_t dpc_irq(int irq, void *context)
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, &status);
- if (!(status & PCI_EXP_DPC_STATUS_INTERRUPT) || status == (u16)(~0))
+ if (!(status & PCI_EXP_DPC_STATUS_INTERRUPT) || RESPONSE_IS_PCI_ERROR(&status))
return IRQ_NONE;
pci_write_config_word(pdev, cap + PCI_EXP_DPC_STATUS,
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 20/24] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:39 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Krzysztof Wilczyński, Qiuxu Zhuo, Sean V Kelley, linux-pci,
linux-kernel, linux-kernel-mentees
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Compile tested only.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/pcie/pme.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index 1d0dd77fed3a..24588d0b581f 100644
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -224,7 +224,7 @@ static void pcie_pme_work_fn(struct work_struct *work)
break;
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
- if (rtsta == (u32) ~0)
+ if (RESPONSE_IS_PCI_ERROR(&rtsta))
break;
if (rtsta & PCI_EXP_RTSTA_PME) {
@@ -274,7 +274,7 @@ static irqreturn_t pcie_pme_irq(int irq, void *context)
spin_lock_irqsave(&data->lock, flags);
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
- if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) {
+ if (RESPONSE_IS_PCI_ERROR(&rtsta) || !(rtsta & PCI_EXP_RTSTA_PME)) {
spin_unlock_irqrestore(&data->lock, flags);
return IRQ_NONE;
}
--
2.25.1
_______________________________________________
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] 95+ messages in thread* [PATCH v2 20/24] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Krzysztof Wilczyński, Qiuxu Zhuo, Sean V Kelley
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Compile tested only.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/pcie/pme.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index 1d0dd77fed3a..24588d0b581f 100644
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -224,7 +224,7 @@ static void pcie_pme_work_fn(struct work_struct *work)
break;
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
- if (rtsta == (u32) ~0)
+ if (RESPONSE_IS_PCI_ERROR(&rtsta))
break;
if (rtsta & PCI_EXP_RTSTA_PME) {
@@ -274,7 +274,7 @@ static irqreturn_t pcie_pme_irq(int irq, void *context)
spin_lock_irqsave(&data->lock, flags);
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
- if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) {
+ if (RESPONSE_IS_PCI_ERROR(&rtsta) || !(rtsta & PCI_EXP_RTSTA_PME)) {
spin_unlock_irqrestore(&data->lock, flags);
return IRQ_NONE;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v2 21/24] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:39 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Krzysztof Wilczyński
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/hotplug/cpqphp_ctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/cpqphp_ctrl.c b/drivers/pci/hotplug/cpqphp_ctrl.c
index 1b26ca0b3701..d5274b9b06a5 100644
--- a/drivers/pci/hotplug/cpqphp_ctrl.c
+++ b/drivers/pci/hotplug/cpqphp_ctrl.c
@@ -2273,7 +2273,7 @@ static u32 configure_new_device(struct controller *ctrl, struct pci_func *func
while ((function < max_functions) && (!stop_it)) {
pci_bus_read_config_dword(ctrl->pci_bus, PCI_DEVFN(func->device, function), 0x00, &ID);
- if (ID == 0xFFFFFFFF) {
+ if (RESPONSE_IS_PCI_ERROR(&ID)) {
function++;
} else {
/* Setup slot structure. */
@@ -2517,7 +2517,7 @@ static int configure_new_function(struct controller *ctrl, struct pci_func *func
pci_bus_read_config_dword(pci_bus, PCI_DEVFN(device, 0), 0x00, &ID);
pci_bus->number = func->bus;
- if (ID != 0xFFFFFFFF) { /* device present */
+ if (!RESPONSE_IS_PCI_ERROR(&ID)) { /* device present */
/* Setup slot structure. */
new_slot = cpqhp_slot_create(hold_bus_node->base);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 21/24] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Krzysztof Wilczyński, linux-kernel-mentees, linux-kernel, linux-pci
An MMIO read from a PCI device that doesn't exist or doesn't respond
causes a PCI error. There's no real data to return to satisfy the
CPU read, so most hardware fabricates ~0 data.
Use RESPONSE_IS_PCI_ERROR() to check the response we get when we read
data from hardware.
This helps unify PCI error response checking and make error checks
consistent and easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/hotplug/cpqphp_ctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/cpqphp_ctrl.c b/drivers/pci/hotplug/cpqphp_ctrl.c
index 1b26ca0b3701..d5274b9b06a5 100644
--- a/drivers/pci/hotplug/cpqphp_ctrl.c
+++ b/drivers/pci/hotplug/cpqphp_ctrl.c
@@ -2273,7 +2273,7 @@ static u32 configure_new_device(struct controller *ctrl, struct pci_func *func
while ((function < max_functions) && (!stop_it)) {
pci_bus_read_config_dword(ctrl->pci_bus, PCI_DEVFN(func->device, function), 0x00, &ID);
- if (ID == 0xFFFFFFFF) {
+ if (RESPONSE_IS_PCI_ERROR(&ID)) {
function++;
} else {
/* Setup slot structure. */
@@ -2517,7 +2517,7 @@ static int configure_new_function(struct controller *ctrl, struct pci_func *func
pci_bus_read_config_dword(pci_bus, PCI_DEVFN(device, 0), 0x00, &ID);
pci_bus->number = func->bus;
- if (ID != 0xFFFFFFFF) { /* device present */
+ if (!RESPONSE_IS_PCI_ERROR(&ID)) { /* device present */
/* Setup slot structure. */
new_slot = cpqhp_slot_create(hold_bus_node->base);
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 22/24] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:39 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Jingoo Han, Marc Zyngier, Kishon Vijay Abraham I
Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment to
specify a hardware error. This helps finding where MMIO read error
occurs easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pci-keystone.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 865258d8c53c..25b11610b500 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -748,8 +748,8 @@ static int ks_pcie_config_legacy_irq(struct keystone_pcie *ks_pcie)
#ifdef CONFIG_ARM
/*
* When a PCI device does not exist during config cycles, keystone host gets a
- * bus error instead of returning 0xffffffff. This handler always returns 0
- * for this kind of faults.
+ * bus error instead of returning 0xffffffff (PCI_ERROR_RESPONSE).
+ * This handler always returns 0 for this kind of faults.
*/
static int ks_pcie_fault(unsigned long addr, unsigned int fsr,
struct pt_regs *regs)
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v2 22/24] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Marc Zyngier,
Krzysztof Wilczyński, linux-pci, linux-kernel,
Kishon Vijay Abraham I, Jingoo Han, linux-kernel-mentees
Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment to
specify a hardware error. This helps finding where MMIO read error
occurs easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/dwc/pci-keystone.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 865258d8c53c..25b11610b500 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -748,8 +748,8 @@ static int ks_pcie_config_legacy_irq(struct keystone_pcie *ks_pcie)
#ifdef CONFIG_ARM
/*
* When a PCI device does not exist during config cycles, keystone host gets a
- * bus error instead of returning 0xffffffff. This handler always returns 0
- * for this kind of faults.
+ * bus error instead of returning 0xffffffff (PCI_ERROR_RESPONSE).
+ * This handler always returns 0 for this kind of faults.
*/
static int ks_pcie_fault(unsigned long addr, unsigned int fsr,
struct pt_regs *regs)
--
2.25.1
_______________________________________________
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] 95+ messages in thread
* [PATCH v2 23/24] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
2021-10-15 14:35 ` Naveen Naidu
@ 2021-10-15 14:39 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Wei Liu, Lorenzo Pieralisi, Stephen Hemminger,
open list:Hyper-V/Azure CORE AND DRIVERS,
Krzysztof Wilczyński, linux-pci, Haiyang Zhang, Dexuan Cui,
linux-kernel, K. Y. Srinivasan, linux-kernel-mentees
Include PCI_ERROR_RESPONSE along with 0xFFFFFFFF in the comment to
specify a hardware error. This helps finding where MMIO read error
occurs easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-hyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 67c46e52c0dc..7e1102e3d7c6 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -1774,7 +1774,7 @@ static void prepopulate_bars(struct hv_pcibus_device *hbus)
* If the memory enable bit is already set, Hyper-V silently ignores
* the below BAR updates, and the related PCI device driver can not
* work, because reading from the device register(s) always returns
- * 0xFFFFFFFF.
+ * 0xFFFFFFFF (PCI_ERROR_RESPONSE).
*/
list_for_each_entry(hpdev, &hbus->children, list_entry) {
_hv_pcifront_read_config(hpdev, PCI_COMMAND, 2, &command);
--
2.25.1
_______________________________________________
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] 95+ messages in thread* [PATCH v2 23/24] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu,
Dexuan Cui, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński,
open list:Hyper-V/Azure CORE AND DRIVERS
Include PCI_ERROR_RESPONSE along with 0xFFFFFFFF in the comment to
specify a hardware error. This helps finding where MMIO read error
occurs easier to find.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-hyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 67c46e52c0dc..7e1102e3d7c6 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -1774,7 +1774,7 @@ static void prepopulate_bars(struct hv_pcibus_device *hbus)
* If the memory enable bit is already set, Hyper-V silently ignores
* the below BAR updates, and the related PCI device driver can not
* work, because reading from the device register(s) always returns
- * 0xFFFFFFFF.
+ * 0xFFFFFFFF (PCI_ERROR_RESPONSE).
*/
list_for_each_entry(hpdev, &hbus->children, list_entry) {
_hv_pcifront_read_config(hpdev, PCI_COMMAND, 2, &command);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v2 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
2021-10-15 14:35 ` Naveen Naidu
(?)
@ 2021-10-15 14:39 ` Naveen Naidu
-1 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Rob Herring, Lorenzo Pieralisi, Krzysztof Wilczyński,
linux-pci, linux-kernel, Toan Le, linux-kernel-mentees,
moderated list:PCI DRIVER FOR APPLIEDMICRO XGENE
Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment to
specify a hardware error. This makes finding where MMIO read error
occurs easier.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-xgene.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index e64536047b65..4b10794e1ba1 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -176,10 +176,10 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
* Retry Status (CRS) logic: when CRS Software Visibility is
* enabled and we read the Vendor and Device ID of a non-existent
* device, the controller fabricates return data of 0xFFFF0001
- * ("device exists but is not ready") instead of 0xFFFFFFFF
- * ("device does not exist"). This causes the PCI core to retry
- * the read until it times out. Avoid this by not claiming to
- * support CRS SV.
+ * ("device exists but is not ready") instead of
+ * 0xFFFFFFFF (PCI_ERROR_RESPONSE) ("device does not exist"). This causes
+ * the PCI core to retry the read until it times out.
+ * Avoid this by not claiming to support CRS SV.
*/
if (pci_is_root_bus(bus) && (port->version == XGENE_PCIE_IP_VER_1) &&
((where & ~0x3) == XGENE_V1_PCI_EXP_CAP + PCI_EXP_RTCTL))
--
2.25.1
_______________________________________________
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] 95+ messages in thread* [PATCH v2 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Toan Le, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński,
moderated list:PCI DRIVER FOR APPLIEDMICRO XGENE
Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment to
specify a hardware error. This makes finding where MMIO read error
occurs easier.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-xgene.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index e64536047b65..4b10794e1ba1 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -176,10 +176,10 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
* Retry Status (CRS) logic: when CRS Software Visibility is
* enabled and we read the Vendor and Device ID of a non-existent
* device, the controller fabricates return data of 0xFFFF0001
- * ("device exists but is not ready") instead of 0xFFFFFFFF
- * ("device does not exist"). This causes the PCI core to retry
- * the read until it times out. Avoid this by not claiming to
- * support CRS SV.
+ * ("device exists but is not ready") instead of
+ * 0xFFFFFFFF (PCI_ERROR_RESPONSE) ("device does not exist"). This causes
+ * the PCI core to retry the read until it times out.
+ * Avoid this by not claiming to support CRS SV.
*/
if (pci_is_root_bus(bus) && (port->version == XGENE_PCIE_IP_VER_1) &&
((where & ~0x3) == XGENE_V1_PCI_EXP_CAP + PCI_EXP_RTCTL))
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v2 24/24] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
@ 2021-10-15 14:39 ` Naveen Naidu
0 siblings, 0 replies; 95+ messages in thread
From: Naveen Naidu @ 2021-10-15 14:39 UTC (permalink / raw)
To: bhelgaas
Cc: Naveen Naidu, linux-kernel-mentees, linux-pci, linux-kernel,
Toan Le, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński,
moderated list:PCI DRIVER FOR APPLIEDMICRO XGENE
Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment to
specify a hardware error. This makes finding where MMIO read error
occurs easier.
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
---
drivers/pci/controller/pci-xgene.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index e64536047b65..4b10794e1ba1 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -176,10 +176,10 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
* Retry Status (CRS) logic: when CRS Software Visibility is
* enabled and we read the Vendor and Device ID of a non-existent
* device, the controller fabricates return data of 0xFFFF0001
- * ("device exists but is not ready") instead of 0xFFFFFFFF
- * ("device does not exist"). This causes the PCI core to retry
- * the read until it times out. Avoid this by not claiming to
- * support CRS SV.
+ * ("device exists but is not ready") instead of
+ * 0xFFFFFFFF (PCI_ERROR_RESPONSE) ("device does not exist"). This causes
+ * the PCI core to retry the read until it times out.
+ * Avoid this by not claiming to support CRS SV.
*/
if (pci_is_root_bus(bus) && (port->version == XGENE_PCIE_IP_VER_1) &&
((where & ~0x3) == XGENE_V1_PCI_EXP_CAP + PCI_EXP_RTCTL))
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread