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
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 - 25:
- Edits the comments to include PCI_ERROR_RESPONSE alsong with
0xFFFFFFFF, so that it becomes easier to grep for faulty
hardware reads.
Changelog
=========
v3:
- Change RESPONSE_IS_PCI_ERROR macro definition
- Fix the macros, Add () around macro parameters
- Fix alignment issue in Patch 2/24
- Add proper receipients for all the patches
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 (25):
[Patch 1/25] PCI: Add PCI_ERROR_RESPONSE and it's related definitions
[Patch 2/25] PCI: Set error response in config access defines when ops->read() fails
[Patch 3/25] PCI: Use SET_PCI_ERROR_RESPONSE() when device not found
[Patch 4/25] PCI: Remove redundant error fabrication when device read fails
[Patch 5/25] PCI: thunder: Remove redundant error fabrication when device read fails
[Patch 6/25] PCI: iproc: Remove redundant error fabrication when device read fails
[Patch 7/25] PCI: mediatek: Remove redundant error fabrication when device read fails
[Patch 8/25] PCI: exynos: Remove redundant error fabrication when device read fails
[Patch 9/25] PCI: histb: Remove redundant error fabrication when device read fails
[Patch 10/25] PCI: kirin: Remove redundant error fabrication when device read fails
[Patch 11/25] PCI: aardvark: Remove redundant error fabrication when device read fails
[Patch 12/25] PCI: mvebu: Remove redundant error fabrication when device read fails
[Patch 13/25] PCI: altera: Remove redundant error fabrication when device read fails
[Patch 14/25] PCI: rcar: Remove redundant error fabrication when device read fails
[Patch 15/25] PCI: rockchip: Remove redundant error fabrication when device read fails
[Patch 16/25] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[Patch 17/25] PCI: vmd: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[Patch 18/25] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[Patch 19/25] PCI/DPC: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[Patch 20/25] PCI/PME: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[Patch 21/25] PCI: cpqphp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware
[Patch 22/25] PCI: Use PCI_ERROR_RESPONSE to specify hardware error
[Patch 23/25] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error
[Patch 24/25] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error
[Patch 25/25] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error
drivers/pci/access.c | 32 +++++++-------
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, 85 insertions(+), 121 deletions(-)
--
2.25.1
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 <redacted>
---
include/linux/pci.h | 9 +++++++++
1 file changed, 9 insertions(+)
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>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Naveen Naidu <redacted>
---
drivers/pci/access.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
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 <redacted>
---
drivers/pci/pcie/dpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Thursday 21 October 2021 20:37:27 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>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Naveen Naidu <redacted>
On Thursday 21 October 2021 20:37:26 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 <redacted>
On Thu, Oct 21, 2021 at 08:37:26PM +0530, Naveen Naidu wrote:
quoted hunk
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 <redacted>
---
include/linux/pci.h | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -154,6 +154,15 @@ enum pci_interrupt_pin {/* The number of legacy PCI INTx interrupts */#define PCI_NUM_INTX 4+/*+*Readingfromadevicethatdoesn'trespondtypicallyreturns~0.A+*successfulreadfromadevicemayalsoreturn~0,soyouneedadditional+*informationtoreliablyidentifyerrors.+*/+#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))
Beautiful! I really like this.
I would prefer the macros to start with "PCI_", e.g.,
PCI_SET_ERROR_RESPONSE().
I think "RESPONSE_IS_PCI_ERROR()" is too strong because (as the
comment says), ~0 *may* indicate an error. Or it may be a successful
read of a register that happens to contain ~0.
Possibilities to convey the idea that this isn't definitive:
PCI_POSSIBLE_ERROR_RESPONSE(val) # a little long
PCI_LIKELY_ERROR(val) # we really have no idea whether
PCI_PROBABLE_ERROR(val) # likely or probable
PCI_POSSIBLE_ERROR(val) # promising?
Can you rebase to my "main" branch (v5.16-rc1), tweak the above, and
collect up the acks/reviews?
We should also browse drivers outside drivers/pci for places we could
use these. Not necessarily as part of this series, although if
authors there object, it would be good to learn that earlier than
later.
Drivers that implement pci_error_handlers might be a fruitful place to
start. But you've done a great job finding users of ~0 and 0xffff...
in drivers/pci/, too.
+
/*
* 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
On Thu, Oct 21, 2021 at 08:37:26PM +0530, Naveen Naidu wrote:
quoted
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 <redacted>
---
include/linux/pci.h | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -154,6 +154,15 @@ enum pci_interrupt_pin {/* The number of legacy PCI INTx interrupts */#define PCI_NUM_INTX 4+/*+*Readingfromadevicethatdoesn'trespondtypicallyreturns~0.A+*successfulreadfromadevicemayalsoreturn~0,soyouneedadditional+*informationtoreliablyidentifyerrors.+*/+#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))
Beautiful! I really like this.
Thank you very much for the review ^^
I would prefer the macros to start with "PCI_", e.g.,
PCI_SET_ERROR_RESPONSE().
ACK
I think "RESPONSE_IS_PCI_ERROR()" is too strong because (as the
comment says), ~0 *may* indicate an error. Or it may be a successful
read of a register that happens to contain ~0.
Possibilities to convey the idea that this isn't definitive:
PCI_POSSIBLE_ERROR_RESPONSE(val) # a little long
PCI_LIKELY_ERROR(val) # we really have no idea whether
PCI_PROBABLE_ERROR(val) # likely or probable
PCI_POSSIBLE_ERROR(val) # promising?
ACK. Will use PCI_POSSIBLE_ERROR()
Can you rebase to my "main" branch (v5.16-rc1), tweak the above, and
collect up the acks/reviews?
ACK
We should also browse drivers outside drivers/pci for places we could
use these. Not necessarily as part of this series, although if
authors there object, it would be good to learn that earlier than
later.
Drivers that implement pci_error_handlers might be a fruitful place to
start. But you've done a great job finding users of ~0 and 0xffff...
in drivers/pci/, too.
A quick grep showed that there are around 80 drivers which have
pci_error_handlers. I was thinking that it would be better if we handle
these drivers in another patch series since the current patch series is
itself 25 patches long. And in my short tenure reading LKML, I gathered
that folks generally are not so kind to a long list of patches in a
single patch series ^^' (I might be wrong though, Apologies)
The consensus on the patch series does seem slightly positive so
ideally, I was hoping that we would not have the case where a author
does not like the way we are handling this patch. Then again, I'm
pretty sure that I might be wrong ^^'
I hope it would be okay that I send in a new patch series with the
suggested changes and handle the other changes in another patch series
^^
Thanks,
Naveen
quoted
+
/*
* 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