History log of /linux/drivers/platform/wmi/core.c (Results 1 – 25 of 232)
Revision Date Author Comments
# c17ee635 23-Feb-2026 Maxime Ripard <mripard@kernel.org>

Merge drm/drm-fixes into drm-misc-fixes

7.0-rc1 was just released, let's merge it to kick the new release cycle.

Signed-off-by: Maxime Ripard <mripard@kernel.org>


# bf4afc53 22-Feb-2026 Linus Torvalds <torvalds@linux-foundation.org>

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

This was done entirely with mindless brute force, using

git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

This was done entirely with mindless brute force, using

git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'

to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.

Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.

For the same reason the 'flex' versions will be done as a separate
conversion.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...


# 8934827d 21-Feb-2026 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'kmalloc_obj-treewide-v7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull kmalloc_obj conversion from Kees Cook:
"This does the tree-wide conversion to kmalloc_obj(

Merge tag 'kmalloc_obj-treewide-v7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull kmalloc_obj conversion from Kees Cook:
"This does the tree-wide conversion to kmalloc_obj() and friends using
coccinelle, with a subsequent small manual cleanup of whitespace
alignment that coccinelle does not handle.

This uncovered a clang bug in __builtin_counted_by_ref(), so the
conversion is preceded by disabling that for current versions of
clang. The imminent clang 22.1 release has the fix.

I've done allmodconfig build tests for x86_64, arm64, i386, and arm. I
did defconfig builds for alpha, m68k, mips, parisc, powerpc, riscv,
s390, sparc, sh, arc, csky, xtensa, hexagon, and openrisc"

* tag 'kmalloc_obj-treewide-v7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
kmalloc_obj: Clean up after treewide replacements
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
compiler_types: Disable __builtin_counted_by_ref for Clang

show more ...


# 69050f8d 21-Feb-2026 Kees Cook <kees@kernel.org>

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid sc

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)

Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook <kees@kernel.org>

show more ...


# f50822fd 13-Feb-2026 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'platform-drivers-x86-v7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform driver updates from Ilpo Järvinen:
"Highlights:

- amd/pmf:

Merge tag 'platform-drivers-x86-v7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform driver updates from Ilpo Järvinen:
"Highlights:

- amd/pmf:
- Avoid overwriting BIOS input values when events occur rapidly
- Fix PMF driver issues related to S4 (in part on crypto/ccp side)
- Add NPU metrics API (for accel side consumers)
- Allow disabling Smart PC function through a module parameter

- asus-wmi & HID/asus:
- Unification of backlight control (replaces quirks)
- Support multiple interfaces for controlling keyboard/RGB brightness
- Simplify init sequence

- hp-wmi:
- Add manual fan control for Victus S models
- Add fan mode keep-alive
- Fix platform profile values for Omen 16-wf1xxx
- Add EC offset to get the thermal profile

- intel/pmc: Show substate residencies also for non-primary PMCs

- intel/ISST:
- Store and restore data for all domains
- Write interface improvements

- lenovo-wmi:
- Support multiple Capability Data
- Add HWMON reporting and tuning support

- mellanox/mlx-platform: Add HI173 & HI174 support

- surface/aggregator_registry: Add Surface Pro 11 (QCOM)

- thinkpad_acpi: Add support for HW damage detection capability

- uniwill: Implement cTGP setting

- wmi:
- Introduce marshalling support
- Convert a few drivers to use the new buffer-based WMI API

- tools/power/x86/intel-speed-select: Allow read operations for non-root

- Miscellaneous cleanups / refactoring / improvements"

* tag 'platform-drivers-x86-v7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (68 commits)
platform/x86: lenovo-wmi-{capdata,other}: Fix HWMON channel visibility
platform/x86: hp-wmi: Add EC offsets to read Victus S thermal profile
platform: mellanox: mlx-platform: Add support DGX flavor of next-generation 800GB/s ethernet switch.
platform: mellanox: mlx-platform: Add support for new Nvidia DGX system based on class VMOD0010
HID: asus: add support for the asus-wmi brightness handler
platform/x86: asus-wmi: add keyboard brightness event handler
platform/x86: asus-wmi: remove unused keyboard backlight quirk
HID: asus: listen to the asus-wmi brightness device instead of creating one
platform/x86: asus-wmi: Add support for multiple kbd led handlers
HID: asus: early return for ROG devices
HID: asus: move vendor initialization to probe
HID: asus: fortify keyboard handshake
HID: asus: use same report_id in response
HID: asus: initialize additional endpoints only for certain devices
HID: asus: simplify RGB init sequence
platform/wmi: string-kunit: Add missing oversized string test case
platform/x86/amd/pmf: Added a module parameter to disable the Smart PC function
platform/x86/uniwill: Implement cTGP setting
platform/x86: uniwill-laptop: Introduce device descriptor system
platform/x86/amd: Use scope-based cleanup for wbrf_record()
...

show more ...


# 015b70a6 16-Jan-2026 Armin Wolf <W_Armin@gmx.de>

platform/wmi: Introduce marshalling support

The Windows WMI-ACPI driver likely uses wmilib [1] to interact with
the WMI service in userspace. Said library uses plain byte buffers
for exchanging data

platform/wmi: Introduce marshalling support

The Windows WMI-ACPI driver likely uses wmilib [1] to interact with
the WMI service in userspace. Said library uses plain byte buffers
for exchanging data, so the WMI-ACPI driver has to convert between
those byte buffers and ACPI objects returned by the ACPI firmware.

The format of the byte buffer is publicly documented [2], and after
some reverse eingineering of the WMI-ACPI driver using a set of custom
ACPI tables, the following conversion rules have been discovered:

- ACPI integers are always converted into a uint32
- ACPI strings are converted into special WMI strings
- ACPI buffers are copied as-is
- ACPI packages are unpacked

Extend the ACPI-WMI driver to also perform this kind of marshalling
for WMI data blocks, methods and events. Doing so gives us a number
of benefits:

- WMI drivers are not restricted to a fixed set of supported ACPI data
types anymore, see dell-wmi-aio (integer vs buffer) and
hp-wmi-sensors (string vs buffer)

- correct marshalling of WMI strings when data blocks are marked
as requiring ACPI strings instead of ACPI buffers

- development of WMI drivers without having to understand ACPI

This eventually should result in better compatibility with some
ACPI firmware implementations and in simpler WMI drivers. There are
however some differences between the original Windows driver and
the ACPI-WMI driver when it comes to ACPI object conversions:

- the Windows driver copies internal _ACPI_METHOD_ARGUMENT_V1 data
structures into the output buffer when encountering nested ACPI
packages. This is very likely an error inside the driver itself, so
we do not support nested ACPI packages.

- when converting WMI strings (UTF-16LE) into ACPI strings (ASCII),
the Windows driver replaces non-ascii characters (ä -> a, & -> ?)
instead of returning an error. This behavior is not documented
anywhere and might lead to severe errors in some cases (like
setting BIOS passwords over WMI), so we simply return an error.

As the current bus-based WMI API is based on ACPI buffers, a new
API is necessary. The legacy GUID-based WMI API is not extended to
support marshalling, as WMI drivers using said API are expected to
move to the bus-based WMI API in the future.

[1] https://learn.microsoft.com/de-de/windows-hardware/drivers/ddi/wmilib/
[2] https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/
driver-defined-wmi-data-items

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260116204116.4030-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# ec496f77 09-Feb-2026 Jiri Kosina <jkosina@suse.com>

Merge branch 'for-6.20/sony' into for-linus

- Support for Rock band 4 PS4 and PS5 guitars (Rosalie Wanders)


# cc4adab1 20-Jan-2026 Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

Merge tag 'v6.19-rc1' into msm-next

Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC
config database defining UBWC_6).

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.q

Merge tag 'v6.19-rc1' into msm-next

Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC
config database defining UBWC_6).

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

show more ...


# 5add3c3c 19-Dec-2025 Thomas Hellström <thomas.hellstrom@linux.intel.com>

Merge drm/drm-next into drm-xe-next

Backmerging to bring in 6.19-rc1. An important upstream bugfix and
to help unblock PTL CI.

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>


# b8304863 15-Dec-2025 Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge drm/drm-next into drm-intel-next

Sync-up some display code needed for Async flips refactor.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>


# 7f790dd2 15-Dec-2025 Maxime Ripard <mripard@kernel.org>

Merge drm/drm-next into drm-misc-next

Let's kickstart the v6.20 (7.0?) release cycle.

Signed-off-by: Maxime Ripard <mripard@kernel.org>


# ec439c38 17-Dec-2025 Alexei Starovoitov <ast@kernel.org>

Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after 6.19-rc1

Cross-merge BPF and other fixes after downstream PR.

Signed-off-by: Alexei Starovoitov <ast@kernel.org>


# 24f171c7 21-Dec-2025 Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-fix-v6.19-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v6.19

We've been quite busy with fixes since the merge window, though

Merge tag 'asoc-fix-v6.19-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v6.19

We've been quite busy with fixes since the merge window, though not in
any particularly exciting ways - the standout thing is the fix for _SX
controls which were broken by a change to how we do clamping, otherwise
it's all fairly run of the mill fixes and quirks.

show more ...


# 84318277 15-Dec-2025 Maarten Lankhorst <dev@lankhorst.se>

Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

Pull in rc1 to include all changes since the merge window closed,
and grab all fixes and changes from drm/drm-next.

Signed-off-by: M

Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

Pull in rc1 to include all changes since the merge window closed,
and grab all fixes and changes from drm/drm-next.

Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

show more ...


# e2c1b56f 11-Nov-2025 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Move WMI core code into a separate directory

Move the WMI core code into a separate directory to prepare for
future additions to the WMI driver. Also update the description
of the

platform/x86: wmi: Move WMI core code into a separate directory

Move the WMI core code into a separate directory to prepare for
future additions to the WMI driver. Also update the description
of the Kconfig entry to better fit with the other subsystem
Kconfig entries.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20251111131125.3379-5-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# c209195a 11-Nov-2025 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Use correct type when populating ACPI objects

When evaluating a WMxx/WSxx ACPI control method, the data buffer
either needs to be passed as an ACPI buffer or as an ACPI string.
Us

platform/x86: wmi: Use correct type when populating ACPI objects

When evaluating a WMxx/WSxx ACPI control method, the data buffer
either needs to be passed as an ACPI buffer or as an ACPI string.
Use the correct type (buffer/string) when populating the associated
ACPI object.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20251111131125.3379-3-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# 88e326b3 02-Jul-2025 Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

Merge branch 'fixes' into for-next

Merge fixes back into for-next to be able to take dell_rbu change that
is build on top of fixes material, and to bring lenovo related changes
in sync after the mov

Merge branch 'fixes' into for-next

Merge fixes back into for-next to be able to take dell_rbu change that
is build on top of fixes material, and to bring lenovo related changes
in sync after the move under lenovo/ subdir in the for-next branch and
diverging changes in the fixes branch.

show more ...


# cf0b8125 19-Jun-2025 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Fix WMI event enablement

It turns out that the Windows WMI-ACPI driver always enables/disables
WMI events regardless of whether they are marked as expensive or not.
This finding i

platform/x86: wmi: Fix WMI event enablement

It turns out that the Windows WMI-ACPI driver always enables/disables
WMI events regardless of whether they are marked as expensive or not.
This finding is further reinforced when reading the documentation of
the WMI_FUNCTION_CONTROL_CALLBACK callback used by Windows drivers
for enabling/disabling WMI devices:

The DpWmiFunctionControl routine enables or disables
notification of events, and enables or disables data
collection for data blocks that the driver registered
as expensive to collect.

Follow this behavior to fix the WMI event used for reporting hotkey
events on the Dell Latitude 5400 and likely many more devices.

Reported-by: Dmytro Bagrii <dimich.dmb@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220246
Tested-by: Dmytro Bagrii <dimich.dmb@gmail.com>
Fixes: 656f0961d126 ("platform/x86: wmi: Rework WCxx/WExx ACPI method handling")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250619221440.6737-1-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# 73f0f2b5 10-Jun-2025 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Fix WMI device naming issue

When multiple WMI devices with the same GUID are present
inside a given system, the WMI driver core might fail to
register all of them.

Consider the f

platform/x86: wmi: Fix WMI device naming issue

When multiple WMI devices with the same GUID are present
inside a given system, the WMI driver core might fail to
register all of them.

Consider the following scenario:

WMI devices (<GUID>[-<ID>]):
05901221-D566-11D1-B2F0-00A0C9062910 (on PNP0C14:00)
05901221-D566-11D1-B2F0-00A0C9062910-1 (on PNP0C14:01)

If the WMI core driver somehow unbinds from PNP0C14:00, the following
will happen upon rebinding:

1. The WMI driver core counts all registered WMI devices with a GUID
of 05901221-D566-11D1-B2F0-00A0C9062910 (count: 1).

2. The new WMI device will be named
"05901221-D566-11D1-B2F0-00A0C9062910-1" because another device
with the same GUID is already registered (on PNP0C14:01).

3. The new WMI device cannot be registered due to a name conflict.

Use a IDA when building the WMI device name to avoid such name
collisions by ensuring that a given WMI device ID is not reused.

Userspace applications using udev for WMI device detection are not
impacted by this change. Additionally userspace applications that do
fully support the existing naming scheme are also not impacted. Only
userspace applications using hardcoded sysfs paths will break.
Introduce a kconfig option for restoring the old naming scheme to
give developers time to fix any compatibility issues.

Tested on a Asus Prime B650-Plus.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250610055526.23688-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# 08c9f402 16-Feb-2025 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Call WCxx methods when setting data blocks

After performing some tests with a custom SSDT table available at
https://github.com/Wer-Wolf/acpi-wmi-ssdt i found out that Windows
als

platform/x86: wmi: Call WCxx methods when setting data blocks

After performing some tests with a custom SSDT table available at
https://github.com/Wer-Wolf/acpi-wmi-ssdt i found out that Windows
also enables data block collection even when the data block is
being set.

Emulate this behaviour to avoid confusing the ACPI firmware.
The bus-based API already implements this behaviour, so only the
legacy GUID-based API needs to be changed.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250216193251.866125-8-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# 656f0961 16-Feb-2025 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Rework WCxx/WExx ACPI method handling

The handling of the WExx ACPI methods used for enabling and disabling
WMI events has multiple flaws:

- the ACPI methods are called even when

platform/x86: wmi: Rework WCxx/WExx ACPI method handling

The handling of the WExx ACPI methods used for enabling and disabling
WMI events has multiple flaws:

- the ACPI methods are called even when the WMI device has not been
marked as expensive.

- WExx ACPI methods might be called for inappropriate WMI devices.

- the error code AE_NOT_FOUND is treated as success.

The handling of the WCxx ACPI methods used for enabling and disabling
WMI data blocks is also flawed:

- WMI data blocks are enabled and disabled for every single "query"
operation. This is racy and inefficient.

Unify the handling of both ACPI methods by introducing a common
helper function for enabling and disabling WMI devices.

Also enable/disable WMI data blocks during probe/remove and shutdown
to match the handling of WMI events.

Legacy GUID-based functions still have to enable/disable the WMI
device manually and thus still suffer from a potential race condition.
Since those functions are deprecated and suffer from various other
flaws this issue is purposefully not fixed.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250216193251.866125-7-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# b6b56690 16-Feb-2025 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Use devres to disable the WMI device

Use devm_add_action_or_reset() to disable the WMI device instead of
manually calling wmi_method_enable() to prepare for future changes
inside

platform/x86: wmi: Use devres to disable the WMI device

Use devm_add_action_or_reset() to disable the WMI device instead of
manually calling wmi_method_enable() to prepare for future changes
inside the WMI data block handlign code.

The reason for this is that we have to make sure that all
devres-managed resources are released first because some might still
want to access the underlying WMI device.

Because devres-managed resources are not released during shutdown
we still have to manually disable the WMI device in this case.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250216193251.866125-6-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# e001341a 26-Oct-2024 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Introduce to_wmi_driver()

Introduce to_wmi_driver() as a replacement for dev_to_wdrv()
so WMI drivers can use this support macro instead of having
to duplicate its functionality.

platform/x86: wmi: Introduce to_wmi_driver()

Introduce to_wmi_driver() as a replacement for dev_to_wdrv()
so WMI drivers can use this support macro instead of having
to duplicate its functionality.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20241026193803.8802-3-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# c382429b 26-Oct-2024 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Replace dev_to_wdev() with to_wmi_device()

Replace dev_to_wdev() with to_wmi_device() to stop duplicating
functionality.

Also switch to_wmi_device() to use container_of_const() s

platform/x86: wmi: Replace dev_to_wdev() with to_wmi_device()

Replace dev_to_wdev() with to_wmi_device() to stop duplicating
functionality.

Also switch to_wmi_device() to use container_of_const() so const
values are handled correctly.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20241026193803.8802-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


# 049571ce 26-Oct-2024 Armin Wolf <W_Armin@gmx.de>

platform/x86: wmi: Remove wmi_block_list

The wmi_block_list is only used by guid_count() and without proper
protection. It also duplicates some of the WMI bus functionality.

Remove the wmi_block_li

platform/x86: wmi: Remove wmi_block_list

The wmi_block_list is only used by guid_count() and without proper
protection. It also duplicates some of the WMI bus functionality.

Remove the wmi_block_list and use bus_for_each_dev() instead.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20241026193803.8802-1-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

show more ...


12345678910