On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > On 10/11/16 14:12, Rob Herring wrote: >> >> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@xxxxxxx> >> wrote: >>> >>> >>> >>> On 10/11/16 01:22, Rob Herring wrote: >>>> >>>> >>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: >>>>> >>>>> >>>>> This patch adds specific compatible to support legacy SCPI protocol. >>>>> >>>>> Cc: Rob Herring <robh+dt@xxxxxxxxxx> >>>>> Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxx> >>>>> --- >>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> index d1882c4540d0..ebd03fc93135 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power >>>>> operations. >>>>> >>>>> Required properties: >>>>> >>>>> -- compatible : should be "arm,scpi" >>>>> +- compatible : should be >>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or >>>>> above >>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI >>>>> v1.0 >>>> >>>> >>>> >>>> I'd prefer that we explicitly enumerate the old versions. Are there >>>> many? >>>> >>> >>> I understand your concern, but this legacy SCPI protocol was not >>> officially released. It was just WIP which vendors picked up from very >>> early releases. Since they are not numbered, it's hard to have specific >>> compatibles with different versions until v1.0. That's one of the reason >>> to retain platform specific compatible so that we can add any quirks >>> based on them if needed. >>> >>> I will probably add these information in the commit log so that it's >>> clear why we can't do version based compatible. >> >> >> This is exactly my point. By enumerate, I meant having platform >> specific compatibles. Having "arm,legacy-scpi" is pointless because >> who knows what version they followed and they may all be different. >> > > OK, but IIUC Olof's concern wanted a generic one along with the platform > specific compatible which kind of makes sense as so far we have seen > some commonality between Amlogic and Rockchip. > > E.g. Amlogic follows most of the legacy protocol though it deviates in > couple of things which we can handle with platform specific compatible > (in the following patch in the series). When another user(Rockchip ?) > make use of this legacy protocol, we can start using those platform > specific compatible for deviations only. > > Is that not acceptable ? If there's no shared legacy feature set, then it's probably less useful to have a shared less precise compatible value. What the main point I was trying to get across was that we shouldn't expand the generic binding with per-vendor compatible fields, instead we should have those as extensions on the side. I'm also a little apprehensive of using "legacy", it goes in the same bucket as "misc". At some point 1.0 will be legacy too, etc. -Olof -- 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
