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

[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 1/4] dt-bindings: vendor-prefixes: Add GXCAS Technology

[Zaixiang Xu]

Add vendor prefix for Beijing Galaxy-CAS Technology Co., Ltd. (GXCAS).
The prefix was confirmed from the manufacturer's website:
https://www.gxcas.com/en/index.html

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Zaixiang Xu <zaixiang.xu.dev@gmail.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f368e7..6793125d6cc6 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -692,6 +692,8 @@ patternProperties:
     description: Gateworks Corporation
                  use "gateworks" vendor prefix
     deprecated: true
+  "^gxcas,.*":
+    description: Beijing Galaxy-CAS Technology Co., Ltd.
   "^hannstar,.*":
     description: HannStar Display Corporation
   "^haochuangyi,.*":
-- 
2.34.1

Re: [PATCH v7 1/4] dt-bindings: vendor-prefixes: Add GXCAS Technology

[sashiko-bot]

> Add vendor prefix for Beijing Galaxy-CAS Technology Co., Ltd. (GXCAS).
> The prefix was confirmed from the manufacturer's website:
> https://www.gxcas.com/en/index.html
> 
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Zaixiang Xu <zaixiang.xu.dev@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713074559.12196-1-zaixiang.xu.dev@gmail.com?part=1

[PATCH v7 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series

[Zaixiang Xu]

Add a YAML devicetree binding for the Sensirion SHT3x/STS3x sensor
family and the compatible GXCAS GXHT30, with the ALERT interrupt,
nRESET GPIO and VDD supply as optional properties.

The SHT30, SHT31, SHT35 and SHT85 measure humidity and temperature
and differ only in accuracy and packaging, while the STS30, STS31,
STS32 and STS35 are temperature-only parts. Within each group the
parts share the same software interface, so model them with a
fallback to the base part of their group: "sensirion,sht30" for the
SHT parts and "sensirion,sts30" for the STS parts.

The GXCAS GXHT30 is a drop-in replacement for the SHT30 and uses it
as fallback as well.

Signed-off-by: Zaixiang Xu <zaixiang.xu.dev@gmail.com>
---
 .../bindings/hwmon/sensirion,sht30.yaml       | 71 +++++++++++++++++++
 1 file changed, 71 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml
new file mode 100644
index 000000000000..dee0252941c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/sensirion,sht30.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SHT3x and GXCAS GXHT30 humidity and temperature sensors
+
+maintainers:
+  - Zaixiang Xu <zaixiang.xu.dev@gmail.com>
+
+properties:
+  compatible:
+    oneOf:
+      - enum:
+          - sensirion,sht30
+          - sensirion,sts30
+      - items:
+          - enum:
+              - gxcas,gxht30
+              - sensirion,sht31
+              - sensirion,sht35
+              - sensirion,sht85
+          - const: sensirion,sht30
+      - items:
+          - enum:
+              - sensirion,sts31
+              - sensirion,sts32
+              - sensirion,sts35
+          - const: sensirion,sts30
+
+  reg:
+    maxItems: 1
+
+  vdd-supply:
+    description: Regulator that provides power to the VDD pin.
+
+  reset-gpios:
+    maxItems: 1
+    description:
+      GPIO connected to the nRESET pin. Active low.
+
+  interrupts:
+    maxItems: 1
+    description:
+      Interrupt connected to the ALERT pin.
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        humidity-sensor@44 {
+            compatible = "gxcas,gxht30", "sensirion,sht30";
+            reg = <0x44>;
+            vdd-supply = <&vcc_3v3_reg>;
+            reset-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+            interrupt-parent = <&gpio1>;
+            interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
+        };
+    };
-- 
2.34.1

Re: [PATCH v7 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Device tree nodes using the newly defined compatible strings will silently fail to probe because the existing `sht3x` driver lacks a corresponding `of_match_table`.
--

--- Patch [2]: [PATCH v7 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series ---
commit a41d5511b126bf5d822219f86d5fe60736eb2e81
Author: Zaixiang Xu <zaixiang.xu.dev@gmail.com>

dt-bindings: hwmon: Add Sensirion SHT30 series

Add a YAML devicetree binding for the Sensirion SHT3x/STS3x sensor
family and the compatible GXCAS GXHT30, with the ALERT interrupt,
nRESET GPIO and VDD supply as optional properties.

> diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml
> new file mode 100644
> index 0000000000000..dee0252941c29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht30.yaml
[ ... ]
> +maintainers:
> +  - Zaixiang Xu <zaixiang.xu.dev@gmail.com>
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - enum:
> +          - sensirion,sht30
> +          - sensirion,sts30

[Severity: Medium]
Will devices using these newly defined compatible strings silently fail to probe?

Looking at the existing driver in drivers/hwmon/sht3x.c, it lacks an
of_match_table and relies on this legacy ID table:

static const struct i2c_device_id sht3x_ids[] = {
        { .name = "sht3x", .driver_data = sht3x },
        { .name = "sts3x", .driver_data = sts3x },
        { .name = "sht85", .driver_data = sht3x },
        { }
};

Because it relies on the I2C core extracting the compatible string to use as the
legacy matching name, it will fail to match against strings like "sht30",
"sts30", or "gxht30" from this new binding.

Does the driver need to be updated with an of_match_table to prevent this
regression?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713074559.12196-1-zaixiang.xu.dev@gmail.com?part=2

Re: [PATCH v7 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series

[Zaixiang Xu]

On Mon, 13 Jul 2026 07:55:12 +0000, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Will devices using these newly defined compatible strings silently
> fail to probe?
>
> Looking at the existing driver in drivers/hwmon/sht3x.c, it lacks an
> of_match_table and relies on this legacy ID table:
[...]
> Does the driver need to be updated with an of_match_table to prevent
> this regression?

The of_device_id table is added by patch 3/4 of this series
("hwmon: (sht3x) Add devicetree support"), so there is no gap once
the series is applied. Within the series the binding intentionally
comes first, following the usual convention that dt-bindings changes
precede the driver changes that implement them.

The compatibles introduced here did not probe before this series
either, so no bisection point regresses.

Thanks,
Zaixiang

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Unaligned memory access when extracting the humidity value causes a kernel panic on strict-alignment architectures.
- [High] Integer overflow in `limit_write()` calculating raw limit values for temperature and humidity, resulting in limits wrapping around to 0.
- [High] Missing `hwmon_lock()` synchronization for extra sysfs attributes (`heater_enable_store`, `repeatability_store`).
- [High] Changing the 'repeatability' sysfs attribute fails to update the active measurement command, rendering the change ineffective until the update interval is toggled.
- [High] `heater_enable_store()` returns the I2C transfer length instead of the consumed buffer length, breaking sysfs writes.
--

--- Patch [3]: [PATCH v7 3/4] hwmon: (sht3x) Add devicetree support ---
commit 3205e8775fc638eb1ac86ddf6feacc8304401779
Author: Zaixiang Xu <zaixiang.xu.dev@gmail.com>

hwmon: (sht3x) Add devicetree support

Add an of_device_id table to support devicetree based instantiation of the
supported sensors. The match data distinguishes the humidity and temperature
parts (SHT3x) from the temperature-only parts (STS3x). Enum sht3x_chips is
started at 1 to prevent i2c_get_match_data() from falling back to device
id matching on devicetree names.

> diff --git a/drivers/hwmon/sht3x.c b/drivers/hwmon/sht3x.c
> index c2f6b73aa7f34..6d47cfd340f83 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);

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?

drivers/hwmon/sht3x.c:sht3x_update_client() {
    ...
		val = be16_to_cpup((__be16 *)buf);
		data->temperature = sht3x_extract_temperature(val);
		val = be16_to_cpup((__be16 *)(buf + 3));
		data->humidity = sht3x_extract_humidity(val);
		data->last_update = jiffies;
	}
    ...
}

Since buf is a stack-allocated byte array, buf + 3 is at an unaligned odd
offset. Dereferencing this pointer triggers an alignment fault on strict
alignment architectures like ARMv5 or SPARC. 

Since these sysfs attributes are world-readable, could an unprivileged local
user repeatedly read them to trigger a denial of service?


[Severity: High]
This isn't a bug introduced by this patch, but does this integer arithmetic
overflow?

drivers/hwmon/sht3x.c:limit_write() {
    ...
	/*
	 * ST = (T + 45) / 175 * 2^16
	 * SRH = RH / 100 * 2^16
	 * adapted for fixed point arithmetic and packed the same as
	 * in limit_read()
	 */
	raw = ((u32)(temperature + 45000) * 24543) >> (16 + 7);
	raw |= ((humidity * 42950) >> 16) & 0xfe00;
    ...
}

Writing the maximum allowed temperature or humidity limits, such as 130000
for temp1_max, causes the expression ((u32)(temperature + 45000) * 24543)
to become 175000 * 24543 = 4295025000.

This overflows the 32-bit unsigned integer maximum. Does this result in a
calculated raw limit of 0, corresponding to the hardware's minimum bounds,
and incorrectly trigger a spurious hardware alert?


[Severity: High]
This is a pre-existing issue, but do these attributes violate the hwmon core
locking rules?

drivers/hwmon/sht3x.c:heater_enable_store() {
    ...
	mutex_lock(&data->i2c_lock);

	if (status)
		ret = i2c_master_send(client, (char *)&sht3x_cmd_heater_on,
				      SHT3X_CMD_LENGTH);
    ...
}

drivers/hwmon/sht3x.c:repeatability_store() {
    ...
	if (val > 2)
		return -EINVAL;

	data->repeatability = val;

	return count;
}

Attributes registered via the extra_groups parameter, such as heater_enable
and repeatability, do not have automatic hwmon core serialization.

The hwmon subsystem guidelines explicitly require drivers to implement
locking for extra attributes using hwmon_lock(). Should these functions use
hwmon_lock() to prevent concurrent state modifications?


[Severity: High]
This isn't a bug introduced by this patch, but does repeatability_store()
fail to update the active measurement command?

drivers/hwmon/sht3x.c:repeatability_store() {
    ...
	if (val > 2)
		return -EINVAL;

	data->repeatability = val;

	return count;
}

When a user writes to the repeatability attribute, this updates the internal
data->repeatability variable but fails to call sht3x_select_command() or
send the required I2C commands to the device.

Does the driver continue to use the old command and wait time for all
subsequent measurements in single-shot mode, rendering the change
ineffective?


[Severity: High]
This is a pre-existing issue, but does heater_enable_store() break sysfs
writes by returning the I2C transfer length?

drivers/hwmon/sht3x.c:heater_enable_store() {
    ...
	if (status)
		ret = i2c_master_send(client, (char *)&sht3x_cmd_heater_on,
				      SHT3X_CMD_LENGTH);
	else
		ret = i2c_master_send(client, (char *)&sht3x_cmd_heater_off,
				      SHT3X_CMD_LENGTH);

	mutex_unlock(&data->i2c_lock);

	return ret;
}

This returns the result of i2c_master_send(), which is 2 (the length of the
I2C command) instead of the consumed buffer length expected by sysfs.

If a user writes a string longer than 2 bytes, such as 'echo true', does
the sysfs core assume a partial write and invoke the store function again
with the remaining bytes, resulting in a spurious -EINVAL error?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713074559.12196-1-zaixiang.xu.dev@gmail.com?part=3

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 4/4] hwmon: (sht3x) Document support for GXCAS GXHT30

[Zaixiang Xu]

The GXCAS GXHT30 is a humidity and temperature sensor that is a
drop-in replacement for and fully software compatible with the
Sensirion SHT30.

It is handled by the "sensirion,sht30" fallback compatible without
any driver changes; manual instantiation works with the existing
sht3x device name. Document the chip as supported.

Signed-off-by: Zaixiang Xu <zaixiang.xu.dev@gmail.com>
---
 Documentation/hwmon/sht3x.rst | 17 ++++++++++++++---
 drivers/hwmon/Kconfig         |  5 +++--
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/Documentation/hwmon/sht3x.rst b/Documentation/hwmon/sht3x.rst
index ea1642920295..4f67671eb0cd 100644
--- a/Documentation/hwmon/sht3x.rst
+++ b/Documentation/hwmon/sht3x.rst
@@ -31,6 +31,14 @@ Supported chips:
 
     Datasheet: https://sensirion.com/media/documents/4B40CEF3/640B2346/Sensirion_Humidity_Sensors_SHT85_Datasheet.pdf
 
+  * GXCAS GXHT30
+
+    Prefix: 'sht3x'
+
+    Addresses scanned: none
+
+    Datasheet: https://www.galaxy-cas.com/uploads/files/202509/GXHT30_datasheet_V3.9_20250919170350.pdf
+
 Author:
 
   - David Frey <david.frey@sensirion.com>
@@ -40,9 +48,12 @@ Description
 -----------
 
 This driver implements support for the Sensirion SHT3x-DIS, STS3x-DIS and SHT85
-series of humidity and temperature sensors. Temperature is measured in degrees
-celsius, relative humidity is expressed as a percentage. In the sysfs interface,
-all values are scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
+series of humidity and temperature sensors, as well as the compatible GXCAS
+GXHT30. The GXHT30 is a drop-in replacement for the SHT30: instantiate it from
+devicetree with the "gxcas,gxht30", "sensirion,sht30" compatibles, or manually
+using the sht3x device name. Temperature is measured in degrees celsius,
+relative humidity is expressed as a percentage. In the sysfs interface, all
+values are scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
 
 The device communicates with the I2C protocol. SHT3x sensors can have the I2C
 addresses 0x44 or 0x45 (0x4a or 0x4b for sts3x), depending on the wiring. SHT85
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08c29685126a..64fc00ade5ca 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2023,8 +2023,9 @@ config SENSORS_SHT3x
 	depends on I2C
 	select CRC8
 	help
-	  If you say yes here you get support for the Sensiron SHT30, SHT31 and
-	  SHT85 humidity and temperature sensors.
+	  If you say yes here you get support for the Sensiron SHT30, SHT31,
+	  SHT85 and the compatible GXCAS GXHT30 humidity and temperature
+	  sensors.
 
 	  This driver can also be built as a module. If so, the module
 	  will be called sht3x.
-- 
2.34.1

Re: [PATCH v7 4/4] hwmon: (sht3x) Document support for GXCAS GXHT30

[sashiko-bot]

> The GXCAS GXHT30 is a humidity and temperature sensor that is a
> drop-in replacement for and fully software compatible with the
> Sensirion SHT30.
> 
> It is handled by the "sensirion,sht30" fallback compatible without
> any driver changes; manual instantiation works with the existing
> sht3x device name. Document the chip as supported.
> 
> Signed-off-by: Zaixiang Xu <zaixiang.xu.dev@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713074559.12196-1-zaixiang.xu.dev@gmail.com?part=4