platform/x86: Update alienware-wmi config entries

Add config entries for each WMI driver managed by the alienware-wmi
module to be able to conditionally compile them.

Reviewed-by: Armin Wolf <W_Arm

platform/x86: Update alienware-wmi config entries

Add config entries for each WMI driver managed by the alienware-wmi
module to be able to conditionally compile them.

Reviewed-by: Armin Wolf <[email protected]>
Reviewed-by: Mario Limonciello <[email protected]>
Signed-off-by: Kurt Borja <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

platform/x86: dell-smo8800: Move instantiation of lis3lv02d i2c_client from i2c-i801 to dell-lis3lv02d

Various Dell laptops have an lis3lv02d freefall/accelerometer sensor.
The lis3lv02d chip has an

platform/x86: dell-smo8800: Move instantiation of lis3lv02d i2c_client from i2c-i801 to dell-lis3lv02d

Various Dell laptops have an lis3lv02d freefall/accelerometer sensor.
The lis3lv02d chip has an interrupt line as well as an I2C connection to
the system's main SMBus.

The lis3lv02d is described in the ACPI tables by an SMO88xx ACPI device,
but the SMO88xx ACPI fwnodes are incomplete and only list an IRQ resource.

So far this has been worked around with some SMO88xx specific quirk code
in the generic i2c-i801 driver, but it is not necessary to handle the Dell
specific instantiation of i2c_client-s for SMO88xx ACPI devices there.

The kernel already instantiates platform_device-s for these with an
acpi:SMO88xx modalias. The drivers/platform/x86/dell/dell-smo8800.c
driver binds to this platform device but this only deals with
the interrupt resource. Add a drivers/platform/x86/dell/dell-lis3lv02d.c
which will matches on the same acpi:SMO88xx modaliases and move
the i2c_client instantiation from the generic i2c-i801 driver there.

Moving the i2c_client instantiation has the following advantages:

1. This moves the SMO88xx ACPI device quirk handling away from the generic
i2c-i801 module which is loaded on all Intel x86 machines to a module
which will only be loaded when there is an ACPI SMO88xx device.

2. This removes the duplication of the SMO88xx ACPI Hardware ID (HID) table
between the i2c-i801 and dell-smo8800 drivers.

3. This allows extending the quirk handling by adding new code and related
module parameters to the dell-lis3lv02d driver, without needing to modify
the i2c-i801 code.

Reviewed-by: Pali Rohár <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

alienware-wmi: added platform profile support

Implements platform profile support for Dell laptops with new WMAX thermal
interface, present on some Alienware X-Series, Alienware M-Series and
Dell's

alienware-wmi: added platform profile support

Implements platform profile support for Dell laptops with new WMAX thermal
interface, present on some Alienware X-Series, Alienware M-Series and
Dell's G-Series laptops. This interface is suspected to be used by
Alienware Command Center (AWCC), which is not available for linux
systems, to manage thermal profiles.

This implementation makes use of three WMI methods, namely
THERMAL_CONTROL, THERMAL_INFORMATION and GAME_SHIFT_STATUS, which take
u32 as input and output arguments. Each method has a set of supported
operations specified in their respective enums.

Not all models with WMAX WMI interface support these methods. Because of
this, models have to manually declare support through new quirks
`thermal` for THERMAL_CONTROL and THERMAL_INFORMATION and `gmode` for
GAME_SHIFT_STATUS.

Wrappers written for these methods support multiple operations.

THERMAL_CONTROL switches thermal modes through operation
ACTIVATE_PROFILE. Available thermal codes are auto-detected at runtime
and matched against a list of known thermal codes:

Thermal Table "User Selectable Thermal Tables" (USTT):
BALANCED 0xA0
BALANCED_PERFORMANCE 0xA1
COOL 0xA2
QUIET 0xA3
PERFORMANCE 0xA4
LOW_POWER 0xA5

Thermal Table Basic:
QUIET 0x96
BALANCED 0x97
BALANCED_PERFORMANCE 0x98
PERFORMANCE 0x99

Devices are known to implement only one of these tables without mixing
their thermal codes.

The fact that the least significant digit of every thermal code is
consecutive of one another is exploited to efficiently match codes
through arrays.

Autodetection of available codes is done through operation LIST_IDS of
method THERMAL_INFORMATION. This operation lists fan IDs, CPU sensor ID,
GPU sensor ID and available thermal profile codes, *in that order*. As
number of fans and thermal codes is very model dependent, almost every
ID is scanned and matched based on conditions found on
is_wmax_thermal_code(). The known upper bound for the number of IDs is
13, corresponding to a device that have 4 fans, 2 sensors and 7 thermal
codes.

Additionally G-Series laptops have a key called G-key, which (with AWCC
proprietary driver) switches the thermal mode to an special mode named
GMODE with code 0xAB and changes Game Shift Status to 1. Game Shift is a
mode the manufacturer claims, increases gaming performance.

GAME_SHIFT_STATUS method is used to mimic this behavior when selecting
PLATFORM_PROFILE_PERFORMANCE option.

All of these profiles are known to only change fan speed profiles,
although there are untested claims that some of them also change power
profiles.

Activating a thermal mode with method THERMAL_CONTROL may cause short
hangs. This is a known problem present on every platform.

Signed-off-by: Kurt Borja <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>
Reviewed-by: Armin Wolf <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

ACPI: EC: make EC support compile-time conditional

The embedded controller code is mainly used on x86 laptops and cannot
work without PC style I/O port access.

Make this a user-visible configuratio

ACPI: EC: make EC support compile-time conditional

The embedded controller code is mainly used on x86 laptops and cannot
work without PC style I/O port access.

Make this a user-visible configuration option that is default enabled
on x86 but otherwise disabled, and that can never be enabled unless
CONFIG_HAS_IOPORT is also available.

The empty stubs in internal.h help ignore the EC code in configurations
that don't support it. In order to see those stubs, the sbshc code also
has to include this header and drop duplicate declarations.

All the direct callers of ec_read/ec_write already had an x86
dependency and now also need to depend on APCI_EC.

Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

platform/x86:dell-laptop: Add knobs to change battery charge settings

The Dell BIOS allows you to set custom charging modes, which is useful
in particular for extending battery life. This adds suppo

platform/x86:dell-laptop: Add knobs to change battery charge settings

The Dell BIOS allows you to set custom charging modes, which is useful
in particular for extending battery life. This adds support for tweaking
those various settings from Linux via sysfs knobs. One might, for
example, have their laptop plugged into power at their desk the vast
majority of the time and choose fairly aggressive battery-saving
settings (eg, only charging once the battery drops below 50% and only
charging up to 80%). When leaving for a trip, it would be more useful
to instead switch to a standard charging mode (top off at 100%, charge
any time power is available). Rebooting into the BIOS to change the
charging mode settings is a hassle.

For the Custom charging type mode, we reuse the common
charge_control_{start,end}_threshold sysfs power_supply entries. The
BIOS also has a bunch of other charging modes (with varying levels of
usefulness), so this also adds a 'charge_type' sysfs entry that maps the
standard values to Dell-specific ones.

This work is based on a patch by Perry Yuan <[email protected]> and
Limonciello Mario <[email protected]> submitted back in 2020.

Hans de Goede:
s/charge_type/charge_types/ since charge_types_show() used the new
charge_types power-supply property output format.

Signed-off-by: Andres Salomon <[email protected]>
Reviewed-by: Pali Rohár <[email protected]>
Link: https://lore.kernel.org/r/20240820033005.09e03af1@5400
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: dell-uart-backlight: Use acpi_video_get_backlight_type()

The dell-uart-backlight driver supports backlight control on Dell All In
One (AIO) models using a backlight controller board co

platform/x86: dell-uart-backlight: Use acpi_video_get_backlight_type()

The dell-uart-backlight driver supports backlight control on Dell All In
One (AIO) models using a backlight controller board connected to an UART.

In DSDT this uart port will be defined as:

Name (_HID, "DELL0501")
Name (_CID, EisaId ("PNP0501")

Now the first AIO has turned up which has not only the DSDT bits for this,
but also an actual controller attached to the UART, yet it is not using
this controller for backlight control.

Use the acpi_video_get_backlight_type() function from the ACPI video-detect
code to check if the dell-uart-backlight driver should actually be used.
This allows reusing the existing ACPI video-detect infra to override
the backlight control method on the commandline or with DMI quirks.

Fixes: 484bae9e4d6a ("platform/x86: Add new Dell UART backlight driver")
Cc: All applicable <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

platform/x86: dell-pc: Implement platform_profile

Some Dell laptops support configuration of preset fan modes through
smbios tables.

If the platform supports these fan modes, set up platform_profil

platform/x86: dell-pc: Implement platform_profile

Some Dell laptops support configuration of preset fan modes through
smbios tables.

If the platform supports these fan modes, set up platform_profile to
change these modes. If not supported, skip enabling platform_profile.

Signed-off-by: Lyndon Sanche <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ij: Adjust #includes into alphabetical order]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

platform/x86: Add new Dell UART backlight driver

Dell All In One (AIO) models released after 2017 use a backlight controller
board connected to an UART.

In DSDT this uart port will be defined as:

platform/x86: Add new Dell UART backlight driver

Dell All In One (AIO) models released after 2017 use a backlight controller
board connected to an UART.

In DSDT this uart port will be defined as:

Name (_HID, "DELL0501")
Name (_CID, EisaId ("PNP0501")

Instead of having a separate ACPI device with an UartSerialBusV2() resource
to model the backlight-controller, which would be the standard way to do
this.

The acpi_quirk_skip_serdev_enumeration() has special handling for this
and it will make the serial port code create a serdev controller device
for the UART instead of a /dev/ttyS0 char-dev. It will also create
a dell-uart-backlight driver platform device for this driver to bind too.

This new kernel module contains 2 drivers for this:

1. A simple platform driver which creates the actual serdev device
(with the serdev controller device as parent)

2. A serdev driver for the created serdev device which exports
the backlight functionality uses a standard backlight class device.

Reported-by: Roman Bogoyev <[email protected]>
Tested-by: Roman Bogoyev <[email protected]>
Tested-by: Kai-Heng Feng <[email protected]>
Co-developed-by: AceLan Kao <[email protected]>
Signed-off-by: AceLan Kao <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86: remove obsolete calls to ledtrig_audio_get

Since 64f67b5240db ("leds: trigger: audio: Add an activate callback to
ensure the initial brightness is set") the audio triggers have an
acti

platform/x86: remove obsolete calls to ledtrig_audio_get

Since 64f67b5240db ("leds: trigger: audio: Add an activate callback to
ensure the initial brightness is set") the audio triggers have an
activate callback which sets the LED brightness as soon as the
(default) trigger is bound to the LED device. So we can remove the
call to ledtrig_audio_get.

Positive side effect: There's no code dependency to ledtrig-audio any
longer, what allows to remove some Kconfig dependencies.

Signed-off-by: Heiner Kallweit <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

Documentation: move driver-api/dcdbas to userspace-api/

This file documents a sysfs interface that is intended for systems
management software. It does NOT document any kind of kernel driver
API. It

Documentation: move driver-api/dcdbas to userspace-api/

This file documents a sysfs interface that is intended for systems
management software. It does NOT document any kind of kernel driver
API. It is also not meant to be used directly by system administrators
or users.

Cc: Stuart Hayes <[email protected]>
Cc: [email protected]
Signed-off-by: Vegard Nossum <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86: dell-ddv: Add hwmon support

Thanks to bugreport 216655 on bugzilla triggered by the
dell-smm-hwmon driver, the contents of the sensor buffers
could be almost completely decoded.
Add an

platform/x86: dell-ddv: Add hwmon support

Thanks to bugreport 216655 on bugzilla triggered by the
dell-smm-hwmon driver, the contents of the sensor buffers
could be almost completely decoded.
Add an hwmon interface for exposing the fan and thermal
sensor values. Since the WMI interface can be quite slow
on some machines, the sensor buffers are cached for 1 second
to lessen the performance impact.
The debugfs interface remains in place to aid in reverse-engineering
of unknown sensor types and the thermal buffer.

Tested-by: Antonín Skala <[email protected]>
Tested-by: Gustavo Walbon <[email protected]>
Signed-off-by: Armin Wolf <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: dell: Add new dell-wmi-ddv driver

The dell-wmi-ddv driver adds support for reading
the current temperature and ePPID of ACPI batteries
on supported Dell machines.

Since the WMI interf

platform/x86: dell: Add new dell-wmi-ddv driver

The dell-wmi-ddv driver adds support for reading
the current temperature and ePPID of ACPI batteries
on supported Dell machines.

Since the WMI interface used by this driver does not
do any input validation and thus cannot be used for probing,
the driver depends on the ACPI battery extension machanism
to discover batteries.

The driver also supports a debugfs interface for retrieving
buffers containing fan and thermal sensor information.
Since the meaing of the content of those buffers is currently
unknown, the interface is meant for reverse-engineering and
will likely be replaced with an hwmon interface once the
meaning has been understood.

The driver was tested on a Dell Inspiron 3505.

Signed-off-by: Armin Wolf <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86/dell: Kconfig: Remove unnecessary "depends on X86_PLATFORM_DEVICES"

platform/x86/dell/Kconfig is only sourced if X86_PLATFORM_DEVICES is set,
so it does not need to depend on it.

Revie

platform/x86/dell: Kconfig: Remove unnecessary "depends on X86_PLATFORM_DEVICES"

platform/x86/dell/Kconfig is only sourced if X86_PLATFORM_DEVICES is set,
so it does not need to depend on it.

Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86: dell-wmi-descriptor: disable by default

dell-wmi-descriptor only provides symbols to other drivers.
These drivers already select dell-wmi-descriptor when needed.

This fixes an issue w

platform/x86: dell-wmi-descriptor: disable by default

dell-wmi-descriptor only provides symbols to other drivers.
These drivers already select dell-wmi-descriptor when needed.

This fixes an issue where dell-wmi-descriptor is compiled as a module
with localyesconfig on a non-Dell machine.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: dell: Make DELL_WMI_PRIVACY depend on DELL_WMI

DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver,
so it must depend on the Kconfig option which enables the main
dell-wm

platform/x86: dell: Make DELL_WMI_PRIVACY depend on DELL_WMI

DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver,
so it must depend on the Kconfig option which enables the main
dell-wmi driver.

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86: dell: Make DELL_WMI_PRIVACY depend on DELL_WMI

DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver,
so it must depend on the Kconfig option which enables the main
dell-wm

platform/x86: dell: Make DELL_WMI_PRIVACY depend on DELL_WMI

DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver,
so it must depend on the Kconfig option which enables the main
dell-wmi driver.

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86: dell: fix DELL_WMI_PRIVACY dependencies & build error

When DELL_WMI=y, DELL_WMI_PRIVACY=y, and LEDS_TRIGGER_AUDIO=m, there
is a linker error since the LEDS trigger code is built as a l

platform/x86: dell: fix DELL_WMI_PRIVACY dependencies & build error

When DELL_WMI=y, DELL_WMI_PRIVACY=y, and LEDS_TRIGGER_AUDIO=m, there
is a linker error since the LEDS trigger code is built as a loadable
module. This happens because DELL_WMI_PRIVACY is a bool that depends
on a tristate (LEDS_TRIGGER_AUDIO=m), which can be dangerous.

ld: drivers/platform/x86/dell/dell-wmi-privacy.o: in function `dell_privacy_wmi_probe':
dell-wmi-privacy.c:(.text+0x3df): undefined reference to `ledtrig_audio_get'

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Perry Yuan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Hans de Goede <[email protected]>
Cc: Mark Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: dell: fix DELL_WMI_PRIVACY dependencies & build error

When DELL_WMI=y, DELL_WMI_PRIVACY=y, and LEDS_TRIGGER_AUDIO=m, there
is a linker error since the LEDS trigger code is built as a l

platform/x86: dell: fix DELL_WMI_PRIVACY dependencies & build error

When DELL_WMI=y, DELL_WMI_PRIVACY=y, and LEDS_TRIGGER_AUDIO=m, there
is a linker error since the LEDS trigger code is built as a loadable
module. This happens because DELL_WMI_PRIVACY is a bool that depends
on a tristate (LEDS_TRIGGER_AUDIO=m), which can be dangerous.

ld: drivers/platform/x86/dell/dell-wmi-privacy.o: in function `dell_privacy_wmi_probe':
dell-wmi-privacy.c:(.text+0x3df): undefined reference to `ledtrig_audio_get'

Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Perry Yuan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Hans de Goede <[email protected]>
Cc: Mark Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: dell-smo8800: Convert to be a platform driver

ACPI core in conjunction with platform driver core provides
an infrastructure to enumerate ACPI devices. Use it in order
to remove a lot o

platform/x86: dell-smo8800: Convert to be a platform driver

ACPI core in conjunction with platform driver core provides
an infrastructure to enumerate ACPI devices. Use it in order
to remove a lot of boilerplate code.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Pali Rohár <[email protected]>
Tested-by: Pali Rohár <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: Remove "default n" entries

Linus already once did that for PDx86, don't repeat our mistakes.
TL;DR: 'n' *is* the default 'default'.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@l

platform/x86: Remove "default n" entries

Linus already once did that for PDx86, don't repeat our mistakes.
TL;DR: 'n' *is* the default 'default'.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: dell-wmi-sysman: Use firmware_attributes_class helper

Update Dell WMI sysman driver to use newly implemented helper module.

Reviewed-by: Hans de Goede <[email protected]>
Signed-off

platform/x86: dell-wmi-sysman: Use firmware_attributes_class helper

Update Dell WMI sysman driver to use newly implemented helper module.

Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Mark Pearson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: dell-privacy: Add support for Dell hardware privacy

add support for Dell privacy driver for the Dell units equipped
hardware privacy design, which protect users privacy of audio and
ca

platform/x86: dell-privacy: Add support for Dell hardware privacy

add support for Dell privacy driver for the Dell units equipped
hardware privacy design, which protect users privacy of audio and
camera from hardware level. Once the audio or camera privacy mode
activated, any applications will not get any audio or video stream
when user pressed ctrl+F4 hotkey, audio privacy mode will be
enabled, micmute led will be also changed accordingly
The micmute led is fully controlled by hardware & EC(embedded controller)
and camera mute hotkey is Ctrl+F9. Currently design only emits
SW_CAMERA_LENS_COVER event while the camera lens shutter will be
changed by EC & HW(hardware) control

*The flow is like this:
1) User presses key. HW does stuff with this key (timeout timer is started)
2) WMI event is emitted from BIOS to kernel
3) WMI event is received by dell-privacy
4) KEY_MICMUTE emitted from dell-privacy
5) Userland picks up key and modifies kcontrol for SW mute
6) Codec kernel driver catches and calls ledtrig_audio_set
7) dell-privacy notifies EC, the timeout is cancelled and the HW mute
is activated. If the EC is not notified then the HW mic mute will
activate when the timeout triggers, just a bit later than with the
active ack.

Signed-off-by: Perry Yuan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[[email protected]: Rework Kconfig/Makefile bits + other small fixups]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: Move all dell drivers to their own subdirectory

A user without a Dell system doesn't need to pick any of these
drivers.

Users with a Dell system can enable this submenu and all driver

platform/x86: Move all dell drivers to their own subdirectory

A user without a Dell system doesn't need to pick any of these
drivers.

Users with a Dell system can enable this submenu and all drivers
behind it will be enabled.

Suggested-by: Andy Shevchenko <[email protected]>
Signed-off-by: Mario Limonciello <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...