Hans de Goede [Mon, 29 Aug 2022 13:17:03 +0000 (15:17 +0200)]
drivers/platform: toshiba_acpi: Call HCI_PANEL_POWER_ON on resume on some models
Some Toshibas have a broken acpi-video interface for brightness control, so
far these have been using a special workaround in drivers/acpi/acpi_video.c
which gets activated by the disable_backlight_sysfs_if module-param/quirks.
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 commit makes toshiba_acpi do a HCI_SET HCI_PANEL_POWER_ON call
on resume on the affected models, so that the (now broken)
acpi_video disable_backlight_sysfs_if workaround will no longer
be necessary.
Note this uses HCI_PANEL_POWER_ON instead of HCI_LCD_BRIGHTNESS
to avoid changing the configured brightness level.
Tested-by: Arvid Norlander <lkml@vorpal.se>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Arvid Norlander [Fri, 2 Sep 2022 18:00:37 +0000 (20:00 +0200)]
docs: ABI: charge_control_end_threshold may not support all values
Some laptops (for example Toshiba Satellite Z830) only supports some fixed
values. Allow for this and document the expected behaviour in such cases.
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Arvid Norlander <lkml@vorpal.se>
Link: https://lore.kernel.org/r/20220902180037.1728546-4-lkml@vorpal.se
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Arvid Norlander [Fri, 2 Sep 2022 18:00:36 +0000 (20:00 +0200)]
platform/x86: Battery charge mode in toshiba_acpi (sysfs)
This commit adds the ACPI battery hook which in turns adds the sysfs
entries.
Because the Toshiba laptops only support two modes (eco or normal), which
in testing correspond to 80% and 100% we simply round to the nearest
possible level when set.
It is possible that Toshiba laptops other than the Z830 has different set
points for the charging. If so, a quirk table could be introduced in the
future for this. For now, assume that all laptops that support this feature
work the same way.
Tested on a Toshiba Satellite Z830.
Signed-off-by: Arvid Norlander <lkml@vorpal.se>
Link: https://lore.kernel.org/r/20220902180037.1728546-3-lkml@vorpal.se
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Arvid Norlander [Fri, 2 Sep 2022 18:00:35 +0000 (20:00 +0200)]
platform/x86: Battery charge mode in toshiba_acpi (internals)
This commit adds the internal functions to control the Toshiba laptop.
Unlike for example ThinkPads where this control is granular here it is
just off/on. When off it charges to 100%. When on it charges to about 80%.
Controlling this setting is done via HCI register 0x00ba. Setting to value
1 will result in limiting the charing to 80% of the battery capacity,
while setting it to 0 will allow charging to 100%.
Reading the current state is a bit weird, and needs a 1 set in the last
position of the query for whatever reason. In addition, the read may
return 0x8d20 (Data not available) rarely, so a retry mechanism is needed.
According to the Windows program used to control the feature the setting
will not take effect until the battery has been discharged to around 50%.
However, in my testing it takes effect as soon as the charge drops below
80%. On Windows Toshiba branded this feature as "Eco charging".
Signed-off-by: Arvid Norlander <lkml@vorpal.se>
Link: https://lore.kernel.org/r/20220902180037.1728546-2-lkml@vorpal.se
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Arvid Norlander [Fri, 2 Sep 2022 17:40:18 +0000 (19:40 +0200)]
platform/x86: toshiba_acpi: Add fan RPM reading (hwmon interface)
This expands on the previous commit, exporting the fan RPM via hwmon.
This will look something like the following when using the "sensors"
command from lm_sensors:
toshiba_acpi_sensors-acpi-0
Adapter: ACPI interface
fan1: 0 RPM
Signed-off-by: Arvid Norlander <lkml@vorpal.se>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220902174018.1720029-3-lkml@vorpal.se
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Arvid Norlander [Fri, 2 Sep 2022 17:40:17 +0000 (19:40 +0200)]
platform/x86: toshiba_acpi: Add fan RPM reading (internals)
This add the internal feature detection and reading function for fan RPM.
The approach is based on tracing ACPI calls using AMLI (a tracer/debugger
built into ACPI.sys) while using the Windows cooling self-test software.
The call used is {HCI_GET, 0x45, 0, 1, 0, 0} which returns:
{0x0, 0x45, fan_rpm, probably_max_rpm, 0x0, 0x0}
What is probably the max RPM is not currently used.
Signed-off-by: Arvid Norlander <lkml@vorpal.se>
Link: https://lore.kernel.org/r/20220902174018.1720029-2-lkml@vorpal.se
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Mon, 29 Aug 2022 16:29:52 +0000 (11:29 -0500)]
platform/x86/amd: pmc: Add an extra STB message for checking s2idle entry
The `check` callback is run right before the cores are put into HLT.
This will allow checking synchronization problems with other software
that writes into the STB.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220829162953.5947-5-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Mon, 29 Aug 2022 16:29:51 +0000 (11:29 -0500)]
platform/x86/amd: pmc: Always write to the STB
The kernel parameter `enable_stb` currently gates the access to the STB
from debugfs and also controls whether the kernel writes events to the
STB.
Even if not accessing STB data from the kernel it's useful to have this
data stored to review the STB. So in suspend/resume always write it.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220829162953.5947-4-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Mon, 29 Aug 2022 16:29:50 +0000 (11:29 -0500)]
platform/x86/amd: pmc: Add defines for STB events
Currently `amd-pmc` has two events, but just adds one to the first to
distinguish the second. Add a clear definition what these events mean.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220829162953.5947-3-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Mon, 29 Aug 2022 16:29:49 +0000 (11:29 -0500)]
ACPI: s2idle: Add a new ->check() callback for platform_s2idle_ops
On some platforms it is found that Linux more aggressively enters s2idle
than Windows enters Modern Standby and this uncovers some synchronization
issues for the platform. To aid in debugging this class of problems in
the future, add support for an extra optional callback intended for
drivers to emit extra debugging.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220829162953.5947-2-mario.limonciello@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 5 Sep 2022 09:01:56 +0000 (11:01 +0200)]
Merge tag 'backlight-detect-refactor-1' into review-hans
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.
Andy Shevchenko [Thu, 1 Sep 2022 11:34:06 +0000 (14:34 +0300)]
platform/x86: p2sb: Fix UAF when caller uses resource name
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:
9745fb07474f ("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.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Mon, 29 Aug 2022 20:14:59 +0000 (15:14 -0500)]
platform/x86: wmi: Allow duplicate GUIDs for drivers that use struct wmi_driver
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.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 11 Jul 2022 11:49:34 +0000 (13:49 +0200)]
drm/todo: Add entry about dealing with brightness control on devices with > 1 panel
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 <hdegoede@redhat.com>
Hans de Goede [Sat, 18 Jun 2022 17:19:51 +0000 (19:19 +0200)]
ACPI: video: Fix indentation of video_detect_dmi_table[] entries
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 <hdegoede@redhat.com>
Hans de Goede [Sat, 18 Jun 2022 17:15:22 +0000 (19:15 +0200)]
ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks
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=215683
Tested-by: Werner Sembach <wse@tuxedocomputers.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 18 Jun 2022 17:06:51 +0000 (19:06 +0200)]
ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 20 Jun 2022 09:49:57 +0000 (11:49 +0200)]
ACPI: video: Remove 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.
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 18 Jun 2022 17:01:05 +0000 (19:01 +0200)]
platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 18 Jun 2022 15:44:58 +0000 (17:44 +0200)]
platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 18 Jun 2022 15:15:24 +0000 (17:15 +0200)]
platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sun, 5 Jun 2022 15:26:54 +0000 (17:26 +0200)]
platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling
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 <hdegoede@redhat.com>
Hans de Goede [Sat, 4 Jun 2022 16:28:52 +0000 (18:28 +0200)]
platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 4 Jun 2022 14:18:05 +0000 (16:18 +0200)]
platform/x86: toshiba_acpi: Stop using 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.
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 4 Jun 2022 13:25:39 +0000 (15:25 +0200)]
platform/x86: apple-gmux: Stop calling acpi/video.h functions
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 <hdegoede@redhat.com>
Hans de Goede [Wed, 17 Aug 2022 12:37:21 +0000 (14:37 +0200)]
platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()
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: Daniel Dadap <ddadap@nvidia.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 4 Jun 2022 13:21:51 +0000 (15:21 +0200)]
ACPI: video: Add Apple GMUX brightness control detection
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 4 Jun 2022 12:06:18 +0000 (14:06 +0200)]
ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 4 Jun 2022 12:38:24 +0000 (14:38 +0200)]
ACPI: video: Refactor acpi_video_get_backlight_type() a bit
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 17 Aug 2022 12:03:32 +0000 (14:03 +0200)]
platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2)
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: Daniel Dadap <ddadap@nvidia.com>
Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 16 May 2022 14:04:17 +0000 (16:04 +0200)]
drm/radeon: Register ACPI video backlight when skipping radeon backlight registration
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 <hdegoede@redhat.com>
Hans de Goede [Mon, 16 May 2022 09:32:33 +0000 (11:32 +0200)]
drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration
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: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 30 Apr 2022 12:29:00 +0000 (14:29 +0200)]
drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2)
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: Lyude Paul <lyude@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 30 Apr 2022 13:54:36 +0000 (15:54 +0200)]
drm/i915: Call acpi_video_register_backlight() (v3)
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 29 Apr 2022 11:00:15 +0000 (13:00 +0200)]
ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 28 Apr 2022 15:41:46 +0000 (17:41 +0200)]
ACPI: video: Make backlight class device registration a separate step (v2)
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 29 Apr 2022 11:29:31 +0000 (13:29 +0200)]
ACPI: video: Simplify acpi_video_unregister_backlight()
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 28 Apr 2022 15:53:51 +0000 (17:53 +0200)]
ACPI: video: Remove acpi_video_bus from list before tearing it down
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 28 Apr 2022 12:45:35 +0000 (14:45 +0200)]
ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type()
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 15 Apr 2022 20:25:01 +0000 (22:25 +0200)]
drm/nouveau: Don't register backlight when another backlight should be used (v2)
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: Lyude Paul <lyude@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Sun, 28 Aug 2022 07:46:38 +0000 (19:46 +1200)]
platform/x86: asus-wmi: Increase FAN_CURVE_BUF_LEN to 32
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.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Pali Rohár [Sat, 27 Aug 2022 13:30:40 +0000 (15:30 +0200)]
platform/x86: dell-wmi: Add WMI event 0x0012 0x0003 to the list
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.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 1 Sep 2022 14:53:38 +0000 (16:53 +0200)]
Merge tag 'platform-drivers-x86-simatec-1' into review-hans
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 [Thu, 25 Aug 2022 10:44:22 +0000 (12:44 +0200)]
platform/x86: simatic-ipc: add new model 427G
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20220825104422.14156-8-henning.schild@siemens.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Henning Schild [Thu, 25 Aug 2022 10:44:21 +0000 (12:44 +0200)]
platform/x86: simatic-ipc: enable watchdog for 227G
Just load the watchdog module, after having identified that machine.
That watchdog module does not have any autoloading support.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20220825104422.14156-7-henning.schild@siemens.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Henning Schild [Thu, 25 Aug 2022 10:44:20 +0000 (12:44 +0200)]
leds: simatic-ipc-leds-gpio: add new model 227G
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20220825104422.14156-6-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Henning Schild [Thu, 25 Aug 2022 10:44:19 +0000 (12:44 +0200)]
gpio-f7188x: use unique labels for banks/chips
So that drivers building on top can find those pins with GPIO_LOOKUP
helpers.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
Link: https://lore.kernel.org/r/20220825104422.14156-5-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Henning Schild [Thu, 25 Aug 2022 10:44:18 +0000 (12:44 +0200)]
gpio-f7188x: Add GPIO support for Nuvoton NCT6116
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
Link: https://lore.kernel.org/r/20220825104422.14156-4-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Henning Schild [Thu, 25 Aug 2022 10:44:17 +0000 (12:44 +0200)]
gpio-f7188x: add a prefix to macros to keep gpio namespace clean
Subsequent patches will touch that file, apply some nice to have style
changes before actually adding functional changes.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
Link: https://lore.kernel.org/r/20220825104422.14156-3-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Henning Schild [Thu, 25 Aug 2022 10:44:16 +0000 (12:44 +0200)]
gpio-f7188x: switch over to using pr_fmt
Subsequent patches will touch that file, apply some nice to have style
changes before actually adding functional changes.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
Link: https://lore.kernel.org/r/20220825104422.14156-2-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Andy Shevchenko [Wed, 24 Aug 2022 15:21:15 +0000 (18:21 +0300)]
platform/x86: intel_cht_int33fe: Fix comment according to the code flow
We don't use software_node_register_nodes() in the code, fix the comment.
Fixes:
140355e5db8b ("platform/x86: intel_cht_int33fe: Convert software node array to group")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220824152115.88012-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Vadim Pasternak [Tue, 23 Aug 2022 20:19:37 +0000 (23:19 +0300)]
platform/mellanox: Remove redundant 'NULL' check
Remove 'NULL' check for 'data->hpdev.client' in error flow of
mlxreg_lc_probe(). It cannot be 'NULL' at this point.
Fixes:
b4b830a34d80 ("platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-5-vadimp@nvidia.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Vadim Pasternak [Tue, 23 Aug 2022 20:19:36 +0000 (23:19 +0300)]
platform/mellanox: Remove unnecessary code
Remove redundant 'NULL' check for of if 'data->notifier'.
Replace 'return err' by 'return 0' in mlxreg_lc_probe().
Fixes:
62f9529b8d5c87b ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-4-vadimp@nvidia.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Vadim Pasternak [Tue, 23 Aug 2022 20:19:35 +0000 (23:19 +0300)]
platform/mellanox: mlxreg-lc: Fix locking issue
Fix locking issues:
- mlxreg_lc_state_update() takes a lock when set or clear
"MLXREG_LC_POWERED".
- All the devices can be deleted before MLXREG_LC_POWERED flag is cleared.
To fix it:
- Add lock() / unlock() at the beginning / end of
mlxreg_lc_event_handler() and remove locking from
mlxreg_lc_power_on_off() and mlxreg_lc_enable_disable()
- Add locked version of mlxreg_lc_state_update() -
mlxreg_lc_state_update_locked() for using outside
mlxreg_lc_event_handler().
(2) Remove redundant NULL check for of if 'data->notifier'.
Fixes:
62f9529b8d5c87b ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-3-vadimp@nvidia.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Vadim Pasternak [Tue, 23 Aug 2022 20:19:34 +0000 (23:19 +0300)]
platform/mellanox: mlxreg-lc: Fix coverity warning
Fix smatch warning:
drivers/platform/mellanox/mlxreg-lc.c:866 mlxreg_lc_probe() warn: passing zero to 'PTR_ERR'
by removing 'err = PTR_ERR(regmap)'.
Fixes:
b4b830a34d80 ("platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-2-vadimp@nvidia.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 29 Aug 2022 16:35:44 +0000 (18:35 +0200)]
platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes
2 keymap fixes for the Acer Aspire One AOD270 and the same hardware
rebranded as Packard Bell Dot SC:
1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC,
this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping
for this.
2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate
input event with the "Video Bus" input device events. But on these devices
the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN
instead of using KE_IGNORE so that udev/hwdb can override it on these devs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220829163544.5288-1-hdegoede@redhat.com
Hans de Goede [Fri, 26 Aug 2022 11:14:53 +0000 (13:14 +0200)]
platform/x86: msi-laptop: Add msi_scm_disable_hw_fn_handling() helper
Add a msi_scm_disable_hw_fn_handling() to remove the duplicate code
for this in the resume and init paths.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220826111453.178962-2-hdegoede@redhat.com
Hans de Goede [Fri, 26 Aug 2022 11:14:52 +0000 (13:14 +0200)]
platform/x86: msi-laptop: Add msi_scm_model_exit() helper
The probe-error-exit and remove paths both duplicate the exact same code
to undo load_scm_model_init(). Add a helper for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220826111453.178962-1-hdegoede@redhat.com
Hans de Goede [Thu, 25 Aug 2022 14:13:36 +0000 (16:13 +0200)]
platform/x86: msi-laptop: Fix resource cleanup
Fix the input-device not getting free-ed on probe-errors and
fix the msi_touchpad_dwork not getting cancelled on neither
probe-errors nor on remove.
Fixes:
143a4c0284dc ("msi-laptop: send out touchpad on/off key")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220825141336.208597-3-hdegoede@redhat.com
Hans de Goede [Thu, 25 Aug 2022 14:13:35 +0000 (16:13 +0200)]
platform/x86: msi-laptop: Simplify ec_delay handling
There is no reason to have both non-delayed and delayed work structs
for the rfkill and touchpad work.
Instead simply call schedule_delayed_work() with a delay of 0 for
the quirks->ec_delay == false case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220825141336.208597-2-hdegoede@redhat.com
Hans de Goede [Thu, 25 Aug 2022 14:13:34 +0000 (16:13 +0200)]
platform/x86: msi-laptop: Fix old-ec check for backlight registering
Commit
2cc6c717799f ("msi-laptop: Port to new backlight interface
selection API") replaced this check:
if (!quirks->old_ec_model || acpi_video_backlight_support())
pr_info("Brightness ignored, ...");
else
do_register();
With:
if (quirks->old_ec_model ||
acpi_video_get_backlight_type() == acpi_backlight_vendor)
do_register();
But since the do_register() part was part of the else branch, the entire
condition should be inverted. So not only the 2 statements on either
side of the || should be inverted, but the || itself should be replaced
with a &&.
In practice this has likely not been an issue because the new-ec models
(old_ec_model==false) likely all support ACPI video backlight control,
making acpi_video_get_backlight_type() return acpi_backlight_video
turning the second part of the || also false when old_ec_model == false.
Fixes:
2cc6c717799f ("msi-laptop: Port to new backlight interface selection API")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220825141336.208597-1-hdegoede@redhat.com
Hans de Goede [Mon, 22 Aug 2022 15:08:18 +0000 (17:08 +0200)]
platform/x86: msi-laptop: Drop MSI_DRIVER_VERSION
Modules carrying there own version is a practice which the kernel
has stopped doing for a long time now, drop it.
While dropping the version pr_info from msi_init() lets remove
the somewhat useless pr_info() from msi_cleanup() as well.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220822150818.45765-2-hdegoede@redhat.com
Hans de Goede [Mon, 22 Aug 2022 15:08:17 +0000 (17:08 +0200)]
platform/x86: msi-laptop: Use MODULE_DEVICE_TABLE()
Use MODULE_DEVICE_TABLE() instead of manually adding a bunch of
MODULE_ALIAS() statements.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220822150818.45765-1-hdegoede@redhat.com
Arvid Norlander [Sun, 21 Aug 2022 20:08:21 +0000 (22:08 +0200)]
platform/x86: toshiba_acpi: Fix ECO LED control on Toshiba Z830
The toshiba_acpi driver checks for TOS_INPUT_DATA_ERROR and tries a
different format. On the Z830 the error returned is TOS_NOT_SUPPORTED
though the different format still works. Allow either error.
Signed-off-by: Arvid Norlander <lkml@vorpal.se>
Link: https://lore.kernel.org/r/20220821200821.1837460-2-lkml@vorpal.se
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Mario Limonciello [Fri, 19 Aug 2022 18:01:00 +0000 (13:01 -0500)]
platform/x86: thinkpad_acpi: Explicitly set to balanced mode on startup
It was observed that on a Thinkpad T14 Gen1 (AMD) that the platform
profile is starting up in 'low-power' mode after refreshing what the
firmware had. This is most likely a firmware bug, but as a harmless
workaround set the default profile to 'balanced' at thinkpad_acpi startup.
Reported-by: madcatx@atlas.cz
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216347
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220819180101.6383-1-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Wolfram Sang [Thu, 18 Aug 2022 21:00:57 +0000 (23:00 +0200)]
platform/x86: move from strlcpy with unused retval to strscpy
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20220818210058.7229-1-wsa+renesas@sang-engineering.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
PaddyKP_Yao [Thu, 25 Aug 2022 00:43:05 +0000 (08:43 +0800)]
platform/x86: asus-wmi: Fix the name of the mic-mute LED classdev
According to well-known-leds.txt, we should use "platform::micmute"
instead of "asus::micmute" for the name of the mic-mute LED classdev.
Signed-off-by: PaddyKP_Yao <PaddyKP_Yao@asus.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220825004305.709539-1-PaddyKP_Yao@asus.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Thu, 25 Aug 2022 23:22:51 +0000 (11:22 +1200)]
platform/x86: asus-wmi: Implement TUF laptop keyboard power states
Adds support for setting various power states of TUF keyboards.
These states are combinations of:
- boot, set if a boot animation is shown on keyboard
- awake, set if the keyboard LEDs are visible while laptop is on
- sleep, set if an animation is displayed while the laptop is suspended
- keyboard (unknown effect)
Adds two sysfs attributes to asus::kbd_backlight:
- kbd_rgb_state
- kbd_rgb_state_index
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220825232251.345893-3-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Thu, 25 Aug 2022 23:22:50 +0000 (11:22 +1200)]
platform/x86: asus-wmi: Implement TUF laptop keyboard LED modes
Adds support for changing the laptop keyboard LED mode and colour.
The modes are visible effects such as static, rainbow, pulsing,
colour cycles.
These sysfs attributes are added to asus::kbd_backlight:
- kbd_rgb_mode
- kbd_rgb_mode_index
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220825232251.345893-2-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Fri, 26 Aug 2022 00:42:10 +0000 (12:42 +1200)]
platform/x86: asus-wmi: Support the GPU fan on TUF laptops
Add support for TUF laptops which have the ability to control
the GPU fan. This will show as a second fan in hwmon, and has
the ability to run as boost (fullspeed), or auto.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220826004210.356534-3-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Fri, 26 Aug 2022 00:42:09 +0000 (12:42 +1200)]
platform/x86: asus-wmi: Modify behaviour of Fn+F5 fan key
Some more recent TUF laptops have both fan_boost and thermal_throttle.
The key code for Fn+F5 is also different and unmapped.
This patch adjusts the asus_wmi_handle_event_code() match to match
for both 0x99 and 0xAE, and run both mode switch functions for
fan_boost and/or thermal_throttle if either are available.
It is required that both are tried, as in some instances the ACPI
set-method for one may not have any code body within it even though
it was returned as supported by the get method.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220826004210.356534-2-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 26 Aug 2022 09:29:21 +0000 (11:29 +0200)]
platform/x86: asus-wmi: Update tablet_mode_sw module-param help text
Document how to select asus_wmi_lid_flip_rog_devid as tablet_switch_mode
by adding "3:lid-flip-rog" to the tablet_mode_sw module-param help text.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220826092921.8907-1-hdegoede@redhat.com
Hans de Goede [Wed, 24 Aug 2022 15:11:45 +0000 (17:11 +0200)]
platform/x86: asus-wmi: Simplify tablet-mode-switch handling
Simplify tablet-mode-switch handling:
1. The code is the same for all variants, the only difference is the
dev_id and notify event code. Store the dev_id + code in struct asus_wmi
and unify the handling
2. Make the new unified asus_wmi_tablet_mode_get_state() check dev_id has
been set and make it a no-op when not set. This allows calling it
unconditionally at resume/restore time
3. Simplify the tablet_mode_sw module-param handling, this also allows
selecting the new lid-flip-rog type through the module-param.
Cc: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220824151145.1448010-2-hdegoede@redhat.com
Hans de Goede [Wed, 24 Aug 2022 15:11:44 +0000 (17:11 +0200)]
platform/x86: asus-wmi: Simplify tablet-mode-switch probing
The 3 different tablet-mode-switch initialization paths repeat a lot
of the same code. Add a helper function for this.
This also makes the error-handling for the kbd_dock_devid case consistent
with the other 2 cases.
Cc: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220824151145.1448010-1-hdegoede@redhat.com
Luke D. Jones [Sat, 13 Aug 2022 09:27:53 +0000 (21:27 +1200)]
platform/x86: asus-wmi: Add support for ROG X13 tablet mode
Add quirk for ASUS ROG X13 Flow 2-in-1 to enable tablet mode with
lid flip (all screen rotations).
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220813092753.6635-2-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Sat, 13 Aug 2022 09:27:52 +0000 (21:27 +1200)]
platform/x86: asus-wmi: Adjust tablet/lidflip handling to use enum
Due to multiple types of tablet/lidflip, the existing code for
handling these events is refactored to use an enum for each type.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220813092753.6635-1-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Sat, 13 Aug 2022 09:26:24 +0000 (21:26 +1200)]
platform/x86: asus-wmi: Support the hardware GPU MUX on some laptops
Support the hardware GPU MUX switch available on some models. This
switch can toggle the MUX between:
- 0, Dedicated mode
- 1, Optimus mode
Optimus mode is the regular iGPU + dGPU available, while dedicated
mode switches the system to have only the dGPU available.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220813092624.6228-1-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 15 Aug 2022 15:05:38 +0000 (17:05 +0200)]
platform/x86: asus-wmi: Simplify some of the *_check_present() helpers
After the recent cleanup patches, some of the *_check_present() helpers
just propagate the result of asus_wmi_dev_is_present().
Replace these with direct asus_wmi_dev_is_present() calls as a further
cleanup.
Cc: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220815150538.474306-1-hdegoede@redhat.com
Luke D. Jones [Fri, 12 Aug 2022 22:25:09 +0000 (10:25 +1200)]
platform/x86: asus-wmi: Refactor panel_od attribute
The settings for these attributes can be read from the device, this
is now done instead of reading a stored value from module. The stored
value is also removed.
This means the simpler asus_wmi_dev_is_present() can be used in
*_check_present() - it is not an error for these methods to be
missing.
The _write() functions have their bodies shifted in to *_store()
which simplifies things further.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220812222509.292692-7-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Fri, 12 Aug 2022 22:25:08 +0000 (10:25 +1200)]
platform/x86: asus-wmi: Refactor egpu_enable attribute
The settings for these attributes can be read from the device, this
is now done instead of reading a stored value from module. The stored
value is also removed.
This means the simpler asus_wmi_dev_is_present() can be used in
*_check_present() - it is not an error for these methods to be
missing.
The _write() functions have their bodies shifted in to *_store()
which simplifies things further.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220812222509.292692-6-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Fri, 12 Aug 2022 22:25:07 +0000 (10:25 +1200)]
platform/x86: asus-wmi: Refactor disable_gpu attribute
The settings for these attributes can be read from the device, this
is now done instead of reading a stored value from module. The stored
value is also removed.
This means the simpler asus_wmi_dev_is_present() can be used in
*_check_present() - it is not an error for these methods to be
missing.
The _write() functions have their bodies shifted in to *_store()
which simplifies things further.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220812222509.292692-5-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Fri, 12 Aug 2022 22:25:06 +0000 (10:25 +1200)]
platform/x86: asus-wmi: Document the panel_od sysfs attribute
The panel_od attribute was not documented, this adds the
required documentation.
Fixes:
ca91ea34778f ("asus-wmi: Add panel overdrive functionality")
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220812222509.292692-4-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Fri, 12 Aug 2022 22:25:05 +0000 (10:25 +1200)]
platform/x86: asus-wmi: Document the egpu_enable sysfs attribute
The egpu_enable attribute was not documented, this adds the
required documentation.
Fixes:
382b91db8044 ("asus-wmi: Add egpu enable method")
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220812222509.292692-3-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Fri, 12 Aug 2022 22:25:04 +0000 (10:25 +1200)]
platform/x86: asus-wmi: Document the dgpu_disable sysfs attribute
The dgpu_disable attribute was not documented, this adds the
required documentation.
Fixes:
98829e84dc67 ("asus-wmi: Add dgpu disable method")
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220812222509.292692-2-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ye xingchen [Thu, 11 Aug 2022 01:32:03 +0000 (01:32 +0000)]
platform/x86: asus-wmi: Use kobj_to_dev()
Use kobj_to_dev() instead of open-coding it.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Link: https://lore.kernel.org/r/20220811013203.16010-1-ye.xingchen@zte.com.cn
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Luke D. Jones [Tue, 9 Aug 2022 02:50:53 +0000 (14:50 +1200)]
platform/x86: asus-wmi: Convert all attr-show to use sysfs_emit
This changes all *_show attributes in asus-wmi.c to use sysfs_emit()
instead of the older method of writing to the output buffer manually.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220809025054.1626339-6-luke@ljones.dev
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Maximilian Luz [Wed, 10 Aug 2022 14:41:17 +0000 (16:41 +0200)]
platform/surface: aggregator_registry: Add HID devices for sensors and UCSI client to SP8
Add software nodes for the HID sensor collection and the UCM UCSI HID
client to the Surface Pro 8. In contrast to the type-cover devices,
these devices are directly attached to the SAM controller, without any
hub.
This enables support for HID-based sensors, including the ones used for
automatic screen rotation, on the Surface Pro 8.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20220810144117.493710-4-luzmaximilian@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Maximilian Luz [Wed, 10 Aug 2022 14:41:16 +0000 (16:41 +0200)]
platform/surface: aggregator_registry: Rename HID device nodes based on new findings
On Windows, the HID devices with target ID 1 are grouped as "Surface Hot
Plug - SAM". Rename their device nodes in the registry to reflect that
and update the comments accordingly.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20220810144117.493710-3-luzmaximilian@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Maximilian Luz [Wed, 10 Aug 2022 14:41:15 +0000 (16:41 +0200)]
platform/surface: aggregator_registry: Rename HID device nodes based on their function
Rename HID device nodes based on their function. In particular, these
are nodes for firmware updates via the CFU mechanism (component firmware
update), HID based sensors, and a USB-C UCSI client.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20220810144117.493710-2-luzmaximilian@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Maximilian Luz [Wed, 10 Aug 2022 14:01:33 +0000 (16:01 +0200)]
platform/surface: aggregator_registry: Add support for Surface Laptop Go 2
The Surface Laptop Go 2 seems to have the same SAM client devices as the
Surface Laptop Go 1, so re-use its node group.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20220810140133.99087-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 10 Aug 2022 14:19:34 +0000 (16:19 +0200)]
platform/x86: x86-android-tablets: Fix broken touchscreen on Chuwi Hi8 with Windows BIOS
The x86-android-tablets handling for the Chuwi Hi8 is only necessary with
the Android BIOS and it is causing problems with the Windows BIOS version.
Specifically when trying to register the already present touchscreen
x86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks
the working of the touchscreen and also leads to an oops:
[ 14.248946] ------------[ cut here ]------------
[ 14.248954] remove_proc_entry: removing non-empty directory 'irq/75', leaking at least 'MSSL0001:00'
[ 14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry
...
[ 14.249293] unregister_irq_proc+0xe0/0x100
[ 14.249305] free_desc+0x29/0x70
[ 14.249312] irq_free_descs+0x4b/0x80
[ 14.249320] mp_unmap_irq+0x5c/0x60
[ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40
[ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets]
[ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets]
Add an init callback for the Chuwi Hi8, which detects when the Windows BIOS
is in use and exits with -ENODEV in that case, fixing this.
Fixes:
84c2dcdd475f ("platform/x86: x86-android-tablets: Add an init() callback to struct x86_dev_info")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220810141934.140771-1-hdegoede@redhat.com
Andy Shevchenko [Mon, 1 Aug 2022 11:37:34 +0000 (14:37 +0300)]
platform/x86: pmc_atom: Amend comment style and grammar
The style of the comments is not uniform, make it so and fix
a few grammar issues. While at it, update Copyright years.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220801113734.36131-4-andriy.shevchenko@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Andy Shevchenko [Mon, 1 Aug 2022 11:37:33 +0000 (14:37 +0300)]
platform/x86: pmc_atom: Make terminator entry uniform
Make terminator entry uniform by dropping:
- trailing commas
- anything inside curly braces
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220801113734.36131-3-andriy.shevchenko@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Andy Shevchenko [Mon, 1 Aug 2022 11:37:32 +0000 (14:37 +0300)]
platform/x86: pmc_atom: Improve quirk message to be less cryptic
Not everyone can get what "critclks" means in the message, improve
it to make less cryptic.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220801113734.36131-2-andriy.shevchenko@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Andy Shevchenko [Mon, 1 Aug 2022 11:37:31 +0000 (14:37 +0300)]
platform/x86: pmc_atom: Fix SLP_TYPx bitfield mask
On Intel hardware the SLP_TYPx bitfield occupies bits 10-12 as per ACPI
specification (see Table 4.13 "PM1 Control Registers Fixed Hardware
Feature Control Bits" for the details).
Fix the mask and other related definitions accordingly.
Fixes:
93e5eadd1f6e ("x86/platform: New Intel Atom SOC power management controller driver")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220801113734.36131-1-andriy.shevchenko@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Greg Kroah-Hartman [Fri, 29 Jul 2022 11:53:02 +0000 (13:53 +0200)]
platform/x86: dell-privacy: convert to use dev_groups
The driver core supports the ability to handle the creation and removal
of device-specific sysfs files in a race-free manner. Take advantage of
that by converting this driver to use this by moving the sysfs
attributes into a group and assigning the dev_groups pointer to it.
Cc: Perry Yuan <Perry.Yuan@dell.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mark Gross <markgross@kernel.org>
Cc: Dell.Client.Kernel@dell.com
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220729115302.2258296-1-gregkh@linuxfoundation.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 25 Aug 2022 14:23:39 +0000 (16:23 +0200)]
Merge branch 'platform-drivers-x86-amd-pmf' into pdx86-base
Hans de Goede [Fri, 15 Apr 2022 20:24:21 +0000 (22:24 +0200)]
drm/radeon: Don't register backlight when another backlight should be used (v3)
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:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI is enabled.
When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
the stubs from acpi/video.h will be used.
Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 15 Apr 2022 20:22:41 +0000 (22:22 +0200)]
drm/amdgpu: Don't register backlight when another backlight should be used (v3)
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:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI is enabled.
When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
the stubs from acpi/video.h will be used.
Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 15 Apr 2022 19:55:35 +0000 (21:55 +0200)]
drm/i915: Don't register backlight when another backlight should be used (v2)
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:
- Use drm_info(drm_dev, ...) for log messages
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>