linux-kernel - Re: [PATCH v2] ACPI: video: Fix missing native backlight on Chromebooks

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Oct 2022 00:07:56 +0900
From:   Akihiko Odaki <akihiko.odaki@...nix.com>
To:     Hans de Goede <hdegoede@...hat.com>,
        Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Sean Paul <seanpaul@...omium.org>
Cc:     kernel@...labora.com, linux-acpi@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ACPI: video: Fix missing native backlight on
 Chromebooks



On 2022/10/24 23:59, Hans de Goede wrote:
> Hi,
> 
> On 10/24/22 16:52, Akihiko Odaki wrote:
>> On 2022/10/24 23:12, Dmitry Osipenko wrote:
>>> Chromebooks don't have backlight in ACPI table, they suppose to use
>>> native backlight in this case. Check presence of the CrOS embedded
>>> controller ACPI device and prefer the native backlight if EC found.
>>>
>>> Suggested-by: Hans de Goede <hdegoede@...hat.com>
>>> Fixes: 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native() helper")
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@...labora.com>
>>> ---
>>>
>>> Changelog:
>>>
>>> v2: - Added explanatory comment to the code and added check for the
>>>         native backlight presence, like was requested by Hans de Goede.
>>>
>>>    drivers/acpi/video_detect.c | 12 ++++++++++++
>>>    1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index 0d9064a9804c..9cd8797d12bb 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -668,6 +668,11 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>>>        { },
>>>    };
>>>    +static bool google_cros_ec_present(void)
>>> +{
>>> +    return acpi_dev_found("GOOG0004");
>>> +}
>>> +
>>>    /*
>>>     * Determine which type of backlight interface to use on this system,
>>>     * First check cmdline, then dmi quirks, then do autodetect.
>>> @@ -730,6 +735,13 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>                return acpi_backlight_video;
>>>        }
>>>    +    /*
>>> +     * Chromebooks that don't have backlight handle in ACPI table
>>> +     * are supposed to use native backlight if it's available.
>>> +     */
>>> +    if (google_cros_ec_present() && native_available)
>>> +        return acpi_backlight_native;
>>> +
>>>        /* No ACPI video (old hw), use vendor specific fw methods. */
>>>        return acpi_backlight_vendor;
>>>    }
>>
>> Hi,
>>
>> The native_available check does not prevent duplicate registration if vendor backlight registers first. It was enough for the combination of ACPI video and native because ACPI video delays its registration, but it is not the case for vendor/native combination.
> 
> There are no drivers providing acpi_backlight_vendor functionality on chromebooks.
> 
> All the drivers providing acpi_backlight_vendor functionality use vendor (Dell, Acer, Asus, etc.)
> specific firmware (smbios, EC bitbanging or ACPI) backlight control method which are not available
> on CoreBoot based ChromeBooks.

Hi,

Isn't the "native_available" check is for the case when 
acpi_backlight_vendor functionality gets implemented on Chromebooks? If 
it is, you don't want it to get broken when it actually happens. If you 
can ignore the case, native_available check is simply unnecessary.

> 
> Also notice that the theoretical problem of a vendor driver loading first was already present
> before the backlight refactor which landed in 6.1 and this has never been an issue.

The situation is even a bit better than it was before the refactor since 
duplication happened even when vendor driver loads later if I understand 
it correctly.

Regards,
Akihiko Odaki

> 
> Regards,
> 
> Hans
>