Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2972553pxb; Sun, 8 Nov 2020 21:31:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJxEC0h4Cy1BBpAZQ47Sw4MDqXBz0RJauruaKTSgN5R6Dyjh4BJKwR0wST64DIXQy3DRuA69 X-Received: by 2002:aa7:c612:: with SMTP id h18mr13291372edq.27.1604899892858; Sun, 08 Nov 2020 21:31:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604899892; cv=none; d=google.com; s=arc-20160816; b=JyQWWWEIGyoXhyr5iX6sP3QN6p8A7JyVWJ9au06Ww4B0BIsGpHqbxcDdT/jNNX3n8Y VFQx3uqC4DBKSNqwpEASwxKS8uuE12u4GwbUUfv2AOVa/zIr5x6V47DuBZuwt5eq4zE1 WPX+mgJE/+kMekhPyS4FBDI/khL7yOlpCRorJD8okQbrkWhLkmkmUDI9vNm7YVwwEVyF uSLV2GRUah/eLWF4QgB39cOsE0Hd3+x9WP7RJfYPmGTJP2siwaJwlQ4Q8IvBy5uwlR0V tAEn2enWbJkOxldLMW6VJ2mTBpdyv+pG/fFUJDHxatYeeaik2Zy2fMy+pLYyz0xn4ew0 R8xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=Rub6A86a0+TidKGgBoC2PFnme8lun0CVqmJ7J6T6EZQ=; b=TWoYrKiNG4Z7+EQOl2YXFLWL6ovjLSU/C/kJHU1zvc52PEyBtdKfnzvIreoRfWz0et Oc+3xdE17mMwWpjJrDdvASn8DhFpnDhv3Xe+0PFgPOJY+viDns6bVA9Gk31Vtig1p4jx 8Lw7qSm1U12nUNY1aFGNFFQES2w5JkW4RY4Z/eryEqCv5rragHx70KDa75wYQzQgzgsi B/BjYbFERXGmIsufc56UD+Ogea74HkO3qd1ffKm9TQGNcCz9qhRZ2DmOUcPBYqehYLz7 MxjlyQhAp9bkKsrrOPw2ijH9HBs/cDvG6+n9iN7WHXdUrcnTR59NbSpKcQw+umV2osm8 w9IA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lOUMHcG5; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i26si6073863edb.556.2020.11.08.21.31.10; Sun, 08 Nov 2020 21:31:32 -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=@gmail.com header.s=20161025 header.b=lOUMHcG5; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729192AbgKIF3y (ORCPT + 99 others); Mon, 9 Nov 2020 00:29:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725865AbgKIF3y (ORCPT ); Mon, 9 Nov 2020 00:29:54 -0500 Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93A2DC0613CF; Sun, 8 Nov 2020 21:29:53 -0800 (PST) Received: by mail-lf1-x141.google.com with SMTP id v144so10626067lfa.13; Sun, 08 Nov 2020 21:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Rub6A86a0+TidKGgBoC2PFnme8lun0CVqmJ7J6T6EZQ=; b=lOUMHcG5m2tMEm+526TpHbvBV9zUKuKVrYtjEntSyVPCHGP7QSox/NpzyJtSlbLYF/ y2l6Qngqr/slp1nSBLBsiBNl0hw8Z5oHgFvHI195tO6HGfIRiyP8PwR8m+8tND5Btk74 ETK390CCylvgmqHDYIbEy9tK15Qsn+bQbOCp7BAs4rsib0E18fSdaiKlVFLmhqVb/0tv 85sV7ulW/FA8+Uo+1tvOhb916bROcd27At9mtPawLLauDoWhBDHcxCcAFtXUi7LwhVby r9wIMJQhjztQm+oJIgfwCzA0meqCl+jSQgdj9pmDLfEv1GsYIhaIUN/2VvupygqLCNLB ur7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Rub6A86a0+TidKGgBoC2PFnme8lun0CVqmJ7J6T6EZQ=; b=K6oC2t56iJ8e8cDCY3VhQ93LMCDnmCdYW4vU+R1BXqY/lS0p6419HfxmlEOFARAR+8 94DcrPhfHdoshYII5yayG0cj0CAZTX16NmT0mh9/3dce4F9yppyfQBSw0aTKO3sXzGBC feYbaWHfNoExRLtCjarctmqD3f9RqJ6QRWLypDaGUnhFT79bKcXeUZrdmev0ehzNY/oe dLKR6OiqOpF1iBEF3fwEJRuvRgeDyFcZPov2iFWCtZPeuBRp6mp0px42a+QlVFyu7Uag md0K4GVxPlnx6/uzJtg/9eHJlnjd328CMLzFlhGlDh2/TKFYvCDe9X1Bx4CmcFH8rI6G gYTw== X-Gm-Message-State: AOAM533h6b7XxSIUHC2HjOCkb+1Lv568+5pd8LYTZa9TS7FoVZ646oVZ aBPbo6UcdSFtx8sIPy+jTPhxULtIzO4= X-Received: by 2002:a05:6512:31d5:: with SMTP id j21mr4525808lfe.488.1604899791728; Sun, 08 Nov 2020 21:29:51 -0800 (PST) Received: from [192.168.2.145] (109-252-193-159.dynamic.spd-mgts.ru. [109.252.193.159]) by smtp.googlemail.com with ESMTPSA id r66sm835570lff.265.2020.11.08.21.29.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Nov 2020 21:29:51 -0800 (PST) Subject: Re: [PATCH 2/2] opp: Don't create an OPP table from dev_pm_opp_get_opp_table() To: Viresh Kumar 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 References: <684ff01900180c0a40ec307dacc673b24eab593b.1604643714.git.viresh.kumar@linaro.org> <1012a98950355bd5a52424668050a17c3430cbe0.1604643714.git.viresh.kumar@linaro.org> <20201109043457.xf55kufhjjz2fvct@vireshk-i7> <20201109045740.y5kpd6tjscoqxhi5@vireshk-i7> From: Dmitry Osipenko Message-ID: <7a0a904d-8ee2-d1d6-509c-950bb408e0c5@gmail.com> Date: Mon, 9 Nov 2020 08:29:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201109045740.y5kpd6tjscoqxhi5@vireshk-i7> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 09.11.2020 07:57, Viresh Kumar пишет: > On 09-11-20, 07:41, Dmitry Osipenko wrote: >> 09.11.2020 07:34, Viresh Kumar пишет: >>> 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. >> >> Why _allocate_opp_table() grabs the first default clk of a device and >> assigns it to the created table? > > Right, it was there so everybody isn't required to call > dev_pm_opp_set_clkname() if they don't need to pass a connection id > while getting the clock. But for the case of supporting empty OPP > tables for cases where we just want dev_pm_opp_set_rate() to act as > clk_set_rate() (in order for the drivers to avoid supporting two > different ways of doing so), we do need that call to be made. > > We need to add the OPP table explicitly and what happened with > dev_pm_opp_get_opp_table() was accidental and not what I wanted. > > drivers/mmc/host/sdhci-msm.c has an example of how this is done. > Alright, thank you for the clarification.