drivers/iio/humidity/Kconfig | 8 +++++--- drivers/iio/humidity/am2315.c | 3 ++- 2 files changed, 7 insertions(+), 4 deletions(-)
The AM2320 is fully compatible with the AM2315 sensor in terms of I2C
communication protocol and measurement conversions.
Add the "am2320" entry to the i2c_device_id table.
Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
---
v2:
- Adapted KConfig text using the suggestions from v1 by Nuno Sá and Andy
Shevchenko
v1: https://lore.kernel.org/all/20260805183733.1000550-1-nico.antinori.7@gmail.com/T/#u
drivers/iio/humidity/Kconfig | 8 +++++---
drivers/iio/humidity/am2315.c | 3 ++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
index 54f11f000b6f..10598a0b15bc 100644
--- a/drivers/iio/humidity/Kconfig
+++ b/drivers/iio/humidity/Kconfig
@@ -5,13 +5,15 @@
menu "Humidity sensors"
config AM2315
- tristate "Aosong AM2315 relative humidity and temperature sensor"
+ tristate "Aosong AM2315 and similar relative humidity and temperature sensor"
depends on I2C
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
- If you say yes here you get support for the Aosong AM2315
- relative humidity and ambient temperature sensor.
+ If you say yes here you get support for the Aosong relative
+ humidity and ambient temperature sensors:
+ - AM2315
+ - AM2320
This driver can also be built as a module. If so, the module will
be called am2315.
diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
index f29baa251f9f..5bce5eec45cc 100644
--- a/drivers/iio/humidity/am2315.c
+++ b/drivers/iio/humidity/am2315.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Aosong AM2315 relative humidity and temperature
+ * Aosong AM2315 and similar relative humidity and temperature
*
* Copyright (c) 2016, Intel Corporation.
*
@@ -251,6 +251,7 @@ static int am2315_probe(struct i2c_client *client)
static const struct i2c_device_id am2315_i2c_id[] = {
{ .name = "am2315" },
+ { .name = "am2320" },
{ }
};
MODULE_DEVICE_TABLE(i2c, am2315_i2c_id);
--
2.47.3
On 08/10, Nicolás Antinori wrote: > The AM2320 is fully compatible with the AM2315 sensor in terms of I2C > communication protocol and measurement conversions. > > Add the "am2320" entry to the i2c_device_id table. > > Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com> > --- David's comment about the IIO device name sounds appropriate. The am2315 driver might use a chip_info struct to hold the name of each specific design. There are many drivers in IIO that already have such things. drivers/iio/accel/adxl372_i2c.c is one example. An alternative might be to use the device id. const struct i2c_device_id *id = i2c_client_get_device_id(client); ... indio_dev->name = id->name; Not sure if the second option works well for both i2c and dt (probably not), so I'd suggest the chip_info approach if you intend to add a device tree id table. > v2: > - Adapted KConfig text using the suggestions from v1 by Nuno Sá and Andy > Shevchenko > > v1: https://lore.kernel.org/all/20260805183733.1000550-1-nico.antinori.7@gmail.com/T/#u
On Mon, Aug 10, 2026 at 11:36:48PM -0300, Marcelo Schmitt wrote: > On 08/10, Nicolás Antinori wrote: ... > David's comment about the IIO device name sounds appropriate. > The am2315 driver might use a chip_info struct to hold the name of each specific design. > There are many drivers in IIO that already have such things. > drivers/iio/accel/adxl372_i2c.c is one example. > > An alternative might be to use the device id. > > const struct i2c_device_id *id = i2c_client_get_device_id(client); > ... > > indio_dev->name = id->name; > > Not sure if the second option works well for both i2c and dt (probably not), so > I'd suggest the chip_info approach if you intend to add a device tree id table. Indeed, we suggest chip_info for the more robust approach when name is provided via string literals independently on the ID tables (as there maybe same ID in the tables for the slightly different devices that may be autodetected runtime, or different IDs for the same or fully compatible component; the chip_info works for the latter case). -- With Best Regards, Andy Shevchenko
On Mon Aug 10, 2026 at 4:28 PM -03, David Lechner wrote: > On 8/10/26 1:32 PM, Nicolás Antinori wrote: >> The AM2320 is fully compatible with the AM2315 sensor in terms of I2C >> communication protocol and measurement conversions. >> >> Add the "am2320" entry to the i2c_device_id table. > > Interesting. No devicetree bindings for this one? What kind of > system is it on? > I am testing this on a Raspberry Pi 3b mounted on a protoboard. On Tue Aug 11, 2026 at 4:38 AM -03, Andy Shevchenko wrote: > On Mon, Aug 10, 2026 at 11:36:48PM -0300, Marcelo Schmitt wrote: >> On 08/10, Nicolás Antinori wrote: > > ... > >> David's comment about the IIO device name sounds appropriate. >> The am2315 driver might use a chip_info struct to hold the name of each specific design. >> There are many drivers in IIO that already have such things. >> drivers/iio/accel/adxl372_i2c.c is one example. >> >> An alternative might be to use the device id. >> >> const struct i2c_device_id *id = i2c_client_get_device_id(client); >> ... >> >> indio_dev->name = id->name; >> >> Not sure if the second option works well for both i2c and dt (probably not), so >> I'd suggest the chip_info approach if you intend to add a device tree id table. > > Indeed, we suggest chip_info for the more robust approach when name is provided > via string literals independently on the ID tables (as there maybe same ID in > the tables for the slightly different devices that may be autodetected runtime, > or different IDs for the same or fully compatible component; the chip_info works > for the latter case). Thank you all for the suggestions. I am going to try to implement chip_info struct. I'll wait a little bit to send the v3 in case there are some more comments on this version. Regards, Nicolás
On 8/11/26 10:12 AM, Nicolás Antinori wrote: > On Mon Aug 10, 2026 at 4:28 PM -03, David Lechner wrote: >> On 8/10/26 1:32 PM, Nicolás Antinori wrote: >>> The AM2320 is fully compatible with the AM2315 sensor in terms of I2C >>> communication protocol and measurement conversions. >>> >>> Add the "am2320" entry to the i2c_device_id table. >> >> Interesting. No devicetree bindings for this one? What kind of >> system is it on? >> > > I am testing this on a Raspberry Pi 3b mounted on a protoboard. How do you tell the RPi to bind the driver? Since Raspberry Pi is ARM-based, usually we would use devicetree overlay to do this, which would mean that we should write a dt-bindings .yaml file for these chips.
On Tue Aug 11, 2026 at 12:49 PM -03, David Lechner wrote: > On 8/11/26 10:12 AM, Nicolás Antinori wrote: >> On Mon Aug 10, 2026 at 4:28 PM -03, David Lechner wrote: >>> On 8/10/26 1:32 PM, Nicolás Antinori wrote: >>>> The AM2320 is fully compatible with the AM2315 sensor in terms of I2C >>>> communication protocol and measurement conversions. >>>> >>>> Add the "am2320" entry to the i2c_device_id table. >>> >>> Interesting. No devicetree bindings for this one? What kind of >>> system is it on? >>> >> >> I am testing this on a Raspberry Pi 3b mounted on a protoboard. > > How do you tell the RPi to bind the driver? > > Since Raspberry Pi is ARM-based, usually we would use devicetree > overlay to do this, which would mean that we should write a > dt-bindings .yaml file for these chips. I do it manually. I use that RPi for development, at the moment the kernel I am using is 7.2.0-rc6-v8+ with CONFIG_AM2315=m. When I need to use the AM2320 I modprobe it with: $ sudo modprobe am2315 And then $ sudo bash -c "echo am2315 0x5c > /sys/bus/i2c/devices/i2c-1/new_device" (With the modifications I made ... echo am2320 ... works as well) The pins for i2c I am using are GPIO 2 (SDA) and GPIO 3 (SCL). If a dt-binding yaml is needed I can send another patch with it!
On 8/11/26 12:58 PM, Nicolás Antinori wrote: > On Tue Aug 11, 2026 at 12:49 PM -03, David Lechner wrote: >> On 8/11/26 10:12 AM, Nicolás Antinori wrote: >>> On Mon Aug 10, 2026 at 4:28 PM -03, David Lechner wrote: >>>> On 8/10/26 1:32 PM, Nicolás Antinori wrote: >>>>> The AM2320 is fully compatible with the AM2315 sensor in terms of I2C >>>>> communication protocol and measurement conversions. >>>>> >>>>> Add the "am2320" entry to the i2c_device_id table. >>>> >>>> Interesting. No devicetree bindings for this one? What kind of >>>> system is it on? >>>> >>> >>> I am testing this on a Raspberry Pi 3b mounted on a protoboard. >> >> How do you tell the RPi to bind the driver? >> >> Since Raspberry Pi is ARM-based, usually we would use devicetree >> overlay to do this, which would mean that we should write a >> dt-bindings .yaml file for these chips. > > I do it manually. > > I use that RPi for development, at the moment the kernel I am using is > 7.2.0-rc6-v8+ with CONFIG_AM2315=m. When I need to use the AM2320 I > modprobe it with: > > $ sudo modprobe am2315 > > And then > > $ sudo bash -c "echo am2315 0x5c > /sys/bus/i2c/devices/i2c-1/new_device" > > (With the modifications I made ... echo am2320 ... works as well) > The pins for i2c I am using are GPIO 2 (SDA) and GPIO 3 (SCL). > > If a dt-binding yaml is needed I can send another patch with it! > > Yes please. It will make it easier for others to use as well.
On Tue, 11 Aug 2026 13:06:50 -0500 David Lechner <dlechner@baylibre.com> wrote: > On 8/11/26 12:58 PM, Nicolás Antinori wrote: > > On Tue Aug 11, 2026 at 12:49 PM -03, David Lechner wrote: > >> On 8/11/26 10:12 AM, Nicolás Antinori wrote: > >>> On Mon Aug 10, 2026 at 4:28 PM -03, David Lechner wrote: > >>>> On 8/10/26 1:32 PM, Nicolás Antinori wrote: > >>>>> The AM2320 is fully compatible with the AM2315 sensor in terms of I2C > >>>>> communication protocol and measurement conversions. > >>>>> > >>>>> Add the "am2320" entry to the i2c_device_id table. > >>>> > >>>> Interesting. No devicetree bindings for this one? What kind of > >>>> system is it on? > >>>> > >>> > >>> I am testing this on a Raspberry Pi 3b mounted on a protoboard. > >> > >> How do you tell the RPi to bind the driver? > >> > >> Since Raspberry Pi is ARM-based, usually we would use devicetree > >> overlay to do this, which would mean that we should write a > >> dt-bindings .yaml file for these chips. > > > > I do it manually. > > > > I use that RPi for development, at the moment the kernel I am using is > > 7.2.0-rc6-v8+ with CONFIG_AM2315=m. When I need to use the AM2320 I > > modprobe it with: > > > > $ sudo modprobe am2315 > > > > And then > > > > $ sudo bash -c "echo am2315 0x5c > /sys/bus/i2c/devices/i2c-1/new_device" > > > > (With the modifications I made ... echo am2320 ... works as well) > > The pins for i2c I am using are GPIO 2 (SDA) and GPIO 3 (SCL). > > > > If a dt-binding yaml is needed I can send another patch with it! > > > > > > Yes please. It will make it easier for others to use as well. I think (from a quick bit of googling) that these two parts are at least 'kind of' the same thing with different packaging. The name is a nice to have and given the packaging may I guess affect the signal and how it is used it probably makes sense to add it. They only have 4 pins. Power, ground, SCL and SDA. So it is a rare device simple enough that I think an entry in trivial-devices.yaml is probably sufficient. Ideally add an of_device_id table, even though this will work fine by the fallback path that uses the i2c_device_id table Jonathan >
On Wed Aug 12, 2026 at 1:43 AM -03, Jonathan Cameron wrote: > On Tue, 11 Aug 2026 13:06:50 -0500 > David Lechner <dlechner@baylibre.com> wrote: > >> On 8/11/26 12:58 PM, Nicolás Antinori wrote: >> > On Tue Aug 11, 2026 at 12:49 PM -03, David Lechner wrote: >> >> On 8/11/26 10:12 AM, Nicolás Antinori wrote: >> >>> On Mon Aug 10, 2026 at 4:28 PM -03, David Lechner wrote: >> >>>> On 8/10/26 1:32 PM, Nicolás Antinori wrote: >> >>>>> The AM2320 is fully compatible with the AM2315 sensor in terms of I2C >> >>>>> communication protocol and measurement conversions. >> >>>>> >> >>>>> Add the "am2320" entry to the i2c_device_id table. >> >>>> >> >>>> Interesting. No devicetree bindings for this one? What kind of >> >>>> system is it on? >> >>>> >> >>> >> >>> I am testing this on a Raspberry Pi 3b mounted on a protoboard. >> >> >> >> How do you tell the RPi to bind the driver? >> >> >> >> Since Raspberry Pi is ARM-based, usually we would use devicetree >> >> overlay to do this, which would mean that we should write a >> >> dt-bindings .yaml file for these chips. >> > >> > I do it manually. >> > >> > I use that RPi for development, at the moment the kernel I am using is >> > 7.2.0-rc6-v8+ with CONFIG_AM2315=m. When I need to use the AM2320 I >> > modprobe it with: >> > >> > $ sudo modprobe am2315 >> > >> > And then >> > >> > $ sudo bash -c "echo am2315 0x5c > /sys/bus/i2c/devices/i2c-1/new_device" >> > >> > (With the modifications I made ... echo am2320 ... works as well) >> > The pins for i2c I am using are GPIO 2 (SDA) and GPIO 3 (SCL). >> > >> > If a dt-binding yaml is needed I can send another patch with it! >> > >> > >> >> Yes please. It will make it easier for others to use as well. > > I think (from a quick bit of googling) that these two parts are > at least 'kind of' the same thing with different packaging. > The name is a nice to have and given the packaging may I guess > affect the signal and how it is used it probably makes sense > to add it. > > They only have 4 pins. Power, ground, SCL and SDA. So it > is a rare device simple enough that I think an entry in trivial-devices.yaml > is probably sufficient. > > Ideally add an of_device_id table, even though this will work fine > by the fallback path that uses the i2c_device_id table > > Jonathan > >> Thank you all for the feedback. I've added of_device_id table, chip_data struct (and assign the name from there), and added "aosong,am2315" and "aosong,am2320" to trivial-devices.yml. I'll wait a few days to send v3 in case something else comes up.
On 8/10/26 1:32 PM, Nicolás Antinori wrote:
> The AM2320 is fully compatible with the AM2315 sensor in terms of I2C
> communication protocol and measurement conversions.
>
> Add the "am2320" entry to the i2c_device_id table.
Interesting. No devicetree bindings for this one? What kind of
system is it on?
>
> Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
> ---
> v2:
> - Adapted KConfig text using the suggestions from v1 by Nuno Sá and Andy
> Shevchenko
>
> v1: https://lore.kernel.org/all/20260805183733.1000550-1-nico.antinori.7@gmail.com/T/#u
>
> drivers/iio/humidity/Kconfig | 8 +++++---
> drivers/iio/humidity/am2315.c | 3 ++-
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
> index 54f11f000b6f..10598a0b15bc 100644
> --- a/drivers/iio/humidity/Kconfig
> +++ b/drivers/iio/humidity/Kconfig
> @@ -5,13 +5,15 @@
> menu "Humidity sensors"
>
> config AM2315
> - tristate "Aosong AM2315 relative humidity and temperature sensor"
> + tristate "Aosong AM2315 and similar relative humidity and temperature sensor"
> depends on I2C
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> help
> - If you say yes here you get support for the Aosong AM2315
> - relative humidity and ambient temperature sensor.
> + If you say yes here you get support for the Aosong relative
> + humidity and ambient temperature sensors:
> + - AM2315
> + - AM2320
>
> This driver can also be built as a module. If so, the module will
> be called am2315.
> diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
> index f29baa251f9f..5bce5eec45cc 100644
> --- a/drivers/iio/humidity/am2315.c
> +++ b/drivers/iio/humidity/am2315.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Aosong AM2315 relative humidity and temperature
> + * Aosong AM2315 and similar relative humidity and temperature
> *
> * Copyright (c) 2016, Intel Corporation.
> *
> @@ -251,6 +251,7 @@ static int am2315_probe(struct i2c_client *client)
>
> static const struct i2c_device_id am2315_i2c_id[] = {
> { .name = "am2315" },
> + { .name = "am2320" },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, am2315_i2c_id);
> --
> 2.47.3
>
Currently, the driver sets `indio_dev->name = AM2315_DRIVER_NAME;`
Usually, when there is more than one chip supported in a driver, we
want this to be the the name of the actual chip.
(And we usually try to avoid DRIVER_NAME macros so removing that
would be a welcome change.)
On Mon, Aug 10, 2026 at 03:32:31PM -0300, Nicolás Antinori wrote: > The AM2320 is fully compatible with the AM2315 sensor in terms of I2C > communication protocol and measurement conversions. > > Add the "am2320" entry to the i2c_device_id table. I haven't checked the datasheet, but code wise LGTM, Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.