linux-kernel - Re: [PATCH AUTOSEL 4.14 4/6] ACPI: video: Change disable_backlight_sysfs_if quirks to acpi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 16 Oct 2022 10:48:17 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Arvid Norlander <lkml@...pal.se>, rafael@...nel.org,
        linux-acpi@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 4.14 4/6] ACPI: video: Change
 disable_backlight_sysfs_if quirks to acpi_backlight=native

On Mon, Oct 10, 2022 at 09:37:16AM +0200, Hans de Goede wrote:
>Hi,
>
>On 10/10/22 01:58, Sasha Levin wrote:
>> From: Hans de Goede <hdegoede@...hat.com>
>>
>> [ Upstream commit c5b94f5b7819348c59f9949b2b75c341a114cdd4 ]
>>
>> Some Toshibas have a broken acpi-video interface for brightness control
>> and need a special firmware call on resume to turn the panel back on.
>> So far these have been using the disable_backlight_sysfs_if workaround
>> to deal with this.
>>
>> The recent x86/acpi backlight refactoring has broken this workaround:
>> 1. This workaround relies on acpi_video_get_backlight_type() returning
>>    acpi_video so that the acpi_video code actually runs; and
>> 2. this relies on the actual native GPU driver to offer the sysfs
>>    backlight interface to userspace.
>>
>> After the refactor this breaks since the native driver will no
>> longer register its backlight-device if acpi_video_get_backlight_type()
>> does not return native and making it return native breaks 1.
>>
>> Keeping the acpi_video backlight handling on resume active, while not
>> using it to set the brightness, is necessary because it does a _BCM
>> call on resume which is necessary to turn the panel back on on resume.
>>
>> Looking at the DSDT shows that this _BCM call results in a Toshiba
>> HCI_SET HCI_LCD_BRIGHTNESS call, which turns the panel back on.
>>
>> This kind of special vendor specific handling really belongs in
>> the vendor specific acpi driver. An earlier patch in this series
>> modifies toshiba_acpi to make the necessary HCI_SET call on resume
>> on affected models.
>>
>> With toshiba_acpi taking care of the HCI_SET call on resume,
>> the acpi_video code no longer needs to call _BCM on resume.
>>
>> So instead of using the (now broken) disable_backlight_sysfs_if
>> workaround, simply setting acpi_backlight=native to disable
>> the broken apci-video interface is sufficient fix things now.
>>
>> After this there are no more users of the disable_backlight_sysfs_if
>> flag and as discussed above the flag also no longer works as intended,
>> so remove the disable_backlight_sysfs_if flag entirely.
>>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>> Tested-by: Arvid Norlander <lkml@...pal.se>
>> Signed-off-by: Hans de Goede <hdegoede@...hat.com>
>> Signed-off-by: Sasha Levin <sashal@...nel.org>
>
>This patch goes hand in hand with:
>
>commit 3cb1f40dfdc3 ("drivers/platform: toshiba_acpi: Call HCI_PANEL_POWER_ON on resume on some models")
>
>and without that commit also being present it will cause a regression on
>the quirked Toshiba models.
>
>This really is part of the big x86/ACPI backlight handling refactor which
>has landed in 6.1 and as such is not intended for older kernels, please
>drop this from the stable series.

Will do, thanks!

-- 
Thanks,
Sasha