linux-kernel - Re: [PATCH v4] arm64: dts: rockchip: Fix SD card init on rk3399-nanopi4

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: <17a4c6f6-d79c-a7b2-860f-e5944b778f9f@arm.com>
Date:   Fri, 15 Jul 2022 19:11:39 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Christian Kohlschütter 
        <christian@...lschutter.com>, wens@...nel.org,
        Heiko Stübner <heiko@...ech.de>,
        Markus Reichl <m.reichl@...etechno.de>
Cc:     linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linux MMC List <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH v4] arm64: dts: rockchip: Fix SD card init on
 rk3399-nanopi4

On 2022-07-15 18:16, Christian Kohlschütter wrote:
> OK, this took me a while to figure out.
> 
> When no undervoltage limit is configured, I can reliably trigger the initialization bug upon boot.
> When the limit is set to 3.0V, it rarely occurs, but just after I send the v3 patch, I was able to reproduce...

Well this has to be in the running for "weirdest placebo ever"... :/

All it actually seems to achieve is printing an error[1] (this is after 
all a tiny 5-pin fixed-voltage LDO regulator, not an intelligent PMIC), 
and if that makes an appreciable difference then there has to be some 
kind of weird timing condition at play. Maybe regulator_register() ends 
up turning it off and on again rapidly enough that the card sees a 
voltage brownout and glitches, and adding more delay by printing to the 
console somewhere in the middle gives it enough time to act as a proper 
power cycle with no ill effect?

If you just whack something like an mdelay(500) at around that point in 
set_machine_constraints(), without the DT property, does it have the 
same effect?

Robin.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/core.c#n1521

>> Am 15.07.2022 um 19:12 schrieb Christian Kohlschütter <christian@...lschutter.com>:
>>
>> mmc/SD-card initialization may fail on NanoPi R4S with
>> "mmc1: problem reading SD Status register" /
>> "mmc1: error -110 whilst initialising SD card"
>> either on cold boot or after a reboot.
>>
>> Moreover, the system would also sometimes hang upon reboot.
>>
>> This is prevented by setting an explicit undervoltage protection limit
>> for the SD-card-specific vcc3v0_sd voltage regulator.
>>
>> Set the undervoltage protection limit to 2.7V, which is the minimum
>> permissible SD card operating voltage.
>>
>> Signed-off-by: Christian Kohlschütter <christian@...lschutter.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 4 ++++
>> 1 file changed, 4 insertions(+)
>> mode change 100644 => 100755 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
>> old mode 100644
>> new mode 100755
>> index 8c0ff6c96e03..669c74ce4d13
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
>> @@ -73,6 +73,10 @@ vcc3v0_sd: vcc3v0-sd {
>> 		regulator-always-on;
>> 		regulator-min-microvolt = <3000000>;
>> 		regulator-max-microvolt = <3000000>;
>> +
>> +		// must be configured or SD card may fail to initialize occasionally
>> +		regulator-uv-protection-microvolt = <2700000>;
>> +
>> 		regulator-name = "vcc3v0_sd";
>> 		vin-supply = <&vcc3v3_sys>;
>> 	};
>> -- 
>> 2.36.1
>