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

["KONDO KAZUMA(近藤 和真)" <kazuma-kondo@nec.com>]

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!