public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Matthew W Carlis <mattc@purestorage.com>
Cc: bhelgaas@google.com, helgaas@kernel.org, kbusch@kernel.org,
	linux-pci@vger.kernel.org, lukas@wunner.de,
	mika.westerberg@linux.intel.com
Subject: Re: [PATCH 1/1] PCI/portdrv: Allow DPC if the OS controls AER natively.
Date: Wed, 10 Jan 2024 08:41:27 -0800	[thread overview]
Message-ID: <65c81900-cec6-4d3a-b2fe-bb8169ee701c@linux.intel.com> (raw)
In-Reply-To: <20240109001508.32359-1-mattc@purestorage.com>



On 1/8/2024 4:15 PM, Matthew W Carlis wrote:
> A small part is probably historical; we've been using DPC on PCIe switches
> since before there was any EDR support in the kernel. It looks like there
> was a PCIe DPC ECN as early as Feb 2012, but this EDR/DPC fw ECN didn't come in
> till Jan 2019 & kernel support for ECN was even later. Its not immediately
> clear I would want to use EDR in my newer architecures & then there are also
> the older architecures still requiring support. When I submitted this patch I
> came at it with the approach of trying to keep the old behavior & still support
> the newer EDR behavior. Bjorns patch from Dec 28 2023 would seem to change

Just advertising the support for EDR in OS should not change any functional
behavior. EDR will be used only if your firmware take DPC control and sends
EDR notification. Since your kernel has EDR source support, why not enable
the relevant config? or did I not understand the issue correctly?

> the behavior for both root ports & switch ports, requiring them to set
> _OSC Control Field bit 7 (DPC) and _OSC Support Field bit 7 (EDR) or a kernel
> command line value. I think no matter what, we want to ensure that PCIe Root
> Ports and PCIe switches arrive at the same policy here.
> 
> Should we consider CONFIG_PCIEAER or CONFIG_PCIEDPC as any amount of directive
> for the OS to use AER/DPC? In addition we have kernel command line arguments

No, I don't think we should use CONFIG options in actual support check.

> for pcieports=(compat/native/dpc-native) and pci=noaer. There are perhaps some
> others I'm not aware of. Then, there are the PCIe capabilities of the devies
> & bios settings for AER FW/OS controls, etc. I'm not sure if it strikes me as the
> right thing to now require users to specify additional fields to use DPC when
> they had been using it happily before.
> 
> Perhaps the condition should be:
>>         if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
>> -           pci_aer_available() &&
>> -           (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
>> +           pci_aer_available() && (pcie_ports_dpc_native ||
>> +           (host->native_aer && !IS_ENABLED(CONFIG_PCIE_EDR))))
> 
> i.e: Use DPC if we set the command line argument or use DPC if we are are using
> EDR's _OSC DPC field, or use DPC if we have AER & there isn't EDR support?
> 

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

  reply	other threads:[~2024-01-10 16:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-23 21:22 [PATCH 1/1] PCI/portdrv: Allow DPC if the OS controls AER natively Matthew W Carlis
2023-12-23 21:22 ` Matthew W Carlis
2023-12-25 17:53   ` kernel test robot
2023-12-25 20:36   ` kernel test robot
2023-12-26  0:02     ` Matthew W Carlis
2023-12-28 21:23   ` Bjorn Helgaas
2024-01-02 15:41     ` Kuppuswamy Sathyanarayanan
2024-01-08 19:46       ` Matthew W Carlis
2024-01-08 19:53         ` Kuppuswamy Sathyanarayanan
2024-01-09  0:15           ` Matthew W Carlis
2024-01-10 16:41             ` Kuppuswamy Sathyanarayanan [this message]
2024-01-10 17:13               ` Kuppuswamy Sathyanarayanan
2024-01-10 20:01                 ` Matthew W Carlis
2024-01-10 19:59               ` Matthew W Carlis
2024-01-22 19:32             ` Bjorn Helgaas
2024-01-23  2:37               ` Kuppuswamy Sathyanarayanan
2024-01-23 15:59                 ` Bjorn Helgaas
2024-01-23 23:18                   ` Matthew W Carlis
2024-01-24 20:29                     ` Bjorn Helgaas
2024-02-21 23:11                   ` Bjorn Helgaas
2024-02-21 23:33                     ` Bjorn Helgaas

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=65c81900-cec6-4d3a-b2fe-bb8169ee701c@linux.intel.com \
    --to=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mattc@purestorage.com \
    --cc=mika.westerberg@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox