[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YImld9VyBOGvPdiA@8bytes.org>
Date: Wed, 28 Apr 2021 20:12:07 +0200
From: Joerg Roedel <joro@...tes.org>
To: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, rjw@...ysocki.net,
Len Brown <lenb@...nel.org>, linux-pci@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
Joerg Roedel <jroedel@...e.de>
Subject: Re: [RFC PATCH] PCI/APCI: Move acpi_pci_osc_support() check to
negotiation phase
On Wed, Apr 28, 2021 at 10:21:12AM -0700, Kuppuswamy, Sathyanarayanan wrote:
>
>
> On 4/28/21 1:18 AM, Joerg Roedel wrote:
> > From: Joerg Roedel <jroedel@...e.de>
> >
> > The acpi_pci_osc_support() does an _OSC query with _OSC supported set
> > to what the OS supports but a zero _OSC control value. This is
> > problematic on some platforms where the firmware allows to configure
> > whether DPC is under OS or Firmware control.
>
> Do we run acpi_pci_osc_support() only to check whether _OSC is
> supported ? Or does it serve any other purpose.
I am not 100% sure, but to me it looks like the pure purpose of the
acpi_pci_osc_support() call was indeed to check whether the firmware is
willing to grant the OS control over some PCIe features.
> > When DPC is configured to be under OS control these platforms will
> > issue a warning in the firmware log that the OS does not support DPC.
>
> Also, is there any other benefit from this patch other than fixing
> a warning message in firmware?
Not much other benefit, besides some removed code. But those messages
can confuse the system owner and are worth getting rid of imho.
Regards,
Joerg
Powered by blists - more mailing lists