From: Bjorn Helgaas <helgaas@kernel.org>
To: linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org
Cc: Austin Bolen <Austin.Bolen@dell.com>,
Alex Williamson <alex.williamson@redhat.com>,
Kai-Heng Feng <kai.heng.feng@canonical.com>
Subject: Lack of _HPX after reset, DPC
Date: Mon, 15 Jul 2024 16:45:29 -0500 [thread overview]
Message-ID: <20240715214529.GA447149@bhelgaas> (raw)
I think Linux is missing some important _HPX functionality. Per ACPI
r6.5, sec 6.2.9,
OSPM uses the information returned by _HPX to determine how to
configure PCI Functions that are hot-plugged into the system, to
configure Functions not configured by the platform firmware during
initial system boot, and to configure Functions any time they lose
configuration space settings (e.g. OSPM issues a Secondary Bus
Reset/Function Level Reset or Downstream Port Containment is
triggered).
Linux currently *does* process _HPX for hot-added devices.
The spec doesn't call it out for boot-time enumeration, except for
"Functions not configured by the platform firmware during initial
system boot", but Linux does process _HPX for all devices enumerated
at boot-time because it's not clear how to identify devices that
weren't configured by firmware.
But AFAICT, Linux does not do anything with _HPX in the device reset,
AER, or DPC flows. I don't have any problem reports that I can say
are caused by lack of _HPX after reset, but it seems like something we
should fix.
If we could find a system with _HPX that does something interesting,
we might be able to demonstrate a defect by looking at a device before
and after a reset.
Bjorn
next reply other threads:[~2024-07-15 21:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 21:45 Bjorn Helgaas [this message]
2024-07-29 2:24 ` Lack of _HPX after reset, DPC Kai-Heng Feng
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=20240715214529.GA447149@bhelgaas \
--to=helgaas@kernel.org \
--cc=Austin.Bolen@dell.com \
--cc=alex.williamson@redhat.com \
--cc=kai.heng.feng@canonical.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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).