Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp5074770rwe; Tue, 18 Apr 2023 01:28:58 -0700 (PDT) X-Google-Smtp-Source: AKy350ampVD1Kft14wVDzWxKh0NTpzjukH7iwdxgHrRkxoG3htQdxMJNm8iOmPGY2DGDPmJbBAgH X-Received: by 2002:a05:6a20:4422:b0:f0:515d:1742 with SMTP id ce34-20020a056a20442200b000f0515d1742mr4408503pzb.53.1681806538629; Tue, 18 Apr 2023 01:28:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681806538; cv=none; d=google.com; s=arc-20160816; b=rm/oW43K8DSjWiwMwEGF2qJFNdumcwFsSbmSHd3Y++wElOzd2BJc4hjPZ1NTd7LrdQ kgOZ0nikpn2NXI/eFPOY/8Gxe4uyTriwISG7w66t+CM7fjHKrj3Fr+Oqv3jQ6ac5sHV6 cMpNYfBCTqu8H4YJkMhwagqNWILWvPKVdJXcW0pk3LWwNYv853Pf4HiFMa6R9ELm9AkY P4TKr/wNPGVpbty6vcjuWyyPcoNvYxxLOcboRS+NvcIqFyV0NqhxkoRVrpW4agmYi+RF Ae9MhnRwul6BC09CEHJGmL5cZGfeA1qeaclM3azhSamzXbMAUVN+l7wMUoNzo0nQuBTm SF4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=VCiNu1mOtB7laUM4bFCLww5HGe90bX5kQCMaz63PSvg=; b=yPUArhk+3PrEFMGC9Zia0e8vZKU5ONOxCD3AaRxPiegik3i1S509vDwUb+LRIM1TfQ 7DBQQh0dMxUAEJ51dYZm2wcbxb46RrErZyVPIsm35ZWhI4Xhj7EgJLEK7STKiPq4iS+J fy5yhsvnho2Ub1qg719Hq7Q5RtUk2hZRPgnnKNicO8q+P0Y9FgFZ/jB2eb1NA/jFFve9 v13ZeFaH0RGLQALGtZTD8f5jChxzVYBLy4iQqR5n65X7cLGIbfSplqeAbVLjjyXbC8Za KEDx944ZMcemWYVjYtwX2SXl/ZAfvc3LKWfi0rtY0BEud7qnbljfbGejVdc2BHyb9ZB2 1a4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uzbsajfv; 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=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q17-20020aa79831000000b006399bb6f5b2si13424413pfl.25.2023.04.18.01.28.42; Tue, 18 Apr 2023 01:28:58 -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=@linaro.org header.s=google header.b=uzbsajfv; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231169AbjDRINJ (ORCPT + 99 others); Tue, 18 Apr 2023 04:13:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230332AbjDRINI (ORCPT ); Tue, 18 Apr 2023 04:13:08 -0400 Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED54659DF for ; Tue, 18 Apr 2023 01:13:06 -0700 (PDT) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-555bc7f6746so2987327b3.6 for ; Tue, 18 Apr 2023 01:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1681805586; x=1684397586; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VCiNu1mOtB7laUM4bFCLww5HGe90bX5kQCMaz63PSvg=; b=uzbsajfvzhMME2BbITiqUYlU5JmDHTOBbzrynZ8UB9jovx8iStQe0oFs0+sb9CD2c5 en04wTDEnp4Y08px8o3TnO70QysiactEsoaFebfFydHRVttStiEddPcuD4M+XLePSnP7 CE0xk7DAdExtDFo8Gua+G6R3JNWJJWlWKB6tuDr/fevhCWCAqnYfCf1GqjULT5qgNBIf 2GEyDh82sTVHgIpAlfG40ZTNV17svod4n1r6BUr48pX31McQPN+TnuKZ1HN2pqUGkFt0 oEInSPUsRd2bzzr2WkPA5JxtMZ4TbZibZzFfdi4tVrd6yrbcfQy8gb9RnV4/1vR1PKgx RyyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681805586; x=1684397586; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VCiNu1mOtB7laUM4bFCLww5HGe90bX5kQCMaz63PSvg=; b=XNJEZCpCuXAelPkPbSonEvnTyR6rlloUNYqf1WiASWPkmqpabKBYW5h6C7tTUsslfX lv8G704Kw6WgXSG67V2wPsmx/rkmWPYTsy3O8FzUI9dW7Wwc0K+iGFLZMZZWfF1rFUaN ED4UVepCVHqMi6vITPjl09aqf4U6I9ka9BOSv5PYJMQitfXGW6arXTfEc/x4IuhzQxp4 YI/YKDzPC0GATQ5xHpzRQbPfOfZnNcDXy1U0zTyKcCxhB8CzUGFMvjMisvA8CA3YzDlH WrP2x1zVXA8Wo3ye225VPIEWVgTc9kD5iKH/18/jMEkBXcp/4WU93mOrxlNnHOZpYBMb qDhQ== X-Gm-Message-State: AAQBX9ccxv44y9tLLTmnJgVEZswxg0VS9D0V0oxyAIWu+8kVV9uySbsw 9e9GP2bp5CXjfKO92oB5DCLuNm+mJe7MD5bU7cBGbQ== X-Received: by 2002:a81:6ac3:0:b0:54f:bb34:1a0 with SMTP id f186-20020a816ac3000000b0054fbb3401a0mr17171311ywc.33.1681805586119; Tue, 18 Apr 2023 01:13:06 -0700 (PDT) MIME-Version: 1.0 References: <20230414055502.23920-1-quic_mkshah@quicinc.com> <20230414055502.23920-3-quic_mkshah@quicinc.com> In-Reply-To: <20230414055502.23920-3-quic_mkshah@quicinc.com> From: Ulf Hansson Date: Tue, 18 Apr 2023 10:12:30 +0200 Message-ID: Subject: Re: [PATCH v3 2/3] cpuidle: psci: Move enabling OSI mode after power domains creation To: Maulik Shah Cc: andersson@kernel.org, dianders@chromium.org, swboyd@chromium.org, wingers@google.com, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, jwerner@chromium.org, quic_lsrao@quicinc.com, quic_rjendra@quicinc.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 14 Apr 2023 at 07:55, Maulik Shah wrote: > > A switch from OSI to PC mode is only possible if all CPUs other than the > calling one are OFF, either through a call to CPU_OFF or not yet booted. > > Currently OSI mode is enabled before power domains are created. In cases > where CPUidle states are not using hierarchical CPU topology the bail out > path tries to switch back to PC mode which gets denied by firmware since > other CPUs are online at this point and creates inconsistent state as > firmware is in OSI mode and Linux in PC mode. > > This change moves enabling OSI mode after power domains are created, > this would makes sure that hierarchical CPU topology is used before > switching firmware to OSI mode. > > Fixes: 70c179b49870 ("cpuidle: psci: Allow PM domain to be initialized even if no OSI mode") > Signed-off-by: Maulik Shah > --- > drivers/cpuidle/cpuidle-psci-domain.c | 37 +++++++++------------------ > 1 file changed, 12 insertions(+), 25 deletions(-) > > diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/cpuidle-psci-domain.c > index c2d6d9c3c930..c3993df24eef 100644 > --- a/drivers/cpuidle/cpuidle-psci-domain.c > +++ b/drivers/cpuidle/cpuidle-psci-domain.c > @@ -120,20 +120,6 @@ static void psci_pd_remove(void) > } > } > > -static bool psci_pd_try_set_osi_mode(void) > -{ > - int ret; > - > - if (!psci_has_osi_support()) > - return false; > - > - ret = psci_set_osi_mode(true); > - if (ret) > - return false; > - > - return true; > -} > - > static void psci_cpuidle_domain_sync_state(struct device *dev) > { > /* > @@ -152,15 +138,12 @@ static int psci_cpuidle_domain_probe(struct platform_device *pdev) > { > struct device_node *np = pdev->dev.of_node; > struct device_node *node; > - bool use_osi; > + bool use_osi = psci_has_osi_support(); > int ret = 0, pd_count = 0; > > if (!np) > return -ENODEV; > > - /* If OSI mode is supported, let's try to enable it. */ > - use_osi = psci_pd_try_set_osi_mode(); > - > /* > * Parse child nodes for the "#power-domain-cells" property and > * initialize a genpd/genpd-of-provider pair when it's found. > @@ -178,25 +161,29 @@ static int psci_cpuidle_domain_probe(struct platform_device *pdev) > > /* Bail out if not using the hierarchical CPU topology. */ > if (!pd_count) > - goto no_pd; > + goto remove_pd; We should return 0 here instead, right? > > /* Link genpd masters/subdomains to model the CPU topology. */ > ret = dt_idle_pd_init_topology(np); > if (ret) > - goto remove_pd; > + goto remove_pd_topology; This looks wrong to me. Shouldn't we continue to goto the "remove_pd" label for this error path? > + > + /* let's try to enable OSI. */ > + ret = psci_set_osi_mode(use_osi); > + if (ret) > + goto remove_pd_topology; > > pr_info("Initialized CPU PM domain topology using %s mode\n", > use_osi ? "OSI" : "PC"); > return 0; > > -put_node: > - of_node_put(node); > +remove_pd_topology: > + dt_idle_pd_remove_topology(np); > remove_pd: > psci_pd_remove(); > +put_node: > + of_node_put(node); This of_node_put() should only be called if we break the "for_each_child_of_node" loop above because of an error, I think. Perhaps it's cleaner to just move this within the loop? > pr_err("failed to create CPU PM domains ret=%d\n", ret); > -no_pd: > - if (use_osi) > - psci_set_osi_mode(false); > return ret; > } > Kind regards Uffe