Add support for MAX31875

[jemfgeronimo]

PR Description

• This adds driver support and device tree bindings for MAX31875 Temperature Sensor.
• Datasheet: MAX31875
• Tested on RPI4 with MAX31875EVKIT

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have tested the changes on the relevant hardware
• I have updated the documentation outside this repo accordingly (if there is the case)

[nunojsa]

First round of review from me...

[nunojsa]

Maybe adi,interrupt-enable? But this also brings the question? Don't we need interrupts to be set if IRQ mode is enabled? If so, you could use that standard property to know if IRQs are used or not...

[jemfgeronimo]

I based this on an existing dt property: adi,comp-int

What this controls is the behavior of a STATUS BIT of the device: whether it will be de-asserted via an I2C read or when going below the hysteresis value. This is documented here.

Maybe, I can just modify the description to better reflect this behavior.

[nunojsa]

Hmm, I see... interrupt mode is misleading :)

[jemfgeronimo]

I will change the description into

  If present, the Overtemperature Status bit operates in interrupt mode. If
  not present, it operates in comparator mode (default).

[jemfgeronimo]

V2

• added adi,extended-format
• modified adi,comp-int description
• changed adi,timeout-enable to adi,timeout-disable
• changed adi,fault-q from u8 to u32
• renamed resolution of max31875_data to bit_reso
• added bool extend_fmt to max31875_data
• renamed shutdown_write to max31875_shutdown_write
• removed ugly cast from a function call of max31875_update_bits
• fixed indentions/alignments
• refactored max31875_convert_raw_to_temp() and max31875_convert_temp_to_raw()
• used switch cases to handle the type and attr in max31875_is_visible(), max31875_read() and max31875_write()
• removed i2c_set_clientdata() call

[nunojsa]

Some more inputs from me

[nunojsa]

It depends, if the mismatches in the register addresses are not that much and the differences overall you can always have a chip_info dedicated struct with the differences. Then no need for conditionals. As a reference look at this:

https://elixir.bootlin.com/linux/v6.11.3/source/drivers/iio/imu/adis16475.c#L900

And see how many devices we support in there. Anyways, up to you... but keep in mind the very same question might pop up upstream... Another thing to have in mind are the DT bindings. Even if you end up with a different driver, you should see if the bindings for the other device could be used for this one (adding the new compatible to the old file and taking care of all differences)

[nunojsa]

do we need the cast to long? I think what you need to reason is that if the multiplication can actually lead to 64bits? If so, you need a cast to s64...