linux-kernel - Re: 回复: [DMARC error] [PATCH v3 3/3] arm64: dts: meson-s4-s905y4-khadas-vim1s: add initial device tree

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: <CAFBinCDcDy4M79+mM+axsqXLfoQ56Ucd1C-OHkGLxwNkpfZ-zQ@mail.gmail.com>
Date: Mon, 9 Feb 2026 23:31:40 +0100
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: George Stark <gnstark@...utedevices.com>
Cc: Nick Xie <nick@...das.com>, "robh@...nel.org" <robh@...nel.org>, 
	"khilman@...libre.com" <khilman@...libre.com>, "jbrunet@...libre.com" <jbrunet@...libre.com>, 
	"neil.armstrong@...aro.org" <neil.armstrong@...aro.org>, 
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, 
	"linux-amlogic@...ts.infradead.org" <linux-amlogic@...ts.infradead.org>, 
	"conor+dt@...nel.org" <conor+dt@...nel.org>, "kernel@...utedevices.com" <kernel@...utedevices.com>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "xianwei.zhao@...ogic.com" <xianwei.zhao@...ogic.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 回复: [DMARC error] [PATCH v3 3/3] arm64: dts: meson-s4-s905y4-khadas-vim1s: add initial device tree

Hi George,

sorry for the late reply.

On Thu, Jan 29, 2026 at 3:48 PM George Stark <gnstark@...utedevices.com> wrote:
>
>
>
> On 1/26/26 12:35, Nick Xie wrote:
> >> Thanks for the patch. Since you have khadas mail I'm pretty sure you've
> >> had the possibility to test it on the real vim board and I just don't
> >> get it how it works with the voltage table above. The problem is that
> >> pwm is calculated incorrectly in the upstream pwm-meson driver. That
> >> voltage table appeared to be used in early amlogic bl loader and
> >> appropriate pwm is initialized from a table's record. Duty cycle value
> >> is translated to pwm regs correctly. Later when kernel start running
> >> pwm-regulator driver is probed. It reads the pwm regs, calculates back
> >> duty-cyle and search it in the table. Since calculation algos are not
> >> match and the table doesn't contain full range of 0-100% values
> >> regulator driver doesn't find current voltage. In such case regulator
> >> core sets the minimum voltage from the table [1] and the SoC may hang
> >> (depending on board) due to minimum voltage may be too low for the
> >> current frequency SoC uses.
Nick likely didn't spot any issues on S4 since CPU frequency scaling
is not upstreamed yet (as there's no way to control the CPU clock
yet).
The lack of a OPP table means: the PWM and CPU clock will just stay at
whatever the bootloader provides

> >> Or I'm missing something?
> >
> >
> >> There's not-yet-reviewed patch that fixes pwm algo [2]. There's
> >> calculation example in the cover letter.
> >> [1] https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/regulator/core.c#L1227
> >> [2] https://lkml.iu.edu/2412.3/00826.html
> >
> > What's the status of such patches?
>
> the patch is ready for review. It's seems like nobody is interested
I'm sorry to see that the patch had it's first anniversary.
I'll need to bring out my logic analyzer and test your patch (I hope
it's precise enough to show the impact of your changes).
Are your plans then to re-send the patches or have you moved on and
need someone else to take care of it?


Best regards,
Martin