linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	"Hou, Xiaomeng (Matthew)" <Xiaomeng.Hou@amd.com>,
	"Liu, Aaron" <Aaron.Liu@amd.com>,
	"Huang, Ray" <Ray.Huang@amd.com>,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v6] ACPI: bus: For platform OSC negotiate capabilities
Date: Tue, 15 Mar 2022 21:09:22 +0100	[thread overview]
Message-ID: <CAJZ5v0iStA0JmO0H3z+VgQsVuQONVjKPpw0F5HKfiq=Gb6B5yw@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0i=ecAksq0TV+iLVObm-=fUfdqPABzzkgm9K6KxO1ZCcg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4471 bytes --]

On Tue, Mar 15, 2022 at 11:34 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Tue, Mar 15, 2022 at 5:30 AM Limonciello, Mario
> <Mario.Limonciello@amd.com> wrote:
> >
> > [AMD Official Use Only]
> >
> >
> >
> > > -----Original Message-----
> > > From: Rafael J. Wysocki <rafael@kernel.org>
> > > Sent: Monday, March 14, 2022 15:01
> > > To: Limonciello, Mario <Mario.Limonciello@amd.com>
> > > Cc: Rafael J. Wysocki <rafael@kernel.org>; Rafael J . Wysocki
> > > <rjw@rjwysocki.net>; ACPI Devel Maling List <linux-acpi@vger.kernel.org>;
> > > Mika Westerberg <mika.westerberg@linux.intel.com>; Hou, Xiaomeng
> > > (Matthew) <Xiaomeng.Hou@amd.com>; Liu, Aaron <Aaron.Liu@amd.com>;
> > > Huang, Ray <Ray.Huang@amd.com>; Hans de Goede
> > > <hdegoede@redhat.com>
> > > Subject: Re: [PATCH v6] ACPI: bus: For platform OSC negotiate capabilities
> > >
> > > On Mon, Mar 14, 2022 at 12:45 AM Limonciello, Mario
> > > <Mario.Limonciello@amd.com> wrote:
> > > >
> > > > [Public]
> > > >
> > > > > I would do
> > > > >
> > > > > if (capbuf[OSC_SUPPORT_DWORD] ==
> > > capbuf_ret[OSC_SUPPORT_DWORD])
> > > > >         capbuf[OSC_QUERY_DWORD] = 0;
> > > > > else
> > > > >         capbuf[OSC_SUPPORT_DWORD] &=
> > > capbuf_ret[OSC_SUPPORT_DWORD];
> > > > >
> > > > > so that the loop terminates even if the firmware does strange things
> > > > > and then it would only be necessary to check
> > > capbuf[OSC_QUERY_DWORD]
> > > > > in the loop termination condition.
> > > > >
> > > > > Would that work?
> > > > >
> > > >
> > > > I think it will.  I'll try it and send up a v7 if so.
> > > >
> > > > > > +               kfree(context.ret.pointer);
> > > > > > +       } while (capbuf[OSC_QUERY_DWORD] &&
> > > > > capbuf[OSC_SUPPORT_DWORD]);
> > > > > >
> > > > > > -       /* Now run _OSC again with query flag clear */
> > > > > > -       capbuf[OSC_QUERY_DWORD] = 0;
> > > > > > +       /*
> > > > > > +        * Avoid problems with BIOS dynamically loading tables by
> > > indicating
> > > > > > +        * support for CPPC even if it was masked.
> > > > >
> > > > > What exactly do you mean by "BIOS dynamically loading tables"?
> > > >
> > > > As mentioned in commit 159d8c274fd9:
> > > >
> > > >     On certain systems the BIOS loads SSDT tables dynamically based on the
> > > >     capabilities the OS claims to support. However, on these systems the
> > > >     _OSC actually clears some of the bits (under certain conditions) so what
> > > >     happens is that now when we call the _OSC twice the second time we
> > > pass
> > > >     the cleared values and that results errors like below to appear on the
> > > >     system log:
> > > >
> > > >       ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC],
> > > AE_NOT_FOUND (20210105/psargs-330)
> > > >       ACPI Error: Aborting method \_PR.PR01._CPC due to previous error
> > > (AE_NOT_FOUND) (20210105/psparse-529)
> > > >
> > > > This block  is to avoid regressing that again by forcing it on these systems.
> > >
> > > Well, this means that the code before and after the patch is not
> > > actually following the spec.
> > >
> > > First off, as mentioned in the changelog of commit 159d8c274fd9 (in
> > > the part that has not been quoted above), the OS is required to pass
> > > the same set of capabilities every time _OSC is evaluated.  This
> > > doesn't happen after the change.
> > >
> > > Second, acpi_bus_osc_negotiate_platform_control() should take the
> > > capabilities mask returned by the platform which it doesn't do without
> > > the patch.
> >
> > Right on both points.
> >
> > >
> > > That latter piece appears to be the bug in question here and IMO
> > > fixing it doesn't even require calling acpi_run_osc() with the query
> > > flag set for multiple times.
> >
> > I think just taking the results will re-introduce the CPC bug though
> > won't it?  So how to avoid it but also to take the results?
>
> I think that the OS should not ask for the control of the CPPC bits if
> they are masked by the firmware and it should avoid invoking _CPC
> then.
>
> Otherwise we risk breaking legitimate cases in which the firmware
> actually doesn't want the OS to control those bits.

I'm basically talking about reverting commit 159d8c274fd9, as the part
of the _OSC definition in the spec it is based on appears to be bogus
(that will be addressed separately via the ACPI spec process), and
applying the attached change on top of that.

If this looks good to you, I'll take care of it.

[-- Attachment #2: acpi-osc-fix-cppc-fallout.patch --]
[-- Type: text/x-patch, Size: 1922 bytes --]

---
 drivers/acpi/bus.c       |    4 ++++
 drivers/acpi/cppc_acpi.c |    3 +++
 include/linux/acpi.h     |    1 +
 3 files changed, 8 insertions(+)

Index: linux-pm/drivers/acpi/bus.c
===================================================================
--- linux-pm.orig/drivers/acpi/bus.c
+++ linux-pm/drivers/acpi/bus.c
@@ -278,6 +278,8 @@ bool osc_sb_apei_support_acked;
 bool osc_pc_lpi_support_confirmed;
 EXPORT_SYMBOL_GPL(osc_pc_lpi_support_confirmed);
 
+bool osc_sb_cppc_control_granted;
+
 /*
  * ACPI 6.4 Operating System Capabilities for USB.
  */
@@ -346,6 +348,8 @@ static void acpi_bus_osc_negotiate_platf
 		capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT;
 	osc_pc_lpi_support_confirmed =
 		capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_PCLPI_SUPPORT;
+	osc_sb_cppc_control_granted = capbuf_ret[OSC_SUPPORT_DWORD] &
+		(OSC_SB_CPC_SUPPORT | OSC_SB_CPCV2_SUPPORT);
 	osc_sb_native_usb4_support_confirmed =
 		capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT;
 
Index: linux-pm/drivers/acpi/cppc_acpi.c
===================================================================
--- linux-pm.orig/drivers/acpi/cppc_acpi.c
+++ linux-pm/drivers/acpi/cppc_acpi.c
@@ -656,6 +656,9 @@ int acpi_cppc_processor_probe(struct acp
 	acpi_status status;
 	int ret = -EFAULT;
 
+	if (!osc_sb_cppc_control_granted)
+		return -ENODEV;
+
 	/* Parse the ACPI _CPC table for this CPU. */
 	status = acpi_evaluate_object_typed(handle, "_CPC", NULL, &output,
 			ACPI_TYPE_PACKAGE);
Index: linux-pm/include/linux/acpi.h
===================================================================
--- linux-pm.orig/include/linux/acpi.h
+++ linux-pm/include/linux/acpi.h
@@ -579,6 +579,7 @@ acpi_status acpi_run_osc(acpi_handle han
 
 extern bool osc_sb_apei_support_acked;
 extern bool osc_pc_lpi_support_confirmed;
+extern bool osc_sb_cppc_control_granted;
 extern bool osc_sb_native_usb4_support_confirmed;
 
 /* USB4 Capabilities */

  reply	other threads:[~2022-03-15 20:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 21:28 [PATCH v6] ACPI: bus: For platform OSC negotiate capabilities Mario Limonciello
2022-03-11 15:37 ` Rafael J. Wysocki
2022-03-13 23:45   ` Limonciello, Mario
2022-03-14 20:01     ` Rafael J. Wysocki
2022-03-15  4:30       ` Limonciello, Mario
2022-03-15 10:34         ` Rafael J. Wysocki
2022-03-15 20:09           ` Rafael J. Wysocki [this message]
2022-03-15 20:32             ` Limonciello, Mario
2022-03-16 10:20               ` 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='CAJZ5v0iStA0JmO0H3z+VgQsVuQONVjKPpw0F5HKfiq=Gb6B5yw@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=Aaron.Liu@amd.com \
    --cc=Mario.Limonciello@amd.com \
    --cc=Ray.Huang@amd.com \
    --cc=Xiaomeng.Hou@amd.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    /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).