samples/sensor/*: Build issue when board expose sensors defined on both I2C and SPI buses #48518
Comments
erwango
added
area: Sensors
|
@erwango I had worked up something similar to what you suggested in a PR: However @MaureenHelm asked to just update the board Kconfig.defconfig to enable the bus needed. So will look for her comment on this to see what direction we should go. |
If this is something like follows, this would make sense indeed: Edit: There would be a consequence on Then, no reason to go to the next step which would be to get some DT magic to do this automatically |
I really don't like this pattern.
I tried this before, but it created a circular dependency (LSM6DSL depends on SPI, and SPI depends on LSM6DSL). That's why I wound up using SENSOR instead of LSM6DSL.
Agreed |
|
@erwango will you work up a PR for this? |
I'm not convinced by this solution. This enables bus irrespective of sensor devicetree status on the bus.
So I kind of prefer solution proposed here |
|
Dev meeting: Review the bus selection: select bus in drivers and remove board related code. |
pushed a PR, will see how it goes through CI. |
This change in pattern is meant to address a misconfiguration issue that can occur for sensors that support being on multiple busses like I2C & SPI. For example, you can have a configuration in which such a sensor is on the I2C bus in the devicetree and the sensor is enabled. However the application configuration enables CONFIG_SPI=y and CONFIG_I2C=n and this will cause the sensor driver to be built by default, however since we don't have the I2C bus enabled the driver will not compile correctly. Previously we had been adding to board Kconfig.defconfig something like: config I2C default y if SENSOR This pattern doesn't scale well and may differ from what an application specific need/use is. So instead move to a pattern in which we leave the default enablement up to the devicetree "status" property for the sensor. We then have the Kconfig move from 'depends on <BUS>' to 'select <BUS>' and in the case of drivers that support multiple busses we have the Kconfig be: 'select <BUS> if $(dt_compat_on_bus,$(<DT_COMPAT>),<BUS>) for each bus type the sensor supports. This removes the need to add Kconfig logic to each board and enables the bus subsystem and bus controller driver if the sensor requires it by default in the build system. Fixes: zephyrproject-rtos#48518 Signed-off-by: Kumar Gala <galak@kernel.org>
This change in pattern is meant to address a misconfiguration issue that can occur for sensors that support being on multiple busses like I2C & SPI. For example, you can have a configuration in which such a sensor is on the I2C bus in the devicetree and the sensor is enabled. However the application configuration enables CONFIG_SPI=y and CONFIG_I2C=n and this will cause the sensor driver to be built by default, however since we don't have the I2C bus enabled the driver will not compile correctly. Previously we had been adding to board Kconfig.defconfig something like: config I2C default y if SENSOR This pattern doesn't scale well and may differ from what an application specific need/use is. So instead move to a pattern in which we leave the default enablement up to the devicetree "status" property for the sensor. We then have the Kconfig move from 'depends on <BUS>' to 'select <BUS>' and in the case of drivers that support multiple busses we have the Kconfig be: 'select <BUS> if $(dt_compat_on_bus,$(<DT_COMPAT>),<BUS>) for each bus type the sensor supports. This removes the need to add Kconfig logic to each board and enables the bus subsystem and bus controller driver if the sensor requires it by default in the build system. Fixes: #48518 Signed-off-by: Kumar Gala <galak@kernel.org>
…select' This change in pattern is meant to address a misconfiguration issue that can occur for sensors that support being on multiple busses like I2C & SPI. For example, you can have a configuration in which such a sensor is on the I2C bus in the devicetree and the sensor is enabled. However the application configuration enables CONFIG_SPI=y and CONFIG_I2C=n and this will cause the sensor driver to be built by default, however since we don't have the I2C bus enabled the driver will not compile correctly. Previously we had been adding to board Kconfig.defconfig something like: config I2C default y if SENSOR This pattern doesn't scale well and may differ from what an application specific need/use is. So instead move to a pattern in which we leave the default enablement up to the devicetree "status" property for the sensor. We then have the Kconfig move from 'depends on <BUS>' to 'select <BUS>' and in the case of drivers that support multiple busses we have the Kconfig be: 'select <BUS> if $(dt_compat_on_bus,$(<DT_COMPAT>),<BUS>) for each bus type the sensor supports. This removes the need to add Kconfig logic to each board and enables the bus subsystem and bus controller driver if the sensor requires it by default in the build system. Fixes: zephyrproject-rtos#48518 Signed-off-by: Kumar Gala <galak@kernel.org> (cherry picked from commit df81fef)
…select' This change in pattern is meant to address a misconfiguration issue that can occur for sensors that support being on multiple busses like I2C & SPI. For example, you can have a configuration in which such a sensor is on the I2C bus in the devicetree and the sensor is enabled. However the application configuration enables CONFIG_SPI=y and CONFIG_I2C=n and this will cause the sensor driver to be built by default, however since we don't have the I2C bus enabled the driver will not compile correctly. Previously we had been adding to board Kconfig.defconfig something like: config I2C default y if SENSOR This pattern doesn't scale well and may differ from what an application specific need/use is. So instead move to a pattern in which we leave the default enablement up to the devicetree "status" property for the sensor. We then have the Kconfig move from 'depends on <BUS>' to 'select <BUS>' and in the case of drivers that support multiple busses we have the Kconfig be: 'select <BUS> if $(dt_compat_on_bus,$(<DT_COMPAT>),<BUS>) for each bus type the sensor supports. This removes the need to add Kconfig logic to each board and enables the bus subsystem and bus controller driver if the sensor requires it by default in the build system. Fixes: zephyrproject-rtos#48518 Signed-off-by: Kumar Gala <galak@kernel.org> (cherry picked from commit 550a80a)
Describe the bug
There are a few sensor samples which fail to build with
96b_argonkey:samples/sensor/vl53l0x/samples/sensor/hts221samples/sensor/lps22hbRoot cause is:
lsm6dslon SPI bus, while other sensors (hts221,vl53l0x,lps22hb) are defined on I2C busCONFIG_SENSORandCONFIG_I2CCONFIG_SENSOR=ydrivers/sensor/lsm6dsl.cis compiled, but compilation fails due toCONFIG_SPInot being enabled.This is likely an effect of:
Ideally
LSM6DSLactivation should be a little bit more selective and check bus activation:The text was updated successfully, but these errors were encountered: