linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
To: Sarannya S <quic_sarannya@quicinc.com>,
	<quic_bjorande@quicinc.com>, <swboyd@chromium.org>,
	<quic_clew@quicinc.com>, <mathieu.poirier@linaro.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<linux-remoteproc@vger.kernel.org>,
	Deepak Kumar Singh <quic_deesin@quicinc.com>,
	Bjorn Andersson <andersson@kernel.org>
Subject: Re: [PATCH V4 3/3] rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support
Date: Wed, 21 Dec 2022 17:28:16 +0100	[thread overview]
Message-ID: <12f53ff1-a358-7129-c9ed-9b9fd7dad7e7@foss.st.com> (raw)
In-Reply-To: <1670418258-11502-4-git-send-email-quic_sarannya@quicinc.com>



On 12/7/22 14:04, Sarannya S wrote:
> Add TICOMGET and TIOCMSET ioctl support for rpmsg char device nodes
> to get/set the low level transport signals.
> 
> Signed-off-by: Chris Lew <quic_clew@quicinc.com>
> Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com>
> Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
> ---
>  drivers/rpmsg/rpmsg_char.c | 60 +++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 52 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index 3e0b8f3..8109d18 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -23,6 +23,7 @@
>  #include <linux/rpmsg.h>
>  #include <linux/skbuff.h>
>  #include <linux/slab.h>
> +#include <linux/termios.h>
>  #include <linux/uaccess.h>
>  #include <uapi/linux/rpmsg.h>
>  
> @@ -68,6 +69,8 @@ struct rpmsg_eptdev {
>  	struct sk_buff_head queue;
>  	wait_queue_head_t readq;
>  
> +	u32 remote_signals;
> +	bool signals_pending;

Could you detail the need/use of signals_pending, in your implementation?
This is not obvious (at least for me)...

>  };
>  
>  int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
> @@ -109,7 +112,22 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void *buf, int len,
>  	skb_queue_tail(&eptdev->queue, skb);
>  	spin_unlock(&eptdev->queue_lock);
>  
> -	/* wake up any blocking processes, waiting for new data */
> +	wake_up_interruptible(&eptdev->readq);
> +
> +	return 0;
> +}
> +
> +static int rpmsg_ept_flow_cb(struct rpmsg_device *rpdev, void *priv, bool enable)
> +{
> +	struct rpmsg_eptdev *eptdev = priv;
> +
> +	if (enable)
> +		eptdev->remote_signals = TIOCM_DSR | TIOCM_CTS;
> +	else
> +		eptdev->remote_signals = 0;
> +
> +	eptdev->signals_pending = true;
> +
>  	wake_up_interruptible(&eptdev->readq);
>  
>  	return 0;
> @@ -146,6 +164,7 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
>  		return -EINVAL;
>  	}
>  
> +	ept->flow_cb = rpmsg_ept_flow_cb;
>  	eptdev->ept = ept;
>  	filp->private_data = eptdev;
>  	mutex_unlock(&eptdev->ept_lock);
> @@ -166,6 +185,7 @@ static int rpmsg_eptdev_release(struct inode *inode, struct file *filp)
>  		eptdev->ept = NULL;
>  	}
>  	mutex_unlock(&eptdev->ept_lock);
> +	eptdev->signals_pending = false;
>  
>  	/* Discard all SKBs */
>  	skb_queue_purge(&eptdev->queue);
> @@ -279,6 +299,9 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp, poll_table *wait)
>  	if (!skb_queue_empty(&eptdev->queue))
>  		mask |= EPOLLIN | EPOLLRDNORM;
>  
> +	if (eptdev->signals_pending)
> +		mask |= EPOLLPRI;
> +
>  	mask |= rpmsg_poll(eptdev->ept, filp, wait);
>  
>  	return mask;
> @@ -289,14 +312,35 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned int cmd,
>  {
>  	struct rpmsg_eptdev *eptdev = fp->private_data;
>  
> -	if (cmd != RPMSG_DESTROY_EPT_IOCTL)
> -		return -EINVAL;
> -
> -	/* Don't allow to destroy a default endpoint. */
> -	if (eptdev->default_ept)
> -		return -EINVAL;
> +	bool set;
> +	u32 val;
> +	int ret;
> +	
> +	switch (cmd) {
> +	case TIOCMGET:
> +		eptdev->signals_pending = false;
> +		ret = put_user(eptdev->remote_signals, (int __user *)arg);
> +		break;
> +	case TIOCMSET:
> +		ret = get_user(val, (int __user *)arg);
> +		if (ret)
> +			break;
> +		set = (val & (TIOCM_DTR | TIOCM_RTS)) ? true : false;
> +		ret = rpmsg_set_flow_control(eptdev->ept, set, 0);
> +		break;

I still wonder if it makes sense to implement serial IOCTRL in rpmsg_char.
I think it is quite dangerous to have such kind of mixed interface.
User application would want to use the serial interface should use the tty
interface.

For the rpmsg char, I would be in favor of creating a specific RPMSG IOCTRLs
to avoid confusion.

For instance:

 - RPMSG_GET_SIGN_IOCTRL
 - RPMSG_SET_SIGN_IOCTRL

With associated parameter corresponding to the bitmap proposed in my comment of
your patch 1/4.

Of course, this is only a suggestion, I let Bjorn and Mathieu comment.

Regards,
Arnaud


> +	case RPMSG_DESTROY_EPT_IOCTL:
> +		/* Don't allow to destroy a default endpoint. */
> +		if (eptdev->default_ept) {
> +			ret = -EINVAL;
> +			break;
> +		}
> +		ret = rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
>  
> -	return rpmsg_chrdev_eptdev_destroy(&eptdev->dev, NULL);
> +	return ret;
>  }
>  
>  static const struct file_operations rpmsg_eptdev_fops = {

  reply	other threads:[~2022-12-21 16:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-07 13:04 [PATCH V4 0/3] rpmsg signaling/flowcontrol patches Sarannya S
2022-12-07 13:04 ` [PATCH V4 1/3] rpmsg: core: Add signal API support Sarannya S
2022-12-21 16:12   ` Arnaud POULIQUEN
2022-12-27 15:32     ` Bjorn Andersson
2023-01-03 13:50       ` Arnaud POULIQUEN
2023-01-04 16:30         ` Bjorn Andersson
2023-01-04 18:31           ` Arnaud POULIQUEN
2022-12-07 13:04 ` [PATCH V4 2/3] rpmsg: glink: Add support to handle signals command Sarannya S
2022-12-07 13:04 ` [PATCH V4 3/3] rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support Sarannya S
2022-12-21 16:28   ` Arnaud POULIQUEN [this message]
2022-12-27 15:56     ` Bjorn Andersson
2023-01-03 14:50       ` Arnaud POULIQUEN
2023-01-04 16:03         ` Bjorn Andersson
2023-01-04 18:31           ` Arnaud POULIQUEN
  -- strict thread matches above, loose matches on Subject: below --
2022-11-28 18:02 [PATCH V4 0/3] rpmsg signaling/flowcontrol patches Sarannya S
2022-11-28 18:02 ` [PATCH V4 3/3] rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support Sarannya S
2022-11-28 13:28 [PATCH V4 1/3] rpmsg: core: Add signal API support Sarannya S
2022-11-28 13:28 ` [PATCH V4 3/3] rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support Sarannya S

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12f53ff1-a358-7129-c9ed-9b9fd7dad7e7@foss.st.com \
    --to=arnaud.pouliquen@foss.st.com \
    --cc=andersson@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=quic_bjorande@quicinc.com \
    --cc=quic_clew@quicinc.com \
    --cc=quic_deesin@quicinc.com \
    --cc=quic_sarannya@quicinc.com \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).