diff options
author | Bryan O'Donoghue <bodonoghue@codehermit.ie> | 2007-01-27 12:16:32 +0000 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2007-02-16 15:32:20 -0800 |
commit | 8356f3113d2628c98a58180ca183345474a9d011 (patch) | |
tree | 9f57060b56addf17c4f8eb51932552fb7782723d | |
parent | fc8d91912694859d3e598839af2427ec1287741c (diff) | |
download | blackbird-op-linux-8356f3113d2628c98a58180ca183345474a9d011.tar.gz blackbird-op-linux-8356f3113d2628c98a58180ca183345474a9d011.zip |
USB: fix g_serial small error
A SET_LINE_CODING control request should return a zero length packet
as an ACK to the host, during the status phase of a USB transaction.
The return value of gs_setup_class() is treated as the number of
bytes to write in the status phase of the control request, by
gs_setup(). For this case, the value returned by gs_setup_class should
be zero for SET_LINE_CODING but, right now, appears to be
sizeof(struct usb_cdc_line_coding).
However, if after doing the memcpy of the line coding descriptor we
set the variable "ret" to be zero, we should return the appropiate ZLP
to the host as an ACK in the status phase of the control request.
I've tested this out using Linux as both host and slave and confirmed
that the following small change fixes the spurious return of
sizeof(struct usb_cdc_line_coding)/wLength bytes in the status phase
of a USB_CDC_REQ_SET_LINE_CODING request. It's not a huge bug but, it
is worth fixing.
Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-rw-r--r-- | drivers/usb/gadget/serial.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c index e6c19aa4bef3..e552668d36b3 100644 --- a/drivers/usb/gadget/serial.c +++ b/drivers/usb/gadget/serial.c @@ -1699,6 +1699,7 @@ static int gs_setup_class(struct usb_gadget *gadget, memcpy(&port->port_line_coding, req->buf, ret); spin_unlock(&port->port_lock); } + ret = 0; break; case USB_CDC_REQ_GET_LINE_CODING: |