Add a devicetree binding for the TSC1641 I2C power monitor.
Signed-off-by: Igor Reznichenko <igor@reznichenko.net>
---
.../devicetree/bindings/hwmon/st,tsc1641.yaml | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml b/Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml
new file mode 100644
index 000000000000..cfa0e2cca869
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/st,tsc1641.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST Microelectronics TSC1641 I2C power monitor
+
+maintainers:
+ - Igor Reznichenko <igor@reznichenko.net>
+
+description: |
+ TSC1641 is a 60 V, 16-bit high-precision power monitor with I2C and
+ MIPI I3C interface
+
+ Datasheets:
+ https://www.st.com/resource/en/datasheet/tsc1641.pdf
+
+properties:
+ compatible:
+ const: st,tsc1641
+
+ reg:
+ maxItems: 1
+
+ shunt-resistor-micro-ohms:
+ description: Shunt resistor value in micro-ohms. Since device has internal
+ 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at
+ 655.35 mOhm.
+ minimum: 100
+ default: 1000
+ maximum: 655350
+
+ st,alert-polarity-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Default value is 0 which configures the normal polarity of the
+ ALERT pin, being active low open-drain. Setting this to 1 configures the
+ polarity of the ALERT pin to be inverted and active high open-drain.
+ Specify this property to set the alert polarity to active-high.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-sensor@40 {
+ compatible = "st,tsc1641";
+ reg = <0x40>;
+ shunt-resistor-micro-ohms = <1000>;
+ st,alert-polarity-active-high;
+ };
+ };
--
2.43.0On 26/10/2025 07:50, Igor Reznichenko wrote: > +properties: > + compatible: > + const: st,tsc1641 Subject: I asked to drop "binding" and not add "support for". "Support for" makes little sense in terms of binding. How binding can support anything? This is the "ST TSC1641 power monitor" not support. > + > + reg: > + maxItems: 1 > + > + shunt-resistor-micro-ohms: > + description: Shunt resistor value in micro-ohms. Since device has internal > + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at > + 655.35 mOhm. > + minimum: 100 > + default: 1000 > + maximum: 655350 > + > + st,alert-polarity-active-high: Isn't this just interrupt? You need proper interrupts property and then its flag define the type of interrupt. Best regards, Krzysztof
> Subject: I asked to drop "binding" and not add "support for". "Support > for" makes little sense in terms of binding. How binding can support > anything? This is the "ST TSC1641 power monitor" not support. Krzysztof, Thanks for feedback, will fix this and will create following patch versions in new threads. >> + >> + reg: >> + maxItems: 1 >> + >> + shunt-resistor-micro-ohms: >> + description: Shunt resistor value in micro-ohms. Since device has internal >> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >> + 655.35 mOhm. >> + minimum: 100 >> + default: 1000 >> + maximum: 655350 >> + >> + st,alert-polarity-active-high: > >Isn't this just interrupt? You need proper interrupts property and then >its flag define the type of interrupt. This controls a bit written into device register. I omitted interrupt property after looking at existing power monitor bindings, especially hwmon/ti,ina2xx.yaml. INA226 has very similar bit controlling alert pin polarity and binding doesn't define alert pin as interrupt. Overall, I didn't find many power monitor bindings defining alert pins as interrupts. Thanks, Igor
On 26/10/2025 19:46, Igor Reznichenko wrote: >> Subject: I asked to drop "binding" and not add "support for". "Support >> for" makes little sense in terms of binding. How binding can support >> anything? This is the "ST TSC1641 power monitor" not support. > > Krzysztof, > > Thanks for feedback, will fix this and will create following patch versions > in new threads. > >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + shunt-resistor-micro-ohms: >>> + description: Shunt resistor value in micro-ohms. Since device has internal >>> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >>> + 655.35 mOhm. >>> + minimum: 100 >>> + default: 1000 >>> + maximum: 655350 >>> + >>> + st,alert-polarity-active-high: >> >> Isn't this just interrupt? You need proper interrupts property and then >> its flag define the type of interrupt. > > This controls a bit written into device register. > I omitted interrupt property after looking at existing power monitor bindings, > especially hwmon/ti,ina2xx.yaml. INA226 has very similar bit controlling alert > pin polarity and binding doesn't define alert pin as interrupt. Overall, I didn't > find many power monitor bindings defining alert pins as interrupts. On INA2xx that's SMBUS Alert. Is this the case here as well? Best regards, Krzysztof
On 10/26/25 12:41, Krzysztof Kozlowski wrote: > On 26/10/2025 19:46, Igor Reznichenko wrote: >>> Subject: I asked to drop "binding" and not add "support for". "Support >>> for" makes little sense in terms of binding. How binding can support >>> anything? This is the "ST TSC1641 power monitor" not support. >> >> Krzysztof, >> >> Thanks for feedback, will fix this and will create following patch versions >> in new threads. >> >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + shunt-resistor-micro-ohms: >>>> + description: Shunt resistor value in micro-ohms. Since device has internal >>>> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >>>> + 655.35 mOhm. >>>> + minimum: 100 >>>> + default: 1000 >>>> + maximum: 655350 >>>> + >>>> + st,alert-polarity-active-high: >>> >>> Isn't this just interrupt? You need proper interrupts property and then >>> its flag define the type of interrupt. >> >> This controls a bit written into device register. >> I omitted interrupt property after looking at existing power monitor bindings, >> especially hwmon/ti,ina2xx.yaml. INA226 has very similar bit controlling alert >> pin polarity and binding doesn't define alert pin as interrupt. Overall, I didn't >> find many power monitor bindings defining alert pins as interrupts. > > > On INA2xx that's SMBUS Alert. Is this the case here as well? > It could be wired to SMBus alert, or it could be wired to a CPU interrupt pin. Guenter
On 26/10/2025 20:58, Guenter Roeck wrote: >>>>> + reg: >>>>> + maxItems: 1 >>>>> + >>>>> + shunt-resistor-micro-ohms: >>>>> + description: Shunt resistor value in micro-ohms. Since device has internal >>>>> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >>>>> + 655.35 mOhm. >>>>> + minimum: 100 >>>>> + default: 1000 >>>>> + maximum: 655350 >>>>> + >>>>> + st,alert-polarity-active-high: >>>> >>>> Isn't this just interrupt? You need proper interrupts property and then >>>> its flag define the type of interrupt. >>> >>> This controls a bit written into device register. >>> I omitted interrupt property after looking at existing power monitor bindings, >>> especially hwmon/ti,ina2xx.yaml. INA226 has very similar bit controlling alert >>> pin polarity and binding doesn't define alert pin as interrupt. Overall, I didn't >>> find many power monitor bindings defining alert pins as interrupts. >> >> >> On INA2xx that's SMBUS Alert. Is this the case here as well? >> > > It could be wired to SMBus alert, or it could be wired to a CPU interrupt pin. So please explain me why CPU interrupt pin, which in every really every device called "interrupts", would not be "interrupts" here? How CPU can even guess the number of the interrupt in such case, without "interrupts" property? Best regards, Krzysztof
On 10/27/25 01:40, Krzysztof Kozlowski wrote: > On 26/10/2025 20:58, Guenter Roeck wrote: >>>>>> + reg: >>>>>> + maxItems: 1 >>>>>> + >>>>>> + shunt-resistor-micro-ohms: >>>>>> + description: Shunt resistor value in micro-ohms. Since device has internal >>>>>> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >>>>>> + 655.35 mOhm. >>>>>> + minimum: 100 >>>>>> + default: 1000 >>>>>> + maximum: 655350 >>>>>> + >>>>>> + st,alert-polarity-active-high: >>>>> >>>>> Isn't this just interrupt? You need proper interrupts property and then >>>>> its flag define the type of interrupt. >>>> >>>> This controls a bit written into device register. >>>> I omitted interrupt property after looking at existing power monitor bindings, >>>> especially hwmon/ti,ina2xx.yaml. INA226 has very similar bit controlling alert >>>> pin polarity and binding doesn't define alert pin as interrupt. Overall, I didn't >>>> find many power monitor bindings defining alert pins as interrupts. >>> >>> >>> On INA2xx that's SMBUS Alert. Is this the case here as well? >>> >> >> It could be wired to SMBus alert, or it could be wired to a CPU interrupt pin. > > So please explain me why CPU interrupt pin, which in every really every > device called "interrupts", would not be "interrupts" here? How CPU can > even guess the number of the interrupt in such case, without > "interrupts" property? > I thought we were discussing the need for the st,alert-polarity-active-high property, sorry. Guenter
On 27/10/2025 17:53, Guenter Roeck wrote: > On 10/27/25 01:40, Krzysztof Kozlowski wrote: >> On 26/10/2025 20:58, Guenter Roeck wrote: >>>>>>> + reg: >>>>>>> + maxItems: 1 >>>>>>> + >>>>>>> + shunt-resistor-micro-ohms: >>>>>>> + description: Shunt resistor value in micro-ohms. Since device has internal >>>>>>> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >>>>>>> + 655.35 mOhm. >>>>>>> + minimum: 100 >>>>>>> + default: 1000 >>>>>>> + maximum: 655350 >>>>>>> + >>>>>>> + st,alert-polarity-active-high: >>>>>> >>>>>> Isn't this just interrupt? You need proper interrupts property and then >>>>>> its flag define the type of interrupt. >>>>> >>>>> This controls a bit written into device register. >>>>> I omitted interrupt property after looking at existing power monitor bindings, >>>>> especially hwmon/ti,ina2xx.yaml. INA226 has very similar bit controlling alert >>>>> pin polarity and binding doesn't define alert pin as interrupt. Overall, I didn't >>>>> find many power monitor bindings defining alert pins as interrupts. >>>> >>>> >>>> On INA2xx that's SMBUS Alert. Is this the case here as well? >>>> >>> >>> It could be wired to SMBus alert, or it could be wired to a CPU interrupt pin. >> >> So please explain me why CPU interrupt pin, which in every really every >> device called "interrupts", would not be "interrupts" here? How CPU can >> even guess the number of the interrupt in such case, without >> "interrupts" property? >> > > I thought we were discussing the need for the st,alert-polarity-active-high > property, sorry. Yes, we kind of do, I am just trying to understand what is expressed here. If this is a CPU interrupt, its flags should mark the proper signal level, including inverter. If this is something else (or both), then this property might make sense, I just don't know what is this. Best regards, Krzysztof
On Mon, Oct 27, 2025 at 07:01:47PM +0100, Krzysztof Kozlowski wrote: > On 27/10/2025 17:53, Guenter Roeck wrote: > > On 10/27/25 01:40, Krzysztof Kozlowski wrote: > >> On 26/10/2025 20:58, Guenter Roeck wrote: > >>>>>>> + reg: > >>>>>>> + maxItems: 1 > >>>>>>> + > >>>>>>> + shunt-resistor-micro-ohms: > >>>>>>> + description: Shunt resistor value in micro-ohms. Since device has internal > >>>>>>> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at > >>>>>>> + 655.35 mOhm. > >>>>>>> + minimum: 100 > >>>>>>> + default: 1000 > >>>>>>> + maximum: 655350 > >>>>>>> + > >>>>>>> + st,alert-polarity-active-high: > >>>>>> > >>>>>> Isn't this just interrupt? You need proper interrupts property and then > >>>>>> its flag define the type of interrupt. > >>>>> > >>>>> This controls a bit written into device register. > >>>>> I omitted interrupt property after looking at existing power monitor bindings, > >>>>> especially hwmon/ti,ina2xx.yaml. INA226 has very similar bit controlling alert > >>>>> pin polarity and binding doesn't define alert pin as interrupt. Overall, I didn't > >>>>> find many power monitor bindings defining alert pins as interrupts. > >>>> > >>>> > >>>> On INA2xx that's SMBUS Alert. Is this the case here as well? > >>>> > >>> > >>> It could be wired to SMBus alert, or it could be wired to a CPU interrupt pin. > >> > >> So please explain me why CPU interrupt pin, which in every really every > >> device called "interrupts", would not be "interrupts" here? How CPU can > >> even guess the number of the interrupt in such case, without > >> "interrupts" property? > >> > > > > I thought we were discussing the need for the st,alert-polarity-active-high > > property, sorry. > > > Yes, we kind of do, I am just trying to understand what is expressed > here. If this is a CPU interrupt, its flags should mark the proper > signal level, including inverter. > > If this is something else (or both), then this property might make > sense, I just don't know what is this. If the device's polarity is programmable and there's possibly an inverter, you can't express both with just flags. In that case, flags should be the polarity after the inverter since flags are defined by the interrupt provider. So we'd need something to define the device side. Perhaps wait until someone actually has h/w with an inverter needing this. Rob
Understood. The bit in question controls the alert pin polarity on the device side, independent of whether the pin is used as interrupt or not. I'll drop the property for now and revisit if there's a board that actually uses an inverter or needs to program the bit explicitly. Thanks, Igor
On 10/28/25 08:17, Igor Reznichenko wrote: > Understood. The bit in question controls the alert pin polarity on the device side, > independent of whether the pin is used as interrupt or not. I'll drop the property > for now and revisit if there's a board that actually uses an inverter or needs to > program the bit explicitly. > This is kind of unusual. The requirement used to be that devicetree properties shall be complete. "Only if there is a known use case" is a significant policy change. Has the policy changed recently ? Thanks, Guenter
>On 10/28/25 08:17, Igor Reznichenko wrote: >> Understood. The bit in question controls the alert pin polarity on the device side, >> independent of whether the pin is used as interrupt or not. I'll drop the property >> for now and revisit if there's a board that actually uses an inverter or needs to >> program the bit explicitly. >> > >This is kind of unusual. The requirement used to be that devicetree properties >shall be complete. "Only if there is a known use case" is a significant policy >change. Has the policy changed recently ? > >Thanks, >Guenter Rob, following up on Guenter's question above. I'm not sure whether it's better to drop the property as discussed earlier or keep it for binding completeness. Could you clarify what approach is preferred? Thanks, Igor
On 31/10/2025 05:40, Igor Reznichenko wrote: >> On 10/28/25 08:17, Igor Reznichenko wrote: >>> Understood. The bit in question controls the alert pin polarity on the device side, >>> independent of whether the pin is used as interrupt or not. I'll drop the property >>> for now and revisit if there's a board that actually uses an inverter or needs to >>> program the bit explicitly. >>> >> >> This is kind of unusual. The requirement used to be that devicetree properties >> shall be complete. "Only if there is a known use case" is a significant policy >> change. Has the policy changed recently ? >> >> Thanks, >> Guenter > > Rob, following up on Guenter's question above. > I'm not sure whether it's better to drop the property as discussed earlier or keep > it for binding completeness. > Could you clarify what approach is preferred? Don't you have there possibility of interrupt (not only SMBus Alert)? At least this is what I understood from previous talks. Best regards, Krzysztof
>>> On 10/28/25 08:17, Igor Reznichenko wrote: >>>> Understood. The bit in question controls the alert pin polarity on the device side, >>>> independent of whether the pin is used as interrupt or not. I'll drop the property >>>> for now and revisit if there's a board that actually uses an inverter or needs to >>>> program the bit explicitly. >>>> >>> >>> This is kind of unusual. The requirement used to be that devicetree properties >>> shall be complete. "Only if there is a known use case" is a significant policy >>> change. Has the policy changed recently ? >>> >>> Thanks, >>> Guenter >> >> Rob, following up on Guenter's question above. >> I'm not sure whether it's better to drop the property as discussed earlier or keep >> it for binding completeness. >> Could you clarify what approach is preferred? > >Don't you have there possibility of interrupt (not only SMBus Alert)? At >least this is what I understood from previous talks. Yes, the alert pin could be used as interrupt in principle. Datasheet calls it "Multi-functional digital alert pin". Thanks, Igor
On 10/31/25 10:30, Igor Reznichenko wrote: >>>> On 10/28/25 08:17, Igor Reznichenko wrote: >>>>> Understood. The bit in question controls the alert pin polarity on the device side, >>>>> independent of whether the pin is used as interrupt or not. I'll drop the property >>>>> for now and revisit if there's a board that actually uses an inverter or needs to >>>>> program the bit explicitly. >>>>> >>>> >>>> This is kind of unusual. The requirement used to be that devicetree properties >>>> shall be complete. "Only if there is a known use case" is a significant policy >>>> change. Has the policy changed recently ? >>>> >>>> Thanks, >>>> Guenter >>> >>> Rob, following up on Guenter's question above. >>> I'm not sure whether it's better to drop the property as discussed earlier or keep >>> it for binding completeness. >>> Could you clarify what approach is preferred? >> >> Don't you have there possibility of interrupt (not only SMBus Alert)? At >> least this is what I understood from previous talks. > > Yes, the alert pin could be used as interrupt in principle. > Datasheet calls it "Multi-functional digital alert pin". > Maybe you could try adding an optional "interrupts" property. Guenter
On 10/26/25 09:32, Krzysztof Kozlowski wrote: > On 26/10/2025 07:50, Igor Reznichenko wrote: >> +properties: >> + compatible: >> + const: st,tsc1641 > > Subject: I asked to drop "binding" and not add "support for". "Support > for" makes little sense in terms of binding. How binding can support > anything? This is the "ST TSC1641 power monitor" not support. > >> + >> + reg: >> + maxItems: 1 >> + >> + shunt-resistor-micro-ohms: >> + description: Shunt resistor value in micro-ohms. Since device has internal >> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >> + 655.35 mOhm. >> + minimum: 100 >> + default: 1000 >> + maximum: 655350 >> + >> + st,alert-polarity-active-high: > > Isn't this just interrupt? You need proper interrupts property and then > its flag define the type of interrupt. > This is a value to write into the chip. It is orthogonal to how the interrupt is reported to the interrupt controller. It may be active low by the chip and inverted, or it may be active high by the chip and inverted. How does one express an additional inverter in the interrupt signal path in a devicetree property ? Can you give an example ? Thanks, Guenter
On 26/10/2025 18:22, Guenter Roeck wrote: > On 10/26/25 09:32, Krzysztof Kozlowski wrote: >> On 26/10/2025 07:50, Igor Reznichenko wrote: >>> +properties: >>> + compatible: >>> + const: st,tsc1641 >> >> Subject: I asked to drop "binding" and not add "support for". "Support >> for" makes little sense in terms of binding. How binding can support >> anything? This is the "ST TSC1641 power monitor" not support. >> >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + shunt-resistor-micro-ohms: >>> + description: Shunt resistor value in micro-ohms. Since device has internal >>> + 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at >>> + 655.35 mOhm. >>> + minimum: 100 >>> + default: 1000 >>> + maximum: 655350 >>> + >>> + st,alert-polarity-active-high: >> >> Isn't this just interrupt? You need proper interrupts property and then >> its flag define the type of interrupt. >> > > This is a value to write into the chip. It is orthogonal to how the interrupt > is reported to the interrupt controller. It may be active low by the chip and > inverted, or it may be active high by the chip and inverted. How does one express > an additional inverter in the interrupt signal path in a devicetree property ? > Can you give an example ? If that is the interrupt to the CPU, then it's just like I said - proper flag to the interrupts property. There is no need to express inverter separately from the interrupts, because that would mean you first express interrupts incorrectly and then you add inverter to make it correct. Just like people expressing RESET_N GPIO with ACTIVE_HIGH and then making reversed set high/low in the driver :/ Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.