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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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
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
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
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
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
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