From: Hans de Goede <hansg@kernel.org>
To: Zihuan Zhang <zhangzihuan@kylinos.cn>,
"Rafael J . wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>,
Mario Limonciello <mario.limonciello@amd.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v1] ACPI: video: Fix missing backlight node creation on Zhaoxin platforms
Date: Wed, 10 Sep 2025 11:37:10 +0200 [thread overview]
Message-ID: <12816b79-c9b0-43d1-9b99-a1e7c7d73571@kernel.org> (raw)
In-Reply-To: <20250910074711.1511753-1-zhangzihuan@kylinos.cn>
Hi Zihuan,
On 10-Sep-25 9:47 AM, Zihuan Zhang wrote:
> Some recent Lenovo and Inspur machines with Zhaoxin CPUs fail to create
> /sys/class/backlight/acpi_video0 on v6.6 kernels, while the same hardware
> works correctly on v5.4.
>
> Our analysis shows that the current implementation assumes the presence of a
> GPU. The backlight registration is only triggered if a GPU is detected, but on
> these platforms the backlight is handled purely by the EC without any GPU.
> As a result, the detection path does not create the expected backlight node.
>
> To fix this, move the following logic:
>
> /* Use ACPI video if available, except when native should be preferred. */
> if ((video_caps & ACPI_VIDEO_BACKLIGHT) &&
> !(native_available && prefer_native_over_acpi_video()))
> return acpi_backlight_video;
>
> above the if (auto_detect) *auto_detect = true; statement.
>
> This ensures that the ACPI video backlight node is created even when no GPU is
> present, restoring the correct behavior observed on older kernels.
>
> Fixes: 78dfc9d1d1ab ("ACPI: video: Add auto_detect arg to __acpi_video_get_backlight_type()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Thank you for your patch.
> ---
> drivers/acpi/video_detect.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index d507d5e08435..c1bb22b57f56 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -1011,6 +1011,11 @@ enum acpi_backlight_type __acpi_video_get_backlight_type(bool native, bool *auto
> if (acpi_backlight_dmi != acpi_backlight_undef)
> return acpi_backlight_dmi;
>
> + /* Use ACPI video if available, except when native should be preferred. */
> + if ((video_caps & ACPI_VIDEO_BACKLIGHT) &&
> + !(native_available && prefer_native_over_acpi_video()))
> + return acpi_backlight_video;
> +
> if (auto_detect)
> *auto_detect = true;
>
> @@ -1024,11 +1029,6 @@ enum acpi_backlight_type __acpi_video_get_backlight_type(bool native, bool *auto
> if (dell_uart_present)
> return acpi_backlight_dell_uart;
>
> - /* Use ACPI video if available, except when native should be preferred. */
> - if ((video_caps & ACPI_VIDEO_BACKLIGHT) &&
> - !(native_available && prefer_native_over_acpi_video()))
> - return acpi_backlight_video;
> -
> /* Use native if available */
> if (native_available)
> return acpi_backlight_native;
There is a very specific ordering, as the comment in the function says:
/*
* The below heuristics / detection steps are in order of descending
* presedence. The commandline takes presedence over anything else.
*/
You cannot just move one fo the detect steps like this, this will break
many many other systems.
NACK for this patch, sorry.
We will need to figure out some other way to fix your issue.
For starters I do not understand how this patch helps.
You are moving the:
/* Use ACPI video if available, except when native should be preferred. */
if ((video_caps & ACPI_VIDEO_BACKLIGHT) &&
!(native_available && prefer_native_over_acpi_video()))
return acpi_backlight_video;
Above the nvidia_wmi_ec_present, apple_gmux_present and dell_uart_present
checks, but I would expect all of these to be false on Lenovo and Inspur
machines with Zhaoxin CPUs ? So this patch should not make a difference.
Please double check that this patch fixes things for you.
And if it does really fix things then please add printk()
calls printing the value of nvidia_wmi_ec_present, apple_gmux_present
and dell_uart_present these should all be false, but maybe we get
a false-positive and one of them is set to true ?
Regards,
Hans
next prev parent reply other threads:[~2025-09-10 9:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 7:47 [PATCH v1] ACPI: video: Fix missing backlight node creation on Zhaoxin platforms Zihuan Zhang
2025-09-10 9:37 ` Hans de Goede [this message]
2025-09-10 9:58 ` Hans de Goede
2025-09-11 7:45 ` [PATCH v1] ACPI: video: Fix missing backlight node creation on Zihuan Zhang
2025-09-11 10:38 ` Hans de Goede
2025-09-12 1:11 ` Zihuan Zhang
2025-09-12 8:59 ` Hans de Goede
2025-09-12 10:35 ` Zihuan Zhang
2025-09-18 0:36 ` Zihuan Zhang
2025-09-18 7:33 ` Hans de Goede
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=12816b79-c9b0-43d1-9b99-a1e7c7d73571@kernel.org \
--to=hansg@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
--cc=zhangzihuan@kylinos.cn \
/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