lkml.org 
[lkml]   [2019]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 2/2] tty: add rpmsg driver
From
Date
Hello Jiri,

On 5/22/19 11:01 AM, Jiri Slaby wrote:
> On 17. 05. 19, 16:27, Arnaud Pouliquen wrote:
>> This driver exposes a standard tty interface on top of the rpmsg
>> framework through the "rpmsg-tty-channel" rpmsg service.
>>
>> This driver supports multi-instances, offering a /dev/ttyRPMSGx entry
>> per rpmsg endpoint.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
>> ---
>> Documentation/serial/tty_rpmsg.txt | 38 +++
>> drivers/tty/Kconfig | 9 +
>> drivers/tty/Makefile | 1 +
>> drivers/tty/rpmsg_tty.c | 479 +++++++++++++++++++++++++++++++++++++
>> 4 files changed, 527 insertions(+)
>> create mode 100644 Documentation/serial/tty_rpmsg.txt
>> create mode 100644 drivers/tty/rpmsg_tty.c
>>
>> diff --git a/Documentation/serial/tty_rpmsg.txt b/Documentation/serial/tty_rpmsg.txt
>> new file mode 100644
>> index 000000000000..e069ed268a2b
>> --- /dev/null
>> +++ b/Documentation/serial/tty_rpmsg.txt
>> @@ -0,0 +1,38 @@
>> +
>> + The rpmsg TTY
>
> Perhaps you should use rst nowadays.
>
>> diff --git a/drivers/tty/rpmsg_tty.c b/drivers/tty/rpmsg_tty.c
>> new file mode 100644
>> index 000000000000..c7f53352acb6
>> --- /dev/null
>> +++ b/drivers/tty/rpmsg_tty.c
>> @@ -0,0 +1,479 @@
> ...
>> +struct rpmsg_tty_port {
>> + struct tty_port port; /* TTY port data */
>> + int id; /* TTY rpmsg index */
>> + struct rpmsg_device *rpdev; /* rpmsg device */
>> + int cts; /* remote reception status */
>
> Just a nit, but if you move this int to the one above, you save some
> bytes thanks to alignment and holes.
Indeed for 64 bit arch can be more optimized
>
>> +};
>> +
>> +typedef void (*rpmsg_tty_rx_cb_t)(struct rpmsg_device *, void *, int, void *,
>> + u32);
>> +
>> +static void rpmsg_tty_data_handler(struct rpmsg_device *rpdev, void *data,
>> + int len, void *priv, u32 src)
>> +{
>> + struct rpmsg_tty_port *cport = dev_get_drvdata(&rpdev->dev);
>> + u8 *cbuf;
>> + int space;
>> +
>> + dev_dbg(&rpdev->dev, "msg(<- src 0x%x) len %d\n", src, len);
>> +
>> + if (!len)
>> + return;
>> +
>> + space = tty_prepare_flip_string(&cport->port, &cbuf, len);
>> + if (space != len)
>> + dev_dbg(&rpdev->dev, "trunc buffer: available space is %d\n",
>> + len, space);
>> + if (space <= 0)
>> + return;
>> +
>> + memcpy(cbuf, data, space);
>
> Why is the above not tty_insert_flip_string_fixed_flag instead?
Just because i was not aware about this (i parsed driver/tty looking for
an example), thanks to reporting it to me!
>
>> + tty_flip_buffer_push(&cport->port);
>> +}
>> +
>> +static void rpmsg_tty_ctrl_handler(struct rpmsg_device *rpdev, void *data,
>> + int len, void *priv, u32 src)
>> +{
>> + struct rpmsg_tty_port *cport = dev_get_drvdata(&rpdev->dev);
>> + struct rpmsg_tty_ctrl *ctrl = data;
>> +
>> + dev_dbg(&rpdev->dev, "%s: ctrl received %d\n", __func__, ctrl->ctrl);
>> + print_hex_dump_debug(__func__, DUMP_PREFIX_NONE, 16, 1, data, len,
>> + true);
>> +
>> + if (len <= sizeof(*ctrl)) {
>> + dev_err(&rpdev->dev, "%s: ctrl message invalid\n", __func__);
>> + return;
>> + }
>> +
>> + if (ctrl->ctrl == DATA_TERM_READY) {
>
> Could this be switch-case instead?
Yes for future extension, i hesitated... "if" seems more optimized if
only one case.
>
>> + /* Update the CTS according to remote RTS */
>> + if (!ctrl->values[0]) {
>> + cport->cts = 0;
>> + } else {
>> + cport->cts = 1;
>> + tty_port_tty_wakeup(&cport->port);
>> + }
>> + } else {
>> + dev_err(&rpdev->dev, "unknown control ID %d\n", ctrl->ctrl);
>> + }
>> +}
>> +
>> +static const rpmsg_tty_rx_cb_t rpmsg_tty_handler[] = {
>> + [RPMSG_DATA] = rpmsg_tty_data_handler,
>> + [RPMSG_CTRL] = rpmsg_tty_ctrl_handler,
>> +};
>> +
>> +static int rpmsg_tty_cb(struct rpmsg_device *rpdev, void *data, int len,
>> + void *priv, u32 src)
>> +{
>> + struct rpmsg_tty_payload *rbuf = data;
>> +
>> + if (len <= sizeof(*rbuf) || rbuf->cmd > NUM_RPMSG_TTY_TYPE) {
>> + dev_err(&rpdev->dev, "Invalid message: size %d, type %d\n",
>> + len, rbuf->cmd);
>> + return -EINVAL;
>> + }
>> +
>> + rpmsg_tty_handler[rbuf->cmd](rpdev, &rbuf->data,
>> + len - sizeof(rbuf->cmd), priv, src);
>
> Out-of-bound access if rbuf->cmd == NUM_RPMSG_TTY_TYPE, right? Nice hole.
oops...this kind of error should not allowed on such a basic test :(

>> +
>> + return 0;
>> +}
>> +
>> +static int rpmsg_tty_write_control(struct tty_struct *tty, u8 ctrl, u8 *values,
>> + unsigned int n_value)
>> +{
>> + struct rpmsg_tty_port *cport = idr_find(&tty_idr, tty->index);
>> + struct rpmsg_tty_payload *msg;
>> + struct rpmsg_tty_ctrl *m_ctrl;
>> + struct rpmsg_device *rpdev;
>> + unsigned int msg_size;
>> + int ret;
>> +
>> + if (!cport) {
>> + dev_err(tty->dev, "cannot get cport\n");
>> + return -ENODEV;
>> + }
>> +
>> + rpdev = cport->rpdev;
>> +
>> + msg_size = sizeof(*msg) + sizeof(*m_ctrl) + n_value;
>> + msg = kzalloc(msg_size, GFP_KERNEL);
>> + if (!msg)
>> + return -ENOMEM;
>> +
>> + msg->cmd = RPMSG_CTRL;
>> + m_ctrl = (struct rpmsg_tty_ctrl *)&msg->data[0];
>> + m_ctrl->ctrl = DATA_TERM_READY;
>> + memcpy(m_ctrl->values, values, n_value);
>> +
>> + ret = rpmsg_trysend(rpdev->ept, msg, msg_size);
>> + if (ret < 0) {
>> + dev_dbg(tty->dev, "cannot send control (%d)\n", ret);
>> + ret = 0;
>> + }
>> + kfree(msg);
>> +
>> + return ret;
>> +};
>> +
>> +static void rpmsg_tty_throttle(struct tty_struct *tty)
>> +{
>> + u8 rts = 0;
>> +
>> + /* Disable remote transmission */
>> + rpmsg_tty_write_control(tty, DATA_TERM_READY, &rts, 1);
>> +};
>> +
>> +static void rpmsg_tty_unthrottle(struct tty_struct *tty)
>> +{
>> + u8 rts = 1;
>> +
>> + /* Enable remote transmission */
>> + rpmsg_tty_write_control(tty, DATA_TERM_READY, &rts, 1);
>> +};
>> +
>> +static int rpmsg_tty_install(struct tty_driver *driver, struct tty_struct *tty)
>> +{
>> + struct rpmsg_tty_port *cport = idr_find(&tty_idr, tty->index);
>> +
>> + if (!cport) {
>> + dev_err(tty->dev, "cannot get cport\n");
>> + return -ENODEV;
>> + }
>
> Set cport to driver_data?
Yes would be more optimized, i will test it.
>
>> +
>> + return tty_port_install(&cport->port, driver, tty);
>> +}
>> +
>> +static int rpmsg_tty_open(struct tty_struct *tty, struct file *filp)
>> +{
>> + return tty_port_open(tty->port, tty, filp);
>> +}
>> +
>> +static void rpmsg_tty_close(struct tty_struct *tty, struct file *filp)
>> +{
>> + return tty_port_close(tty->port, tty, filp);
>> +}
>> +
>> +static int rpmsg_tty_write(struct tty_struct *tty, const u8 *buf, int len)
>> +{
>> + struct rpmsg_tty_port *cport = idr_find(&tty_idr, tty->index);
>
> Get from driver_data?
>
>> + struct rpmsg_device *rpdev;
>> + int msg_size, msg_max_size, ret = 0;
>> + int cmd_sz = sizeof(struct rpmsg_tty_payload);
>> + u8 *tmpbuf;
>> +
>> + if (!cport) {
>
> This would be superflous then?
yes
>
>> + dev_err(tty->dev, "cannot get cport\n");
>> + return -ENODEV;
>> + }
>> +
>> + /* If cts not set, the message is not sent*/
>> + if (!cport->cts)
>> + return 0;
>> +
>> + rpdev = cport->rpdev;
>> +
>> + dev_dbg(&rpdev->dev, "%s: send msg from tty->index = %d, len = %d\n",
>> + __func__, tty->index, len);
>> + if (!buf) {
>
> How can this happen?
overprotection, i will clean it
>
>> + dev_err(&rpdev->dev, "buf shouldn't be null.\n");
>> + return -ENOMEM;
>> + }
>> +
>> + msg_max_size = rpmsg_get_buf_payload_size(rpdev->ept);
>> + if (msg_max_size < 0)
>> + return msg_max_size;
>> +
>> + msg_size = min(len + cmd_sz, msg_max_size);
>> + tmpbuf = kzalloc(msg_size, GFP_KERNEL);
>> + if (!tmpbuf)
>> + return -ENOMEM;
>> +
>> + tmpbuf[0] = RPMSG_DATA;
>> + memcpy(&tmpbuf[cmd_sz], buf, msg_size - cmd_sz);
>
> Just curious: could "msg_size - cmd_sz" overflow to negatives? i.e.
> msg_max_size < sizeof(struct rpmsg_tty_payload)?
In theory this could not happen today as rpmsg payload size is fixed to
496 bytes. In future this size could be customizable. But this would
be a design issue.

>
>> +
>> + /*
>> + * Try to send the message to remote processor, if failed return 0 as
>> + * no data sent
>> + */
>> + ret = rpmsg_trysend(rpdev->ept, (void *)tmpbuf, msg_size);
>
> No need to cast.
>
>> + kfree(tmpbuf);
>> + if (ret) {
>> + dev_dbg(&rpdev->dev, "rpmsg_send failed: %d\n", ret);
>> + return 0;
>> + }
>> +
>> + return msg_size - sizeof(struct rpmsg_tty_payload);
>
> The latter is cmd_sz or not?
yes to be replaced for readability.
>
>> +}
>> +
>> +static int rpmsg_tty_write_room(struct tty_struct *tty)
>> +{
>> + struct rpmsg_tty_port *cport = idr_find(&tty_idr, tty->index);
>> + int space = 0;
>> +
>> + if (!cport) {
>
> The same as above.
>
>> + dev_err(tty->dev, "cannot get cport\n");
>> + return -ENODEV;
>> + }
>> +
>> + /*
>> + * Report the space in the rpmsg buffer, first byte is reserved to
>> + * define the buffer type.
>> + */
>> + if (cport->cts) {
>> + space = rpmsg_get_buf_payload_size(cport->rpdev->ept);
>> + space -= sizeof(struct rpmsg_tty_payload);
>> + }
>> +
>> + return space;
>> +}
>> +
>> +static const struct tty_operations rpmsg_tty_ops = {
>> + .install = rpmsg_tty_install,
>> + .open = rpmsg_tty_open,
>> + .close = rpmsg_tty_close,
>> + .write = rpmsg_tty_write,
>> + .write_room = rpmsg_tty_write_room,
>> + .throttle = rpmsg_tty_throttle,
>> + .unthrottle = rpmsg_tty_unthrottle,
>> +};
>> +
>> +static struct rpmsg_tty_port *rpmsg_tty_alloc_cport(void)
>> +{
>> + struct rpmsg_tty_port *cport;
>> +
>> + cport = kzalloc(sizeof(*cport), GFP_KERNEL);
>> + if (!cport)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + mutex_lock(&idr_lock);
>> + cport->id = idr_alloc(&tty_idr, cport, 0, MAX_TTY_RPMSG, GFP_KERNEL);
>> + mutex_unlock(&idr_lock);
>> +
>> + if (cport->id < 0) {
>> + kfree(cport);
>> + return ERR_PTR(-ENOSPC);
>> + }
>> +
>> + return cport;
>> +}
>> +
>> +static void rpmsg_tty_release_cport(struct rpmsg_tty_port *cport)
>> +{
>> + mutex_lock(&idr_lock);
>> + idr_remove(&tty_idr, cport->id);
>> + mutex_unlock(&idr_lock);
>> +
>> + kfree(cport);
>> +}
>> +
>> +static int rpmsg_tty_port_activate(struct tty_port *p, struct tty_struct *tty)
>> +{
>> + /* Allocate the buffer we use for writing data */
>> + return tty_port_alloc_xmit_buf(p);
>> +}
>> +
>> +static void rpmsg_tty_port_shutdown(struct tty_port *p)
>> +{
>> + /* Free the write buffer */
>> + tty_port_free_xmit_buf(p);
>> +}
>> +
>> +static void rpmsg_tty_dtr_rts(struct tty_port *port, int raise)
>> +{
>> + struct rpmsg_tty_port *cport =
>> + container_of(port, struct rpmsg_tty_port, port);
>> +
>> + pr_debug("%s: dtr_rts state %d\n", __func__, raise);
>> + if (!port->tty || !cport) {
>
> The latter barely can happen given you use container_of above.
overprotection again
>
>> + pr_err("invalid port\n");
>> + return;
>> + }
>> +
>> + cport->cts = raise;
>> +
>> + if (raise)
>> + rpmsg_tty_unthrottle(port->tty);
>> + else
>> + rpmsg_tty_throttle(port->tty);
>> +}
>> +
>> +static const struct tty_port_operations rpmsg_tty_port_ops = {
>> + .activate = rpmsg_tty_port_activate,
>> + .shutdown = rpmsg_tty_port_shutdown,
>> + .dtr_rts = rpmsg_tty_dtr_rts,
>> +};
>> +
>> +static int rpmsg_tty_probe(struct rpmsg_device *rpdev)
>> +{
>> + struct rpmsg_tty_port *cport;
>> + struct device *dev = &rpdev->dev;
>> + struct device *tty_dev;
>> + int ret;
>> +
>> + cport = rpmsg_tty_alloc_cport();
>> + if (IS_ERR(cport)) {
>> + dev_err(dev, "failed to alloc tty port\n");
>> + return PTR_ERR(cport);
>> + }
>> +
>> + tty_port_init(&cport->port);
>> + cport->port.low_latency = cport->port.flags | ASYNC_LOW_LATENCY;
>
> "|"? Not "&"? You should prepend "!!" in any way as low latency is 13th bit.
After crosscheck this line is wrong and should not be fixed in probe.
Should be in activate ops (as done in uart_port_activate)

>
>> + cport->port.ops = &rpmsg_tty_port_ops;
>> +
>> + tty_dev = tty_port_register_device(&cport->port, rpmsg_tty_driver,
>> + cport->id, dev);
>> + if (IS_ERR(tty_dev)) {
>> + dev_err(dev, "failed to register tty port\n");
>> + ret = PTR_ERR(tty_dev);
>> + goto err_destroy;
>> + }
> ...
> regards,
>
--
Thanks for your reviewing
i will send a V4 soon to fix.

Regards,
Arnaud

\
 
 \ /
  Last update: 2019-05-22 18:16    [W:0.071 / U:5.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site