Phoronix first highlighted the collection on August 26. The upstream PCI pull request confirms the key items and adds useful context: this is code queued for the in-development Linux 7.3 kernel, not a patch set that users of current stable distributions will receive immediately. For workstation administrators and dual-boot PC owners, the immediate takeaway is to distinguish between changes that unlock future hardware and the one change that addresses an observed failure on shipping hardware.
Advisory Non-Fatal errors become visible to Linux
The most consequential diagnostic change is Linux 7.3’s new handling for PCIe Advisory Non-Fatal errors, or ANFs. PCIe devices use Advanced Error Reporting, commonly called AER, to notify the operating system of link and transaction failures. Linux already separates correctable errors from uncorrectable non-fatal and fatal errors; the latter two can trigger driver recovery or reset paths depending on severity.
An Advisory Non-Fatal event is different from a conventional uncorrectable non-fatal error. It lets PCIe hardware flag a condition as advisory rather than force it into the more disruptive handling path. The upstream pull explicitly lists “Support Advisory Non-Fatal Errors” among AER changes, alongside improved mappings of errors to their originating agent and layer, per-error logging when several errors are captured together, and a reduction in duplicate Error Source messages.
That grouping is revealing. The practical benefit is observability, not proof that a previously broken device will now work. Linux’s current AER documentation already describes console logging, per-device counters, and rate limiting for noisy PCIe error reports. It also already includes “Advisory Non-Fatal” in examples of device error statistics. The 7.3 work therefore appears to close a gap between having a named statistic or hardware indication and correctly classifying and reporting the associated PCIe event through the kernel’s AER machinery.
That distinction will matter most to people debugging servers, high-speed storage, accelerators, and unusual PCIe topologies. An advisory event should give operators more information without being confused with an error that demands device recovery. But Linux 7.3 does not turn those reports into a simple health verdict. AER messages still require context: the reporting device, the type of transaction, recurrence, firmware version, and whether the driver recovered normally all determine whether an event is benign noise or an early warning of a failing link.
The PCI pull also specifies that TLP—Transaction Layer Packet—logs will be emitted only for unmasked errors. That should make kernel logs more useful in the cases where firmware or platform policy deliberately masks recurring conditions, while avoiding the implication that every captured hardware status bit deserves a noisy dump.
Intel VMD changes target future platforms and a current enumeration gap
Intel’s Volume Management Device, or VMD, driver is receiving several changes in the same pull. The driver is used where Intel exposes NVMe and other downstream PCIe devices behind a VMD controller, which is why its behavior can affect whether an installer, recovery environment, or operating system sees storage at all.
The upstream record adds VMD device IDs for Nova Lake and Dunlow, abbreviated NVL and DNL in the driver work. Device IDs are an early form of enablement: they allow the driver to recognize the controller when that silicon reaches systems, but they do not establish product configuration, performance characteristics, or operating-system support beyond that recognition path. Phoronix reported that Dunlow is believed to be an entry-level Xeon-oriented platform derived from Nova Lake, but the Linux merge itself only confirms the identifiers and does not define Intel’s commercial positioning.
More immediately useful is the new support for VMCONFIG BUS_RESTRICT_CFG=3. The upstream merge description says this makes it possible to enumerate downstream devices on Intel Arrow Lake-HX systems and “probably others.” In plain language, Linux previously encountered a bus-number configuration value that it could not interpret, causing VMD probing to abort rather than map the controller’s downstream hierarchy.
For administrators, this is a storage-discovery fix—not a generic Arrow Lake performance improvement. Its value lies in preventing a class of systems from losing visibility of devices behind VMD due to an unsupported controller configuration. Anyone deploying Linux to an Arrow Lake-HX laptop or workstation with firmware-configured VMD should still validate the actual distribution kernel, installer image, and firmware mode. The merged code is headed to Linux 7.3; it does not retroactively modify the kernel bundled with an older enterprise image.
The VMD changes also include a feature to scan devices already enumerated by BIOS and a correction so that root-bridge ACPI _OSC control flags are copied for a VMD hierarchy only on bare metal, rather than inside a virtual machine. Both are low-level changes, but they point to the same underlying issue: PCIe discovery is negotiated among firmware, the operating system, and—in virtualized setups—the hypervisor. Treating firmware-established topology as usable state can be the difference between a controller that appears absent and one Linux can safely manage.
Vera Rubin and the limits of a P2PDMA enablement line
Linux 7.3 also adds NVIDIA Vera Rubin to the platforms declared capable of PCI peer-to-peer DMA, or P2PDMA. This mechanism can allow one PCIe device to transfer data directly to another PCIe device’s memory region without routing the entire transfer through ordinary system-memory copies.
That line will interest GPU and storage operators, but it should not be read as a blanket declaration that every Vera Rubin deployment will gain a turnkey direct-data path. P2PDMA depends on the PCIe topology, IOMMU configuration, root-complex behavior, device-driver support, and the particular consumer of the memory. A system can contain compatible hardware and still fall back to host-memory transfers because the devices sit behind unsuitable switches or because the application stack does not request the path.
The kernel merge confirms that Linux will identify Vera Rubin among supported P2PDMA platforms. It does not supply benchmarks, name a supported storage or networking stack, or quantify the performance effect. Those omissions are normal for a PCI subsystem patch, but they are important for procurement teams: this is infrastructure enablement that makes a deployment possible, not evidence of a completed application-level solution.
The Realtek RTS525A quirk addresses a demonstrated shutdown failure
The clearest end-user fix in the PCI set concerns the Realtek RTS525A PCIe card reader. Linux 7.3 will avoid the PCIe L0s power-saving state for this specific device because L0s can trigger an AER interrupt storm.
The upstream change is not based only on theoretical compatibility caution. An Ubuntu bug report documents the issue on an HP ZBook Power 16 G11 after a BIOS update to version 01.07.01 or later enabled AER correctable-error reporting. In the reported case, the RTS525A generated Replay Timer Timeout events so rapidly that the machine could freeze during shutdown or reboot. The report describes roughly 240,000 events in 11 seconds and says the issue persisted even with the rtsx_pci driver blacklisted, implicating the PCIe link behavior rather than normal card-reader driver activity.
The selected mitigation is appropriately narrow: Linux removes only L0s from the RTS525A’s advertised Active State Power Management capability. Testing in the Ubuntu report found that this stopped the interrupt storm while retaining L1 and L1 substates; disabling those deeper power-saving states did not solve the fault. That is a better outcome than the common blunt workaround of disabling ASPM globally, which can increase power use across an entire laptop.
The tradeoff is local and explicit. Preventing L0s on the RTS525A can leave that card-reader link at a higher-power state, with a possible battery-life cost on affected machines. But the alternative in the reported configuration is much worse: log flooding followed by shutdown or reboot hangs requiring a long press of the power button. For Linux users seeing repeated rtsx_pci AER Replay Timer Timeout messages on device ID 10ec:525a, the 7.3 quirk is the upstream fix to watch for. It is not a reason to disable ASPM system-wide preemptively on unaffected systems.
A quieter but more defensible PCI configuration-space boundary
Linux 7.3 will also warn when user space writes to kernel-exclusive PCI configuration-space regions. The PCI pull says the behavior aligns procfs handling with an existing sysfs warning, while adjacent changes tighten credential checks and preserve lockdown restrictions for legacy PCI I/O and memory access.
This is a modest security and supportability improvement. Low-level tools sometimes write PCI configuration registers while diagnosing hardware or implementing vendor-specific functionality. A warning cannot stop a privileged process from doing damage, but it makes a disputed configuration change visible in logs and draws a line between regions that kernel drivers own and regions that administrators are attempting to alter from user space.
For managed fleets, that can make troubleshooting less opaque. When a device begins disappearing, resetting, or changing power behavior after an automated hardware-management action, the kernel will provide a clearer signal that an external tool touched protected PCI configuration state.
Linux 7.3’s PCI updates will not transform ordinary desktop behavior on their own. Their value is more concrete: better classification of emerging PCIe error signals, storage-controller recognition for upcoming Intel platforms, a route to enumerate affected Arrow Lake-HX VMD hierarchies, and a device-specific fix for Realtek card-reader storms that can prevent a laptop from shutting down. The code is now in the Linux 7.3 development branch; distribution backports, firmware combinations, and real hardware testing will determine when those changes reach the machines that need them.
