Received: by 2002:ab2:6991:0:b0:1f7:f6c3:9cb1 with SMTP id v17csp1122086lqo; Thu, 9 May 2024 05:35:21 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUIka6Od+TgxyS/KbJ9Jvt8M1X2ndQdA1kyaa510suaN3Wr0StgcLo9fKYRp2RwBxspHdQxr++fmcBf1Dx5OHbXCkH6xDQLfip7yxcRfQ== X-Google-Smtp-Source: AGHT+IEBZM/9iBIzu0SZ5A6SJaRmyGL7BcBJUM4jw2r6OICH8ccwB2bn5KelY+ZmJ9xSbAGbrWzl X-Received: by 2002:a05:6a21:998:b0:1af:62a6:e2 with SMTP id adf61e73a8af0-1afc8ddc313mr4673417637.56.1715258121451; Thu, 09 May 2024 05:35:21 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715258121; cv=pass; d=google.com; s=arc-20160816; b=oSXVrM2q1rfAhiYVY9DGGLBEpubOLyR9ciUIquFXYtpyVSU5zQ4ZWg3NzwU6eSCPpn HzRXNvcPe3imLJY9GzqzLA+qEoIpQPc1zg5kGkfvEwygAtcAnr1yu1DF0wjJ4AWNg2Ey oDXYx08K4fw8CfORcLlkF002g+LfOQaoJ9MdrQyFOWCV5ZCtTZg5C+x6kRr6bSJJkboG Qb6WXVJtMcMxV+LIe6pqxF5DB2MxY5USNIZ/TByj9FmPSOuQcVKI467xinlDV8+gSJPW HieupZZvmBaqEN44/RUUAdylphYwNOumcM+z8PUF26it6N4N+VLGy3w07Vg+Z1xyAmwf 5RgQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=SmlbI/FlmmuHIPcswkddkrEGDrmDZVS/Ndo9dCDCyeA=; fh=UAQomj3ap7711YbbNaLBLrjIcBf+GEUDhpt2s9/1wN4=; b=fF8SspkXoi8iawA0Se75mb3LtTGWv8upQP2WgzMyxMHsZiI9qy98BOun0HwPKSbmU4 6DE9SURdF9Qd3wIAJxCG/gTMO6hWr34Z2sB/qgXFt6+7NM0B0hVwCant8pl1yLVLvpzl x1iaQfMP/l6VWW5iE4kEr1qzmH6VrQc+9XTAYch7tej3lxUGuLzAaQX8wwbiMbb0snLR nXeYtLEejRCR8GJsZB9czeVWDYXapx/WNysmkPqLj2dPKD1Es8jcZguVTW+y2WzUPiFR DkARHCKLc7tSWUbly+v9isIdAehtkHM7ElJE7J+WXOs/E2s/bGvD+OaGG1CnvuzFNaYD iquw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@leemhuis.info header.s=he214686 header.b=2WeLbyJ2; arc=pass (i=1 spf=pass spfdomain=leemhuis.info dkim=pass dkdomain=leemhuis.info); spf=pass (google.com: domain of linux-kernel+bounces-174502-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-174502-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id d2e1a72fcca58-6f4d2b4cdeasi1546212b3a.385.2024.05.09.05.35.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 May 2024 05:35:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-174502-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@leemhuis.info header.s=he214686 header.b=2WeLbyJ2; arc=pass (i=1 spf=pass spfdomain=leemhuis.info dkim=pass dkdomain=leemhuis.info); spf=pass (google.com: domain of linux-kernel+bounces-174502-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-174502-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 1296B282FEA for ; Thu, 9 May 2024 12:35:21 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0B20714A4E2; Thu, 9 May 2024 12:35:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b="2WeLbyJ2" Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2D8914A90; Thu, 9 May 2024 12:35:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.237.130.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715258112; cv=none; b=QCBKxZFOPiBuf5X231M6/2t0OZfv+jtq6kiFpzUQSYUDQX3iNYTfkEm/4QcYBmSZQPPydXI5g1JBtOsE9vAZtAMLASC6LF3PuHqtLtpymFL44azq7zlDthp7Me+6kKe+3jhDzvhY8hC5Eij2YtP9+MA2Hf2pNjXAhYDXenjOvyA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715258112; c=relaxed/simple; bh=I66ut8+KtUA6Bv3Xqx+VAizz2te0CAi50j3/JmvvNpw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VqiA64STSGCBzbaHOnofLHMtv9AvumsJieV3Mp8bvuy7j1e8xnWHHA7WvEGgEJVYHcEpFbWdvxvPaZlworU/NIKtJPWp9YZqSzXT48jPxPLlm4Cdq8CCX2fa8d4BderAVeWFo+5/0aax3QYVAo4wkozWAMJjc/1CdJNdytsnxHg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info; spf=pass smtp.mailfrom=leemhuis.info; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b=2WeLbyJ2; arc=none smtp.client-ip=80.237.130.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=leemhuis.info DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemhuis.info; s=he214686; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:In-Reply-To: References; bh=SmlbI/FlmmuHIPcswkddkrEGDrmDZVS/Ndo9dCDCyeA=; t=1715258110; x=1715690110; b=2WeLbyJ2V1sI3RvSCn0Ay912av3FzAmVCb6XXIeSU0BAy8mSkmlxgMx7IHRix 8NYit9qKEDou6zmmCHqJSh2u6VY9zo2x/h2p9gaouBF+79mjluPgVsKT0KH8/G05YBSoVJWdTKgu9 ZFGmqbcmo2sYmcix4IDl06T24JO23zpL0aoDPxt1SWmEp8zTozljcLukuft1iMYxf3uO5FKUGioCl YjHpkaQ9Dq4nFrn4duQqgihIpq9qypsClKY0PKFzwAnVBVK3J3vUZoXBSVfXTqHz2oAdI79yokVW3 tepbs/8bsQOIv3mJ1X3t7ftsTrpfYc3QHJ+NTzWa/+P2SF2TUA==; Received: from [2a02:8108:8980:2478:8cde:aa2c:f324:937e]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1s52zK-0006Xy-8j; Thu, 09 May 2024 14:35:06 +0200 Message-ID: Date: Thu, 9 May 2024 14:35:05 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] OPP: Fix required_opp_tables for multiple genpds using same table To: Viresh Kumar , Viresh Kumar , Nishanth Menon , Stephen Boyd , Ulf Hansson , "Rafael J. Wysocki" Cc: linux-pm@vger.kernel.org, Vincent Guittot , Vladimir Lypak , linux-kernel@vger.kernel.org, Linux kernel regressions list References: <2eb72832e852c80e5c11cd69e7d2f14cefd8b1cb.1712903998.git.viresh.kumar@linaro.org> From: Thorsten Leemhuis Content-Language: en-US, de-DE In-Reply-To: <2eb72832e852c80e5c11cd69e7d2f14cefd8b1cb.1712903998.git.viresh.kumar@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1715258110;d806580a; X-HE-SMSGID: 1s52zK-0006Xy-8j On 12.04.24 08:41, Viresh Kumar wrote: > The required_opp_tables parsing is not perfect, as the OPP core does the > parsing solely based on the DT node pointers. > > The core sets the required_opp_tables entry to the first OPP table in > the "opp_tables" list, that matches with the node pointer. > > If the target DT OPP table is used by multiple devices and they all > create separate instances of 'struct opp_table' from it, then it is > possible that the required_opp_tables entry may be set to the incorrect > sibling device. > > Unfortunately, there is no clear way to initialize the right values > during the initial parsing and we need to do this at a later point of > time. > > Cross check the OPP table again while the genpds are attached and fix > them if required. > > Also add a new API for the genpd core to fetch the device pointer for > the genpd. > > Cc: Thorsten Leemhuis > Reported-by: Vladimir Lypak > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218682 Did this fall through the cracks? Just wondering, as from here it looks like for about four weeks now nothing happened to fix the regression linked above. But I might have missed something. Or is everybody waiting for a test from the reporter? Ciao, Thorsten > Co-developed-by: Vladimir Lypak > Signed-off-by: Viresh Kumar > --- > V2: > - Fix an `if` condition. > - s/Bugzilla/Closes/ and change ordering. > > drivers/opp/core.c | 31 ++++++++++++++++++++++++++++++- > drivers/pmdomain/core.c | 10 ++++++++++ > include/linux/pm_domain.h | 6 ++++++ > 3 files changed, 46 insertions(+), 1 deletion(-) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index e233734b7220..cb4611fe1b5b 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -2394,7 +2394,8 @@ static void _opp_detach_genpd(struct opp_table *opp_table) > static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev, > const char * const *names, struct device ***virt_devs) > { > - struct device *virt_dev; > + struct device *virt_dev, *gdev; > + struct opp_table *genpd_table; > int index = 0, ret = -EINVAL; > const char * const *name = names; > > @@ -2427,6 +2428,34 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev, > goto err; > } > > + /* > + * The required_opp_tables parsing is not perfect, as the OPP > + * core does the parsing solely based on the DT node pointers. > + * The core sets the required_opp_tables entry to the first OPP > + * table in the "opp_tables" list, that matches with the node > + * pointer. > + * > + * If the target DT OPP table is used by multiple devices and > + * they all create separate instances of 'struct opp_table' from > + * it, then it is possible that the required_opp_tables entry > + * may be set to the incorrect sibling device. > + * > + * Cross check it again and fix if required. > + */ > + gdev = dev_to_genpd_dev(virt_dev); > + if (IS_ERR(gdev)) > + return PTR_ERR(gdev); > + > + genpd_table = _find_opp_table(gdev); > + if (!IS_ERR(genpd_table)) { > + if (genpd_table != opp_table->required_opp_tables[index]) { > + dev_pm_opp_put_opp_table(opp_table->required_opp_tables[index]); > + opp_table->required_opp_tables[index] = genpd_table; > + } else { > + dev_pm_opp_put_opp_table(genpd_table); > + } > + } > + > /* > * Add the virtual genpd device as a user of the OPP table, so > * we can call dev_pm_opp_set_opp() on it directly. > diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c > index 4215ffd9b11c..c40eda92a85a 100644 > --- a/drivers/pmdomain/core.c > +++ b/drivers/pmdomain/core.c > @@ -184,6 +184,16 @@ static struct generic_pm_domain *dev_to_genpd(struct device *dev) > return pd_to_genpd(dev->pm_domain); > } > > +struct device *dev_to_genpd_dev(struct device *dev) > +{ > + struct generic_pm_domain *genpd = dev_to_genpd(dev); > + > + if (IS_ERR(genpd)) > + return ERR_CAST(genpd); > + > + return &genpd->dev; > +} > + > static int genpd_stop_dev(const struct generic_pm_domain *genpd, > struct device *dev) > { > diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h > index 772d3280d35f..f24546a3d3db 100644 > --- a/include/linux/pm_domain.h > +++ b/include/linux/pm_domain.h > @@ -260,6 +260,7 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd, > int pm_genpd_init(struct generic_pm_domain *genpd, > struct dev_power_governor *gov, bool is_off); > int pm_genpd_remove(struct generic_pm_domain *genpd); > +struct device *dev_to_genpd_dev(struct device *dev); > int dev_pm_genpd_set_performance_state(struct device *dev, unsigned int state); > int dev_pm_genpd_add_notifier(struct device *dev, struct notifier_block *nb); > int dev_pm_genpd_remove_notifier(struct device *dev); > @@ -307,6 +308,11 @@ static inline int pm_genpd_remove(struct generic_pm_domain *genpd) > return -EOPNOTSUPP; > } > > +static inline struct device *dev_to_genpd_dev(struct device *dev) > +{ > + return ERR_PTR(-EOPNOTSUPP); > +} > + > static inline int dev_pm_genpd_set_performance_state(struct device *dev, > unsigned int state) > {