Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sensor: bme280: opt-in bmp280 support #78213

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

JordanYates
Copy link
Collaborator

Remove the runtime BMP280 support, instead require the support to
be specified as a compatible in the devicetree. This assumes that
a single board does not have both a BME280 and a BMP280, which is
hopefully valid as the BME280 is a strict superset of the BMP280.

Support for the BMP280 sampling device ID has been dropped, which is hopefully not controversial given the sensor itself went obsolete in 2018.

Remove the runtime BMP280 support, instead require the support to
be specified as a compatible in the devicetree. This assumes that
a single board does not have both a BME280 and a BMP280, which is
hopefully valid as the BME280 is a strict superset of the BMP280.

Signed-off-by: Jordan Yates <[email protected]>
Don't mark the sensor as bad if the very first I2C transaction after
boot does not give the value we expect. Retry the ID read up to 5 times
before giving up.

Signed-off-by: Jordan Yates <[email protected]>
The BME280 driver now requires an additional compatible to signify that
the driver is actually being used with a BMP280.

Signed-off-by: Jordan Yates <[email protected]>
@teburd
Copy link
Collaborator

teburd commented Sep 11, 2024

I don't think the reasoning for the removal of runtime bmp/bme 280 selection is clear enough here. Why do you want to change this?

@JordanYates
Copy link
Collaborator Author

I don't think the reasoning for the removal of runtime bmp/bme 280 selection is clear enough here. Why do you want to change this?

The trigger for this was the driver falling over because the first I2C transaction after boot happened to not read the ID correctly.
Retrying this a few times necessitates knowing which ID is expected.
Pulling this information from the DT compatible doesn't seem controversial.
If you know which device you expect at compile-time, there doesn't seem to be any advantage of supporting both variants at runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Sensors Sensors Release Notes To be mentioned in the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants