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
