| Message ID | 20191127201738.1234-1-linus.walleij@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] iio: imu: inv_mpu6050: Select I2C_MUX again | expand |
Hello, very good idea, I was thinking about it recently. Thanks, JB Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> From: linux-iio-owner@vger.kernel.org <linux-iio-owner@vger.kernel.org> on behalf of Linus Walleij <linus.walleij@linaro.org> Sent: Wednesday, November 27, 2019 21:17 To: Jonathan Cameron <jic23@kernel.org>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de>; Lars-Peter Clausen <lars@metafoo.de>; Peter Meerwald-Stadler <pmeerw@pmeerw.net>; Linus Walleij <linus.walleij@linaro.org>; Richard Weinberger <richard@nod.at>; Stephan Gerhold <stephan@gerhold.net> Subject: [PATCH v2] iio: imu: inv_mpu6050: Select I2C_MUX again CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe. commit f7072198f217 ("iio: imu: Fix inv_mpu6050 dependencies") undid the explicit selection of I2C_MUX previously done by the driver, because I2C_MUX implicitly depended on HAS_IOMEM. However commit 93d710a65ef0 ("i2c: mux: fix up dependencies") cleared up the situation properly and drivers that need to select I2C_MUX can now do so again. It makes a lot of sense for a driver to select the driver infrastructure it needs so restore the natural order of things. Cc: Richard Weinberger <richard@nod.at> Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- ChangeLog v1->v2: - Depend on I2C instead of I2C_MUX, it's necessary to at least have the I2C infrastructure... --- drivers/iio/imu/inv_mpu6050/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iio/imu/inv_mpu6050/Kconfig b/drivers/iio/imu/inv_mpu6050/Kconfig index e4c4c12236a7..d9dba6b8abf6 100644 --- a/drivers/iio/imu/inv_mpu6050/Kconfig +++ b/drivers/iio/imu/inv_mpu6050/Kconfig @@ -10,7 +10,8 @@ config INV_MPU6050_IIO config INV_MPU6050_I2C tristate "Invensense MPU6050 devices (I2C)" - depends on I2C_MUX + depends on I2C + select I2C_MUX select INV_MPU6050_IIO select REGMAP_I2C help
On Thu, 28 Nov 2019 08:46:28 +0000 Jean-Baptiste Maneyrol <JManeyrol@invensense.com> wrote: > Hello, > > very good idea, I was thinking about it recently. > > Thanks, > JB > > Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Applied to the togreg branch of iio.git and pushed out as testing to let the autobuilders have a good poke at it. Thanks, Jonathan > > > From: linux-iio-owner@vger.kernel.org <linux-iio-owner@vger.kernel.org> on behalf of Linus Walleij <linus.walleij@linaro.org> > > Sent: Wednesday, November 27, 2019 21:17 > > To: Jonathan Cameron <jic23@kernel.org>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org> > > Cc: Hartmut Knaack <knaack.h@gmx.de>; Lars-Peter Clausen <lars@metafoo.de>; Peter Meerwald-Stadler <pmeerw@pmeerw.net>; Linus Walleij <linus.walleij@linaro.org>; Richard Weinberger <richard@nod.at>; Stephan Gerhold <stephan@gerhold.net> > > Subject: [PATCH v2] iio: imu: inv_mpu6050: Select I2C_MUX again > > > > > CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > commit f7072198f217 ("iio: imu: Fix inv_mpu6050 dependencies") > > undid the explicit selection of I2C_MUX previously > > done by the driver, because I2C_MUX implicitly depended > > on HAS_IOMEM. > > > > However commit 93d710a65ef0 ("i2c: mux: fix up dependencies") > > cleared up the situation properly and drivers that need > > to select I2C_MUX can now do so again. > > > > It makes a lot of sense for a driver to select the driver > > infrastructure it needs so restore the natural order of > > things. > > > > Cc: Richard Weinberger <richard@nod.at> > > Cc: Stephan Gerhold <stephan@gerhold.net> > > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > > --- > > ChangeLog v1->v2: > > - Depend on I2C instead of I2C_MUX, it's necessary to > > at least have the I2C infrastructure... > > --- > > drivers/iio/imu/inv_mpu6050/Kconfig | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iio/imu/inv_mpu6050/Kconfig b/drivers/iio/imu/inv_mpu6050/Kconfig > > index e4c4c12236a7..d9dba6b8abf6 100644 > > --- a/drivers/iio/imu/inv_mpu6050/Kconfig > > +++ b/drivers/iio/imu/inv_mpu6050/Kconfig > > @@ -10,7 +10,8 @@ config INV_MPU6050_IIO > > > > config INV_MPU6050_I2C > > tristate "Invensense MPU6050 devices (I2C)" > > - depends on I2C_MUX > > + depends on I2C > > + select I2C_MUX > > select INV_MPU6050_IIO > > select REGMAP_I2C > > help >
diff --git a/drivers/iio/imu/inv_mpu6050/Kconfig b/drivers/iio/imu/inv_mpu6050/Kconfig index e4c4c12236a7..d9dba6b8abf6 100644 --- a/drivers/iio/imu/inv_mpu6050/Kconfig +++ b/drivers/iio/imu/inv_mpu6050/Kconfig @@ -10,7 +10,8 @@ config INV_MPU6050_IIO config INV_MPU6050_I2C tristate "Invensense MPU6050 devices (I2C)" - depends on I2C_MUX + depends on I2C + select I2C_MUX select INV_MPU6050_IIO select REGMAP_I2C help
commit f7072198f217 ("iio: imu: Fix inv_mpu6050 dependencies") undid the explicit selection of I2C_MUX previously done by the driver, because I2C_MUX implicitly depended on HAS_IOMEM. However commit 93d710a65ef0 ("i2c: mux: fix up dependencies") cleared up the situation properly and drivers that need to select I2C_MUX can now do so again. It makes a lot of sense for a driver to select the driver infrastructure it needs so restore the natural order of things. Cc: Richard Weinberger <richard@nod.at> Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- ChangeLog v1->v2: - Depend on I2C instead of I2C_MUX, it's necessary to at least have the I2C infrastructure... --- drivers/iio/imu/inv_mpu6050/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)