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: <1929240.tdWV9SEqCh@diego>
Date: Sun, 27 Apr 2025 13:14:58 +0200
From: Heiko StĂĽbner <heiko@...ech.de>
To: linux-rockchip@...ts.infradead.org, Hao Zhang <hao.zhang@...lkit.cn>
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 conor+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org,
 linux-kernel@...r.kernel.org, "hao.zhang" <hao.zhang@...lkit.cn>
Subject:
 Re: [PATCH 1/1] ARM: dts: rockchip: Wifi improvements for Sonoff iHost

Hi,

Am Sonntag, 27. April 2025, 08:50:13 Mitteleuropäische Sommerzeit schrieb Hao Zhang:
> From: "hao.zhang" <hao.zhang@...lkit.cn>
> 
> After some Sonoff-iHosts have been running for a long time, 
> the WiFi module will run abnormally.
> 
> Adjust the pmu_io_domains and sdio properties 
> to solve the WiFi module operation abnormality.

"adjust the ... properties", really sounds like hacking around some issue.

> diff --git a/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
> index 9a87dc0d5f66..3c0371103015 100644
> --- a/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
> @@ -323,15 +323,15 @@ wifi_enable_h: wifi-enable-h {
>  };
>  
>  &pmu_io_domains {
> -	pmuio0-supply = <&vcc1v8_pmu>;
> +	pmuio0-supply = <&vcc3v3_sys>;
>  	pmuio1-supply = <&vcc3v3_sys>;
>  	vccio1-supply = <&vcc_1v8>;
>  	vccio2-supply = <&vccio_sd>;
> -	vccio3-supply = <&vcc3v3_sd>;
> -	vccio4-supply = <&vcc_dovdd>;
> -	vccio5-supply = <&vcc_1v8>;
> -	vccio6-supply = <&vcc_1v8>;
> -	vccio7-supply = <&vcc_dovdd>;
> +	vccio3-supply = <&vcc_3v3>;
> +	vccio4-supply = <&vcc_3v3>;
> +	vccio5-supply = <&vcc_3v3>;
> +	vccio6-supply = <&vcc_3v3>;
> +	vccio7-supply = <&vcc_1v8>;
>  	status = "okay";
>  };

First of all, this would be two patches.  If the io-domains do not follow
the schematics, fixing this is one patch, but for such a big change
I do expect actual references to the devices' schematics for that.

This is even more important, as you're switching some supplies
between sources of different voltages


> @@ -342,18 +342,15 @@ &saradc {
>  
>  &sdio {
>  	bus-width = <4>;
> -	cap-sd-highspeed;
>  	cap-sdio-irq;
>  	keep-power-in-suspend;
> -	max-frequency = <50000000>;
> +	max-frequency = <25000000>;
>  	mmc-pwrseq = <&sdio_pwrseq>;
> +	supports-sdio;
>  	non-removable;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc1_clk &sdmmc1_cmd &sdmmc1_bus4>;
>  	rockchip,default-sample-phase = <90>;
> -	sd-uhs-sdr50;
> -	vmmc-supply = <&vcc3v3_sd>;
> -	vqmmc-supply = <&vcc_1v8>;
>  	status = "okay";
>  };

and here it looks like you're more or less randomly adding and removing
properties until it worked "for you".

Especially removing the supply-regulators does not really make sense.
If you see instabilities, the main contenders would be max-frequency and
sd-uhs-sdr50 as culprits.

Similarly, supports-sdio is not even a valid property, so neither the
devicetree spec does allow it, nor does the kernel handle it at all.


Heiko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ