linux-kernel - Re: [PATCH] platform/x86: dell-laptop: Add drm module soft dependency

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:   Wed, 7 Jun 2023 21:16:38 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Matthew Garrett <mjg59@...f.ucam.org>,
        AceLan Kao <acelan.kao@...onical.com>
Cc:     Pali Rohár <pali@...nel.org>,
        Mark Gross <markgross@...nel.org>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        Kai-Heng Feng <kai.heng.feng@...onical.com>
Subject: Re: [PATCH] platform/x86: dell-laptop: Add drm module soft dependency

Hi,

On 6/7/23 09:47, Matthew Garrett wrote:
> On Wed, Jun 07, 2023 at 03:39:33PM +0800, AceLan Kao wrote:
> 
>> What do you think if we unregister backlight devices if the backlight type
>> is larger than the current registered one.
>> Do this check in backlight_device_register() and unregister backlight
>> devices by the order raw(1) > platform(2) > firmware(3)
>> And maybe introduce a sticky bit into the backlight device if the backlight
>> driver doesn't want to be removed.
> 
> Hans looked at doing this, but there were some awkward corner cases. 
> When we first introduced this functionality, firmware was preferred to 
> platform was preferred to raw - but on Intel, at least, this behaviour 
> changed with later versions of Windows. I don't think there's a single 
> static policy that works, I think you need to pay attention to the hints 
> the platform gives you. How does Windows know which interface to use on 
> this platform? The simplest solution may actually just be for 
> dell-laptop to refuse to register a backlight if the platform claims to 
> be Windows 8 or later.

I like that idea.

AceLan, I guess that you hit this easy while testing on a (development)
Meteor Lake platform ?

I have had other/similar reports about Meteor Lake platforms.

On hw from the last 10 years dell-laptop will not register
its vendor-type backlight class device because
acpi_video_get_backlight_type() will return acpi_backlight_video
there (1) so it does not matter if the GPU driver shows up only
later (2).

But it seems that on Meteor Lake the ACPI tables will no longer
contain acpi_video backlight control support which causes
acpi_video_get_backlight_type() to return acpi_backlight_vendor (2).
triggering the issue you are seeing.

Can you give the attached patch a try please ?

Regards,

Hans

1) Starting with kernel >= 6.2 acpi_video.c will only register
the /sys/class/backlight/acpi_video# node after a drm/kms drivers
asks it to register it.

2) The native GPU driver will tell the drivers/acpi/video_detect.c
code that native backlight control is available changing
the return of acpi_video_get_backlight_type() to native, which
is what loading the native GPU driver first also fixes this issue.

View attachment "0001-ACPI-video-Stop-trying-to-use-vendor-backlight-contr.patch" of type "text/x-patch" (3135 bytes)