Re: [PATCH v2] iio: humidity: am2315: add am2320 to i2c_device_id table
Nicolás Antinori <[email protected]>
| Newsgroups | dev.linux.lists.linux-kernel-mentees,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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