linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Yicong Yang <yangyicong@hisilicon.com>
Cc: linux-pci@vger.kernel.org,
	sathyanarayanan.kuppuswamy@linux.intel.com, kbusch@kernel.org,
	sean.v.kelley@intel.com, qiuxu.zhuo@intel.com,
	prime.zeng@huawei.com, linuxarm@openeuler.org
Subject: Re: [PATCH v2] PCI/DPC: Check host->native_dpc before enable dpc service
Date: Mon, 26 Jul 2021 17:05:12 -0500	[thread overview]
Message-ID: <20210726220512.GA648162@bjorn-Precision-5520> (raw)
In-Reply-To: <8ab7923c-c9d4-d864-86f0-743077e15d98@hisilicon.com>

On Wed, Feb 24, 2021 at 05:47:58PM +0800, Yicong Yang wrote:
> On 2021/2/3 20:53, Yicong Yang wrote:
> > Per Downstream Port Containment Related Enhancements ECN[1]
> > Table 4-6, Interpretation of _OSC Control Field Returned Value,
> > for bit 7 of _OSC control return value:
> > 
> >   "Firmware sets this bit to 1 to grant the OS control over PCI Express
> >   Downstream Port Containment configuration."
> >   "If control of this feature was requested and denied,
> >   or was not requested, the firmware returns this bit set to 0."
> > 
> > We store bit 7 of _OSC control return value in host->native_dpc,
> > check it before enable the dpc service as the firmware may not
> > grant the control.
> > 
> > [1] Downstream Port Containment Related Enhancements ECN,
> >     Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2
> >     https://members.pcisig.com/wg/PCI-SIG/document/12888
> > 
> > Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
> > ---
> > Change since v1:
> > - use correct reference for _OSC control return value
> > 
> >  drivers/pci/pcie/portdrv_core.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> > index e1fed664..7445d03 100644
> > --- a/drivers/pci/pcie/portdrv_core.c
> > +++ b/drivers/pci/pcie/portdrv_core.c
> > @@ -253,7 +253,8 @@ static int get_port_device_capability(struct pci_dev *dev)
> >  	 */
> >  	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> >  	    pci_aer_available() &&
> > -	    (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
> > +	    (pcie_ports_dpc_native ||
> > +	    ((services & PCIE_PORT_SERVICE_AER) && host->native_dpc)))
> >  		services |= PCIE_PORT_SERVICE_DPC;
> >  
> 
> the check here maybe problematic. the bit 7 of _OSC return value is reserved
> previously and the change here may break the backward compatibility.
> currently we make dpc enabled along with aer, which can ensure the native
> dpc won't be enabled if the edr is enabled.

Since you think this is problematic, I'll drop it for now.  If you
decide it's the right thing to do, please post it again.

> i feel a bit confused as the bit 7 is not used.
> does it provide a way to enable native dpc regardless of aer ownership?
> just as pcie_ports=dpc-native does when i checked the discussion in [1].
> 
> [1] https://lore.kernel.org/linux-pci/20191023192205.97024-1-olof@lixom.net/
> 
> Thanks,
> Yicong
> 
> >  	if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
> > 
> 

  reply	other threads:[~2021-07-26 22:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-03 12:53 [PATCH v2] PCI/DPC: Check host->native_dpc before enable dpc service Yicong Yang
2021-02-03 12:53 ` [PATCH] PCI/DPC: Disable ERR_COR explicitly for native " Yicong Yang
2021-02-18 17:20   ` Bjorn Helgaas
2021-02-24  8:56     ` Yicong Yang
2021-04-10 15:21   ` Bjorn Helgaas
2021-04-10 19:17     ` Lukas Wunner
2021-04-12  9:32       ` Yicong Yang
2021-04-12  3:32     ` Kuppuswamy, Sathyanarayanan
2021-04-12  9:46       ` Yicong Yang
2021-02-24  9:47 ` [PATCH v2] PCI/DPC: Check host->native_dpc before enable " Yicong Yang
2021-07-26 22:05   ` Bjorn Helgaas [this message]
2021-07-28  9:22     ` Yicong Yang

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=20210726220512.GA648162@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@openeuler.org \
    --cc=prime.zeng@huawei.com \
    --cc=qiuxu.zhuo@intel.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=sean.v.kelley@intel.com \
    --cc=yangyicong@hisilicon.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;
as well as URLs for NNTP newsgroup(s).