From nobody Thu Sep 24 21:48:27 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACE7A37C923; Sat, 19 Sep 2026 16:27:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835225; cv=none; b=RGEY28cMAJyPoNSV9e4m3LvTeuxxg8k4kADs8s665pXX/ht8zuukCld+Q4mAm6KuKBxPaHpQUHhwetHukNprgHxYGjczjKBsFjZiWGjeH0jJ8YozxC4d+tsp+xM1wggeMxjDA1cMjjel/2+0zucDIumeIHVZ0Pvm/s5ZrfPvrPQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835225; c=relaxed/simple; bh=0LDGncaI5MxJUIFYPYtU9c0kJcuTF2TQmLJsM2qYqj0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BBhb0b5VN1wLWV4oyv+ODcyAOlVpIZIjN9kULiwgULWpq2PTIrUwEvLXkAEpSD426U7ZaRsJ6KMAAwE471ew6S4lxoTGJp2++D974hBLvmUcl7rcTKxEg/wKHzdBz4Fn2PwyBENlpOjd4q154waig5qVkXqj+9zZWy6x69e24AY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MboDx7Dm; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MboDx7Dm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789835224; x=1821371224; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0LDGncaI5MxJUIFYPYtU9c0kJcuTF2TQmLJsM2qYqj0=; b=MboDx7Dmv87hX85+rc/uJ54O2cO8nwSJL0kLOfDws66yTl1SOnPlWAxk ++yM2ZMhJLLknKGB6rsR74M4gqkBl2nUP3Qg/oxt7wwEJHDBd3M+Qn3qe +PPtpAKbpqKqdEXCSzCLdMaf4oTJ74vgwOXPWbNzDSs/BSrA9IEc5eTFy pRqLNSS3zO0zgMQIaBn8fxPYWH/nJ5/ef6ErCdc3W1ufuxjysqtGDHkkF r79qR1OJbEtvQxRPYMAmpxqVObZHg+2H00f2zX2f/oSUuclH+yCt1XXMe 1rQnJv3Vzof7S5B8BG4FcUHCBNyP8YQLIxgNkDk2dEmyZ9onwraRiZIcV w==; X-CSE-ConnectionGUID: DdLrc6FZTcSUyMCZ/UKs4g== X-CSE-MsgGUID: uBS26YJcTmKK9qO5dBbibg== X-IronPort-AV: E=McAfee;i="6800,10657,11910"; a="94187228" X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="94187228" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:02 -0700 X-CSE-ConnectionGUID: O8Vu3FlTTdGhBKY60sf+uw== X-CSE-MsgGUID: BqQuAaNkQpykH+4HHtNOdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="272186116" Received: from skuppusw-desk2.jf.intel.com ([10.165.154.101]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:02 -0700 From: Kuppuswamy Sathyanarayanan To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Rafael J Wysocki , Guixin Liu , Olof Johansson Subject: [PATCH v13 1/5] PCI/DPC: Ignore devices with no AER Capability Date: Sat, 19 Sep 2026 09:26:51 -0700 Message-ID: <20260919162655.3499010-2-sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> References: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bjorn Helgaas Downstream Ports may support DPC regardless of whether they support AER (see PCIe r7.0, sec 6.2.11.2). Previously, if the user booted with "pcie_ports=3Ddpc-native", it was possible for dpc_probe() to succeed even = if the device had no AER Capability, but dpc_get_aer_uncorrect_severity() depends on the AER Capability. dpc_probe() previously failed if: !pcie_aer_is_native(pdev) && !pcie_ports_dpc_native !(pcie_aer_is_native() || pcie_ports_dpc_native) # by De Morgan's law so it succeeded if: pcie_aer_is_native() || pcie_ports_dpc_native Fail dpc_probe() if the device has no AER Capability. Signed-off-by: Bjorn Helgaas Cc: Olof Johansson --- Changes since v12 * Rebased to v7.3-rc3. No other changes. v12 posting https://lore.kernel.org/all/20201126011816.711106-1-helgaas@kernel.org/ drivers/pci/pcie/dpc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index 2b779bd1d861..4c2cfae27a08 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -477,6 +477,9 @@ static int dpc_probe(struct pcie_device *dev) int status; u16 cap; =20 + if (!pdev->aer_cap) + return -ENOTSUPP; + if (!pcie_aer_is_native(pdev) && !pcie_ports_dpc_native) return -ENOTSUPP; =20 --=20 2.43.0 From nobody Thu Sep 24 21:48:27 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 240B7380FF5; Sat, 19 Sep 2026 16:27:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835226; cv=none; b=fSp1wdeUZqfS0EEP0O1PUjV5M3LtVDUglmYVoikewOxfIQCBoCl5vDW8akVhKxWfpLFJYsqF2ajsSvNdSU2r1aBHi7FautYIZPMKcf2gVKgiLB/H5pAD3cwnuI05+NvIQCKUZM6mZJ287o/4U5PRBsaFsUK91454HDEX2ZxLHEk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835226; c=relaxed/simple; bh=KBEyovsTBQZ4FyHhLxPlufc+TwZjADtubpxUAsCsdGg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o2fT8TrVTfOmW6zdYUrZD61IqXjy8Bb5X9+1rJR8Zojdo7DWHxsbwABrwxJSkPmwiADh0o1eSAM+fZv5Cf7J/TF5kajOajftz4ek3by21+8dagk2Ry1Su7LMxHroCqRyAst6KUqWG2d9AFg/eH6V8ZZ8IKvva0MNONNLJKYPnvo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=P5P+k+Sv; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="P5P+k+Sv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789835225; x=1821371225; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KBEyovsTBQZ4FyHhLxPlufc+TwZjADtubpxUAsCsdGg=; b=P5P+k+Sv6SF+t9uLKFph5aZztlLFTpwaPjs5xcvIvLkrjRFXW84SARrB moVklbLBChTktLObGobPWb5QEgvU82aE/oT7516KRjDwZm2DPLA05KR/X brbqfrH1nDNIDRRHyt6y+2hnVA4RLoDOsCkh5TIda5CLLtrlvxsLg4KQ6 mWXpUnJTFFlvTu1OOdqRONgchsxBcfJW8zhRPwnEpLpMxC9esCLngbKCK nZEFlRgwJri4P0aWW3S79/eKROH5ag6xEGm3SEgfij/dG6G5ybfnqUv20 k/GY+UY2s8PH2ssrt3OaBZ/efXNQfbXv1axC/bdArz3IV4CtRoTra321p w==; X-CSE-ConnectionGUID: jlP3375HRfyHtYBLi+Lcng== X-CSE-MsgGUID: eVdk/Ow+RouXvc7FCSjR8w== X-IronPort-AV: E=McAfee;i="6800,10657,11910"; a="94187233" X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="94187233" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:02 -0700 X-CSE-ConnectionGUID: MEE+hRoRSEif6lde+bj8XA== X-CSE-MsgGUID: 3d87gAWKTmCWAVQp+K1uQQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="272186118" Received: from skuppusw-desk2.jf.intel.com ([10.165.154.101]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:02 -0700 From: Kuppuswamy Sathyanarayanan To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Rafael J Wysocki , Guixin Liu , Olof Johansson Subject: [PATCH v13 2/5] PCI: Assume control of portdrv-related features only when portdrv enabled Date: Sat, 19 Sep 2026 09:26:52 -0700 Message-ID: <20260919162655.3499010-3-sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> References: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Native control of PME, AER, DPC, and PCIe hotplug depends on the portdrv, so default to native handling of them only when CONFIG_PCIEPORTBUS is enabled. Native control of LTR and SHPC hotplug does not depend on portdrv, so keep defaulting those to native regardless. [bhelgaas: commit log] Link: https://lore.kernel.org/r/fcbe8a624166a1101a755edfef44a185d32ff493.16= 03766889.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Bjorn Helgaas --- Changes since v12 * Rebased to v7.3-rc3. No code change. * Commit log reworded. v12 said we can always take control of LTR and SHPC hotplug unless a platform interface tells us otherwise, which is not true on ACPI systems. v12 posting https://lore.kernel.org/all/20201126011816.711106-1-helgaas@kernel.org/ drivers/pci/probe.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 27008e2ea5af..5f7eb6bc438b 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -668,12 +668,14 @@ static void pci_init_host_bridge(struct pci_host_brid= ge *bridge) * may implement its own AER handling and use _OSC to prevent the * OS from interfering. */ +#ifdef CONFIG_PCIEPORTBUS bridge->native_aer =3D 1; bridge->native_pcie_hotplug =3D 1; - bridge->native_shpc_hotplug =3D 1; bridge->native_pme =3D 1; - bridge->native_ltr =3D 1; bridge->native_dpc =3D 1; +#endif + bridge->native_ltr =3D 1; + bridge->native_shpc_hotplug =3D 1; bridge->domain_nr =3D PCI_DOMAIN_NR_NOT_SET; bridge->native_cxl_error =3D 1; bridge->dev.type =3D &pci_host_bridge_type; --=20 2.43.0 From nobody Thu Sep 24 21:48:27 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 880C1382394; Sat, 19 Sep 2026 16:27:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835227; cv=none; b=kNAce14Qj0+WO6+33bVJg0zVf8a5OE+z+vf1sbQBlVbj7QyEmW6WH/Bs9+PY/CJob+eaiqCCu23ln5etK8Bw1/X/w4BUHMVDO8nv/9xBqFSyp1t3P5EvR/5aJHxTWcdqcFj+Xu4rL8lbQpYfmAiaFimuUgjpukqhfVvDi598bo4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835227; c=relaxed/simple; bh=Twrfbx7XknL5uR8rjzSc78GsWqmuoofdHKSwhzF9hb0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oI69t8VPzRy7uFeQjeo23rFxz2+Am2VaCqPn3P5URKQLSZL2xvZaOSOD3hrBjzg0ocYz1+aBBLaZwk10TGEOhKar1yi/ORnnhuBILkJQTlZayTg2Mun336mSoBIfsSremdeEd87NEB5WBntd4Va+R5JrV28pRjFwVZCERL+pyx4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=J6KccOnO; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="J6KccOnO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789835225; x=1821371225; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Twrfbx7XknL5uR8rjzSc78GsWqmuoofdHKSwhzF9hb0=; b=J6KccOnORczJbdJHrixB0k2/qRQmDpdBfhgfWdR2dtLroI+n+hKoA6ug jtPVhgWTmfvoWGcOoQ6MNm/YgZP9QSDKDfmAjJY1rFHLTs2fc8aatMe3b efNcs7PuJcx2QMPP8gQPm5APQhbHmv0dUGikf1TXC7nW5ukTyAQab/Jcz ZtGkMF06RZt9zSxMzQeenyjIimKF09OlvQWQDo2mx6F3mr80GvaH2ms+w iXirhA9inOqNYFz1YiTeN44CkA0me6zC/6+doTbCGndLvs4bg5JJz2rPd VPwYiJtkUkdi0AnYp35DCnEIVeed/wp2sOjKHTH27NQvhqX+xT0d+BCi6 g==; X-CSE-ConnectionGUID: lOZ43QNGRauRh0t7Z9I6HA== X-CSE-MsgGUID: Cf7xswgrRGOBj23yUP+K3A== X-IronPort-AV: E=McAfee;i="6800,10657,11910"; a="94187238" X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="94187238" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:02 -0700 X-CSE-ConnectionGUID: Entq9IhkTFCXjrYkW+nNCw== X-CSE-MsgGUID: cn9qJY3cQeqnLfy6CshmRQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="272186120" Received: from skuppusw-desk2.jf.intel.com ([10.165.154.101]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:03 -0700 From: Kuppuswamy Sathyanarayanan To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Rafael J Wysocki , Guixin Liu , Olof Johansson Subject: [PATCH v13 3/5] PCI/ACPI: Tidy _OSC control bit checking Date: Sat, 19 Sep 2026 09:26:53 -0700 Message-ID: <20260919162655.3499010-4-sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> References: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add OSC_OWNER() helper to prettify checking the _OSC control bits to learn whether the platform has granted us control of PCI features. No functional change intended. [bhelgaas: split to separate patch, commit log] Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki (Intel) --- Changes since v12 * Rebased to v7.3-rc3. Parenthesized the OSC_OWNER() arguments, as checkpatch --strict asks. * Also convert native_cxl_error, which v12 left open coded. Its bit comes from the extended control word, so that word gets its own ext_ctrl local. v12 posting https://lore.kernel.org/all/20201126011816.711106-1-helgaas@kernel.org/ drivers/acpi/pci_root.c | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c index 88c65f34e305..756dc2f055f5 100644 --- a/drivers/acpi/pci_root.c +++ b/drivers/acpi/pci_root.c @@ -993,6 +993,12 @@ static void acpi_pci_root_release_info(struct pci_host= _bridge *bridge) __acpi_pci_root_release_info(bridge->release_data); } =20 +#define OSC_OWNER(ctrl, bit, flag) \ + do { \ + if (!((ctrl) & (bit))) \ + flag =3D 0; \ + } while (0) + struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root, struct acpi_pci_root_ops *ops, struct acpi_pci_root_info *info, @@ -1003,6 +1009,7 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_= root *root, int node =3D acpi_get_node(device->handle); struct pci_bus *bus; struct pci_host_bridge *host_bridge; + u32 ctrl, ext_ctrl; =20 info->root =3D root; info->bridge =3D device; @@ -1028,21 +1035,21 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pc= i_root *root, goto out_release_info; =20 host_bridge =3D to_pci_host_bridge(bus->bridge); - if (!(root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL)) - host_bridge->native_pcie_hotplug =3D 0; - if (!(root->osc_control_set & OSC_PCI_SHPC_NATIVE_HP_CONTROL)) - host_bridge->native_shpc_hotplug =3D 0; - if (!(root->osc_control_set & OSC_PCI_EXPRESS_AER_CONTROL)) - host_bridge->native_aer =3D 0; - if (!(root->osc_control_set & OSC_PCI_EXPRESS_PME_CONTROL)) - host_bridge->native_pme =3D 0; - if (!(root->osc_control_set & OSC_PCI_EXPRESS_LTR_CONTROL)) - host_bridge->native_ltr =3D 0; - if (!(root->osc_control_set & OSC_PCI_EXPRESS_DPC_CONTROL)) - host_bridge->native_dpc =3D 0; - - if (!(root->osc_ext_control_set & OSC_CXL_ERROR_REPORTING_CONTROL)) - host_bridge->native_cxl_error =3D 0; + + ctrl =3D root->osc_control_set; + ext_ctrl =3D root->osc_ext_control_set; + + OSC_OWNER(ctrl, OSC_PCI_EXPRESS_NATIVE_HP_CONTROL, + host_bridge->native_pcie_hotplug); + OSC_OWNER(ctrl, OSC_PCI_SHPC_NATIVE_HP_CONTROL, + host_bridge->native_shpc_hotplug); + OSC_OWNER(ctrl, OSC_PCI_EXPRESS_AER_CONTROL, host_bridge->native_aer); + OSC_OWNER(ctrl, OSC_PCI_EXPRESS_PME_CONTROL, host_bridge->native_pme); + OSC_OWNER(ctrl, OSC_PCI_EXPRESS_LTR_CONTROL, host_bridge->native_ltr); + OSC_OWNER(ctrl, OSC_PCI_EXPRESS_DPC_CONTROL, host_bridge->native_dpc); + + OSC_OWNER(ext_ctrl, OSC_CXL_ERROR_REPORTING_CONTROL, + host_bridge->native_cxl_error); =20 acpi_dev_power_up_children_with_adr(device); =20 --=20 2.43.0 From nobody Thu Sep 24 21:48:27 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B38C38238F; Sat, 19 Sep 2026 16:27:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835227; cv=none; b=fs97ZFVIcnfPtbmHBPaMR95jiug807BYEU/7yRfaeNxXDH5lg3GRKGw0u2HjD6SIvrxfjdWTtaNNhDV863I44/2w+FSPKQA9IhH9Fwm+oIfx2ONeTcoWofcuZlbEPJWd1nGaj/kw3fq/JXZ9cBNp0guYk0Y/eBuSAK88sLNh4KY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835227; c=relaxed/simple; bh=OB6tUklnujCL2ztPGJDJRm5mITRc6KPTZ3Q5OKu5h+M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jaSr/eOSx8l17tzCgQ2gAnYXgn+MUXgNJIsXr2d16nKUoQ4E2H8TFN2J6JkZOjW+D4a8UhyDPVIVTMUiaZ5JA7s/h0OMivZS7uQ4aTREZNrldo4s/6kqTD07HXOU91Vp0z2KePYppD9aQ+HwXiHDtYsxVz0CqF23GtMQv771558= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EUICkFOV; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EUICkFOV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789835225; x=1821371225; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=OB6tUklnujCL2ztPGJDJRm5mITRc6KPTZ3Q5OKu5h+M=; b=EUICkFOVkm+Y/VYiDt82V0/BAX7vQOK53egSO+XM8xdSknZRqZUudvDW gSvkFbzshf9eE39XdzproUL234DbOEJROU9gBPH+MYR82NKcnqyitEkac INHxCrEasAkCJVJT7YtkpRGUAB7CtKyqiFv70/DT5PQLjVXT6MXGuDkk0 xp37G/sHino7SA5E13w1xr/69JLnDrJ8fP2USpjf2+/aC+MGZiiM5XbH/ SOq0eAUEHrDU9vT4dSt7PsZq+ys8szoIUgnV8J+QjiOgXw2Ned0MeIj3k tC+dlLDbs0y/ijNd3lwLcMqz69VweLxcAOpDKeqlw7dKIzCRM4nOkobK2 A==; X-CSE-ConnectionGUID: UZX1/kk+S2SJS1itf0Ha5A== X-CSE-MsgGUID: 8vp7QSFnQN2Jy7jWeSkssQ== X-IronPort-AV: E=McAfee;i="6800,10657,11910"; a="94187243" X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="94187243" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:03 -0700 X-CSE-ConnectionGUID: dlSilZXyRSiaiIjqvE5Y2g== X-CSE-MsgGUID: k0LO/7r+Q6iPs47IOJb/kw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="272186121" Received: from skuppusw-desk2.jf.intel.com ([10.165.154.101]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:03 -0700 From: Kuppuswamy Sathyanarayanan To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Rafael J Wysocki , Guixin Liu , Olof Johansson Subject: [PATCH v13 4/5] PCI/ACPI: Centralize pcie_ports_native checking Date: Sat, 19 Sep 2026 09:26:54 -0700 Message-ID: <20260919162655.3499010-5-sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> References: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If the user booted with "pcie_ports=3Dnative", we take control of the PCIe port services unconditionally, regardless of what _OSC says. Centralize the testing of pcie_ports_native in acpi_pci_root_create(), where we interpret the _OSC results, so other places only have to check host_bridge->native_X and we don't have to sprinkle tests of pcie_ports_native everywhere. Rather than overriding the host_bridge->native_X flags after the fact, fold "pcie_ports=3Dnative" into the _OSC control mask we evaluate, i.e., proceed as though the platform had granted control of the port services. That way there is a single mechanism deciding each native_X flag, and we can report exactly which features we are overriding _OSC for instead of just noting that we are overriding something: acpi PNP0A08:00: _OSC: OS forcing control ("pcie_ports=3Dnative") of [PCI= eHotplug PME AER DPC] This also extends "pcie_ports=3Dnative" to host_bridge->native_dpc, which had no pcie_ports_native fallback before. The effect is narrow. native_dpc is only used by pci_dpc_recovered(), and only when CONFIG_PCIE_EDR=3Dn, where hotplug now waits for firmware-owned DPC recovery. host_bridge->native_ltr is deliberately not forced. "pcie_ports=3D" controls PCIe port services and LTR is not one. There is no PCIE_PORT_SERVICE_LTR, and native_ltr is only used by pci_configure_ltr() to enable ASPM L1.2, so forcing it would be an ASPM policy decision users did not ask for. SHPC hotplug is left alone for a simpler reason: SHPC is a conventional PCI feature rather than a PCIe one, so "pcie_ports=3D" has no bearing on it. [bhelgaas: commit log, rework OSC_PCIE_PORT_SERVICE_CONTROLS, logging] Link: https://lore.kernel.org/r/bc87c9e675118960949043a832bed86bc22becbd.16= 03766889.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki (Intel) # ACPI core --- Changes since v12 * Rebased to v7.3-rc3. * Fold "pcie_ports=3Dnative" into the _OSC control mask instead of overriding the native_X flags afterwards, and report which features we override, as agreed in the v12 review. * Do not force native_ltr, which v12 did. LTR is not a PCIe port service, so "pcie_ports=3D" should not affect it. v12 posting https://lore.kernel.org/all/20201126011816.711106-1-helgaas@kernel.org/ drivers/acpi/pci_root.c | 36 +++++++++++++++++++++++++++++++ drivers/pci/hotplug/pciehp_core.c | 2 +- drivers/pci/pci-acpi.c | 3 --- drivers/pci/pcie/aer.c | 6 +++--- drivers/pci/pcie/aer_cxl_rch.c | 2 +- drivers/pci/pcie/err.c | 2 +- drivers/pci/pcie/portdrv.c | 6 +++--- 7 files changed, 45 insertions(+), 12 deletions(-) diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c index 756dc2f055f5..2494811dd69b 100644 --- a/drivers/acpi/pci_root.c +++ b/drivers/acpi/pci_root.c @@ -999,6 +999,19 @@ static void acpi_pci_root_release_info(struct pci_host= _bridge *bridge) flag =3D 0; \ } while (0) =20 +#define FLAG(x) ((x) ? '+' : '-') + +/* + * _OSC control bits for the features implemented by the PCIe port driver, + * i.e., the ones "pcie_ports=3Dnative" applies to. LTR and SHPC hotplug = are + * negotiated via _OSC as well, but they are not portdrv services, so + * "pcie_ports=3D" has no bearing on them. + */ +#define OSC_PCIE_PORT_SERVICE_CONTROLS (OSC_PCI_EXPRESS_NATIVE_HP_CONTROL = | \ + OSC_PCI_EXPRESS_PME_CONTROL | \ + OSC_PCI_EXPRESS_AER_CONTROL | \ + OSC_PCI_EXPRESS_DPC_CONTROL) + struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root, struct acpi_pci_root_ops *ops, struct acpi_pci_root_info *info, @@ -1039,6 +1052,21 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci= _root *root, ctrl =3D root->osc_control_set; ext_ctrl =3D root->osc_ext_control_set; =20 + /* + * If the user specified "pcie_ports=3Dnative", use the PCIe port + * services regardless of what _OSC says, i.e., proceed as though the + * platform had granted us control of them. This may conflict with + * firmware that expects to own those features. + */ + if (pcie_ports_native) { + u32 override =3D OSC_PCIE_PORT_SERVICE_CONTROLS & ~ctrl; + + if (override) + decode_osc_control(root, "OS forcing control (\"pcie_ports=3Dnative\") = of", + override); + ctrl |=3D override; + } + OSC_OWNER(ctrl, OSC_PCI_EXPRESS_NATIVE_HP_CONTROL, host_bridge->native_pcie_hotplug); OSC_OWNER(ctrl, OSC_PCI_SHPC_NATIVE_HP_CONTROL, @@ -1051,6 +1079,14 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci= _root *root, OSC_OWNER(ext_ctrl, OSC_CXL_ERROR_REPORTING_CONTROL, host_bridge->native_cxl_error); =20 + dev_info(&root->device->dev, "OS native features: SHPCHotplug%c PCIeHotpl= ug%c PME%c AER%c DPC%c LTR%c\n", + FLAG(host_bridge->native_shpc_hotplug), + FLAG(host_bridge->native_pcie_hotplug), + FLAG(host_bridge->native_pme), + FLAG(host_bridge->native_aer), + FLAG(host_bridge->native_dpc), + FLAG(host_bridge->native_ltr)); + acpi_dev_power_up_children_with_adr(device); =20 pci_scan_child_bus(bus); diff --git a/drivers/pci/hotplug/pciehp_core.c b/drivers/pci/hotplug/pciehp= _core.c index 2cafd3b26f34..b42829cf1377 100644 --- a/drivers/pci/hotplug/pciehp_core.c +++ b/drivers/pci/hotplug/pciehp_core.c @@ -258,7 +258,7 @@ static bool pme_is_native(struct pcie_device *dev) const struct pci_host_bridge *host; =20 host =3D pci_find_host_bridge(dev->port->bus); - return pcie_ports_native || host->native_pme; + return host->native_pme; } =20 static void pciehp_disable_interrupt(struct pcie_device *dev) diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index 42d545edd7fa..1150f2fbabf4 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -812,9 +812,6 @@ bool pciehp_is_native(struct pci_dev *bridge) if (!IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE)) return false; =20 - if (pcie_ports_native) - return true; - host =3D pci_find_host_bridge(bridge->bus); return host->native_pcie_hotplug; } diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index d8dcd238fda1..e84dd686582a 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -260,7 +260,7 @@ int pcie_aer_is_native(struct pci_dev *dev) if (!dev->aer_cap) return 0; =20 - return pcie_ports_native || host->native_aer; + return host->native_aer; } EXPORT_SYMBOL_NS_GPL(pcie_aer_is_native, "CXL"); =20 @@ -1847,7 +1847,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev= *dev) */ aer =3D root ? root->aer_cap : 0; =20 - if ((host->native_aer || pcie_ports_native) && aer) + if (host->native_aer && aer) aer_disable_irq(root); =20 if (type =3D=3D PCI_EXP_TYPE_RC_EC || type =3D=3D PCI_EXP_TYPE_RC_END) { @@ -1862,7 +1862,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev= *dev) pci_is_root_bus(dev->bus) ? "Root" : "Downstream", rc); } =20 - if ((host->native_aer || pcie_ports_native) && aer) { + if (host->native_aer && aer) { /* Clear Root Error Status */ pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, ®32); pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32); diff --git a/drivers/pci/pcie/aer_cxl_rch.c b/drivers/pci/pcie/aer_cxl_rch.c index e471eefec9c4..b480dad8bbf4 100644 --- a/drivers/pci/pcie/aer_cxl_rch.c +++ b/drivers/pci/pcie/aer_cxl_rch.c @@ -31,7 +31,7 @@ static bool cxl_error_is_native(struct pci_dev *dev) { struct pci_host_bridge *host =3D pci_find_host_bridge(dev->bus); =20 - return (pcie_ports_native || host->native_aer); + return host->native_aer; } =20 static int cxl_rch_handle_error_iter(struct pci_dev *dev, void *data) diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index d77403d8855b..1a7fc71c79d8 100644 --- a/drivers/pci/pcie/err.c +++ b/drivers/pci/pcie/err.c @@ -273,7 +273,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, * it is responsible for clearing this status. In that case, the * signaling device may not even be visible to the OS. */ - if (host->native_aer || pcie_ports_native) { + if (host->native_aer) { pcie_clear_device_status(dev); pci_aer_clear_nonfatal_status(dev); } diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c index a9cbfc1d2bc7..32fc623dd410 100644 --- a/drivers/pci/pcie/portdrv.c +++ b/drivers/pci/pcie/portdrv.c @@ -223,7 +223,7 @@ static int get_port_device_capability(struct pci_dev *d= ev) if (dev->is_pciehp && (pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_ROOT_PORT || pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_DOWNSTREAM) && - (pcie_ports_native || host->native_pcie_hotplug)) { + host->native_pcie_hotplug) { services |=3D PCIE_PORT_SERVICE_HP; =20 /* @@ -240,14 +240,14 @@ static int get_port_device_capability(struct pci_dev = *dev) if ((pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_ROOT_PORT || pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_RC_EC) && dev->aer_cap && pci_aer_available() && - (pcie_ports_native || host->native_aer)) + host->native_aer) services |=3D PCIE_PORT_SERVICE_AER; #endif =20 /* Root Ports and Root Complex Event Collectors may generate PMEs */ if ((pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_ROOT_PORT || pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_RC_EC) && - (pcie_ports_native || host->native_pme)) { + host->native_pme) { services |=3D PCIE_PORT_SERVICE_PME; =20 /* --=20 2.43.0 From nobody Thu Sep 24 21:48:27 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DADE13890F0; Sat, 19 Sep 2026 16:27:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835238; cv=none; b=qzV3KJs8EYNqtv1sWMWxTRgu4cRlpNBbA7c3gCnIKpwnU8FLjffrcVNIl0THvyyUt5O1JCp0dDGHJlHPWMsFZQe+eFxYjQNaCgA8S4s0NxGD8cTKmgsqSc2fhV5mtgTltM913td2/usUgr3ZbiubfGLoY8nQkseAXTzUs1DTIKg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789835238; c=relaxed/simple; bh=hMEIkU0IZiY8MhFIZ3Isk3Eao21uFP9lZDWi9G1NZH4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uTu8fTpaU5RGOmatszJLAZBmyN0ZRj8g+esJ1A3IKNL7DWWe+onb2u3Fxxg5TFyBf+cky9Rlhoa7+V20LE0cUok0hcfjuLtedVXnRJPVH+IyNMtNhcM3pQP1TmCAvlNnAML11TU0IjsduW+tD97thzw9FBUubiQZ1+fsj1Qsius= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=lpEn7e+t; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="lpEn7e+t" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789835227; x=1821371227; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hMEIkU0IZiY8MhFIZ3Isk3Eao21uFP9lZDWi9G1NZH4=; b=lpEn7e+taYnXUjv7/9eYZnremZxhOK1rgLpnG+NDmtQlI+KGKwC6xWsW n4aMv6HNblhBnpm7I5VSZ3HFY0UOXJF5/pY7CG0RpjHeh+Gr+yylRFRcO nAG7W9937cpDR9WtpSOgy/NzzSc6sobW3IgVSX5GrlPVg0YMk0X1JWE8n 4MjdS32N1d9AoHx8PUqT2HBBcwQR5JVNPCyS3P7NNy0FXkRCA/yObHQLR WXJfZR7lycah2fRT7zUIXOZWEQk3+zAhvE3r0ukScg4triPz6YAAgV7sh eu4SeprDVeslROsWrGMD/ZExSipLO/aCwev1vknC1J9/OqIvLQPkb3BV8 Q==; X-CSE-ConnectionGUID: qBi3S0ktT9WZIlcUpEQ0jw== X-CSE-MsgGUID: O8wBMZpsSMex+E61IAEldg== X-IronPort-AV: E=McAfee;i="6800,10657,11910"; a="94187248" X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="94187248" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:03 -0700 X-CSE-ConnectionGUID: omDgAUvATJ6xj50wW72h5g== X-CSE-MsgGUID: 8Xg3kZzSSyap4gE7ZQ217w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,111,1787036400"; d="scan'208";a="272186122" Received: from skuppusw-desk2.jf.intel.com ([10.165.154.101]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2026 09:27:03 -0700 From: Kuppuswamy Sathyanarayanan To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Rafael J Wysocki , Guixin Liu , Olof Johansson Subject: [PATCH v13 5/5] PCI: Centralize pci_aer_available() checking Date: Sat, 19 Sep 2026 09:26:55 -0700 Message-ID: <20260919162655.3499010-6-sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> References: <20260919162655.3499010-1-sathyanarayanan.kuppuswamy@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bjorn Helgaas "pci=3Dnoaer" tells us not to use AER. pci_aer_available() reports that, and it also reports the other cases where the OS cannot use AER at all, namely CONFIG_PCIEAER=3Dn and MSI being unavailable. Set host_bridge->native_aer from pci_aer_available() when we initialize the host bridge, so callers only have to look at native_aer and we do not have to test pci_aer_available() separately in each of them. Do this in pci_init_host_bridge() rather than in acpi_pci_root_create() so it also covers host bridges that are not described by ACPI and never reach acpi_pci_root_create(). Signed-off-by: Bjorn Helgaas Co-developed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Kuppuswamy Sathyanarayanan --- Changes since v12 * Rebased to v7.3-rc3. * Set native_aer from pci_aer_available() in pci_init_host_bridge() rather than clearing it in acpi_pci_root_create(), so "pci=3Dnoaer" also works on host bridges that ACPI does not describe. * pci_aer_available() stays in the DPC arm of get_port_device_capability(), where pcie_ports_dpc_native still needs it. v12 posting https://lore.kernel.org/all/20201126011816.711106-1-helgaas@kernel.org/ drivers/pci/pcie/portdrv.c | 3 +-- drivers/pci/probe.c | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c index 32fc623dd410..9f8c6dd434c5 100644 --- a/drivers/pci/pcie/portdrv.c +++ b/drivers/pci/pcie/portdrv.c @@ -239,8 +239,7 @@ static int get_port_device_capability(struct pci_dev *d= ev) #ifdef CONFIG_PCIEAER if ((pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_ROOT_PORT || pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_RC_EC) && - dev->aer_cap && pci_aer_available() && - host->native_aer) + dev->aer_cap && host->native_aer) services |=3D PCIE_PORT_SERVICE_AER; #endif =20 diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 5f7eb6bc438b..0429f5671c63 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -669,7 +669,7 @@ static void pci_init_host_bridge(struct pci_host_bridge= *bridge) * OS from interfering. */ #ifdef CONFIG_PCIEPORTBUS - bridge->native_aer =3D 1; + bridge->native_aer =3D pci_aer_available(); bridge->native_pcie_hotplug =3D 1; bridge->native_pme =3D 1; bridge->native_dpc =3D 1; --=20 2.43.0