Messages in this thread | | | Subject | Re: [PATCH v6 0/3] rpmsg: core: Add support for name extension | From | Suman Anna <> | Date | Mon, 8 Jun 2020 17:33:50 -0500 |
| |
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 >>>
| |