Messages in this thread | | | Date | Tue, 25 Oct 2022 14:45:11 -0700 | From | Brian Norris <> | Subject | Re: [PATCH v3 6/7] mmc: sdhci_am654: Fix SDHCI_RESET_ALL for CQHCI |
| |
On Tue, Oct 25, 2022 at 04:10:44PM +0300, Adrian Hunter wrote: > On 24/10/22 20:55, Brian Norris wrote: > > diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c > > index 8f1023480e12..6a282c7a221e 100644 > > --- a/drivers/mmc/host/sdhci_am654.c > > +++ b/drivers/mmc/host/sdhci_am654.c
> > @@ -378,7 +379,7 @@ static void sdhci_am654_reset(struct sdhci_host *host, u8 mask) > > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); > > struct sdhci_am654_data *sdhci_am654 = sdhci_pltfm_priv(pltfm_host); > > > > - sdhci_reset(host, mask); > > + sdhci_and_cqhci_reset(host, mask); > > > > if (sdhci_am654->quirks & SDHCI_AM654_QUIRK_FORCE_CDTEST) { > > ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); > > What about sdhci_reset in sdhci_am654_ops ?
Oops, I think you caught a big fallacy in some of my patches: I assumed there was a single reset() implementation in a given driver (an unwise assumption, I realize). I see at least sdhci-brcmstb.c also has several variant ops that call sdhci_reset(), and I should probably convert them too.
I'll take another pass through the series for v4, fixing this and the other smaller cosmetic issues. I may retain some Acks, depending on whether I think the changes are substantial.
Thanks, Brian
| |