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] [day] [month] [year] [list]
Message-ID: <045c408f-6d52-4135-ae82-bc8598c41fab@roeck-us.net>
Date: Mon, 9 Feb 2026 08:09:41 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: ashish yadav <ashishyadav78@...il.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-hwmon@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 ASHISH YADAV <Ashish.Yadav@...ineon.com>
Subject: Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage
 Regulator Driver

On 2/8/26 21:04, ashish yadav wrote:
> Hi Guenter,
> 
> I hope you are doing well.
> 
> Please find my response inline.
> 
> With Best Regards
>    Ashish Yadav
> 
> 
> On Mon, Feb 2, 2026 at 5:59 AM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On 1/22/26 03:42, ashish yadav wrote:
>>> Hi Guenter,
>>>
>>> Please find my response inline.
>>>
>>> Thanks & Regards
>>>      Ashish Yadav
>>>
>>> On Tue, Jan 13, 2026 at 8:40 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>>>
>>>> On 1/12/26 23:24, ashish yadav wrote:
>>>>
>>>>>> The need for this, especially why it would only be needed for PMBUS_READ_VOUT
>>>>>> but not for any other VOUT related commands, is still insufficiently explained
>>>>>> (and I failed to understand the rationale provided earlier).
>>>>>>
>>>>>
>>>>> It is specifically needed for READ_VOUT as it is being used by
>>>>> external controller to monitor the rail health.
>>>>> Other Vout related parameters are used internally in the IC to for
>>>>> output voltage related protections and does not impact any external
>>>>> decision making.
>>>>>
>>>>
>>>> Sorry, that doesn't really make sense. How would the chip know to match
>>>> VOUT with its VOUT limits if both don't use the same scale ?
>>>>
>>> The chip telemetry would still show Vout as 0.7V as it does not know
>>> about the external feedback resistors.
>>> Hence, no need to scale internal Vout related parameters.
>>> This scale is only for external vendor use to tweak their telemetry
>>> output voltage reading.
>>>
>>
>> You fail to explain why VOUT_SCALE_LOOP - which is supposed to handle such
>> situations - can not be used, and why it would be acceptable for other VOUT
>> related attributes such as VOUT_MIN, VOUT_MAX, VOUT_MARGIN_LOW, VOUT_MARGIN_HIGH,
>> and the various VOUT fault limits to show the wrong values.
>>
>> For reference:
>>
>> VOUT_SCALE_LOOP:
>> "Used to account for any external attenuation network on VOUT sense
>>    feedback and provide correct VOUT reporting."
>>
> 
> TDA38725A/TDA38740A has only two options of vout_scale_loop. These are
> 1 and 0.5.
> If the output voltage is directly connected to the output rail, then
> vout_scale_loop = 1 as there is no resistor divider in the feedback
> and feedback voltage is equal to the actual output voltage.
> 
> If vout_scale_loop = 0.5, it is recommended to use a resistor divider
> (top & bottom – 499ohms each) with a ratio of  0.5 in the feedback
> path.
> In this case, feedback voltage will be 0.5 x actual output voltage.
> As the vout_scale_loop is set to 0.5, IC would use this
> vout_scale_loop internally to provide the correct telemetry data.
> 
> If a customer uses a resistor divider of 2.21k (top) & 22.1k (bottom),
> the divider ratio would be (2.21/22.1 + 2.21 = 0.09).

Is that theory or practice ?

> This is not an option available in the IC as it can only identify 1 and 0.5.
> In this case, they configure the IC in vout_scale_loop of 1 and use a
> multiplier in Linux code to correct the READ_VOUT telemetry voltage.
> 
> Why can vout_scale_loop not be used?
> Using vout_scale_loop for correction will also impact all the Vout
> related parameters and makes it cumbersome.

No, it causes the other values to be reported correctly. There is nothing
cumbersome about that. It would be not cumbersome but troubling and
potentially critical to have the chip report adjusted voltages but raw
limits.

> To simplify the linux code, customers prefer changing only Read_Vout
> value and accept that IC would still operate based on vout_scale_loop
> value configured to 1.

That explains why vout_scale_loop can not be used, assuming that the
use case is real. It does not explain why it would make sense to only
adjust READ_VOUT but not all the limits, nor does it explain if this
is an actual use case or just theory.

I am inclined to suggest that a devicetree property should only
indicate if vout_scale_loop is 1:1 or 1:2, and that all other
adjustments should be handled in the sensors configuration file.
What is completely unacceptable, customer desire or not, is to just
adjust READ_VOUT and not all other VOUT related register values.

Thanks,
Guenter


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ