2019-05-19 13:07:45 +01:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2013-11-07 14:25:45 -08:00
|
|
|
#
|
|
|
|
|
# Platform support for Chrome OS hardware (Chromebooks and Chromeboxes)
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
menuconfig CHROME_PLATFORMS
|
|
|
|
|
bool "Platform support for Chrome hardware"
|
2015-07-01 12:46:42 +02:00
|
|
|
depends on X86 || ARM || ARM64 || COMPILE_TEST
|
2020-06-14 01:50:22 +09:00
|
|
|
help
|
2013-11-07 14:25:45 -08:00
|
|
|
Say Y here to get to see options for platform support for
|
|
|
|
|
various Chromebooks and Chromeboxes. This option alone does
|
|
|
|
|
not add any kernel code.
|
|
|
|
|
|
|
|
|
|
If you say N, all options in this submenu will be skipped and disabled.
|
|
|
|
|
|
|
|
|
|
if CHROME_PLATFORMS
|
|
|
|
|
|
2022-05-13 12:52:09 +05:00
|
|
|
config CHROMEOS_ACPI
|
|
|
|
|
tristate "ChromeOS specific ACPI extensions"
|
|
|
|
|
depends on ACPI
|
|
|
|
|
help
|
|
|
|
|
This driver provides the firmware interface for the services
|
|
|
|
|
exported through the ChromeOS interfaces when using ChromeOS
|
|
|
|
|
ACPI firmware.
|
|
|
|
|
|
|
|
|
|
If you have an ACPI-compatible Chromebook, say Y or M here.
|
|
|
|
|
The module will be called chromeos_acpi.
|
|
|
|
|
|
2013-11-07 14:25:45 -08:00
|
|
|
config CHROMEOS_LAPTOP
|
|
|
|
|
tristate "Chrome OS Laptop"
|
2015-02-02 12:26:25 +01:00
|
|
|
depends on I2C && DMI && X86
|
2020-06-14 01:50:22 +09:00
|
|
|
help
|
2013-11-07 14:25:45 -08:00
|
|
|
This driver instantiates i2c and smbus devices such as
|
|
|
|
|
light sensors and touchpads.
|
|
|
|
|
|
|
|
|
|
If you have a supported Chromebook, choose Y or M here.
|
|
|
|
|
The module will be called chromeos_laptop.
|
|
|
|
|
|
2013-11-12 13:32:13 -08:00
|
|
|
config CHROMEOS_PSTORE
|
|
|
|
|
tristate "Chrome OS pstore support"
|
2015-02-02 12:26:25 +01:00
|
|
|
depends on X86
|
2020-06-14 01:50:22 +09:00
|
|
|
help
|
2013-11-12 13:32:13 -08:00
|
|
|
This module instantiates the persistent storage on x86 ChromeOS
|
|
|
|
|
devices. It can be used to store away console logs and crash
|
|
|
|
|
information across reboots.
|
|
|
|
|
|
|
|
|
|
The range of memory used is 0xf00000-0x1000000, traditionally
|
|
|
|
|
the memory used to back VGA controller memory.
|
|
|
|
|
|
|
|
|
|
If you have a supported Chromebook, choose Y or M here.
|
|
|
|
|
The module will be called chromeos_pstore.
|
|
|
|
|
|
2017-01-30 15:47:22 -08:00
|
|
|
config CHROMEOS_TBMC
|
|
|
|
|
tristate "ChromeOS Tablet Switch Controller"
|
|
|
|
|
depends on ACPI
|
2018-05-28 17:58:46 +02:00
|
|
|
depends on INPUT
|
2017-01-30 15:47:22 -08:00
|
|
|
help
|
|
|
|
|
This option adds a driver for the tablet switch on
|
|
|
|
|
select Chrome OS systems.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called chromeos_tbmc.
|
|
|
|
|
|
platform/chrome: Introduce device tree hardware prober
Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.
This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.
Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component prober. For any given
class of devices on the same I2C bus, it will go through all of them,
doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.
This requires some minor modifications in the existing device tree.
The status for all the device nodes for the component options must be
set to "fail-needs-probe". This makes it clear that some mechanism is
needed to enable one of them, and also prevents the prober and device
drivers running at the same time.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-06 17:33:33 +08:00
|
|
|
config CHROMEOS_OF_HW_PROBER
|
|
|
|
|
tristate "ChromeOS Device Tree Hardware Prober"
|
|
|
|
|
depends on OF
|
|
|
|
|
depends on I2C
|
|
|
|
|
select OF_DYNAMIC
|
|
|
|
|
default OF
|
|
|
|
|
help
|
|
|
|
|
This option enables the device tree hardware prober for ChromeOS
|
|
|
|
|
devices. The driver will probe the correct component variant in
|
|
|
|
|
devices that have multiple drop-in options for one component.
|
|
|
|
|
|
2019-09-02 11:53:01 +02:00
|
|
|
config CROS_EC
|
|
|
|
|
tristate "ChromeOS Embedded Controller"
|
|
|
|
|
select CROS_EC_PROTO
|
|
|
|
|
depends on X86 || ARM || ARM64 || COMPILE_TEST
|
|
|
|
|
help
|
|
|
|
|
If you say Y here you get support for the ChromeOS Embedded
|
|
|
|
|
Controller (EC) providing keyboard, battery and power services.
|
|
|
|
|
You also need to enable the driver for the bus you are using. The
|
|
|
|
|
protocol for talking to the EC is defined by the bus driver.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec.
|
|
|
|
|
|
2018-07-02 12:21:59 +02:00
|
|
|
config CROS_EC_I2C
|
|
|
|
|
tristate "ChromeOS Embedded Controller (I2C)"
|
2019-09-02 11:53:01 +02:00
|
|
|
depends on CROS_EC && I2C
|
2018-07-02 12:21:59 +02:00
|
|
|
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you get support for talking to the ChromeOS
|
|
|
|
|
EC through an I2C bus. This uses a simple byte-level protocol with
|
|
|
|
|
a checksum. Failing accesses will be retried three times to
|
|
|
|
|
improve reliability.
|
|
|
|
|
|
2019-04-12 15:18:50 +08:00
|
|
|
config CROS_EC_RPMSG
|
|
|
|
|
tristate "ChromeOS Embedded Controller (rpmsg)"
|
2019-09-02 11:53:01 +02:00
|
|
|
depends on CROS_EC && RPMSG && OF
|
2019-04-12 15:18:50 +08:00
|
|
|
help
|
|
|
|
|
If you say Y here, you get support for talking to the ChromeOS EC
|
|
|
|
|
through rpmsg. This uses a simple byte-level protocol with a
|
|
|
|
|
checksum. Also since there's no addition EC-to-host interrupt, this
|
|
|
|
|
use a byte in message to distinguish host event from host command.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_rpmsg.
|
|
|
|
|
|
2019-05-15 16:08:41 +05:30
|
|
|
config CROS_EC_ISHTP
|
|
|
|
|
tristate "ChromeOS Embedded Controller (ISHTP)"
|
2019-09-02 11:53:04 +02:00
|
|
|
depends on CROS_EC
|
2019-05-15 16:08:41 +05:30
|
|
|
depends on INTEL_ISH_HID
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you get support for talking to the ChromeOS EC
|
|
|
|
|
firmware running on Intel Integrated Sensor Hub (ISH), using the
|
|
|
|
|
ISH Transport protocol (ISH-TP). This uses a simple byte-level
|
|
|
|
|
protocol with a checksum.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_ishtp.
|
|
|
|
|
|
2018-07-02 12:21:59 +02:00
|
|
|
config CROS_EC_SPI
|
|
|
|
|
tristate "ChromeOS Embedded Controller (SPI)"
|
2019-09-02 11:53:01 +02:00
|
|
|
depends on CROS_EC && SPI
|
2018-07-02 12:21:59 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
help
|
2018-07-02 12:21:59 +02:00
|
|
|
If you say Y here, you get support for talking to the ChromeOS EC
|
|
|
|
|
through a SPI bus, using a byte-level protocol. Since the EC's
|
|
|
|
|
response time cannot be guaranteed, we support ignoring
|
|
|
|
|
'pre-amble' bytes before the response actually starts.
|
|
|
|
|
|
2022-12-27 12:32:22 -07:00
|
|
|
config CROS_EC_UART
|
|
|
|
|
tristate "ChromeOS Embedded Controller (UART)"
|
|
|
|
|
depends on CROS_EC && ACPI && SERIAL_DEV_BUS
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you get support for talking to the ChromeOS EC
|
|
|
|
|
through a UART, using a byte-level protocol.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_uart.
|
|
|
|
|
|
2015-02-02 12:26:24 +01:00
|
|
|
config CROS_EC_LPC
|
platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime
On many boards, communication between the kernel and the Embedded
Controller happens over an LPC bus. In these cases, the kernel config
CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a
Microchip Embedded Controller (MEC) that is different from the regular
EC. On these devices, the same LPC bus is used, but the protocol is
a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel
config is enabled. Currently, the kernel decides at compile-time whether
or not to use the MEC variant, and, when that kernel option is selected
it breaks the other boards. We would like a kind of runtime detection to
avoid this.
This patch adds that detection mechanism by probing the protocol at
runtime, first we assume that a MEC variant is connected, and if the
protocol fails it fallbacks to the regular EC. This adds a bit of
overload because we try to read twice on those LPC boards that doesn't
contain a MEC variant, but is a better solution than having to select the
EC variant at compile-time.
While here also fix the alignment in Kconfig file for this config option
replacing the spaces by tabs.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Nick Crews <ncrews@chromium.org>
Reviewed-by: Nick Crews <ncrews@chromium.org>
2019-06-14 23:43:01 +02:00
|
|
|
tristate "ChromeOS Embedded Controller (LPC)"
|
2019-09-02 11:53:01 +02:00
|
|
|
depends on CROS_EC && ACPI && (X86 || COMPILE_TEST)
|
2024-04-05 15:41:51 +02:00
|
|
|
depends on HAS_IOPORT
|
2017-05-16 17:46:48 +02:00
|
|
|
help
|
platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime
On many boards, communication between the kernel and the Embedded
Controller happens over an LPC bus. In these cases, the kernel config
CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a
Microchip Embedded Controller (MEC) that is different from the regular
EC. On these devices, the same LPC bus is used, but the protocol is
a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel
config is enabled. Currently, the kernel decides at compile-time whether
or not to use the MEC variant, and, when that kernel option is selected
it breaks the other boards. We would like a kind of runtime detection to
avoid this.
This patch adds that detection mechanism by probing the protocol at
runtime, first we assume that a MEC variant is connected, and if the
protocol fails it fallbacks to the regular EC. This adds a bit of
overload because we try to read twice on those LPC boards that doesn't
contain a MEC variant, but is a better solution than having to select the
EC variant at compile-time.
While here also fix the alignment in Kconfig file for this config option
replacing the spaces by tabs.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Nick Crews <ncrews@chromium.org>
Reviewed-by: Nick Crews <ncrews@chromium.org>
2019-06-14 23:43:01 +02:00
|
|
|
If you say Y here, you get support for talking to the ChromeOS EC
|
|
|
|
|
over an LPC bus, including the LPC Microchip EC (MEC) variant.
|
|
|
|
|
This uses a simple byte-level protocol with a checksum. This is
|
|
|
|
|
used for userspace access only. The kernel typically has its own
|
|
|
|
|
communication methods.
|
2017-05-16 17:46:48 +02:00
|
|
|
|
platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime
On many boards, communication between the kernel and the Embedded
Controller happens over an LPC bus. In these cases, the kernel config
CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a
Microchip Embedded Controller (MEC) that is different from the regular
EC. On these devices, the same LPC bus is used, but the protocol is
a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel
config is enabled. Currently, the kernel decides at compile-time whether
or not to use the MEC variant, and, when that kernel option is selected
it breaks the other boards. We would like a kind of runtime detection to
avoid this.
This patch adds that detection mechanism by probing the protocol at
runtime, first we assume that a MEC variant is connected, and if the
protocol fails it fallbacks to the regular EC. This adds a bit of
overload because we try to read twice on those LPC boards that doesn't
contain a MEC variant, but is a better solution than having to select the
EC variant at compile-time.
While here also fix the alignment in Kconfig file for this config option
replacing the spaces by tabs.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Nick Crews <ncrews@chromium.org>
Reviewed-by: Nick Crews <ncrews@chromium.org>
2019-06-14 23:43:01 +02:00
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_lpcs.
|
2017-05-16 17:46:48 +02:00
|
|
|
|
2015-06-09 13:04:44 +02:00
|
|
|
config CROS_EC_PROTO
|
2025-03-28 13:26:12 +00:00
|
|
|
tristate
|
2019-11-20 21:40:13 +08:00
|
|
|
help
|
|
|
|
|
ChromeOS EC communication protocol helpers.
|
2015-06-09 13:04:44 +02:00
|
|
|
|
2016-03-08 11:12:46 -08:00
|
|
|
config CROS_KBD_LED_BACKLIGHT
|
|
|
|
|
tristate "Backlight LED support for Chrome OS keyboards"
|
2025-04-14 21:24:27 +08:00
|
|
|
depends on LEDS_CLASS
|
|
|
|
|
depends on MFD_CROS_EC_DEV || (MFD_CROS_EC_DEV=n && ACPI)
|
2016-03-08 11:12:46 -08:00
|
|
|
help
|
|
|
|
|
This option enables support for the keyboard backlight LEDs on
|
|
|
|
|
select Chrome OS systems.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_kbd_led_backlight.
|
|
|
|
|
|
2019-09-02 11:53:02 +02:00
|
|
|
config CROS_EC_CHARDEV
|
|
|
|
|
tristate "ChromeOS EC miscdevice"
|
2019-09-02 11:53:04 +02:00
|
|
|
depends on MFD_CROS_EC_DEV
|
|
|
|
|
default MFD_CROS_EC_DEV
|
2019-09-02 11:53:02 +02:00
|
|
|
help
|
|
|
|
|
This driver adds file operations support to talk with the
|
|
|
|
|
ChromeOS EC from userspace via a character device.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_chardev.
|
|
|
|
|
|
2018-12-12 18:33:57 +01:00
|
|
|
config CROS_EC_LIGHTBAR
|
|
|
|
|
tristate "Chromebook Pixel's lightbar support"
|
2019-09-02 11:53:04 +02:00
|
|
|
depends on MFD_CROS_EC_DEV
|
|
|
|
|
default MFD_CROS_EC_DEV
|
2018-12-12 18:33:57 +01:00
|
|
|
help
|
|
|
|
|
This option exposes the Chromebook Pixel's lightbar to
|
|
|
|
|
userspace.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_lightbar.
|
|
|
|
|
|
2018-12-12 18:33:58 +01:00
|
|
|
config CROS_EC_VBC
|
|
|
|
|
tristate "ChromeOS EC vboot context support"
|
2019-09-02 11:53:04 +02:00
|
|
|
depends on MFD_CROS_EC_DEV && OF
|
|
|
|
|
default MFD_CROS_EC_DEV
|
2018-12-12 18:33:58 +01:00
|
|
|
help
|
|
|
|
|
This option exposes the ChromeOS EC vboot context nvram to
|
|
|
|
|
userspace.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_vbc.
|
|
|
|
|
|
2018-12-12 18:33:59 +01:00
|
|
|
config CROS_EC_DEBUGFS
|
|
|
|
|
tristate "Export ChromeOS EC internals in DebugFS"
|
2019-09-02 11:53:04 +02:00
|
|
|
depends on MFD_CROS_EC_DEV && DEBUG_FS
|
|
|
|
|
default MFD_CROS_EC_DEV
|
2018-12-12 18:33:59 +01:00
|
|
|
help
|
|
|
|
|
This option exposes the ChromeOS EC device internals to
|
|
|
|
|
userspace.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_debugfs.
|
|
|
|
|
|
2019-11-19 13:45:45 +01:00
|
|
|
config CROS_EC_SENSORHUB
|
|
|
|
|
tristate "ChromeOS EC MEMS Sensor Hub"
|
2019-11-27 09:49:39 +01:00
|
|
|
depends on MFD_CROS_EC_DEV
|
|
|
|
|
default MFD_CROS_EC_DEV
|
2019-11-19 13:45:45 +01:00
|
|
|
help
|
|
|
|
|
Allow loading IIO sensors. This driver is loaded by MFD and will in
|
|
|
|
|
turn query the EC and register the sensors.
|
|
|
|
|
It also spreads the sensor data coming from the EC to the IIO sensor
|
|
|
|
|
object.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_sensorhub.
|
|
|
|
|
|
2018-12-12 18:34:00 +01:00
|
|
|
config CROS_EC_SYSFS
|
|
|
|
|
tristate "ChromeOS EC control and information through sysfs"
|
2019-09-02 11:53:04 +02:00
|
|
|
depends on MFD_CROS_EC_DEV && SYSFS
|
|
|
|
|
default MFD_CROS_EC_DEV
|
2018-12-12 18:34:00 +01:00
|
|
|
help
|
|
|
|
|
This option exposes some sysfs attributes to control and get
|
|
|
|
|
information from ChromeOS EC.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_ec_sysfs.
|
|
|
|
|
|
2024-12-13 15:35:47 -08:00
|
|
|
config CROS_EC_TYPEC_ALTMODES
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Selectable symbol to enable altmodes.
|
|
|
|
|
|
2020-03-16 02:00:17 -07:00
|
|
|
config CROS_EC_TYPEC
|
|
|
|
|
tristate "ChromeOS EC Type-C Connector Control"
|
|
|
|
|
depends on MFD_CROS_EC_DEV && TYPEC
|
2020-04-14 22:29:41 -07:00
|
|
|
depends on CROS_USBPD_NOTIFY
|
2020-06-29 12:32:23 +02:00
|
|
|
depends on USB_ROLE_SWITCH
|
2020-03-16 02:00:17 -07:00
|
|
|
default MFD_CROS_EC_DEV
|
2024-12-13 15:35:47 -08:00
|
|
|
select CROS_EC_TYPEC_ALTMODES if TYPEC_DP_ALTMODE
|
2024-12-13 15:35:48 -08:00
|
|
|
select CROS_EC_TYPEC_ALTMODES if TYPEC_TBT_ALTMODE
|
2020-03-16 02:00:17 -07:00
|
|
|
help
|
|
|
|
|
If you say Y here, you get support for accessing Type C connector
|
|
|
|
|
information from the Chrome OS EC.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will be
|
2022-12-28 00:45:10 +00:00
|
|
|
called cros-ec-typec.
|
2020-03-16 02:00:17 -07:00
|
|
|
|
2022-10-18 15:06:23 +11:00
|
|
|
config CROS_HPS_I2C
|
|
|
|
|
tristate "ChromeOS HPS device"
|
|
|
|
|
depends on HID && I2C && PM
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you want to enable support for the ChromeOS
|
|
|
|
|
human presence sensor (HPS), attached via I2C. The driver supports a
|
|
|
|
|
sensor connected to the I2C bus and exposes it as a character device.
|
|
|
|
|
To save power, the sensor is automatically powered down when no
|
|
|
|
|
clients are accessing it.
|
|
|
|
|
|
2019-04-03 16:05:28 +02:00
|
|
|
config CROS_USBPD_LOGGER
|
|
|
|
|
tristate "Logging driver for USB PD charger"
|
|
|
|
|
depends on CHARGER_CROS_USBPD
|
|
|
|
|
default y
|
|
|
|
|
select RTC_LIB
|
|
|
|
|
help
|
|
|
|
|
This option enables support for logging event data for the USB PD charger
|
|
|
|
|
available in the Embedded Controller on ChromeOS systems.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_usbpd_logger.
|
|
|
|
|
|
2020-01-24 15:18:32 -08:00
|
|
|
config CROS_USBPD_NOTIFY
|
|
|
|
|
tristate "ChromeOS Type-C power delivery event notifier"
|
|
|
|
|
depends on MFD_CROS_EC_DEV
|
|
|
|
|
default MFD_CROS_EC_DEV
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you get support for Type-C PD event notifications
|
2025-07-23 10:09:30 -04:00
|
|
|
from the ChromeOS EC. On ACPI platforms this driver will bind to the
|
2020-01-24 15:18:32 -08:00
|
|
|
GOOG0003 ACPI device, and on platforms which don't have this device it
|
|
|
|
|
will get initialized on ECs which support the feature
|
|
|
|
|
EC_FEATURE_USB_PD.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called cros_usbpd_notify.
|
|
|
|
|
|
2022-01-07 11:02:07 -08:00
|
|
|
config CHROMEOS_PRIVACY_SCREEN
|
|
|
|
|
tristate "ChromeOS Privacy Screen support"
|
|
|
|
|
depends on ACPI
|
|
|
|
|
depends on DRM
|
|
|
|
|
select DRM_PRIVACY_SCREEN
|
|
|
|
|
help
|
|
|
|
|
This driver provides the support needed for the in-built electronic
|
|
|
|
|
privacy screen that is present on some ChromeOS devices. When enabled,
|
|
|
|
|
this should probably always be built into the kernel to avoid or
|
|
|
|
|
minimize drm probe deferral.
|
|
|
|
|
|
2022-08-16 21:48:30 +00:00
|
|
|
config CROS_TYPEC_SWITCH
|
|
|
|
|
tristate "ChromeOS EC Type-C Switch Control"
|
|
|
|
|
depends on MFD_CROS_EC_DEV && TYPEC && ACPI
|
|
|
|
|
default MFD_CROS_EC_DEV
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you get support for configuring the ChromeOS EC Type-C
|
|
|
|
|
muxes and retimers.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will be
|
|
|
|
|
called cros_typec_switch.
|
|
|
|
|
|
2019-02-08 17:37:17 -07:00
|
|
|
source "drivers/platform/chrome/wilco_ec/Kconfig"
|
|
|
|
|
|
2022-05-18 17:18:11 +08:00
|
|
|
# Kunit test cases
|
2023-10-03 08:05:15 +00:00
|
|
|
config CROS_KUNIT_EC_PROTO_TEST
|
|
|
|
|
tristate "Kunit tests for ChromeOS EC protocol" if !KUNIT_ALL_TESTS
|
2022-05-18 17:18:11 +08:00
|
|
|
depends on KUNIT && CROS_EC
|
|
|
|
|
default KUNIT_ALL_TESTS
|
|
|
|
|
select CROS_EC_PROTO
|
|
|
|
|
help
|
2023-10-03 08:05:15 +00:00
|
|
|
Kunit tests for ChromeOS EC protocol.
|
2022-05-18 17:18:11 +08:00
|
|
|
|
2013-11-07 14:25:45 -08:00
|
|
|
endif # CHROMEOS_PLATFORMS
|