2017-06-13 06:52:29

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 0/8] Allow f_acm gadgets to notify the user about SetLineCoding requests

I'm currently working on a project where I'd like to have an omap board
running linux be a usb-to-uart converter (using f_acm), and I've ran
into an issue: there's no way for the application to know if the host
has issued a SetLineCoding requests (after which parity/baudrate should
be changed to match the host's request).

This series adds the support necessary to achieve that:
- Allowing tty drivers to supply a poll() function to notify the user of
driver-specific events.
- Propagating poll() and ioctl() from u_serial to the next layer (f_acm)
in this case.
- Let the user read the current line coding set by the host (via an
ioctl() call).
- Notify the user when there's a pending SetLineCoding request they
haven't read yet

The last patch also removes up the port_line_config field from
struct gserial. It made no sense to have there (and had a REVISIT
comment at every turn), it was never used and it was initialized with
invalid values.

Changes from v1:
- patch 5 was messed up, which made patch 6 also messed up. fixed both
of these.

Tal Shorer (8):
tty: add a poll() callback in struct tty_operations
usb: gadget: u_serial: propagate poll() to the next layer
usb: gadget: f_acm: validate set_line_coding requests
usb: gadget: u_serial: propagate ioctl() to the next layer
usb: gadget: f_acm: initialize port_line_coding when creating an
instance
usb: gadget: f_acm: add an ioctl to get the current line coding
usb: gadget: f_acm: notify the user on SetLineCoding
usb: gadget: u_serial: remove port_line_config from struct gserial

Documentation/ioctl/ioctl-number.txt | 1 +
drivers/tty/n_tty.c | 2 ++
drivers/usb/gadget/function/f_acm.c | 66 +++++++++++++++++++++++++++++-----
drivers/usb/gadget/function/u_serial.c | 53 ++++++++++++++++-----------
drivers/usb/gadget/function/u_serial.h | 7 ++--
include/linux/tty_driver.h | 3 ++
include/uapi/linux/usb/f_acm.h | 12 +++++++
7 files changed, 113 insertions(+), 31 deletions(-)
create mode 100644 include/uapi/linux/usb/f_acm.h

--
2.7.4


2017-06-13 06:52:40

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

If a tty driver wants to notify the user of some exceptional event,
such as a usb cdc acm device set_line_coding event, it needs a way to
modify the mask returned by poll() and possible also add wait queues.
In order to do that, we allow the driver to supply a poll() callback
of its own, which will be called in n_tty_poll().

Signed-off-by: Tal Shorer <[email protected]>
---
drivers/tty/n_tty.c | 2 ++
include/linux/tty_driver.h | 3 +++
2 files changed, 5 insertions(+)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index bdf0e6e..7af8c29 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2394,6 +2394,8 @@ static unsigned int n_tty_poll(struct tty_struct *tty, struct file *file,
tty_chars_in_buffer(tty) < WAKEUP_CHARS &&
tty_write_room(tty) > 0)
mask |= POLLOUT | POLLWRNORM;
+ if (tty->ops->poll)
+ mask |= tty->ops->poll(tty, file, wait);
return mask;
}

diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index b742b5e..630ef03 100644
--- a/include/linux/tty_driver.h
+++ b/include/linux/tty_driver.h
@@ -243,6 +243,7 @@
#include <linux/list.h>
#include <linux/cdev.h>
#include <linux/termios.h>
+#include <linux/poll.h>

struct tty_struct;
struct tty_driver;
@@ -285,6 +286,8 @@ struct tty_operations {
int (*set_termiox)(struct tty_struct *tty, struct termiox *tnew);
int (*get_icount)(struct tty_struct *tty,
struct serial_icounter_struct *icount);
+ unsigned int (*poll)(struct tty_struct *tty, struct file *file,
+ poll_table *wait);
#ifdef CONFIG_CONSOLE_POLL
int (*poll_init)(struct tty_driver *driver, int line, char *options);
int (*poll_get_char)(struct tty_driver *driver, int line);
--
2.7.4

2017-06-13 06:52:47

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 3/8] usb: gadget: f_acm: validate set_line_coding requests

We shouldn't accept malformed set_line_coding requests.
All values were taken from table 17 (section 6.3.11) of the cdc1.2 spec
available at http://www.usb.org/developers/docs/devclass_docs/
The table is in the file PTSN120.pdf.

Signed-off-by: Tal Shorer <[email protected]>
---
drivers/usb/gadget/function/f_acm.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/function/f_acm.c b/drivers/usb/gadget/function/f_acm.c
index 5e3828d..e023313 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -326,13 +326,22 @@ static void acm_complete_set_line_coding(struct usb_ep *ep,
struct usb_cdc_line_coding *value = req->buf;

/* REVISIT: we currently just remember this data.
- * If we change that, (a) validate it first, then
- * (b) update whatever hardware needs updating,
- * (c) worry about locking. This is information on
- * the order of 9600-8-N-1 ... most of which means
- * nothing unless we control a real RS232 line.
- */
- acm->port_line_coding = *value;
+ * If we change that,
+ * (a) update whatever hardware needs updating,
+ * (b) worry about locking. This is information on
+ * the order of 9600-8-N-1 ... most of which means
+ * nothing unless we control a real RS232 line.
+ */
+ dev_dbg(&cdev->gadget->dev,
+ "acm ttyGS%d set_line_coding: %d %d %d %d\n",
+ acm->port_num, le32_to_cpu(value->dwDTERate),
+ value->bCharFormat, value->bParityType,
+ value->bDataBits);
+ if (value->bCharFormat > 2 || value->bParityType > 4 ||
+ value->bDataBits < 5 || value->bDataBits > 8)
+ usb_ep_set_halt(ep);
+ else
+ acm->port_line_coding = *value;
}
}

--
2.7.4

2017-06-13 06:52:42

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 2/8] usb: gadget: u_serial: propagate poll() to the next layer

In order for a serial function to add flags to the poll() mask of their
tty files, propagate the poll() callback to the next layer so it can
return a mask if it sees fit to do so.

Signed-off-by: Tal Shorer <[email protected]>
---
drivers/usb/gadget/function/u_serial.c | 16 ++++++++++++++++
drivers/usb/gadget/function/u_serial.h | 3 +++
2 files changed, 19 insertions(+)

diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
index 9b0805f..d466f58 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1025,6 +1025,21 @@ static int gs_break_ctl(struct tty_struct *tty, int duration)
return status;
}

+static unsigned int gs_poll(struct tty_struct *tty, struct file *file,
+ poll_table *wait)
+{
+ struct gs_port *port = tty->driver_data;
+ struct gserial *gser;
+ unsigned int mask = 0;
+
+ spin_lock_irq(&port->port_lock);
+ gser = port->port_usb;
+ if (gser && gser->poll)
+ mask |= gser->poll(gser, file, wait);
+ spin_unlock_irq(&port->port_lock);
+ return mask;
+}
+
static const struct tty_operations gs_tty_ops = {
.open = gs_open,
.close = gs_close,
@@ -1035,6 +1050,7 @@ static const struct tty_operations gs_tty_ops = {
.chars_in_buffer = gs_chars_in_buffer,
.unthrottle = gs_unthrottle,
.break_ctl = gs_break_ctl,
+ .poll = gs_poll,
};

/*-------------------------------------------------------------------------*/
diff --git a/drivers/usb/gadget/function/u_serial.h b/drivers/usb/gadget/function/u_serial.h
index c20210c..ce00840 100644
--- a/drivers/usb/gadget/function/u_serial.h
+++ b/drivers/usb/gadget/function/u_serial.h
@@ -12,6 +12,7 @@
#ifndef __U_SERIAL_H
#define __U_SERIAL_H

+#include <linux/poll.h>
#include <linux/usb/composite.h>
#include <linux/usb/cdc.h>

@@ -50,6 +51,8 @@ struct gserial {
void (*connect)(struct gserial *p);
void (*disconnect)(struct gserial *p);
int (*send_break)(struct gserial *p, int duration);
+ unsigned int (*poll)(struct gserial *p, struct file *file,
+ poll_table *wait);
};

/* utilities to allocate/free request and buffer */
--
2.7.4

2017-06-13 06:52:55

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 5/8] usb: gadget: f_acm: initialize port_line_coding when creating an instance

Initialize acm->port_line_coding with something that makes sense so
that we can return a valid line coding if the host requests
GetLineCoding before requesting SetLineCoding

Signed-off-by: Tal Shorer <[email protected]>
---
drivers/usb/gadget/function/f_acm.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/usb/gadget/function/f_acm.c b/drivers/usb/gadget/function/f_acm.c
index e023313..188d314 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -763,6 +763,12 @@ static struct usb_function *acm_alloc_func(struct usb_function_instance *fi)
acm->port.func.unbind = acm_unbind;
acm->port.func.free_func = acm_free_func;

+ /* initialize port_line_coding with something that makes sense */
+ acm->port_line_coding.dwDTERate = cpu_to_le32(9600);
+ acm->port_line_coding.bCharFormat = USB_CDC_1_STOP_BITS;
+ acm->port_line_coding.bParityType = USB_CDC_NO_PARITY;
+ acm->port_line_coding.bDataBits = 8;
+
return &acm->port.func;
}

--
2.7.4

2017-06-13 06:53:10

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 7/8] usb: gadget: f_acm: notify the user on SetLineCoding

Notify the user with a POLLPRI event when the host issues a
SetLineCoding request so that they can act upon it, for example by
configuring the line coding on a real serial port.

The event is cleared when the user reads the line coding using
USB_F_ACM_GET_LINE_CODING ioctl()

Signed-off-by: Tal Shorer <[email protected]>
---
drivers/usb/gadget/function/f_acm.c | 38 ++++++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_acm.c b/drivers/usb/gadget/function/f_acm.c
index 5feea7c..0983999 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -58,6 +58,9 @@ struct f_acm {
struct usb_request *notify_req;

struct usb_cdc_line_coding port_line_coding; /* 8-N-1 etc */
+ /* we have a SetLineCoding request that the user haven't read yet */
+ bool set_line_coding_pending;
+ wait_queue_head_t set_line_coding_waitq;

/* SetControlLineState request -- CDC 1.1 section 6.2.14 (INPUT) */
u16 port_handshake_bits;
@@ -326,23 +329,19 @@ static void acm_complete_set_line_coding(struct usb_ep *ep,
} else {
struct usb_cdc_line_coding *value = req->buf;

- /* REVISIT: we currently just remember this data.
- * If we change that,
- * (a) update whatever hardware needs updating,
- * (b) worry about locking. This is information on
- * the order of 9600-8-N-1 ... most of which means
- * nothing unless we control a real RS232 line.
- */
dev_dbg(&cdev->gadget->dev,
"acm ttyGS%d set_line_coding: %d %d %d %d\n",
acm->port_num, le32_to_cpu(value->dwDTERate),
value->bCharFormat, value->bParityType,
value->bDataBits);
if (value->bCharFormat > 2 || value->bParityType > 4 ||
- value->bDataBits < 5 || value->bDataBits > 8)
+ value->bDataBits < 5 || value->bDataBits > 8) {
usb_ep_set_halt(ep);
- else
+ } else {
acm->port_line_coding = *value;
+ acm->set_line_coding_pending = true;
+ wake_up_interruptible(&acm->set_line_coding_waitq);
+ }
}
}

@@ -598,6 +597,19 @@ static void acm_disconnect(struct gserial *port)
acm_notify_serial_state(acm);
}

+static unsigned int acm_poll(struct gserial *port, struct file *file,
+ poll_table *wait)
+{
+ unsigned int mask = 0;
+ struct f_acm *acm = port_to_acm(port);
+
+ poll_wait(file, &acm->set_line_coding_waitq, wait);
+ if (acm->set_line_coding_pending)
+ mask |= POLLPRI;
+ return mask;
+}
+
+
static int acm_send_break(struct gserial *port, int duration)
{
struct f_acm *acm = port_to_acm(port);
@@ -620,10 +632,12 @@ static int acm_ioctl(struct gserial *port, unsigned int cmd, unsigned long arg)
switch (cmd) {
case USB_F_ACM_GET_LINE_CODING:
if (copy_to_user((__user void *)arg, &acm->port_line_coding,
- sizeof(acm->port_line_coding)))
+ sizeof(acm->port_line_coding))) {
ret = -EFAULT;
- else
+ } else {
ret = 0;
+ acm->set_line_coding_pending = false;
+ }
break;
}
return ret;
@@ -763,11 +777,13 @@ static struct usb_function *acm_alloc_func(struct usb_function_instance *fi)
return ERR_PTR(-ENOMEM);

spin_lock_init(&acm->lock);
+ init_waitqueue_head(&acm->set_line_coding_waitq);

acm->port.connect = acm_connect;
acm->port.disconnect = acm_disconnect;
acm->port.send_break = acm_send_break;
acm->port.ioctl = acm_ioctl;
+ acm->port.poll = acm_poll;

acm->port.func.name = "acm";
acm->port.func.strings = acm_strings;
--
2.7.4

2017-06-13 06:52:59

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 4/8] usb: gadget: u_serial: propagate ioctl() to the next layer

In order for a serial function to implement its own ioctl() calls,
propagate the ioctl() callback to the next layer so it can handle it if
it sees fit to do so.

Signed-off-by: Tal Shorer <[email protected]>
---
drivers/usb/gadget/function/u_serial.c | 15 +++++++++++++++
drivers/usb/gadget/function/u_serial.h | 1 +
2 files changed, 16 insertions(+)

diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
index d466f58..8d9abf1 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1040,6 +1040,20 @@ static unsigned int gs_poll(struct tty_struct *tty, struct file *file,
return mask;
}

+static int gs_ioctl(struct tty_struct *tty, unsigned int cmd, unsigned long arg)
+{
+ struct gs_port *port = tty->driver_data;
+ struct gserial *gser;
+ int ret = -ENOIOCTLCMD;
+
+ spin_lock_irq(&port->port_lock);
+ gser = port->port_usb;
+ if (gser && gser->ioctl)
+ ret = gser->ioctl(gser, cmd, arg);
+ spin_unlock_irq(&port->port_lock);
+ return ret;
+}
+
static const struct tty_operations gs_tty_ops = {
.open = gs_open,
.close = gs_close,
@@ -1051,6 +1065,7 @@ static const struct tty_operations gs_tty_ops = {
.unthrottle = gs_unthrottle,
.break_ctl = gs_break_ctl,
.poll = gs_poll,
+ .ioctl = gs_ioctl,
};

/*-------------------------------------------------------------------------*/
diff --git a/drivers/usb/gadget/function/u_serial.h b/drivers/usb/gadget/function/u_serial.h
index ce00840..8d0901e 100644
--- a/drivers/usb/gadget/function/u_serial.h
+++ b/drivers/usb/gadget/function/u_serial.h
@@ -53,6 +53,7 @@ struct gserial {
int (*send_break)(struct gserial *p, int duration);
unsigned int (*poll)(struct gserial *p, struct file *file,
poll_table *wait);
+ int (*ioctl)(struct gserial *p, unsigned int cmd, unsigned long arg);
};

/* utilities to allocate/free request and buffer */
--
2.7.4

2017-06-13 06:52:53

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

The user can issue USB_F_GET_LINE_CODING to get the current line coding
as set by the host (or the default if unset yet).

Signed-off-by: Tal Shorer <[email protected]>
---
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/usb/gadget/function/f_acm.c | 19 +++++++++++++++++++
include/uapi/linux/usb/f_acm.h | 12 ++++++++++++
3 files changed, 32 insertions(+)
create mode 100644 include/uapi/linux/usb/f_acm.h

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 1e9fcb4..3d70680 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -329,6 +329,7 @@ Code Seq#(hex) Include File Comments
0xCA 80-8F uapi/scsi/cxlflash_ioctl.h
0xCB 00-1F CBM serial IEC bus in development:
<mailto:[email protected]>
+0xCD 10-1F linux/usb/f_acm.h
0xCD 01 linux/reiserfs_fs.h
0xCF 02 fs/cifs/ioctl.c
0xDB 00-0F drivers/char/mwave/mwavepub.h
diff --git a/drivers/usb/gadget/function/f_acm.c b/drivers/usb/gadget/function/f_acm.c
index 188d314..5feea7c 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/device.h>
#include <linux/err.h>
+#include <uapi/linux/usb/f_acm.h>

#include "u_serial.h"

@@ -611,6 +612,23 @@ static int acm_send_break(struct gserial *port, int duration)
return acm_notify_serial_state(acm);
}

+static int acm_ioctl(struct gserial *port, unsigned int cmd, unsigned long arg)
+{
+ struct f_acm *acm = port_to_acm(port);
+ int ret = -ENOIOCTLCMD;
+
+ switch (cmd) {
+ case USB_F_ACM_GET_LINE_CODING:
+ if (copy_to_user((__user void *)arg, &acm->port_line_coding,
+ sizeof(acm->port_line_coding)))
+ ret = -EFAULT;
+ else
+ ret = 0;
+ break;
+ }
+ return ret;
+}
+
/*-------------------------------------------------------------------------*/

/* ACM function driver setup/binding */
@@ -749,6 +767,7 @@ static struct usb_function *acm_alloc_func(struct usb_function_instance *fi)
acm->port.connect = acm_connect;
acm->port.disconnect = acm_disconnect;
acm->port.send_break = acm_send_break;
+ acm->port.ioctl = acm_ioctl;

acm->port.func.name = "acm";
acm->port.func.strings = acm_strings;
diff --git a/include/uapi/linux/usb/f_acm.h b/include/uapi/linux/usb/f_acm.h
new file mode 100644
index 0000000..51f96f0
--- /dev/null
+++ b/include/uapi/linux/usb/f_acm.h
@@ -0,0 +1,12 @@
+/* f_acm.h -- Header file for USB CDC-ACM gadget function */
+
+#ifndef __UAPI_LINUX_USB_F_ACM_H
+#define __UAPI_LINUX_USB_F_ACM_H
+
+#include <linux/usb/cdc.h>
+#include <linux/ioctl.h>
+
+/* The 0xCD code is also used by reiserfs. we use 0x10-0x1F range */
+#define USB_F_ACM_GET_LINE_CODING _IOR(0xCD, 0x10, struct usb_cdc_line_coding)
+
+#endif /* __UAPI_LINUX_USB_F_ACM_H */
--
2.7.4

2017-06-13 06:53:53

by Tal Shorer

[permalink] [raw]
Subject: [PATCH v2 8/8] usb: gadget: u_serial: remove port_line_config from struct gserial

GetLineCoding and SetLineCoding are a cdc-acm thing. It doesn't make
sense to have that in the generic u_serial layer. Moreso, f_acm has its
own port_line_coding in its own struct and it uses that, while the one
in struct gserial is set once upon initialization and then never used.
Also, the initialized never-used values were invalid, with bDataBits
and bCharFormat having each other's value.

Signed-off-by: Tal Shorer <[email protected]>
---
drivers/usb/gadget/function/u_serial.c | 22 ++--------------------
drivers/usb/gadget/function/u_serial.h | 3 ---
2 files changed, 2 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
index 8d9abf1..654d4a6 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -129,9 +129,6 @@ struct gs_port {
wait_queue_head_t drain_wait; /* wait while writes drain */
bool write_busy;
wait_queue_head_t close_wait;
-
- /* REVISIT this state ... */
- struct usb_cdc_line_coding port_line_coding; /* 8-N-1 etc */
};

static struct portmaster {
@@ -1314,7 +1311,7 @@ static void gserial_console_exit(void)
#endif

static int
-gs_port_alloc(unsigned port_num, struct usb_cdc_line_coding *coding)
+gs_port_alloc(unsigned port_num)
{
struct gs_port *port;
int ret = 0;
@@ -1343,7 +1340,6 @@ gs_port_alloc(unsigned port_num, struct usb_cdc_line_coding *coding)
INIT_LIST_HEAD(&port->write_pool);

port->port_num = port_num;
- port->port_line_coding = *coding;

ports[port_num].port = port;
out:
@@ -1392,18 +1388,12 @@ EXPORT_SYMBOL_GPL(gserial_free_line);

int gserial_alloc_line(unsigned char *line_num)
{
- struct usb_cdc_line_coding coding;
struct device *tty_dev;
int ret;
int port_num;

- coding.dwDTERate = cpu_to_le32(9600);
- coding.bCharFormat = 8;
- coding.bParityType = USB_CDC_NO_PARITY;
- coding.bDataBits = USB_CDC_1_STOP_BITS;
-
for (port_num = 0; port_num < MAX_U_SERIAL_PORTS; port_num++) {
- ret = gs_port_alloc(port_num, &coding);
+ ret = gs_port_alloc(port_num);
if (ret == -EBUSY)
continue;
if (ret)
@@ -1491,11 +1481,6 @@ int gserial_connect(struct gserial *gser, u8 port_num)
gser->ioport = port;
port->port_usb = gser;

- /* REVISIT unclear how best to handle this state...
- * we don't really couple it with the Linux TTY.
- */
- gser->port_line_coding = port->port_line_coding;
-
/* REVISIT if waiting on "carrier detect", signal. */

/* if it's already open, start I/O ... and notify the serial
@@ -1543,9 +1528,6 @@ void gserial_disconnect(struct gserial *gser)
/* tell the TTY glue not to do I/O here any more */
spin_lock_irqsave(&port->port_lock, flags);

- /* REVISIT as above: how best to track this? */
- port->port_line_coding = gser->port_line_coding;
-
port->port_usb = NULL;
gser->ioport = NULL;
if (port->port.count > 0 || port->openclose) {
diff --git a/drivers/usb/gadget/function/u_serial.h b/drivers/usb/gadget/function/u_serial.h
index 8d0901e..0549efe 100644
--- a/drivers/usb/gadget/function/u_serial.h
+++ b/drivers/usb/gadget/function/u_serial.h
@@ -44,9 +44,6 @@ struct gserial {
struct usb_ep *in;
struct usb_ep *out;

- /* REVISIT avoid this CDC-ACM support harder ... */
- struct usb_cdc_line_coding port_line_coding; /* 9600-8-N-1 etc */
-
/* notification callbacks */
void (*connect)(struct gserial *p);
void (*disconnect)(struct gserial *p);
--
2.7.4

2017-06-13 09:19:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v2 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

On Tue, Jun 13, 2017 at 09:52:12AM +0300, Tal Shorer wrote:
> The user can issue USB_F_GET_LINE_CODING to get the current line coding
> as set by the host (or the default if unset yet).
>
> Signed-off-by: Tal Shorer <[email protected]>
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> drivers/usb/gadget/function/f_acm.c | 19 +++++++++++++++++++
> include/uapi/linux/usb/f_acm.h | 12 ++++++++++++

Where is this ioctl being called? On the tty device? If so, which one?
The gadget driver's tty device node? Or somewhere else?

confused at the different levels here, sorry.

greg k-h

2017-06-13 09:24:57

by Tal Shorer

[permalink] [raw]
Subject: Re: [PATCH v2 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding

On Tue, Jun 13, 2017 at 12:19 PM, Greg KH <[email protected]> wrote:
> On Tue, Jun 13, 2017 at 09:52:12AM +0300, Tal Shorer wrote:
>> The user can issue USB_F_GET_LINE_CODING to get the current line coding
>> as set by the host (or the default if unset yet).
>>
>> Signed-off-by: Tal Shorer <[email protected]>
>> ---
>> Documentation/ioctl/ioctl-number.txt | 1 +
>> drivers/usb/gadget/function/f_acm.c | 19 +++++++++++++++++++
>> include/uapi/linux/usb/f_acm.h | 12 ++++++++++++
>
> Where is this ioctl being called? On the tty device? If so, which one?
> The gadget driver's tty device node? Or somewhere else?
On an acm ttyGS* fd, yes.
>
> confused at the different levels here, sorry.
>
> greg k-h

2017-06-14 01:15:17

by Alan Cox

[permalink] [raw]
Subject: Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

On Tue, 13 Jun 2017 09:52:07 +0300
Tal Shorer <[email protected]> wrote:

> If a tty driver wants to notify the user of some exceptional event,
> such as a usb cdc acm device set_line_coding event, it needs a way to
> modify the mask returned by poll() and possible also add wait queues.
> In order to do that, we allow the driver to supply a poll() callback
> of its own, which will be called in n_tty_poll().
>
> Signed-off-by: Tal Shorer <[email protected]>

You might be in any line discipline so you need to support that for each
ldisc that supports poll(). Also what do I do when I get an exception
event - what does it mean, how do I understand that, are you proposing a
standardized meaning ? Have you checked whether that conflicts with SuS
v3 or POSIX ? What will it do with existing code.

At the very least it probably has to be something you turn on, and you
might then want to model it on the pty/tty interface logic and extend
TIOCPKT a shade.

Alan

2017-06-14 08:20:54

by Tal Shorer

[permalink] [raw]
Subject: Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox <[email protected]> wrote:
> On Tue, 13 Jun 2017 09:52:07 +0300
> Tal Shorer <[email protected]> wrote:
>
>> If a tty driver wants to notify the user of some exceptional event,
>> such as a usb cdc acm device set_line_coding event, it needs a way to
>> modify the mask returned by poll() and possible also add wait queues.
>> In order to do that, we allow the driver to supply a poll() callback
>> of its own, which will be called in n_tty_poll().
>>
>> Signed-off-by: Tal Shorer <[email protected]>
>
> You might be in any line discipline so you need to support that for each
> ldisc that supports poll(). Also what do I do when I get an exception
> event - what does it mean, how do I understand that, are you proposing a
> standardized meaning ? Have you checked whether that conflicts with SuS
> v3 or POSIX ? What will it do with existing code.
>
> At the very least it probably has to be something you turn on, and you
> might then want to model it on the pty/tty interface logic and extend
> TIOCPKT a shade.
That would cut it, but TIOCPKT is too coupled with having a linked tty.
I could make acm behave like a pty (accept TIOCPKT and issue the
ctrl_status bits), but for that I need n_tty to know that packet does
not always mean a linked tty is present, and that in case it isn't we
take our own ctrl_status bits instead of the link's. I could write a
small (inline?) function to fetch the correct ctrl_status bits and put
that in n_tty. Does that make sense?

2017-06-14 08:27:31

by Tal Shorer

[permalink] [raw]
Subject: Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

On Wed, Jun 14, 2017 at 11:20 AM, Tal Shorer <[email protected]> wrote:
> On Wed, Jun 14, 2017 at 4:15 AM, Alan Cox <[email protected]> wrote:
>> On Tue, 13 Jun 2017 09:52:07 +0300
>> Tal Shorer <[email protected]> wrote:
>>
>>> If a tty driver wants to notify the user of some exceptional event,
>>> such as a usb cdc acm device set_line_coding event, it needs a way to
>>> modify the mask returned by poll() and possible also add wait queues.
>>> In order to do that, we allow the driver to supply a poll() callback
>>> of its own, which will be called in n_tty_poll().
>>>
>>> Signed-off-by: Tal Shorer <[email protected]>
>>
>> You might be in any line discipline so you need to support that for each
>> ldisc that supports poll(). Also what do I do when I get an exception
>> event - what does it mean, how do I understand that, are you proposing a
>> standardized meaning ? Have you checked whether that conflicts with SuS
>> v3 or POSIX ? What will it do with existing code.
>>
>> At the very least it probably has to be something you turn on, and you
>> might then want to model it on the pty/tty interface logic and extend
>> TIOCPKT a shade.
> That would cut it, but TIOCPKT is too coupled with having a linked tty.
> I could make acm behave like a pty (accept TIOCPKT and issue the
> ctrl_status bits), but for that I need n_tty to know that packet does
> not always mean a linked tty is present, and that in case it isn't we
> take our own ctrl_status bits instead of the link's. I could write a
> small (inline?) function to fetch the correct ctrl_status bits and put
> that in n_tty. Does that make sense?
Or (maybe) better yet, I can do a hack and have the acm tty point to
itself as the link, which means n_tty doesn't have to change at all.
Any thoughts?

2017-06-14 13:33:11

by Alan Cox

[permalink] [raw]
Subject: Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

> That would cut it, but TIOCPKT is too coupled with having a linked tty.
> I could make acm behave like a pty (accept TIOCPKT and issue the
> ctrl_status bits), but for that I need n_tty to know that packet does
> not always mean a linked tty is present, and that in case it isn't we
> take our own ctrl_status bits instead of the link's. I could write a
> small (inline?) function to fetch the correct ctrl_status bits and put
> that in n_tty. Does that make sense?

I think that makes sense, and I would do the job properly rather than do
a hack with tty->link. Those hacks in the long term never work out the
best approach.

Alan

2017-06-15 14:44:44

by Tal Shorer

[permalink] [raw]
Subject: Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations

On Wed, Jun 14, 2017 at 4:33 PM, Alan Cox <[email protected]> wrote:
>> That would cut it, but TIOCPKT is too coupled with having a linked tty.
>> I could make acm behave like a pty (accept TIOCPKT and issue the
>> ctrl_status bits), but for that I need n_tty to know that packet does
>> not always mean a linked tty is present, and that in case it isn't we
>> take our own ctrl_status bits instead of the link's. I could write a
>> small (inline?) function to fetch the correct ctrl_status bits and put
>> that in n_tty. Does that make sense?
>
> I think that makes sense, and I would do the job properly rather than do
> a hack with tty->link. Those hacks in the long term never work out the
> best approach.
>
> Alan
Ok, so I'm doing that and everything is great until I got to actually
modifying tty->termios.
I need to modify it from interrupt context (the usb_request's
complete() callback), but modifying the termios requires a
rw_semaphore I can't take.
I could queue_work() to do it, but then I'd have to flush the work
from another non-sleepable context in acm_disconnect() (which runs
under a spinlock).
I can't change the semaphore to a spinlock because some drivers that
use it actually wanna sleep while holding it.
Any ideas?