All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Matthew W Carlis <mattc@purestorage.com>,
	Keith Busch <kbusch@kernel.org>, Lukas Wunner <lukas@wunner.de>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v2 2/3] PCI/DPC: Remove CONFIG_PCIE_EDR
Date: Fri, 1 Mar 2024 17:06:04 -0600	[thread overview]
Message-ID: <20240301230604.GA368825@bhelgaas> (raw)
In-Reply-To: <35cafc72-89d2-48d3-ab73-0af4ed2bcac1@linux.intel.com>

On Sun, Feb 25, 2024 at 12:05:12PM -0800, Kuppuswamy Sathyanarayanan wrote:
> On 2/22/24 2:15 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas <bhelgaas@google.com>
> >
> > Previous Kconfig allowed the possibility of enabling CONFIG_PCIE_DPC
> > without CONFIG_PCIE_EDR.  The PCI Firmware Spec, r3.3, sec 4.5.1,
> > table 4-5, says an ACPI OS that requests control of DPC must also
> > advertise support for EDR.
> >
> > Remove CONFIG_PCIE_EDR and enable the EDR code with CONFIG_PCIE_DPC so that
> > enabling DPC also enables EDR for ACPI systems.  Since EDR is an ACPI
> > feature, build edr.o only when CONFIG_ACPI is enabled.  Stubs cover the
> > case when DPC is enabled without ACPI.
> >
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > ---
> >  drivers/acpi/pci_root.c   |  2 +-
> >  drivers/pci/pcie/Kconfig  | 14 ++++----------
> >  drivers/pci/pcie/Makefile |  5 ++++-
> >  drivers/pci/pcie/dpc.c    | 10 ----------
> >  include/linux/pci-acpi.h  |  4 ++--
> >  5 files changed, 11 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > index efc292b6214e..bcaf3d3a5e05 100644
> > --- a/drivers/acpi/pci_root.c
> > +++ b/drivers/acpi/pci_root.c
> > @@ -448,7 +448,7 @@ static u32 calculate_support(void)
> >  		support |= OSC_PCI_ASPM_SUPPORT | OSC_PCI_CLOCK_PM_SUPPORT;
> >  	if (pci_msi_enabled())
> >  		support |= OSC_PCI_MSI_SUPPORT;
> > -	if (IS_ENABLED(CONFIG_PCIE_EDR))
> > +	if (IS_ENABLED(CONFIG_PCIE_DPC))	/* DPC => EDR support */
> >  		support |= OSC_PCI_EDR_SUPPORT;
> 
> Since EDR internally touches AER registers, I still think we should
> make sure OS enables AER support before advertising the EDR support.

I guess you're suggesting that we should make it look like this?

  if (host_bridge->native_aer && IS_ENABLED(CONFIG_PCIE_DPC))

That doesn't seem right to me because the implementation note in PCI
Firmware r3.3, sec 4.6.12, shows the EDR flow when firmware maintains
control of AER and DPC, i.e., "host_bridge->native_aer" would be
false.

> >  	return support;
> > diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
> > index 8999fcebde6a..21e98289fbe9 100644
> > --- a/drivers/pci/pcie/Kconfig
> > +++ b/drivers/pci/pcie/Kconfig
> > @@ -137,6 +137,10 @@ config PCIE_DPC
> >  	  have this capability or you do not want to use this feature,
> >  	  it is safe to answer N.
> >  
> > +	  On ACPI systems, this includes Error Disconnect Recover support,
> > +	  the hybrid model that uses both firmware and OS to implement DPC,
> > +	  as specified in the PCI Firmware Specification r3.3.
> 
> Nit: Include some section reference?

I basically copied this from the PCIE_EDR help and updated the
revision number.  But I don't think the firmware spec is a very good
reference because EDR is defined by ACPI.  There's very little text in
the ACPI spec about EDR, but the firmware spec does assume you know
what *is* there.  And the ACPI spec is available to anybody, unlike
the PCI firmware spec.

+         On ACPI systems, this includes Error Disconnect Recover support,
+         the hybrid model that uses both firmware and OS to implement DPC,
+         as specified in ACPI r6.5, sec 5.6.6.

> >  config PCIE_PTM
> >  	bool "PCI Express Precision Time Measurement support"
> >  	help
> > @@ -145,13 +149,3 @@ config PCIE_PTM
> >  
> >  	  This is only useful if you have devices that support PTM, but it
> >  	  is safe to enable even if you don't.
> > -
> > -config PCIE_EDR
> > -	bool "PCI Express Error Disconnect Recover support"
> > -	depends on PCIE_DPC && ACPI
> > -	help
> > -	  This option adds Error Disconnect Recover support as specified
> > -	  in the Downstream Port Containment Related Enhancements ECN to
> > -	  the PCI Firmware Specification r3.2.  Enable this if you want to
> > -	  support hybrid DPC model which uses both firmware and OS to
> > -	  implement DPC.

  reply	other threads:[~2024-03-01 23:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22 22:15 [PATCH v2 0/3] PCI/DPC: Clean up DPC vs AER/EDR ownership and Kconfig Bjorn Helgaas
2024-02-22 22:15 ` [PATCH v2 1/3] PCI/DPC: Request DPC only if also requesting AER Bjorn Helgaas
2024-02-25 19:46   ` Kuppuswamy Sathyanarayanan
2024-02-26 15:18     ` Bjorn Helgaas
2024-02-26 15:46       ` Kuppuswamy Sathyanarayanan
2024-02-26 16:33         ` Bjorn Helgaas
2024-02-26 16:50           ` Kuppuswamy Sathyanarayanan
2024-02-22 22:15 ` [PATCH v2 2/3] PCI/DPC: Remove CONFIG_PCIE_EDR Bjorn Helgaas
2024-02-25 20:05   ` Kuppuswamy Sathyanarayanan
2024-03-01 23:06     ` Bjorn Helgaas [this message]
2024-03-02  6:42       ` Kuppuswamy Sathyanarayanan
2024-02-22 22:15 ` [PATCH v2 3/3] PCI/DPC: Encapsulate pci_acpi_add_edr_notifier() Bjorn Helgaas
2024-02-25 20:06   ` Kuppuswamy Sathyanarayanan
2024-02-26 15:25     ` Bjorn Helgaas
2024-02-27  6:18 ` [PATCH v2 0/3] PCI/DPC: Clean up DPC vs AER/EDR ownership and Kconfig Ethan Zhao
2024-02-27  6:35   ` Kuppuswamy Sathyanarayanan
2024-02-27  7:12     ` Ethan Zhao
2024-02-29  0:00       ` Kuppuswamy Sathyanarayanan

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=20240301230604.GA368825@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mattc@purestorage.com \
    --cc=mika.westerberg@linux.intel.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: link
Be 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.