From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751798AbcDRVBT (ORCPT ); Mon, 18 Apr 2016 17:01:19 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:51633 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164AbcDRVBS (ORCPT ); Mon, 18 Apr 2016 17:01:18 -0400 From: Arnd Bergmann To: linaro-kernel@lists.linaro.org Cc: Viresh Kumar , Rob Herring , Rob Herring , Krzysztof =?utf-8?B?S296xYJvd3NraQ==?= , Kukjin Kim , Heiko =?ISO-8859-1?Q?St=FCbner?= , "linux-pm@vger.kernel.org" , Matthew McClintock , xf@rock-chips.com, Rafael Wysocki , "linux-kernel@vger.kernel.org" , Mason Subject: Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support Date: Mon, 18 Apr 2016 23:00:46 +0200 Message-ID: <5357210.7C6VxI046A@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160407083036.GB3201@vireshk-i7> References: <20160407083036.GB3201@vireshk-i7> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:9Apc0XnF9JQKUV7oSkmNTWk+rzyAJ6DhQz3VY91kF9RfGRCXQ0D F7RliXEQlg/gAgs+c1MpF5RWRmOQ8Vqip8cjeAYRn3bn1Khjk+3J9ZmRcr+83XRjIei3pfr dOWtbPVUaw2qlb+EgZE3IDh9SEDaZIIE7Ba8yxoJRcAGADz9F3YV4PNgD5PbPHoeLAW+iKS oFIrrnSkbDKn3Rs2X24UQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:TkPuwN6SDSk=:zB1cg5WxZ3XLgR4U44p+q+ OfIelfoZZt62xbogoHzxXGsQHjHZyinYw1JUvET3BgbVz8ni5zz2wEutVcCeH14tz56tfntLw Q0kPPsbhHHuw2VJW/x+RUzCbRvK9PxAz2yqo4c8u4+qXBDGgQtBNEwnvP+SDg0anezymczMSh iJbl/hnaRE0dHT0fOpm2xVC32a2i776+2tZdXX/Q18mR9TyNjWe4kde534gBC5acnDfZBEXs8 QL8TpDe/7ByhlV2rRFe6IyYy1asIN0Yom9BUvwMPJWBNXZUiAfkBdgeiuNlhNg0JMFPp51qOg eCns5wNORiDCkbW/pLBglOM0qkrrpKCoWzsnxZdtUMLfnsrGU7KmlX3IRfO522polfRnMfw0m P94axt1b4z63NG0rHRWJjlUhRMv3zwTDFnRxcSuB8cQRLyCjre24h910IsKmjZzwjBKcCkIfj f/zxS9GXOYmFVCyBE4vqPyQwIkSR4JoxUEf9lSkMSyvyr9I0nJtEVP3vDkz37DoNiUcGsP+QT Zr7Fx6jgUSqTYjW7TR+5OGWTS7j0aDq7wBq7oMc8QirvPcJfxy5QhP2vEWPnLejjRCuC8vKic BSlvnZ3IMYt663GBYhHc5oy/I22aGc2sNTrUxarCHJCpBRNRxdgCOT5LYJiz2a2bHhw7VjYNv dkJlOuXfTurl+ZZ+D0bb9Q/oNhRxkESj6tCSeQuEt0t++txrf+b3u42GlZHndCai3H0trfxCh DpoID/uSF5F5IaKX Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 07 April 2016 14:00:36 Viresh Kumar wrote: > On 01-04-16, 09:15, Rob Herring wrote: > > On Fri, Apr 1, 2016 at 5:23 AM, Viresh Kumar wrote: > > > > > > > > > And the cpufreq-dt driver can match /cpus node's compatible string against > > > "operating-points-v2" and create a device at runtime ? > > > > > > @Rob: Will that be acceptable to you? We are discussing (again) about how to > > > probe cpufreq-dt driver automatically for platforms > > > > No, I don't think that belongs in /cpus. > > > > Part of the problem is this requires a DT change if you switch between > > a platform-specific driver and generic driver. > > Right. How likely is that to happen for future platforms though? I'd rather see a whitelist for the existing platforms (as started by Viresh), because we don't know what other out-of-tree platforms use the "operating-points-v2" binding that are in fact not compatible with today's driver. If we add one way to identify machines that are known to follow the binding to the degree necessary to make them work with the Linux driver (whatever way that would be), then the only remaining worry is about machines suddenly breaking because of a change in the Linux driver, and we can work around that in the kernel if necessary (or revert whatever broke the platform). > > I don't understand the issue having a little bit of code to parse the > > DT and create the device. > > I am fine with that, we were just re-evaluating our options > > > If you are worried about having a long list > > of platforms, > > At least I am not. The length of the list is not the issue here, it's the requirement to edit the list for each new SoC that gets added. That causes conflicts and constant churn. > > you could instead check the tree for operating-points-v2 > > property in the cpu node and create the device unless the platform is > > black-listed. > > I don't really like the black-list idea much. It forces a Non > cpufreq-dt platform to edit cpufreq-dt related file, just to make its > own cpufreq driver work. > > I find that ugly somehow Agreed. Sorry for the late reply, I'm still catching up with email from two weeks of travelling. Arnd