Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1722120ybg; Sat, 19 Oct 2019 01:05:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqxU1BI8rwI4vhuXIK+juG6JkgCcQnXZod7Tn05Hfqa4weqXm5Nw8W/v1qs3D3EeqI8VT9VW X-Received: by 2002:a17:906:c82e:: with SMTP id dd14mr3380026ejb.310.1571472328269; Sat, 19 Oct 2019 01:05:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571472328; cv=none; d=google.com; s=arc-20160816; b=ZiYYQBQzUkBAV3jiKgVbqDUPojY+0tUK9oKnAkaFl+V0HJkvbJZYXv5QBCapPEJhzo /d1lhq4EmfPA4V4ddVzPme9HycXqvKilkWcbyqtoSrF8IC8tQ1/oCZcLrsZJzNlyA6GE En+Z8L/FNs0vCqc39pyghukszgQaUk122BlxZ3a8TeYRbFKNSlOAEfjQw9WIC1k953O0 aT4mahr4j5lWbk2MX3i2VU4j11A2t/s4jKVwz9B9JwQ/8WcNnFxWCo2bpW+W69pu6PQm fLRk1Y6QrzFyLhPgeC8hTBLFX0LVfk6NDAj9KNShEghOna27QY0EJYxi9UU1nkJ78bMM yjxQ== 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:dkim-signature; bh=V3RrnhLavTjOu4XjHWUy1bDOhkG5uBMC/iS8OEbXenw=; b=CsrjzDcIW8Ton1edObUz1uo5+zi3c4x/lI9pz3u0TFaF6ymYfeWRBk4urNZTo/Mr6T +SRu0/Q0FgGc3tTfLLYaJeUlt57Hj8WKkiKmAtQHLwdeNFprN5ycsbWohUgUF05Y4HfJ RZbe7/jzJdjeXq2COzys/3R2UsTSQ3at4TilnarTHlDgxD//jTkWZfyXdm3wIqh8uoz5 Ob/FGXAYBiD39zr82i7BRWi97nV2rElu173YGm3Plk7QicohU/vD2wWrGdY1FSgW53Uj LbBrLZpGRyrGjs+aaRrvO1emDYrNpk0RJggtmREdDgIiPPH0cgWe91fwg6gAdyIKjpeq 0WXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=HnLBkQV0; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 34si6279627edk.26.2019.10.19.01.05.05; Sat, 19 Oct 2019 01:05:28 -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; dkim=pass header.i=@linaro.org header.s=google header.b=HnLBkQV0; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395008AbfJRJ3D (ORCPT + 99 others); Fri, 18 Oct 2019 05:29:03 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:34427 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728723AbfJRJ3D (ORCPT ); Fri, 18 Oct 2019 05:29:03 -0400 Received: by mail-pg1-f195.google.com with SMTP id k20so3057628pgi.1 for ; Fri, 18 Oct 2019 02:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=V3RrnhLavTjOu4XjHWUy1bDOhkG5uBMC/iS8OEbXenw=; b=HnLBkQV0TcUy4MGD4CYNgCZJNMDfdyoYbbUYDRENkWjyB5g/6AV14CtgdFow1/0nnn T4FbNLbkpTMe15ww/JHfETzg97tP2HrfU+dikdh+zLj5XMZxcZ24bnR5bZTrAxz/SnDF dnA5n+TQdb6UgtdUDQEpH4OhTM1UqngIa42rKKyEKF28CgGOQHq8OuWQNY/Nq0rSzrr6 bUnMC2Fi5HnRQ4xYxWZsNxrii73sy2u9aF7aLIyYO+mZW++NQpQodzzoZ2Q1z23fpxMQ eSZ2PmeaVrOQiWCXjDT9IxkvMtjyWn7pOYT0jdAGv4UyvbSj9rzYXTBx271Bj6c3Nlhu tgoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=V3RrnhLavTjOu4XjHWUy1bDOhkG5uBMC/iS8OEbXenw=; b=RR5l0odk+A0LbS1wvsZEtmwZe/+M+pqu4aEhp0y8v9lfhp80sIqssCelcmnYqgVQ7Y UVGUNFHnpc8chUqRZy92Sr8MiOe1KB64W6euSP88b4pICzJKpSTa4sKzjPaELvcWytw9 zhHdw3bGCppxKaEcon1B85QvuPM0fhNo4hLfHE3J/kDcq2zQp5eth3U6FkxKjTnXwqGj PGPyEWuzLvS6u8dr85pub3Gc45r2Mkf3mWuZg378pSR56oZ9W+eR79J6poRfGYIagaf2 +SQtjbIh8SU9lC7yi2sbAEnHHVQnDy/vD4jgAgMiuWb9lEY8XZ/OLLR49TLW0Sw2LF1P 3tJg== X-Gm-Message-State: APjAAAVdg4vRQrF/6B6f7KBFluBSdtGDneNxLSWAWLtLk4JLz/dwSwYl pLe96ADW0N5m5lmGeelSGV0xUg== X-Received: by 2002:a17:90a:32e4:: with SMTP id l91mr10004158pjb.48.1571390942762; Fri, 18 Oct 2019 02:29:02 -0700 (PDT) Received: from localhost ([122.172.151.112]) by smtp.gmail.com with ESMTPSA id ce16sm5416635pjb.29.2019.10.18.02.28.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Oct 2019 02:29:01 -0700 (PDT) Date: Fri, 18 Oct 2019 14:58:57 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Sudeep Holla , "Rafael J. Wysocki" , Linux PM , Linux ACPI , LKML , Dmitry Osipenko Subject: Re: [RFT][PATCH 0/3] cpufreq / PM: QoS: Introduce frequency QoS and use it in cpufreq Message-ID: <20191018092857.dfg6n3xcbdsfjr4r@vireshk-i7> References: <20191016142343.GB5330@bogus> <20191017095725.izchzl7enfylvpf3@vireshk-i7> <20191017095942.GF8978@bogus> <20191018054433.tq2euue675xk4o63@vireshk-i7> <20191018082745.3zr6tc3yqmbydkrw@vireshk-i7> <20191018092447.2utqazqfob65x4k2@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18-10-19, 11:26, Rafael J. Wysocki wrote: > On Fri, Oct 18, 2019 at 11:24 AM Viresh Kumar wrote: > > > > On 18-10-19, 10:30, Rafael J. Wysocki wrote: > > > On Fri, Oct 18, 2019 at 10:27 AM Viresh Kumar wrote: > > > > > > > > On 18-10-19, 10:24, Rafael J. Wysocki wrote: > > > > > On Fri, Oct 18, 2019 at 7:44 AM Viresh Kumar wrote: > > > > > > > > > > > > On 17-10-19, 18:34, Rafael J. Wysocki wrote: > > > > > > > [BTW, Viresh, it looks like cpufreq_set_policy() should still ensure > > > > > > > that the new min is less than the new max, because the QoS doesn't do > > > > > > > that.] > > > > > > > > > > > > The ->verify() callback does that for us I believe. > > > > > > > > > > It does in practice AFAICS, but in theory it may assume the right > > > > > ordering between the min and the max and just test the boundaries, may > > > > > it not? > > > > > > > > I think cpufreq_verify_within_limits() gets called for sure from > > > > within ->verify() for all platforms > > > > > > That's why I mean by "in practice". :-) > > > > Hmm, I am not sure if we should really add another min <= max check in > > cpufreq_set_policy() as in practice it will never hit :) > > Fair enough, but adding a comment regarding that in there would be prudent IMO. will do. -- viresh