From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934229AbbHKKJs (ORCPT ); Tue, 11 Aug 2015 06:09:48 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:36190 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933911AbbHKKJq (ORCPT ); Tue, 11 Aug 2015 06:09:46 -0400 Date: Tue, 11 Aug 2015 15:39:41 +0530 From: Viresh Kumar To: Lee Jones Cc: Stephen Boyd , Rob Herring , Nishanth Menon , kernel@stlinux.com, "linux-pm@vger.kernel.org" , Dmitry Eremin-Solenikov , Rafael Wysocki , "linux-kernel@vger.kernel.org" , Sebastian Reichel , "devicetree@vger.kernel.org" , Arnd Bergmann , Ajit Pal Singh , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Message-ID: <20150811100941.GG5509@linux> References: <20150728225510.GB3159@codeaurora.org> <20150729081403.GH2284@x1> <20150729221526.GE3159@codeaurora.org> <20150730084634.GD9319@x1> <20150731163715.GV3159@codeaurora.org> <20150803034642.GV899@linux> <20150810132247.GH3249@x1> <20150811080023.GB5509@linux> <20150811093039.GA18282@x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150811093039.GA18282@x1> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11-08-15, 10:30, Lee Jones wrote: > On Tue, 11 Aug 2015, Viresh Kumar wrote: > > > On 10-08-15, 14:22, Lee Jones wrote: > > > > Optional properties: > > > > +- opp-cuts: One or more strings, describing the versions of hardware the OPPs > > > > + can support. > > > > > > This isn't very generic. > > > > > > I'm guessing some vendors my have quite a few ways to differentiate > > > between board versions/revisions/cuts etc. > > > > > > How about another array where a vendor can choose to identify a piece > > > of hardware however they see fit. > > > > > > Example 1 (simple version): > > > > > > /* Version 1 */ > > > opp-version = <1>; > > > > > > Example 2 (using the kernel's versioning): > > > > > > /* 2.6.32-rc1 */ > > > opp-version = <2 6 32 1>; > > > > > > Example 3 (using ST's versioning): > > > > > > /* Major 2, Minor 0, Cut 2, All substrates */ > > > opp-version = <2 0 2 0xff>; > > > > But how will we parse this with generic code ? > > Why would you want to? So that individual platforms don't need to reinvent the wheel ? -- viresh