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 04DB4C4332F for ; Wed, 19 Oct 2022 22:20:44 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FoyvExFCzOkSyXm+lCGAhZUIoK12bwz3W85KqbyGStE=; b=RtIr/dRZqKxEIf j2gzlGR2750bNnXoObT4DC0RPGHE4z6ZF2kjAJF4mdAzrrpQzPPqdfLcquEd/z8l/xvO40b73q7ES eAGJEQGfNR3jjqdBWC9nyGl2+2vdyQFB3xPbiU7s6P1+hk/rzueSVevRAc1VIZ2habeIzdHoAU7ae vTWqnma+zbiRnLlihPuEIlGDx92G9lMNCEOCuxSxG2QR81rGY53LIEQZl3i4A30jA3ZK3wpA+LVA9 t0JlIy9UTvUcTRF+uuG/lBBD0YdOMcJpq4AqEJGOzAtobxr/VTNRWpswW/kJoz0uoYRNICA2jJF2N 6YxRnGOtGunt1Z2hNnKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1olHPL-005ViB-L7; Wed, 19 Oct 2022 22:19:27 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1olHPI-005Vfa-PZ for linux-arm-kernel@lists.infradead.org; Wed, 19 Oct 2022 22:19:26 +0000 Received: by mail-pj1-x1030.google.com with SMTP id g8-20020a17090a128800b0020c79f987ceso1485946pja.5 for ; Wed, 19 Oct 2022 15:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZaGv7LlJBdgHofmM5ORri4ochUXzvI+2qUpKqb/vueI=; b=XPXW0AcauLG0R9ecSLc8KU3XGw73i+SHfDt8loROSQA6cTZ5b9EowD9Wn/KEgzCYVM O+03dmnQNBXaDLT3Y7U2d6SG4dgsB/7nJwvHYw97536Qclx3ik8mriTR1G4zV1244QIn KcXdlV+SOBPKJCSbTBZgkU6c5qlVP/oGs7aec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZaGv7LlJBdgHofmM5ORri4ochUXzvI+2qUpKqb/vueI=; b=TRm8vUlLs/YScX3EExkkqlE4v7xndU+dpzAKwco+SMpoWFAcZn81SBofD9f/mvfu3b xgDRyofUWhhlQO7o+QJHzn24Kzxug1NxEuQkinTfHq3fxxvJ8qH4DrZF1LxPbPV7aXTg oFiBxo4xEtLrLqKtWPkxtZQcx7vPpT4DKYTVQgzFSCV0G8qPUx1ZrOPqq0wwt/mMJAed zUd0lMdqEfdCxTLVTfuJIxB4obFVAkPtnQrsxCynt2UkEY04Lpj/s7Ykbuet7hrJ8tzZ UdbxKg/LxjNwZyFx7Uixfa07PEtBOrnPRDikHeUaxbq9Z0GKQQvFuRSEbYJkJ8TylUHV WeEg== X-Gm-Message-State: ACrzQf2vbJyR+cRbii45Zfgzb8UdD3pUntmPmRJosFxmAq5Z2K7Y+iE2 JYIJ5Ros13BVSlf0zOwaA/6cRw== X-Google-Smtp-Source: AMsMyM6m0qybDJCJSqtG9j3D5wrv8KHuP86ID2eiErDwVgap0Kq2QZsnamY56NRwNhc9lqyG+NYllg== X-Received: by 2002:a17:90a:9381:b0:20a:79b7:766a with SMTP id q1-20020a17090a938100b0020a79b7766amr48854405pjo.33.1666217963650; Wed, 19 Oct 2022 15:19:23 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:57b7:1f0e:44d1:f252]) by smtp.gmail.com with ESMTPSA id n12-20020a170902d2cc00b00172897952a0sm11458401plc.283.2022.10.19.15.19.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Oct 2022 15:19:23 -0700 (PDT) Date: Wed, 19 Oct 2022 15:19:20 -0700 From: Brian Norris To: 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 , Adrian Hunter , Sascha Hauer , stable@vger.kernel.org Subject: Re: [PATCH v2 2/7] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI Message-ID: References: <20221019215440.277643-1-briannorris@chromium.org> <20221019145246.v2.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid> <14efb3e6-96cf-f42e-16aa-c45001ec632e@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <14efb3e6-96cf-f42e-16aa-c45001ec632e@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221019_151924_922990_808D989C X-CRM114-Status: GOOD ( 20.65 ) 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 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. Brian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel