linux-kernel - Re: [PATCH v2 1/2] dt-bindings: hwmon: Add support for ST TSC1641 power monitor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251027191425.GA1403533-robh@kernel.org>
Date: Mon, 27 Oct 2025 14:14:25 -0500
From: Rob Herring <robh@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Guenter Roeck <linux@...ck-us.net>,
	Igor Reznichenko <igor@...nichenko.net>, conor+dt@...nel.org,
	corbet@....net, david.hunter.linux@...il.com,
	devicetree@...r.kernel.org, krzk+dt@...nel.org,
	linux-doc@...r.kernel.org, linux-hwmon@...r.kernel.org,
	linux-kernel@...r.kernel.org, skhan@...uxfoundation.org
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: Add support for ST TSC1641
 power monitor

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