Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752721AbdFUFAn (ORCPT ); Wed, 21 Jun 2017 01:00:43 -0400 Received: from mail-pg0-f49.google.com ([74.125.83.49]:34181 "EHLO mail-pg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750939AbdFUFAm (ORCPT ); Wed, 21 Jun 2017 01:00:42 -0400 Date: Wed, 21 Jun 2017 10:30:38 +0530 From: Viresh Kumar To: Stephen Boyd Cc: Rafael Wysocki , Viresh Kumar , Nishanth Menon , linux-pm@vger.kernel.org, Vincent Guittot , Rajendra Nayak , linux-kernel@vger.kernel.org Subject: Re: [PATCH] PM / OPP: Add dev_pm_opp_{set|put}_clkname() Message-ID: <20170621050038.GQ3942@vireshk-i7> References: <20170620210820.GU4493@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170620210820.GU4493@codeaurora.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1308 Lines: 41 On 20-06-17, 14:08, Stephen Boyd wrote: > On 06/20, Viresh Kumar wrote: > > + */ > > +struct opp_table *dev_pm_opp_set_clkname(struct device *dev, const char *name) > > +{ > > + struct opp_table *opp_table; > > + int ret; > > + > > + opp_table = dev_pm_opp_get_opp_table(dev); > > + if (!opp_table) > > + return ERR_PTR(-ENOMEM); > > + > > + /* This should be called before OPPs are initialized */ > > + if (WARN_ON(!list_empty(&opp_table->opp_list))) { > > + ret = -EBUSY; > > + goto err; > > + } > > + > > + /* Already have clkname set */ > > + if (opp_table->clk_name) { > > + ret = -EBUSY; > > + goto err; > > + } > > + > > + opp_table->clk_name = kstrdup(name, GFP_KERNEL); > > + if (!opp_table->clk_name) { > > Is there a reason to duplicate clk_name instead of using the clk > structure returned from clk_get()? Is it because we may already > have opp_table->clk set from default init? Why can't we always > clk_put() the clk structure if it's !IS_ERR() and then allow > dev_pm_opp_set_clkname() to be called many times in succession? > Long story short, I don't see the benefit to allocating the name > again here just to use it as a mechanism to know if the APIs have > been called symmetrically. Yeah, it was kind of required in what I was trying to do earlier, but not anymore. -- viresh