platform/chrome: Move cros-ec transport drivers to drivers/platform.
There are some cros-ec transport drivers (I2C, SPI) living in MFD, while others (LPC) living in drivers/platform. The transport drivers are more platform specific. So, move the I2C and SPI transport drivers to the platform/chrome directory. The patch also removes the MFD_ prefix of their Kconfig symbols. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Benson Leung <bleung@chromium.org>
This commit is contained in:
parent
021c91791a
commit
d00a8741fd
6 changed files with 22 additions and 22 deletions
|
@ -202,26 +202,6 @@ config MFD_CROS_EC
|
|||
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.
|
||||
|
||||
config MFD_CROS_EC_I2C
|
||||
tristate "ChromeOS Embedded Controller (I2C)"
|
||||
depends on MFD_CROS_EC && I2C
|
||||
|
||||
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.
|
||||
|
||||
config MFD_CROS_EC_SPI
|
||||
tristate "ChromeOS Embedded Controller (SPI)"
|
||||
depends on MFD_CROS_EC && SPI
|
||||
|
||||
---help---
|
||||
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.
|
||||
|
||||
config MFD_CROS_EC_CHARDEV
|
||||
tristate "Chrome OS Embedded Controller userspace device interface"
|
||||
depends on MFD_CROS_EC
|
||||
|
|
|
@ -14,8 +14,6 @@ obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
|
|||
obj-$(CONFIG_MFD_BD9571MWV) += bd9571mwv.o
|
||||
cros_ec_core-objs := cros_ec.o
|
||||
obj-$(CONFIG_MFD_CROS_EC) += cros_ec_core.o
|
||||
obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
|
||||
obj-$(CONFIG_MFD_CROS_EC_SPI) += cros_ec_spi.o
|
||||
obj-$(CONFIG_MFD_CROS_EC_CHARDEV) += cros_ec_dev.o
|
||||
obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
|
||||
|
||||
|
|
|
@ -52,6 +52,26 @@ config CHROMEOS_TBMC
|
|||
config CROS_EC_CTL
|
||||
tristate
|
||||
|
||||
config CROS_EC_I2C
|
||||
tristate "ChromeOS Embedded Controller (I2C)"
|
||||
depends on MFD_CROS_EC && I2C
|
||||
|
||||
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.
|
||||
|
||||
config CROS_EC_SPI
|
||||
tristate "ChromeOS Embedded Controller (SPI)"
|
||||
depends on MFD_CROS_EC && SPI
|
||||
|
||||
---help---
|
||||
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.
|
||||
|
||||
config CROS_EC_LPC
|
||||
tristate "ChromeOS Embedded Controller (LPC)"
|
||||
depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST)
|
||||
|
|
|
@ -6,6 +6,8 @@ obj-$(CONFIG_CHROMEOS_TBMC) += chromeos_tbmc.o
|
|||
cros_ec_ctl-objs := cros_ec_sysfs.o cros_ec_lightbar.o \
|
||||
cros_ec_vbc.o cros_ec_debugfs.o
|
||||
obj-$(CONFIG_CROS_EC_CTL) += cros_ec_ctl.o
|
||||
obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
|
||||
obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
|
||||
cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o
|
||||
cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
|
||||
obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpcs.o
|
||||
|
|
Loading…
Reference in a new issue