- 05 Sep, 2022 1 commit
-
-
Hans de Goede authored
Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86 Tag (immutable branch) with v6.0-rc1 + the (acpi/x86) backlight detect refactor work. For merging into the acpi, drm-* and pdx86 subsystems.
-
- 03 Sep, 2022 23 commits
-
-
Andy Shevchenko authored
We have to copy only selected fields from the original resource. Because a PCI device will be removed immediately after getting its resources, we may not use any allocated data, hence we may not copy any pointers. Consider the following scenario: 1/ a caller of p2sb_bar() gets the resource; 2/ the resource has been copied by platform_device_add_data() in order to create a platform device; 3/ the platform device creation will call for the device driver's ->probe() as soon as a match found; 4/ the ->probe() takes given resources (see 2/) and tries to access one of its field, i.e. 'name', in the __devm_ioremap_resource() to create a pretty looking output; 5/ but the 'name' is a dangling pointer because p2sb_bar() removed a PCI device, which 'name' had been copied to the caller's memory. 6/ UAF (Use-After-Free) as a result. Kudos to Mika for the initial analisys of the issue. Fixes: 9745fb07 ("platform/x86/intel: Add Primary to Sideband (P2SB) bridge support") Reported-by:kernel test robot <oliver.sang@intel.com> Suggested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/linux-i2c/YvPCbnKqDiL2XEKp@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/linux-i2c/YtjAswDKfiuDfWYs@xsang-OptiPlex-9020/Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220901113406.65876-1-andriy.shevchenko@linux.intel.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Mario Limonciello authored
The WMI subsystem in the kernel currently tracks WMI devices by a GUID string not by ACPI device. The GUID used by the `wmi-bmof` module however is available from many devices on nearly every machine. This originally was thought to be a bug, but as it happens on most machines it is a design mistake. It has been fixed by tying an ACPI device to the driver with struct wmi_driver. So drivers that have moved over to struct wmi_driver can actually support multiple instantiations of a GUID without any problem. Add an allow list into wmi.c for GUIDs that the drivers that are known to use struct wmi_driver. The list is populated with `wmi-bmof` right now. The additional instances of that in sysfs with be suffixed with -%d Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220829201500.6341-1-mario.limonciello@amd.comReviewed-by:
-
Hans de Goede authored
Add an entry summarizing the discussion about dealing with brightness control on devices with more then 1 internal panel. The original discussion can be found here: https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdegoede@redhat.com/Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Hans de Goede authored
The video_detect_dmi_table[] uses an unusual indentation for before the ".name = ..." named struct initializers. Instead of being indented with an extra tab compared to the previous line's '{' these are indented to with only a single space to allow for long DMI_MATCH() lines without wrapping. But over time some entries did not event have the single space indent in front of the ".name = ..." lines. Make things consistent by using a single space indent for these lines everywhere. Acked-by:Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Hans de Goede authored
acpi_backlight=native is the default for these, but as the comment explains the quirk was still necessary because even briefly registering the acpi_video0 backlight; and then unregistering it once the native driver showed up, was leading to issues. After the "ACPI: video: Make backlight class device registration a separate step" patch from earlier in this patch-series, we no longer briefly register the acpi_video0 backlight on systems where the native driver should be used. So this is no longer an issue an the quirks are no longer needed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683Tested-by:
Werner Sembach <wse@tuxedocomputers.com> Acked-by:
-
Hans de Goede authored
acpi_backlight=native is the default for the "Samsung X360", but as the comment explains the quirk was still necessary because even briefly registering the acpi_video0 backlight; and then unregistering it once the native driver showed up, was leading to issues. After the "ACPI: video: Make backlight class device registration a separate step" patch from earlier in this patch-series, we no longer briefly register the acpi_video0 backlight on systems where the native driver should be used. So this is no longer an issue an the quirk is no longer needed. Acked-by:
-
Hans de Goede authored
acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type() actually calls acpi_video_unregister_backlight() since that is often probed earlier, leading to userspace seeing the acpi_video0 class device being briefly available, leading to races in userspace where udev probe-rules try to access the device and it is already gone. All callers have been fixed to no longer call it, so remove acpi_video_set_dmi_backlight_type() now. This means we now also no longer need acpi_video_unregister_backlight() for the remove acpi_video backlight after it was wrongly registered hack, so remove that too. Acked-by:
-
Hans de Goede authored
acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Move all the acpi_backlight=[vendor|native] quirks from samsung-laptop to drivers/acpi/video_detect.c . Note the X360 -> acpi_backlight=native quirk is not moved because that already was present in drivers/acpi/video_detect.c . Acked-by:
-
Hans de Goede authored
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace it with acpi/video_detect.c video_detect_dmi_table[] entries using the video_detect_force_native callback. acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Acked-by:
-
Hans de Goede authored
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace it with acpi/video_detect.c video_detect_dmi_table[] entries using the video_detect_force_vendor callback. acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Note no entries are dropped from the dmi_system_id table in asus-nb-wmi.c. This is because the entries using the removed wmi_backlight_power flag also use other model specific quirks from the asus-wmi quirk_entry struct. So the quirk_asus_x55u struct and the entries pointing to it cannot be dropped. Acked-by:
-
Hans de Goede authored
Remove this check from the asus-wmi backlight handling: /* Some Asus desktop boards export an acpi-video backlight interface, stop this from showing up */ chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); if (chassis_type && !strcmp(chassis_type, "3")) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be removed because other changes in this series change the native backlight drivers to no longer unconditionally register their backlight. Instead these drivers now do this check: if (acpi_video_get_backlight_type(false) != acpi_backlight_native) return 0; /* bail */ So leaving this in place can break things on laptops with a broken DMI chassis-type, which would have GPU native brightness control before the addition of the acpi_video_get_backlight_type() != native check. Removing this should be ok now, since the ACPI video code has improved heuristics for this itself now (which includes a chassis-type check). Signed-off-by: -
Hans de Goede authored
Move the backlight DMI quirks to acpi/video_detect.c, so that the driver no longer needs to call acpi_video_set_dmi_backlight_type(). acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Note that even though the DMI quirk table name was video_vendor_dmi_table, 5/6 quirks were actually quirks to use the GPU native backlight. These 5 quirks also had a callback in their dmi_system_id entry which disabled the acer-wmi vendor driver; and any DMI match resulted in: acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); which disabled the acpi_video driver, so only the native driver was left. The new entries for these 5/6 devices correctly marks these as needing the native backlight driver. Also note that other changes in this series change the native backlight drivers to no longer unconditionally register their backlight. Instead these drivers now do this check: if (acpi_video_get_backlight_type(false) != acpi_backlight_native) return 0; /* bail */ which without this patch would have broken these 5/6 "special" quirks. Since I had to look at all the commits adding the quirks anyways, to make sure that I understood the code correctly, I've also added links to the various original bugzillas for these quirks to the new entries. Acked-by:
-
Hans de Goede authored
acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type() actually calls acpi_video_unregister_backlight() since that is often probed earlier, leading to userspace seeing the acpi_video0 class device being briefly available, leading to races in userspace where udev probe-rules try to access the device and it is already gone. In case of toshiba_acpi there are no DMI quirks to move to acpi/video_detect.c, but it also (ab)uses it for transflective displays. Adding transflective display support to video_detect.c would be quite involved. But luckily there are only 2 known models with a transflective display, so we can just add DMI quirks for those. Acked-by:
-
Hans de Goede authored
Now that acpi_video_get_backlight_type() has apple-gmux detection (using apple_gmux_present()), it is no longer necessary for the apple-gmux code to manually remove possibly conflicting drivers. So remove the handling for this from the apple-gmux driver. Signed-off-by: -
Hans de Goede authored
Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec check. This will make nvidia-wmi-ec-backlight properly honor the user selecting a different backlight driver through the acpi_backlight=... kernel commandline option. Since the auto-detect code check for nvidia-wmi-ec-backlight in drivers/acpi/video_detect.c already checks that the WMI advertised brightness-source is the embedded controller, this new check makes it unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself. Suggested-by:
Daniel Dadap <ddadap@nvidia.com> Reviewed-by:
-
Hans de Goede authored
On Apple laptops with an Apple GMUX using this for brightness control, should take precedence of any other brightness control methods. Add apple-gmux detection to acpi_video_get_backlight_type() using the already existing apple_gmux_present() helper function. This will allow removig the (ab)use of: acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); Inside the apple-gmux driver. Acked-by:
-
Hans de Goede authored
On some new laptop designs a new Nvidia specific WMI interface is present which gives info about panel brightness control and may allow controlling the brightness through this interface when the embedded controller is used for brightness control. When this WMI interface is present and indicates that the EC is used, then this interface should be used for brightness control. Changes in v2: - Use the new shared nvidia-wmi-ec-backlight.h header for the WMI firmware API definitions - ACPI_VIDEO can now be enabled on non X86 too, adjust the Kconfig changes to match this. Changes in v3: - Use WMI_BRIGHTNESS_GUID define Acked-by:
-
Hans de Goede authored
Refactor acpi_video_get_backlight_type() so that the heuristics / detection steps are stricly in order of descending precedence. Also move the comments describing the steps to when the various steps are actually done, to avoid the comments getting out of sync with the code. Acked-by:
-
Hans de Goede authored
Move the WMI interface definitions to a header, so that the definitions can be shared with drivers/acpi/video_detect.c . Changes in v2: - Add missing Nvidia copyright header - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well Suggested-by:
-
Hans de Goede authored
Typically the acpi_video driver will initialize before radeon, which used to cause /sys/class/backlight/acpi_video0 to get registered and then radeon would register its own radeon_bl# device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when radeon skips registering its own backlight device because of e.g. the firmware_flags or the acpi_video_get_backlight_type() return value. This ensures that if the acpi_video backlight device should be used, it will be available before the radeon drm_device gets registered with userspace. Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Hans de Goede authored
Typically the acpi_video driver will initialize before amdgpu, which used to cause /sys/class/backlight/acpi_video0 to get registered and then amdgpu would register its own amdgpu_bl# device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when amdgpu skips registering its own backlight device because of either the firmware_flags or the acpi_video_get_backlight_type() return value. This ensures that if the acpi_video backlight device should be used, it will be available before the amdgpu drm_device gets registered with userspace. Acked-by:
-
Hans de Goede authored
Typically the acpi_video driver will initialize before nouveau, which used to cause /sys/class/backlight/acpi_video0 to get registered and then nouveau would register its own nv_backlight device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when native backlight device registration has failed / was skipped to ensure that there is a backlight device available before the drm_device gets registered with userspace. Changes in v2: - Add nouveau_acpi_video_register_backlight() wrapper to avoid unresolved symbol errors on non X86 Reviewed-by:
-
Hans de Goede authored
On machins without an i915 opregion the acpi_video driver immediately probes the ACPI video bus and used to also immediately register acpi_video# backlight devices when supported. Once the drm/kms driver then loaded later and possibly registered a native backlight device then the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices (when acpi_video_get_backlight_type()==native). This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() after the i915 calls acpi_video_register() (after setting up the i915 opregion) so that the acpi_video backlight devices get registered on systems where the i915 native backlight device is not registered. Changes in v2: -Only call acpi_video_register_backlight() when a panel is detected Changes in v3: -Add a new intel_acpi_video_register() helper which checks if a panel is present and then calls acpi_video_register_backlight() Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 02 Sep, 2022 6 commits
-
-
Hans de Goede authored
Remove the code to unregister acpi_video backlight devices when a native backlight device gets registered later. Now that the acpi_video backlight device registration is a separate step which runs later, after the drm/kms driver is done setting up its own native backlight device, it is no longer necessary to monitor for a native (BACKLIGHT_RAW) device showing up later and to then unregister the acpi_video backlight device(s). Acked-by:
-
Hans de Goede authored
On x86/ACPI boards the acpi_video driver will usually initialize before the kms driver (except i915). This causes /sys/class/backlight/acpi_video0 to show up and then the kms driver registers its own native backlight device after which the drivers/acpi/video_detect.c code unregisters the acpi_video0 device (when acpi_video_get_backlight_type()==native). This means that userspace briefly sees 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this make backlight class device registration a separate step done by a new acpi_video_register_backlight() function. The intend is for this to be called by the drm/kms driver *after* it is done setting up its own native backlight device. So that acpi_video_get_backlight_type() knows if a native backlight will be available or not at acpi_video backlight registration time, avoiding the add + remove dance. Note the new acpi_video_register_backlight() function is also called from a delayed work to ensure that the acpi_video backlight devices does get registered if necessary even if there is no drm/kms driver or when it is disabled. Changes in v2: - Make register_backlight_delay a module parameter, mainly so that it can be disabled by Nvidia binary driver users Acked-by:
-
Hans de Goede authored
When acpi_video_register() has not run yet the video_bus_head will be empty, so there is no need to check the register_count flag first. Acked-by:
-
Hans de Goede authored
Move the list_del removing an acpi_video_bus from video_bus_head on teardown to before the teardown is done, to avoid code iterating over the video_bus_head list seeing acpi_video_bus objects on there which are (partly) torn down already. Acked-by:
-
Hans de Goede authored
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type backlight devices call acpi_video_backlight_use_native() now. This sets __acpi_video_get_backlight_type()'s internal static native_available flag. This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check unnecessary. Relying on the cached native_available value not only is simpler, it will also work correctly in cases where then native backlight registration was skipped because of acpi_video_backlight_use_native() returning false. Acked-by:
-
Hans de Goede authored
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved symbol errors on non X86 Reviewed-by:
-
- 01 Sep, 2022 10 commits
-
-
Luke D. Jones authored
Fix for TUF laptops returning with an -ENOSPC on calling asus_wmi_evaluate_method_buf() when fetching default curves. The TUF method requires at least 32 bytes space. This also moves and changes the pr_debug() in fan_curve_check_present() to pr_warn() in fan_curve_get_factory_default() so that there is at least some indication in logs of why it fails. Signed-off-by:
Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/20220828074638.5473-1-luke@ljones.devReviewed-by:
-
Pali Rohár authored
It looks like that on Dell Latitude E6440 is WMI event 0x0012 0x0003 sent when display changes brightness. When it happens kernel prints "dell_wmi: Unknown WMI event type 0x12" message into dmesg. So ignore it for now to not spam dmesg. Signed-off-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20220827133040.15932-1-pali@kernel.orgReviewed-by:
-
Hans de Goede authored
Tag (immutable branch) for: v6.0-rc1 + "[PATCH v6 0/7] add support for another simatic board" series for merging into the gpio, leds and pdx86 subsystems.
-
Henning Schild authored
This adds support for the Siemens Simatic IPC427G. A board which basically works like the 227G added in a previous patch. So all there is to do is to add the station_id and make it take all the 227G branches. Reviewed-by:
Henning Schild <henning.schild@siemens.com> Link: https://lore.kernel.org/r/20220825104422.14156-8-henning.schild@siemens.comReviewed-by:
-
Henning Schild authored
Just load the watchdog module, after having identified that machine. That watchdog module does not have any autoloading support. Reviewed-by:
-
Henning Schild authored
This adds support of the Siemens Simatic IPC227G. Its LEDs are connected to GPIO pins provided by the gpio-f7188x module. We make sure that gets loaded, if not enabled in the kernel config no LED support will be available. Reviewed-by:
-
Henning Schild authored
So that drivers building on top can find those pins with GPIO_LOOKUP helpers. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Simon Guinot <simon.guinot@sequanux.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220825104422.14156-5-henning.schild@siemens.comSigned-off-by:
-
Henning Schild authored
Add GPIO support for Nuvoton NCT6116 chip. Nuvoton SuperIO chips are very similar to the ones from Fintek. In other subsystems they also share drivers and are called a family of drivers. For the GPIO subsystem the only difference is that the direction bit is reversed and that there is only one data bit per pin. On the SuperIO level the logical device is another one. On a chip level we do not have a manufacturer ID to check and also no revision. Reviewed-by:
-
Henning Schild authored
Subsequent patches will touch that file, apply some nice to have style changes before actually adding functional changes. Signed-off-by:
-
Henning Schild authored
Subsequent patches will touch that file, apply some nice to have style changes before actually adding functional changes. Signed-off-by:
-
