From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3F6C5C4332F for ; Thu, 20 Oct 2022 06:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZIteIzidIPVtgmjcEDGC1BeXy+uPgFHa4KtMOj18dBU=; b=xfuQcmMKH/+4I9 CNCsUlTBJswHAY6qYNS27YcKWG3yxvYwlczqslRnZlrSj3VLcsVlCkhO7iGoEjZzAdY/JVgGsSYHr ULIpy50Q1JqAzj3u8zM2lDOwUitEltGbs2cQfH2XjJOmop0/EUxy8HYqIXnfruQnWv/qZiH0nu+4o IUY6QG0810b72qAx/YoxSYj57GdnvIZHiG4JCivmBkM9dbTXcmfcxJ4C0Svt/wKPdRP0Md1JOA06W s3eYsO17f+uYyx5mS72Z0FeDHGHklMeY/vq8Ow3+0VjedsaXkEjmn6paUYb6L1ttKXr3I/lTnELNb o8CMcNbA956Jeb15kssQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1olP3W-00B3Y0-AE; Thu, 20 Oct 2022 06:29:26 +0000 Received: from mga04.intel.com ([192.55.52.120]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1olP3S-00B3SE-Sq for linux-arm-kernel@lists.infradead.org; Thu, 20 Oct 2022 06:29:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666247362; x=1697783362; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ZCZxqxkxlhv4qXWNtnj/k+0pRzItxdl7yKBQyZzESDw=; b=L2P31gmiNutoXPz1/iB727l1iVtWlv7h7uoqpF6xh4kta8Ts4MuVggYR Y6MJ02nia09FIucSVdPY4AmlRr6y0Y3yFtgwLRvpi7zgZEP3Fr/ONBVub aqsOmMbiH7HQhGeMP7Todi1tqMcVBOiPA1IPEXZYf8cII0H66Kb3Sh7J8 pMEkQWdfvp7pxixOUAhXEhU7K4h7aS0KyHr0vo7ToEEOQEwQX1rcXu1zk Q/OnPeuAqAcMhDz+My0QiVzz5DHg/yRKN+P8eGC1B/NK4qJehrGN2An22 JHUyWsBoxoWwRxrt7cDpFXI0Dc0nrhvqc7kS7ocEzvxZ7V7DdX2eWfJJH w==; X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="305356201" X-IronPort-AV: E=Sophos;i="5.95,198,1661842800"; d="scan'208";a="305356201" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 23:29:19 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="607479841" X-IronPort-AV: E=Sophos;i="5.95,198,1661842800"; d="scan'208";a="607479841" Received: from ahunter6-mobl1.ger.corp.intel.com (HELO [10.0.2.15]) ([10.252.53.25]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 23:29:14 -0700 Message-ID: <5f1adbf7-b477-914e-0a07-5c76532e85cd@intel.com> Date: Thu, 20 Oct 2022 09:29:10 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.0 Subject: Re: [PATCH v2 2/7] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI Content-Language: en-US To: Brian Norris , Florian Fainelli Cc: Ulf Hansson , Shawn Lin , Shawn Guo , Fabio Estevam , Haibo Chen , Broadcom internal kernel review list , NXP Linux Team , Pengutronix Kernel Team , Michal Simek , Faiz Abbas , linux-mmc@vger.kernel.org, Jonathan Hunter , Al Cooper , linux-arm-kernel@lists.infradead.org, Sowjanya Komatineni , linux-kernel@vger.kernel.org, Thierry Reding , Sascha Hauer , stable@vger.kernel.org References: <20221019215440.277643-1-briannorris@chromium.org> <20221019145246.v2.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid> <14efb3e6-96cf-f42e-16aa-c45001ec632e@gmail.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221019_232922_981851_FF2AD90B X-CRM114-Status: GOOD ( 20.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 20/10/22 01:19, Brian Norris wrote: > On Wed, Oct 19, 2022 at 02:59:39PM -0700, Florian Fainelli wrote: >> On 10/19/22 14:54, Brian Norris wrote: >>> 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." > >>> --- a/drivers/mmc/host/sdhci-of-arasan.c >>> +++ b/drivers/mmc/host/sdhci-of-arasan.c >>> @@ -366,6 +366,9 @@ 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)) >>> + cqhci_deactivate(host->mmc); >>> + >>> sdhci_reset(host, mask); >> >> Cannot this be absorbed by sdhci_reset() that all of these drivers appear to >> be utilizing since you have access to the host and the mask to make that >> decision? > > It potentially could. > > I don't know if this is a specified SDHCI behavior that really belongs > in the common helper, or if this is just a commonly-shared behavior. Per > the comments I quote above ("if they also have CQHCI reset by > SDHCI_RESET_ALL"), I chose to leave that as an implementation-specific > behavior. > > I suppose it's not all that harmful to do this even if some SDHCI > controller doesn't have the same behavior/quirk. > > I guess I also don't know if any SDHCI controllers will support command > queueing (MMC_CAP2_CQE) via somethings *besides* CQHCI. I see > CQE support in sdhci-sprd.c without CQHCI, although that driver doesn't > set MMC_CAP2_CQE. SDHCI and CQHCI are separate modules and are not dependent, so they cannot call into each other directly (and should not). A new CQE API would be needed in mmc_cqe_ops e.g. (*cqe_notify_reset)(struct mmc_host *host), and wrapped in mmc/host.h: static inline void mmc_cqe_notify_reset(struct mmc_host *host) { if (host->cqe_ops->cqe_notify_reset) host->cqe_ops->cqe_notify_reset(host); } Alternatively, you could make a new module for SDHCI/CQHCI helper functions, although in this case there is so little code it could be static inline and added in a new include file instead, say sdhci-cqhci.h e.g. #include "cqhci.h" #include "sdhci.h" static inline void sdhci_cqhci_reset(struct sdhci_host *host, u8 mask) { if ((host->mmc->caps2 & MMC_CAP2_CQE) && (mask & SDHCI_RESET_ALL) && host->mmc->cqe_private) cqhci_deactivate(host->mmc); sdhci_reset(host, mask); } _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel