Skip to contentSkip to conversation

iio: humidity: hdc100x: add HDC1000 and HDC1008 product names

PATCH Superseded Alison Schofield 3 participants 5 messages May 20, 2016 – Jul 24, 2016 IIO

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 iio: humidity: hdc100x: add HDC1000 and HDC1008 product names

hdc100x supports Texas Instruments HDC1000 and HDC1008 relative humidity and temperature sensors. Add these product names to Kconfig and to the drivers device id structure to enable finding the product by name and using it to add a device.

---
 drivers/iio/humidity/Kconfig   | 8 ++++----
 drivers/iio/humidity/hdc100x.c | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/iio/humidity/Kconfig +4 -4
index 738a86d..f155386 100644
@@ -26,11 +26,11 @@ config HDC100X
 	tristate "TI HDC100x relative humidity and temperature sensor"
 	depends on I2C
 	help
-	 Say yes here to build support for the TI HDC100x series of
-	 relative humidity and temperature sensors.
+	  Say yes here to build support for the Texas Instruments
+	  HDC1000 and HDC1008 relative humidity and temperature sensors.
 
-	 To compile this driver as a module, choose M here: the module
-	 will be called hdc100x.
+	  To compile this driver as a module, choose M here: the module
+	  will be called hdc100x.
 
 config HTU21
 	tristate "Measurement Specialties HTU21 humidity & temperature sensor"
drivers/iio/humidity/hdc100x.c +2 -0
index fa47676..0deb874 100644
@@ -302,6 +302,8 @@ static int hdc100x_probe(struct i2c_client *client,
 
 static const struct i2c_device_id hdc100x_id[] = {
 	{ "hdc100x", 0 },
+	{ "hdc1000", 0 },
+	{ "hdc1008", 0 },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, hdc100x_id);
Signature · 1 line
2.1.4
#1 lore raw
Quoted 37 lines · Alison Schofield

hdc100x supports Texas Instruments HDC1000 and HDC1008 relative humidity and temperature sensors. Add these product names to Kconfig and to the drivers device id structure to enable finding the product by name and using it to add a device.

---
 drivers/iio/humidity/Kconfig   | 8 ++++----
 drivers/iio/humidity/hdc100x.c | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/iio/humidity/Kconfig +4 -4
index 738a86d..f155386 100644
@@ -26,11 +26,11 @@ config HDC100X
        tristate "TI HDC100x relative humidity and temperature sensor"
        depends on I2C
        help
-        Say yes here to build support for the TI HDC100x series of
-        relative humidity and temperature sensors.
+         Say yes here to build support for the Texas Instruments
+         HDC1000 and HDC1008 relative humidity and temperature sensors.
 
-        To compile this driver as a module, choose M here: the module
-        will be called hdc100x.
+         To compile this driver as a module, choose M here: the module
+         will be called hdc100x.
 
 config HTU21
        tristate "Measurement Specialties HTU21 humidity & temperature sensor"
drivers/iio/humidity/hdc100x.c +0 -0
index fa47676..0deb874 100644

drivers/iio/humidity/hdc100x.c static int hdc100x_probe(struct i2c_client *client, · line 306

Quoted 5 lines
drivers/iio/humidity/hdc100x.c +2 -0
@@ -302,6 +302,8 @@ static int hdc100x_probe(struct i2c_client *client,
 
 static const struct i2c_device_id hdc100x_id[] = {
        { "hdc100x", 0 },
+       { "hdc1000", 0 },
+       { "hdc1008", 0 },

Personally I think adding more device ids that don't add any per chip configuration is just adding clutter.
There is a reason I used "hdc100x" when I wrote the driver :)

Quoted 6 lines
drivers/iio/humidity/hdc100x.c +0 -1
        { }
 };
 MODULE_DEVICE_TABLE(i2c, hdc100x_id);
--

2.1.4

maintainer
#2 lore raw
Quoted 39 lines · Matt Ranostay
Quoted 38 lines · Alison Schofield

hdc100x supports Texas Instruments HDC1000 and HDC1008 relative humidity and temperature sensors. Add these product names to Kconfig and to the drivers device id structure to enable finding the product by name and using it to add a device.

---
 drivers/iio/humidity/Kconfig   | 8 ++++----
 drivers/iio/humidity/hdc100x.c | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/iio/humidity/Kconfig +4 -4
index 738a86d..f155386 100644
@@ -26,11 +26,11 @@ config HDC100X
        tristate "TI HDC100x relative humidity and temperature sensor"
        depends on I2C
        help
-        Say yes here to build support for the TI HDC100x series of
-        relative humidity and temperature sensors.
+         Say yes here to build support for the Texas Instruments
+         HDC1000 and HDC1008 relative humidity and temperature sensors.
 
-        To compile this driver as a module, choose M here: the module
-        will be called hdc100x.
+         To compile this driver as a module, choose M here: the module
+         will be called hdc100x.
 
 config HTU21
        tristate "Measurement Specialties HTU21 humidity & temperature sensor"
drivers/iio/humidity/hdc100x.c +0 -0
index fa47676..0deb874 100644
@@ -302,6 +302,8 @@ static int hdc100x_probe(struct i2c_client *client,
 
Quoted 8 lines

drivers/iio/humidity/hdc100x.c static int hdc100x_probe(struct i2c_client *client, · line 306

Quoted 4 lines
drivers/iio/humidity/hdc100x.c +2 -0
 static const struct i2c_device_id hdc100x_id[] = {
        { "hdc100x", 0 },
+       { "hdc1000", 0 },
+       { "hdc1008", 0 },

Personally I think adding more device ids that don't add any per chip configuration is just adding clutter.
There is a reason I used "hdc100x" when I wrote the driver :)

Hmm. I should have picked up on this in the first place. It's much preferred to go with complete part names. Avoids any possible issues with devicetrees / ACPI bindings where it's kind of assumed a whole part name will be used.

I'd prefer to have them explicitly listed. We will have to keep the wild card form as well as by now there will be boards using that out there. If it was just internal to the kernel I'd agree with the clutter argument, but it isn't so let us be as explicit in the naming as possible.

Jonathan

Quoted 8 lines
Quoted 8 lines
drivers/iio/humidity/hdc100x.c +0 -1
        { }
 };
 MODULE_DEVICE_TABLE(i2c, hdc100x_id);
--

2.1.4

#3 lore raw
Quoted 52 lines · Jonathan Cameron
Quoted 39 lines · Matt Ranostay
Quoted 38 lines · Alison Schofield

hdc100x supports Texas Instruments HDC1000 and HDC1008 relative humidity and temperature sensors. Add these product names to Kconfig and to the drivers device id structure to enable finding the product by name and using it to add a device.

---
 drivers/iio/humidity/Kconfig   | 8 ++++----
 drivers/iio/humidity/hdc100x.c | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/iio/humidity/Kconfig +4 -4
index 738a86d..f155386 100644
@@ -26,11 +26,11 @@ config HDC100X
        tristate "TI HDC100x relative humidity and temperature sensor"
        depends on I2C
        help
-        Say yes here to build support for the TI HDC100x series of
-        relative humidity and temperature sensors.
+         Say yes here to build support for the Texas Instruments
+         HDC1000 and HDC1008 relative humidity and temperature sensors.
 
-        To compile this driver as a module, choose M here: the module
-        will be called hdc100x.
+         To compile this driver as a module, choose M here: the module
+         will be called hdc100x.
 
 config HTU21
        tristate "Measurement Specialties HTU21 humidity & temperature sensor"
drivers/iio/humidity/hdc100x.c +0 -0
index fa47676..0deb874 100644
@@ -302,6 +302,8 @@ static int hdc100x_probe(struct i2c_client *client,
 
Quoted 8 lines

drivers/iio/humidity/hdc100x.c static int hdc100x_probe(struct i2c_client *client, · line 306

Quoted 4 lines
drivers/iio/humidity/hdc100x.c +2 -0
 static const struct i2c_device_id hdc100x_id[] = {
        { "hdc100x", 0 },
+       { "hdc1000", 0 },
+       { "hdc1008", 0 },

Personally I think adding more device ids that don't add any per chip configuration is just adding clutter.
There is a reason I used "hdc100x" when I wrote the driver :)

Hmm. I should have picked up on this in the first place. It's much preferred to go with complete part names. Avoids any possible issues with devicetrees / ACPI bindings where it's kind of assumed a whole part name will be used.

Quoted 6 lines

I'd prefer to have them explicitly listed. We will have to keep the wild card form as well as by now there will be boards using that out there. If it was just internal to the kernel I'd agree with the clutter argument, but it isn't so let us be as explicit in the naming as possible.

Jonathan

Jonathan,

It seemed like you were going to take this patch, but haven't.
I can pull the names out of the device_id fields if wanted, but it would be nice to at least have them in the Kconfig so one can grep for these names. Let me know if it needs a v2.

Thanks,
alisons

Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/iio/humidity/hdc100x.c +0 -1
        { }
 };
 MODULE_DEVICE_TABLE(i2c, hdc100x_id);
--

2.1.4

maintainer
#4 lore raw
Quoted 58 lines · Alison Schofield
Quoted 57 lines · Jonathan Cameron
Quoted 39 lines · Matt Ranostay
Quoted 38 lines · Alison Schofield

hdc100x supports Texas Instruments HDC1000 and HDC1008 relative humidity and temperature sensors. Add these product names to Kconfig and to the drivers device id structure to enable finding the product by name and using it to add a device.

---
 drivers/iio/humidity/Kconfig   | 8 ++++----
 drivers/iio/humidity/hdc100x.c | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/iio/humidity/Kconfig +4 -4
index 738a86d..f155386 100644
@@ -26,11 +26,11 @@ config HDC100X
        tristate "TI HDC100x relative humidity and temperature sensor"
        depends on I2C
        help
-        Say yes here to build support for the TI HDC100x series of
-        relative humidity and temperature sensors.
+         Say yes here to build support for the Texas Instruments
+         HDC1000 and HDC1008 relative humidity and temperature sensors.
 
-        To compile this driver as a module, choose M here: the module
-        will be called hdc100x.
+         To compile this driver as a module, choose M here: the module
+         will be called hdc100x.
 
 config HTU21
        tristate "Measurement Specialties HTU21 humidity & temperature sensor"
drivers/iio/humidity/hdc100x.c +0 -0
index fa47676..0deb874 100644
@@ -302,6 +302,8 @@ static int hdc100x_probe(struct i2c_client *client,
 
Quoted 8 lines

drivers/iio/humidity/hdc100x.c static int hdc100x_probe(struct i2c_client *client, · line 306

Quoted 4 lines
drivers/iio/humidity/hdc100x.c +2 -0
 static const struct i2c_device_id hdc100x_id[] = {
        { "hdc100x", 0 },
+       { "hdc1000", 0 },
+       { "hdc1008", 0 },

Personally I think adding more device ids that don't add any per chip configuration is just adding clutter.
There is a reason I used "hdc100x" when I wrote the driver :)

Hmm. I should have picked up on this in the first place. It's much preferred to go with complete part names. Avoids any possible issues with devicetrees / ACPI bindings where it's kind of assumed a whole part name will be used.

I'd prefer to have them explicitly listed. We will have to keep the wild card form as well as by now there will be boards using that out there. If it was just internal to the kernel I'd agree with the clutter argument, but it isn't so let us be as explicit in the naming as possible.

Quoted 9 lines
Quoted 1 line

Jonathan

Jonathan,

It seemed like you were going to take this patch, but haven't.
I can pull the names out of the device_id fields if wanted, but it would be nice to at least have them in the Kconfig so one can grep for these names. Let me know if it needs a v2.

yes please.

Quoted 17 lines

Thanks,
alisons

Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/iio/humidity/hdc100x.c +0 -1
        { }
 };
 MODULE_DEVICE_TABLE(i2c, hdc100x_id);
--

2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html