On 6/30/21 12:24 PM, Linus Walleij wrote:
If we find a reset handle when probing the MMCI block,
make sure the reset is de-asserted. It could happen that
a hardware has reset asserted at boot. >
Hi Linus,
I was wondering on which HW you saw this issue?
But I've seen this kind of thing is also done in some other drivers, so
maybe it is just an alignment?
Anyway I tested it on STM32MP157C-EV1 board, so feel free to add my:
Tested-by: Yann Gautier <yann.gautier@xxxxxxxxxxx>
Regards,
Yann
Cc: Russell King <linux@xxxxxxxxxxxxxxx>
Cc: Yann Gautier <yann.gautier@xxxxxxxxxxx>
Cc: Ludovic Barre <ludovic.barre@xxxxxx>
Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
---
ChangeLog v1->v2:
- Drop the else {} clause: reset_control_deassert() handles
NULL just fine.
---
drivers/mmc/host/mmci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 984d35055156..3765e2f4ad98 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -2126,6 +2126,9 @@ static int mmci_probe(struct amba_device *dev,
ret = PTR_ERR(host->rst);
goto clk_disable;
}
+ ret = reset_control_deassert(host->rst);
+ if (ret)
+ dev_err(mmc_dev(mmc), "failed to de-assert reset\n");
/* Get regulators and the supported OCR mask */
ret = mmc_regulator_get_supply(mmc);
