linux-kernel - Re: [PATCH RFC] mmc: pwrseq_simple: Handle !RESET

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: <e42a6573-fc0d-4a12-9895-09c1889fc759@gmx.net>
Date: Mon, 4 Nov 2024 20:37:25 +0100
From: Stefan Wahren <wahrenst@....net>
To: Mark Brown <broonie@...nel.org>
Cc: Philipp Zabel <p.zabel@...gutronix.de>,
 Ulf Hansson <ulf.hansson@...aro.org>,
 Catalin Popescu <catalin.popescu@...ca-geosystems.com>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 Marco Felsch <m.felsch@...gutronix.de>,
 linux-arm-kernel@...ts.infradead.org, linux-mmc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
 regressions@...ts.linux.dev
Subject: Re: [PATCH RFC] mmc: pwrseq_simple: Handle !RESET_CONTROLLER properly

Hi Mark,

Am 04.11.24 um 10:39 schrieb Marco Felsch:
> Hi Stefan,
>
> On 24-11-02, Stefan Wahren wrote:
>> The recent introduction of reset control in pwrseq_simple introduced
>> a regression for platforms without RESET_CONTROLLER support, because
> This is what I was afraid of :/
>
>> devm_reset_control_get_optional_shared() would return NULL and make all
>> resets no-ops. Instead of enforcing this dependency rely on this behavior
>> to determine reset support. As a benefit we can get the rid of the
>> use_reset flag.
>>
>> Fixes: 73bf4b7381f7 ("mmc: pwrseq_simple: add support for one reset control")
>> Signed-off-by: Stefan Wahren <wahrenst@....net>
>> ---
>>   drivers/mmc/core/pwrseq_simple.c | 16 +++++++---------
>>   1 file changed, 7 insertions(+), 9 deletions(-)
>>
>> Hi,
>> will trying to reproduce the Rpi 4 regression from here [1], I found
>> the issue above. I'm pretty sure the Rpi 4 regression is caused by the same
>> commit. Unfortunately I wasn't able to reproduce it.
>>
>> [1] - https://lore.kernel.org/linux-next/6724d7d5.170a0220.1281e9.910a@mx.google.com/T/#u
I think i've a better unterstanding of the regression in your case. I
noticed on my Raspberry Pi 3 B+ that this change in combination with
arm64/defconfig causes a huge delay until wifi is probed (~ 32 seconds).
Maybe this is caused by the fact that RESET_GPIO is build as a module,
while PWRSEQ_SIMPLE is builtin. But this doesn't explain why the driver
seem to never probe in your case.

Regards