[PATCH 0/5] mmc: sdhci controllers: Fix SDHCI_RESET_ALL for CQHCI

[PATCH 0/5] mmc: sdhci controllers: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

This is a series of nearly identical fixes for several SDHCI host
drivers. The first patch (for sdhci-of-arasan) is the only one I've
tested, and I wrote it due to a bug described there.

I then noticed that several other drivers do the same thing, and that
commit df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for
Intel GLK-based controllers") points out the likely-repeated bug.

Thus, I include additional patches (compile-tested only) that apply
similar fixes to the other drivers which call cqhci_init() but not
cqhci_deactivate(). They contain appropriate disclaimers and the
relevant parties are CC'd. I would suggest only merging them if you get
some kind of ACK from people familiar with the relevant hardware.

Notably, I do *not* patch drivers/mmc/host/mtk-sd.c although it uses
CQHCI, because it doesn't seem to be an SDHCI-based controller, and so
even if it has a similar bug, it's not clear to me how to patch it.

- Brian


Brian Norris (5):
  mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
  mmc: sdhci-brcmstb: Fix SDHCI_RESET_ALL for CQHCI
  mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI
  mmc: sdhci-tegra: Fix SDHCI_RESET_ALL for CQHCI
  mmc: sdhci_am654: Fix SDHCI_RESET_ALL for CQHCI

 drivers/mmc/host/sdhci-brcmstb.c   |  7 ++++++-
 drivers/mmc/host/sdhci-esdhc-imx.c |  7 +++++++
 drivers/mmc/host/sdhci-of-arasan.c | 17 +++++++++++------
 drivers/mmc/host/sdhci-tegra.c     |  4 ++++
 drivers/mmc/host/sdhci_am654.c     |  3 +++
 5 files changed, 31 insertions(+), 7 deletions(-)

-- 
2.38.0.413.g74048e4d9e-goog

[PATCH 1/5] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
tracking that properly in software. When out of sync, we may trigger
various timeouts.

It's not typical to perform resets while CQE is enabled, but one
particular case I hit commonly enough: mmc_suspend() -> mmc_power_off().
Typically we will eventually deactivate CQE (cqhci_suspend() ->
cqhci_deactivate()), but that's not guaranteed -- in particular, if
we perform a partial (e.g., interrupted) system suspend.

The same bug was already found and fixed for two other drivers, in v5.7
and v5.9:

5cf583f1fb9c mmc: sdhci-msm: Deactivate CQE during SDHC reset
df57d73276b8 mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers

The latter is especially prescient, saying "other drivers using CQHCI
might benefit from a similar change, if they also have CQHCI reset by
SDHCI_RESET_ALL."

So like these other patches, deactivate CQHCI when resetting the
controller. Also, move around the DT/caps handling, because
sdhci_setup_host() performs resets before we've initialized CQHCI. This
is the pattern followed in other SDHCI/CQHCI drivers.

Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1")
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
---

 drivers/mmc/host/sdhci-of-arasan.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 3997cad1f793..1988a703781a 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -366,6 +366,10 @@ static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 	struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
 
+	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL) &&
+	    sdhci_arasan->has_cqe)
+		cqhci_deactivate(host->mmc);
+
 	sdhci_reset(host, mask);
 
 	if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_FORCE_CDTEST) {
@@ -1521,7 +1525,8 @@ static int sdhci_arasan_register_sdclk(struct sdhci_arasan_data *sdhci_arasan,
 	return 0;
 }
 
-static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan)
+static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan,
+				 struct device_node *np)
 {
 	struct sdhci_host *host = sdhci_arasan->host;
 	struct cqhci_host *cq_host;
@@ -1549,6 +1554,10 @@ static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan)
 	if (dma64)
 		cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
 
+	host->mmc->caps2 |= MMC_CAP2_CQE;
+	if (!of_property_read_bool(np, "disable-cqe-dcmd"))
+		host->mmc->caps2 |= MMC_CAP2_CQE_DCMD;
+
 	ret = cqhci_init(cq_host, host->mmc, dma64);
 	if (ret)
 		goto cleanup;
@@ -1705,13 +1714,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
 		host->mmc_host_ops.start_signal_voltage_switch =
 					sdhci_arasan_voltage_switch;
 		sdhci_arasan->has_cqe = true;
-		host->mmc->caps2 |= MMC_CAP2_CQE;
-
-		if (!of_property_read_bool(np, "disable-cqe-dcmd"))
-			host->mmc->caps2 |= MMC_CAP2_CQE_DCMD;
 	}
 
-	ret = sdhci_arasan_add_host(sdhci_arasan);
+	ret = sdhci_arasan_add_host(sdhci_arasan, np);
 	if (ret)
 		goto err_add_host;
 
-- 
2.38.0.413.g74048e4d9e-goog

[PATCH 2/5] mmc: sdhci-brcmstb: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

 [[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
tracking that properly in software. When out of sync, we may trigger
various timeouts.

It's not typical to perform resets while CQE is enabled, but this may
occur in some suspend or error recovery scenarios.

Move around the CQE caps handling, because sdhci_setup_host() performs
resets before we've initialized CQHCI. This is the pattern followed in
other SDHCI/CQHCI drivers.

Fixes: d46ba2d17f90 ("mmc: sdhci-brcmstb: Add support for Command Queuing (CQE)")
Signed-off-by: Brian Norris <briannorris@chromium.org>
---

 drivers/mmc/host/sdhci-brcmstb.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index aff36a933ebe..7f4bb362b923 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -55,6 +55,10 @@ static void brcmstb_reset(struct sdhci_host *host, u8 mask)
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
 
+	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL) &&
+	    (priv->flags & BRCMSTB_PRIV_FLAGS_HAS_CQE))
+		cqhci_deactivate(host->mmc);
+
 	sdhci_reset(host, mask);
 
 	/* Reset will clear this, so re-enable it */
@@ -209,7 +213,6 @@ static int sdhci_brcmstb_add_host(struct sdhci_host *host,
 		return sdhci_add_host(host);
 
 	dev_dbg(mmc_dev(host->mmc), "CQE is enabled\n");
-	host->mmc->caps2 |= MMC_CAP2_CQE | MMC_CAP2_CQE_DCMD;
 	ret = sdhci_setup_host(host);
 	if (ret)
 		return ret;
@@ -230,6 +233,8 @@ static int sdhci_brcmstb_add_host(struct sdhci_host *host,
 		cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
 	}
 
+	host->mmc->caps2 |= MMC_CAP2_CQE | MMC_CAP2_CQE_DCMD;
+
 	ret = cqhci_init(cq_host, host->mmc, dma64);
 	if (ret)
 		goto cleanup;
-- 
2.38.0.413.g74048e4d9e-goog

[PATCH 3/5] mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

 [[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
tracking that properly in software. When out of sync, we may trigger
various timeouts.

It's not typical to perform resets while CQE is enabled, but this may
occur in some suspend or error recovery scenarios.

Fixes: bb6e358169bf ("mmc: sdhci-esdhc-imx: add CMDQ support")
Signed-off-by: Brian Norris <briannorris@chromium.org>
---

 drivers/mmc/host/sdhci-esdhc-imx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 55981b0f0b10..222c83929e20 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1288,6 +1288,13 @@ static void esdhc_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
 
 static void esdhc_reset(struct sdhci_host *host, u8 mask)
 {
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
+
+	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL) &&
+	    imx_data->socdata->flags & ESDHC_FLAG_CQHCI)
+		cqhci_deactivate(host->mmc);
+
 	sdhci_reset(host, mask);
 
 	sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
-- 
2.38.0.413.g74048e4d9e-goog

[PATCH 4/5] mmc: sdhci-tegra: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

 [[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
tracking that properly in software. When out of sync, we may trigger
various timeouts.

It's not typical to perform resets while CQE is enabled, but this may
occur in some suspend or error recovery scenarios.

Fixes: 3c4019f97978 ("mmc: tegra: HW Command Queue Support for Tegra SDMMC")
Signed-off-by: Brian Norris <briannorris@chromium.org>
---

 drivers/mmc/host/sdhci-tegra.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 2d2d8260c681..d1d1ae9b2a86 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -367,6 +367,10 @@ static void tegra_sdhci_reset(struct sdhci_host *host, u8 mask)
 	const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
 	u32 misc_ctrl, clk_ctrl, pad_ctrl;
 
+	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL) &&
+	    tegra_host->enable_hwcq)
+		cqhci_deactivate(host->mmc);
+
 	sdhci_reset(host, mask);
 
 	if (!(mask & SDHCI_RESET_ALL))
-- 
2.38.0.413.g74048e4d9e-goog

[PATCH 5/5] mmc: sdhci_am654: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

 [[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
tracking that properly in software. When out of sync, we may trigger
various timeouts.

It's not typical to perform resets while CQE is enabled, but this may
occur in some suspend or error recovery scenarios.

Fixes: f545702b74f9 ("mmc: sdhci_am654: Add Support for Command Queuing Engine to J721E")
Signed-off-by: Brian Norris <briannorris@chromium.org>
---

 drivers/mmc/host/sdhci_am654.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index 8f1023480e12..187a21086791 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -378,6 +378,9 @@ 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);
 
+	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL))
+		cqhci_deactivate(host->mmc);
+
 	sdhci_reset(host, mask);
 
 	if (sdhci_am654->quirks & SDHCI_AM654_QUIRK_FORCE_CDTEST) {
-- 
2.38.0.413.g74048e4d9e-goog

RE: [PATCH 3/5] mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI

[Bough Chen]

> -----Original Message-----
> From: Brian Norris <briannorris@chromium.org>
> Sent: 2022年10月18日 11:57
> To: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Shawn Lin <shawn.lin@rock-chips.com>; Adrian Hunter
> <adrian.hunter@intel.com>; Shawn Guo <shawnguo@kernel.org>; Fabio
> Estevam <festevam@gmail.com>; Faiz Abbas <faiz_abbas@ti.com>;
> dl-linux-imx <linux-imx@nxp.com>; Bough Chen <haibo.chen@nxp.com>; Al
> Cooper <alcooperx@gmail.com>; linux-mmc@vger.kernel.org; Pengutronix
> Kernel Team <kernel@pengutronix.de>; linux-kernel@vger.kernel.org; Florian
> Fainelli <f.fainelli@gmail.com>; Sascha Hauer <s.hauer@pengutronix.de>;
> Thierry Reding <thierry.reding@gmail.com>; Michal Simek
> <michal.simek@xilinx.com>; Jonathan Hunter <jonathanh@nvidia.com>;
> Sowjanya Komatineni <skomatineni@nvidia.com>;
> linux-arm-kernel@lists.infradead.org; Broadcom internal kernel review list
> <bcm-kernel-feedback-list@broadcom.com>; Brian Norris
> <briannorris@chromium.org>
> Subject: [PATCH 3/5] mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI
> 
>  [[ NOTE: this is completely untested by the author, but included solely
>     because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
>     SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
>     drivers using CQHCI might benefit from a similar change, if they
>     also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
>     bug on at least MSM, Arasan, and Intel hardware. ]]
> 
> SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
> tracking that properly in software. When out of sync, we may trigger various
> timeouts.
> 
> It's not typical to perform resets while CQE is enabled, but this may occur in
> some suspend or error recovery scenarios.
> 
> Fixes: bb6e358169bf ("mmc: sdhci-esdhc-imx: add CMDQ support")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> 
>  drivers/mmc/host/sdhci-esdhc-imx.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
> b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 55981b0f0b10..222c83929e20 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -1288,6 +1288,13 @@ static void esdhc_set_uhs_signaling(struct
> sdhci_host *host, unsigned timing)
> 
>  static void esdhc_reset(struct sdhci_host *host, u8 mask)  {
> +	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
> +
> +	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL)
> &&
> +	    imx_data->socdata->flags & ESDHC_FLAG_CQHCI)

I think we can remove the condition " imx_data->socdata->flags & ESDHC_FLAG_CQHCI" here.
According to code logic, host->mmc->caps2 & MMC_CAP2_CQE means it already contain imx_data->socdata->flags & ESDHC_FLAG_CQHCI

Best Regards
Haibo Chen


> +		cqhci_deactivate(host->mmc);
> +
>  	sdhci_reset(host, mask);
> 
>  	sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> --
> 2.38.0.413.g74048e4d9e-goog

Re: [PATCH 1/5] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI

[Guenter Roeck]

On Mon, Oct 17, 2022 at 08:57:20PM -0700, Brian Norris wrote:
> SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
> tracking that properly in software. When out of sync, we may trigger
> various timeouts.
> 
> It's not typical to perform resets while CQE is enabled, but one
> particular case I hit commonly enough: mmc_suspend() -> mmc_power_off().
> Typically we will eventually deactivate CQE (cqhci_suspend() ->
> cqhci_deactivate()), but that's not guaranteed -- in particular, if
> we perform a partial (e.g., interrupted) system suspend.
> 
> The same bug was already found and fixed for two other drivers, in v5.7
> and v5.9:
> 
> 5cf583f1fb9c mmc: sdhci-msm: Deactivate CQE during SDHC reset
> df57d73276b8 mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers
> 
> The latter is especially prescient, saying "other drivers using CQHCI
> might benefit from a similar change, if they also have CQHCI reset by
> SDHCI_RESET_ALL."
> 
> So like these other patches, deactivate CQHCI when resetting the
> controller. Also, move around the DT/caps handling, because
> sdhci_setup_host() performs resets before we've initialized CQHCI. This
> is the pattern followed in other SDHCI/CQHCI drivers.
> 
> Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Brian Norris <briannorris@chromium.org>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
> 
>  drivers/mmc/host/sdhci-of-arasan.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 3997cad1f793..1988a703781a 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -366,6 +366,10 @@ static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
>  	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>  	struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
>  
> +	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL) &&
> +	    sdhci_arasan->has_cqe)
> +		cqhci_deactivate(host->mmc);
> +
>  	sdhci_reset(host, mask);
>  
>  	if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_FORCE_CDTEST) {
> @@ -1521,7 +1525,8 @@ static int sdhci_arasan_register_sdclk(struct sdhci_arasan_data *sdhci_arasan,
>  	return 0;
>  }
>  
> -static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan)
> +static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan,
> +				 struct device_node *np)
>  {
>  	struct sdhci_host *host = sdhci_arasan->host;
>  	struct cqhci_host *cq_host;
> @@ -1549,6 +1554,10 @@ static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan)
>  	if (dma64)
>  		cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
>  
> +	host->mmc->caps2 |= MMC_CAP2_CQE;
> +	if (!of_property_read_bool(np, "disable-cqe-dcmd"))
> +		host->mmc->caps2 |= MMC_CAP2_CQE_DCMD;
> +
>  	ret = cqhci_init(cq_host, host->mmc, dma64);
>  	if (ret)
>  		goto cleanup;
> @@ -1705,13 +1714,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>  		host->mmc_host_ops.start_signal_voltage_switch =
>  					sdhci_arasan_voltage_switch;
>  		sdhci_arasan->has_cqe = true;
> -		host->mmc->caps2 |= MMC_CAP2_CQE;
> -
> -		if (!of_property_read_bool(np, "disable-cqe-dcmd"))
> -			host->mmc->caps2 |= MMC_CAP2_CQE_DCMD;
>  	}
>  
> -	ret = sdhci_arasan_add_host(sdhci_arasan);
> +	ret = sdhci_arasan_add_host(sdhci_arasan, np);
>  	if (ret)
>  		goto err_add_host;
>  
> -- 
> 2.38.0.413.g74048e4d9e-goog
> 

Re: [PATCH 1/5] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI

[Adrian Hunter]

On 18/10/22 06:57, Brian Norris wrote:
> SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
> tracking that properly in software. When out of sync, we may trigger
> various timeouts.
> 
> It's not typical to perform resets while CQE is enabled, but one
> particular case I hit commonly enough: mmc_suspend() -> mmc_power_off().
> Typically we will eventually deactivate CQE (cqhci_suspend() ->
> cqhci_deactivate()), but that's not guaranteed -- in particular, if
> we perform a partial (e.g., interrupted) system suspend.
> 
> The same bug was already found and fixed for two other drivers, in v5.7
> and v5.9:
> 
> 5cf583f1fb9c mmc: sdhci-msm: Deactivate CQE during SDHC reset
> df57d73276b8 mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers
> 
> The latter is especially prescient, saying "other drivers using CQHCI
> might benefit from a similar change, if they also have CQHCI reset by
> SDHCI_RESET_ALL."
> 
> So like these other patches, deactivate CQHCI when resetting the
> controller. Also, move around the DT/caps handling, because
> sdhci_setup_host() performs resets before we've initialized CQHCI. This
> is the pattern followed in other SDHCI/CQHCI drivers.

Did you consider just checking host->mmc->cqe_private like
sdhci_cqhci_reset() ?

> 
> Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> 
>  drivers/mmc/host/sdhci-of-arasan.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 3997cad1f793..1988a703781a 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -366,6 +366,10 @@ static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
>  	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>  	struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
>  
> +	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL) &&
> +	    sdhci_arasan->has_cqe)
> +		cqhci_deactivate(host->mmc);
> +
>  	sdhci_reset(host, mask);
>  
>  	if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_FORCE_CDTEST) {
> @@ -1521,7 +1525,8 @@ static int sdhci_arasan_register_sdclk(struct sdhci_arasan_data *sdhci_arasan,
>  	return 0;
>  }
>  
> -static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan)
> +static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan,
> +				 struct device_node *np)
>  {
>  	struct sdhci_host *host = sdhci_arasan->host;
>  	struct cqhci_host *cq_host;
> @@ -1549,6 +1554,10 @@ static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan)
>  	if (dma64)
>  		cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
>  
> +	host->mmc->caps2 |= MMC_CAP2_CQE;
> +	if (!of_property_read_bool(np, "disable-cqe-dcmd"))
> +		host->mmc->caps2 |= MMC_CAP2_CQE_DCMD;
> +
>  	ret = cqhci_init(cq_host, host->mmc, dma64);
>  	if (ret)
>  		goto cleanup;
> @@ -1705,13 +1714,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>  		host->mmc_host_ops.start_signal_voltage_switch =
>  					sdhci_arasan_voltage_switch;
>  		sdhci_arasan->has_cqe = true;
> -		host->mmc->caps2 |= MMC_CAP2_CQE;
> -
> -		if (!of_property_read_bool(np, "disable-cqe-dcmd"))
> -			host->mmc->caps2 |= MMC_CAP2_CQE_DCMD;
>  	}
>  
> -	ret = sdhci_arasan_add_host(sdhci_arasan);
> +	ret = sdhci_arasan_add_host(sdhci_arasan, np);
>  	if (ret)
>  		goto err_add_host;
>  

Re: [PATCH 1/5] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

Hi Adrian,

On Tue, Oct 18, 2022 at 07:13:28PM +0300, Adrian Hunter wrote:
> On 18/10/22 06:57, Brian Norris wrote:
> > So like these other patches, deactivate CQHCI when resetting the
> > controller. Also, move around the DT/caps handling, because
> > sdhci_setup_host() performs resets before we've initialized CQHCI. This
> > is the pattern followed in other SDHCI/CQHCI drivers.
> 
> Did you consider just checking host->mmc->cqe_private like
> sdhci_cqhci_reset() ?

I did not, although I am doing so now.

My first thought is that this feels a bit too private. Is the host
driver supposed to be memorizing the details of the CQHCI layer?

But on the plus side, that would remove some contortions needed here
(and also in sdhci-brcmstb.c).

Here's another option I previously considered: teaching
cqhci_deactivate() to check cqe_private itself. That would have the same
benefits, while keeping the private details in cqhci-core.c. How do you
like that?

(Tiny downside: cqhci-core.c got its rename in v5.12, so backporting
this to -stable would get slightly more difficult.)

Brian

Re: [PATCH 1/5] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI

[Adrian Hunter]

On 18/10/22 19:59, Brian Norris wrote:
> Hi Adrian,
> 
> On Tue, Oct 18, 2022 at 07:13:28PM +0300, Adrian Hunter wrote:
>> On 18/10/22 06:57, Brian Norris wrote:
>>> So like these other patches, deactivate CQHCI when resetting the
>>> controller. Also, move around the DT/caps handling, because
>>> sdhci_setup_host() performs resets before we've initialized CQHCI. This
>>> is the pattern followed in other SDHCI/CQHCI drivers.
>>
>> Did you consider just checking host->mmc->cqe_private like
>> sdhci_cqhci_reset() ?
> 
> I did not, although I am doing so now.
> 
> My first thought is that this feels a bit too private. Is the host
> driver supposed to be memorizing the details of the CQHCI layer?

Some drivers need to access CQHCI registers and get the reference
to cqhci_host from cqe_private, so that is already accepted.

> 
> But on the plus side, that would remove some contortions needed here
> (and also in sdhci-brcmstb.c).
> 
> Here's another option I previously considered: teaching
> cqhci_deactivate() to check cqe_private itself. That would have the same
> benefits, while keeping the private details in cqhci-core.c. How do you
> like that?

I don't mind either way.

> 
> (Tiny downside: cqhci-core.c got its rename in v5.12, so backporting
> this to -stable would get slightly more difficult.)
> 
> Brian

Re: [PATCH 3/5] mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI

[Brian Norris]

Hi,

On Tue, Oct 18, 2022 at 07:22:04AM +0000, Bough Chen wrote:
> > -----Original Message-----
> > From: Brian Norris <briannorris@chromium.org>
> > --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> > @@ -1288,6 +1288,13 @@ static void esdhc_set_uhs_signaling(struct
> > sdhci_host *host, unsigned timing)
> > 
> >  static void esdhc_reset(struct sdhci_host *host, u8 mask)  {
> > +	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > +	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
> > +
> > +	if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL)
> > &&
> > +	    imx_data->socdata->flags & ESDHC_FLAG_CQHCI)
> 
> I think we can remove the condition " imx_data->socdata->flags & ESDHC_FLAG_CQHCI" here.
> According to code logic, host->mmc->caps2 & MMC_CAP2_CQE means it already contain imx_data->socdata->flags & ESDHC_FLAG_CQHCI

I don't know why I had this in the first place. Maybe just to be
double-sure that caps flags aren't getting set elsewhere (e.g., by the
core)? But you're right, and I've dropped this in v2.

Thanks,
Brian