Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2559717imm; Thu, 16 Aug 2018 11:28:41 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwxHzd29VN3o9DSKk2/JutCGP2fDIrdMhqNfKovb5J0x/sgC9JHf/+owUW5A0X8LzaGoQ2I X-Received: by 2002:a17:902:76c7:: with SMTP id j7-v6mr30098910plt.275.1534444121648; Thu, 16 Aug 2018 11:28:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534444121; cv=none; d=google.com; s=arc-20160816; b=VR4vywsYqz8+fwUZwrnQae9xvdgMKVE0fX10jtfYsGUb0rdUxjlYdV4HdkVN6l6YUD Do7biXTu7eJpcWK7r7F3WfCmZ+3CS0ewEqM0gP9nGUFSlCS3fnjPulzurRmSn/o/+RLL 0B501VpK5YFTUPW+ZeLEpCVf50HHZ86kz1CzaxTJFvDhw9y20jRMYYEJP8vdDQ8+D5KK h4+xUTL/2knnrHjJCdTIE5ox3aJNHQBFvkRHjMqm9gTlx7iTRVvc34CCvE25TqyVpjr1 nZIbkj+d5vWb2pLUVOV/X1k2vPMv0IUcIlWz+jZy0QVSSoKzyeXKnyogl63/BffMqx1N oF4g== 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:arc-authentication-results; bh=11TL7ow6ab6MbsRWApSciGWOuwMpp03WGJ+yK1xcWKM=; b=zTAybn/YUAWlbovxuTCyyu8qMNtseSXBnxqx742uIaXqrYx0iEVkoSyfwzd51Q/OL/ 4XdM4SJoRJgRSUKAXi6+yWl4/XuCCUh+OKPHDxIxVfr5824dwwVsestVJOz3AmSu9CRn NSSdF9+IH9Q59lzsBwyB4KL32+hNqWqkr5HbcjEy51iMB/VQ7Uhhph/pIQ6JLwJDzwiX H5ti76sackrF2ICSJyDqQjB/PkGKHsrjnM1SCafXXjVrtiYQLhQJB5xfnlKIpTKOA0ZQ +4aQbPu+We7TNqI5bLeAriXUq2efdZlC2oGoPO+cBpbXuHgRhGIqdFponBhwtOugs8MC CQkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n1-v6si8195plp.166.2018.08.16.11.28.26; Thu, 16 Aug 2018 11:28:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389637AbeHPQvv (ORCPT + 99 others); Thu, 16 Aug 2018 12:51:51 -0400 Received: from foss.arm.com ([217.140.101.70]:36998 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388977AbeHPQvv (ORCPT ); Thu, 16 Aug 2018 12:51:51 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 27C1680D; Thu, 16 Aug 2018 06:53:06 -0700 (PDT) Received: from e110439-lin (e110439-lin.Emea.Arm.com [10.4.12.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C4693F5D0; Thu, 16 Aug 2018 06:53:03 -0700 (PDT) Date: Thu, 16 Aug 2018 14:53:00 +0100 From: Patrick Bellasi To: Dietmar Eggemann Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v3 05/14] sched/cpufreq: uclamp: add utilization clamping for FAIR tasks Message-ID: <20180816135300.GC2960@e110439-lin> References: <20180806163946.28380-1-patrick.bellasi@arm.com> <20180806163946.28380-6-patrick.bellasi@arm.com> <012b7e15-888c-a200-c34b-4fac0f8ab8b9@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012b7e15-888c-a200-c34b-4fac0f8ab8b9@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15-Aug 17:30, Dietmar Eggemann wrote: > On 08/06/2018 06:39 PM, Patrick Bellasi wrote: > > [...] > > >+#else /* CONFIG_UCLAMP_TASK */ > >+static inline unsigned int uclamp_value(unsigned int cpu, int clamp_id) > >+{ > >+ return uclamp_none(clamp_id); > >+} > > Looks like that uclamp_value() is not used outside CONFIG_UCLAMP_TASK areas. Yes, you right... I use it on some debug patches I'm tracking on top of the series... but I can defenitivel drop it in v4. Cheers Patrick -- #include Patrick Bellasi