Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4247173ybc; Fri, 15 Nov 2019 01:14:30 -0800 (PST) X-Google-Smtp-Source: APXvYqw9m1W+HCbHVfDMtG7VokBQ/itKPRY2SS98Hzc3IfoM++NjpGZaRmU82FdnJFtP0UnV4VWn X-Received: by 2002:a17:906:5211:: with SMTP id g17mr12486828ejm.60.1573809270574; Fri, 15 Nov 2019 01:14:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573809270; cv=none; d=google.com; s=arc-20160816; b=g2MUJKztyBbc7XQbDfIVs7pPxqLJykX2Bz/vTTne6eLd9m9xzoXUF7VnAydjn2R9f/ 5ZVLAhWWq7kVN58jyk5rfl6MuoEmsWqGtXgBATqWy0x5pTkuCdWwtyTSIe/XrJ+UxLCQ g4dCCrEJ7wn1avaOJf0VZdzc2Nqo8UTkyldob99p3i4evvY5svqF3uJ+eUblrCTrcfHY u9mfYrw74eRHfvGUVayMWY9Qsv1zgQd5tPbMp0CfVCpCmGwUbAdw5OAX7gYwogllfkeq UWUvAzZsDbJMk50QKNOOb6aMXYQ+u5LPOlXBqAkpPe+GmIk8A/3B8AcmIv65SqrwSkG3 4Zdg== 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; bh=Plx9fVceCYM+5DX5ueOpAOOdTiyEayyx6ckakDz07Pw=; b=sWyd6CExai7jHZ7h7sk23DyFnyPiizeIFFlzgKJaRaBEWfrrxFyURTah+s/Z7p1NB3 w8/C239ho85VYS4Y+CNtgr9QnZnDDp4iLAG/lt/qQEn+20PkO+DMBvm9+LWR1COZKkcl bkl8zzHILL1TN9Zq6g2K8bqXO43R6vH/orSDHtnAGmo7pg/KlGPIiGTLy8NRA2wGPhFR ZCGLqjmDi2JO3vHW3Bu7jXIGmwoaIHq1xStdhdGkZMXPK163q8d6SSp5mHBw5eP2mF4s cWIJ9ctDhT9M0VsjJWYFW7XSpoUDPTfowa/+57U1uVxQG4FiGqChpjnclvyEGXY30Pga D6hw== 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 jp18si5171490ejb.318.2019.11.15.01.14.06; Fri, 15 Nov 2019 01:14:30 -0800 (PST) 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 S1727291AbfKOJJp (ORCPT + 99 others); Fri, 15 Nov 2019 04:09:45 -0500 Received: from foss.arm.com ([217.140.110.172]:55392 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725829AbfKOJJo (ORCPT ); Fri, 15 Nov 2019 04:09:44 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2D5F4328; Fri, 15 Nov 2019 01:09:44 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CBF883F6C4; Fri, 15 Nov 2019 01:09:42 -0800 (PST) Date: Fri, 15 Nov 2019 09:09:40 +0000 From: Qais Yousef To: Vincent Guittot Cc: Valentin Schneider , linux-kernel , Ingo Molnar , Peter Zijlstra , Dietmar Eggemann , Tejun Heo , Patrick Bellasi , Suren Baghdasaryan , Quentin Perret Subject: Re: [PATCH] sched/uclamp: Fix overzealous type replacement Message-ID: <20191115090939.6ku6cc44iaoanjph@e107158-lin.cambridge.arm.com> References: <20191113165334.14291-1-valentin.schneider@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/15/19 09:12, Vincent Guittot wrote: > On Wed, 13 Nov 2019 at 17:55, Valentin Schneider > wrote: > > > > Some uclamp helpers had their return type changed from 'unsigned int' to > > 'enum uclamp_id' by commit > > > > 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values") > > > > but it happens that some *actually* do return an unsigned int value. Those > > are the helpers that return a utilization value: uclamp_rq_max_value() and > > uclamp_eff_value(). Fix those up. > > > > Note that this doesn't lead to any obj diff using a relatively recent > > aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value() > > already figures out that the return value is 11 bits (bits_per(1024)) and > > doesn't seem to do anything funny. I'm still marking this as fixing the > > above commit to be on the safe side. > > > > Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values") > > Signed-off-by: Valentin Schneider > > --- > > kernel/sched/core.c | 4 ++-- > > kernel/sched/sched.h | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index 513a4794ff36..71a45025cd2e 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -853,7 +853,7 @@ static inline void uclamp_idle_reset(struct rq *rq, enum uclamp_id clamp_id, > > } > > > > static inline > > -enum uclamp_id uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id, > > +unsigned int uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id, > > unsigned int clamp_value) > > { > > struct uclamp_bucket *bucket = rq->uclamp[clamp_id].bucket; > > @@ -918,7 +918,7 @@ uclamp_eff_get(struct task_struct *p, enum uclamp_id clamp_id) > > return uc_req; > > } > > > > -enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id) > > +unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id) > > { > > struct uclamp_se uc_eff; > > > > And static inline enum uclamp_id uclamp_none(enum uclamp_id clamp_id) ? > > Should it be fixed as well as it can return SCHED_CAPACITY_SCALE ? Indeed. That should return unsigned int too as it's returning the uclamp value. Thanks -- Qais Yousef