lkml.org 
[lkml]   [2023]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH V7 1/3] rpmsg: core: Add signal API support
    From
    Hi,

    On 6/14/23 17:24, Bjorn Andersson wrote:
    > On Mon, Apr 24, 2023 at 02:49:29PM +0200, Arnaud POULIQUEN wrote:
    >> Hello,
    >>
    >> On 4/22/23 12:42, Sarannya S wrote:
    >>> From: Deepak Kumar Singh <quic_deesin@quicinc.com>
    >>>
    >>> Some transports like Glink support the state notifications between
    >>> clients using flow control signals similar to serial protocol signals.
    >>> Local glink client drivers can send and receive flow control status
    >>> to glink clients running on remote processors.
    >>>
    >>> Add APIs to support sending and receiving of flow control status by
    >>> rpmsg clients.
    >>>
    >>> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
    >>> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
    >>> ---
    >>> drivers/rpmsg/rpmsg_core.c | 21 +++++++++++++++++++++
    >>> drivers/rpmsg/rpmsg_internal.h | 2 ++
    >>> include/linux/rpmsg.h | 15 +++++++++++++++
    >>> 3 files changed, 38 insertions(+)
    >>>
    >>> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
    >>> index a2207c0..e8bbe05 100644
    >>> --- a/drivers/rpmsg/rpmsg_core.c
    >>> +++ b/drivers/rpmsg/rpmsg_core.c
    >>> @@ -331,6 +331,25 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
    >>> EXPORT_SYMBOL(rpmsg_trysend_offchannel);
    >>>
    >>> /**
    >>> + * rpmsg_set_flow_control() - sets/clears serial flow control signals
    >>> + * @ept: the rpmsg endpoint
    >>> + * @enable: pause/resume incoming data flow
    >>> + * @dst: destination address of the endpoint
    >>> + *
    >>> + * Return: 0 on success and an appropriate error value on failure.
    >>> + */
    >>> +int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, bool enable, u32 dst)
    >>> +{
    >>> + if (WARN_ON(!ept))
    >>> + return -EINVAL;
    >>> + if (!ept->ops->set_flow_control)
    >>> + return -ENXIO;
    >>
    >> Here we return an error if the backend does not implement the ops.
    >> But the set_flow_control ops is optional.
    >> Should we return 0 instead with a debug message?
    >>
    >
    > It seems reasonable to allow the software to react to the absence of
    > flow control support, so a debug message wouldn't help.
    >
    > But advertising that more explicitly by returning something like
    > EOPNOTSUPP seems better.

    Right, this seems more reliable.

    Thanks,
    Arnaud

    >
    > Regards,
    > Bjorn

    \
     
     \ /
      Last update: 2023-06-15 10:51    [W:2.985 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site