diff options
author | Frank Schaefer <schaefer.frank@gmx.net> | 2009-08-18 20:15:07 +0200 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2009-09-23 06:46:36 -0700 |
commit | 25b8286805e856c8c7fda127018e31032c918015 (patch) | |
tree | e95665d787347049bc728d96c2c169f329e8a4db /drivers/usb/image | |
parent | e55c6d06fead7e58b7c597fd9afc46a88ef740e6 (diff) | |
download | kernel_samsung_smdk4412-25b8286805e856c8c7fda127018e31032c918015.zip kernel_samsung_smdk4412-25b8286805e856c8c7fda127018e31032c918015.tar.gz kernel_samsung_smdk4412-25b8286805e856c8c7fda127018e31032c918015.tar.bz2 |
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/image')
0 files changed, 0 insertions, 0 deletions