From: "Pali Rohár" <pali@kernel.org> To: Naveen Naidu <naveennaidu479@gmail.com> Cc: Lukas Wunner <lukas@wunner.de>, bhelgaas@google.com, linux-kernel-mentees@lists.linuxfoundation.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Amey Narkhede <ameynarkhede03@gmail.com> Subject: Re: [PATCH 16/22] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware Date: Wed, 13 Oct 2021 01:12:01 +0200 [thread overview] Message-ID: <20211012231201.xj7fvfgvpde5wwrl@pali> (raw) In-Reply-To: <20211012160505.3dov6gjnmxdq5lz6@theprophet> On Tuesday 12 October 2021 21:35:13 Naveen Naidu wrote: > On 11/10, Lukas Wunner wrote: > > On Mon, Oct 11, 2021 at 11:37:33PM +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 RESPONSE_IS_PCI_ERROR() to check the response we get when we read > > > data from hardware. > > > > Actually what happens is that PCI read transactions *time out*, > > so the host controller fabricates a response. > > > > Ah! yes. Now that I look at it, RESPONSE_IS_PCI_TIMEOUT() does indeed > seem like a better option to RESPONSE_IS_PCI_ERROR(), since it's more > specfic and depicts the actual condition. This is not fully correct. 0xffffffff is returned when some error happens. It does not have to be timeout error. Errors like Unsupported Request, Completer Abort or Configuration Request Retry Status (when CRSSVE bit is disabled) are also reported as 0xffffffff and they do not represent timeout. For example Unsupported Request is returned when you try to read from non-existent device behind some PCIe switch. Also pci-aardvark.c fabricates value 0xffffffff when trying to read from config space below the PCIe Root Port when PCIe link is not up. And I have seen that Completer Abort was returned by PCIe switch when switch itself did not received reply from device below switch. So it means that controller can receive some reply from other device even when no real reply was sent. Which means that timeout can be reported by some other message. So I think that generic PCI_ERROR is the best name. You do not know what really happened (only some controller drivers can provide additional information, it does not have any standard HW<-->OS API) and application logic must decide how to process error. > I'll wait for sometime and see if others have any objection/a better > name for the macro and then redo the patch with that. > > Thank you very much for the review ^^ > > > By contrast, a PCI *error* usually denotes an Uncorrectable or > > Correctable Error as specified in section 6.2.2 of the PCIe Base Spec. > > > > Thus something like RESPONSE_IS_PCI_TIMEOUT() or IS_PCI_TIMEOUT() would > > probably be more appropriate. I'll leave the exact bikeshed color for > > others to decide. :-) > > > > > > > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> > > > --- > > > drivers/pci/hotplug/pciehp_hpc.c | 10 +++++----- > > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > Acked-by: Lukas Wunner <lukas@wunner.de>
WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali@kernel.org> To: Naveen Naidu <naveennaidu479@gmail.com> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Lukas Wunner <lukas@wunner.de>, bhelgaas@google.com, linux-kernel-mentees@lists.linuxfoundation.org Subject: Re: [PATCH 16/22] PCI: pciehp: Use RESPONSE_IS_PCI_ERROR() to check read from hardware Date: Wed, 13 Oct 2021 01:12:01 +0200 [thread overview] Message-ID: <20211012231201.xj7fvfgvpde5wwrl@pali> (raw) In-Reply-To: <20211012160505.3dov6gjnmxdq5lz6@theprophet> On Tuesday 12 October 2021 21:35:13 Naveen Naidu wrote: > On 11/10, Lukas Wunner wrote: > > On Mon, Oct 11, 2021 at 11:37:33PM +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 RESPONSE_IS_PCI_ERROR() to check the response we get when we read > > > data from hardware. > > > > Actually what happens is that PCI read transactions *time out*, > > so the host controller fabricates a response. > > > > Ah! yes. Now that I look at it, RESPONSE_IS_PCI_TIMEOUT() does indeed > seem like a better option to RESPONSE_IS_PCI_ERROR(), since it's more > specfic and depicts the actual condition. This is not fully correct. 0xffffffff is returned when some error happens. It does not have to be timeout error. Errors like Unsupported Request, Completer Abort or Configuration Request Retry Status (when CRSSVE bit is disabled) are also reported as 0xffffffff and they do not represent timeout. For example Unsupported Request is returned when you try to read from non-existent device behind some PCIe switch. Also pci-aardvark.c fabricates value 0xffffffff when trying to read from config space below the PCIe Root Port when PCIe link is not up. And I have seen that Completer Abort was returned by PCIe switch when switch itself did not received reply from device below switch. So it means that controller can receive some reply from other device even when no real reply was sent. Which means that timeout can be reported by some other message. So I think that generic PCI_ERROR is the best name. You do not know what really happened (only some controller drivers can provide additional information, it does not have any standard HW<-->OS API) and application logic must decide how to process error. > I'll wait for sometime and see if others have any objection/a better > name for the macro and then redo the patch with that. > > Thank you very much for the review ^^ > > > By contrast, a PCI *error* usually denotes an Uncorrectable or > > Correctable Error as specified in section 6.2.2 of the PCIe Base Spec. > > > > Thus something like RESPONSE_IS_PCI_TIMEOUT() or IS_PCI_TIMEOUT() would > > probably be more appropriate. I'll leave the exact bikeshed color for > > others to decide. :-) > > > > > > > Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> > > > --- > > > drivers/pci/hotplug/pciehp_hpc.c | 10 +++++----- > > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > Acked-by: Lukas Wunner <lukas@wunner.de> _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next prev parent reply other threads:[~2021-10-12 23:12 UTC|newest] Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-11 17:35 [PATCH 00/22] PCI: Unify PCI error response checking Naveen Naidu 2021-10-11 17:35 ` Naveen Naidu 2021-10-11 17:35 ` Naveen Naidu 2021-10-11 17:35 ` Naveen Naidu 2021-10-11 17:35 ` Naveen Naidu 2021-10-11 17:35 ` Naveen Naidu 2021-10-11 17:37 ` [PATCH 01/22] PCI: Add PCI_ERROR_RESPONSE and it's related defintions Naveen Naidu 2021-10-11 17:37 ` Naveen Naidu 2021-10-11 17:37 ` Naveen Naidu 2021-10-11 17:37 ` Naveen Naidu 2021-10-11 17:37 ` Naveen Naidu 2021-10-11 17:37 ` Naveen Naidu 2021-10-11 17:38 ` [PATCH 02/22] PCI: Unify PCI error response checking Naveen Naidu 2021-10-11 17:38 ` Naveen Naidu 2021-10-11 22:05 ` Rob Herring 2021-10-11 22:05 ` Rob Herring 2021-10-12 16:21 ` Naveen Naidu 2021-10-12 16:21 ` Naveen Naidu 2021-10-12 18:02 ` Rob Herring 2021-10-12 18:02 ` Rob Herring 2021-10-12 22:52 ` Pali Rohár 2021-10-12 22:52 ` Pali Rohár 2021-10-13 2:43 ` Bjorn Helgaas 2021-10-13 2:43 ` Bjorn Helgaas 2021-10-13 13:06 ` Rob Herring 2021-10-13 13:06 ` Rob Herring 2021-10-13 17:16 ` Naveen Naidu 2021-10-13 17:16 ` Naveen Naidu 2021-10-13 17:54 ` Pali Rohár 2021-10-13 17:54 ` Pali Rohár 2021-10-13 18:48 ` Bjorn Helgaas 2021-10-13 18:48 ` Bjorn Helgaas 2021-10-13 21:47 ` Rob Herring 2021-10-13 21:47 ` Rob Herring 2021-10-13 22:03 ` Pali Rohár 2021-10-13 22:03 ` Pali Rohár 2021-10-13 22:12 ` Bjorn Helgaas 2021-10-13 22:12 ` Bjorn Helgaas 2021-10-11 17:45 ` [PATCH 03/22] PCI: thunder: Use SET_PCI_ERROR_RESPONSE() when device not found Naveen Naidu 2021-10-11 17:45 ` Naveen Naidu 2021-10-11 17:45 ` Naveen Naidu 2021-10-11 17:46 ` [PATCH 04/22] PCI: iproc: " Naveen Naidu 2021-10-11 17:46 ` Naveen Naidu 2021-10-11 17:46 ` Naveen Naidu 2021-10-11 17:51 ` [PATCH 05/22] PCI: mediatek: " Naveen Naidu 2021-10-11 17:51 ` Naveen Naidu 2021-10-11 17:51 ` Naveen Naidu 2021-10-11 17:51 ` Naveen Naidu 2021-10-11 17:52 ` [PATCH 06/22] PCI: exynos: " Naveen Naidu 2021-10-11 17:52 ` Naveen Naidu 2021-10-11 17:52 ` Naveen Naidu 2021-10-11 17:53 ` [PATCH 07/22] PCI: histb: " Naveen Naidu 2021-10-11 17:53 ` Naveen Naidu 2021-10-11 17:55 ` [PATCH 08/22] PCI: kirin: " Naveen Naidu 2021-10-11 17:55 ` Naveen Naidu 2021-10-11 17:56 ` [PATCH 09/22] PCI: aardvark: " Naveen Naidu 2021-10-11 17:56 ` Naveen Naidu 2021-10-11 17:56 ` Naveen Naidu 2021-10-11 18:08 ` Pali Rohár 2021-10-11 18:08 ` Pali Rohár 2021-10-11 18:08 ` Pali Rohár 2021-10-11 18:28 ` Naveen Naidu 2021-10-11 18:28 ` Naveen Naidu 2021-10-11 18:28 ` Naveen Naidu [not found] ` <20211011182526.kboaxqofdpd2jjrl@theprophet> 2021-10-11 18:41 ` Pali Rohár 2021-10-11 18:41 ` Pali Rohár 2021-10-11 18:41 ` Pali Rohár 2021-10-12 15:59 ` Naveen Naidu 2021-10-12 15:59 ` Naveen Naidu 2021-10-12 15:59 ` Naveen Naidu 2021-10-13 2:13 ` Bjorn Helgaas 2021-10-13 2:13 ` Bjorn Helgaas 2021-10-13 2:13 ` Bjorn Helgaas 2021-10-13 17:59 ` Pali Rohár 2021-10-13 17:59 ` Pali Rohár 2021-10-13 17:59 ` Pali Rohár 2021-10-11 18:00 ` [PATCH 10/22] PCI: mvebu: " Naveen Naidu 2021-10-11 18:00 ` Naveen Naidu 2021-10-11 18:00 ` Naveen Naidu 2021-10-11 18:00 ` [PATCH 11/22] PCI: altera: " Naveen Naidu 2021-10-11 18:00 ` Naveen Naidu 2021-10-11 18:02 ` [PATCH 12/22] PCI: rcar: " Naveen Naidu 2021-10-11 18:02 ` Naveen Naidu 2021-10-11 18:02 ` [PATCH 13/22] PCI: rockchip: " Naveen Naidu 2021-10-11 18:02 ` Naveen Naidu 2021-10-11 18:02 ` Naveen Naidu 2021-10-11 18:02 ` Naveen Naidu 2021-10-11 18:04 ` [PATCH 14/22] PCI/ERR: Use RESPONSE_IS_PCI_ERROR() to check read from hardware Naveen Naidu 2021-10-11 18:04 ` Naveen Naidu 2021-10-11 18:06 ` [PATCH 15/22] PCI: vmd: " Naveen Naidu 2021-10-11 18:06 ` Naveen Naidu 2021-10-14 18:04 ` Jonathan Derrick 2021-10-14 18:04 ` Jonathan Derrick 2021-10-11 18:07 ` [PATCH 16/22] PCI: pciehp: " Naveen Naidu 2021-10-11 18:07 ` Naveen Naidu 2021-10-11 19:47 ` Lukas Wunner 2021-10-11 19:47 ` Lukas Wunner 2021-10-12 16:05 ` Naveen Naidu 2021-10-12 16:05 ` Naveen Naidu 2021-10-12 23:12 ` Pali Rohár [this message] 2021-10-12 23:12 ` Pali Rohár 2021-10-13 12:20 ` Lukas Wunner 2021-10-13 12:20 ` Lukas Wunner 2021-10-11 18:08 ` [PATCH 17/22] PCI/DPC: " Naveen Naidu 2021-10-11 18:08 ` Naveen Naidu 2021-10-11 18:08 ` Naveen Naidu 2021-10-11 18:10 ` [PATCH 18/22] PCI/PME: " Naveen Naidu 2021-10-11 18:10 ` Naveen Naidu 2021-10-11 18:11 ` [PATCH 19/22] PCI: cpqphp: " Naveen Naidu 2021-10-11 18:11 ` Naveen Naidu 2021-10-11 18:11 ` [PATCH 20/22] PCI: keystone: Use PCI_ERROR_RESPONSE to specify hardware error Naveen Naidu 2021-10-11 18:11 ` Naveen Naidu 2021-10-11 18:12 ` [PATCH 21/22] PCI: hv: Use PCI_ERROR_RESPONSE to specify hardware read error Naveen Naidu 2021-10-11 18:12 ` Naveen Naidu 2021-10-11 18:13 ` [PATCH 22/22] PCI: xgene: Use PCI_ERROR_RESPONSE to specify hardware error Naveen Naidu 2021-10-11 18:13 ` Naveen Naidu 2021-10-11 18:13 ` Naveen Naidu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211012231201.xj7fvfgvpde5wwrl@pali \ --to=pali@kernel.org \ --cc=ameynarkhede03@gmail.com \ --cc=bhelgaas@google.com \ --cc=linux-kernel-mentees@lists.linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=lukas@wunner.de \ --cc=naveennaidu479@gmail.com \ --cc=sathyanarayanan.kuppuswamy@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.