Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v6 0/3] rpmsg: core: Add support for name extension
To:     Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>
CC:     <ohad@wizery.com>, <linux-remoteproc@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, Xiang Xiao <xiaoxiang@xiaomi.com>
References: <20200515205642.13529-1-mathieu.poirier@linaro.org>
 <20200515210914.GA408178@builder.lan>
 <bbc97b0d-b36c-c088-a972-d1d10f7eed17@st.com>
From:   Suman Anna <s-anna@ti.com>
Message-ID: <8e69229b-ece2-18b8-aa8c-01c105aa38bb@ti.com>
Date:   Mon, 8 Jun 2020 17:33:50 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <bbc97b0d-b36c-c088-a972-d1d10f7eed17@st.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 5/20/20 9:49 AM, Arnaud POULIQUEN wrote:
> Hi Bjorn,
> 
> On 5/15/20 11:09 PM, Bjorn Andersson wrote:
>> On Fri 15 May 13:56 PDT 2020, Mathieu Poirier wrote:
>>
>>> This patchset adds the capability to supplement the base definition
>>> published by an rpmsg_driver with a postfix description so that it
>>> is easy to differentiate entities that use the same name service.
>>>
>>> Applies cleanly on rpmsg-next (4f05fc33bebd).
>>>
>>
>> Thanks Mathieu, this series does look good.
>>
>>
>> But before merging this, can someone show me a real example where this
>> is being/would be used? What are some real channel names and extensions?
> 
> On ST side, This is something we plan to integrate in the TTY over RPMSG support.
> The use case is the support of multi-instances. We already provided to our
> customer a TTY service supporting it but without name extension.
> Some feed-backs are: how can we know which TTY instances to use to communicate
> to the expected remote application in case of multi-instance.
> A concrete example would be one instance to control a remote processor
> application, the other instance to get the remote system logs.
> 
> Then in rpmsg TTY proposed for upstream the extension could also been used to
> differentiate the data from the control channels, as discussed with Mathieu
> during reviews: https://lkml.org/lkml/2020/4/3/964.
> Means the service is the TTY, the sub-services are the data and the control.
> 
> An other usecase i have in mind is the management of the rpmsg flow control for
> the QOS.
> This could be reused to create a core flow control manager based on the
> service extension, which could be quite smooth in term of legacy support.
> 
> Suman and Xiang(added in CC) have probably also some usecases as they
> proposed similar patches...

Yeah, this series is a result of the discussion on those prior patches, 
and maintaining compatibility for both the current in-kernel usage and 
the OpenAMP usage.

My original usecase was with an out-of-tree driver and is explained as 
part of review of those prior solution,
https://patchwork.kernel.org/comment/22850003/

I am also looking at this for future usage with the rpmsg-chrdev driver.

regards
Suman


> 
> Regards,
> Arnaud
> 
>>
>> Regards,
>> Bjorn
>>
>>> New for V6:
>>> - Added example on how to use the new API.
>>>
>>> Thanks,
>>> Mathieu
>>>
>>>
>>> Mathieu Poirier (3):
>>>    rpmsg: core: Add wildcard match for name service
>>>    rpmsg: core: Add support to retrieve name extension
>>>    sample/rpmsg: Print out RPMSG device name extension
>>>
>>>   drivers/rpmsg/rpmsg_core.c          | 115 +++++++++++++++++++++++++++-
>>>   include/linux/rpmsg.h               |  13 ++++
>>>   samples/rpmsg/rpmsg_client_sample.c |   5 ++
>>>   3 files changed, 132 insertions(+), 1 deletion(-)
>>>
>>> -- 
>>> 2.20.1
>>>