[PATCH v2 0/2] iio: temperature: Add support for the STS30 temperature sensor

[PATCH v2 0/2] iio: temperature: Add support for the STS30 temperature sensor

[Maxwell Doose]

Hi all,

This patch series adds support for the Sensirion STS30 temperature
sensor family. This driver currently supports non clock stretched single
shot measurements.

Given there were very little issues found with the v1 submission, I've
decided to make this a regular patch series rather than an RFC patch.

Changes since v1:
* whole series:
- Squashed MAINTAINERS updates into both the dt-bindings commit and the
  driver commit.

* dt-bindings:
- Added ALERT pin as an interrupt and in the examples.

* driver:
- Fixed a mixup between the clock-stretched and non-clock stretched
  commands.
- Fixed an issue where the return value of sts30_reset() was ignored.
- Removed redundant "Author" line at the top.
- Added comment at the top for the formula used to calculate the
temperature in Celsius alongside a macro.
- Added a dedicated macro for the temperature reading size.
- Separated the generic linux headers from the iio specific headers.
- Removed kernel.h from includes.
- Removed unneeded comments.
- Used named initializers for sts30_id and moved above _probe().

Maxwell Doose (2):
  dt-bindings: iio: temperature: Add STS30 devicetree bindings
  iio: temperature: Add STS30 temperature sensor driver

 .../iio/temperature/sensirion,sts30.yaml      |  55 +++
 MAINTAINERS                                   |   6 +
 drivers/iio/temperature/Kconfig               |  11 +
 drivers/iio/temperature/Makefile              |   1 +
 drivers/iio/temperature/sts30.c               | 329 ++++++++++++++++++
 5 files changed, 402 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
 create mode 100644 drivers/iio/temperature/sts30.c

-- 
2.54.0

[PATCH v2 1/2] dt-bindings: iio: temperature: Add STS30 devicetree bindings

[Maxwell Doose]

Add the devicetree bindings for the STS30 family of temperature sensors.
The STS30 family of sensors includes the STS30, STS31, and STS35.

All devices in the STS30 family share the same commands, timings, etc.
The only difference between them is their measurement accuracy and
tolerance.

Additionally add MAINTAINERS entry for the driver.

Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
Changes since v1:
- Squashed parts of the MAINTAINERS commit into this commit.
- Added ALERT pin as an interrupt and in the examples.

 .../iio/temperature/sensirion,sts30.yaml      | 55 +++++++++++++++++++
 MAINTAINERS                                   |  5 ++
 2 files changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml

diff --git a/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml b/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
new file mode 100644
index 000000000000..9bb0f04795d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/sensirion,sts30.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STS30, STS31, and STS35 temperature iio sensors
+
+maintainers:
+  - Maxwell Doose <m32285159@gmail.com>
+
+description: |
+  Family of digital temperature sensors from Sensirion with I2C interface.
+  All devices are compatible with each other, their only differences are
+  their levels of accuracy.
+
+  Datasheet available at:
+  https://sensirion.com/media/documents/1DA31AFD/65D613A8/Datasheet_STS3x_DIS.pdf
+
+properties:
+  compatible:
+    enum:
+      - sensirion,sts30
+      - sensirion,sts31
+      - sensirion,sts35
+
+  reg:
+    maxItems: 1
+
+  vdd-supply: true
+
+  interrupts:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        temperature@4a {
+            compatible = "sensirion,sts30";
+            reg = <0x4a>;
+            vdd-supply = <&reg_3v3>;
+            interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index d95d3ef77773..7f94b8cac3e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24487,6 +24487,11 @@ F:	drivers/iio/chemical/sps30.c
 F:	drivers/iio/chemical/sps30_i2c.c
 F:	drivers/iio/chemical/sps30_serial.c
 
+SENSIRION STS30 TEMPERATURE SENSOR DRIVER
+M:	Maxwell Doose <m32285159@gmail.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
+
 SERIAL DEVICE BUS
 M:	Rob Herring <robh@kernel.org>
 L:	linux-serial@vger.kernel.org
-- 
2.54.0

[PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver

[Maxwell Doose]

Add a driver for the Sensirion STS30 family of temperature sensor
drivers over I2C. The STS30 family of sensors includes the STS30, STS31,
and STS35, all of which are supported by this driver, since they all
share the same commands, etc. and only differ in accuracy and tolerance.

The driver currently supports single-shot non-clock stretched readings,
by using a specified delay based on the repeatability/delay specified
by the user. The repeatability/delay can be changed at any time through
sysfs.

Additionally add Kconfig and Makefile entries for the driver as well as
a MAINTAINERS entry.

Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
Changes since v1:
- Squashed parts of the MAINTAINERS commit into this commit.
- Fixed a mixup between the clock-stretched and non-clock stretched
  commands.
- Fixed an issue where the return value of sts30_reset() was ignored.
- Removed redundant "Author" line at the top.
- Added comment at the top for the formula used to calculate the
temperature in Celsius alongside a macro.
- Added a dedicated macro for the temperature reading size.
- Separated the generic linux headers from the iio specific headers.
- Removed kernel.h from includes.
- Removed unneeded comments.
- Used named initializers for sts30_id and moved above _probe().

 MAINTAINERS                      |   1 +
 drivers/iio/temperature/Kconfig  |  11 ++
 drivers/iio/temperature/Makefile |   1 +
 drivers/iio/temperature/sts30.c  | 329 +++++++++++++++++++++++++++++++
 4 files changed, 342 insertions(+)
 create mode 100644 drivers/iio/temperature/sts30.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f94b8cac3e2..6bb361ac213f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24491,6 +24491,7 @@ SENSIRION STS30 TEMPERATURE SENSOR DRIVER
 M:	Maxwell Doose <m32285159@gmail.com>
 S:	Maintained
 F:	Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
+F:	drivers/iio/temperature/sts30.c
 
 SERIAL DEVICE BUS
 M:	Rob Herring <robh@kernel.org>
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 9328b2250ace..c23a9c40c725 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -88,6 +88,17 @@ config MLX90635
 	  This driver can also be built as a module. If so, the module will
 	  be called mlx90635.
 
+config STS30
+	tristate "STS30/STS31/STS35 temperature sensor"
+	depends on I2C
+	select CRC8
+	help
+	  If you say yes here you get support for the Sensirion STS30,
+	  STS31, and STS35 temperature sensors over I2C.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called sts30.
+
 config TMP006
 	tristate "TMP006 infrared thermopile sensor"
 	depends on I2C
diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
index 07d6e65709f7..9c9bf8d1b70e 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_MCP9600) += mcp9600.o
 obj-$(CONFIG_MLX90614) += mlx90614.o
 obj-$(CONFIG_MLX90632) += mlx90632.o
 obj-$(CONFIG_MLX90632) += mlx90635.o
+obj-$(CONFIG_STS30) += sts30.o
 obj-$(CONFIG_TMP006) += tmp006.o
 obj-$(CONFIG_TMP007) += tmp007.o
 obj-$(CONFIG_TMP117) += tmp117.o
diff --git a/drivers/iio/temperature/sts30.c b/drivers/iio/temperature/sts30.c
new file mode 100644
index 000000000000..dcfe3435ae5a
--- /dev/null
+++ b/drivers/iio/temperature/sts30.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Maxwell Doose
+ *
+ * Sensirion STS30 temperature sensor driver
+ *
+ * Datasheet: https://sensirion.com/media/documents/1DA31AFD/65D613A8/Datasheet_STS3x_DIS.pdf
+ */
+
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/crc8.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/types.h>
+
+/*
+ * STS30 measurement to Celsius conversion formula:
+ *
+ * T = -45 + 175(S[T]/(2^16 - 1)
+ *
+ * Where S[T] is the raw sensor output. We use this formula to calculate the offset.
+ * Using this we can calculate the offset to be -16852.
+ *
+ * See section 4.12 in the datasheet for more info.
+ */
+#define STS30_TEMP_OFFSET -16852
+
+/* Amount of bytes received from the STS30 after a read command */
+#define STS30_MEAS_SIZE 3
+
+/* Size of the temperature measurement data received after a read command */
+#define STS30_TEMP_MEAS_SIZE 2
+
+#define STS30_COMMAND_READ_HIGH_REPEAT 0x2400
+#define STS30_COMMAND_READ_MED_REPEAT 0x240B
+#define STS30_COMMAND_READ_LOW_REPEAT 0x2416
+
+#define STS30_COMMAND_RESET 0x30A2
+
+/*
+ * sts30 includes a CRC8 checksum at the end of its i2c responses. The polynomial
+ * is used to generate the CRC8 table and the seed is the starting value.
+ */
+#define STS30_CRC8_POLYNOMIAL 0x31
+#define STS30_CRC8_SEED 0xFF
+
+DECLARE_CRC8_TABLE(sts30_crc_table);
+
+enum sts30_read_delays {
+	STS30_REPEAT_LOW = 4500,
+	STS30_REPEAT_MED = 6000,
+	STS30_REPEAT_HIGH = 15000
+};
+
+struct sts30_data {
+	struct i2c_client *client;
+	struct mutex lock; /* Mutex for serialized communication on the i2c bus */
+	/*
+	 * sts30 has three potential repeatability/measurement durations. We need to
+	 * account for them while reading the i2c bus.
+	 *
+	 * See section 2.2 in the datasheet for more info on processing times.
+	 */
+	enum sts30_read_delays delay;
+};
+
+static int sts30_verify_crc8(struct sts30_data *data, u8 buf[STS30_MEAS_SIZE])
+{
+	int crc;
+
+	crc = crc8(sts30_crc_table, buf, STS30_TEMP_MEAS_SIZE, STS30_CRC8_SEED);
+	if (crc != buf[2]) {
+		dev_err(&data->client->dev, "Expected CRC8 value of 0x%02x, got 0x%02x\n",
+			buf[2], crc);
+		return -EIO;
+	}
+
+	return 0;
+}
+
+static int sts30_read(struct sts30_data *data, u16 command, u16 *val)
+{
+	u8 buf[STS30_MEAS_SIZE];
+	u8 tmp[2];
+	int ret;
+
+	put_unaligned_be16(command, tmp);
+
+	ret = i2c_master_send(data->client, tmp, sizeof(tmp));
+	if (ret < 0)
+		return ret;
+	if (ret != sizeof(tmp))
+		return -EIO;
+
+	fsleep(data->delay);
+
+	ret = i2c_master_recv(data->client, buf, sizeof(buf));
+	if (ret < 0)
+		return ret;
+	if (ret != sizeof(buf))
+		return -EIO;
+
+	*val = get_unaligned_be16(buf);
+
+	ret = sts30_verify_crc8(data, buf);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int sts30_write(struct sts30_data *data, u16 command)
+{
+	u8 buf[2];
+	int ret;
+
+	put_unaligned_be16(command, buf);
+
+	ret = i2c_master_send(data->client, buf, sizeof(buf));
+	if (ret < 0)
+		return ret;
+	if (ret != sizeof(buf))
+		return -EIO;
+
+	return 0;
+}
+
+static int sts30_reset(struct sts30_data *data)
+{
+	int ret;
+
+	guard(mutex)(&data->lock);
+
+	ret = sts30_write(data, STS30_COMMAND_RESET);
+	if (ret)
+		return ret;
+
+	/*
+	 * Datasheet dictates that the maximum time for a soft reset is 1.5ms.
+	 *
+	 * See section 2.2 for more info on timing.
+	 */
+	fsleep(1500);
+
+	return 0;
+}
+
+static int sts30_read_raw(struct iio_dev *indio_dev,
+			  struct iio_chan_spec const *chan, int *val, int *val2,
+			  long mask)
+{
+	struct sts30_data *data = iio_priv(indio_dev);
+	int ret;
+	u16 tmp;
+
+	guard(mutex)(&data->lock);
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		switch (data->delay) {
+		case STS30_REPEAT_LOW:
+			ret = sts30_read(data, STS30_COMMAND_READ_LOW_REPEAT, &tmp);
+			break;
+		case STS30_REPEAT_MED:
+			ret = sts30_read(data, STS30_COMMAND_READ_MED_REPEAT, &tmp);
+			break;
+		case STS30_REPEAT_HIGH:
+			ret = sts30_read(data, STS30_COMMAND_READ_HIGH_REPEAT, &tmp);
+			break;
+		default:
+			dev_warn(&data->client->dev, "Repeatability state corrupted, got: %d\n",
+				 data->delay);
+			return -EINVAL;
+		}
+
+		if (ret)
+			return ret;
+
+		*val = tmp;
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_OFFSET:
+		*val = STS30_TEMP_OFFSET;
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		*val = 175000;
+		*val2 = 65535;
+		return IIO_VAL_FRACTIONAL;
+	case IIO_CHAN_INFO_INT_TIME:
+		*val = 0;
+		*val2 = data->delay;
+		return IIO_VAL_INT_PLUS_MICRO;
+	default:
+		return -EINVAL;
+	}
+}
+
+static int sts30_write_raw(struct iio_dev *indio_dev,
+			   struct iio_chan_spec const *chan, int val, int val2,
+			   long mask)
+{
+	struct sts30_data *data = iio_priv(indio_dev);
+
+	if (val)
+		return -EINVAL;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_INT_TIME: {
+		guard(mutex)(&data->lock);
+
+		switch (val2) {
+		case STS30_REPEAT_LOW:
+			data->delay = STS30_REPEAT_LOW;
+			break;
+		case STS30_REPEAT_MED:
+			data->delay = STS30_REPEAT_MED;
+			break;
+		case STS30_REPEAT_HIGH:
+			data->delay = STS30_REPEAT_HIGH;
+			break;
+		default:
+			return -EINVAL;
+		}
+
+		return 0;
+	}
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info sts30_info = {
+	.read_raw = sts30_read_raw,
+	.write_raw = sts30_write_raw
+};
+
+static const struct iio_chan_spec sts30_channels[] = {
+	{
+		.type = IIO_TEMP,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_OFFSET) |
+				      BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_INT_TIME)
+	},
+};
+
+static int sts30_probe(struct i2c_client *client)
+{
+	struct iio_dev *indio_dev;
+	struct sts30_data *data;
+	int ret;
+
+	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
+	if (!indio_dev)
+		return -ENOMEM;
+
+	indio_dev->name = client->name;
+	indio_dev->info = &sts30_info;
+	indio_dev->channels = sts30_channels;
+	indio_dev->num_channels = ARRAY_SIZE(sts30_channels);
+	indio_dev->modes = INDIO_DIRECT_MODE;
+
+	data = iio_priv(indio_dev);
+	data->client = client;
+	data->delay = STS30_REPEAT_HIGH;
+
+	ret = devm_mutex_init(&client->dev, &data->lock);
+	if (ret)
+		return ret;
+
+	i2c_set_clientdata(client, indio_dev);
+
+	ret = sts30_reset(data);
+	if (ret)
+		return ret;
+
+	return devm_iio_device_register(&client->dev, indio_dev);
+}
+
+static const struct i2c_device_id sts30_id[] = {
+	{ .name = "sts30" },
+	{ .name = "sts31" },
+	{ .name = "sts35" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, sts30_id);
+
+static const struct of_device_id sts30_of_match[] = {
+	{ .compatible = "sensirion,sts30" },
+	{ .compatible = "sensirion,sts31" },
+	{ .compatible = "sensirion,sts35" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, sts30_of_match);
+
+static struct i2c_driver sts30_driver = {
+	.driver = {
+		.name = "sts30",
+		.of_match_table = sts30_of_match,
+	},
+	.probe = sts30_probe,
+	.id_table = sts30_id,
+};
+
+static int __init sts30_init(void)
+{
+	crc8_populate_msb(sts30_crc_table, STS30_CRC8_POLYNOMIAL);
+
+	return i2c_add_driver(&sts30_driver);
+}
+module_init(sts30_init);
+
+static void __exit sts30_exit(void)
+{
+	i2c_del_driver(&sts30_driver);
+}
+module_exit(sts30_exit);
+
+MODULE_AUTHOR("Maxwell Doose <m32285159@gmail.com>");
+MODULE_DESCRIPTION("Sensirion STS30 temperature sensor driver");
+MODULE_LICENSE("GPL");
-- 
2.54.0

Re: [PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver

[Joshua Crofts]

On Sat, 20 Jun 2026 19:46:24 -0500
Maxwell Doose <m32285159@gmail.com> wrote:
> +#include <linux/array_size.h>
> +#include <linux/bits.h>
> +#include <linux/cleanup.h>
> +#include <linux/crc8.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/export.h>
> +#include <linux/i2c.h>

I am a numpty as I also forgot to mention a missing
mod_devicetable.h header.

-- 
Kind regards

CJD

Re: [PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver

[Maxwell Doose]

On Sun, Jun 21, 2026 at 1:33 PM Joshua Crofts <joshua.crofts1@gmail.com> wrote:
>
> On Sat, 20 Jun 2026 19:46:24 -0500
> Maxwell Doose <m32285159@gmail.com> wrote:
> > +#include <linux/array_size.h>
> > +#include <linux/bits.h>
> > +#include <linux/cleanup.h>
> > +#include <linux/crc8.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/errno.h>
> > +#include <linux/export.h>
> > +#include <linux/i2c.h>
>
> I am a numpty as I also forgot to mention a missing
> mod_devicetable.h header.
>

D'oh, I ought to look at my includes a lot more closely as well.

Re: [PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver

[Maxwell Doose]

On Sun, Jun 21, 2026 at 7:05 PM Maxwell Doose <m32285159@gmail.com> wrote:
>
> On Sun, Jun 21, 2026 at 1:33 PM Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> >
> > On Sat, 20 Jun 2026 19:46:24 -0500
> > Maxwell Doose <m32285159@gmail.com> wrote:
> > > +#include <linux/array_size.h>
> > > +#include <linux/bits.h>
> > > +#include <linux/cleanup.h>
> > > +#include <linux/crc8.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/device.h>
> > > +#include <linux/errno.h>
> > > +#include <linux/export.h>
> > > +#include <linux/i2c.h>
> >
> > I am a numpty as I also forgot to mention a missing
> > mod_devicetable.h header.
> >
>
> D'oh, I ought to look at my includes a lot more closely as well.

Forgot to mention, I'll be away for 2 weeks starting tomorrow so it'll
have to wait :(

Re: [PATCH v2 0/2] iio: temperature: Add support for the STS30 temperature sensor

[David Lechner]

On 6/20/26 7:46 PM, Maxwell Doose wrote:
> Hi all,
> 
> This patch series adds support for the Sensirion STS30 temperature
> sensor family. This driver currently supports non clock stretched single
> shot measurements.
> 
> Given there were very little issues found with the v1 submission, I've
> decided to make this a regular patch series rather than an RFC patch.

You should wait at least one week for feedback on a new driver before
submitting the next revision.

Given that you said in v1 that don't actually have the hardware, I am not
going to review this. We are getting more patches than I can keep up with
already.

> 
> Changes since v1:
> * whole series:
> - Squashed MAINTAINERS updates into both the dt-bindings commit and the
>   driver commit.
> 

Re: [PATCH v2 0/2] iio: temperature: Add support for the STS30 temperature sensor

[Maxwell Doose]

On Mon, Jun 22, 2026 at 10:45 AM David Lechner <dlechner@baylibre.com> wrote:
>
> On 6/20/26 7:46 PM, Maxwell Doose wrote:
> > Hi all,
> >
> > This patch series adds support for the Sensirion STS30 temperature
> > sensor family. This driver currently supports non clock stretched single
> > shot measurements.
> >
> > Given there were very little issues found with the v1 submission, I've
> > decided to make this a regular patch series rather than an RFC patch.
>
> You should wait at least one week for feedback on a new driver before
> submitting the next revision.
>
> Given that you said in v1 that don't actually have the hardware, I am not
> going to review this. We are getting more patches than I can keep up with
> already.
>

Fair enough, I'll be away until 4 July anyways.

Re: [PATCH v2 1/2] dt-bindings: iio: temperature: Add STS30 devicetree bindings

[Rob Herring (Arm)]

On Sat, 20 Jun 2026 19:46:23 -0500, Maxwell Doose wrote:
> Add the devicetree bindings for the STS30 family of temperature sensors.
> The STS30 family of sensors includes the STS30, STS31, and STS35.
> 
> All devices in the STS30 family share the same commands, timings, etc.
> The only difference between them is their measurement accuracy and
> tolerance.
> 
> Additionally add MAINTAINERS entry for the driver.
> 
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> ---
> Changes since v1:
> - Squashed parts of the MAINTAINERS commit into this commit.
> - Added ALERT pin as an interrupt and in the examples.
> 
>  .../iio/temperature/sensirion,sts30.yaml      | 55 +++++++++++++++++++
>  MAINTAINERS                                   |  5 ++
>  2 files changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver

[Jonathan Cameron]

On Sun, 21 Jun 2026 19:09:11 -0500
Maxwell Doose <m32285159@gmail.com> wrote:

> On Sun, Jun 21, 2026 at 7:05 PM Maxwell Doose <m32285159@gmail.com> wrote:
> >
> > On Sun, Jun 21, 2026 at 1:33 PM Joshua Crofts <joshua.crofts1@gmail.com> wrote:  
> > >
> > > On Sat, 20 Jun 2026 19:46:24 -0500
> > > Maxwell Doose <m32285159@gmail.com> wrote:  
> > > > +#include <linux/array_size.h>
> > > > +#include <linux/bits.h>
> > > > +#include <linux/cleanup.h>
> > > > +#include <linux/crc8.h>
> > > > +#include <linux/delay.h>
> > > > +#include <linux/device.h>
> > > > +#include <linux/errno.h>
> > > > +#include <linux/export.h>
> > > > +#include <linux/i2c.h>  
> > >
> > > I am a numpty as I also forgot to mention a missing
> > > mod_devicetable.h header.
> > >  
> >
> > D'oh, I ought to look at my includes a lot more closely as well.  
> 
> Forgot to mention, I'll be away for 2 weeks starting tomorrow so it'll
> have to wait :(

Don't add mod_devicetable.h.  There is a series from Uwe that splits that header
up and puts the tables different headers. i2c.h is now enough.
(It's causing merge conflicts)

Jonathan

Re: [PATCH v2 1/2] dt-bindings: iio: temperature: Add STS30 devicetree bindings

[Jonathan Cameron]

On Sat, 20 Jun 2026 19:46:23 -0500
Maxwell Doose <m32285159@gmail.com> wrote:

> Add the devicetree bindings for the STS30 family of temperature sensors.
> The STS30 family of sensors includes the STS30, STS31, and STS35.
> 
> All devices in the STS30 family share the same commands, timings, etc.
> The only difference between them is their measurement accuracy and
> tolerance.
Given we don't report accuracy (and reporting less accurate than they
actually are should always be safe if we do add such reporting in future),
I think a fallback compatible to the least accurate is appropriate for
the other two.

> 
> Additionally add MAINTAINERS entry for the driver.
> 
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> ---
> Changes since v1:
> - Squashed parts of the MAINTAINERS commit into this commit.
> - Added ALERT pin as an interrupt and in the examples.
> 
>  .../iio/temperature/sensirion,sts30.yaml      | 55 +++++++++++++++++++
>  MAINTAINERS                                   |  5 ++
>  2 files changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml b/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
> new file mode 100644
> index 000000000000..9bb0f04795d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/temperature/sensirion,sts30.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STS30, STS31, and STS35 temperature iio sensors
> +
> +maintainers:
> +  - Maxwell Doose <m32285159@gmail.com>
> +
> +description: |
> +  Family of digital temperature sensors from Sensirion with I2C interface.
> +  All devices are compatible with each other, their only differences are
> +  their levels of accuracy.
> +
> +  Datasheet available at:
> +  https://sensirion.com/media/documents/1DA31AFD/65D613A8/Datasheet_STS3x_DIS.pdf
> +
> +properties:
> +  compatible:
> +    enum:
> +      - sensirion,sts30
> +      - sensirion,sts31
> +      - sensirion,sts35
> +
> +  reg:
> +    maxItems: 1
> +
> +  vdd-supply: true
> +
> +  interrupts:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        temperature@4a {
> +            compatible = "sensirion,sts30";
> +            reg = <0x4a>;
> +            vdd-supply = <&reg_3v3>;
> +            interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> +        };
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d95d3ef77773..7f94b8cac3e2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -24487,6 +24487,11 @@ F:	drivers/iio/chemical/sps30.c
>  F:	drivers/iio/chemical/sps30_i2c.c
>  F:	drivers/iio/chemical/sps30_serial.c
>  
> +SENSIRION STS30 TEMPERATURE SENSOR DRIVER
> +M:	Maxwell Doose <m32285159@gmail.com>
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
> +
>  SERIAL DEVICE BUS
>  M:	Rob Herring <robh@kernel.org>
>  L:	linux-serial@vger.kernel.org

Re: [PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver

[Jonathan Cameron]

On Sat, 20 Jun 2026 19:46:24 -0500
Maxwell Doose <m32285159@gmail.com> wrote:

> Add a driver for the Sensirion STS30 family of temperature sensor
> drivers over I2C. The STS30 family of sensors includes the STS30, STS31,
> and STS35, all of which are supported by this driver, since they all
> share the same commands, etc. and only differ in accuracy and tolerance.
> 
> The driver currently supports single-shot non-clock stretched readings,
> by using a specified delay based on the repeatability/delay specified
> by the user. The repeatability/delay can be changed at any time through
> sysfs.
> 
> Additionally add Kconfig and Makefile entries for the driver as well as
> a MAINTAINERS entry.
> 
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>

Big question first.  Why IIO? These are fairly basic temperature sensors
which typically means hwmon is more appropriate.  What does it need
that hwmon doesn't provide?

A few other things inline.

> diff --git a/drivers/iio/temperature/sts30.c b/drivers/iio/temperature/sts30.c
> new file mode 100644
> index 000000000000..dcfe3435ae5a
> --- /dev/null
> +++ b/drivers/iio/temperature/sts30.c

> +
> +/* Size of the temperature measurement data received after a read command */
> +#define STS30_TEMP_MEAS_SIZE 2
> +
> +#define STS30_COMMAND_READ_HIGH_REPEAT 0x2400
> +#define STS30_COMMAND_READ_MED_REPEAT 0x240B
> +#define STS30_COMMAND_READ_LOW_REPEAT 0x2416
That smells like two fields in one value.

> +
> +#define STS30_COMMAND_RESET 0x30A2

> +enum sts30_read_delays { 

Name it to indicate unit.

> +	STS30_REPEAT_LOW = 4500,
> +	STS30_REPEAT_MED = 6000,
> +	STS30_REPEAT_HIGH = 15000
> +};
> +

> +static int sts30_read(struct sts30_data *data, u16 command, u16 *val)
> +{
> +	u8 buf[STS30_MEAS_SIZE];
> +	u8 tmp[2];
Might as well make it __be16  then it's aligned.
> +	int ret;
> +
> +	put_unaligned_be16(command, tmp);
> +
> +	ret = i2c_master_send(data->client, tmp, sizeof(tmp));
> +	if (ret < 0)
> +		return ret;
> +	if (ret != sizeof(tmp))
> +		return -EIO;
> +
> +	fsleep(data->delay);
> +
> +	ret = i2c_master_recv(data->client, buf, sizeof(buf));
> +	if (ret < 0)
> +		return ret;
> +	if (ret != sizeof(buf))
> +		return -EIO;
> +
> +	*val = get_unaligned_be16(buf);
> +
> +	ret = sts30_verify_crc8(data, buf);

return sts30_...

> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}

> +
> +static int sts30_read_raw(struct iio_dev *indio_dev,
> +			  struct iio_chan_spec const *chan, int *val, int *val2,
> +			  long mask)
> +{
> +	struct sts30_data *data = iio_priv(indio_dev);
> +	int ret;
> +	u16 tmp;
> +
> +	guard(mutex)(&data->lock);

I'd move this into appropriate scope as the lock isn't needed for
all the const data cases.

> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		switch (data->delay) {
> +		case STS30_REPEAT_LOW:
> +			ret = sts30_read(data, STS30_COMMAND_READ_LOW_REPEAT, &tmp);
> +			break;
> +		case STS30_REPEAT_MED:
> +			ret = sts30_read(data, STS30_COMMAND_READ_MED_REPEAT, &tmp);
> +			break;
> +		case STS30_REPEAT_HIGH:
> +			ret = sts30_read(data, STS30_COMMAND_READ_HIGH_REPEAT, &tmp);
> +			break;
> +		default:
> +			dev_warn(&data->client->dev, "Repeatability state corrupted, got: %d\n",
> +				 data->delay);

Any realistic way this can happen?  If not drop the print.

> +			return -EINVAL;
> +		}
> +
> +		if (ret)
> +			return ret;
> +
> +		*val = tmp;
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_OFFSET:
> +		*val = STS30_TEMP_OFFSET;

These constant cases don't need the lock.

> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = 175000;
> +		*val2 = 65535;
> +		return IIO_VAL_FRACTIONAL;
> +	case IIO_CHAN_INFO_INT_TIME:
> +		*val = 0;
> +		*val2 = data->delay;

Might need the guard - I haven't checked.

> +		return IIO_VAL_INT_PLUS_MICRO;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int sts30_write_raw(struct iio_dev *indio_dev,
> +			   struct iio_chan_spec const *chan, int val, int val2,
> +			   long mask)
> +{
> +	struct sts30_data *data = iio_priv(indio_dev);
> +
> +	if (val)
> +		return -EINVAL;

That is going to be IIO_* specific in the switch - so move it into
the case block.

> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_INT_TIME: {
> +		guard(mutex)(&data->lock);

Given it is taken in all non error paths, I'd lift the guard() up to outside
the switch.

> +
> +		switch (val2) {
> +		case STS30_REPEAT_LOW:
> +			data->delay = STS30_REPEAT_LOW;
> +			break;

Given you are done in each of these, return instead of break.

> +		case STS30_REPEAT_MED:
> +			data->delay = STS30_REPEAT_MED;
> +			break;
> +		case STS30_REPEAT_HIGH:
> +			data->delay = STS30_REPEAT_HIGH;
> +			break;
> +		default:
> +			return -EINVAL;
> +		}
> +
> +		return 0;
> +	}
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static const struct iio_info sts30_info = {
> +	.read_raw = sts30_read_raw,
> +	.write_raw = sts30_write_raw
Missing comma.

Basic rule of these is you can only skip the comma if doing so doesn't create additional
churn when adding new stuff after it.  Two cases are common.
1) Nothing can be added there - true of terminators  {} etc.
2) It's one line anyway so any change will result in that line changing
   and hence no advantage in having the comma.

> +};
> +
> +static const struct iio_chan_spec sts30_channels[] = {
> +	{
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_OFFSET) |
> +				      BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_INT_TIME)

No obvious gain in going longer than 80 chars here.  Just have one per line.
Also the , is missing

> +	},
> +};
> +
> +static int sts30_probe(struct i2c_client *client)
> +{
> +	struct iio_dev *indio_dev;
> +	struct sts30_data *data;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	indio_dev->name = client->name;

I'd prefer to see that done via device specific chip_info structures.
IIRC there are some paths in which client->name might not be set appropriately.
For ACPI PRP0001 (the route that uses compatible) it is set to the vendor stripped
name so that is fine, but should we ever add 'proper' ACPI support it will be the
_HID which isn't what we want.

Anyhow, normally we avoid thinking about this by getting from the data
rather than the ->name via i2c_get_match_data() and appropriate structures.

> +	indio_dev->info = &sts30_info;
> +	indio_dev->channels = sts30_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(sts30_channels);
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +
> +	data = iio_priv(indio_dev);
> +	data->client = client;
> +	data->delay = STS30_REPEAT_HIGH;
> +
> +	ret = devm_mutex_init(&client->dev, &data->lock);
> +	if (ret)
> +		return ret;
> +
> +	i2c_set_clientdata(client, indio_dev);

Why? I'm not seeing it being used.

> +
> +	ret = sts30_reset(data);
> +	if (ret)
> +		return ret;
> +
> +	return devm_iio_device_register(&client->dev, indio_dev);
> +}

Re: [PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver

[Joshua Crofts]

On Fri, 3 Jul 2026 00:31:59 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> On Sun, 21 Jun 2026 19:09:11 -0500
> Maxwell Doose <m32285159@gmail.com> wrote:
> 
> > On Sun, Jun 21, 2026 at 7:05 PM Maxwell Doose <m32285159@gmail.com> wrote:  
> > >
> > > On Sun, Jun 21, 2026 at 1:33 PM Joshua Crofts <joshua.crofts1@gmail.com> wrote:    
> > > >
> > > > On Sat, 20 Jun 2026 19:46:24 -0500
> > > > Maxwell Doose <m32285159@gmail.com> wrote:    
> > > > > +#include <linux/array_size.h>
> > > > > +#include <linux/bits.h>
> > > > > +#include <linux/cleanup.h>
> > > > > +#include <linux/crc8.h>
> > > > > +#include <linux/delay.h>
> > > > > +#include <linux/device.h>
> > > > > +#include <linux/errno.h>
> > > > > +#include <linux/export.h>
> > > > > +#include <linux/i2c.h>    
> > > >
> > > > I am a numpty as I also forgot to mention a missing
> > > > mod_devicetable.h header.
> > > >    
> > >
> > > D'oh, I ought to look at my includes a lot more closely as well.    
> > 
> > Forgot to mention, I'll be away for 2 weeks starting tomorrow so it'll
> > have to wait :(  
> 
> Don't add mod_devicetable.h.  There is a series from Uwe that splits that header
> up and puts the tables different headers. i2c.h is now enough.
> (It's causing merge conflicts)

Cool, one include less to worry about.

-- 
Kind regards

CJD