summaryrefslogtreecommitdiffstats
path: root/drivers/usb/serial/keyspan_usa49msg.h
diff options
context:
space:
mode:
authorFrank Schaefer2009-08-18 20:15:07 +0200
committerGreg Kroah-Hartman2009-09-23 15:46:36 +0200
commit25b8286805e856c8c7fda127018e31032c918015 (patch)
treee95665d787347049bc728d96c2c169f329e8a4db /drivers/usb/serial/keyspan_usa49msg.h
parentUSB: iuu_phoenix: add a way to select the default VCC (diff)
downloadkernel-qcow2-linux-25b8286805e856c8c7fda127018e31032c918015.tar.gz
kernel-qcow2-linux-25b8286805e856c8c7fda127018e31032c918015.tar.xz
kernel-qcow2-linux-25b8286805e856c8c7fda127018e31032c918015.zip
USB-serial: pl2303: fix baud rate handling in case of unsupported values
According to the datasheets, the PL2303 supports a set of 25 baudrates. The baudrate is set as a 4 byte value directly. During my experiments with device 067b:2303 (PL2303X), I noticed that - the bridge-controller always uses 9600 baud if invalid/unsupported baud rate values are set - the baud rate value returned by usb_control_msg(..., GET_LINE_REQUEST, ...) does not reflect the actually used baudrate. Always the last set value is returned, even if it was invalid and not used by the controller. This patch fixes the following issues with the current code: 1.) make sure that only supported baudrates are set (are there any buggy chip revisions out there which don't "like" other values... ?). 2.) always set the baudrate to the next nearest supported baudrate. 3.) applications can now read back the resulting baudrate properly, because tty_encode_baud_rate(...) is now fed with the actually used baudrate. Signed-off-by: Frank Schaefer <schaefer.frank@gmx.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/usb/serial/keyspan_usa49msg.h')
0 files changed, 0 insertions, 0 deletions