[PATCH 00/31] Remove use of i2c_match_id in HWMON

[PATCH 00/31] Remove use of i2c_match_id in HWMON

[Andrew Davis]

Hello all,

Goal here is to remove the i2c_match_id() function from all drivers.
Using i2c_get_match_data() can simplify code and has some other
benefits described in the patches.

There are not many users left in kernel, most remaining users
are here in HWMON, so let's clear those out here.

I don't have most of this hardware, so testing is very welcome :)

Thanks,
Andrew

Andrew Davis (31):
  hwmon: (ad7418) Remove use of i2c_match_id()
  hwmon: (adm1021) Remove use of i2c_match_id()
  hwmon: (adm1031) Remove use of i2c_match_id()
  hwmon: (ads7828) Remove use of i2c_match_id()
  hwmon: (adt7475) Remove use of i2c_match_id()
  hwmon: (aht10) Remove use of i2c_match_id()
  hwmon: (dme1737) Remove use of i2c_match_id()
  hwmon: (ds1621) Remove use of i2c_match_id()
  hwmon: (f75375s) Remove use of i2c_match_id()
  hwmon: (fschmd) Remove use of i2c_match_id()
  hwmon: (ina2xx) Remove use of i2c_match_id()
  hwmon: (lm63) Remove use of i2c_match_id()
  hwmon: (lm75) Remove use of i2c_match_id()
  hwmon: (lm78) Remove use of i2c_match_id()
  hwmon: (lm83) Remove use of i2c_match_id()
  hwmon: (lm85) Remove use of i2c_match_id()
  hwmon: (lm90) Remove use of i2c_match_id()
  hwmon: (lm95234) Remove use of i2c_match_id()
  hwmon: (max16065) Remove use of i2c_match_id()
  hwmon: (max1668) Remove use of i2c_match_id()
  hwmon: (max6697) Remove use of i2c_match_id()
  hwmon: (mcp3021) Remove use of i2c_match_id()
  hwmon: (powr1220) Remove use of i2c_match_id()
  hwmon: (sht3x) Remove use of i2c_match_id()
  hwmon: (shtc1) Remove use of i2c_match_id()
  hwmon: (thmc50) Remove use of i2c_match_id()
  hwmon: (tmp401) Remove use of i2c_match_id()
  hwmon: (tmp421) Remove use of i2c_match_id()
  hwmon: (tmp464) Remove use of i2c_match_id()
  hwmon: (w83781d) Remove use of i2c_match_id()
  hwmon: (w83795): Remove use of i2c_match_id()

 drivers/hwmon/ad7418.c   |  7 +-----
 drivers/hwmon/adm1021.c  |  4 +---
 drivers/hwmon/adm1031.c  |  4 +---
 drivers/hwmon/ads7828.c  |  7 +-----
 drivers/hwmon/adt7475.c  | 16 ++++++--------
 drivers/hwmon/aht10.c    |  3 +--
 drivers/hwmon/dme1737.c  |  4 +---
 drivers/hwmon/ds1621.c   |  4 +---
 drivers/hwmon/f75375s.c  | 46 +++++++++++++++++-----------------------
 drivers/hwmon/fschmd.c   |  2 +-
 drivers/hwmon/ina2xx.c   |  7 +-----
 drivers/hwmon/lm63.c     |  5 +----
 drivers/hwmon/lm75.c     | 10 +--------
 drivers/hwmon/lm78.c     |  4 +---
 drivers/hwmon/lm83.c     | 16 +++++++-------
 drivers/hwmon/lm85.c     |  7 +-----
 drivers/hwmon/lm90.c     |  5 +----
 drivers/hwmon/lm95234.c  |  5 ++---
 drivers/hwmon/max16065.c | 10 ++++-----
 drivers/hwmon/max1668.c  |  4 +---
 drivers/hwmon/max6697.c  |  7 +-----
 drivers/hwmon/mcp3021.c  |  6 +++---
 drivers/hwmon/powr1220.c |  6 +++---
 drivers/hwmon/sht3x.c    | 20 ++++++++---------
 drivers/hwmon/shtc1.c    |  4 +---
 drivers/hwmon/thmc50.c   |  4 +---
 drivers/hwmon/tmp401.c   |  2 +-
 drivers/hwmon/tmp421.c   |  6 +-----
 drivers/hwmon/tmp464.c   |  5 +----
 drivers/hwmon/w83781d.c  |  4 +---
 drivers/hwmon/w83795.c   |  4 +---
 31 files changed, 79 insertions(+), 159 deletions(-)

-- 
2.39.2

[PATCH 01/31] hwmon: (ad7418) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/ad7418.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/hwmon/ad7418.c b/drivers/hwmon/ad7418.c
index 4829f83ff52e3..7a132accdf8a3 100644
--- a/drivers/hwmon/ad7418.c
+++ b/drivers/hwmon/ad7418.c
@@ -230,8 +230,6 @@ static void ad7418_init_client(struct i2c_client *client)
 	}
 }
 
-static const struct i2c_device_id ad7418_id[];
-
 static int ad7418_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -252,10 +250,7 @@ static int ad7418_probe(struct i2c_client *client)
 
 	mutex_init(&data->lock);
 	data->client = client;
-	if (dev->of_node)
-		data->type = (uintptr_t)of_device_get_match_data(dev);
-	else
-		data->type = i2c_match_id(ad7418_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 
 	switch (data->type) {
 	case ad7416:
-- 
2.39.2

[PATCH 02/31] hwmon: (adm1021) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/adm1021.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/adm1021.c b/drivers/hwmon/adm1021.c
index 7c15398ebb378..87b42e0cfd2ef 100644
--- a/drivers/hwmon/adm1021.c
+++ b/drivers/hwmon/adm1021.c
@@ -440,8 +440,6 @@ static void adm1021_init_client(struct i2c_client *client)
 	i2c_smbus_write_byte_data(client, ADM1021_REG_CONV_RATE_W, 0x04);
 }
 
-static const struct i2c_device_id adm1021_id[];
-
 static int adm1021_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -453,7 +451,7 @@ static int adm1021_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	data->client = client;
-	data->type = i2c_match_id(adm1021_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 	mutex_init(&data->update_lock);
 
 	/* Initialize the ADM1021 chip */
-- 
2.39.2

[PATCH 03/31] hwmon: (adm1031) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/adm1031.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/adm1031.c b/drivers/hwmon/adm1031.c
index 88c7e0d62d089..343118532cdb4 100644
--- a/drivers/hwmon/adm1031.c
+++ b/drivers/hwmon/adm1031.c
@@ -1021,8 +1021,6 @@ static void adm1031_init_client(struct i2c_client *client)
 	data->update_interval = update_intervals[i];
 }
 
-static const struct i2c_device_id adm1031_id[];
-
 static int adm1031_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -1035,7 +1033,7 @@ static int adm1031_probe(struct i2c_client *client)
 
 	i2c_set_clientdata(client, data);
 	data->client = client;
-	data->chip_type = i2c_match_id(adm1031_id, client)->driver_data;
+	data->chip_type = (uintptr_t)i2c_get_match_data(client);
 	mutex_init(&data->update_lock);
 
 	if (data->chip_type == adm1030)
-- 
2.39.2

[PATCH 04/31] hwmon: (ads7828) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/ads7828.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/hwmon/ads7828.c b/drivers/hwmon/ads7828.c
index 809e830f52a6b..436637264056c 100644
--- a/drivers/hwmon/ads7828.c
+++ b/drivers/hwmon/ads7828.c
@@ -99,8 +99,6 @@ static const struct regmap_config ads2830_regmap_config = {
 	.val_bits = 8,
 };
 
-static const struct i2c_device_id ads7828_device_ids[];
-
 static int ads7828_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -138,10 +136,7 @@ static int ads7828_probe(struct i2c_client *client)
 		}
 	}
 
-	if (client->dev.of_node)
-		chip = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		chip = i2c_match_id(ads7828_device_ids, client)->driver_data;
+	chip = (uintptr_t)i2c_get_match_data(client);
 
 	/* Bound Vref with min/max values */
 	vref_mv = clamp_val(vref_mv, ADS7828_EXT_VREF_MV_MIN,
-- 
2.39.2

[PATCH 05/31] hwmon: (adt7475) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/adt7475.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 4224ffb304832..5f78e66330187 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -1676,7 +1676,6 @@ static int adt7475_probe(struct i2c_client *client)
 	struct device *hwmon_dev;
 	int i, ret = 0, revision, group_num = 0;
 	u8 config3;
-	const struct i2c_device_id *id = i2c_match_id(adt7475_id, client);
 
 	data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
 	if (data == NULL)
@@ -1686,10 +1685,7 @@ static int adt7475_probe(struct i2c_client *client)
 	data->client = client;
 	i2c_set_clientdata(client, data);
 
-	if (client->dev.of_node)
-		chip = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		chip = id->driver_data;
+	chip = (uintptr_t)i2c_get_match_data(client);
 
 	/* Initialize device-specific values */
 	switch (chip) {
@@ -1717,7 +1713,7 @@ static int adt7475_probe(struct i2c_client *client)
 	if (!(config3 & CONFIG3_SMBALERT))
 		data->has_pwm2 = 1;
 	/* Meaning of this bit is inverted for the ADT7473-1 */
-	if (id->driver_data == adt7473 && revision >= 1)
+	if (chip == adt7473 && revision >= 1)
 		data->has_pwm2 = !data->has_pwm2;
 
 	data->config4 = adt7475_read(REG_CONFIG4);
@@ -1730,12 +1726,12 @@ static int adt7475_probe(struct i2c_client *client)
 	 * because 2 different pins (TACH4 and +2.5 Vin) can be used for
 	 * this function
 	 */
-	if (id->driver_data == adt7490) {
+	if (chip == adt7490) {
 		if ((data->config4 & CONFIG4_PINFUNC) == 0x1 &&
 		    !(config3 & CONFIG3_THERM))
 			data->has_fan4 = 1;
 	}
-	if (id->driver_data == adt7476 || id->driver_data == adt7490) {
+	if (chip == adt7476 || chip == adt7490) {
 		if (!(config3 & CONFIG3_THERM) ||
 		    (data->config4 & CONFIG4_PINFUNC) == 0x1)
 			data->has_voltage |= (1 << 0);		/* in0 */
@@ -1745,7 +1741,7 @@ static int adt7475_probe(struct i2c_client *client)
 	 * On the ADT7476, the +12V input pin may instead be used as VID5,
 	 * and VID pins may alternatively be used as GPIO
 	 */
-	if (id->driver_data == adt7476) {
+	if (chip == adt7476) {
 		u8 vid = adt7475_read(REG_VID);
 		if (!(vid & VID_VIDSEL))
 			data->has_voltage |= (1 << 4);		/* in4 */
@@ -1829,7 +1825,7 @@ static int adt7475_probe(struct i2c_client *client)
 	}
 
 	dev_info(&client->dev, "%s device, revision %d\n",
-		 names[id->driver_data], revision);
+		 names[chip], revision);
 	if ((data->has_voltage & 0x11) || data->has_fan4 || data->has_pwm2)
 		dev_info(&client->dev, "Optional features:%s%s%s%s%s\n",
 			 (data->has_voltage & (1 << 0)) ? " in0" : "",
-- 
2.39.2

[PATCH 06/31] hwmon: (aht10) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/aht10.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hwmon/aht10.c b/drivers/hwmon/aht10.c
index f136bf3ff40ad..312ef3e987540 100644
--- a/drivers/hwmon/aht10.c
+++ b/drivers/hwmon/aht10.c
@@ -331,8 +331,7 @@ static const struct hwmon_chip_info aht10_chip_info = {
 
 static int aht10_probe(struct i2c_client *client)
 {
-	const struct i2c_device_id *id = i2c_match_id(aht10_id, client);
-	enum aht10_variant variant = id->driver_data;
+	enum aht10_variant variant = (uintptr_t)i2c_get_match_data(client);
 	struct device *device = &client->dev;
 	struct device *hwmon_dev;
 	struct aht10_data *data;
-- 
2.39.2

[PATCH 07/31] hwmon: (dme1737) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/dme1737.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/dme1737.c b/drivers/hwmon/dme1737.c
index 3dcef221041d0..1a9b28dc91e64 100644
--- a/drivers/hwmon/dme1737.c
+++ b/drivers/hwmon/dme1737.c
@@ -2461,8 +2461,6 @@ static int dme1737_i2c_detect(struct i2c_client *client,
 	return 0;
 }
 
-static const struct i2c_device_id dme1737_id[];
-
 static int dme1737_i2c_probe(struct i2c_client *client)
 {
 	struct dme1737_data *data;
@@ -2474,7 +2472,7 @@ static int dme1737_i2c_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	i2c_set_clientdata(client, data);
-	data->type = i2c_match_id(dme1737_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 	data->client = client;
 	data->name = client->name;
 	mutex_init(&data->update_lock);
-- 
2.39.2

[PATCH 08/31] hwmon: (ds1621) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/ds1621.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/ds1621.c b/drivers/hwmon/ds1621.c
index bffbc80401718..42ec34cb8a5f8 100644
--- a/drivers/hwmon/ds1621.c
+++ b/drivers/hwmon/ds1621.c
@@ -342,8 +342,6 @@ static const struct attribute_group ds1621_group = {
 };
 __ATTRIBUTE_GROUPS(ds1621);
 
-static const struct i2c_device_id ds1621_id[];
-
 static int ds1621_probe(struct i2c_client *client)
 {
 	struct ds1621_data *data;
@@ -356,7 +354,7 @@ static int ds1621_probe(struct i2c_client *client)
 
 	mutex_init(&data->update_lock);
 
-	data->kind = i2c_match_id(ds1621_id, client)->driver_data;
+	data->kind = (uintptr_t)i2c_get_match_data(client);
 	data->client = client;
 
 	/* Initialize the DS1621 chip */
-- 
2.39.2

[PATCH 09/31] hwmon: (f75375s) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/f75375s.c | 46 ++++++++++++++++++-----------------------
 1 file changed, 20 insertions(+), 26 deletions(-)

diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index 8c572bb64f5dc..7e867f1324201 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -111,31 +111,6 @@ struct f75375_data {
 	s8 temp_max_hyst[2];
 };
 
-static int f75375_detect(struct i2c_client *client,
-			 struct i2c_board_info *info);
-static int f75375_probe(struct i2c_client *client);
-static void f75375_remove(struct i2c_client *client);
-
-static const struct i2c_device_id f75375_id[] = {
-	{ "f75373", f75373 },
-	{ "f75375", f75375 },
-	{ "f75387", f75387 },
-	{ }
-};
-MODULE_DEVICE_TABLE(i2c, f75375_id);
-
-static struct i2c_driver f75375_driver = {
-	.class = I2C_CLASS_HWMON,
-	.driver = {
-		.name = "f75375",
-	},
-	.probe = f75375_probe,
-	.remove = f75375_remove,
-	.id_table = f75375_id,
-	.detect = f75375_detect,
-	.address_list = normal_i2c,
-};
-
 static inline int f75375_read8(struct i2c_client *client, u8 reg)
 {
 	return i2c_smbus_read_byte_data(client, reg);
@@ -830,7 +805,7 @@ static int f75375_probe(struct i2c_client *client)
 
 	i2c_set_clientdata(client, data);
 	mutex_init(&data->update_lock);
-	data->kind = i2c_match_id(f75375_id, client)->driver_data;
+	data->kind = (uintptr_t)i2c_get_match_data(client);
 
 	err = sysfs_create_group(&client->dev.kobj, &f75375_group);
 	if (err)
@@ -901,6 +876,25 @@ static int f75375_detect(struct i2c_client *client,
 	return 0;
 }
 
+static const struct i2c_device_id f75375_id[] = {
+	{ "f75373", f75373 },
+	{ "f75375", f75375 },
+	{ "f75387", f75387 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, f75375_id);
+
+static struct i2c_driver f75375_driver = {
+	.class = I2C_CLASS_HWMON,
+	.driver = {
+		.name = "f75375",
+	},
+	.probe = f75375_probe,
+	.remove = f75375_remove,
+	.id_table = f75375_id,
+	.detect = f75375_detect,
+	.address_list = normal_i2c,
+};
 module_i2c_driver(f75375_driver);
 
 MODULE_AUTHOR("Riku Voipio");
-- 
2.39.2

[PATCH 10/31] hwmon: (fschmd) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/fschmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/fschmd.c b/drivers/hwmon/fschmd.c
index b30512a705a79..1811f84d835ef 100644
--- a/drivers/hwmon/fschmd.c
+++ b/drivers/hwmon/fschmd.c
@@ -1087,7 +1087,7 @@ static int fschmd_probe(struct i2c_client *client)
 				"Heracles", "Heimdall", "Hades", "Syleus" };
 	static const int watchdog_minors[] = { WATCHDOG_MINOR, 212, 213, 214, 215 };
 	int i, err;
-	enum chips kind = i2c_match_id(fschmd_id, client)->driver_data;
+	enum chips kind = (uintptr_t)i2c_get_match_data(client);
 
 	data = kzalloc(sizeof(struct fschmd_data), GFP_KERNEL);
 	if (!data)
-- 
2.39.2

[PATCH 11/31] hwmon: (ina2xx) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/ina2xx.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index d8415d1f21fc5..f8b5d972191ee 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -612,8 +612,6 @@ static const struct attribute_group ina226_group = {
 	.attrs = ina226_attrs,
 };
 
-static const struct i2c_device_id ina2xx_id[];
-
 static int ina2xx_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -623,10 +621,7 @@ static int ina2xx_probe(struct i2c_client *client)
 	int ret, group = 0;
 	enum ina2xx_ids chip;
 
-	if (client->dev.of_node)
-		chip = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		chip = i2c_match_id(ina2xx_id, client)->driver_data;
+	chip = (uintptr_t)i2c_get_match_data(client);
 
 	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
 	if (!data)
-- 
2.39.2

[PATCH 12/31] hwmon: (lm63) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/lm63.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/hwmon/lm63.c b/drivers/hwmon/lm63.c
index 0878a044dd8ef..035176a98ce9c 100644
--- a/drivers/hwmon/lm63.c
+++ b/drivers/hwmon/lm63.c
@@ -1104,10 +1104,7 @@ static int lm63_probe(struct i2c_client *client)
 	mutex_init(&data->update_lock);
 
 	/* Set the device type */
-	if (client->dev.of_node)
-		data->kind = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		data->kind = i2c_match_id(lm63_id, client)->driver_data;
+	data->kind = (uintptr_t)i2c_get_match_data(client);
 	if (data->kind == lm64)
 		data->temp2_offset = 16000;
 
-- 
2.39.2

[PATCH 13/31] hwmon: (lm75) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/lm75.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index e007507185360..2c2205aec7d40 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -625,20 +625,12 @@ static void lm75_remove(void *data)
 	i2c_smbus_write_byte_data(client, LM75_REG_CONF, lm75->orig_conf);
 }
 
-static const struct i2c_device_id lm75_ids[];
-
 static int lm75_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
 	struct device *hwmon_dev;
 	struct lm75_data *data;
 	int status, err;
-	enum lm75_type kind;
-
-	if (client->dev.of_node)
-		kind = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		kind = i2c_match_id(lm75_ids, client)->driver_data;
 
 	if (!i2c_check_functionality(client->adapter,
 			I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA))
@@ -649,7 +641,7 @@ static int lm75_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	data->client = client;
-	data->kind = kind;
+	data->kind = (uintptr_t)i2c_get_match_data(client);
 
 	data->vs = devm_regulator_get(dev, "vs");
 	if (IS_ERR(data->vs))
-- 
2.39.2

[PATCH 14/31] hwmon: (lm78) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/lm78.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/lm78.c b/drivers/hwmon/lm78.c
index b739c354311b0..8b53bb3120693 100644
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -627,8 +627,6 @@ static int lm78_i2c_detect(struct i2c_client *client,
 	return -ENODEV;
 }
 
-static const struct i2c_device_id lm78_i2c_id[];
-
 static int lm78_i2c_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -640,7 +638,7 @@ static int lm78_i2c_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	data->client = client;
-	data->type = i2c_match_id(lm78_i2c_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 
 	/* Initialize the LM78 chip */
 	lm78_init_device(data);
-- 
2.39.2

[PATCH 15/31] hwmon: (lm83) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/lm83.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/lm83.c b/drivers/hwmon/lm83.c
index b333c9bde4e64..f800fe2ef18b8 100644
--- a/drivers/hwmon/lm83.c
+++ b/drivers/hwmon/lm83.c
@@ -417,13 +417,6 @@ static int lm83_detect(struct i2c_client *client,
 	return 0;
 }
 
-static const struct i2c_device_id lm83_id[] = {
-	{ "lm83", lm83 },
-	{ "lm82", lm82 },
-	{ }
-};
-MODULE_DEVICE_TABLE(i2c, lm83_id);
-
 static int lm83_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -438,7 +431,7 @@ static int lm83_probe(struct i2c_client *client)
 	if (IS_ERR(data->regmap))
 		return PTR_ERR(data->regmap);
 
-	data->type = i2c_match_id(lm83_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 
 	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name,
 							 data, &lm83_chip_info, NULL);
@@ -449,6 +442,13 @@ static int lm83_probe(struct i2c_client *client)
  * Driver data (common to all clients)
  */
 
+static const struct i2c_device_id lm83_id[] = {
+	{ "lm83", lm83 },
+	{ "lm82", lm82 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, lm83_id);
+
 static struct i2c_driver lm83_driver = {
 	.class		= I2C_CLASS_HWMON,
 	.driver = {
-- 
2.39.2

[PATCH 16/31] hwmon: (lm85) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/lm85.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/hwmon/lm85.c b/drivers/hwmon/lm85.c
index 68c2100023575..1c244ed75122e 100644
--- a/drivers/hwmon/lm85.c
+++ b/drivers/hwmon/lm85.c
@@ -1544,8 +1544,6 @@ static int lm85_detect(struct i2c_client *client, struct i2c_board_info *info)
 	return 0;
 }
 
-static const struct i2c_device_id lm85_id[];
-
 static int lm85_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -1558,10 +1556,7 @@ static int lm85_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	data->client = client;
-	if (client->dev.of_node)
-		data->type = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		data->type = i2c_match_id(lm85_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 	mutex_init(&data->update_lock);
 
 	/* Fill in the chip specific driver values */
-- 
2.39.2

[PATCH 17/31] hwmon: (lm90) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/lm90.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index e0d7454a301cf..a5c65fc21163e 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -2764,10 +2764,7 @@ static int lm90_probe(struct i2c_client *client)
 	INIT_WORK(&data->report_work, lm90_report_alarms);
 
 	/* Set the device type */
-	if (client->dev.of_node)
-		data->kind = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		data->kind = i2c_match_id(lm90_id, client)->driver_data;
+	data->kind = (uintptr_t)i2c_get_match_data(client);
 
 	/*
 	 * Different devices have different alarm bits triggering the
-- 
2.39.2

[PATCH 18/31] hwmon: (lm95234) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/lm95234.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/lm95234.c b/drivers/hwmon/lm95234.c
index 67b9d7636ee42..be00a374632d3 100644
--- a/drivers/hwmon/lm95234.c
+++ b/drivers/hwmon/lm95234.c
@@ -677,10 +677,9 @@ static int lm95234_init_client(struct i2c_client *client)
 	return 0;
 }
 
-static const struct i2c_device_id lm95234_id[];
-
 static int lm95234_probe(struct i2c_client *client)
 {
+	enum chips type = (uintptr_t)i2c_get_match_data(client);
 	struct device *dev = &client->dev;
 	struct lm95234_data *data;
 	struct device *hwmon_dev;
@@ -699,7 +698,7 @@ static int lm95234_probe(struct i2c_client *client)
 		return err;
 
 	data->groups[0] = &lm95234_common_group;
-	if (i2c_match_id(lm95234_id, client)->driver_data == lm95234)
+	if (type == lm95234)
 		data->groups[1] = &lm95234_group;
 
 	hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
-- 
2.39.2

[PATCH 19/31] hwmon: (max16065) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/max16065.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/hwmon/max16065.c b/drivers/hwmon/max16065.c
index aa38c45adc09e..7ce9a89f93a0d 100644
--- a/drivers/hwmon/max16065.c
+++ b/drivers/hwmon/max16065.c
@@ -493,8 +493,6 @@ static const struct attribute_group max16065_max_group = {
 	.is_visible = max16065_secondary_is_visible,
 };
 
-static const struct i2c_device_id max16065_id[];
-
 static int max16065_probe(struct i2c_client *client)
 {
 	struct i2c_adapter *adapter = client->adapter;
@@ -505,7 +503,7 @@ static int max16065_probe(struct i2c_client *client)
 	bool have_secondary;		/* true if chip has secondary limits */
 	bool secondary_is_max = false;	/* secondary limits reflect max */
 	int groups = 0;
-	const struct i2c_device_id *id = i2c_match_id(max16065_id, client);
+	enum chips chip = (uintptr_t)i2c_get_match_data(client);
 
 	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA
 				     | I2C_FUNC_SMBUS_READ_WORD_DATA))
@@ -518,9 +516,9 @@ static int max16065_probe(struct i2c_client *client)
 	data->client = client;
 	mutex_init(&data->update_lock);
 
-	data->num_adc = max16065_num_adc[id->driver_data];
-	data->have_current = max16065_have_current[id->driver_data];
-	have_secondary = max16065_have_secondary[id->driver_data];
+	data->num_adc = max16065_num_adc[chip];
+	data->have_current = max16065_have_current[chip];
+	have_secondary = max16065_have_secondary[chip];
 
 	if (have_secondary) {
 		val = i2c_smbus_read_byte_data(client, MAX16065_SW_ENABLE);
-- 
2.39.2

[PATCH 20/31] hwmon: (max1668) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/max1668.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/max1668.c b/drivers/hwmon/max1668.c
index c4a02edefbee7..9fc583ebb11b2 100644
--- a/drivers/hwmon/max1668.c
+++ b/drivers/hwmon/max1668.c
@@ -391,8 +391,6 @@ static int max1668_detect(struct i2c_client *client,
 	return 0;
 }
 
-static const struct i2c_device_id max1668_id[];
-
 static int max1668_probe(struct i2c_client *client)
 {
 	struct i2c_adapter *adapter = client->adapter;
@@ -408,7 +406,7 @@ static int max1668_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	data->client = client;
-	data->type = i2c_match_id(max1668_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 	mutex_init(&data->update_lock);
 
 	/* sysfs hooks */
-- 
2.39.2

[PATCH 21/31] hwmon: (max6697) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/max6697.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c
index d161ba0e7813c..b28b7b9448aa8 100644
--- a/drivers/hwmon/max6697.c
+++ b/drivers/hwmon/max6697.c
@@ -684,8 +684,6 @@ static int max6697_init_chip(struct max6697_data *data,
 	return 0;
 }
 
-static const struct i2c_device_id max6697_id[];
-
 static int max6697_probe(struct i2c_client *client)
 {
 	struct i2c_adapter *adapter = client->adapter;
@@ -701,10 +699,7 @@ static int max6697_probe(struct i2c_client *client)
 	if (!data)
 		return -ENOMEM;
 
-	if (client->dev.of_node)
-		data->type = (uintptr_t)of_device_get_match_data(&client->dev);
-	else
-		data->type = i2c_match_id(max6697_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 	data->chip = &max6697_chip_data[data->type];
 	data->client = client;
 	mutex_init(&data->update_lock);
-- 
2.39.2

[PATCH 22/31] hwmon: (mcp3021) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/mcp3021.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c
index 9814eaf245644..bcddf6804d3ab 100644
--- a/drivers/hwmon/mcp3021.c
+++ b/drivers/hwmon/mcp3021.c
@@ -116,13 +116,12 @@ static const struct hwmon_chip_info mcp3021_chip_info = {
 	.info = mcp3021_info,
 };
 
-static const struct i2c_device_id mcp3021_id[];
-
 static int mcp3021_probe(struct i2c_client *client)
 {
 	struct mcp3021_data *data = NULL;
 	struct device_node *np = client->dev.of_node;
 	struct device *hwmon_dev;
+	enum chips type;
 
 	if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
 		return -ENODEV;
@@ -149,7 +148,8 @@ static int mcp3021_probe(struct i2c_client *client)
 			data->vdd = MCP3021_VDD_REF_DEFAULT;
 	}
 
-	switch (i2c_match_id(mcp3021_id, client)->driver_data) {
+	type = (uintptr_t)i2c_get_match_data(client);
+	switch (type) {
 	case mcp3021:
 		data->sar_shift = MCP3021_SAR_SHIFT;
 		data->sar_mask = MCP3021_SAR_MASK;
-- 
2.39.2

[PATCH 23/31] hwmon: (powr1220) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/powr1220.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/powr1220.c b/drivers/hwmon/powr1220.c
index 2388d0565e7ec..5f9ca6543530d 100644
--- a/drivers/hwmon/powr1220.c
+++ b/drivers/hwmon/powr1220.c
@@ -279,12 +279,11 @@ static const struct hwmon_chip_info powr1220_chip_info = {
 	.info = powr1220_info,
 };
 
-static const struct i2c_device_id powr1220_ids[];
-
 static int powr1220_probe(struct i2c_client *client)
 {
 	struct powr1220_data *data;
 	struct device *hwmon_dev;
+	enum powr1xxx_chips chip;
 
 	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
 		return -ENODEV;
@@ -293,7 +292,8 @@ static int powr1220_probe(struct i2c_client *client)
 	if (!data)
 		return -ENOMEM;
 
-	switch (i2c_match_id(powr1220_ids, client)->driver_data) {
+	chip = (uintptr_t)i2c_get_match_data(client);
+	switch (chip) {
 	case powr1014:
 		data->max_channels = 10;
 		break;
-- 
2.39.2

[PATCH 24/31] hwmon: (sht3x) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/sht3x.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/hwmon/sht3x.c b/drivers/hwmon/sht3x.c
index c0d02fbcdb76c..650b0bcc2359e 100644
--- a/drivers/hwmon/sht3x.c
+++ b/drivers/hwmon/sht3x.c
@@ -882,15 +882,6 @@ static const struct hwmon_chip_info sht3x_chip_info = {
 	.info = sht3x_channel_info,
 };
 
-/* device ID table */
-static const struct i2c_device_id sht3x_ids[] = {
-	{"sht3x", sht3x},
-	{"sts3x", sts3x},
-	{}
-};
-
-MODULE_DEVICE_TABLE(i2c, sht3x_ids);
-
 static int sht3x_probe(struct i2c_client *client)
 {
 	int ret;
@@ -920,7 +911,7 @@ static int sht3x_probe(struct i2c_client *client)
 	data->mode = 0;
 	data->last_update = jiffies - msecs_to_jiffies(3000);
 	data->client = client;
-	data->chip_id = i2c_match_id(sht3x_ids, client)->driver_data;
+	data->chip_id = (uintptr_t)i2c_get_match_data(client);
 	crc8_populate_msb(sht3x_crc8_table, SHT3X_CRC8_POLYNOMIAL);
 
 	sht3x_select_command(data);
@@ -963,6 +954,15 @@ static int sht3x_probe(struct i2c_client *client)
 	return PTR_ERR_OR_ZERO(hwmon_dev);
 }
 
+/* device ID table */
+static const struct i2c_device_id sht3x_ids[] = {
+	{"sht3x", sht3x},
+	{"sts3x", sts3x},
+	{}
+};
+
+MODULE_DEVICE_TABLE(i2c, sht3x_ids);
+
 static struct i2c_driver sht3x_i2c_driver = {
 	.driver.name = "sht3x",
 	.probe       = sht3x_probe,
-- 
2.39.2

[PATCH 25/31] hwmon: (shtc1) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/shtc1.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
index 1f96e94967ee8..24a8ae092d00e 100644
--- a/drivers/hwmon/shtc1.c
+++ b/drivers/hwmon/shtc1.c
@@ -186,8 +186,6 @@ static void shtc1_select_command(struct shtc1_data *data)
 	}
 }
 
-static const struct i2c_device_id shtc1_id[];
-
 static int shtc1_probe(struct i2c_client *client)
 {
 	int ret;
@@ -195,7 +193,7 @@ static int shtc1_probe(struct i2c_client *client)
 	char id_reg_buf[2];
 	struct shtc1_data *data;
 	struct device *hwmon_dev;
-	enum shtcx_chips chip = i2c_match_id(shtc1_id, client)->driver_data;
+	enum shtcx_chips chip = (uintptr_t)i2c_get_match_data(client);
 	struct i2c_adapter *adap = client->adapter;
 	struct device *dev = &client->dev;
 	struct device_node *np = dev->of_node;
-- 
2.39.2

[PATCH 26/31] hwmon: (thmc50) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/thmc50.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/thmc50.c b/drivers/hwmon/thmc50.c
index 68ba26bc90142..0cbdb91698b1f 100644
--- a/drivers/hwmon/thmc50.c
+++ b/drivers/hwmon/thmc50.c
@@ -377,8 +377,6 @@ static void thmc50_init_client(struct thmc50_data *data)
 	i2c_smbus_write_byte_data(client, THMC50_REG_CONF, config);
 }
 
-static const struct i2c_device_id thmc50_id[];
-
 static int thmc50_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -391,7 +389,7 @@ static int thmc50_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	data->client = client;
-	data->type = i2c_match_id(thmc50_id, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 	mutex_init(&data->update_lock);
 
 	thmc50_init_client(data);
-- 
2.39.2

[PATCH 27/31] hwmon: (tmp401) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/tmp401.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/tmp401.c b/drivers/hwmon/tmp401.c
index df1b45a62e804..853dbe708ff5d 100644
--- a/drivers/hwmon/tmp401.c
+++ b/drivers/hwmon/tmp401.c
@@ -693,7 +693,7 @@ static int tmp401_probe(struct i2c_client *client)
 
 	data->client = client;
 	mutex_init(&data->update_lock);
-	data->kind = i2c_match_id(tmp401_id, client)->driver_data;
+	data->kind = (uintptr_t)i2c_get_match_data(client);
 
 	data->regmap = devm_regmap_init(dev, NULL, data, &tmp401_regmap_config);
 	if (IS_ERR(data->regmap))
-- 
2.39.2

[PATCH 28/31] hwmon: (tmp421) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/tmp421.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 10b66c9ce0452..7a6f9532e5942 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -446,11 +446,7 @@ static int tmp421_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	mutex_init(&data->update_lock);
-	if (client->dev.of_node)
-		data->channels = (unsigned long)
-			of_device_get_match_data(&client->dev);
-	else
-		data->channels = i2c_match_id(tmp421_id, client)->driver_data;
+	data->channels = (unsigned long)i2c_get_match_data(client);
 	data->client = client;
 
 	for (i = 0; i < data->channels; i++) {
-- 
2.39.2

[PATCH 29/31] hwmon: (tmp464) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/tmp464.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/hwmon/tmp464.c b/drivers/hwmon/tmp464.c
index f58ca4c6acb6e..3ee1137533d63 100644
--- a/drivers/hwmon/tmp464.c
+++ b/drivers/hwmon/tmp464.c
@@ -666,10 +666,7 @@ static int tmp464_probe(struct i2c_client *client)
 
 	mutex_init(&data->update_lock);
 
-	if (dev->of_node)
-		data->channels = (int)(unsigned long)of_device_get_match_data(&client->dev);
-	else
-		data->channels = i2c_match_id(tmp464_id, client)->driver_data;
+	data->channels = (int)(unsigned long)i2c_get_match_data(client);
 
 	data->regmap = devm_regmap_init_i2c(client, &tmp464_regmap_config);
 	if (IS_ERR(data->regmap))
-- 
2.39.2

[PATCH 30/31] hwmon: (w83781d) Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/w83781d.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
index cba5ec432e6d1..b7957c84d2352 100644
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -1192,8 +1192,6 @@ static void w83781d_remove_files(struct device *dev)
 	sysfs_remove_group(&dev->kobj, &w83781d_group_other);
 }
 
-static const struct i2c_device_id w83781d_ids[];
-
 static int w83781d_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -1208,7 +1206,7 @@ static int w83781d_probe(struct i2c_client *client)
 	mutex_init(&data->lock);
 	mutex_init(&data->update_lock);
 
-	data->type = i2c_match_id(w83781d_ids, client)->driver_data;
+	data->type = (uintptr_t)i2c_get_match_data(client);
 	data->client = client;
 
 	/* attach secondary i2c lm75-like clients */
-- 
2.39.2

[PATCH 31/31] hwmon: (w83795): Remove use of i2c_match_id()

[Andrew Davis]

The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().

This helper has a couple other benefits:
 * It doesn't need the i2c_device_id passed in so we do not need
   to have that forward declared, allowing us to remove those or
   move the i2c_device_id table down to its more natural spot
   with the other module info.
 * It also checks for device match data, which allows for OF and
   ACPI based probing. That means we do not have to manually check
   those first and can remove those checks.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/hwmon/w83795.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/w83795.c b/drivers/hwmon/w83795.c
index c446e00db6586..5174db69db5e1 100644
--- a/drivers/hwmon/w83795.c
+++ b/drivers/hwmon/w83795.c
@@ -2134,8 +2134,6 @@ static void w83795_apply_temp_config(struct w83795_data *data, u8 config,
 	}
 }
 
-static const struct i2c_device_id w83795_id[];
-
 static int w83795_probe(struct i2c_client *client)
 {
 	int i;
@@ -2149,7 +2147,7 @@ static int w83795_probe(struct i2c_client *client)
 		return -ENOMEM;
 
 	i2c_set_clientdata(client, data);
-	data->chip_type = i2c_match_id(w83795_id, client)->driver_data;
+	data->chip_type = (uintptr_t)i2c_get_match_data(client);
 	data->bank = i2c_smbus_read_byte_data(client, W83795_REG_BANKSEL);
 	mutex_init(&data->update_lock);
 
-- 
2.39.2

Re: [PATCH 00/31] Remove use of i2c_match_id in HWMON

[Guenter Roeck]

On Wed, Apr 03, 2024 at 03:36:02PM -0500, Andrew Davis wrote:
> Hello all,
> 
> Goal here is to remove the i2c_match_id() function from all drivers.
> Using i2c_get_match_data() can simplify code and has some other
> benefits described in the patches.
> 

The return value from i2c_match_id() is typically an integer (chip ID)
starting with 0. Previously it has been claimed that this would be
unacceptable for i2c_get_match_data(), and chip IDs were changed to start
with 1. Commit ac0c26bae662 ("hwmon: (lm25066) Use i2c_get_match_data()")
is an example. Either this series is wrong, or the previous claim that
chip IDs (i.e., the content of .driver_data or .data) must not be 0 was
wrong. Which one is it ? I find it very confusing that the chip type for
some drivers now starts with 1 and for others with 0. Given that, I am not
inclined to accept this series unless it is explained in detail why the
chip type enum in, for example, drivers/hwmon/pmbus/lm25066.c has to start
with one but is ok to start with 0 for all drivers affected by this
series. Quite frankly, even if there is some kind of explanation, I am not
sure if I am going to accept it because future driver developers won't
know if they have to start chip types with 0 or 1.

Guenter

Re: [PATCH 00/31] Remove use of i2c_match_id in HWMON

[Andrew Davis]

On 4/3/24 4:30 PM, Guenter Roeck wrote:
> On Wed, Apr 03, 2024 at 03:36:02PM -0500, Andrew Davis wrote:
>> Hello all,
>>
>> Goal here is to remove the i2c_match_id() function from all drivers.
>> Using i2c_get_match_data() can simplify code and has some other
>> benefits described in the patches.
>>
> 
> The return value from i2c_match_id() is typically an integer (chip ID)
> starting with 0. Previously it has been claimed that this would be
> unacceptable for i2c_get_match_data(), and chip IDs were changed to start
> with 1. Commit ac0c26bae662 ("hwmon: (lm25066) Use i2c_get_match_data()")
> is an example. Either this series is wrong, or the previous claim that
> chip IDs (i.e., the content of .driver_data or .data) must not be 0 was
> wrong. Which one is it ? I find it very confusing that the chip type for
> some drivers now starts with 1 and for others with 0. Given that, I am not
> inclined to accept this series unless it is explained in detail why the
> chip type enum in, for example, drivers/hwmon/pmbus/lm25066.c has to start
> with one but is ok to start with 0 for all drivers affected by this
> series. Quite frankly, even if there is some kind of explanation, I am not
> sure if I am going to accept it because future driver developers won't
> know if they have to start chip types with 0 or 1.
> 

i2c_get_match_data() has no issue with returning 0 when the driver_data
for the match is also 0 (as it will be when the chip type is 0 here).

The confusion might be that returning 0 is also considered a failure code.
This is a problem in general with returning errors in-band with data, and
that is nothing new as i2c_match_id() does the same thing.

Actually, i2c_match_id() is worse as most of these drivers take the result
from that and immediately dereference it. Meaning if i2c_match_id() ever did
failed to find a match, they would crash before this series. Luckily i2c_match_id()
can't fail to find a match as far as I can tell, and so for the same reason
neither can i2c_get_match_data(), which means if 0 is returned it is always
because the chip ID was actually 0.

At some point we should switch all the *_get_match_data() functions to
return an error code and put the match if found as a argument pointer.
Forcing everyone to changing the chip type to avoid 0 as done in
ac0c26bae662 is the wrong way to fix an issue like that.

Andrew

Re: [PATCH 00/31] Remove use of i2c_match_id in HWMON

[Guenter Roeck]

On Wed, Apr 03, 2024 at 05:06:43PM -0500, Andrew Davis wrote:
> On 4/3/24 4:30 PM, Guenter Roeck wrote:
> > On Wed, Apr 03, 2024 at 03:36:02PM -0500, Andrew Davis wrote:
> > > Hello all,
> > > 
> > > Goal here is to remove the i2c_match_id() function from all drivers.
> > > Using i2c_get_match_data() can simplify code and has some other
> > > benefits described in the patches.
> > > 
> > 
> > The return value from i2c_match_id() is typically an integer (chip ID)
> > starting with 0. Previously it has been claimed that this would be
> > unacceptable for i2c_get_match_data(), and chip IDs were changed to start
> > with 1. Commit ac0c26bae662 ("hwmon: (lm25066) Use i2c_get_match_data()")
> > is an example. Either this series is wrong, or the previous claim that
> > chip IDs (i.e., the content of .driver_data or .data) must not be 0 was
> > wrong. Which one is it ? I find it very confusing that the chip type for
> > some drivers now starts with 1 and for others with 0. Given that, I am not
> > inclined to accept this series unless it is explained in detail why the
> > chip type enum in, for example, drivers/hwmon/pmbus/lm25066.c has to start
> > with one but is ok to start with 0 for all drivers affected by this
> > series. Quite frankly, even if there is some kind of explanation, I am not
> > sure if I am going to accept it because future driver developers won't
> > know if they have to start chip types with 0 or 1.
> > 
> 
> i2c_get_match_data() has no issue with returning 0 when the driver_data
> for the match is also 0 (as it will be when the chip type is 0 here).
> 
> The confusion might be that returning 0 is also considered a failure code.
> This is a problem in general with returning errors in-band with data, and
> that is nothing new as i2c_match_id() does the same thing.
> 
> Actually, i2c_match_id() is worse as most of these drivers take the result
> from that and immediately dereference it. Meaning if i2c_match_id() ever did
> failed to find a match, they would crash before this series. Luckily i2c_match_id()
> can't fail to find a match as far as I can tell, and so for the same reason
> neither can i2c_get_match_data(), which means if 0 is returned it is always
> because the chip ID was actually 0.
> 
> At some point we should switch all the *_get_match_data() functions to
> return an error code and put the match if found as a argument pointer.
> Forcing everyone to changing the chip type to avoid 0 as done in
> ac0c26bae662 is the wrong way to fix an issue like that.
> 

That doesn't really answer my question. It does not explain why it was
necessary to change the chip ID base for other drivers from 0 to 1,
but not for the drivers in this series. I fail to see the difference,
and I have to assume that others looking into the code will have the
same problem.

Guenter

Re: [PATCH 00/31] Remove use of i2c_match_id in HWMON

[Guenter Roeck]

On Mon, Apr 08, 2024 at 04:49:43AM -0700, Guenter Roeck wrote:
> On Wed, Apr 03, 2024 at 05:06:43PM -0500, Andrew Davis wrote:
> > On 4/3/24 4:30 PM, Guenter Roeck wrote:
> > > On Wed, Apr 03, 2024 at 03:36:02PM -0500, Andrew Davis wrote:
> > > > Hello all,
> > > > 
> > > > Goal here is to remove the i2c_match_id() function from all drivers.
> > > > Using i2c_get_match_data() can simplify code and has some other
> > > > benefits described in the patches.
> > > > 
> > > 
> > > The return value from i2c_match_id() is typically an integer (chip ID)
> > > starting with 0. Previously it has been claimed that this would be
> > > unacceptable for i2c_get_match_data(), and chip IDs were changed to start
> > > with 1. Commit ac0c26bae662 ("hwmon: (lm25066) Use i2c_get_match_data()")
> > > is an example. Either this series is wrong, or the previous claim that
> > > chip IDs (i.e., the content of .driver_data or .data) must not be 0 was
> > > wrong. Which one is it ? I find it very confusing that the chip type for
> > > some drivers now starts with 1 and for others with 0. Given that, I am not
> > > inclined to accept this series unless it is explained in detail why the
> > > chip type enum in, for example, drivers/hwmon/pmbus/lm25066.c has to start
> > > with one but is ok to start with 0 for all drivers affected by this
> > > series. Quite frankly, even if there is some kind of explanation, I am not
> > > sure if I am going to accept it because future driver developers won't
> > > know if they have to start chip types with 0 or 1.
> > > 
> > 
> > i2c_get_match_data() has no issue with returning 0 when the driver_data
> > for the match is also 0 (as it will be when the chip type is 0 here).
> > 
> > The confusion might be that returning 0 is also considered a failure code.
> > This is a problem in general with returning errors in-band with data, and
> > that is nothing new as i2c_match_id() does the same thing.
> > 
> > Actually, i2c_match_id() is worse as most of these drivers take the result
> > from that and immediately dereference it. Meaning if i2c_match_id() ever did
> > failed to find a match, they would crash before this series. Luckily i2c_match_id()
> > can't fail to find a match as far as I can tell, and so for the same reason
> > neither can i2c_get_match_data(), which means if 0 is returned it is always
> > because the chip ID was actually 0.
> > 
> > At some point we should switch all the *_get_match_data() functions to
> > return an error code and put the match if found as a argument pointer.
> > Forcing everyone to changing the chip type to avoid 0 as done in
> > ac0c26bae662 is the wrong way to fix an issue like that.
> > 
> 
> That doesn't really answer my question. It does not explain why it was
> necessary to change the chip ID base for other drivers from 0 to 1,
> but not for the drivers in this series. I fail to see the difference,
> and I have to assume that others looking into the code will have the
> same problem.
> 

Just to follow up: I am not going to apply this series until I understand
why the chip ID range had to be changed from 0.. to 1.. for other hardware
monitoring drivers (lm25066, nct6775) but not for the drivers changed
in this series. I have been telling people that chip IDs need to start
with 1 if i2c_get_match_data() is used. I'll need understand when and 
why this is needed to be able to provide guidance to other developers.

Guenter

Re: [PATCH 00/31] Remove use of i2c_match_id in HWMON

[Andrew Davis]

On 4/16/24 9:16 AM, Guenter Roeck wrote:
> On Mon, Apr 08, 2024 at 04:49:43AM -0700, Guenter Roeck wrote:
>> On Wed, Apr 03, 2024 at 05:06:43PM -0500, Andrew Davis wrote:
>>> On 4/3/24 4:30 PM, Guenter Roeck wrote:
>>>> On Wed, Apr 03, 2024 at 03:36:02PM -0500, Andrew Davis wrote:
>>>>> Hello all,
>>>>>
>>>>> Goal here is to remove the i2c_match_id() function from all drivers.
>>>>> Using i2c_get_match_data() can simplify code and has some other
>>>>> benefits described in the patches.
>>>>>
>>>>
>>>> The return value from i2c_match_id() is typically an integer (chip ID)
>>>> starting with 0. Previously it has been claimed that this would be
>>>> unacceptable for i2c_get_match_data(), and chip IDs were changed to start
>>>> with 1. Commit ac0c26bae662 ("hwmon: (lm25066) Use i2c_get_match_data()")
>>>> is an example. Either this series is wrong, or the previous claim that
>>>> chip IDs (i.e., the content of .driver_data or .data) must not be 0 was
>>>> wrong. Which one is it ? I find it very confusing that the chip type for
>>>> some drivers now starts with 1 and for others with 0. Given that, I am not
>>>> inclined to accept this series unless it is explained in detail why the
>>>> chip type enum in, for example, drivers/hwmon/pmbus/lm25066.c has to start
>>>> with one but is ok to start with 0 for all drivers affected by this
>>>> series. Quite frankly, even if there is some kind of explanation, I am not
>>>> sure if I am going to accept it because future driver developers won't
>>>> know if they have to start chip types with 0 or 1.
>>>>
>>>
>>> i2c_get_match_data() has no issue with returning 0 when the driver_data
>>> for the match is also 0 (as it will be when the chip type is 0 here).
>>>
>>> The confusion might be that returning 0 is also considered a failure code.
>>> This is a problem in general with returning errors in-band with data, and
>>> that is nothing new as i2c_match_id() does the same thing.
>>>
>>> Actually, i2c_match_id() is worse as most of these drivers take the result
>>> from that and immediately dereference it. Meaning if i2c_match_id() ever did
>>> failed to find a match, they would crash before this series. Luckily i2c_match_id()
>>> can't fail to find a match as far as I can tell, and so for the same reason
>>> neither can i2c_get_match_data(), which means if 0 is returned it is always
>>> because the chip ID was actually 0.
>>>
>>> At some point we should switch all the *_get_match_data() functions to
>>> return an error code and put the match if found as a argument pointer.
>>> Forcing everyone to changing the chip type to avoid 0 as done in
>>> ac0c26bae662 is the wrong way to fix an issue like that.
>>>
>>
>> That doesn't really answer my question. It does not explain why it was
>> necessary to change the chip ID base for other drivers from 0 to 1,
>> but not for the drivers in this series. I fail to see the difference,
>> and I have to assume that others looking into the code will have the
>> same problem.
>>
> 
> Just to follow up: I am not going to apply this series until I understand
> why the chip ID range had to be changed from 0.. to 1.. for other hardware
> monitoring drivers (lm25066, nct6775) but not for the drivers changed
> in this series. I have been telling people that chip IDs need to start
> with 1 if i2c_get_match_data() is used. I'll need understand when and
> why this is needed to be able to provide guidance to other developers.
> 

I was hoping one of those patch authors that made those 0->1 changes
would speak up (+Rob), I can't know what their thinking was, only
offer my best guess as I did above.

Andrew

> Guenter

Re: [PATCH 00/31] Remove use of i2c_match_id in HWMON

[Guenter Roeck]

On Tue, Apr 16, 2024 at 12:08:50PM -0500, Andrew Davis wrote:
> On 4/16/24 9:16 AM, Guenter Roeck wrote:
> > On Mon, Apr 08, 2024 at 04:49:43AM -0700, Guenter Roeck wrote:
> > > On Wed, Apr 03, 2024 at 05:06:43PM -0500, Andrew Davis wrote:
> > > > On 4/3/24 4:30 PM, Guenter Roeck wrote:
> > > > > On Wed, Apr 03, 2024 at 03:36:02PM -0500, Andrew Davis wrote:
> > > > > > Hello all,
> > > > > > 
> > > > > > Goal here is to remove the i2c_match_id() function from all drivers.
> > > > > > Using i2c_get_match_data() can simplify code and has some other
> > > > > > benefits described in the patches.
> > > > > > 
> > > > > 
> > > > > The return value from i2c_match_id() is typically an integer (chip ID)
> > > > > starting with 0. Previously it has been claimed that this would be
> > > > > unacceptable for i2c_get_match_data(), and chip IDs were changed to start
> > > > > with 1. Commit ac0c26bae662 ("hwmon: (lm25066) Use i2c_get_match_data()")
> > > > > is an example. Either this series is wrong, or the previous claim that
> > > > > chip IDs (i.e., the content of .driver_data or .data) must not be 0 was
> > > > > wrong. Which one is it ? I find it very confusing that the chip type for
> > > > > some drivers now starts with 1 and for others with 0. Given that, I am not
> > > > > inclined to accept this series unless it is explained in detail why the
> > > > > chip type enum in, for example, drivers/hwmon/pmbus/lm25066.c has to start
> > > > > with one but is ok to start with 0 for all drivers affected by this
> > > > > series. Quite frankly, even if there is some kind of explanation, I am not
> > > > > sure if I am going to accept it because future driver developers won't
> > > > > know if they have to start chip types with 0 or 1.
> > > > > 
> > > > 
> > > > i2c_get_match_data() has no issue with returning 0 when the driver_data
> > > > for the match is also 0 (as it will be when the chip type is 0 here).
> > > > 
> > > > The confusion might be that returning 0 is also considered a failure code.
> > > > This is a problem in general with returning errors in-band with data, and
> > > > that is nothing new as i2c_match_id() does the same thing.
> > > > 
> > > > Actually, i2c_match_id() is worse as most of these drivers take the result
> > > > from that and immediately dereference it. Meaning if i2c_match_id() ever did
> > > > failed to find a match, they would crash before this series. Luckily i2c_match_id()
> > > > can't fail to find a match as far as I can tell, and so for the same reason
> > > > neither can i2c_get_match_data(), which means if 0 is returned it is always
> > > > because the chip ID was actually 0.
> > > > 
> > > > At some point we should switch all the *_get_match_data() functions to
> > > > return an error code and put the match if found as a argument pointer.
> > > > Forcing everyone to changing the chip type to avoid 0 as done in
> > > > ac0c26bae662 is the wrong way to fix an issue like that.
> > > > 
> > > 
> > > That doesn't really answer my question. It does not explain why it was
> > > necessary to change the chip ID base for other drivers from 0 to 1,
> > > but not for the drivers in this series. I fail to see the difference,
> > > and I have to assume that others looking into the code will have the
> > > same problem.
> > > 
> > 
> > Just to follow up: I am not going to apply this series until I understand
> > why the chip ID range had to be changed from 0.. to 1.. for other hardware
> > monitoring drivers (lm25066, nct6775) but not for the drivers changed
> > in this series. I have been telling people that chip IDs need to start
> > with 1 if i2c_get_match_data() is used. I'll need understand when and
> > why this is needed to be able to provide guidance to other developers.
> > 
> 
> I was hoping one of those patch authors that made those 0->1 changes
> would speak up (+Rob), I can't know what their thinking was, only
> offer my best guess as I did above.
> 

I can see three possibilities.

- Chip IDs must start with 1 if i2c_get_match_data() is used, as I was told
  previously. If so, this series is wrong.
- It is ok for chip IDs to start with 0. If so, what I have been told
  previously is wrong, and the patches changing chip IDs to start with 1
  can and should be partially reverted to avoid confusion.
- Chip IDs must sometimes, but not always, start with 1. If so, the
  conditions will have to be documented to help driver developers decide
  the valid starting value and to be able to determine if all the patches
  in this series follow the rules.

Someone will have to step up and explain to me which one it is.

Thanks,
Guenter

Re: [PATCH 00/31] Remove use of i2c_match_id in HWMON

[Guenter Roeck]

On 4/18/24 06:42, Guenter Roeck wrote:
> On Tue, Apr 16, 2024 at 12:08:50PM -0500, Andrew Davis wrote:
>> On 4/16/24 9:16 AM, Guenter Roeck wrote:
>>> On Mon, Apr 08, 2024 at 04:49:43AM -0700, Guenter Roeck wrote:
>>>> On Wed, Apr 03, 2024 at 05:06:43PM -0500, Andrew Davis wrote:
>>>>> On 4/3/24 4:30 PM, Guenter Roeck wrote:
>>>>>> On Wed, Apr 03, 2024 at 03:36:02PM -0500, Andrew Davis wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> Goal here is to remove the i2c_match_id() function from all drivers.
>>>>>>> Using i2c_get_match_data() can simplify code and has some other
>>>>>>> benefits described in the patches.
>>>>>>>
>>>>>>
>>>>>> The return value from i2c_match_id() is typically an integer (chip ID)
>>>>>> starting with 0. Previously it has been claimed that this would be
>>>>>> unacceptable for i2c_get_match_data(), and chip IDs were changed to start
>>>>>> with 1. Commit ac0c26bae662 ("hwmon: (lm25066) Use i2c_get_match_data()")
>>>>>> is an example. Either this series is wrong, or the previous claim that
>>>>>> chip IDs (i.e., the content of .driver_data or .data) must not be 0 was
>>>>>> wrong. Which one is it ? I find it very confusing that the chip type for
>>>>>> some drivers now starts with 1 and for others with 0. Given that, I am not
>>>>>> inclined to accept this series unless it is explained in detail why the
>>>>>> chip type enum in, for example, drivers/hwmon/pmbus/lm25066.c has to start
>>>>>> with one but is ok to start with 0 for all drivers affected by this
>>>>>> series. Quite frankly, even if there is some kind of explanation, I am not
>>>>>> sure if I am going to accept it because future driver developers won't
>>>>>> know if they have to start chip types with 0 or 1.
>>>>>>
>>>>>
>>>>> i2c_get_match_data() has no issue with returning 0 when the driver_data
>>>>> for the match is also 0 (as it will be when the chip type is 0 here).
>>>>>
>>>>> The confusion might be that returning 0 is also considered a failure code.
>>>>> This is a problem in general with returning errors in-band with data, and
>>>>> that is nothing new as i2c_match_id() does the same thing.
>>>>>
>>>>> Actually, i2c_match_id() is worse as most of these drivers take the result
>>>>> from that and immediately dereference it. Meaning if i2c_match_id() ever did
>>>>> failed to find a match, they would crash before this series. Luckily i2c_match_id()
>>>>> can't fail to find a match as far as I can tell, and so for the same reason
>>>>> neither can i2c_get_match_data(), which means if 0 is returned it is always
>>>>> because the chip ID was actually 0.
>>>>>
>>>>> At some point we should switch all the *_get_match_data() functions to
>>>>> return an error code and put the match if found as a argument pointer.
>>>>> Forcing everyone to changing the chip type to avoid 0 as done in
>>>>> ac0c26bae662 is the wrong way to fix an issue like that.
>>>>>
>>>>
>>>> That doesn't really answer my question. It does not explain why it was
>>>> necessary to change the chip ID base for other drivers from 0 to 1,
>>>> but not for the drivers in this series. I fail to see the difference,
>>>> and I have to assume that others looking into the code will have the
>>>> same problem.
>>>>
>>>
>>> Just to follow up: I am not going to apply this series until I understand
>>> why the chip ID range had to be changed from 0.. to 1.. for other hardware
>>> monitoring drivers (lm25066, nct6775) but not for the drivers changed
>>> in this series. I have been telling people that chip IDs need to start
>>> with 1 if i2c_get_match_data() is used. I'll need understand when and
>>> why this is needed to be able to provide guidance to other developers.
>>>
>>
>> I was hoping one of those patch authors that made those 0->1 changes
>> would speak up (+Rob), I can't know what their thinking was, only
>> offer my best guess as I did above.
>>
> 
> I can see three possibilities.
> 
> - Chip IDs must start with 1 if i2c_get_match_data() is used, as I was told
>    previously. If so, this series is wrong.
> - It is ok for chip IDs to start with 0. If so, what I have been told
>    previously is wrong, and the patches changing chip IDs to start with 1
>    can and should be partially reverted to avoid confusion.
> - Chip IDs must sometimes, but not always, start with 1. If so, the
>    conditions will have to be documented to help driver developers decide
>    the valid starting value and to be able to determine if all the patches
>    in this series follow the rules.
> 
> Someone will have to step up and explain to me which one it is.
> 

Unfortunately, that step-in never happened. Instead, I keep getting patches
similar to this series. So, I applied the series, and I'll submit
patches to update all drivers to have the chip ID enum start with 0,
and/or to remove the complexity introduced under the assumption that it must
not be 0 / NULL.

Guenter