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:   Tue, 13 Jun 2023 15:30:30 +0800
From:   AceLan Kao <acelan.kao@...onical.com>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        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

Hans de Goede <hdegoede@...hat.com> 於 2023年6月8日 週四 下午5:16寫道：
>
> Hi AceLan,
>
> On 6/8/23 05:04, AceLan Kao wrote:
> > Hans de Goede <hdegoede@...hat.com> 於 2023年6月8日 週四 上午3:16寫道：
> >>
> >> 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 why loading the native GPU driver first also fixes this issue.
> >
> > Hi Hans,
> >
> > Yes, this patch works for me, thanks.
> >
> > BTW, I encountered this issue on the RPL platform.
>
> Thank you for testing. I have updated the commit message
> to reflect that this impacts both RPL and MTL platforms
> and submitted the fix upstream:
>
> https://lore.kernel.org/linux-acpi/20230608091258.7963-1-hdegoede@redhat.com/
>
> Regards,
>
> Hans
>

Hi Hans,

I got another issue on the same platform.
The first issue was that when set to DSC graphics only in the BIOS,
I encountered the issue I reported here, dell_laptop creates dell_backlight
and then nvidia creates nvidia_0 later.

Now, set to hybrid mode in the BIOS, I found I still got 2 backlight interfaces
   $ ls /sys/class/backlight/
   acpi_video0  intel_backlight
acpi_video0 is redundant and non-working.

Do you think should I set this platform to the dmi quirk? Or is there anything
I could try to get rid of this?

Thanks.