public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sinan Kaya <okaya@kernel.org>
Cc: Yicong Yang <yangyicong@hisilicon.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH] PCI/ASPM: Print correct ASPM status when _OSC failed
Date: Tue, 2 Jun 2020 17:36:18 -0500	[thread overview]
Message-ID: <20200602223618.GA845676@bjorn-Precision-5520> (raw)
In-Reply-To: <dd5ba708-18a9-fd42-8cf1-af32ef367d5e@kernel.org>

On Tue, Jun 02, 2020 at 01:50:37PM -0400, Sinan Kaya wrote:
> Bjorn,
> 
> On 6/1/2020 9:57 PM, Yicong Yang wrote:
> > well, Sinan's words make sense to me. But I'm still confused that, the message
> > says we're "disabling ASPM" but ASPM maybe enabled if we designate
> > pcie_aspm=force as I mentioned in the commit message. Will it be possible if
> > we replace "disabling" to "disabled" or we can do something else to make
> > the message reflect the real status of ASPM?
> 
> What do you think?

ASPM is a mess in general, and the whole "no_aspm" dance for delaying
setting of aspm_disabled is ... well, it's confusing at best.

These "_OSC failed" messages are confusing to users as well.  They
lead to bug reports against Linux (when it's usually a BIOS problem)
and users booting with "pcie_aspm=force" (which is a poor user
experience and potentially dangerous since the platform hasn't granted
us control of the PCIe Capability).

And it's not even specific to ASPM; when _OSC fails, we don't take
over *any* PCIe features.  At least, we're not *supposed* to -- I
don't think we're very careful about random things in the PCIe
capability.

What if we just removed the ASPM text from the message completely,
e.g., something like this:

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 800a3d26d24b..49fdb07061b1 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -453,9 +453,8 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm,
 		if ((status == AE_NOT_FOUND) && !is_pcie)
 			return;
 
-		dev_info(&device->dev, "_OSC failed (%s)%s\n",
-			 acpi_format_exception(status),
-			 pcie_aspm_support_enabled() ? "; disabling ASPM" : "");
+		dev_info(&device->dev, "_OSC: platform retains control of PCIe features (%s)\n",
+			 acpi_format_exception(status));
 		return;
 	}
 
@@ -516,7 +515,7 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm,
 	} else {
 		decode_osc_control(root, "OS requested", requested);
 		decode_osc_control(root, "platform willing to grant", control);
-		dev_info(&device->dev, "_OSC failed (%s); disabling ASPM\n",
+		dev_info(&device->dev, "_OSC: platform retains control of PCIe features (%s)\n",
 			acpi_format_exception(status));
 
 		/*

  reply	other threads:[~2020-06-02 22:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28  8:38 [PATCH] PCI/ASPM: Print correct ASPM status when _OSC failed Yicong Yang
2020-05-28 11:42 ` Rafael J. Wysocki
2020-06-01 15:14   ` Sinan Kaya
2020-06-01 15:22     ` Rafael J. Wysocki
2020-06-02  1:57       ` Yicong Yang
2020-06-02 17:50         ` Sinan Kaya
2020-06-02 22:36           ` Bjorn Helgaas [this message]
2020-06-02 23:21             ` Sean V Kelley
2020-06-03  4:48               ` Sinan Kaya
     [not found]                 ` <03d2a6ca-78de-2d39-5428-2949c2017099@hisilicon.com>
2020-06-03 13:02                   ` [PATCH v2] ACPI: PCI: Remove ASPM text from _OSC failure message Rafael J. Wysocki
2020-06-03 13:19                     ` Yicong Yang
2020-06-03 12:59             ` [PATCH] PCI/ASPM: Print correct ASPM status when _OSC failed Rafael J. Wysocki

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=20200602223618.GA845676@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=okaya@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=yangyicong@hisilicon.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