linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, pali@kernel.org
Subject: Re: [PATCH 09/13] PCI: aardvark: Implement re-issuing config requests on CRS response
Date: Wed, 6 Oct 2021 00:45:31 +0200	[thread overview]
Message-ID: <20211006004531.42aace4d@thinkpad> (raw)
In-Reply-To: <20211005192826.GA1111810@bhelgaas>

On Tue, 5 Oct 2021 14:28:26 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:

> My claim is that the spec allows root complexes that retry zero times,
> so we must assume such a root complex exists and we cannot rely on any
> retries.  If such a root complex exists, this patch might fix a
> problem, but only for aardvark.  It would be better to fix the problem
> in a way that works for all PCIe controllers.
> 
> I'm playing devil's advocate here, and it's quite possible that I'm
> interpreting the spec incorrectly.  Maybe the Marvell card is a way to
> test this in the real world.
> 
> Bjorn

Hello Bjorn,

this is what I understand from Pali's explanation, please correct me if 
something is wrong

- If HW supports CRSSVE bit, OS can ask HW to switch from HW-retry to 
SW-retry mode by setting this CRSSVE bit.

- If HW does not support CRSSVE bit, it means that HW supports only 
HW-retry.

- By default CRSSVE is disabled, and it is optional, so HW is required 
to support HW-retry.

- Linux' PCI core supports handling CRSSVE in probe.c: when HW says it 
supports it, PCI core enables it and retries on 0xffff0001 in function 
pci_bus_wait_crs().

- Aardvark controller violates specification: it does not support 
HW-retry even if it is mandatory. Pali is solving this in his patch by 
doing the retry in the driver when CRSSVE is disabled. He is able to do 
this because he gets the information about CRS from another channel 
(another register).

- You are talking about wanting to implement an abstraction for what 
Pali's patch does in PCI core, so that if CRSSVE is not set and someone 
reads PCI_VENDOR_ID, you want to make PCI core doing this retry.

Am I correct here?

This could be done by changing Pali's patch so that instead of 
retrying, the pci_ops->read() method would instead return a value 
indicating that a retry should be done (this would be a new value, 
PCIBIOS_CRS), and then in access.c in the pci_bus_read_config_dword() 
(and pci_user_read_config_dword()), if the pci_ops->read() method 
returns this PCIBIOS_CRS value, the function will retry reading the 
register.

Is this what you mean?

It would make sense to do this, if there are other controllers where 
HW-retry does not work and instead informs about it via side-channel 
even when CRSSVE is disabled.

Marek

PS: Btw, looking at the code, why do we use these PCIBIOS_* macros? And 
then sometimes convert them to error codes with pcibios_err_to_errno()? 
Is this some legacy thing? Should this be converted to errno?

  reply	other threads:[~2021-10-05 22:45 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-01 19:58 [PATCH 00/13] PCI: aardvark controller fixes Marek Behún
2021-10-01 19:58 ` [PATCH 01/13] PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macros Marek Behún
2021-10-02 16:05   ` Bjorn Helgaas
2021-10-04  8:43   ` Lorenzo Pieralisi
2021-10-04  9:32     ` Marek Behún
2021-10-04  9:35       ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 02/13] PCI: aardvark: Fix PCIe Max Payload Size setting Marek Behún
2021-10-03 17:44   ` Marek Behún
2021-10-01 19:58 ` [PATCH 03/13] PCI: aardvark: Don't spam about PIO Response Status Marek Behún
2021-10-01 19:58 ` [PATCH 04/13] PCI: aardvark: Fix preserving PCI_EXP_RTCTL_CRSSVE flag on emulated bridge Marek Behún
2021-10-01 19:58 ` [PATCH 05/13] PCI: aardvark: Fix configuring Reference clock Marek Behún
2021-10-01 19:58 ` [PATCH 06/13] PCI: aardvark: Do not clear status bits of masked interrupts Marek Behún
2021-10-04 14:06   ` Lorenzo Pieralisi
2021-10-04 15:18     ` Marek Behún
2021-10-04 15:31     ` Marc Zyngier
2021-10-05 12:13       ` Marek Behún
2021-10-05 12:42         ` Marc Zyngier
2021-10-05 13:15           ` Pali Rohár
2021-10-05 15:42             ` Marc Zyngier
2021-10-05 18:48               ` Pali Rohár
2021-10-05 16:04             ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 07/13] PCI: aardvark: Do not unmask unused interrupts Marek Behún
2021-10-01 19:58 ` [PATCH 08/13] PCI: aardvark: Deduplicate code in advk_pcie_rd_conf() Marek Behún
2021-10-01 19:58 ` [PATCH 09/13] PCI: aardvark: Implement re-issuing config requests on CRS response Marek Behún
2021-10-02 16:35   ` Bjorn Helgaas
2021-10-04  7:21     ` Marek Behún
2021-10-04  8:53       ` Lorenzo Pieralisi
2021-10-04 10:19         ` Marek Behún
2021-10-05 19:28           ` Bjorn Helgaas
2021-10-05 22:45             ` Marek Behún [this message]
2021-10-11 18:15               ` Usage of PCBIOS_* macros (Was: Re: [PATCH 09/13] PCI: aardvark: Implement re-issuing config requests on CRS response) Pali Rohár
2021-10-11 20:58                 ` Bjorn Helgaas
2021-10-06 16:29             ` [PATCH 09/13] PCI: aardvark: Implement re-issuing config requests on CRS response Lorenzo Pieralisi
2021-10-06 20:13               ` Bjorn Helgaas
2021-10-07 11:51                 ` Lorenzo Pieralisi
2021-10-07 12:36                   ` Marek Behún
2021-10-07 19:25                     ` Bjorn Helgaas
2021-10-01 19:58 ` [PATCH 10/13] PCI: aardvark: Simplify initialization of rootcap on virtual bridge Marek Behún
2021-10-04  9:44   ` Lorenzo Pieralisi
2021-10-04  9:56     ` Marek Behún
2021-10-04 10:10       ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 11/13] PCI: aardvark: Fix link training Marek Behún
2021-10-01 19:58 ` [PATCH 12/13] PCI: aardvark: Fix checking for link up via LTSSM state Marek Behún
2021-10-04 13:35   ` Lorenzo Pieralisi
2021-10-01 19:58 ` [PATCH 13/13] PCI: aardvark: Fix reporting Data Link Layer Link Active Marek Behún
2021-10-04  9:53 ` [PATCH 00/13] PCI: aardvark controller fixes Lorenzo Pieralisi
2021-10-04 10:40   ` Marek Behún

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=20211006004531.42aace4d@thinkpad \
    --to=kabel@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=pali@kernel.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).