From: Joerg Roedel <joro@8bytes.org>
To: "Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
rjw@rjwysocki.net, Len Brown <lenb@kernel.org>,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, Joerg Roedel <jroedel@suse.de>
Subject: Re: [RFC PATCH] PCI/APCI: Move acpi_pci_osc_support() check to negotiation phase
Date: Wed, 28 Apr 2021 20:12:07 +0200 [thread overview]
Message-ID: <YImld9VyBOGvPdiA@8bytes.org> (raw)
In-Reply-To: <d24893db-2c9e-dbb1-75d2-53b96760c80e@linux.intel.com>
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@suse.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
prev parent reply other threads:[~2021-04-28 18:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-28 8:18 [RFC PATCH] PCI/APCI: Move acpi_pci_osc_support() check to negotiation phase Joerg Roedel
2021-04-28 17:21 ` Kuppuswamy, Sathyanarayanan
2021-04-28 18:12 ` Joerg Roedel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YImld9VyBOGvPdiA@8bytes.org \
--to=joro@8bytes.org \
--cc=bhelgaas@google.com \
--cc=jroedel@suse.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).