On 7/14/24 00:06, Tzung-Bi Shih wrote:
On Sat, Jul 13, 2024 at 11:53:00AM -0700, Guenter Roeck wrote:
On 7/13/24 08:22, Tzung-Bi Shih wrote:
On Fri, Jul 12, 2024 at 10:35:48AM -0700, Guenter Roeck wrote:
diff --git a/drivers/hwmon/adm1021.c b/drivers/hwmon/adm1021.c
[...]
-static const struct i2c_device_id adm1021_id[] = {
- { "adm1021", adm1021 },
- { "adm1023", adm1023 },
- { "max1617", max1617 },
- { "max1617a", max1617a },
The device ID "max1617a" only in Documentation/hwmon/lm90.rst but not in
drivers/hwmon/lm90.c which results in max1617a is no longer supported after
applying the patch.
Thanks for noticing. It is an oversight, really. The chip is the same.
max1617a is even mentioned in the lm90 documentation.
The chip is detected and supported as "max1617" in the lm90 driver.
Here are the notes from that driver.
* Note: Multiple chips with different markings labeled as
* "MAX1617" (no "A") were observed to report manufacturer ID
* 0x4d and device ID 0x01. It is unknown if other variants of
* MAX1617/MAX617A with different behavior exist. The detection
* code below works for those chips.
Ack.
Reviewed-by: Tzung-Bi Shih <tzungbi@xxxxxxxxxx>
Either case, all configurations enabling the adm1021 driver also enable the
lm90 driver, and that in turn prevents the adm1021 driver from being built.
Effectively that means that the adm1021 driver hasn't been built for a long
time.
Curious about how this happens: is there a way for telling build system that
we prefer lm90 to adm1021?
This was
config SENSORS_ADM1021
tristate "Analog Devices ADM1021 and compatibles"
depends on I2C
depends on SENSORS_LM90=n
^^^^^^^^^^^^^^^^^^^^^^^^^
Thanks,
Guenter
