Re: [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@xxxxxxx>
> > ---
> >   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@xxxxxxxxxxxxx/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