Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2954826pxb; Sun, 8 Nov 2020 20:44:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJypUAp3+8vSbsUQxt2J3+lbrfThgMKF0CGu5hTS6MxvrlhjiTYAAatLj+8/Y5wqWDGLLxhe X-Received: by 2002:a17:907:374:: with SMTP id rs20mr8803618ejb.191.1604897061553; Sun, 08 Nov 2020 20:44:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604897061; cv=none; d=google.com; s=arc-20160816; b=CFVunlK824WNiWeNv20IGRMpWN60Oi8yO5RvbPXDvU/+44xylOfarJAF4pqea64uLW rXMtWgUR8hE05bs+XT0PNKDYR2E7VSEJ3e0UnPPr3f8MRemnoRJq7JK2Byn2rb1vLg+e g9wmEwhTsWnapouvF6Oh4NXIreVVgox+psYE3YILsKfqilOqGGeJ7pPRRFp+NDL+9NIZ qC+nlt0K10G2UEez7+W42DG/F5aa7oLKzePBmbrdXkZIvIfRi4Yvt8gVEU2iXNhfHmMU Xkkd2YGvkQvJwbBPLakMf3sPXGxbtwsOj4ksm4aES5N4FvAw1/h3Xx/hHHZT0P8FSBUq Yyyg== 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=iZRG/P0XDE8J45minyMWYaCFUPrsvcXAimG9QNq9Z0Y=; b=hAglyPUG2IfA5KHkNgaqEX9i7DsZw4gr/kqnfz1bHHOiFDxrc3Ww2S8DdnBICklXiN FyQNB2kjXaveTjHWIh8eUjVQekvBcihCI2GDmXJW7IvWu0C6aoWSn5jy6Zq9mkUpqNGH LV47CiYW8iEs58NuF26HVMGGkgxmWtucvd9JENAZ4qN0OHaFxIz1tYWrKQYZrenC7/Fc 87uJnmBpsTyGl3aoXaJSR4wmaRgz1E+LxrgC6CpdEciC90C0mUXaQbR0Q/vhr8L4/BsU W8Ltc3Kx5aEgL5EvBEPzwK75fu6BiuNi/ut9gkoq9zJ/cavYj+sdjOssg+5mn5RojBwJ GiCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="bYLirLk/"; 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 cz6si7517680edb.139.2020.11.08.20.43.58; Sun, 08 Nov 2020 20:44:21 -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="bYLirLk/"; 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 S1729265AbgKIEls (ORCPT + 99 others); Sun, 8 Nov 2020 23:41:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728038AbgKIElr (ORCPT ); Sun, 8 Nov 2020 23:41:47 -0500 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B00AC0613CF; Sun, 8 Nov 2020 20:41:47 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id l2so10579981lfk.0; Sun, 08 Nov 2020 20:41:47 -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=iZRG/P0XDE8J45minyMWYaCFUPrsvcXAimG9QNq9Z0Y=; b=bYLirLk/D0MDS+ujwv74DJRgYMnaZR/hT3gIZo1uL0Bop75Axl+nrqZ53bXZBJRwA5 YCxsLmzPExFpAUGXyXRCPUNo8cWFeojuNyX+OosnqS4HlM72J+fusG77JRbgUWblPHlv ov0mfrhpGwm+orEPmUcgMqKUiQeSb/RRDdOv4mNBOqkHEgSQ8dzbW6U3gczVEIM0vHbd rV0Ou6RbaVSsz8a29x/2urAXP7IPRVknO0Xt6EQSdvJY0wINvKZBhFacVFxHV4pBZSBR nAgfZvYGz2AW4FMj4hyZN3JvDNQsIUwP7hKZVi1oqahPjJOVbIls7hp2eNnC+yjy26Us 9GWg== 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=iZRG/P0XDE8J45minyMWYaCFUPrsvcXAimG9QNq9Z0Y=; b=KpnJmuTgpRoTdAornaxjNvWEo8Vf2rojguIeGlV+yJ1oIRTPTOTzZwf7SdCg9ZrpgW vKSn2KAFsOx94un84Nk7oH1zURMMp+f09Lp2yRuBA2TWgboOmvJgWIaH44NxWZziKwhM NVDD0SKyAlAEUerso8YnNfTx0RWBk57OxmUIeWp87UYsKI0h7gB6hTKaZHaQWWu6Xu/7 NxFXHFem8CRe7z+AedAJEbDQrSSFp8ux22N9usb6fA/cduLaN6gB25yIDMj3ltJJa2Ra gS0KvkjiiZb4xaSyWRimRQH9Lrfv2vyhfdDDNpvVPuS42kco4T3cSkSFisDZZHC82nb1 DJZg== X-Gm-Message-State: AOAM532jw7hIvXGTPRAVUASgR4K5n2cJaTQEnZTPyA0nVoDJMDUmh38X sRKIUrunXr+M+ClEAzoD9Gzz35eqrmA= X-Received: by 2002:a19:6753:: with SMTP id e19mr4621055lfj.425.1604896905704; Sun, 08 Nov 2020 20:41:45 -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 q21sm1515487ljm.52.2020.11.08.20.41.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Nov 2020 20:41:45 -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> From: Dmitry Osipenko Message-ID: Date: Mon, 9 Nov 2020 07:41:44 +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: <20201109043457.xf55kufhjjz2fvct@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: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?