linux-kernel - Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency

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: <2d2a2638-8213-5d6e-0a3a-927ed5bb2ed7@i2se.com>
Date:   Thu, 25 Mar 2021 20:11:24 +0100
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-mmc@...r.kernel.org,
        devicetree@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com,
        linux-rpi-kernel@...ts.infradead.org,
        Rob Herring <robh+dt@...nel.org>
Cc:     f.fainelli@...il.com, phil@...pberrypi.com,
        tim.gover@...pberrypi.com, adrian.hunter@...el.com,
        sbranden@...adcom.com, alcooperx@...il.com,
        linux-kernel@...r.kernel.org, ulf.hansson@...aro.org
Subject: Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency

Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:
> Hi Stefan,
>
> On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
>> Hi Nicolas,
>>
>> Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
>>> From: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
>>>
>>> Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
>>> seems to interfere with the VPU clock when setup at frequencies bigger
>>> than 500MHz (a pretty common case). This ends up causing unwarranted
>>> SDHCI CMD hangs  when no SD card is present.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne <nsaenz@...nel.org>
>>> ---
>>>  arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>> index 3b4ab947492a..9aa8408d9960 100644
>>> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>> @@ -257,6 +257,12 @@ &emmc2 {
>>>  	vqmmc-supply = <&sd_io_1v8_reg>;
>>>  	vmmc-supply = <&sd_vcc_reg>;
>>>  	broken-cd;
>>> +	/*
>>> +	 * Force the frequency to 150MHz as the default 100MHz seems to
>>> +	 * interfere with the VPU clock when setup at frequencies bigger than
>>> +	 * 500MHz, causing unwarranted CMD hangs.
>>> +	 */
>>> +	clock-frequency = <150000000>;
>> i don't want to bike-shed here, but is there any chance to solve this in
>> clk-bcm2835 in a less hacky way?
> What do you have in mind?
Sorry, nothing specific.
>
> All I can think of is adding some kind of heuristic to the clock's prepare()
> callback. That said, I don't feel it would be a better solution than this.

Based on my limited knowledge and an old SD card specification, all
possibly connected devices could have different frequencies. So my
concern here is, that in case we limit the frequency to a specific value
we could break things just to suppress a warning.

More background information about this issue would be helpful.

Best regards