[PATCH RFC] mmc: pwrseq_simple: Handle !RESET_CONTROLLER properly

[Stefan Wahren]

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 at gmx.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