[PATCH v2 0/6] hwmon: (lm63) Add Sensylink CTF2301 support

[PATCH v2 0/6] hwmon: (lm63) Add Sensylink CTF2301 support

[Troy Mitchell]

Sensylink CTF2301 is a system-level thermal management solution chip.

The CTF2301 is an I2C/SMBus compatible device featuring:
  - One local temperature sensor with +/-0.5 degree C accuracy and
    0.0625 degree C resolution.
  - One remote temperature sensor for external diode-connected
    transistors, offering +/-1 degree C accuracy and 0.125 degree C
    resolution (temperature range: -40 degree C to +125 degree C).
  - An integrated PWM fan controller capable of operating in two modes:
      1. Direct-DCY: Open-loop direct duty cycle control.
      2. Auto-Temp: Closed-loop automatic fan speed control based on
         measured temperature.
  - A 1-channel fan speed monitor (TACH input) for RPM measurement.

As Guenter pointed out on v1, the CTF2301 register map is a near match
for the LM63/LM96163 family (local and remote temperature, tachometer and
PWM fan control), so this version drops the standalone ctf2301 driver
and instead adds CTF2301 as a new chip type in the existing lm63 driver.
This reuses the shared temperature, limit, alarm and PWM handling instead
of duplicating it.

The CTF2301-specific differences are handled on top of lm63: 12-bit local
temperature input and high-limit values, nine conversion rates, 12
fan-control lookup table entries, and optional 22.5 kHz high-resolution
PWM. When no IRQ is described, the shared ALERT/TACH pin is configured as
a tachometer input. The LM63 family can also register as a thermal cooling
device when the device tree provides the #cooling-cells property.

The required SpacemiT I2C controller clock series has been merged but is
not yet included in an rc release:
https://lore.kernel.org/all/20260508-k1-i2c-ilcr-v7-0-8c2dde5c3ed5@linux.spacemit.com/

Apply that series before testing this series on K3. Without it, the I2C
controller cannot generate an accurate 400 kHz SCL clock and CTF2301
accesses may fail.

Tested on a SpacemiT K3 CoM260 by booting an initramfs and verifying the
CTF2301 probe. Temperature, tachometer, PWM, and conversion-rate behavior
were checked against direct I2C register accesses and the datasheet.

Datasheet:
https://www.sensylink.com/upload/1/net.sensylink.portal/1689557281035.pdf

Register description:
https://github.com/TroyMitchell911/ctf2301-datasheet

Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
---
Changes in v2:
- Replace the standalone CTF2301 driver with a new lm63 chip type, as
  suggested by Guenter, reusing the existing temperature, limit, alarm,
  tachometer, PWM, and automatic fan-control paths.
- Add the temperature thresholds, alarms, and automatic fan-control lookup
  table support which were missing from the v1 driver.
- Handle CTF2301-specific 12-bit local temperature values, nine conversion
  rates, 12 lookup table entries, shared ALERT/TACH pin, and optional
  22.5 kHz high-resolution PWM.
- Propagate SMBus failures from lm63 initialization and write paths.
- Add optional thermal cooling-device support for the LM63 family using
  the existing manual PWM control path.
- Move the National LM63-family compatibles from trivial-devices.yaml to a
  dedicated binding which permits #cooling-cells.
- Add CTF2301 to the LM63-family binding instead of keeping the standalone
  schema from v1. Do not declare #cooling-cells on K3 CoM260 yet because
  the board has no thermal consumer.
- Fix the binding errors reported by Rob by using a plain compatible string
  and wrapping the description.
- Document CTF2301 support in the lm63 hwmon documentation and provide the
  detailed register description used for review.
- Add the K3 CoM260 I2C6 pinctrl state and CTF2301 device node for hardware
  testing.
- Link to v1: https://lore.kernel.org/r/20250916-ctl2301-v1-0-97e7c84f2c47@linux.dev

To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
To: Paul Walmsley <pjw@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
To: Albert Ou <aou@eecs.berkeley.edu>
To: Alexandre Ghiti <alex@ghiti.fr>
To: Yixun Lan <dlan@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: spacemit@lists.linux.dev
Cc: linux-doc@vger.kernel.org

---
Troy Mitchell (6):
      dt-bindings: vendor-prefixes: Add Sensylink
      dt-bindings: hwmon: Move LM63 family to a dedicated binding
      dt-bindings: hwmon: Add Sensylink CTF2301
      hwmon: (lm63) Add Sensylink CTF2301 support
      riscv: dts: spacemit: Add K3 I2C6 pinctrl state
      riscv: dts: spacemit: Add CTF2301 on K3 CoM260

 .../devicetree/bindings/hwmon/national,lm63.yaml   |  52 +++
 .../devicetree/bindings/trivial-devices.yaml       |   6 -
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 Documentation/hwmon/lm63.rst                       |  22 ++
 arch/riscv/boot/dts/spacemit/k3-com260.dtsi        |  19 +
 arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi       |  11 +
 drivers/hwmon/Kconfig                              |   8 +-
 drivers/hwmon/lm63.c                               | 393 +++++++++++++++++----
 8 files changed, 433 insertions(+), 80 deletions(-)
---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20250916-ctl2301-0416b073c280

Best regards,
--  
Troy Mitchell <troy.mitchell@linux.dev>

[PATCH v2 1/6] dt-bindings: vendor-prefixes: Add Sensylink

[Troy Mitchell]

Add the vendor prefix for Sensylink Microelectronics.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
---
 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..22d0d26f1bbd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1467,6 +1467,8 @@ patternProperties:
     description: Sensirion AG
   "^sensortek,.*":
     description: Sensortek Technology Corporation
+  "^sensylink,.*":
+    description: Sensylink Microelectronics Technology Co., Ltd.
   "^sercomm,.*":
     description: Sercomm (Suzhou) Corporation
   "^sff,.*":

-- 
2.55.0

[PATCH v2 2/6] dt-bindings: hwmon: Move LM63 family to a dedicated binding

[Troy Mitchell]

Move the National Semiconductor LM63, LM64, and LM96163 compatibles out
of trivial-devices.yaml and into a dedicated binding. Describe their
integrated fan control and permit use as thermal cooling devices through
the #cooling-cells property.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
---
 .../devicetree/bindings/hwmon/national,lm63.yaml   | 50 ++++++++++++++++++++++
 .../devicetree/bindings/trivial-devices.yaml       |  6 ---
 2 files changed, 50 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
new file mode 100644
index 000000000000..92b0094ff303
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/national,lm63.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LM63-compatible temperature sensors with integrated fan control
+
+maintainers:
+  - Guenter Roeck <linux@roeck-us.net>
+
+description: |
+  The LM63 family provides local and remote temperature monitoring together
+  with fan speed monitoring and PWM fan control. Supported devices include
+  the National Semiconductor LM63, LM64 and LM96163.
+
+allOf:
+  - $ref: hwmon-common.yaml#
+
+properties:
+  compatible:
+    enum:
+      - national,lm63
+      - national,lm64
+      - national,lm96163
+
+  reg:
+    maxItems: 1
+
+  "#cooling-cells":
+    const: 2
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        temperature-sensor@4c {
+            compatible = "national,lm63";
+            reg = <0x4c>;
+            #cooling-cells = <2>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 435c4baab436..aa62d245464c 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -364,16 +364,10 @@ properties:
           - mps,mp9945
             # Murata D1U74T-W power supply unit
           - murata,d1u74t
-            # Temperature sensor with integrated fan control
-          - national,lm63
-            # Temperature sensor with integrated fan control
-          - national,lm64
             # Temperature sensor
           - national,lm95235
             # Temperature sensor
           - national,lm95245
-            # Temperature sensor with integrated fan control
-          - national,lm96163
             # Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
           - national,lm80
             # Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor

-- 
2.55.0

[PATCH v2 3/6] dt-bindings: hwmon: Add Sensylink CTF2301

[Troy Mitchell]

Add the Sensylink CTF2301 temperature sensor and fan controller to the
LM63 family binding. The chip follows the LM63 register model and can
provide a thermal cooling device when #cooling-cells is present.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
---
 Documentation/devicetree/bindings/hwmon/national,lm63.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
index 92b0094ff303..4a1ffebfdbef 100644
--- a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
+++ b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
@@ -12,7 +12,8 @@ maintainers:
 description: |
   The LM63 family provides local and remote temperature monitoring together
   with fan speed monitoring and PWM fan control. Supported devices include
-  the National Semiconductor LM63, LM64 and LM96163.
+  the National Semiconductor LM63, LM64 and LM96163, and the Sensylink
+  CTF2301.
 
 allOf:
   - $ref: hwmon-common.yaml#
@@ -23,6 +24,7 @@ properties:
       - national,lm63
       - national,lm64
       - national,lm96163
+      - sensylink,ctf2301
 
   reg:
     maxItems: 1

-- 
2.55.0

[PATCH v2 4/6] hwmon: (lm63) Add Sensylink CTF2301 support

[Troy Mitchell]

Add Sensylink CTF2301 support to the LM63 driver. CTF2301 follows
the LM63-style temperature, tachometer, and PWM register layout,
while using a 12-bit local temperature register and requiring the
ALERT/TACH pin to be configured for tachometer input.

Register an optional thermal cooling device when the device tree
node provides #cooling-cells, allowing thermal zones to control
the fan through the existing PWM path without changing behavior
for existing LM63-family users.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
---
 Documentation/hwmon/lm63.rst |  22 +++
 drivers/hwmon/Kconfig        |   8 +-
 drivers/hwmon/lm63.c         | 393 +++++++++++++++++++++++++++++++++++--------
 3 files changed, 349 insertions(+), 74 deletions(-)

diff --git a/Documentation/hwmon/lm63.rst b/Documentation/hwmon/lm63.rst
index 9e27367d7405..c40bd0dfe591 100644
--- a/Documentation/hwmon/lm63.rst
+++ b/Documentation/hwmon/lm63.rst
@@ -33,6 +33,16 @@ Supported chips:
 
 	       http://www.national.com/pf/LM/LM96163.html
 
+  * Sensylink CTF2301
+
+    Prefix: 'ctf2301'
+
+    Addresses scanned: none
+
+    Datasheet: https://www.sensylink.com/upload/1/net.sensylink.portal/1689557281035.pdf
+
+    Register description: https://github.com/TroyMitchell911/ctf2301-datasheet
+
 
 Author: Jean Delvare <jdelvare@suse.de>
 
@@ -62,6 +72,8 @@ value have to be masked out. The value is still 16 bit in width.
 
 All temperature values are given in degrees Celsius. Resolution is 1.0
 degree for the local temperature, 0.125 degree for the remote temperature.
+The CTF2301 local temperature input and limit have a resolution of 0.0625
+degree.
 
 The fan speed is measured using a tachometer. Contrary to most chips which
 store the value in an 8-bit register and have a selectable clock divider
@@ -93,3 +105,13 @@ support these GPIO lines at present.
 The LM96163 is an enhanced version of LM63 with improved temperature accuracy
 and better PWM resolution. For LM96163, the external temperature sensor type is
 configurable as CPU embedded diode(1) or 3904 transistor(2).
+
+The CTF2301 is register-compatible with the LM63 family and provides 12 fan
+control lookup table entries. It supports 8-bit PWM resolution when configured
+for a 22.5 kHz PWM frequency.
+
+Device tree nodes may declare ``#cooling-cells`` to register the fan controller
+with the thermal framework. The cooling state is mapped to the existing
+``pwm1`` range from 0 to 255. The driver keeps the current automatic or manual
+fan control mode during probe and switches to manual control when the thermal
+framework first requests a cooling state.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 2bfbcc033d59..abb1af8664fb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1501,10 +1501,10 @@ config SENSORS_LM63
 	depends on I2C
 	help
 	  If you say yes here you get support for the National
-	  Semiconductor LM63, LM64, and LM96163 remote diode digital temperature
-	  sensors with integrated fan control.  Such chips are found
-	  on the Tyan S4882 (Thunder K8QS Pro) motherboard, among
-	  others.
+	  Semiconductor LM63, LM64, LM96163, and Sensylink CTF2301
+	  remote diode digital temperature sensors with integrated fan
+	  control. Such chips are found on the Tyan S4882 (Thunder K8QS
+	  Pro) motherboard, among others.
 
 	  This driver can also be built as a module. If so, the module
 	  will be called lm63.
diff --git a/drivers/hwmon/lm63.c b/drivers/hwmon/lm63.c
index e2a429e579ac..764a7467afa6 100644
--- a/drivers/hwmon/lm63.c
+++ b/drivers/hwmon/lm63.c
@@ -35,13 +35,14 @@
 #include <linux/mutex.h>
 #include <linux/of.h>
 #include <linux/sysfs.h>
+#include <linux/thermal.h>
 #include <linux/types.h>
 
 /*
  * Addresses to scan
  * Address is fully defined internally and cannot be changed except for
  * LM64 which has one pin dedicated to address selection.
- * LM63 and LM96163 have address 0x4c.
+ * LM63, LM96163, and CTF2301 have address 0x4c.
  * LM64 can have address 0x18 or 0x4e.
  */
 
@@ -70,6 +71,9 @@ static const unsigned short normal_i2c[] = { 0x18, 0x4c, 0x4e, I2C_CLIENT_END };
 #define LM63_REG_LOCAL_TEMP		0x00
 #define LM63_REG_LOCAL_HIGH		0x05
 
+#define CTF2301_REG_LOCAL_TEMP_LSB	0x15
+#define CTF2301_REG_LOCAL_HIGH_LSB	0x06
+
 #define LM63_REG_REMOTE_TEMP_MSB	0x01
 #define LM63_REG_REMOTE_TEMP_LSB	0x10
 #define LM63_REG_REMOTE_OFFSET_MSB	0x11
@@ -94,6 +98,7 @@ static const unsigned short normal_i2c[] = { 0x18, 0x4c, 0x4e, I2C_CLIENT_END };
 
 #define LM63_PWM_BASE_FAST_HZ		180000
 #define LM63_PWM_BASE_SLOW_HZ		700
+#define LM63_MAX_PWM			255
 
 #define LM63_MAX_CONVRATE		9
 
@@ -121,6 +126,9 @@ static const unsigned short normal_i2c[] = { 0x18, 0x4c, 0x4e, I2C_CLIENT_END };
 							    127000), 1000)
 #define TEMP8U_TO_REG(val)	DIV_ROUND_CLOSEST(clamp_val((val), 0, \
 							    255000), 1000)
+#define TEMP12_FROM_REG(reg)	DIV_ROUND_CLOSEST((s16)(reg) * 1000, 256)
+#define TEMP12_TO_REG(val)	DIV_ROUND_CLOSEST(clamp_val((val), -128000, \
+							     127937) * 256, 1000)
 #define TEMP11_FROM_REG(reg)	((reg) / 32 * 125)
 #define TEMP11_TO_REG(val)	(DIV_ROUND_CLOSEST(clamp_val((val), -128000, \
 							     127875), 125) * 32)
@@ -132,7 +140,11 @@ static const unsigned short normal_i2c[] = { 0x18, 0x4c, 0x4e, I2C_CLIENT_END };
 #define UPDATE_INTERVAL(max, rate) \
 			((1000 << (LM63_MAX_CONVRATE - (rate))) / (max))
 
-enum chips { lm63, lm64, lm96163 };
+enum chips { lm63, lm64, lm96163, ctf2301 };
+
+static const unsigned int ctf2301_update_intervals[] = {
+	20000, 10000, 4902, 2463, 1000, 615, 307, 154, 107
+};
 
 /*
  * Client data (each client gets its own)
@@ -164,6 +176,8 @@ struct lm63_data {
 			   1: local high limit
 			   2: remote critical limit
 			   3-14: lookup table */
+	s16 temp1_input; /* local input for chips with extended resolution */
+	s16 temp1_max; /* local limit for chips with extended resolution */
 	s16 temp11[4];	/* 0: remote input
 			   1: remote low limit
 			   2: remote high limit
@@ -256,8 +270,16 @@ static struct lm63_data *lm63_update_device(struct device *dev)
 
 		data->temp8[0] = i2c_smbus_read_byte_data(client,
 				 LM63_REG_LOCAL_TEMP);
+		if (data->kind == ctf2301)
+			data->temp1_input = ((u16)(u8)data->temp8[0] << 8)
+					  | i2c_smbus_read_byte_data(client,
+						CTF2301_REG_LOCAL_TEMP_LSB);
 		data->temp8[1] = i2c_smbus_read_byte_data(client,
 				 LM63_REG_LOCAL_HIGH);
+		if (data->kind == ctf2301)
+			data->temp1_max = ((u16)(u8)data->temp8[1] << 8)
+					  | i2c_smbus_read_byte_data(client,
+						CTF2301_REG_LOCAL_HIGH_LSB);
 
 		/* order matters for temp2_input */
 		data->temp11[0] = i2c_smbus_read_byte_data(client,
@@ -277,7 +299,7 @@ static struct lm63_data *lm63_update_device(struct device *dev)
 				| i2c_smbus_read_byte_data(client,
 				  LM63_REG_REMOTE_OFFSET_LSB);
 
-		if (data->kind == lm96163)
+		if (data->kind == lm96163 || data->kind == ctf2301)
 			data->temp11u = (i2c_smbus_read_byte_data(client,
 					LM96163_REG_REMOTE_TEMP_U_MSB) << 8)
 				      | i2c_smbus_read_byte_data(client,
@@ -367,6 +389,41 @@ static ssize_t set_fan(struct device *dev, struct device_attribute *dummy,
 	return count;
 }
 
+static int lm63_pwm_from_reg(struct lm63_data *data, u8 reg)
+{
+	if (data->pwm_highres)
+		return reg;
+
+	return reg >= 2 * data->pwm1_freq ?
+	       LM63_MAX_PWM :
+	       (reg * LM63_MAX_PWM + data->pwm1_freq) / (2 * data->pwm1_freq);
+}
+
+static u8 lm63_pwm_to_reg(struct lm63_data *data, unsigned long val)
+{
+	val = clamp_val(val, 0, LM63_MAX_PWM);
+
+	if (data->pwm_highres)
+		return val;
+
+	return (val * data->pwm1_freq * 2 + LM63_MAX_PWM / 2) / LM63_MAX_PWM;
+}
+
+static int lm63_write_pwm(struct lm63_data *data, int nr, unsigned long val)
+{
+	struct i2c_client *client = data->client;
+	u8 reg = nr ? LM63_REG_LUT_PWM(nr - 1) : LM63_REG_PWM_VALUE;
+	u8 regval = lm63_pwm_to_reg(data, val);
+	int ret;
+
+	ret = i2c_smbus_write_byte_data(client, reg, regval);
+	if (ret)
+		return ret;
+	data->pwm1[nr] = regval;
+
+	return 0;
+}
+
 static ssize_t show_pwm1(struct device *dev, struct device_attribute *devattr,
 			 char *buf)
 {
@@ -376,12 +433,7 @@ static ssize_t show_pwm1(struct device *dev, struct device_attribute *devattr,
 	int pwm;
 
 	mutex_lock(&data->update_lock);
-	if (data->pwm_highres)
-		pwm = data->pwm1[nr];
-	else
-		pwm = data->pwm1[nr] >= 2 * data->pwm1_freq ?
-		       255 : (data->pwm1[nr] * 255 + data->pwm1_freq) /
-		       (2 * data->pwm1_freq);
+	pwm = lm63_pwm_from_reg(data, data->pwm1[nr]);
 	mutex_unlock(&data->update_lock);
 
 	return sprintf(buf, "%d\n", pwm);
@@ -392,11 +444,9 @@ static ssize_t set_pwm1(struct device *dev, struct device_attribute *devattr,
 {
 	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
 	struct lm63_data *data = dev_get_drvdata(dev);
-	struct i2c_client *client = data->client;
 	int nr = attr->index;
 	unsigned long val;
 	int err;
-	u8 reg;
 
 	if (!(data->config_fan & 0x20)) /* register is read-only */
 		return -EPERM;
@@ -405,15 +455,11 @@ static ssize_t set_pwm1(struct device *dev, struct device_attribute *devattr,
 	if (err)
 		return err;
 
-	reg = nr ? LM63_REG_LUT_PWM(nr - 1) : LM63_REG_PWM_VALUE;
-	val = clamp_val(val, 0, 255);
-
 	mutex_lock(&data->update_lock);
-	data->pwm1[nr] = data->pwm_highres ? val :
-			(val * data->pwm1_freq * 2 + 127) / 255;
-	i2c_smbus_write_byte_data(client, reg, data->pwm1[nr]);
+	err = lm63_write_pwm(data, nr, val);
 	mutex_unlock(&data->update_lock);
-	return count;
+
+	return err ? err : count;
 }
 
 static ssize_t pwm1_enable_show(struct device *dev,
@@ -486,7 +532,9 @@ static ssize_t pwm1_freq_store(struct device *dev,
 	struct lm63_data *data = dev_get_drvdata(dev);
 	struct i2c_client *client = data->client;
 	unsigned long val, pfr_fast, pfr_slow, err_fast, err_slow, pfr;
+	u8 config_fan;
 	bool slow_clock;
+	int config_enhanced = 0;
 	int ret;
 
 	ret = kstrtoul(buf, 10, &val);
@@ -512,35 +560,55 @@ static ssize_t pwm1_freq_store(struct device *dev,
 
 	mutex_lock(&data->update_lock);
 	ret = i2c_smbus_read_byte_data(client, LM63_REG_CONFIG_FAN);
-	if (ret < 0) {
-		mutex_unlock(&data->update_lock);
-		return ret;
-	}
-	data->config_fan = ret;
+	if (ret < 0)
+		goto unlock;
+	config_fan = ret;
 
-	if (!(data->config_fan & 0x20)) { /* register is read-only */
-		mutex_unlock(&data->update_lock);
-		return -EPERM;
+	if (!(config_fan & 0x20)) { /* register is read-only */
+		ret = -EPERM;
+		goto unlock;
 	}
 
-	if (data->kind == lm96163) {
-		ret = i2c_smbus_read_byte_data(client, LM96163_REG_CONFIG_ENHANCED);
-		if (ret < 0) {
-			mutex_unlock(&data->update_lock);
-			return ret;
+	if (data->kind == lm96163 || data->kind == ctf2301) {
+		ret = i2c_smbus_read_byte_data(client,
+					       LM96163_REG_CONFIG_ENHANCED);
+		if (ret < 0)
+			goto unlock;
+		config_enhanced = ret;
+
+		if (data->kind == ctf2301) {
+			if (!slow_clock && pfr == 8)
+				config_enhanced |= 0x10;
+			else
+				config_enhanced &= ~0x10;
+			ret = i2c_smbus_write_byte_data(client,
+							LM96163_REG_CONFIG_ENHANCED,
+							config_enhanced);
+			if (ret)
+				goto unlock;
 		}
-		data->pwm_highres = !slow_clock && pfr == 8 && (ret & 0x10);
 	}
 
 	if (slow_clock)
-		data->config_fan |= 0x08;
+		config_fan |= 0x08;
 	else
-		data->config_fan &= ~0x08;
-	i2c_smbus_write_byte_data(client, LM63_REG_CONFIG_FAN, data->config_fan);
-	i2c_smbus_write_byte_data(client, LM63_REG_PWM_FREQ, pfr);
+		config_fan &= ~0x08;
+	ret = i2c_smbus_write_byte_data(client, LM63_REG_PWM_FREQ, pfr);
+	if (ret)
+		goto unlock;
+	ret = i2c_smbus_write_byte_data(client, LM63_REG_CONFIG_FAN,
+					config_fan);
+	if (ret)
+		goto unlock;
+
+	data->config_fan = config_fan;
 	data->pwm1_freq = pfr;
+	data->pwm_highres = !slow_clock && pfr == 8 &&
+				(config_enhanced & 0x10);
+unlock:
 	mutex_unlock(&data->update_lock);
-	return count;
+
+	return ret ? ret : count;
 }
 
 /*
@@ -555,6 +623,11 @@ static ssize_t show_local_temp8(struct device *dev,
 {
 	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
 	struct lm63_data *data = lm63_update_device(dev);
+
+	if (data->kind == ctf2301)
+		return sprintf(buf, "%d\n", TEMP12_FROM_REG(attr->index ?
+				       data->temp1_max : data->temp1_input));
+
 	return sprintf(buf, "%d\n", TEMP8_FROM_REG(data->temp8[attr->index]));
 }
 
@@ -595,6 +668,23 @@ static ssize_t set_temp8(struct device *dev, struct device_attribute *devattr,
 		return err;
 
 	mutex_lock(&data->update_lock);
+	if (data->kind == ctf2301 && nr == 1) {
+		temp = TEMP12_TO_REG(val);
+		err = i2c_smbus_write_byte_data(client, LM63_REG_LOCAL_HIGH,
+						temp >> 8);
+		if (!err)
+			err = i2c_smbus_write_byte_data(client,
+							CTF2301_REG_LOCAL_HIGH_LSB,
+							temp & 0xf0);
+		if (!err) {
+			data->temp8[nr] = temp >> 8;
+			data->temp1_max = temp;
+		}
+		mutex_unlock(&data->update_lock);
+
+		return err ? err : count;
+	}
+
 	switch (nr) {
 	case 2:
 		reg = LM63_REG_REMOTE_TCRIT;
@@ -611,10 +701,12 @@ static ssize_t set_temp8(struct device *dev, struct device_attribute *devattr,
 		reg = LM63_REG_LUT_TEMP(nr - 3);
 		temp = lut_temp_to_reg(data, val);
 	}
-	data->temp8[nr] = temp;
-	i2c_smbus_write_byte_data(client, reg, temp);
+	err = i2c_smbus_write_byte_data(client, reg, temp);
+	if (!err)
+		data->temp8[nr] = temp;
 	mutex_unlock(&data->update_lock);
-	return count;
+
+	return err ? err : count;
 }
 
 static ssize_t show_temp11(struct device *dev, struct device_attribute *devattr,
@@ -788,11 +880,40 @@ static ssize_t temp2_crit_hyst_store(struct device *dev,
  * Set conversion rate.
  * client->update_lock must be held when calling this function.
  */
-static void lm63_set_convrate(struct lm63_data *data, unsigned int interval)
+static unsigned int lm63_update_interval(struct lm63_data *data, u8 rate)
+{
+	if (data->kind == ctf2301)
+		return ctf2301_update_intervals[min_t(unsigned int, rate,
+					ARRAY_SIZE(ctf2301_update_intervals) - 1)];
+
+	return UPDATE_INTERVAL(data->max_convrate_hz, rate);
+}
+
+static int lm63_set_convrate(struct lm63_data *data, unsigned int interval)
 {
 	struct i2c_client *client = data->client;
-	unsigned int update_interval;
-	int i;
+	unsigned int update_interval, error, best_error = ~0U;
+	unsigned int best = 0;
+	unsigned int i;
+	int ret;
+
+	if (data->kind == ctf2301) {
+		for (i = 0; i < ARRAY_SIZE(ctf2301_update_intervals); i++) {
+			error = abs_diff(interval, ctf2301_update_intervals[i]);
+			if (error < best_error) {
+				best_error = error;
+				best = i;
+			}
+		}
+
+		ret = i2c_smbus_write_byte_data(client, LM63_REG_CONVRATE,
+						best);
+		if (ret)
+			return ret;
+		data->update_interval = ctf2301_update_intervals[best];
+
+		return 0;
+	}
 
 	/* Shift calculations to avoid rounding errors */
 	interval <<= 6;
@@ -804,8 +925,12 @@ static void lm63_set_convrate(struct lm63_data *data, unsigned int interval)
 		if (interval >= update_interval * 3 / 4)
 			break;
 
-	i2c_smbus_write_byte_data(client, LM63_REG_CONVRATE, i);
+	ret = i2c_smbus_write_byte_data(client, LM63_REG_CONVRATE, i);
+	if (ret)
+		return ret;
 	data->update_interval = UPDATE_INTERVAL(data->max_convrate_hz, i);
+
+	return 0;
 }
 
 static ssize_t update_interval_show(struct device *dev,
@@ -829,10 +954,10 @@ static ssize_t update_interval_store(struct device *dev,
 		return err;
 
 	mutex_lock(&data->update_lock);
-	lm63_set_convrate(data, clamp_val(val, 0, 100000));
+	err = lm63_set_convrate(data, clamp_val(val, 0, 100000));
 	mutex_unlock(&data->update_lock);
 
-	return count;
+	return err ? err : count;
 }
 
 static ssize_t temp2_type_show(struct device *dev,
@@ -997,6 +1122,75 @@ static DEVICE_ATTR_RO(alarms);
 
 static DEVICE_ATTR_RW(update_interval);
 
+static int lm63_get_max_state(struct thermal_cooling_device *cdev,
+			      unsigned long *state)
+{
+	*state = LM63_MAX_PWM;
+
+	return 0;
+}
+
+static int lm63_get_cur_state(struct thermal_cooling_device *cdev,
+			      unsigned long *state)
+{
+	struct lm63_data *data = cdev->devdata;
+	int ret;
+
+	mutex_lock(&data->update_lock);
+	ret = i2c_smbus_read_byte_data(data->client, LM63_REG_PWM_VALUE);
+	if (ret < 0)
+		goto unlock;
+
+	data->pwm1[0] = ret;
+	*state = lm63_pwm_from_reg(data, data->pwm1[0]);
+unlock:
+	mutex_unlock(&data->update_lock);
+
+	return ret < 0 ? ret : 0;
+}
+
+static int lm63_set_cur_state(struct thermal_cooling_device *cdev,
+			      unsigned long state)
+{
+	struct lm63_data *data = cdev->devdata;
+	int config_fan;
+	int ret;
+
+	if (state > LM63_MAX_PWM)
+		return -EINVAL;
+
+	mutex_lock(&data->update_lock);
+	config_fan = i2c_smbus_read_byte_data(data->client,
+					      LM63_REG_CONFIG_FAN);
+	if (config_fan < 0) {
+		ret = config_fan;
+		goto unlock;
+	}
+	data->config_fan = config_fan;
+
+	if (!(config_fan & 0x20)) {
+		config_fan |= 0x20;
+		ret = i2c_smbus_write_byte_data(data->client,
+						LM63_REG_CONFIG_FAN,
+						config_fan);
+		if (ret)
+			goto unlock;
+		data->config_fan = config_fan;
+	}
+
+	ret = lm63_write_pwm(data, 0, state);
+unlock:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+static const struct thermal_cooling_device_ops lm63_cooling_ops = {
+	.get_max_state = lm63_get_max_state,
+	.get_cur_state = lm63_get_cur_state,
+	.set_cur_state = lm63_set_cur_state,
+};
+
 static struct attribute *lm63_attributes[] = {
 	&sensor_dev_attr_pwm1.dev_attr.attr,
 	&dev_attr_pwm1_enable.attr,
@@ -1079,8 +1273,8 @@ static const struct attribute_group lm63_group_extra_lut = {
  * On LM63, temp2_crit can be set only once, which should be job
  * of the bootloader.
  * On LM64, temp2_crit can always be set.
- * On LM96163, temp2_crit can be set if bit 1 of the configuration
- * register is true.
+ * On LM96163 and CTF2301, temp2_crit can be set if bit 1 of the
+ * configuration register is true.
  */
 static umode_t lm63_attribute_mode(struct kobject *kobj,
 				   struct attribute *attr, int index)
@@ -1090,7 +1284,8 @@ static umode_t lm63_attribute_mode(struct kobject *kobj,
 
 	if (attr == &sensor_dev_attr_temp2_crit.dev_attr.attr
 	    && (data->kind == lm64 ||
-		(data->kind == lm96163 && (data->config & 0x02))))
+		((data->kind == lm96163 || data->kind == ctf2301) &&
+		 (data->config & 0x02))))
 		return attr->mode | S_IWUSR;
 
 	return attr->mode;
@@ -1165,29 +1360,48 @@ static int lm63_detect(struct i2c_client *client,
  * Ideally we shouldn't have to initialize anything, since the BIOS
  * should have taken care of everything
  */
-static void lm63_init_client(struct lm63_data *data)
+static int lm63_init_client(struct lm63_data *data)
 {
 	struct i2c_client *client = data->client;
 	struct device *dev = &client->dev;
 	u8 convrate;
+	int ret;
 
-	data->config = i2c_smbus_read_byte_data(client, LM63_REG_CONFIG1);
-	data->config_fan = i2c_smbus_read_byte_data(client,
-						    LM63_REG_CONFIG_FAN);
+	ret = i2c_smbus_read_byte_data(client, LM63_REG_CONFIG1);
+	if (ret < 0)
+		return ret;
+	data->config = ret;
+	ret = i2c_smbus_read_byte_data(client, LM63_REG_CONFIG_FAN);
+	if (ret < 0)
+		return ret;
+	data->config_fan = ret;
 
 	/* Start converting if needed */
 	if (data->config & 0x40) { /* standby */
 		dev_dbg(dev, "Switching to operational mode\n");
 		data->config &= 0xA7;
-		i2c_smbus_write_byte_data(client, LM63_REG_CONFIG1,
-					  data->config);
+		ret = i2c_smbus_write_byte_data(client, LM63_REG_CONFIG1,
+						data->config);
+		if (ret)
+			return ret;
 	}
 	/* Tachometer is always enabled on LM64 */
 	if (data->kind == lm64)
 		data->config |= 0x04;
+	if (data->kind == ctf2301 && !client->irq && !(data->config & 0x04)) {
+		dev_dbg(dev, "Configuring ALERT/TACH pin for tachometer input\n");
+		data->config |= 0x04;
+		ret = i2c_smbus_write_byte_data(client, LM63_REG_CONFIG1,
+						data->config);
+		if (ret)
+			return ret;
+	}
 
 	/* We may need pwm1_freq before ever updating the client data */
-	data->pwm1_freq = i2c_smbus_read_byte_data(client, LM63_REG_PWM_FREQ);
+	ret = i2c_smbus_read_byte_data(client, LM63_REG_PWM_FREQ);
+	if (ret < 0)
+		return ret;
+	data->pwm1_freq = ret;
 	if (data->pwm1_freq == 0)
 		data->pwm1_freq = 1;
 
@@ -1200,25 +1414,38 @@ static void lm63_init_client(struct lm63_data *data)
 	case lm96163:
 		data->max_convrate_hz = LM96163_MAX_CONVRATE_HZ;
 		data->lut_size = 12;
-		data->trutherm
-		  = i2c_smbus_read_byte_data(client,
-					     LM96163_REG_TRUTHERM) & 0x02;
+		ret = i2c_smbus_read_byte_data(client, LM96163_REG_TRUTHERM);
+		if (ret < 0)
+			return ret;
+		data->trutherm = ret & 0x02;
+		break;
+	case ctf2301:
+		data->lut_size = 12;
 		break;
 	}
-	convrate = i2c_smbus_read_byte_data(client, LM63_REG_CONVRATE);
-	if (unlikely(convrate > LM63_MAX_CONVRATE))
+	ret = i2c_smbus_read_byte_data(client, LM63_REG_CONVRATE);
+	if (ret < 0)
+		return ret;
+	convrate = ret;
+	if (data->kind == ctf2301 &&
+	    convrate >= ARRAY_SIZE(ctf2301_update_intervals))
+		convrate = ARRAY_SIZE(ctf2301_update_intervals) - 1;
+	else if (unlikely(convrate > LM63_MAX_CONVRATE))
 		convrate = LM63_MAX_CONVRATE;
-	data->update_interval = UPDATE_INTERVAL(data->max_convrate_hz,
-						convrate);
+	data->update_interval = lm63_update_interval(data, convrate);
 
 	/*
-	 * For LM96163, check if high resolution PWM
+	 * For LM96163 and CTF2301, check if high resolution PWM
 	 * and unsigned temperature format is enabled.
 	 */
-	if (data->kind == lm96163) {
-		u8 config_enhanced
-		  = i2c_smbus_read_byte_data(client,
-					     LM96163_REG_CONFIG_ENHANCED);
+	if (data->kind == lm96163 || data->kind == ctf2301) {
+		u8 config_enhanced;
+
+		ret = i2c_smbus_read_byte_data(client,
+					       LM96163_REG_CONFIG_ENHANCED);
+		if (ret < 0)
+			return ret;
+		config_enhanced = ret;
 		if (config_enhanced & 0x20)
 			data->lut_temp_highres = true;
 		if ((config_enhanced & 0x10)
@@ -1239,6 +1466,8 @@ static void lm63_init_client(struct lm63_data *data)
 	dev_dbg(dev, "PWM output active %s, %s mode\n",
 		(data->config_fan & 0x10) ? "low" : "high",
 		(data->config_fan & 0x20) ? "manual" : "auto");
+
+	return 0;
 }
 
 static const struct i2c_device_id lm63_id[];
@@ -1246,9 +1475,11 @@ static const struct i2c_device_id lm63_id[];
 static int lm63_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
+	struct thermal_cooling_device *cdev;
 	struct device *hwmon_dev;
 	struct lm63_data *data;
 	int groups = 0;
+	int ret;
 
 	data = devm_kzalloc(dev, sizeof(struct lm63_data), GFP_KERNEL);
 	if (!data)
@@ -1263,7 +1494,9 @@ static int lm63_probe(struct i2c_client *client)
 		data->temp2_offset = 16000;
 
 	/* Initialize chip */
-	lm63_init_client(data);
+	ret = lm63_init_client(data);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to initialize device\n");
 
 	/* Register sysfs hooks */
 	data->groups[groups++] = &lm63_group;
@@ -1273,11 +1506,26 @@ static int lm63_probe(struct i2c_client *client)
 	if (data->kind == lm96163) {
 		data->groups[groups++] = &lm63_group_temp2_type;
 		data->groups[groups++] = &lm63_group_extra_lut;
+	} else if (data->kind == ctf2301) {
+		data->groups[groups++] = &lm63_group_extra_lut;
 	}
 
 	hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
 							   data, data->groups);
-	return PTR_ERR_OR_ZERO(hwmon_dev);
+	if (IS_ERR(hwmon_dev))
+		return PTR_ERR(hwmon_dev);
+
+	if (IS_ENABLED(CONFIG_THERMAL_OF) &&
+	    of_property_present(dev->of_node, "#cooling-cells")) {
+		cdev = devm_thermal_of_cooling_device_register(dev, 0,
+							       client->name,
+							       data,
+							       &lm63_cooling_ops);
+		if (IS_ERR(cdev))
+			return PTR_ERR(cdev);
+	}
+
+	return 0;
 }
 
 /*
@@ -1288,6 +1536,7 @@ static const struct i2c_device_id lm63_id[] = {
 	{ .name = "lm63", .driver_data = lm63 },
 	{ .name = "lm64", .driver_data = lm64 },
 	{ .name = "lm96163", .driver_data = lm96163 },
+	{ .name = "ctf2301", .driver_data = ctf2301 },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, lm63_id);
@@ -1305,6 +1554,10 @@ static const struct of_device_id __maybe_unused lm63_of_match[] = {
 		.compatible = "national,lm96163",
 		.data = (void *)lm96163
 	},
+	{
+		.compatible = "sensylink,ctf2301",
+		.data = (void *)ctf2301
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, lm63_of_match);

-- 
2.55.0

[PATCH v2 5/6] riscv: dts: spacemit: Add K3 I2C6 pinctrl state

[Troy Mitchell]

Add the K3 I2C6 pinctrl state used by boards that route I2C6 to
pads 7 and 8. Leave board-specific IO voltage selection to board
files.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
---
 arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
index 3ee1471f3798..91cd08099e27 100644
--- a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
@@ -78,6 +78,17 @@ gmac1-phy-0-pins {
 		};
 	};
 
+	/omit-if-no-ref/
+	i2c6_1_cfg: i2c6-1-cfg {
+		i2c6-1-pins {
+			pinmux = <K3_PADCONF(7, 6)>,	/* i2c6 scl */
+				 <K3_PADCONF(8, 6)>;	/* i2c6 sda */
+
+			bias-pull-up = <0>;
+			drive-strength = <18>;
+		};
+	};
+
 	/omit-if-no-ref/
 	i2c8_cfg: i2c8-cfg {
 		i2c8-pins {

-- 
2.55.0

[PATCH v2 6/6] riscv: dts: spacemit: Add CTF2301 on K3 CoM260

[Troy Mitchell]

Enable I2C6 on the K3 CoM260 module and describe the Sensylink
CTF2301 temperature sensor and fan controller at address 0x4c.

Set the I2C6 pin power source in the board-level pinctrl node
because the IO rail voltage is board-specific.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
---
 arch/riscv/boot/dts/spacemit/k3-com260.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/riscv/boot/dts/spacemit/k3-com260.dtsi b/arch/riscv/boot/dts/spacemit/k3-com260.dtsi
index a38d7b738258..95a60fbb411f 100644
--- a/arch/riscv/boot/dts/spacemit/k3-com260.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3-com260.dtsi
@@ -26,6 +26,25 @@ reg_5v_sys: regulator-5v-sys {
 	};
 };
 
+&pinctrl {
+	i2c6-1-cfg {
+		i2c6-1-pins {
+			power-source = <3300>;
+		};
+	};
+};
+
+&i2c6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6_1_cfg>;
+	status = "okay";
+
+	temperature-sensor@4c {
+		compatible = "sensylink,ctf2301";
+		reg = <0x4c>;
+	};
+};
+
 &i2c8 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c8_cfg>;

-- 
2.55.0

Re: [PATCH v2 1/6] dt-bindings: vendor-prefixes: Add Sensylink

[sashiko-bot]

> Add the vendor prefix for Sensylink Microelectronics.
> 
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-ctl2301-v2-0-ef5fb342872a@linux.dev?part=1

Re: [PATCH v2 3/6] dt-bindings: hwmon: Add Sensylink CTF2301

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `sensylink,ctf2301` compatible string is added to a flat `enum` instead of allowing a fallback, preventing the device from using existing driver support.
--

--- Patch [3]: [PATCH v2 3/6] dt-bindings: hwmon: Add Sensylink CTF2301 ---
commit 2d1df9d4d4d9fa27f7828b7715766842a51c0154
Author: Troy Mitchell <troy.mitchell@linux.dev>
Subject: dt-bindings: hwmon: Add Sensylink CTF2301

This commit adds the Sensylink CTF2301 temperature sensor and fan controller
to the LM63 family binding. It updates the device tree schema to accept the
new compatible string.

> diff --git a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
> index 92b0094ff3034..4a1ffebfdbef6 100644
> --- a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
[ ... ]
> @@ -23,6 +24,7 @@ properties:
>        - national,lm63
>        - national,lm64
>        - national,lm96163
> +      - sensylink,ctf2301

[Severity: Medium]
Since the commit message mentions this device follows the LM63 register
model, should this compatible string allow a fallback to "national,lm63"
instead of being added to this flat enum?

Without a fallback, and since no driver update is included to add the new
ID, could this cause a regression where the existing Linux driver fails to
match and probe the device when a device tree specifies only
"sensylink,ctf2301"?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-ctl2301-v2-0-ef5fb342872a@linux.dev?part=3

Re: [PATCH v2 2/6] dt-bindings: hwmon: Move LM63 family to a dedicated binding

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing `interrupts` property in the newly created LM63 device tree binding.
--

--- Patch [2]: [PATCH v2 2/6] dt-bindings: hwmon: Move LM63 family to a dedicated binding ---
commit 5cb7233d8984d02f9823102bcec286ee4ef134d5
Author: Troy Mitchell <troy.mitchell@linux.dev>

dt-bindings: hwmon: Move LM63 family to a dedicated binding

This commit moves the National Semiconductor LM63, LM64, and LM96163
compatibles out of trivial-devices.yaml and into a dedicated schema. It also
describes their integrated fan control and thermal cooling device capabilities.

> diff --git a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
> new file mode 100644
> index 0000000000000..92b0094ff3034
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml

[ ... ]

> +properties:
> +  compatible:
> +    enum:
> +      - national,lm63
> +      - national,lm64
> +      - national,lm96163
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#cooling-cells":
> +    const: 2

[Severity: Medium]
Should the interrupts property be explicitly defined in this block?

Because the LM63 family was moved out of trivial-devices.yaml (which broadly 
permitted the interrupts property) to a dedicated schema using
unevaluatedProperties: false, device trees that correctly describe the 
hardware's interrupt capability via the ALERT# pin will now incorrectly fail 
dtbs_check validation.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-ctl2301-v2-0-ef5fb342872a@linux.dev?part=2

Re: [PATCH v2 4/6] hwmon: (lm63) Add Sensylink CTF2301 support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unchecked I2C reads for LSB are bitwise-ORed into 16-bit register values, corrupting data on read errors.
--

--- Patch [4]: [PATCH v2 4/6] hwmon: (lm63) Add Sensylink CTF2301 support ---
commit bbf54143e45eb1b3b9599d60a55904a5184333c9
Author: Troy Mitchell <troy.mitchell@linux.dev>

hwmon: (lm63) Add Sensylink CTF2301 support

This commit adds support for the Sensylink CTF2301 chip to the lm63 driver.
It introduces extended local temperature resolution and optional thermal
cooling device registration.

> diff --git a/drivers/hwmon/lm63.c b/drivers/hwmon/lm63.c
> index e2a429e579ac1..764a7467afa60 100644
> --- a/drivers/hwmon/lm63.c
> +++ b/drivers/hwmon/lm63.c

[ ... ]

> @@ -256,8 +270,16 @@ static struct lm63_data *lm63_update_device(struct device *dev)
>  
>  		data->temp8[0] = i2c_smbus_read_byte_data(client,
>  				 LM63_REG_LOCAL_TEMP);
> +		if (data->kind == ctf2301)
> +			data->temp1_input = ((u16)(u8)data->temp8[0] << 8)
> +					  | i2c_smbus_read_byte_data(client,
> +						CTF2301_REG_LOCAL_TEMP_LSB);
>  		data->temp8[1] = i2c_smbus_read_byte_data(client,
>  				 LM63_REG_LOCAL_HIGH);
> +		if (data->kind == ctf2301)
> +			data->temp1_max = ((u16)(u8)data->temp8[1] << 8)
> +					  | i2c_smbus_read_byte_data(client,
> +						CTF2301_REG_LOCAL_HIGH_LSB);

[Severity: Medium]
Will this corrupt the temperature reading if the I2C read fails?

In lm63_update_device(), if i2c_smbus_read_byte_data() for the LSB returns
a negative error code (such as -EIO), it gets bitwise-ORed with the shifted
MSB. The negative s32 error code would sign-extend, overwriting the MSB
bits entirely and resulting in a large negative temperature spike instead
of propagating the error or maintaining the previous valid reading.

Could we check the return value of i2c_smbus_read_byte_data() before
merging it into temp1_input and temp1_max?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-ctl2301-v2-0-ef5fb342872a@linux.dev?part=4

Re: [PATCH v2 6/6] riscv: dts: spacemit: Add CTF2301 on K3 CoM260

[sashiko-bot]

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

Pre-existing issues:
- [High] PWM duty cycle calculation can overflow and wrap around to 0, completely turning off the fan when maximum speed is requested.
--

--- Patch [6]: [PATCH v2 6/6] riscv: dts: spacemit: Add CTF2301 on K3 CoM260 ---
commit 2adeea2e46046fc26168a60ad26929de961f2f43
Author: Troy Mitchell <troy.mitchell@linux.dev>

riscv: dts: spacemit: Add CTF2301 on K3 CoM260

This commit enables I2C6 on the K3 CoM260 module. It sets the I2C6 pin power
source and describes the Sensylink CTF2301 temperature sensor and fan
controller.

> diff --git a/arch/riscv/boot/dts/spacemit/k3-com260.dtsi b/arch/riscv/boot/dts/spacemit/k3-com260.dtsi
> index a38d7b738258d..95a60fbb411f8 100644
> --- a/arch/riscv/boot/dts/spacemit/k3-com260.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k3-com260.dtsi
> @@ -26,6 +26,25 @@ reg_5v_sys: regulator-5v-sys {
>  	};
>  };
>  
> +&pinctrl {
> +	i2c6-1-cfg {
> +		i2c6-1-pins {
> +			power-source = <3300>;
> +		};
> +	};
> +};
> +
> +&i2c6 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c6_1_cfg>;
> +	status = "okay";
> +
> +	temperature-sensor@4c {
> +		compatible = "sensylink,ctf2301";

[Severity: High]
This isn't a bug introduced by this patch, but adding this sensor node
exposes a pre-existing PWM duty cycle calculation overflow in the lm63
driver.

When the fan controller computes the duty cycle in drivers/hwmon/lm63.c:

drivers/hwmon/lm63.c:lm63_pwm_to_reg() {
    ...
    return (val * data->pwm1_freq * 2 + LM63_MAX_PWM / 2) / LM63_MAX_PWM;
}

If the bootloader configures a low PWM frequency (setting the register > 127),
data->pwm1_freq will exceed 127 without bounds checking.

When maximum cooling is requested (val = 255), the arithmetic evaluates to
256 or more. Because the function returns a u8, the value implicitly
truncates and wraps around to 0.

Can this completely turn off the fan when maximum cooling is requested?

> +		reg = <0x4c>;
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-ctl2301-v2-0-ef5fb342872a@linux.dev?part=6

Re: [PATCH v2 5/6] riscv: dts: spacemit: Add K3 I2C6 pinctrl state

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `drive-strength` value `18` is invalid according to the SpacemiT K3 pinctrl binding schema, causing `dtbs_check` validation failures.
--

--- Patch [5]: [PATCH v2 5/6] riscv: dts: spacemit: Add K3 I2C6 pinctrl state ---
commit 7b36908eb32982b060ee59a7f9ad3d2f49fdd88e
Author: Troy Mitchell <troy.mitchell@linux.dev>

riscv: dts: spacemit: Add K3 I2C6 pinctrl state

This commit adds the I2C6 pinctrl state for K3 boards that route to pads 7 
and 8, omitting the board-specific IO voltage selection.

> diff --git a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
> index 3ee1471f37985..91cd08099e276 100644
> --- a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
> @@ -78,6 +78,17 @@ gmac1-phy-0-pins {

[ ... ]

> +	/omit-if-no-ref/
> +	i2c6_1_cfg: i2c6-1-cfg {
> +		i2c6-1-pins {
> +			pinmux = <K3_PADCONF(7, 6)>,	/* i2c6 scl */
> +				 <K3_PADCONF(8, 6)>;	/* i2c6 sda */
> +
> +			bias-pull-up = <0>;
> +			drive-strength = <18>;

[Severity: Low]
Is this drive-strength value supported by the binding? The value 18 doesn't
appear to be valid according to the SpacemiT K3 pinctrl binding schema
(spacemit,k1-pinctrl.yaml), which triggers a dtbs_check validation failure.

Since the driver's spacemit_get_ds_value() will silently fall back to the 
next highest valid value (like 21mA or 25mA depending on voltage), could 
this cause an unexpected mismatch between the requested devicetree state 
and the actual hardware configuration?

> +		};
> +	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-ctl2301-v2-0-ef5fb342872a@linux.dev?part=5

Re: [PATCH v2 2/6] dt-bindings: hwmon: Move LM63 family to a dedicated binding

[Troy Mitchell]

On Tue, Jul 21, 2026 at 09:58:20AM +0000, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Should the interrupts property be explicitly defined in this block?
>
> Because the LM63 family was moved out of trivial-devices.yaml (which
> broadly permitted the interrupts property) to a dedicated schema using
> unevaluatedProperties: false, device trees that correctly describe the
> hardware's interrupt capability via the ALERT# pin will now incorrectly
> fail dtbs_check validation.

Good catch. The trivial-devices binding allowed one interrupt, and the
LM63 family has an ALERT output. I will preserve that part of the existing
binding contract by adding the following to the dedicated binding:

  interrupts:
    maxItems: 1

                                            - Troy

Re: [PATCH v2 4/6] hwmon: (lm63) Add Sensylink CTF2301 support

[Troy Mitchell]

On Tue, Jul 21, 2026 at 10:00:04AM +0000, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Will this corrupt the temperature reading if the I2C read fails?
>
> In lm63_update_device(), if i2c_smbus_read_byte_data() for the LSB returns
> a negative error code (such as -EIO), it gets bitwise-ORed with the shifted
> MSB. The negative s32 error code would sign-extend, overwriting the MSB
> bits entirely and resulting in a large negative temperature spike instead
> of propagating the error or maintaining the previous valid reading.
>
> Could we check the return value of i2c_smbus_read_byte_data() before
> merging it into temp1_input and temp1_max?

Good catch. A failed read must not be combined with the other temperature
byte. I will read both bytes into temporary integers, check both return
values, and update the cached 12-bit value only after both reads succeed.

The existing lm63_update_device() also truncates or combines unchecked
i2c_smbus_read_byte_data() results in several other paths. I will address
those existing error-handling issues in a separate patch, rather than mix
that broader change into the CTF2301 support patch.

                                            - Troy

Re: [PATCH v2 5/6] riscv: dts: spacemit: Add K3 I2C6 pinctrl state

[Troy Mitchell]

On Tue, Jul 21, 2026 at 10:00:38AM +0000, sashiko-bot@kernel.org wrote:
> [Severity: Low]
> Is this drive-strength value supported by the binding? The value 18
> doesn't appear to be valid according to the SpacemiT K3 pinctrl binding
> schema (spacemit,k1-pinctrl.yaml), which triggers a dtbs_check validation
> failure.
>
> Since the driver's spacemit_get_ds_value() will silently fall back to the
> next highest valid value (like 21mA or 25mA depending on voltage), could
> this cause an unexpected mismatch between the requested devicetree state
> and the actual hardware configuration?

Good catch. This pin group uses the 3.3 V power domain, for which 18 mA is
not a valid K3 drive-strength value. The driver rounds that request up to
25 mA, so I will use 25 mA in the devicetree to describe the configuration
that is actually programmed and to satisfy the binding.

                                            - Troy

Re: [PATCH v2 3/6] dt-bindings: hwmon: Add Sensylink CTF2301

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Tue, Jul 21, 2026 at 02:48:29AM -0700, Troy Mitchell wrote:
> Add the Sensylink CTF2301 temperature sensor and fan controller to the
> LM63 family binding. The chip follows the LM63 register model and can
> provide a thermal cooling device when #cooling-cells is present.

Commit message should explain why a fallback compatible is not suitable.

pw-bot: changes-requested

Thanks,
Conor.

> 
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
> ---
>  Documentation/devicetree/bindings/hwmon/national,lm63.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
> index 92b0094ff303..4a1ffebfdbef 100644
> --- a/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/national,lm63.yaml
> @@ -12,7 +12,8 @@ maintainers:
>  description: |
>    The LM63 family provides local and remote temperature monitoring together
>    with fan speed monitoring and PWM fan control. Supported devices include
> -  the National Semiconductor LM63, LM64 and LM96163.
> +  the National Semiconductor LM63, LM64 and LM96163, and the Sensylink
> +  CTF2301.
>  
>  allOf:
>    - $ref: hwmon-common.yaml#
> @@ -23,6 +24,7 @@ properties:
>        - national,lm63
>        - national,lm64
>        - national,lm96163
> +      - sensylink,ctf2301
>  
>    reg:
>      maxItems: 1
> 
> -- 
> 2.55.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 1/6] dt-bindings: vendor-prefixes: Add Sensylink

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Tue, Jul 21, 2026 at 02:48:27AM -0700, Troy Mitchell wrote:
> Add the vendor prefix for Sensylink Microelectronics.
> 
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
> ---
>  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..22d0d26f1bbd 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1467,6 +1467,8 @@ patternProperties:
>      description: Sensirion AG
>    "^sensortek,.*":
>      description: Sensortek Technology Corporation
> +  "^sensylink,.*":
> +    description: Sensylink Microelectronics Technology Co., Ltd.

Googling the company to see what their website is, I seem to see a
different name for the company: Shanghai Sensylink Microelectronics Inc.
Their website has that with the Shanghai dropped.

Also, probably the commit message should contain
Link: https://en.sensylink.com/

pw-bot: changes-requested

Thanks,
Conor.

>    "^sercomm,.*":
>      description: Sercomm (Suzhou) Corporation
>    "^sff,.*":
> 
> -- 
> 2.55.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 1/6] dt-bindings: vendor-prefixes: Add Sensylink

[Guenter Roeck]

On 7/21/26 08:49, Conor Dooley wrote:
> On Tue, Jul 21, 2026 at 02:48:27AM -0700, Troy Mitchell wrote:
>> Add the vendor prefix for Sensylink Microelectronics.
>>
>> Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
>> ---
>>   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..22d0d26f1bbd 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> @@ -1467,6 +1467,8 @@ patternProperties:
>>       description: Sensirion AG
>>     "^sensortek,.*":
>>       description: Sensortek Technology Corporation
>> +  "^sensylink,.*":
>> +    description: Sensylink Microelectronics Technology Co., Ltd.
> 
> Googling the company to see what their website is, I seem to see a
> different name for the company: Shanghai Sensylink Microelectronics Inc.
> Their website has that with the Shanghai dropped.
> 
> Also, probably the commit message should contain
> Link: https://en.sensylink.com/
> 

Asking Google search: "Why the two names ? Did they rename themselves at some point ?"

Response:

Understanding the Name Structure

1. English Legal Name vs. Marketing Abbreviation

Sensylink Microelectronics Technology Co., Ltd.:
This is the literal translation of their full, formal registered corporate name
used for international trade, customs, and legal documentation.

Sensylink Microelectronics Inc.:
This is a simplified, Westernized abbreviation used on their official
English website and marketing materials for cleaner global branding.

2. The Native Chinese Name

上海申矽凌微电子科技股份有限公司 (Shanghai Shenxiling Microelectronics Technology
Co., Ltd.): This is the company's sole, official legal name registered with
the Chinese government.

"Sensylink" is a portmanteau created specifically for international markets,
blending "Sensing" (their core technology) and "Link" (their interface and
connectivity products).

Prodding further, asking if the previous response was complete, it tells
me that there was a name change:

According to Chinese corporate registry data (via Tianyancha and Qcc),
they did change their official Chinese legal name:

Old Name: 上海申矽凌微电子科技有限公司 (Shanghai Sensylink Microelectronics Technology
Co., Ltd.)

New Name: 上海申矽凌微电子科技股份有限公司 (Shanghai Sensylink Microelectronics Technology
Co., Ltd. by Shares / Joint-Stock Company)

I don't know if Linux has a policy about Legal vs. Marketing names. Personally
I don't have an opinion. Your call, really.

Guenter