From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751880AbdKBEwB (ORCPT ); Thu, 2 Nov 2017 00:52:01 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:49576 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751261AbdKBEv7 (ORCPT ); Thu, 2 Nov 2017 00:51:59 -0400 X-Google-Smtp-Source: ABhQp+RS00ZITtgrOp9dP/cIQlCLx/xzClp8CA6dFqtqEp/PpvSYzj+skJoBx2nOUNnSnvIKs9G7yA== Date: Thu, 2 Nov 2017 10:21:55 +0530 From: Viresh Kumar To: Stephen Boyd Cc: Rob Herring , Ulf Hansson , Kevin Hilman , Viresh Kumar , Nishanth Menon , Rafael Wysocki , "linux-pm@vger.kernel.org" , Vincent Guittot , Rajendra Nayak , Sudeep Holla , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values Message-ID: <20171102045155.GX4240@vireshk-i7> References: <23ba51eaa6b52117458165dccc00a95cf8e86e1d.1509453284.git.viresh.kumar@linaro.org> <20171101214333.GG30645@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171101214333.GG30645@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 On 01-11-17, 14:43, Stephen Boyd wrote: > On 11/01, Rob Herring wrote: > > On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar wrote: > > > On 31 October 2017 at 16:02, Rob Herring wrote: > > >> Why not a new property for magic values? opp-magic? Don't we want to > > >> know when we have magic values? > > > > > > I have kept a separate property since beginning (domain-performance-state) > > > and moved to using these magic values in the existing field because of the > > > suggestion Kevin gave earlier. > > > > > > https://marc.info/?l=linux-kernel&m=149306082218001&w=2 > > > > > > I am not sure what to do now :) > > > > Okay, I guess reusing the properties is fine. > > > > We call them corners on qcom platforms. Any reason we can't keep > using that name? I'd rather not have to keep telling people that > these fake values in some misnamed property is actually a corner. Surely not "corners", as these are platform and OS independent bindings we are talking about here. Even the kernel code shouldn't generally do that. Though your platform specific genpd driver can :) -- viresh