Re: [PATCH 2.6.13-rc3-git9] pl2303: pl2303_update_line_status data length fix

[Horst Schirmeier <horst@schirmeier.com>]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]