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

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