Message ID | 20240222221521.32159-1-helgaas@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-77456-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp244953dyb; Thu, 22 Feb 2024 14:15:50 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCV7TVzCwYOw9UxDnHZRU8CBq7A8w12KU9qElHmPCsGrMtsP4WGQA1Gz3hjTPZC00IxvYI4Obj09RT1rxa3rzCPmVLv3mw== X-Google-Smtp-Source: AGHT+IG8SwYLkg+aLnQneaBCJtlAmadf3u/AGS+9YL1798guxkPGtcEnXvTA+svfMbCCoCkSlhUq X-Received: by 2002:a17:907:11d0:b0:a3e:599:ae86 with SMTP id va16-20020a17090711d000b00a3e0599ae86mr3529811ejb.9.1708640150073; Thu, 22 Feb 2024 14:15:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708640150; cv=pass; d=google.com; s=arc-20160816; b=CYjQJps7kgpcRHeXVwmSOohnHKCDDNx4VDtFIWFXna5/Q99qMFR+bgct3jud1fYLip MCDH/ujx+T6wy/oAzNBgp1Rn3bPcotEmgwVc3VH7Q1NmMzNeqPflickFZGTQHyExLv5D 2OMutiCFe6gON+CnE3Z/PeCXVFKJ7w53eNM6NcO0Y200N4xN9cMfXKqsWL1+Z7r0Snlb jToyyBg5hCAsx1tPzl/Ilf+Vk2BIuxv7mCvYw5nMbsOtSLyDP1utQbIvq7N1qRFsejvN QLkgilrABwoMX/YxJSqH+QLFeI2YJAGo091LHTN9AnlJ8+kx/HhkY+h9MIoyIQFaE3it rmwA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=mgoCwJyiicbWExtZrmjtpGU6OOx2xiFd90a9Fc1D9Sc=; fh=DQlX4VOMXAZHEB/OHnjBToSsYwvB2UyOs7+/HRg3P7c=; b=l9Pu8mO0wr9vsQMYaRdWoPhH7vJXX4ID8T3O0obUcXn6Pxzx0Xz9ol7nEvCMh5Ke/g /z7+kPdsdoHCNmv3y+C6Hs1WJEzD+x+BseDJYXBIS3vVoyyiQ8ezP7aNqbSzNxzJ1DVi GwpkFOOKBoq6+ehjtVSVYbOWj9CqbrZ0TldzQ549ty0Cq8wmos4Z7EtgabPMJaUD5Hbg NWPTGATimxJtisAgjpEX2U4Vf1Re9ocBueGzhtvttNWvUCxWrf+vhFX09OvZEkHnz7xN DnByBBACw83pP5ZffYb/EMvD6ND8QSvkNDbBf6GNuEfbhH9AdD7wZw/qrxUrY/opacm+ 5Y1g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dzUWt68G; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-77456-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-77456-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id hh11-20020a170906a94b00b00a3f43e48052si1760563ejb.525.2024.02.22.14.15.49 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 14:15:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-77456-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dzUWt68G; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-77456-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-77456-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id ACCD71F26822 for <ouuuleilei@gmail.com>; Thu, 22 Feb 2024 22:15:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C7A4C137916; Thu, 22 Feb 2024 22:15:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dzUWt68G" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 32FC314B81E; Thu, 22 Feb 2024 22:15:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708640134; cv=none; b=esZEkTfVv7OSd94EtkbZ1jcApBui8fbqcyqej1Z7UgQPHU8pMUVr/Tu3KRZ4n94B3BDKzgIIJDoa6FqT46oCzI9vWQ0eO8KWsrdD8eGWmXbs6iAntBKDrglryLQOQHLig/kIm3Q2I4ZGC7iC96eeCozVCDDvKAJEfwI2RlT/xSM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708640134; c=relaxed/simple; bh=P5o8neBVE3O5U/nFyHiW0oafwt0FP0+GwbHlvNgjyZA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=MUX+s0FZiF4/CBvIhVpwahv5Fe20a8sgXi/wPAmQF7MCgF7ljt715dMUQ7MYJTm9EAKWz8qerqZVJOqigHK8VGfzLsa0Km9iT20T5i1SfLgP19merTvCIxOlIrUgp33si9dvXdUkecMXboDpFBocmMji/Yz4o3QJy+pCVUc8jS0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dzUWt68G; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93129C433C7; Thu, 22 Feb 2024 22:15:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708640133; bh=P5o8neBVE3O5U/nFyHiW0oafwt0FP0+GwbHlvNgjyZA=; h=From:To:Cc:Subject:Date:From; b=dzUWt68Gv56NC3EUZr9w0My1v0hnD1jcQWUCyb0KYc223c5ZBDIXAPSjoQipFuiB7 bbkftEo4m9OJqaKgdK2ourtaXcLszjJ8qZPVTwAwdmwv5pdkVku26OdVmzhWYmhR9j KrpgauZC+5B+bWg6JrqAPWIxYzfwP46G4er7337kkiyskznOMeALd0scYDelyJGlZ3 Vqd8Sc3Agr8228ncZjeIyck13KClL8bJrCYaY8wcUoYILw6JySbll+7SHJ25frnQI1 rP08lXypFBPbORBYZIFGpZw5CY0Z6h3zcBORtkzUMuLoPtheHx+xMQkLPO3zJay5+i tRe3KaWlrM2Ow== From: Bjorn Helgaas <helgaas@kernel.org> To: linux-pci@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, 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: [PATCH v2 0/3] PCI/DPC: Clean up DPC vs AER/EDR ownership and Kconfig Date: Thu, 22 Feb 2024 16:15:18 -0600 Message-Id: <20240222221521.32159-1-helgaas@kernel.org> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791639054193584083 X-GMAIL-MSGID: 1791639054193584083 |
Series |
PCI/DPC: Clean up DPC vs AER/EDR ownership and Kconfig
|
|
Message
Bjorn Helgaas
Feb. 22, 2024, 10:15 p.m. UTC
From: Bjorn Helgaas <bhelgaas@google.com>
Previously we could request control of DPC without AER, which is illegal
per spec. Also, we could enable CONFIG_PCIE_DPC without CONFIG_PCIE_EDR,
which is also illegal. This series addresses both.
Bjorn Helgaas (3):
PCI/DPC: Request DPC only if also requesting AER
PCI/DPC: Remove CONFIG_PCIE_EDR
PCI/DPC: Encapsulate pci_acpi_add_edr_notifier()
drivers/acpi/pci_root.c | 22 ++++++++++++----------
drivers/pci/pci.h | 4 ++++
drivers/pci/pcie/Kconfig | 14 ++++----------
drivers/pci/pcie/Makefile | 5 ++++-
drivers/pci/pcie/dpc.c | 10 ----------
include/linux/pci-acpi.h | 8 --------
6 files changed, 24 insertions(+), 39 deletions(-)
Comments
On 2/23/2024 6:15 AM, Bjorn Helgaas wrote: > From: Bjorn Helgaas <bhelgaas@google.com> > > Previously we could request control of DPC without AER, which is illegal > per spec. Also, we could enable CONFIG_PCIE_DPC without CONFIG_PCIE_EDR, > which is also illegal. This series addresses both. I have a question here, how to understand the relationship EDR & AER ? somewhere EDR touches AER status without checking _OSC granted bits, such as pci_aer_raw_clear_status(edev); sometimes EDR calling AER with host->native_aer checked, like pcie_do_recovery() { ... if (host->native_aer || pcie_ports_native) { pcie_clear_device_status(dev); pci_aer_clear_nonfatal_status(dev); } ... } That is really confusing. could we do some cleanup to eliminate it ? such as seperate AER code into common code and runtime part. Thanks, Ethan > > Bjorn Helgaas (3): > PCI/DPC: Request DPC only if also requesting AER > PCI/DPC: Remove CONFIG_PCIE_EDR > PCI/DPC: Encapsulate pci_acpi_add_edr_notifier() > > drivers/acpi/pci_root.c | 22 ++++++++++++---------- > drivers/pci/pci.h | 4 ++++ > drivers/pci/pcie/Kconfig | 14 ++++---------- > drivers/pci/pcie/Makefile | 5 ++++- > drivers/pci/pcie/dpc.c | 10 ---------- > include/linux/pci-acpi.h | 8 -------- > 6 files changed, 24 insertions(+), 39 deletions(-) >
Hi, On 2/26/24 10:18 PM, Ethan Zhao wrote: > On 2/23/2024 6:15 AM, Bjorn Helgaas wrote: >> From: Bjorn Helgaas <bhelgaas@google.com> >> >> Previously we could request control of DPC without AER, which is illegal >> per spec. Also, we could enable CONFIG_PCIE_DPC without CONFIG_PCIE_EDR, >> which is also illegal. This series addresses both. > > I have a question here, how to understand the relationship EDR & AER ? > somewhere EDR touches AER status without checking _OSC granted bits, > such as > pci_aer_raw_clear_status(edev); Which_OSC bits? EDR code will only get triggered if OS advertises the EDR support (which also means OS supports AER and DPC), and both AER and DPC is owned by the firmware. During the EDR notification, the OS is allowed to touch AER and DPC registers. So there is no problem with EDR code using AER routines. > > sometimes EDR calling AER with host->native_aer checked, like > > pcie_do_recovery() > { > ... > if (host->native_aer || pcie_ports_native) { > pcie_clear_device_status(dev); > pci_aer_clear_nonfatal_status(dev); > } > ... > } > > That is really confusing. could we do some cleanup to eliminate it ? > such as seperate AER code into common code and runtime part. > > > Thanks, > Ethan > > >> >> Bjorn Helgaas (3): >> PCI/DPC: Request DPC only if also requesting AER >> PCI/DPC: Remove CONFIG_PCIE_EDR >> PCI/DPC: Encapsulate pci_acpi_add_edr_notifier() >> >> drivers/acpi/pci_root.c | 22 ++++++++++++---------- >> drivers/pci/pci.h | 4 ++++ >> drivers/pci/pcie/Kconfig | 14 ++++---------- >> drivers/pci/pcie/Makefile | 5 ++++- >> drivers/pci/pcie/dpc.c | 10 ---------- >> include/linux/pci-acpi.h | 8 -------- >> 6 files changed, 24 insertions(+), 39 deletions(-) >>
On 2/27/2024 2:35 PM, Kuppuswamy Sathyanarayanan wrote: > Hi, > > On 2/26/24 10:18 PM, Ethan Zhao wrote: >> On 2/23/2024 6:15 AM, Bjorn Helgaas wrote: >>> From: Bjorn Helgaas <bhelgaas@google.com> >>> >>> Previously we could request control of DPC without AER, which is illegal >>> per spec. Also, we could enable CONFIG_PCIE_DPC without CONFIG_PCIE_EDR, >>> which is also illegal. This series addresses both. >> I have a question here, how to understand the relationship EDR & AER ? >> somewhere EDR touches AER status without checking _OSC granted bits, >> such as >> pci_aer_raw_clear_status(edev); > > Which_OSC bits? > > EDR code will only get triggered if OS advertises the EDR support (which > also means OS supports AER and DPC), and both AER and DPC is owned by > the firmware. During the EDR notification, the OS is allowed to touch AER Means no need to check if host->native_aer ? why checked in pcie_do_recovery() ? Thanks, Ethan > and DPC registers. So there is no problem with EDR code using AER routines. > > >> sometimes EDR calling AER with host->native_aer checked, like >> >> pcie_do_recovery() >> { >> ... >> if (host->native_aer || pcie_ports_native) { >> pcie_clear_device_status(dev); >> pci_aer_clear_nonfatal_status(dev); >> } >> ... >> } >> >> That is really confusing. could we do some cleanup to eliminate it ? >> such as seperate AER code into common code and runtime part. >> >> >> Thanks, >> Ethan >> >> >>> Bjorn Helgaas (3): >>> PCI/DPC: Request DPC only if also requesting AER >>> PCI/DPC: Remove CONFIG_PCIE_EDR >>> PCI/DPC: Encapsulate pci_acpi_add_edr_notifier() >>> >>> drivers/acpi/pci_root.c | 22 ++++++++++++---------- >>> drivers/pci/pci.h | 4 ++++ >>> drivers/pci/pcie/Kconfig | 14 ++++---------- >>> drivers/pci/pcie/Makefile | 5 ++++- >>> drivers/pci/pcie/dpc.c | 10 ---------- >>> include/linux/pci-acpi.h | 8 -------- >>> 6 files changed, 24 insertions(+), 39 deletions(-) >>>
On 2/26/24 11:12 PM, Ethan Zhao wrote: > On 2/27/2024 2:35 PM, Kuppuswamy Sathyanarayanan wrote: >> Hi, >> >> On 2/26/24 10:18 PM, Ethan Zhao wrote: >>> On 2/23/2024 6:15 AM, Bjorn Helgaas wrote: >>>> From: Bjorn Helgaas <bhelgaas@google.com> >>>> >>>> Previously we could request control of DPC without AER, which is illegal >>>> per spec. Also, we could enable CONFIG_PCIE_DPC without CONFIG_PCIE_EDR, >>>> which is also illegal. This series addresses both. >>> I have a question here, how to understand the relationship EDR & AER ? >>> somewhere EDR touches AER status without checking _OSC granted bits, >>> such as >>> pci_aer_raw_clear_status(edev); >> >> Which_OSC bits? >> >> EDR code will only get triggered if OS advertises the EDR support (which >> also means OS supports AER and DPC), and both AER and DPC is owned by >> the firmware. During the EDR notification, the OS is allowed to touch AER > > Means no need to check if host->native_aer ? why checked in > pcie_do_recovery() ? pcie_do_recovery() can be called form EDR (FF) or native path. That check is used to skip device status clearing in FF mode. You can find details about it in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/pcie/err.c?id=068c29a248b6ddbfdf7bb150b547569759620d36 > > Thanks, > Ethan > >> and DPC registers. So there is no problem with EDR code using AER routines. >> >> >>> sometimes EDR calling AER with host->native_aer checked, like >>> >>> pcie_do_recovery() >>> { >>> ... >>> if (host->native_aer || pcie_ports_native) { >>> pcie_clear_device_status(dev); >>> pci_aer_clear_nonfatal_status(dev); >>> } >>> ... >>> } >>> >>> That is really confusing. could we do some cleanup to eliminate it ? >>> such as seperate AER code into common code and runtime part. >>> >>> >>> Thanks, >>> Ethan >>> >>>> Bjorn Helgaas (3): >>>> PCI/DPC: Request DPC only if also requesting AER >>>> PCI/DPC: Remove CONFIG_PCIE_EDR >>>> PCI/DPC: Encapsulate pci_acpi_add_edr_notifier() >>>> >>>> drivers/acpi/pci_root.c | 22 ++++++++++++---------- >>>> drivers/pci/pci.h | 4 ++++ >>>> drivers/pci/pcie/Kconfig | 14 ++++---------- >>>> drivers/pci/pcie/Makefile | 5 ++++- >>>> drivers/pci/pcie/dpc.c | 10 ---------- >>>> include/linux/pci-acpi.h | 8 -------- >>>> 6 files changed, 24 insertions(+), 39 deletions(-) >>>> >