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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8186CC4332F for ; Tue, 18 Oct 2022 17:00:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229775AbiJRRAC (ORCPT ); Tue, 18 Oct 2022 13:00:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229564AbiJRQ7v (ORCPT ); Tue, 18 Oct 2022 12:59:51 -0400 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18E505600D for ; Tue, 18 Oct 2022 09:59:48 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id o17-20020a17090aac1100b0020d98b0c0f4so16583204pjq.4 for ; Tue, 18 Oct 2022 09:59:48 -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=b0l2HZlOZuWdOYo1ROWax2muHI31wxqlPHYjTm43zec=; b=PcuH5Qmpe7v1S++KPeobFTZuJ1OT0/3Mf1vuV/rdjGtACw7E4w3+aC1KCXZssWFge0 Iu/XPMhvL7F3sJqOR9h/GULUOS/0uZqUKxnUNQDvMcW6zADq97FjU9tKTbOUREhVCPsY sjzU+3CIpByK647KAuTGK+9fz5B+ME/WdZ1E8= 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=b0l2HZlOZuWdOYo1ROWax2muHI31wxqlPHYjTm43zec=; b=iILqWZjGegZJI9Ax/98CYjCXeWbvlNDGswLU7wFxFx/R8Mwmm/XryxFQVojdReOs9H ZgRzucaUD4HSQxy+2uqHaYLuRXV8IJZ0Xh7RIA+WGBPXzd2T17eoXVjp0KoxG2Nt4Of3 HSuUQH6u38Ta8La0JhHnNjasH4yZDly8JuM9SG3GVwACCYp9p1jHw/Hv+cZZH7rlyt4f uW71KuBogNzTLB6kjHqClEmhob/VHPba961v2CfKqNzXHhW30QBAxV2+oNNCnyElXBwf ux4JmbdOxkWC4pZ8S8bZ4AnLwM1yJ//fu964DWtRrMo3vE+mfXy/lFI1dFFB0L2yUPUY GXQA== X-Gm-Message-State: ACrzQf3OOm7XvQIMMaAYAFV4sVZjJLI6MakJagFQuY47dY01oljuKVk9 6dUCMLK1u0ySPBelqC0XPhXFbQ== X-Google-Smtp-Source: AMsMyM6Rlzv5RCnrpSOJBD3bV+5CLiPqwDe1Lc9YkBbLohQwy95ZHPsRszbYr/mpVmfAeOr1YrsZkQ== X-Received: by 2002:a17:90a:c90c:b0:20a:7179:b14f with SMTP id v12-20020a17090ac90c00b0020a7179b14fmr4574348pjt.58.1666112388295; Tue, 18 Oct 2022 09:59:48 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:2ac3:f4e2:e908:c393]) by smtp.gmail.com with ESMTPSA id w11-20020a170902ca0b00b001782a6fbcacsm8888930pld.101.2022.10.18.09.59.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 09:59:47 -0700 (PDT) Date: Tue, 18 Oct 2022 09:59:44 -0700 From: Brian Norris To: Adrian Hunter Cc: Ulf Hansson , Shawn Lin , Shawn Guo , Fabio Estevam , Faiz Abbas , NXP Linux Team , Haibo Chen , Al Cooper , linux-mmc@vger.kernel.org, Pengutronix Kernel Team , linux-kernel@vger.kernel.org, Florian Fainelli , Sascha Hauer , Thierry Reding , Michal Simek , Jonathan Hunter , Sowjanya Komatineni , linux-arm-kernel@lists.infradead.org, Broadcom internal kernel review list , stable@vger.kernel.org Subject: Re: [PATCH 1/5] mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI Message-ID: References: <20221018035724.2061127-1-briannorris@chromium.org> <20221017205610.1.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org 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