Message ID | 20221017205610.1.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1765012wrs; Mon, 17 Oct 2022 21:05:26 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4Q5Fks2/0uzJkqUvxml4I/MyA9Sp7OvlmvrrLvgPZKSYOGFLcw2EWfKWaeD3dVDANGNbLA X-Received: by 2002:a17:902:8215:b0:178:6946:a282 with SMTP id x21-20020a170902821500b001786946a282mr1247319pln.162.1666065926414; Mon, 17 Oct 2022 21:05:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666065926; cv=none; d=google.com; s=arc-20160816; b=T6QuoRYto/dxEgH5d4cES2vMut5sjauznlegy8HSP5NQoAGcx91tTr2nXh4Y9aGHhI Hsge8iunNoZUl5BXfwgucez/5g1/BOXXfPdY+iZWVo0vbhbHL/L8ajTpI8r6mwOy2FR4 ktcLj7U3DVjSorGNzvYPI7RLItQruJJcpoIqbkGXuNOO5WhKvPTmPPVWFuthUQqTeCoX JEApMSpb8dBwvZAd8Gxe5Bz+9UVxQ+8cNtFOsd2Gr1pLwpoEXZvLYH61/293o+2WcNg6 cM4k6ky8clRVYJAZ2cEO4/lbqQ+82lHXhVPu1/USp+5tNK0N5kHXdBOXR07IzKJNQmdm IieA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=/5SY8Nah0OJo40Eqd9ufrxakceznyXcaJJucJXEE6R0=; b=Xdn716sj/7xWyvfMoXpqxF7MkqcP06o+9CWH+PWV0+joSvxdCZ7xhPjyTn5OneK/Cy pJm1TXiUeI2inqs6ntMfraqB5s7VB66oXFdyQoL9El5AQzlNF75F7+I2me6tBLr3eAVN RSoq+sKnIafpEwJv+UoNYH6mgW7CLqy+bYY1SLlve7xKRGxSNVcy94/wkgmzklvDGIDZ UnnMilo2yxr4kcfPS0vanhFdb0mAPxurby5Y/CKqiXwLd+gyEg2aFZiFlTacFLALpSdP GsWV6jacA7vADhpNwd6N2FGVYAR+1K/bCMowGK/kpoE9Ma+SfX3u136mOnJK+AkPbOlS wTFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=m3Yt3QI6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y16-20020a170902b49000b001782bd6c443si12424725plr.621.2022.10.17.21.05.14; Mon, 17 Oct 2022 21:05:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=m3Yt3QI6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229891AbiJRD5p (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Mon, 17 Oct 2022 23:57:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229898AbiJRD5l (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Oct 2022 23:57:41 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAF1187095 for <linux-kernel@vger.kernel.org>; Mon, 17 Oct 2022 20:57:39 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id b2so12654482plc.7 for <linux-kernel@vger.kernel.org>; Mon, 17 Oct 2022 20:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=/5SY8Nah0OJo40Eqd9ufrxakceznyXcaJJucJXEE6R0=; b=m3Yt3QI6+Z/DrLslxPJ/GzJKEJbJxlIPy8KAYZmEIRcp609iOKz/1AXizo0Chsx+uk ldcx7+d5tpLrsL/TW3piXuuC9bCYwaXfh7MoSV69B5rEG0ycLHN/v2/PNpBvwi03yFqu gFUwj9zrzvuH1GSY26F8RA0v/zQ7eMhlGc7ko= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/5SY8Nah0OJo40Eqd9ufrxakceznyXcaJJucJXEE6R0=; b=IMMok14L1I80y6SRb/0ecYESjVEgQYY7CHgs7iJozm86Ts7nK/6KM8F2zPq8wu9qLa bFoAYF5M0osRJkhW0oW9vHYJEFmunvagQG/OD321Hi7zjEPFvPX4wSg/ByiVQDXw/+HA tH3D7oU1ysEKO9nKKf0lB/pkVY+LTQSNY2CKSwthWuczgssS0ND/nIOrmJi+xSq87mSY fObPsMhPUZ//X9Kj4DOYzpoRuC6UBlIaWgD3s79SISGZTt+f7qepQr9VeoCxCT5TorVH LliaodepI1TzoqX1hltGcncDLvpVRaNZPboBHC1lQBaKsZktcZG5uQ45acsZ/vlV7KGJ Ek1A== X-Gm-Message-State: ACrzQf07CZ9xx8RAvXdR2jbCvw1cqzI07QRWLuUhzzo0gGg3b8tR8MSo MOdMqpu19FUYO8Y7R0n8LUtV/007la5JSg== X-Received: by 2002:a17:902:8e84:b0:178:71f2:113c with SMTP id bg4-20020a1709028e8400b0017871f2113cmr948888plb.79.1666065459409; Mon, 17 Oct 2022 20:57:39 -0700 (PDT) Received: from localhost ([2620:15c:9d:2:2ac3:f4e2:e908:c393]) by smtp.gmail.com with UTF8SMTPSA id h9-20020aa79f49000000b00537fb1f9f25sm7972272pfr.110.2022.10.17.20.57.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Oct 2022 20:57:38 -0700 (PDT) From: Brian Norris <briannorris@chromium.org> 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>, NXP Linux Team <linux-imx@nxp.com>, Haibo 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>, stable@vger.kernel.org Subject: [PATCH 1/5] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI Date: Mon, 17 Oct 2022 20:57:20 -0700 Message-Id: <20221017205610.1.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid> X-Mailer: git-send-email 2.38.0.413.g74048e4d9e-goog In-Reply-To: <20221018035724.2061127-1-briannorris@chromium.org> References: <20221018035724.2061127-1-briannorris@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1746996744834927112?= X-GMAIL-MSGID: =?utf-8?q?1746996744834927112?= |
Series |
mmc: sdhci controllers: Fix SDHCI_RESET_ALL for CQHCI
|
|
Commit Message
Brian Norris
Oct. 18, 2022, 3:57 a.m. UTC
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(-)
Comments
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 >
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; >
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
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
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;