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: <09df45e1-90b5-4618-9197-c724142bd83a@salutedevices.com>
Date: Fri, 23 Jan 2026 23:40:32 +0300
From: George Stark <gnstark@...utedevices.com>
To: Nick Xie <nick@...das.com>
CC: <robh@...nel.org>, <khilman@...libre.com>, <jbrunet@...libre.com>,
	<martin.blumenstingl@...glemail.com>, <neil.armstrong@...aro.org>,
	<devicetree@...r.kernel.org>, <linux-amlogic@...ts.infradead.org>,
	<conor+dt@...nel.org>, "kernel@...utedevices.com" <kernel@...utedevices.com>,
	<linux-arm-kernel@...ts.infradead.org>, <krzk+dt@...nel.org>,
	<xianwei.zhao@...ogic.com>, <linux-kernel@...r.kernel.org>,
	<nick@...qinick.com>
Subject: Re: [DMARC error] [PATCH v3 3/3] arm64: dts:
 meson-s4-s905y4-khadas-vim1s: add initial device tree

Hello Nick

On 1/15/26 06:00, Nick Xie wrote:
> The Khadas VIM1S uses the Amlogic S905Y4 SoC, based on the
> Amlogic S4 SoC family, on a board with the same form factor as the
> VIM/VIM2/VIM3/VIM4 models. Serial debug console, ethernet, SD card
> work with this initial device tree.

...

> +	};
> +
> +	/* SY8120B1ABC DC/DC Regulator. */
> +	vddcpu: regulator-vddcpu {
> +		compatible = "pwm-regulator";
> +
> +		regulator-name = "VDDCPU";
> +		regulator-min-microvolt = <689000>;
> +		regulator-max-microvolt = <1049000>;
> +
> +		vin-supply = <&main_5v>;
> +
> +		pwms = <&pwm_ij 1 1500 0>;
> +		pwm-dutycycle-range = <100 0>;
> +
> +		regulator-boot-on;
> +		regulator-always-on;
> +		/* Voltage Duty-Cycle */
> +		voltage-table = <1049000 0>,
> +				<1039000 3>,
> +				<1029000 6>,
> +				<1019000 9>,
> +				<1009000 12>,
> +				<999000 14>,
> +				<989000 17>,
> +				<979000 20>,
> +				<969000 23>,
> +				<959000 26>,
> +				<949000 29>,
> +				<939000 31>,
> +				<929000 34>,
> +				<919000 37>,
> +				<909000 40>,
> +				<899000 43>,
> +				<889000 45>,
> +				<879000 48>,
> +				<869000 51>,
> +				<859000 54>,
> +				<849000 56>,
> +				<839000 59>,
> +				<829000 62>,
> +				<819000 65>,
> +				<809000 68>,
> +				<799000 70>,
> +				<789000 73>,
> +				<779000 76>,
> +				<769000 79>,
> +				<759000 81>,
> +				<749000 84>,
> +				<739000 87>,
> +				<729000 89>,
> +				<719000 92>,
> +				<709000 95>,
> +				<699000 98>,
> +				<689000 100>;
> +	};
> +};

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.

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

-- 
Best regards
George