Re: [PATCH v7 3/4] hwmon: (sht3x) Add devicetree support

Re: [PATCH v7 3/4] hwmon: (sht3x) Add devicetree support

[Zaixiang Xu]

On Mon, 13 Jul 2026 08:01:29 +0000, sashiko-bot@kernel.org wrote:
> While reviewing this patch, I noticed a few pre-existing regressions
> in this file that might be worth addressing.
>
> [Severity: Critical]
> This is a pre-existing issue, but does this unaligned memory access
> crash strict-alignment architectures?
[...]
> [Severity: High]
> This isn't a bug introduced by this patch, but does this integer
> arithmetic overflow?

Thanks for the report. All five findings are in pre-existing code and
are not touched by this series, so I would prefer to keep them
separate from the devicetree support here.

I checked the first two: the unaligned access in sht3x_update_client()
(buf + 3 is an odd offset into a byte buffer, so it needs
get_unaligned_be16()), and the limit_write() overflow (temperature is
clamped to 130000, and (130000 + 45000) * 24543 = 4295025000 just
exceeds U32_MAX, so writing the maximum limit wraps the raw
temperature field to 0). Both look real.

I plan to go through all five and send fixes as a separate series
after this one.

Thanks,
Zaixiang

[PATCH v7 0/4] hwmon: (sht3x) Add support for GXCAS GXHT30

[Zaixiang Xu]

This series adds devicetree support to the sht3x driver and support
for the GXCAS GXHT30 humidity and temperature sensor, a drop-in
replacement for the Sensirion SHT30.

Apologies for the long delay since v6.

Changes in v7:
- Model the higher accuracy parts as compatible with the base part
  of their group in the binding: SHT31/SHT35/SHT85 and GXHT30 fall
  back to "sensirion,sht30", STS31/STS32/STS35 fall back to
  "sensirion,sts30", and explain the grouping in the commit message
  (Krzysztof).
- Drop the "gxcas,gxht30" of_device_id entry and the "gxht30"
  i2c_device_id entry: the GXHT30 is handled entirely by the
  "sensirion,sht30" fallback, with no driver changes (Krzysztof).
  Patch 4 now only documents the chip in Documentation/hwmon/
  sht3x.rst and the Kconfig help text, following how SHT85 support
  was documented.
- Start enum sht3x_chips at 1 so the OF match data is never NULL
  and i2c_get_match_data() does not silently fall back to
  i2c_device_id name matching (reported by Sashiko AI review on v6).
- Mention all optional properties in the binding commit message
  (Sashiko AI review on v6).
- Rebase onto hwmon-next to account for the conversion of
  i2c_device_id tables to named initializers.
- Drop the MODULE_AUTHOR addition; authorship is recorded in git.

Changes in v6:
- Drop the trivial-devices.yaml approach from v5; add a dedicated
  binding and a proper of_device_id table. (Guenter)
- Split into 4 patches: vendor prefix, binding, driver DT support,
  GXHT30 support.

Changes in v5:
- Move to trivial-devices.yaml and drop of_match_table (wrong
  approach, reverted in v6).
- Drop wildcards, list specific models.

Changes in v3/v4:
- Standalone YAML binding, split driver changes from binding changes.

Changes in v2:
- Fix placeholder in MODULE_AUTHOR, fix commit message wrapping.

Zaixiang Xu (4):
  dt-bindings: vendor-prefixes: Add GXCAS Technology
  dt-bindings: hwmon: Add Sensirion SHT30 series
  hwmon: (sht3x) Add devicetree support
  hwmon: (sht3x) Document support for GXCAS GXHT30

 .../bindings/hwmon/sensirion,sht30.yaml       | 71 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
 Documentation/hwmon/sht3x.rst                 | 17 ++++-
 drivers/hwmon/Kconfig                         |  5 +-
 drivers/hwmon/sht3x.c                         | 15 +++-
 5 files changed, 103 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml


base-commit: ca078d004cf58137bcf8cb24a8b271397431ba58
-- 
2.34.1

[PATCH v7 3/4] hwmon: (sht3x) Add devicetree support

[Zaixiang Xu]

Add an of_device_id table to support devicetree based instantiation
of the supported sensors.

The devicetree binding models all higher accuracy parts with a
fallback to the base part of their group, so only the two base
compatibles need to be listed. The match data distinguishes the
humidity and temperature parts (SHT3x) from the temperature-only
parts (STS3x), which require different configuration.

Start enum sht3x_chips at 1: with sht3x equal to 0, the OF match
data for the SHT devices would be NULL, causing i2c_get_match_data()
to fall back to i2c_device_id name matching, which fails for
devicetree names. The devices would then only work because the
resulting chip id 0 happens to equal sht3x. Non-zero match data
avoids relying on that coincidence.

Signed-off-by: Zaixiang Xu <zaixiang.xu.dev@gmail.com>
---
 drivers/hwmon/sht3x.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/sht3x.c b/drivers/hwmon/sht3x.c
index c2f6b73aa7f3..6d47cfd340f8 100644
--- a/drivers/hwmon/sht3x.c
+++ b/drivers/hwmon/sht3x.c
@@ -61,7 +61,7 @@ static const unsigned char sht3x_cmd_read_serial_number[]      = { 0x37, 0x80 };
 #define SHT3X_MAX_HUMIDITY     100000
 
 enum sht3x_chips {
-	sht3x,
+	sht3x = 1,
 	sts3x,
 };
 
@@ -939,8 +939,19 @@ static const struct i2c_device_id sht3x_ids[] = {
 
 MODULE_DEVICE_TABLE(i2c, sht3x_ids);
 
+static const struct of_device_id sht3x_of_match[] = {
+	{ .compatible = "sensirion,sht30", .data = (void *)(uintptr_t)sht3x },
+	{ .compatible = "sensirion,sts30", .data = (void *)(uintptr_t)sts3x },
+	{ }
+};
+
+MODULE_DEVICE_TABLE(of, sht3x_of_match);
+
 static struct i2c_driver sht3x_i2c_driver = {
-	.driver.name = "sht3x",
+	.driver = {
+		.name = "sht3x",
+		.of_match_table = sht3x_of_match,
+	},
 	.probe       = sht3x_probe,
 	.id_table    = sht3x_ids,
 };
-- 
2.34.1