Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Lee Jones <lee.jones@linaro.org>]

On Tue, 11 Aug 2015, Viresh Kumar wrote:
> 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 ?

The framework does not need to parse this information.  It is used
solely by the platform driver, whose job it is to decide which OPPs
are appropriate for the running platform.

Back to my question; how would you like arbitrary version information,
which means different things to different vendors to be used in
shared/generic/framework code?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog