[REGRESSION] ACPI: PCI: misleading _OSC failure message when _OSC is absent

[REGRESSION] ACPI: PCI: misleading _OSC failure message when _OSC is absent

[KONDO KAZUMA(近藤 和真)]

Hello,

After 7d703df7f4f5 ("ACPI: bus: Split _OSC evaluation out of acpi_run_osc()"),
AE_NOT_FOUND from acpi_evaluate_object() is handled as AE_ERROR in
negotiate_os_control().

I haven't yet observed any functional issue with this change,
but I started seeing the following misleading messages on my Intel servers:

    kernel: ACPI: Enabled 2 GPEs in block 00 to 7F
    kernel: ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus fe])
    kernel: acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
  + kernel: acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC]
  + kernel: acpi PNP0A03:00: _OSC: platform willing to grant [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC]
  + kernel: acpi PNP0A03:00: _OSC: platform retains control of PCIe features (AE_ERROR)
    kernel: PCI host bridge to bus 0000:fe

Before the commit, the log was:

    kernel: ACPI: Enabled 2 GPEs in block 00 to 7F
    kernel: ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus fe])
    kernel: acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
    kernel: PCI host bridge to bus 0000:fe

"UNC0" is an uncore root bridge and does not define an _OSC method in the ACPI
namespace on my systems.

Previously, when acpi_evaluate_object() was called for UNC0._OSC, it returned
AE_NOT_FOUND, and that status was propagated to negotiate_os_control().

Now, it appears that acpi_eval_osc()/acpi_run_osc() no longer preserve the
distinction between AE_NOT_FOUND and other errors from acpi_evaluate_object(),
so negotiate_os_control() no longer receives AE_NOT_FOUND in this case.

The call chain looks like this on my system:

negotiate_os_control()
  acpi_pci_osc_control_set()       [retval = AE_ERROR    ]
    acpi_pci_query_osc ()          [retval = AE_ERROR    ]
      acpi_pci_run_osc()           [retval = AE_ERROR    ]
        acpi_run_osc()             [retval = AE_ERROR    ]
          acpi_eval_osc()          [retval = -ENODATA    ]
            acpi_evaluate_object() [retval = AE_NOT_FOUND]

As a result, negotiate_os_control() logs messages as if the OS had negotiated
with the platform via _OSC, even though _OSC is absent and no such negotiation
actually happens.

I'm not very familiar with the ACPI/PCI code, so I may be missing some
context. However, if my understanding is correct, would preserving
AE_NOT_FOUND here (for example, having acpi_eval_osc()/acpi_run_osc() return
the error as-is) be the right direction, or should the message handling be
adjusted instead?

If there is a preferred direction for fixing this, I would be happy to try
putting together a patch and testing it on my system.

Thanks,
Kazuma

Re: [REGRESSION] ACPI: PCI: misleading _OSC failure message when _OSC is absent

[Rafael J. Wysocki (Intel)]

Hi,

On Fri, Jul 17, 2026 at 2:01 PM KONDO KAZUMA(近藤　和真)
<kazuma-kondo@nec.com> wrote:
>
> Hello,
>
> After 7d703df7f4f5 ("ACPI: bus: Split _OSC evaluation out of acpi_run_osc()"),
> AE_NOT_FOUND from acpi_evaluate_object() is handled as AE_ERROR in
> negotiate_os_control().
>
> I haven't yet observed any functional issue with this change,
> but I started seeing the following misleading messages on my Intel servers:
>
>     kernel: ACPI: Enabled 2 GPEs in block 00 to 7F
>     kernel: ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus fe])
>     kernel: acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
>   + kernel: acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC]
>   + kernel: acpi PNP0A03:00: _OSC: platform willing to grant [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC]
>   + kernel: acpi PNP0A03:00: _OSC: platform retains control of PCIe features (AE_ERROR)
>     kernel: PCI host bridge to bus 0000:fe
>
> Before the commit, the log was:
>
>     kernel: ACPI: Enabled 2 GPEs in block 00 to 7F
>     kernel: ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus fe])
>     kernel: acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
>     kernel: PCI host bridge to bus 0000:fe
>
> "UNC0" is an uncore root bridge and does not define an _OSC method in the ACPI
> namespace on my systems.
>
> Previously, when acpi_evaluate_object() was called for UNC0._OSC, it returned
> AE_NOT_FOUND, and that status was propagated to negotiate_os_control().
>
> Now, it appears that acpi_eval_osc()/acpi_run_osc() no longer preserve the
> distinction between AE_NOT_FOUND and other errors from acpi_evaluate_object(),
> so negotiate_os_control() no longer receives AE_NOT_FOUND in this case.
>
> The call chain looks like this on my system:
>
> negotiate_os_control()
>   acpi_pci_osc_control_set()       [retval = AE_ERROR    ]
>     acpi_pci_query_osc ()          [retval = AE_ERROR    ]
>       acpi_pci_run_osc()           [retval = AE_ERROR    ]
>         acpi_run_osc()             [retval = AE_ERROR    ]
>           acpi_eval_osc()          [retval = -ENODATA    ]
>             acpi_evaluate_object() [retval = AE_NOT_FOUND]
>
> As a result, negotiate_os_control() logs messages as if the OS had negotiated
> with the platform via _OSC, even though _OSC is absent and no such negotiation
> actually happens.

Fortunately though this only affects the printing of messages and only
in the non-PCIe case.

> I'm not very familiar with the ACPI/PCI code, so I may be missing some
> context. However, if my understanding is correct, would preserving
> AE_NOT_FOUND here (for example, having acpi_eval_osc()/acpi_run_osc() return
> the error as-is) be the right direction, or should the message handling be
> adjusted instead?
>
> If there is a preferred direction for fixing this, I would be happy to try
> putting together a patch and testing it on my system.

I cannot send you a proper patch ATM (sorry about that), but please
try to replace the

(status == AE_NOT_FOUND && !is_pcie(root))

check in negotiate_os_control() with the following one:

(!is_pcie(root) && !acpi_has_method(handle, "_OSC"))

and see if that helps.

Thanks!