Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2008727pxa; Mon, 24 Aug 2020 02:20:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygqJxdi3fFYpd6SKt5V1MLhAPpVdvUKB+5SbxEbyQj26ia8qzt0CvFOxG2ZFrv0X1hbyX8 X-Received: by 2002:a50:f386:: with SMTP id g6mr4637469edm.354.1598260847169; Mon, 24 Aug 2020 02:20:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598260847; cv=none; d=google.com; s=arc-20160816; b=LM2BMERKvU9YWm96TIfhPgGcUvVdfAmUZLMpiTItgUEgj5Ln+ISjTcHX0loU41JWfN xHSUHxwakPn6SvMlYVaDv+vkXvT+JLZsPXMPwlj1PPq7ETQQh9JTJcGC5Ufxt1Z3qUZL 6GHpiZBIuw4Zx9CFFMBbMwLYN5+H4FIm1ydc1QNgUlOkEO+JdSp/Qj23CpiqB/gJC+xS q3Kpk+tGE6d06dc+scAi8o50WZJthG2MTHcz1TI/rRmvGAjYyJUcDAL8DqHq3dXFbz4V ztXJ/yBtcBK80OoFAKJeeOam8kFtzIOxdEtJTV5lGrOI7IA93LernEUcP6nMkUgQK7mo LAbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=piFoeKFrUJtBI57BDIALP5epFRujdzh3bH9V8VDZYAo=; b=VcrbeIADvO9F+X+VQvcI0dICK07YopIoqHa9q4tGDlD9H3cU0H5KBiUiLWA+5QymVr QwR+w+BNzeOiWjuBgW6Us1eX8fmH1gK6dk+8IDhzPsresePLq5tifaoHoSMCYHSXIlf1 ygnLCNHYOVraL0x/IUgw3xnVyh+F9QTqsHKhHkWnBikZ9MWgje4MAqjWMG3/OczhLvZv lFPWEaLv0oQN+CgeZwKQAVN5CN1KBqqy+Z81RekClkhXQuO7X/3BkCiYtBdu9l9bVz8F FhSDzaNe9hNc84Lb34iszG1jyMtJIMpBHFyVCPOhMd9OMwAEviHyw2BZo40427q9gG9f GuSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v19si6135546ejf.83.2020.08.24.02.20.24; Mon, 24 Aug 2020 02:20:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730253AbgHXJRm (ORCPT + 99 others); Mon, 24 Aug 2020 05:17:42 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:36345 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729770AbgHXJRa (ORCPT ); Mon, 24 Aug 2020 05:17:30 -0400 Received: by mail-wr1-f68.google.com with SMTP id x7so1838496wro.3; Mon, 24 Aug 2020 02:17:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=piFoeKFrUJtBI57BDIALP5epFRujdzh3bH9V8VDZYAo=; b=GZFVbseRjfzRmeYXFX0EmDZgoFijYc9/oWlgTjr1qb3y1gWhSj062+vqjo0XQHsKvZ rT/uE7jzYeGTiQId2VtFzRakfIp+s5E3/q2ofYEFSwR8vz9i30nPz+jPbnQCKJ/Fszzg hTUxIan7Idq2mQighRB7F3qdaWkfu07luZJAv4fREbQUwMb/lQlGSLN26Um5/yupQd/P RloQRNiw8OxcfDDtBfHIeB0uo4rHYpAuX5lad1X6l9GVySCF/vnuqO8iBo3pitodgRKa fFM+9S+gHfzADpUPBk6OERZdjVeSKXwMScrXFUrOAPvd22AOPvDWBE/JlNX8lEQB6ly9 0AYQ== X-Gm-Message-State: AOAM530au0AWrCR9k4K55GfIL0C6KB7BVdsybT+PxWfY8FTVN3YFPA2B JMz424n7lhB5AQkxmmSJrXU= X-Received: by 2002:a05:6000:d0:: with SMTP id q16mr4847868wrx.389.1598260647712; Mon, 24 Aug 2020 02:17:27 -0700 (PDT) Received: from kozik-lap ([194.230.155.216]) by smtp.googlemail.com with ESMTPSA id u7sm22138521wrq.89.2020.08.24.02.17.25 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Aug 2020 02:17:27 -0700 (PDT) Date: Mon, 24 Aug 2020 11:17:24 +0200 From: Krzysztof Kozlowski To: Viresh Kumar Cc: ulf.hansson@linaro.org, "Rafael J. Wysocki" , Kevin Hilman , Pavel Machek , Len Brown , Greg Kroah-Hartman , Viresh Kumar , Nishanth Menon , Stephen Boyd , Kukjin Kim , linux-pm@vger.kernel.org, Vincent Guittot , nks@flawful.org, georgi.djakov@linaro.org, Stephan Gerhold , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org Subject: Re: [PATCH V2 1/2] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER Message-ID: <20200824091724.GB20819@kozik-lap> References: <24ff92dd1b0ee1b802b45698520f2937418f8094.1598260050.git.viresh.kumar@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <24ff92dd1b0ee1b802b45698520f2937418f8094.1598260050.git.viresh.kumar@linaro.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 24, 2020 at 02:39:32PM +0530, Viresh Kumar wrote: > From: Stephan Gerhold > > The OPP core manages various resources, e.g. clocks or interconnect paths. > These resources are looked up when the OPP table is allocated once > dev_pm_opp_get_opp_table() is called the first time (either directly > or indirectly through one of the many helper functions). > > At this point, the resources may not be available yet, i.e. looking them > up will result in -EPROBE_DEFER. Unfortunately, dev_pm_opp_get_opp_table() > is currently unable to propagate this error code since it only returns > the allocated OPP table or NULL. > > This means that all consumers of the OPP core are required to make sure > that all necessary resources are available. Usually this happens by > requesting them, checking the result and releasing them immediately after. > > For example, we have added "dev_pm_opp_of_find_icc_paths(dev, NULL)" to > several drivers now just to make sure the interconnect providers are > ready before the OPP table is allocated. If this call is missing, > the OPP core will only warn about this and then attempt to continue > without interconnect. This will eventually fail horribly, e.g.: > > cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517 > ... later ... > of: _read_bw: Mismatch between opp-peak-kBps and paths (1 0) > cpu cpu0: _opp_add_static_v2: opp key field not found > cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 > > This example happens when trying to use interconnects for a CPU OPP > table together with qcom-cpufreq-nvmem.c. qcom-cpufreq-nvmem calls > dev_pm_opp_set_supported_hw(), which ends up allocating the OPP table > early. To fix the problem with the current approach we would need to add > yet another call to dev_pm_opp_of_find_icc_paths(dev, NULL). > But actually qcom-cpufreq-nvmem.c has nothing to do with interconnects... > > This commit attempts to make this more robust by allowing > dev_pm_opp_get_opp_table() to return an error pointer. Fixing all > the usages is trivial because the function is usually used indirectly > through another helper (e.g. dev_pm_opp_set_supported_hw() above). > These other helpers already return an error pointer. > > The example above then works correctly because set_supported_hw() will > return -EPROBE_DEFER, and qcom-cpufreq-nvmem.c already propagates that > error. It should also be possible to remove the remaining usages of > "dev_pm_opp_of_find_icc_paths(dev, NULL)" from other drivers as well. > > Note that this commit currently only handles -EPROBE_DEFER for the > clock/interconnects within _allocate_opp_table(). Other errors are just > ignored as before. Eventually those should be propagated as well. > > Signed-off-by: Stephan Gerhold > [ Viresh: skip checking return value of dev_pm_opp_get_opp_table() for > EPROBE_DEFER in domain.c, fix NULL return value and reorder > code a bit in core.c, and update exynos-asv.c ] > Signed-off-by: Viresh Kumar > --- > Stephan, I have made some changes to the code. Please try it again and > lemme know if it works fine. > > drivers/base/power/domain.c | 14 +++++---- > drivers/opp/core.c | 53 +++++++++++++++++++------------- > drivers/opp/of.c | 8 ++--- > drivers/soc/samsung/exynos-asv.c | 2 +- > 4 files changed, 44 insertions(+), 33 deletions(-) For Samsung: Acked-by: Krzysztof Kozlowski Best regards, Krzysztof