[PATCH 0/4] hwmon: Update handling of chip-id enums

[Guenter Roeck <linux@roeck-us.net>]

With the transition to use device_get_match_data() or i2c_get_match_data()
instead of i2c_match_id() and of_match_device(), the assumption was made
that the data pointer in struct i2c_device_id and struct of_device_id must
not be NULL (0). Initial patches changed enums used in those data pointers
to start with 1.

However, it turns out that this is only necessary if device_get_match_data()
is used. i2c_get_match_data() calls device_get_match_data() and uses
i2c_match_id() as fallback if device_get_match_data() returns NULL.
Therefore, it is perfectly valid to keep using 0 as starting enum value
as long as struct i2c_device_id is complete and matches the data in struct
of_device_id.

It is confusing to have some drivers start enums with 0 and others starting
them with 1, even more so if that is done inconsistently and/or if enums
starting with 1 are used to index arrays. Let enums start with index 0
where possible, and otherwise explain why the index has to start with 1.

----------------------------------------------------------------
Guenter Roeck (4):
      hwmon: (pmbus/lm25066) Let enum chips start with index 0
      hwmon: (nct6775) Let enum kinds start with index 0
      hwmon: (pmbus/mp2856) Let enum chips start with index 0
      hwmon: (pmbus/max31827) Explain why enum chips must not start with 0

 drivers/hwmon/max31827.c      | 5 +++++
 drivers/hwmon/nct6775.h       | 2 +-
 drivers/hwmon/pmbus/lm25066.c | 2 +-
 drivers/hwmon/pmbus/mp2856.c  | 8 ++++----
 4 files changed, 11 insertions(+), 6 deletions(-)