From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752697AbdEIKb7 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 9 May 2017 06:31:59 -0400
Received: from mail-qk0-f169.google.com ([209.85.220.169]:35805 "EHLO
        mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752552AbdEIKb5 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 9 May 2017 06:31:57 -0400
MIME-Version: 1.0
In-Reply-To: <ec7869d0-fa18-ec9e-3df7-ac841e06b2d1@arm.com>
References: <1493733353-25812-1-git-send-email-sudeep.holla@arm.com>
 <1493733353-25812-3-git-send-email-sudeep.holla@arm.com> <20170508161026.5vdqnv52ub7hurwf@rob-hp-laptop>
 <CABb+yY1+rU=gEnqML=ybZ61WDW6Brz_QLw4LpYNNe-XsEgi8dw@mail.gmail.com>
 <ff6535ec-fa31-e0b7-53a1-9f4a2f03693d@arm.com> <CABb+yY3tXMgQdQratM56mQVEV4Med1i0NyT=zkXk1P4oCao6+A@mail.gmail.com>
 <ec7869d0-fa18-ec9e-3df7-ac841e06b2d1@arm.com>
From: Jassi Brar <jassisinghbrar@gmail.com>
Date: Tue, 9 May 2017 16:01:55 +0530
Message-ID: <CABb+yY1S_aRGDZJwVt+p7U6PcO2dQGsg5bi21-yvx715HGjUtw@mail.gmail.com>
Subject: Re: [PATCH 2/6] Documentation: devicetree: add bindings to support
 ARM MHU subchannels
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Rob Herring <robh@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Alexey Klimov <alexey.klimov@arm.com>,
        Jassi Brar <jaswinder.singh@linaro.org>,
        Devicetree List <devicetree@vger.kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, May 9, 2017 at 3:28 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

>>
>> If it is still not clear, please share your client driver. I will
>> adapt that to work with existing MHU driver & bindings.
>>
>
> Just take example of SCPI in the mainline. Assume there's another
> protocol SCMI which uses few more bits in the same channel and the
> remote firmware implements both but both are totally independent and not
> related/linked. Also be keep in mind that SCPI is used by other
> platforms and so will be the new protocol. We simply make SCPI or SCMI
> bindings aligned to ARM MHU. That's ruled out.
>
Not sure what you mean by "that's ruled out". Anyways, to be clear,
the bindings must remain same as long as the h/w doesn't change. It is
the client driver (DT node) that should be versioned for SCPI or SCMI
based on what the platform supports.

I have tried many ways to explain how to implement it and apparently
failed. So lets talk code.
You have already shared this "v2" MHU driver, now please also share
your client driver. I'll make it work with original MHU driver and
that should settle your confusion.

Thanks.