lkml.org 
[lkml]   [2005]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.13-rc3-git9] pl2303: pl2303_update_line_status data length fix
On Mon, 08 Aug 2005, Greg KH wrote:
> On Thu, Jul 28, 2005 at 03:32:20PM +0200, Horst Schirmeier wrote:
> > Minimum data length must be UART_STATE + 1, as data[UART_STATE] is being
> > accessed for the new line_state. Although PL-2303 hardware is not
> > expected to send data with exactly UART_STATE length, this keeps it on
> > the safe side.
> >
> > Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
> > ---
> >
> > --- linux-2.6.13-rc3-git9/drivers/usb/serial/pl2303.c.orig 2005-07-28 14:42:58.000000000 +0200
> > +++ linux-2.6.13-rc3-git9/drivers/usb/serial/pl2303.c 2005-07-28 14:43:16.000000000 +0200
> > @@ -826,7 +826,7 @@ static void pl2303_update_line_status(st
> > struct pl2303_private *priv = usb_get_serial_port_data(port);
> > unsigned long flags;
> > u8 status_idx = UART_STATE;
> > - u8 length = UART_STATE;
> > + u8 length = UART_STATE + 1;
>
> "safe side" yes, but this will just prevent any line changes from going
> back to the user, right?

IMHO not, no. The PL-2303 interrupt IN endpoint has a 10 bytes FIFO and
(as far as I've observed from the type_1 model) always sends packets
with exactly this size. The UART_STATE is located at offset 0x08,
therefore the minimum packet length we need is 0x09 (UART_STATE + 1).

Here are the two different byte sequences from that endpoint I picked
up; the first with a terminal on the serial end, the second without one
(both times using the patched pl2303 module with debug=1):

a1 20 00 00 00 00 02 00 00 00
a1 20 00 00 00 00 02 00 82 00

Note the UART_STATE byte with the DSR and CTS bits set in the second
case.

> Hm, how is this working at all, it looks like we overflow the buffer...

In the unlikely case that some weird hardware sends a packet with
exactly UART_STATE (8) bytes length, yes, we do. Normal PL-2303 hardware
_should_ cause no trouble, as it always sends 10 bytes (at least my
hardware does), therefore my side note "this keeps it on the safe side".

> Have you tested this change?

Yes, I have.

> thanks,
>
> greg k-h

Kind regards,
Horst

--
PGP-Key 0xD40E0E7A
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-08-09 01:23    [W:0.044 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site