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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <d0ebc09a-6122-4a52-823b-7cbb2b05741b@kernel.org>
Date: Sun, 26 Oct 2025 20:15:22 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>,
 Igor Reznichenko <igor@...nichenko.net>, linux-hwmon@...r.kernel.org
Cc: 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-kernel@...r.kernel.org, robh@...nel.org, skhan@...uxfoundation.org
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: Add support for ST TSC1641
 power monitor

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