linux-kernel - Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

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: <20251030130006.0221957a@karo-electronics.de>
Date: Thu, 30 Oct 2025 13:00:06 +0100
From: Lothar Waßmann <LW@...O-electronics.de>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Maud Spierings <maudspierings@...ontroll.com>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
 <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics
 tx8m-1610 COM

Hi,

On Thu, 30 Oct 2025 13:01:52 +0200 Matti Vaittinen wrote:
> On 30/10/2025 10:54, Lothar Waßmann wrote:
> > Hi,
> > 
> > On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote:  
> >> Hi Matti,
> >>
> >> On 10/29/25 11:05, Matti Vaittinen wrote:  
> >>> On 29/10/2025 11:48, Lothar Waßmann wrote:  
> >>>> Hi,
> >>>>
> >>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote:  
> >>>>> On 29/10/2025 09:11, Lothar Waßmann wrote:  
> >>>>>> Hi,
> >>>>>>
> >>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote:  
> >>>>>>> On 10/28/25 13:42, Maud Spierings wrote:  
> >>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote:  
> >>>>>> [...]  
> >>>>>>>>> Could/Should this be described using the:
> >>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and
> >>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment
> >>>>>>>>> correctly, that might allow the driver to be able to use correctly
> >>>>>>>>> scaled voltages.
> >>>>>>>>>
> >>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/
> >>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108  
> >>>>>>>>  
> 
> // snip
> 
> >>>>>
> >>>>> If real voltages aren't matching what is calculated by the driver, then
> >>>>> the voltages requested by regulator consumers will cause wrong voltages
> >>>>> to be applied. Debug interfaces will also show wrong voltages, and the
> >>>>> safety limits set in the device-tree will not be really respected.
> >>>>>
> >>>>> I think this would be well worth fixing.
> >>>>>     
> >>>> Before doing the real-life test I did the same calculation that's done
> >>>> in the driver to be sure that it will generate the correct values:
> >>>> bc 1.07.1
> >>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017
> >>>> Free Software Foundation, Inc.
> >>>> This is free software with ABSOLUTELY NO WARRANTY.
> >>>> For details type `warranty'.
> >>>> fb_uv=0
> >>>> r1=2200
> >>>> r2=499
> >>>> min=800000
> >>>> step=10000
> >>>> # default voltage without divider
> >>>> min+30*step
> >>>> 1100000
> >>>> min=min-(fb_uv-min)*r2/r1
> >>>> step=step*(r1+r2)/r1
> >>>> min
> >>>> 981454
> >>>> step
> >>>> 12268
> >>>> # default voltage with divider
> >>>> min+30*step
> >>>> 1349494
> >>>>
> >>>> Probably we need to use this value rather than the nominal 135000 as
> >>>> the target voltage in the DTB.  
> >>>
> >>> Yes. When the driver calculates the voltages which match the actual
> >>> voltages, then you should also use the actual voltages in the device-tree.
> >>>      
> >>  
> 
> // snip
> 
> >>
> >> Then setting 1349494 as the actual voltage makes it fully work.
> >> Otherwise it complains:
> >> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL
> >>
> >> Final debug output now:
> >> [    0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000
> >> [    0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268
> >> [    0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up
> >> configured
> >>
> >> I will add this fix to the next version of this patchset and include
> >> your requested change in the dts.
> >>  
> > Does it also work with min/max settings in the DTS that are taken from
> > the designated value +/- 5% tolerance margin, so that the DTS contains
> > reasonable values determined by the HW requirements, rather than some
> > artificial number that is enforced by the SW behaviour?  
> 
> I am unsure what you mean by "artificial number that is enforced by the 
> SW behaviour"?
> 
The nominal voltage that is required by the consumer is 1.35 V. That's
the voltage I would expect to set as target for the regulator.
If that voltage cannot be achieved exactly, I would prefer to have the
intended voltage listed explicitly rather than listing a value that
accidentally can be achieved by the regulator but has nothing to do with
the requirements of the consumer.

> I don't know why there should be two different min values? Assuming the 
> latter should be max - I have no problem seeing a range of allowed 
>
My copypaste is obviously spoiled... ;)


Lothar Waßmann