![Linus Walleij](/assets/img/avatar_default.png)
We get the following build error from UM Linux after adding an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX": ERROR: "devm_ioremap_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! ERROR: "of_address_to_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! It appears that the I2C mux core code depends on HAS_IOMEM for historical reasons, while CONFIG_I2C_MUX_REG does *not* have a direct dependency on HAS_IOMEM. This creates a situation where a allyesconfig or allmodconfig for UM Linux will select I2C_MUX, and will implicitly enable I2C_MUX_REG as well, and the compilation will fail for the register driver. Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and removing the dependency from I2C_MUX. Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
86 lines
2.6 KiB
Plaintext
86 lines
2.6 KiB
Plaintext
#
|
|
# Multiplexer I2C chip drivers configuration
|
|
#
|
|
|
|
menu "Multiplexer I2C Chip support"
|
|
depends on I2C_MUX
|
|
|
|
config I2C_ARB_GPIO_CHALLENGE
|
|
tristate "GPIO-based I2C arbitration"
|
|
depends on GPIOLIB || COMPILE_TEST
|
|
depends on OF
|
|
help
|
|
If you say yes to this option, support will be included for an
|
|
I2C multimaster arbitration scheme using GPIOs and a challenge &
|
|
response mechanism where masters have to claim the bus by asserting
|
|
a GPIO.
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
will be called i2c-arb-gpio-challenge.
|
|
|
|
config I2C_MUX_GPIO
|
|
tristate "GPIO-based I2C multiplexer"
|
|
depends on GPIOLIB
|
|
help
|
|
If you say yes to this option, support will be included for a
|
|
GPIO based I2C multiplexer. This driver provides access to
|
|
I2C busses connected through a MUX, which is controlled
|
|
through GPIO pins.
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
will be called i2c-mux-gpio.
|
|
|
|
config I2C_MUX_PCA9541
|
|
tristate "NXP PCA9541 I2C Master Selector"
|
|
help
|
|
If you say yes here you get support for the NXP PCA9541
|
|
I2C Master Selector.
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
will be called i2c-mux-pca9541.
|
|
|
|
config I2C_MUX_PCA954x
|
|
tristate "Philips PCA954x I2C Mux/switches"
|
|
depends on GPIOLIB || COMPILE_TEST
|
|
help
|
|
If you say yes here you get support for the Philips PCA954x
|
|
I2C mux/switch devices.
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
will be called i2c-mux-pca954x.
|
|
|
|
config I2C_MUX_PINCTRL
|
|
tristate "pinctrl-based I2C multiplexer"
|
|
depends on PINCTRL
|
|
help
|
|
If you say yes to this option, support will be included for an I2C
|
|
multiplexer that uses the pinctrl subsystem, i.e. pin multiplexing.
|
|
This is useful for SoCs whose I2C module's signals can be routed to
|
|
different sets of pins at run-time.
|
|
|
|
This driver can also be built as a module. If so, the module will be
|
|
called pinctrl-i2cmux.
|
|
|
|
config I2C_MUX_REG
|
|
tristate "Register-based I2C multiplexer"
|
|
depends on HAS_IOMEM
|
|
help
|
|
If you say yes to this option, support will be included for a
|
|
register based I2C multiplexer. This driver provides access to
|
|
I2C busses connected through a MUX, which is controlled
|
|
by a single register.
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
will be called i2c-mux-reg.
|
|
|
|
config I2C_DEMUX_PINCTRL
|
|
tristate "pinctrl-based I2C demultiplexer"
|
|
depends on PINCTRL && OF
|
|
select OF_DYNAMIC
|
|
help
|
|
If you say yes to this option, support will be included for an I2C
|
|
demultiplexer that uses the pinctrl subsystem. This is useful if you
|
|
want to change the I2C master at run-time depending on features.
|
|
|
|
endmenu
|