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:     Bjorn Andersson <bjorn.andersson@linaro.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>
CC:     <ohad@wizery.com>, <s-anna@ti.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>
From:   Arnaud POULIQUEN <arnaud.pouliquen@st.com>
Message-ID: <bbc97b0d-b36c-c088-a972-d1d10f7eed17@st.com>
Date:   Wed, 20 May 2020 16:49:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200515210914.GA408178@builder.lan>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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...

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
>>