Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230719023223.2971481-1-kai.heng.feng@canonical.com>
In-Reply-To: <20230719023223.2971481-1-kai.heng.feng@canonical.com>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Thu, 20 Jul 2023 19:32:39 +0200
Message-ID: <CAJZ5v0g4ngM4Z_nvzMfdgsMjjjc2QXkr-ZGxZBzDufbrqO6Kvw@mail.gmail.com>
Subject: Re: [PATCH v2] ACPI: video: Put ACPI video and its child devices to
 D0 at boot
To:     Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc:     rafael@kernel.org, lenb@kernel.org, hdegoede@redhat.com,
        linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Wed, Jul 19, 2023 at 4:33 AM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
> Screen brightness can only be changed once on some HP laptops.
>
> Vendor identified the root cause as Linux doesn't invoke _PS0 at boot
> for all ACPI devices:

No, it doesn't and it won't.  For the reason why please see the
comment in acpi_bus_init_power().

BTW, missing _PSC for a device that has _PS0 violates Section 7.3.6.
_PSC (Power State Current) of the ACPI specification, so this is a
platform firmware problem.

>     Scope (\_SB.PC00.GFX0)
>     {
>         Scope (DD1F)
>         {
>             Method (_PS0, 0, Serialized)  // _PS0: Power State 0
>             {
>                 If (CondRefOf (\_SB.PC00.LPCB.EC0.SSBC))
>                 {
>                     \_SB.PC00.LPCB.EC0.SSBC ()
>                 }
>             }
>             ...
>         }
>         ...
>     }
>
> The \_SB.PC00.GFX0.DD1F is the panel device, and its _PS0 needs to be
> executed to make the brightness control work properly.
>
> _PS0 doesn't get invoked for all ACPI devices because of commit
> 7cd8407d53ef ("ACPI / PM: Do not execute _PS0 for devices without _PSC
> during initialization"). For now use acpi_device_fix_up_power_extended()
> to put ACPI video and its child devices to D0 to workaround the issue.

The above paragraph is misleading the reader into thinking that the
issue was introduced by a kernel change while the issue really is
there in the platform firmware and it is the missing _PSC.

Blaming kernel changes for platform firmware defects is not really productive.

So this really is a workaround for defective platform firmware on the
affected systems and it should be documented as such.

> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217683
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> v2:
>  - Wording
>  - Bugzilla
>  - Add comment
>
>  drivers/acpi/acpi_video.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
> index 62f4364e4460..bac614e9fe56 100644
> --- a/drivers/acpi/acpi_video.c
> +++ b/drivers/acpi/acpi_video.c
> @@ -2027,6 +2027,13 @@ static int acpi_video_bus_add(struct acpi_device *device)
>         if (error)
>                 goto err_put_video;
>
> +
> +       /*
> +        * Some HP laptops require ACPI video's child devices have _PS0
> +        * evaluated to have functional panel brightness control.

So the comment should mention the platform firmware defect and it
shouldn't say "some" but explicitly identify the defective platforms.

> +        */
> +       acpi_device_fix_up_power_extended(device);
> +

And the code change itself is simple enough, so it can be made as long
as it is fine with Hans.

>         pr_info("%s [%s] (multi-head: %s  rom: %s  post: %s)\n",
>                ACPI_VIDEO_DEVICE_NAME, acpi_device_bid(device),
>                video->flags.multihead ? "yes" : "no",
> --