Cover Letter Detail
Show a cover letter.
GET /api/1.1/covers/2230417/?format=api
{ "id": 2230417, "url": "http://patchwork.ozlabs.org/api/1.1/covers/2230417/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-pci/cover/20260429180647.197072-1-thomas.falcon@intel.com/", "project": { "id": 28, "url": "http://patchwork.ozlabs.org/api/1.1/projects/28/?format=api", "name": "Linux PCI development", "link_name": "linux-pci", "list_id": "linux-pci.vger.kernel.org", "list_email": "linux-pci@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null }, "msgid": "<20260429180647.197072-1-thomas.falcon@intel.com>", "date": "2026-04-29T18:06:42", "name": "[RFC,0/4] pcie/aspm: Enable all advertised ASPM states by default", "submitter": { "id": 93044, "url": "http://patchwork.ozlabs.org/api/1.1/people/93044/?format=api", "name": "Falcon, Thomas", "email": "thomas.falcon@intel.com" }, "mbox": "http://patchwork.ozlabs.org/project/linux-pci/cover/20260429180647.197072-1-thomas.falcon@intel.com/mbox/", "series": [ { "id": 502124, "url": "http://patchwork.ozlabs.org/api/1.1/series/502124/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-pci/list/?series=502124", "date": "2026-04-29T18:06:44", "name": "pcie/aspm: Enable all advertised ASPM states by default", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/502124/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/2230417/comments/", "headers": { "Return-Path": "\n <linux-pci+bounces-53416-incoming=patchwork.ozlabs.org@vger.kernel.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-pci@vger.kernel.org" ], "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=XTepb1qc;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-53416-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)", "smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"XTepb1qc\"", "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=192.198.163.15", "smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=intel.com", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=intel.com" ], "Received": [ "from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5QJX2Wv6z1xqf\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 30 Apr 2026 04:07:56 +1000 (AEST)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 18DC63004264\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 29 Apr 2026 18:07:09 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id AE6B241B35F;\n\tWed, 29 Apr 2026 18:07:03 +0000 (UTC)", "from mgamail.intel.com (mgamail.intel.com [192.198.163.15])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 64C7E413222;\n\tWed, 29 Apr 2026 18:07:00 +0000 (UTC)", "from fmviesa003.fm.intel.com ([10.60.135.143])\n by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 29 Apr 2026 11:06:54 -0700", "from iherna2-mobl4.amr.corp.intel.com (HELO tfalcon-desk.intel.com)\n ([10.124.221.251])\n by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 29 Apr 2026 11:06:53 -0700" ], "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777486023; cv=none;\n b=CuwWUbtMJ09GjdDDFXy54eur8rpYoW6r1tdUZqH0VhBMZWkqagthQOCnizrzFdXRJDLJ6x4o0Jsd6V3a/1kCRHjU/S01o5JLtmYwEFhffmvUQ5YmEdHzA2Ii3D8CQIPYB+4dVg+UmPEacXDUVefuh8BErKABfCahqx7ImqWCWmo=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777486023; c=relaxed/simple;\n\tbh=/xqUyS0Nu6H02iDqmvzGe/xfNqDuvDK/AgOJphjGTes=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type;\n b=h9tHYnL3bJsurvAI40kA9olyTUbPUEkcm2leMlWfraonvkjvjZVL6ABK4YVG+2vOqOuhPU5QDittmJihxc7/265t9Y4GEMVipNkzPqj+FOndquylGzJ/Ko6dPnv6Vp3EkrztVEqJ8AxuAM0Slnu/F+3jZ/UDdekJ8WXB7FsFEXg=", "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=intel.com;\n spf=pass smtp.mailfrom=intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=XTepb1qc; arc=none smtp.client-ip=192.198.163.15", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1777486021; x=1809022021;\n h=from:to:cc:subject:date:message-id:mime-version:\n content-transfer-encoding;\n bh=/xqUyS0Nu6H02iDqmvzGe/xfNqDuvDK/AgOJphjGTes=;\n b=XTepb1qc4+b4MkiJXGPyZWlAxQQqJ1wKqxKDcViIiWTRoRG6ZxCcnPVZ\n Sn01KWqPpz9/o4jMgj9IkOikqVvpIdP1WK8ScI//Td0B0N9If3bGcR4zP\n cbOzVh5yI09jfVRWmhbMFoy7VEjyCXnnbO4bYju41C4k0g4vBqISeeg3H\n xl8+yI1MY3r2+G8kx8Ye8IIAa3XIlZr7ImlHkKG43rfNfL6T66Q6I2D5j\n z8xAKKGVKWegIFV3G76d6SYpP4uEFdapKzO4ubWBR7As9F0tQdXqhHJZp\n FfdHQnM6FsNow1y3Tkr3xXNGBBH55wqtLtTEbAU3gBx4P/XPwu+D5/HLi\n w==;", "X-CSE-ConnectionGUID": [ "FH9e4M03T7Cv2i/7UVPy8g==", "NkYtTC8USS2bbeuKoGjrfQ==" ], "X-CSE-MsgGUID": [ "UgOP8FbHSUyaLxDAwtdmwg==", "uJ5hh9mnQDycBeLyC2PWmA==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6800,10657,11771\"; a=\"78532267\"", "E=Sophos;i=\"6.23,206,1770624000\";\n d=\"scan'208\";a=\"78532267\"" ], "X-ExtLoop1": "1", "From": "Thomas Falcon <thomas.falcon@intel.com>", "To": "Bjorn Helgaas <bhelgaas@google.com>,\n\t\"Rafael J . Wysocki\" <rafael@kernel.org>", "Cc": "\"David E . Box\" <david.e.box@linux.intel.com>,\n\tLukas Wunner <lukas@wunner.de>,\n\tManivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,\n\tLen Brown <lenb@kernel.org>,\n\tlinux-pci@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org,\n\tThomas Falcon <thomas.falcon@intel.com>", "Subject": "[RFC PATCH 0/4] pcie/aspm: Enable all advertised ASPM states by\n default", "Date": "Wed, 29 Apr 2026 13:06:42 -0500", "Message-ID": "<20260429180647.197072-1-thomas.falcon@intel.com>", "X-Mailer": "git-send-email 2.43.0", "Precedence": "bulk", "X-Mailing-List": "linux-pci@vger.kernel.org", "List-Id": "<linux-pci.vger.kernel.org>", "List-Subscribe": "<mailto:linux-pci+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-pci+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=UTF-8", "Content-Transfer-Encoding": "8bit" }, "content": "Hi Bjorn, Rafael, all,\n\nThis series follows up on the discussion from August 2025 about ASPM\ndefault behavior and enabling all advertised link power states by\ndefault [1].\n\nToday, ASPM behavior is influenced first by build-time configuration\n(CONFIG_PCIEASPM_*), along with firmware-provided defaults. The reliance\non Kconfig for policy selection and the current two-phase configuration\nmodel (initial safe setup followed by a later, more aggressive\ndriver-triggered configuration) complicate both usage and maintenance.\n\nThe direction discussed was to move toward a model where the OS enables\nall supported ASPM states by default, while still respecting platform\npolicy (FADT, _OSC), driver constraints, and user overrides.\n\nThis series is an RFC to explore that direction and gather feedback.\n\nSpecifically, it:\n\n Enables all advertised ASPM states by default via the existing\n policy framework, which respects capability masks, blacklist\n restrictions, and user configuration.\n Consolidates ASPM configuration into a single initialization step,\n instead of the current two-phase model (pre-driver “safe” init\n followed by driver-probe adjustments). This simplifies behavior and\n reduces maintenance complexity.\n Adds detailed debug instrumentation to make ASPM configuration\n decisions and transitions more visible, helping to evaluate impact\n and identify mismatches with firmware expectations.\n Limits the default behavior change to newer systems using a DMI BIOS\n year check (>= 2025). This is intended to reduce risk on legacy\n platforms where firmware expectations or device behavior may not\n tolerate more aggressive ASPM enablement.\n Removes CONFIG_PCIEASPM_* policy selections in favor of runtime\n policy selection, simplifying configuration and making behavior\n more consistent.\n\nThis RFC is not intended for immediate upstreaming, but to evaluate the\nfeasibility and impact of this approach.\n\nThis does not address synthetic PCIe hierarchies (e.g. VMD), which may\nlack valid firmware policy entirely. Those cases likely require\ntargeted handling and are left for follow-on work so that the core\ndefaulting model can be evaluated independently.\n\nFeedback is especially welcome on:\n\n The DMI-based gating approach for limiting rollout risk\n Whether this correctly captures “enable all advertised states”\n The removal of Kconfig-based policy selection\n The shift from a two-phase to single-phase configuration model\n\n[1] https://lore.kernel.org/linux-pci/20250828204345.GA958461@bhelgaas/\n\nThomas Falcon (4):\n pcie/aspm: Add debug logging for aspm policy config\n pcie/aspm: Enable all power-saving states during link state\n initialization\n pcie/aspm: Enable all hardware power-saving states by default\n pcie/aspm: Remove CONFIG_PCIEASPM_* policy definitions\n\n Documentation/arch/x86/amd-debugging.rst | 5 +-\n arch/mips/configs/bmips_stb_defconfig | 1 -\n arch/mips/configs/loongson2k_defconfig | 1 -\n drivers/pci/pci-acpi.c | 4 +-\n drivers/pci/pcie/Kconfig | 33 ---------\n drivers/pci/pcie/aspm.c | 87 +++++++++++++++++++-----\n include/linux/pci.h | 1 +\n 7 files changed, 77 insertions(+), 55 deletions(-)" }