Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 08 Feb, 2024 1 commit
  3. 06 Dec, 2023 1 commit
  5. 27 Nov, 2023 1 commit
    • Hans de Goede's avatar
      ACPI: video: Use acpi_video_device for cooling-dev driver data · 172c48ca
      Hans de Goede authored 
      The acpi_video code was storing the acpi_video_device as driver_data
in the acpi_device children of the acpi_video_bus acpi_device.

But the acpi_video driver only binds to the bus acpi_device.
It uses, but does not bind to, the children. Since it is not
the driver it should not be using the driver_data of the children's
acpi_device-s.

Since commit 0d167101 ("ACPI: bus: Set driver_data to NULL every
time .add() fails") the childen's driver_data ends up getting set
to NULL after a driver fails to bind to the children leading to a NULL
pointer deref in video_get_max_state when registering the cooling-dev:

[    3.148958] BUG: kernel NULL pointer dereference, address: 0000000000000090
<snip>
[    3.149015] Hardware name: Sony Corporation VPCSB2X9R/VAIO, BIOS R2087H4 06/15/2012
[    3.149021] RIP: 0010:video_get_max_state+0x17/0x30 [video]
<snip>
[    3.149105] Call Trace:
[    3.149110]  <TASK>
[    3.149114]  ? __die+0x23/0x70
[    3.149126]  ? page_fault_oops+0x171/0x4e0
[    3.149137]  ? exc_page_fault+0x7f/0x180
[    3.149147]  ? asm_exc_page_fault+0x26/0x30
[    3.149158]  ? video_get_max_state+0x17/0x30 [video 9b6f3f0d19d7b4a0e2df17a2d8b43bc19c2ed71f]
[    3.149176]  ? __pfx_video_get_max_state+0x10/0x10 [video 9b6f3f0d19d7b4a0e2df17a2d8b43bc19c2ed71f]
[    3.149192]  __thermal_cooling_device_register.part.0+0xf2/0x2f0
[    3.149205]  acpi_video_bus_register_backlight.part.0.isra.0+0x414/0x570 [video 9b6f3f0d19d7b4a0e2df17a2d8b43bc19c2ed71f]
[    3.149227]  acpi_video_register_backlight+0x57/0x80 [video 9b6f3f0d19d7b4a0e2df17a2d8b43bc19c2ed71f]
[    3.149245]  intel_acpi_video_register+0x68/0x90 [i915 1f3a758130b32ef13d301d4f8f78c7d766d57f2a]
[    3.149669]  intel_display_driver_register+0x28/0x50 [i915 1f3a758130b32ef13d301d4f8f78c7d766d57f2a]
[    3.150064]  i915_driver_probe+0x790/0xb90 [i915 1f3a758130b32ef13d301d4f8f78c7d766d57f2a]
[    3.150402]  local_pci_probe+0x45/0xa0
[    3.150412]  pci_device_probe+0xc1/0x260
<snip>

Fix this by directly using the acpi_video_device as devdata for
the cooling-device, which avoids the need to set driver-data on
the children at all.

Fixes: 0d167101 ("ACPI: bus: Set driver_data to NULL every time .add() fails")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9718
Cc: 6.6+ <stable@vger.kernel.org> # 6.6+
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      172c48ca
  7. 21 Nov, 2023 1 commit
  9. 20 Nov, 2023 2 commits
  11. 06 Oct, 2023 1 commit
  13. 25 Sep, 2023 1 commit
    • Dinghao Liu's avatar
      ACPI: video: Fix NULL pointer dereference in acpi_video_bus_add() · f4dcf06b
      Dinghao Liu authored 
      acpi_video_bus_add_notify_handler() could free video->input and
set it to NULL on failure, but this failure would be missed in its
caller acpi_video_bus_add(). As a result, when an error happens in
acpi_dev_install_notify_handler(), acpi_video_bus_add() would call
acpi_video_bus_remove_notify_handler(), where a potential NULL pointer
video->input is dereferenced in input_unregister_device().

Fix this by adding a return value check and adjusting the following
error handling code.

Fixes: 6f701681 ("ACPI: video: Install Notify() handler directly")
Signed-off-by: default avatarDinghao Liu <dinghao.liu@zju.edu.cn>
[ rjw: Subject and changelog edits ]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f4dcf06b
  15. 17 Aug, 2023 1 commit
    • Kai-Heng Feng's avatar
      ACPI: video: Put ACPI video and its child devices into D0 on boot · 89c290ea
      Kai-Heng Feng authored 
      Screen brightness can only be changed once on HP ZBook Fury 16 G10.

The vendor reports that the issue is related to the fact that Linux doesn't
invoke _PS0 at boot for all ACPI devices, as expected by the platform firmware:

    Scope (\_SB.PC00.GFX0)
    {
        Scope (DD1F)
        {
            Method (_PS0, 0, Serialized)  // _PS0: Power State 0
            {
                If (CondRefOf (\_SB.PC00.LPCB.EC0.SSBC))
                {
                    \_SB.PC00.LPCB.EC0.SSBC ()
                }
            }
	    ...
	}
	...
    }

The \_SB.PC00.GFX0.DD1F is the panel device, and its _PS0 needs to be
executed at the initialization time to make the brightness control work
properly.

_PS0 is not evaluated for this device, because _PSC is missing,
which violates the ACPI specification (ACPI 6.5, section 7.3.6).

Commit b3785492 ("ACPI / PM: Do not power manage devices in unknown
initial states") tried to work around missing _PSC on platforms with
defective firmware, but got reverted due to a regression.

So the safest approach is to use acpi_device_fix_up_power_extended() to
put ACPI video and its child devices to D0 to address the issue at hand.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217683Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      89c290ea
  17. 14 Jul, 2023 1 commit
  19. 11 Apr, 2023 1 commit
  21. 05 Apr, 2023 1 commit
    • Hans de Goede's avatar
      ACPI: video: Make acpi_backlight=video work independent from GPU driver · e506731c
      Hans de Goede authored 
      Commit 3dbc80a3 ("ACPI: video: Make backlight class device
registration a separate step (v2)") combined with
commit 5aa9d943 ("ACPI: video: Don't enable fallback path for
creating ACPI backlight by default")

Means that the video.ko code now fully depends on the GPU driver calling
acpi_video_register_backlight() for the acpi_video# backlight class
devices to get registered.

This means that if the GPU driver does not do this, acpi_backlight=video
on the cmdline, or DMI quirks for selecting acpi_video# will not work.

This is a problem on for example Apple iMac14,1 all-in-ones where
the monitor's LCD panel shows up as a regular DP connection instead of
eDP so the GPU driver will not call acpi_video_register_backlight() [1].

Fix this by making video.ko directly register the acpi_video# devices
when these have been explicitly requested either on the cmdline or
through DMI quirks (rather then auto-detection being used).

[1] GPU drivers only call acpi_video_register_backlight() when an internal
panel is detected, to avoid non working acpi_video# devices getting
registered on desktops which unfortunately is a real issue.

Fixes: 5aa9d943 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default")
Cc: All applicable <stable@vger.kernel.org>
Reviewed-by: default avatarMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e506731c
  23. 22 Dec, 2022 2 commits
  25. 23 Nov, 2022 1 commit
  27. 09 Sep, 2022 1 commit
    • Hans de Goede's avatar
      ACPI: video: Change disable_backlight_sysfs_if quirks to acpi_backlight=native · c5b94f5b
      Hans de Goede authored 
      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: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: default avatarArvid Norlander <lkml@vorpal.se>
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      c5b94f5b
  29. 03 Sep, 2022 2 commits
  31. 02 Sep, 2022 4 commits
  33. 24 Aug, 2022 1 commit
  35. 14 Jul, 2022 2 commits
  37. 28 Jun, 2022 2 commits
  39. 20 Jun, 2022 1 commit
  41. 19 May, 2022 1 commit
  43. 17 Dec, 2021 1 commit
  45. 30 Jun, 2021 1 commit
  47. 14 Jun, 2021 1 commit
  49. 08 Apr, 2021 1 commit
    • Hans de Goede's avatar
      ACPI: video: Check LCD flag on ACPI-reduced-hardware devices · 81cc7e99
      Hans de Goede authored 
      Starting with Windows 8, Windows no longer uses the ACPI-video interface
for backlight control by default. Instead backlight control is left up
to the GPU drivers and these are typically directly accessing the GPU
for this instead of going through ACPI.

This means that the ACPI video interface is no longer being tested by
many vendors, which leads to false-positive /sys/class/backlight entries
on devices which don't have a backlight at all such as desktops or
top-set boxes. These false-positives causes desktop environments to show
a non functional brightness slider in various places.

Checking the LCD flag greatly reduces the amount of false-positives,
so commit 5928c281 ("ACPI / video: Default lcd_only to true on
Win8-ready and newer machines") enabled the checking of this flag
by default on all win8 BIOS-es. But this let to regressions on some
models, so the check was made stricter adding a DMI chassis-type check
to only enable the LCD flag checking on desktop/server chassis.

Unfortunately the chassis-type reported in the DMI strings is not always
reliable. One class of devices where this is a problem is Intel Bay Trail-T
based top-set boxes / mini PCs / HDMI sticks. These are based on reference
designs which were targetets and the reference design BIOS code
is often used without changing the chassis-type to something more
appropriate.

There are many, many Bay Trail-T based devices affected by this, so DMI
quirking our way out of this is a bad idea. This patch takes a different
approach, Bay Trail-T (unlike regular Bay Trail) is an ACPI-reduced-hw
platform and ACPI-reduced-hw platforms generally don't have
an embedded-controller and thus will use a native (GPU specific) backlight
interface. This patch enables Checking the LCD flag by default on
ACPI-reduced-hw platforms with a win8 BIOS independent of the reported
chassis-type, fixing the false positive /sys/class/backlight entries
on these devices.

Note in hindsight I should have never added the DMI chassis-type check
when the enabling of LCD flag checking on Windows 8 BIOS-es let to some
regressions. Instead I should have added DMI quirks for the (presumably
few) models where the LCD flag check let to issues. But I'm afraid that
it is too late to change this now, changing this now will likely lead to
a bunch of regressions.

This patch was tested on a Mele PCG03 mini PC.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      81cc7e99
  51. 19 Mar, 2021 1 commit
  53. 04 Feb, 2021 1 commit
    • Rafael J. Wysocki's avatar
      ACPI: video: Clean up printing messages · 2924d2f8
      Rafael J. Wysocki authored 
      Replace the ACPI_DEBUG_PRINT() instances in acpi_video.c with
acpi_handle_debug() calls and the ACPI_EXCEPTION()/ACPI_ERROR()/
ACPI_WARNING() instances in there with acpi_handle_info() calls,
which among other things causes the excessive log levels of those
messages to be increased.

Drop the _COMPONENT and ACPI_MODULE_NAME() definitions that are not
used any more from acpi_video.c, drop the no longer needed
ACPI_VIDEO_COMPONENT definition from the headers and update the
documentation accordingly.

While at it, add a pr_fmt() definition to acpi_video.c, replace the
direct printk() invocations in there with acpi_handle_info() or
pr_info() (and reduce the excessive log level where applicable) and
drop the PREFIX sybmbol definition which is not necessary any more
from acpi_video.c.

Also make unrelated janitorial changes to fix up white space and
use ACPI_FAILURE() instead of negating ACPI_SUCCESS().
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      2924d2f8
  55. 09 Nov, 2020 1 commit
  57. 04 Mar, 2020 1 commit
  59. 16 Dec, 2019 1 commit
  61. 11 Oct, 2019 1 commit
  63. 16 Jul, 2019 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7