Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2952334pxb; Sun, 8 Nov 2020 20:37:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJz2VW90S3ntQLeN2TEBSYv5wBs3s0TxYCLr7UUSoKPDkCaFN5CydBGqzJmXQS/fH0KWui+s X-Received: by 2002:a17:906:b104:: with SMTP id u4mr12801143ejy.121.1604896623439; Sun, 08 Nov 2020 20:37:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604896623; cv=none; d=google.com; s=arc-20160816; b=llZCqdQwFYfAlEwP/ofKbwpFdxlH04ka4bGFsnE6gExUNw20ZAW029oTYnA/URaIr5 XmTKcMgyhNqPJLks9yxipe0o6wOH/RDPKGaNWN+YoA1ICttC9N7FnfGFFBmVQcJcLi+U 4cJnG9L2Yi7U4ylpTFQERDJdN/vUjYRQ6g9tRpo0bXLa4S363Xt45hv00jDM8ez+0yx9 BU5pAj53wCzgdxjV0Ci2w8Oh0m/tHrwf8QF2eWh8tKZIxkhZlog6nSvp/PzLbDV1JJLK Q6hxO9zf5QIKcXhTXUwaVXlbySaK/f0qlH8J4D4iz0pUKAp3P+SyvUyLO3bK8v86c3JK f5Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=VgMOvNA1Ux0qxEI6TA4rcW3mQnTnYdI0FfzgJi/p7s4=; b=DSscyQx6GwD/GK0gg8U3koPC0OButSmlHxAnZYeQ8j1TwmIm6micqAOxwtqab9b+uZ AtKJjrzsFCKJ2J+GcbBy+mGJcmv0VKAgyfqMXQN1ft4hDRCYvAv9mdUWOLHKHOB4FThf r8AKRaFlcAalZSoTZyI/i4EX7WKGB8/XVh1Tp+hDASZow4oi+ABVdqs3fNsVUxvvma0i jsV8l4cna11HZH1atUfWaCemVj59vmh0SwaEBhAd4djfsnrepRFfab4xJlj1+Gu3QOTu Om0H51BsjZRsV15mgnNNaMESXsclea9lOUpGTNrYRu8pbXun2pFt/WlJ2PM38ozcnR9s /Q3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jJuZvUmB; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p5si6329075ejf.528.2020.11.08.20.36.40; Sun, 08 Nov 2020 20:37:03 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b=jJuZvUmB; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729076AbgKIEfC (ORCPT + 99 others); Sun, 8 Nov 2020 23:35:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728802AbgKIEfB (ORCPT ); Sun, 8 Nov 2020 23:35:01 -0500 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC65DC0613D3 for ; Sun, 8 Nov 2020 20:35:01 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id 10so6918174pfp.5 for ; Sun, 08 Nov 2020 20:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=VgMOvNA1Ux0qxEI6TA4rcW3mQnTnYdI0FfzgJi/p7s4=; b=jJuZvUmBexr8zx1mQzYCuZOVUssmQpohGfQ9N4nQcSoDPF5PZUHuhumYc7I0DV5++z 7nZE+VKCiHjvHJAZLto/qmTwczNztEBpFEmgF1tWM7qFwhD7Ang2SZF8pQMziLCgferf 8DoYY4lk0fjfNbrBxcb7VCha3tPcLfiSiyAV3IklHgqD74CQK4LolzVUdtdMcBKQdBFm eQebTPyELwDAv7iSKtucHw6PV47iIyizo14I6MnX06j+M+HNHxj2IShOoyniyDuBiYkO j/708WAWdZVHYG15zUCCH6RsjVvn3FDc3M4BHKyijcKdpPCQgJGTRzN2AXKKezSd6Btp fDLQ== 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:content-transfer-encoding :in-reply-to:user-agent; bh=VgMOvNA1Ux0qxEI6TA4rcW3mQnTnYdI0FfzgJi/p7s4=; b=T/Ogkb+cGw9ShHnexoU8pCQdvpLbq1esa+ToQP7apxgTFQBExW+w38lvRIK0cNSfoE solbdvWh2v99Xw1JhYjtIV2d+0ZwpYLWecFBo1YE2g2bImNCt+p5SJbb3IRlpzdjAqn+ S7GeLVYf6+p2aSjWqHe28/9ufMgJIBVimafSyxYLs3tYzmk2q2kUiW+3VmPpjzbSviF/ yYsLrCtj18o8B7JnCRMFbM1iwYQJ3PDJaHQjCx2rHJwABUUVwr8Biz4o8DNa/Tk2sVHn BdBeuRbBg/qSD5gi/X085EshfFO1ag0v27h2zQGmOw7L71m2VPAtLivVNR7IETcxwst8 7qcQ== X-Gm-Message-State: AOAM5322DdtMCHsN/ph2UY9rkmMiJ16t/iOjK2VjrvQRcxm3bUfKAvko wvzxuigkPo7fc0Yisz6R1j4FCg== X-Received: by 2002:a63:2145:: with SMTP id s5mr10709145pgm.288.1604896501055; Sun, 08 Nov 2020 20:35:01 -0800 (PST) Received: from localhost ([122.172.12.172]) by smtp.gmail.com with ESMTPSA id 82sm8220532pfv.149.2020.11.08.20.34.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2020 20:34:59 -0800 (PST) Date: Mon, 9 Nov 2020 10:04:57 +0530 From: Viresh Kumar To: Dmitry Osipenko Cc: "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , Len Brown , Pavel Machek , Greg Kroah-Hartman , Viresh Kumar , Nishanth Menon , Stephen Boyd , linux-pm@vger.kernel.org, Vincent Guittot , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] opp: Don't create an OPP table from dev_pm_opp_get_opp_table() Message-ID: <20201109043457.xf55kufhjjz2fvct@vireshk-i7> References: <684ff01900180c0a40ec307dacc673b24eab593b.1604643714.git.viresh.kumar@linaro.org> <1012a98950355bd5a52424668050a17c3430cbe0.1604643714.git.viresh.kumar@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06-11-20, 16:18, Dmitry Osipenko wrote: > 06.11.2020 09:24, Viresh Kumar пишет: > > It has been found that some users (like cpufreq-dt and others on LKML) > > have abused the helper dev_pm_opp_get_opp_table() to create the OPP > > table instead of just finding it, which is the wrong thing to do. This > > routine was meant for OPP core's internal working and exposed the whole > > functionality by mistake. > > > > Change the scope of dev_pm_opp_get_opp_table() to only finding the > > table. The internal helpers _opp_get_opp_table*() are thus renamed to > > _add_opp_table*(), dev_pm_opp_get_opp_table_indexed() is removed (as we > > don't need the index field for finding the OPP table) and so the only > > user, genpd, is updated. > > > > Note that the prototype of _add_opp_table() was already left in opp.h by > > mistake when it was removed earlier and so we weren't required to add it > > now. > > Hello Viresh, > > It looks like this is not an entirely correct change because previously > it was possible to get an empty opp_table in order to use it for the > dev_pm_opp_set_rate(), which would fall back to clk_set_rate if table is > empty. > > Now it's not possible to get an empty table and > dev_pm_opp_of_add_table() would error out if OPPs are missing in a > device-tree. Hence it's not possible to implement a fall back without > abusing opp_set_regulators() or opp_set_supported_hw() for getting the > empty table. Or am I missing something? For that case you were always required to call dev_pm_opp_set_clkname(), otherwise how would the OPP core know which clock to set ? And the same shall work now as well. -- viresh