Allow f_acm gadgets to notify the user about SetLineCoding requests
Subsystems (3)
v2 cover 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
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().
--- drivers/tty/n_tty.c | 2 ++ include/linux/tty_driver.h | 3 +++ 2 files changed, 5 insertions(+)
drivers/tty/n_tty.c +2 -0
@@ -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; }
include/linux/tty_driver.h +3 -0
@@ -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);
Signature · 1 line
2.7.4
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
Quoted 7 lines · 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_codingevent, it needs a way to modify the mask returned bypoll()and possible also add wait queues. In order to do that, we allow the driver to supply apoll()callback of its own, which will be called inn_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
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
Quoted 17 lines · Alan Cox
Quoted 7 lines · 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_codingevent, it needs a way to modify the mask returned bypoll()and possible also add wait queues. In order to do that, we allow the driver to supply apoll()callback of its own, which will be called inn_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.
Quoted 3 lines
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?
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
Quoted 21 lines · Tal Shorer
Quoted 17 lines · Alan Cox
Quoted 7 lines · 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_codingevent, it needs a way to modify the mask returned bypoll()and possible also add wait queues. In order to do that, we allow the driver to supply apoll()callback of its own, which will be called inn_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.Quoted 3 lines
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.
Quoted 7 lines
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_statusbits), but for that I needn_ttyto know that packet does not always mean a linked tty is present, and that in case it isn't we take our ownctrl_statusbits instead of the link's. I could write a small (inline?) function to fetch the correctctrl_statusbits and put that inn_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?
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
In reply to Tal ShorerQuoted 7 lines
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_statusbits), but for that I needn_ttyto know that packet does not always mean a linked tty is present, and that in case it isn't we take our ownctrl_statusbits instead of the link's. I could write a small (inline?) function to fetch the correctctrl_statusbits and put that inn_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
Re: [PATCH v2 1/8] tty: add a poll() callback in struct tty_operations
Quoted 8 lines · Alan Cox
Quoted 7 lines
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_statusbits), but for that I needn_ttyto know that packet does not always mean a linked tty is present, and that in case it isn't we take our ownctrl_statusbits instead of the link's. I could write a small (inline?) function to fetch the correctctrl_statusbits and put that inn_tty. Does that make sense?
Quoted 5 lines
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?
PATCH v2 2/8 usb: gadget: u_serial: propagate poll() to the next layer
In reply to Tal ShorerIn 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.
--- drivers/usb/gadget/function/u_serial.c | 16 ++++++++++++++++ drivers/usb/gadget/function/u_serial.h | 3 +++ 2 files changed, 19 insertions(+)
drivers/usb/gadget/function/u_serial.c +16 -0
@@ -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, };/*-------------------------------------------------------------------------*/
drivers/usb/gadget/function/u_serial.h +3 -0
@@ -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 */
Signature · 1 line
2.7.4
PATCH v2 3/8 usb: gadget: f_acm: validate set_line_coding requests
In reply to Tal ShorerWe 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.
--- drivers/usb/gadget/function/f_acm.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-)
drivers/usb/gadget/function/f_acm.c +16 -7
@@ -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; } }
Signature · 1 line
2.7.4
PATCH v2 4/8 usb: gadget: u_serial: propagate ioctl() to the next layer
In reply to Tal ShorerIn 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.
--- drivers/usb/gadget/function/u_serial.c | 15 +++++++++++++++ drivers/usb/gadget/function/u_serial.h | 1 + 2 files changed, 16 insertions(+)
drivers/usb/gadget/function/u_serial.c +15 -0
@@ -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, };/*-------------------------------------------------------------------------*/
drivers/usb/gadget/function/u_serial.h +1 -0
@@ -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 */
Signature · 1 line
2.7.4
PATCH v2 5/8 usb: gadget: f_acm: initialize port_line_coding when creating an instance
In reply to Tal ShorerInitialize 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
--- drivers/usb/gadget/function/f_acm.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/usb/gadget/function/f_acm.c +6 -0
@@ -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; }
Signature · 1 line
2.7.4
PATCH v2 6/8 usb: gadget: f_acm: add an ioctl to get the current line coding
In reply to Tal ShorerThe 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).
--- 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
Documentation/ioctl/ioctl-number.txt +1 -0
@@ -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
drivers/usb/gadget/function/f_acm.c +19 -0
@@ -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;
include/uapi/linux/usb/f_acm.h new file +12 -0
@@ -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 */
Signature · 1 line
2.7.4
Greg KH
maintainerRe: [PATCH v2 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding
Quoted 8 lines · Tal Shorer
The user can issue
USB_F_GET_LINE_CODINGto 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
Re: [PATCH v2 6/8] usb: gadget: f_acm: add an ioctl to get the current line coding
Quoted 4 lines · Greg KH
Quoted 3 lines · Tal Shorer
The user can issue
USB_F_GET_LINE_CODINGto get the current line coding as set by the host (or the default if unset yet).
Quoted 8 lines
Quoted 5 lines
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.
Quoted 4 lines
confused at the different levels here, sorry.
greg k-h
PATCH v2 7/8 usb: gadget: f_acm: notify the user on SetLineCoding
In reply to Tal ShorerNotify 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()
--- drivers/usb/gadget/function/f_acm.c | 38 ++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-)
drivers/usb/gadget/function/f_acm.c +27 -11
@@ -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;
Signature · 1 line
2.7.4
PATCH v2 8/8 usb: gadget: u_serial: remove port_line_config from struct gserial
In reply to Tal ShorerGetLineCoding 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.
--- drivers/usb/gadget/function/u_serial.c | 22 ++-------------------- drivers/usb/gadget/function/u_serial.h | 3 --- 2 files changed, 2 insertions(+), 23 deletions(-)
drivers/usb/gadget/function/u_serial.c +2 -20
@@ -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) {
drivers/usb/gadget/function/u_serial.h +0 -3
@@ -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);
Signature · 1 line
2.7.4