[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!

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

[KONDO KAZUMA(近藤 和真)]

Hello,

On 2026/07/18 1:22, Rafael J. Wysocki (Intel) wrote:
> 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.

Sorry for the late reply.

With the change you suggested, the failure message no longer appears.
If that's okay with you, I'd like to submit it as a patch.

Thanks,
Kazuma

> 
> Thanks!

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

[Rafael J. Wysocki (Intel)]

On Fri, Jul 24, 2026 at 1:15 PM KONDO KAZUMA(近藤　和真)
<kazuma-kondo@nec.com> wrote:
>
> Hello,
>
> On 2026/07/18 1:22, Rafael J. Wysocki (Intel) wrote:
> > 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.
>
> Sorry for the late reply.
>
> With the change you suggested, the failure message no longer appears.
> If that's okay with you, I'd like to submit it as a patch.

I think that it'd be better to do this check earlier, even at the
beginning of negotiate_os_control(), because it is pointless to
prepare for evaluating _OSC if it is not present.

So I would add

if (!is_pcie(root) && !acpi_has_method(handle, "_OSC")) {
        print a diagnostic message;
        return;
}

to negotiate_os_control() after the x86_apple_machine check and remove
the (status == AE_NOT_FOUND && !is_pcie(root)) check that would become
redundant then.

Feel free to send a patch doing so.

Thanks!