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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
