Skip to contentSkip to conversation

hwmon: (lm63) Add Sensylink CTF2301 support

PATCH Superseded Troy Mitchell 5 participants 20 messages Aug 5 – Aug 27

Subsystems (5)

v3 of 5 Superseded Latest is v5 →

lore
Share & tools
lore
#0 lore raw

v3 cover hwmon: (lm63) Add Sensylink CTF2301 support

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/[email protected]/

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

---
Changes in v3:
- Add the Sensylink website link to the vendor-prefix commit.
- Preserve the optional interrupt from the trivial-devices binding.
- Explain in the commit message of patch 3/6 why CTF2301 cannot use national,lm63 as a fallback compatible.
- Check both bytes of CTF2301 local temperature values before caching them.
- Use the schema-valid 25 mA drive strength for the K3 I2C6 pins.
- Link to v2: https://patch.msgid.link/[email protected]

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/[email protected]

To: Rob Herring <[email protected]>
To: Krzysztof Kozlowski <[email protected]>
To: Conor Dooley <[email protected]>
To: Guenter Roeck <[email protected]>
To: Paul Walmsley <[email protected]>
To: Palmer Dabbelt <[email protected]>
To: Albert Ou <[email protected]>
To: Alexandre Ghiti <[email protected]>
To: Yixun Lan <[email protected]>
To: Jonathan Corbet <[email protected]>
To: Shuah Khan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]

---
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   |  55 +++
 .../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                               | 414 +++++++++++++++++----
 8 files changed, 453 insertions(+), 84 deletions(-)

---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20250916-ctl2301-0416b073c280

Best regards,

Signature · 1 line
Troy Mitchell <[email protected]>
#1 lore raw

PATCH v3 1/6 dt-bindings: vendor-prefixes: Add Sensylink

Add the vendor prefix for Sensylink Microelectronics.

---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
index 396044f368e7..22d0d26f1bbd 100644
@@ -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,.*":
Signature · 1 line
2.55.0
#2 lore raw

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

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

Add the vendor prefix for Sensylink Microelectronics.

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

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
#4 lore raw

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

In reply to 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 preserve the optional interrupt used by the ALERT output. Permit use as thermal cooling devices via #cooling-cells.

---
 .../devicetree/bindings/hwmon/national,lm63.yaml   | 53 ++++++++++++++++++++++
 .../devicetree/bindings/trivial-devices.yaml       |  6 ---
 2 files changed, 53 insertions(+), 6 deletions(-)
Documentation/devicetree/bindings/hwmon/national,lm63.yaml new file +53 -0
new file mode 100644
index 000000000000..f2e0993cfbef
@@ -0,0 +1,53 @@
+# 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 <[email protected]>
+
+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
+
+  interrupts:
+    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>;
+        };
+    };
Documentation/devicetree/bindings/trivial-devices.yaml +0 -6
index 435c4baab436..aa62d245464c 100644
@@ -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
Signature · 1 line
2.55.0
#5 lore raw

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

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

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 preserve the optional interrupt used by the ALERT output. Permit use as thermal cooling devices via #cooling-cells.

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

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Reviewed-by on v3 2/6
#6 lore raw

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

In reply to Troy Mitchell
Quoted 10 lines · 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 preserve the optional interrupt used by the ALERT output. Permit use as thermal cooling devices via #cooling-cells.

---
 .../devicetree/bindings/hwmon/national,lm63.yaml   | 53 ++++++++++++++++++++++
 .../devicetree/bindings/trivial-devices.yaml       |  6 ---
 2 files changed, 53 insertions(+), 6 deletions(-)

Best regards,
Krzysztof

#7 lore raw

PATCH v3 3/6 dt-bindings: hwmon: Add Sensylink CTF2301

In reply to 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.

Do not provide a national,lm63 fallback because the CTF2301 is not fully compatible with LM63. It uses different conversion-rate encodings, extended local-temperature registers, additional fan lookup table entries, and device-specific PWM and ALERT/TACH configuration. An older LM63 driver would therefore not operate the device correctly.

---
 Documentation/devicetree/bindings/hwmon/national,lm63.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/hwmon/national,lm63.yaml +3 -1
index f2e0993cfbef..4c8d0a15fbd1 100644
@@ -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
Signature · 1 line
2.55.0
#8 lore raw

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

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

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.

Do not provide a national,lm63 fallback because the CTF2301 is not fully compatible with LM63. It uses different conversion-rate encodings, extended local-temperature registers, additional fan lookup table entries, and device-specific PWM and ALERT/TACH configuration. An older LM63 driver would therefore not operate the device correctly.

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

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
Acked-by on v3 3/6
#9 lore raw

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

In reply to Troy Mitchell
Quoted 10 lines · 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.

Do not provide a national,lm63 fallback because the CTF2301 is not fully compatible with LM63. It uses different conversion-rate encodings, extended local-temperature registers, additional fan lookup table entries, and device-specific PWM and ALERT/TACH configuration. An older LM63 driver would therefore not operate the device correctly.

Quoted 4 lines
---
 Documentation/devicetree/bindings/hwmon/national,lm63.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Best regards,
Krzysztof

#10 lore raw

PATCH v3 4/6 hwmon: (lm63) Add Sensylink CTF2301 support

In reply to 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.

---
 Documentation/hwmon/lm63.rst |  22 +++
 drivers/hwmon/Kconfig        |   8 +-
 drivers/hwmon/lm63.c         | 414 +++++++++++++++++++++++++++++++++++--------
 3 files changed, 366 insertions(+), 78 deletions(-)
Documentation/hwmon/lm63.rst +22 -0
index 9e27367d7405..c40bd0dfe591 100644
@@ -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 <[email protected]>
 
@@ -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.
drivers/hwmon/Kconfig +4 -4
index 2bfbcc033d59..abb1af8664fb 100644
@@ -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.
drivers/hwmon/lm63.c +340 -74

664 lines not on this page · raw message

Signature · 1 line
2.55.0
#11 lore raw
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: - [High] Missing Kconfig dependency causes undefined reference to devm_thermal_of_cooling_device_register.…

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing Kconfig dependency causes undefined reference to devm_thermal_of_cooling_device_register.
- [Medium] Missing lock around 16-bit variable read in show_local_temp8.
- [Medium] Handling of I2C write errors in pwm1_freq_store permanently desynchronizes the driver's software state from the hardware state. --

--- Patch [4]: [PATCH v3 4/6] hwmon: (lm63) Add Sensylink CTF2301 support --- commit 951fc5c354ae91e1c67e85c453464f893528203b
Author: Troy Mitchell <[email protected]>

hwmon: (lm63) Add Sensylink CTF2301 support

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.

drivers/hwmon/Kconfig config SENSORS_LM63 · line 1501

Quoted 6 lines
drivers/hwmon/Kconfig +0 -0
index 2bfbcc033d599..abb1af8664fb3 100644
@@ -1501,10 +1501,10 @@ config SENSORS_LM63
 	depends on I2C

[Severity: High]
Could this lead to a linker error if the user configures the kernel with CONFIG_THERMAL=m and CONFIG_SENSORS_LM63=y?

CONFIG_THERMAL_OF is a boolean, so it can be enabled even when the thermal subsystem is built as a module. If the driver is built-in, the IS_ENABLED check in lm63_probe evaluates to true, causing the built-in driver to call devm_thermal_of_cooling_device_register from the modular thermal_sys.

Should there be a dependency like depends on THERMAL || THERMAL=n here to prevent this configuration?

[ ... ]

Quoted 4 lines
drivers/hwmon/lm63.c +0 -0
index e2a429e579ac1..3887f02b924d1 100644

[ ... ]

Quoted 14 lines
drivers/hwmon/lm63.c +6 -4
@@ -512,35 +573,55 @@ static ssize_t pwm1_freq_store(struct device *dev,
 
 	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,

drivers/hwmon/lm63.c static ssize_t pwm1_freq_store(struct device *dev, · line 591

Quoted 10 lines
drivers/hwmon/lm63.c +9 -0
+					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);

[Severity: Medium]
Is it possible for the hardware state to desynchronize from the software state if an I2C error occurs here?

If a user writes to the pwm1_freq sysfs attribute and the first I2C write succeeds, but the second fails, the function aborts early via goto unlock. Because the internal data structure is only updated at the end of the function, the early abort leaves the hardware updated while the software caches remain unmodified.

Would it be safer to update the software state incrementally as the writes succeed, or revert the hardware state on failure?

[ ... ]

drivers/hwmon/lm63.c static ssize_t show_local_temp8(struct device *dev, · line 643

Quoted 9 lines
drivers/hwmon/lm63.c +5 -0
@@ -555,6 +636,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));
+

[Severity: Medium]
Does this lockless read introduce a data race?

The 16-bit variables data->temp1_max and data->temp1_input are read here without holding data->update_lock. However, these values are updated under the lock in set_temp8 when a user concurrently modifies the temperature limit via sysfs.

Could this result in a torn read or reading partially updated state, causing an incorrect temperature limit to be reported to user-space?

Quoted 2 lines
drivers/hwmon/lm63.c +0 -0
 	return sprintf(buf, "%d\n", TEMP8_FROM_REG(data->temp8[attr->index]));
 }

[ ... ]

Quoted 10 lines
drivers/hwmon/lm63.c +2 -0
@@ -1273,11 +1519,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);

drivers/hwmon/lm63.c static int lm63_probe(struct i2c_client *client) · line 1536

Quoted 10 lines
drivers/hwmon/lm63.c +9 -1
-	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);

[Severity: High]
Could calling devm_thermal_of_cooling_device_register without a proper Kconfig dependency cause undefined references during the build?

As noted above, if CONFIG_THERMAL=m and CONFIG_SENSORS_LM63=y, this path will be reached by a built-in driver trying to resolve a symbol exported by a loadable module.

Quoted 6 lines
drivers/hwmon/lm63.c +5 -0
+		if (IS_ERR(cdev))
+			return PTR_ERR(cdev);
+	}
+
+	return 0;
 }
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4
maintainer
#12 lore raw
In reply to Troy Mitchell
Quoted 66 lines · 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.

---
 Documentation/hwmon/lm63.rst |  22 +++
 drivers/hwmon/Kconfig        |   8 +-
 drivers/hwmon/lm63.c         | 414 +++++++++++++++++++++++++++++++++++--------
 3 files changed, 366 insertions(+), 78 deletions(-)
Documentation/hwmon/lm63.rst +22 -0
index 9e27367d7405..c40bd0dfe591 100644
@@ -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 <[email protected]>
 
@@ -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.
drivers/hwmon/Kconfig +0 -0
index 2bfbcc033d59..abb1af8664fb 100644

drivers/hwmon/Kconfig config SENSORS_LM63 · line 1501

Quoted 1 line
drivers/hwmon/Kconfig +0 -0
@@ -1501,10 +1501,10 @@ config SENSORS_LM63
 	depends on I2C

This seems to be missing the THERMAL dependency as suggested by Sashiko.

...

drivers/hwmon/Kconfig config SENSORS_LM63 · line 1502

Quoted 2 lines
drivers/hwmon/Kconfig +1 -1
-enum chips { lm63, lm64, lm96163 };
+enum chips { lm63, lm64, lm96163, ctf2301 };

Alphabetic order, please.

drivers/hwmon/Kconfig config SENSORS_LM63 · line 1509

Quoted 7 lines
drivers/hwmon/Kconfig +7 -0
+		if (data->kind == ctf2301) {
+			msb = i2c_smbus_read_byte_data(client,
+						       LM63_REG_LOCAL_TEMP);
+			lsb = i2c_smbus_read_byte_data(client,
+						       CTF2301_REG_LOCAL_TEMP_LSB);
+			if (msb >= 0 && lsb >= 0) {
+				data->temp8[0] = msb;

Why keep the assignments to data->temp8[0] and data->temp8[1] ?

Thanks,
Guenter

#13 lore raw

PATCH v3 5/6 riscv: dts: spacemit: Add K3 I2C6 pinctrl state

In reply to Troy Mitchell

Add the K3 I2C6 pinctrl state used by boards that route I2C6 to pads 7 and 8. Use a 25 mA drive strength, which is supported for both K3 IO voltage domains, and leave board-specific IO voltage selection to board files.

---
 arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)
arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi +11 -0
index 3ee1471f3798..e50f3e4b5536 100644
@@ -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 = <25>;
+		};
+	};
+
 	/omit-if-no-ref/
 	i2c8_cfg: i2c8-cfg {
 		i2c8-pins {
Signature · 1 line
2.55.0
#14 lore raw

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

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

Add the K3 I2C6 pinctrl state used by boards that route I2C6 to pads 7 and 8. Use a 25 mA drive strength, which is supported for both K3 IO voltage domains, and leave board-specific IO voltage selection to board files.

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

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5
#15 lore raw

PATCH v3 6/6 riscv: dts: spacemit: Add CTF2301 on K3 CoM260

In reply to 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.

---
 arch/riscv/boot/dts/spacemit/k3-com260.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
arch/riscv/boot/dts/spacemit/k3-com260.dtsi +19 -0
index a38d7b738258..95a60fbb411f 100644
@@ -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>;
Signature · 1 line
2.55.0
#16 lore raw

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

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

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.

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

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6
maintainer
#17 lore raw

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

In reply to Troy Mitchell

hi Troy,

Quoted 19 lines · 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.

---
 arch/riscv/boot/dts/spacemit/k3-com260.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
arch/riscv/boot/dts/spacemit/k3-com260.dtsi +0 -0
index a38d7b738258..95a60fbb411f 100644
@@ -26,6 +26,25 @@ reg_5v_sys: regulator-5v-sys {
 	};
 };
 

..

arch/riscv/boot/dts/spacemit/k3-com260.dtsi reg_5v_sys: regulator-5v-sys { · line 30

Quoted 2 lines

+&pinctrl {

arch/riscv/boot/dts/spacemit/k3-com260.dtsi +1 -0
+	i2c6-1-cfg {

I'd prefer to use the reference, keep it short & close to where it's used

&i2c6_1_cfg

Quoted 24 lines
arch/riscv/boot/dts/spacemit/k3-com260.dtsi +17 -0
+		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>;
Signature · 2 lines
-- 
2.55.0
Signature · 1 line
Yixun Lan (dlan)
#18 lore raw

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

Quoted 6 lines

arch/riscv/boot/dts/spacemit/k3-com260.dtsi reg_5v_sys: regulator-5v-sys { · line 30

Quoted 2 lines

+&pinctrl {

arch/riscv/boot/dts/spacemit/k3-com260.dtsi +1 -0
+	i2c6-1-cfg {

I'd prefer to use the reference, keep it short & close to where it's used

&i2c6_1_cfg

Quoted 16 lines
Quoted 6 lines
arch/riscv/boot/dts/spacemit/k3-com260.dtsi +6 -0
+		i2c6-1-pins {
+			power-source = <3300>;
+		};
+	};
+};
+

arch/riscv/boot/dts/spacemit/k3-com260.dtsi reg_5v_sys: regulator-5v-sys { · line 46

Quoted 10 lines
arch/riscv/boot/dts/spacemit/k3-com260.dtsi +10 -0
+&i2c6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6_1_cfg>;
+	status = "okay";
+
+	temperature-sensor@4c {
+		compatible = "sensylink,ctf2301";
+		reg = <0x4c>;
+	};
+};

My intention here was to keep all board-specific pin configuration overrides under a single &pinctrl block, so that they can be found and maintained in one place. Using a separate top-level reference for each pin group would tend to scatter those overrides throughout the board DTS as more groups are customized. The &pinctrl block is also placed immediately before the &i2c6 consumer.

Would keeping the current structure be acceptable for that reason? If you still prefer the direct reference, I will change it to &i2c6_1_cfg in the next revision.

- Troy

#19 lore raw

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

Quoted 10 lines · Troy Mitchell

My intention here was to keep all board-specific pin configuration overrides under a single &pinctrl block, so that they can be found and maintained in one place. Using a separate top-level reference for each pin group would tend to scatter those overrides throughout the board DTS as more groups are customized. The &pinctrl block is also placed immediately before the &i2c6 consumer.

Would keeping the current structure be acceptable for that reason? If you still prefer the direct reference, I will change it to &i2c6_1_cfg in the next revision.

I withdraw my earlier suggestion to keep all board-specific pin configuration overrides under a single &pinctrl block.

After checking existing board DTS files, I found that the direct-reference style is already in use. For example:

arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts

adds the board-specific bias-pull-up setting directly through &i2c1_pins. Likewise:

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi

extends &mmc0_pins directly.

Both forms produce the same node override, but since the reference-based form is already used in the tree, we should follow it instead of introducing a different structure here. I will change the board-level override to &i2c6_1_cfg in the next version.

- Troy