On 1/27/24 08:12, Heiner Kallweit wrote:
On 27.01.2024 17:01, Guenter Roeck wrote:
On 1/27/24 07:02, Heiner Kallweit wrote:
Class-based I2C probing requires detect() and address_list to be
set in the I2C client driver, see checks in i2c_detect().
It's misleading to declare I2C_CLASS_HWMON support if this
precondition isn't met.
Signed-off-by: Heiner Kallweit <hkallweit1@xxxxxxxxx>
---
drivers/hwmon/adm1177.c | 1 -
drivers/hwmon/ds1621.c | 1 -
drivers/hwmon/ds620.c | 1 -
drivers/hwmon/ina209.c | 1 -
drivers/hwmon/ina238.c | 1 -
drivers/hwmon/max127.c | 1 -
drivers/hwmon/max31760.c | 1 -
drivers/hwmon/max31790.c | 1 -
drivers/hwmon/max31827.c | 1 -
drivers/hwmon/max6621.c | 1 -
drivers/hwmon/max6697.c | 1 -
drivers/hwmon/occ/p8_i2c.c | 1 -
drivers/hwmon/pmbus/ir36021.c | 1 -
drivers/hwmon/powr1220.c | 1 -
drivers/hwmon/sbrmi.c | 1 -
drivers/hwmon/sbtsi_temp.c | 1 -
drivers/hwmon/w83773g.c | 1 -
Follow-up question: You did not drop the class from drivers/hwmon/adt7410.c
and drivers/hwmon/emc2305.c. Is that because of the address_list in those
drivers ?
Yes. If address_list is set, this shows a certain intention to support
I2C class-based probing. Then the question is whether adding the missing
detect() implementation may be the more appropriate action.
My understanding is that class based auto-detection is in the process of
being phased out. With that in mind, it would not make much sense to add
it to existing drivers. Anyone trying to add it now would have to explain
why it is suddenly needed but wasn't needed before. I think that train
has left the station.
On top of that, at least for adt7410/adt7420, I don't see a reliable means
to auto-detect those chips. Trying to do so for a 10+ year old driver would
only add (lots of) risk for little if any gain.
Those two drivers actually claim in their documentation that the address
ranges would be scanned. That should be dropped as well since it does not match
reality.
Thanks,
Guenter
