This reverts commit b5c16c6a.

Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip.  This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips"

This reverts commit 61fa8d69.

Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip.  This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit c23bda36.

Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip.  This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 73b583af.

Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip.  This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit a77a8c23.

Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip.  This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 034d1527.

Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip.  This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 7d26a78f.

Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip.  This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to Prolific, several (unauthorized) cheap and less functional
clones of the PL2303HX chip are in circulation. [1]
I've had the chance to test such a cloned device and it turned out that
it doesn't support any baud rates above 115200 baud (original: 6 Mbaud)
It also doesn't support the divisior based baud rate encoding method,
so no continuous baud rate adjustment is possible.
Nevertheless, these devices have been working (unintentionally) with
the driver up to commit 61fa8d69 ("pl2303: also use the divisor based
baud rate encoding method for baud rates < 115200 with HX chips"), and
this commit broke support for them.
Fortunately, it is pretty simple to distinguish between the original
and the cloned HX chips, so I've added a check and an extra chip type
to keep the clones working.
The same check is used by the latest Prolific Windows driver, so it
should be solid.

[1] http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225&pcid=41Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver currently knows about 3 different PL2303 chip types:
The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX
type.
The device distinction is currently completely based on the examination
of the USB descriptors.
During the last years, Prolific has introduced further PL2303 chips,
such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA,
RA, EA and TB variants.
Unfortunately, all these new chips are currently detected as HX chips,
because they are all using the same bMaxPacketSize0 = 0x40 value in the
USB device descriptor.

At this point it is not clear if these chips are really working with
the driver, there are just some positive indicators (like device
manufacturers claiming Linux support for these devices or commit
8d48fdf6 "correctly handle baudrates above 115200" which should only
be necessary for newer devices, ...)

For a complete support of all devices, we need to distinguish between
them, because they differ in several functional aspects, such  as the
maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps,
RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and
GPIO ports support (currently not supported by the driver).
And there might be further differences that we don't know yet.

This patch improves the chip type detection by evaluating the bcdDevice
value of the device descriptor. The values are taken from the
datasheets and are safe to use because manufacturers can't change them:

3.00: X/HX, TA
4.00: HXD, EA, RA, SA
5.00: TB

The rest of the device descriptors is completely identical, so no
further distinction is possible this way.
Anyway, Prolifics "checkChipVersion.exe"-tool is definitely able to
distinguish for example between the X/HX and the TA chips, so there
must be a possibility to improve the distinction further...
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no need for two else-if constructs for the type_1 chip
detection in pl2303_startup(), so merge them.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I've found some new datasheets which describe some additionally
supported standard baud rates and I've verified them with my HX
(rev. 3A) device. But adding support for individual (chip type
specific) baud rates would add a good amount of extra code (especially
when support for further chips will be added to the driver one day),
which makes no sense as long as we are not using the direct baud rate
encoding method for newer chips.
So for now, just drop a comment about these additionally supported baud
rates.

The second comment is about the baud rate differences between the two
encoding methods. In theory, we could optimize the code a bit by
comparing the resulting baud rates of both methods and selecting the
one which is closer to the requested baud rate. But that seems to be a
bit overkill, because the differences are very small and the device
likely uses the same baud rate generator for both methods so that the
resulting baud rate would be the same.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips

Now that the divisor based baud rate encoding method has been fixed and
extended, it can also be used for baud rates < 115200 baud with HX
chips.
This makes it possible to adjust the baud rate almost continuously
instead of just beeing able to select between 16 fixed standard values.

Tested with a PL2303HX 04463A (week 46, 2004, rev 3A).
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reinhard Max has done some tests with a PL2303HX (rev A) and a logic
analyzer and it seems, that although the PL2303HX is specified for baud
rates from 75 to 6M baud, the full divisor range can be used with the
divisor based baud rate encoding method. This corresponds to baud rates
from 46 to 24M baud.
Baud rates down to 46 baud (max. divisor) have been confirmed to work
even under heavy/permanent load, so remove the lower limit.
Baud rates up to 24M baud should really be tested carefully in "real
life" scenarios before removing the upper limit completely.
Anyway, the Windows driver allows maximum baud rates of 110% of the
specified limit, so for now, increase the upper limit to this value.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NReinhard Max <max@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 0c967e7e "USB: serial: pl2303 works at 500kbps" added 500000
baud to the list of supported standard baud rates.
But the reason why the driver works with this baud rate is, that since
commit 8d48fdf6 "USB: PL2303: correctly handle baudrates above 115200"
a second (divisor based) baud rate encoding method is used for values
above 115200 baud, which is not limited to a fixed set of standard baud
rates.

Remove the 500000 baud value from the list of standard baud rates
again, because this list is only used with the direct baud rate
encoding method and 500000 baud is not supported with this method.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method

In opposition to the direct baud rate encoding method, the divisor
based method is not limited to a fixed set of standard baud rates.
Hence, there is no need to round to the next nearest standard value.
Reported-by: NMastro Gippo <gipmad@gmail.com>
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NReinhard Max <max@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Based on the formula in the code description, Reinhard Max and me have
investigated the devices behavior / functional principle of the divisor
based baud rate encoding method.

It turned out, that (although beeing a good starting point) the current
code has some flaws. It doesn't work correctly for a wide range of baud
rates and the divisor resolution can be improved. It also doesn't
report the actually set baud rate.

This patch fixes and improves the code for the divisor based baud rate
encoding method a lot. It can now be used for the whole range of baud
rates from 46 baud to 24M baud with a very good divisor resolution and
userspace can read back the resulting baud rate.

It also documents the formula used for encoding and the hardware
behavior (including special cases).

The basic algorithm, rounding and several code comments/explanations
are provided by Reinhard Max.
I've added some minor fixes, the handling of the special cases and
further code/algorithm descriptions.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NReinhard Max <max@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It's not clear if the type_0 and type_1 chips support the divisor based baud
rate encoding method, so don't use it until anyone with such chip has tested it
to avoid regressions with the following patches.

Even if it has been working fine with these chips since the code has been added
2 years ago, this change will not cause any regressions, because the baud rates
currently supported/allowed with the divisor based method are supported with
the direct method, too.

The code for the divisor based method also isn't entirely correct (yet), so that the
direct encoding method actually works better (sets the baud rate more precisely).
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes the following regression that has been introduced recently with
commit b2d6d98f:
With type_0 and type_1 chips
- all baud rates < 1228800 baud are rounded up to 1228800 baud
- the device silently runs at 9600 baud for all baud rates > 1228800
  baud
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Only log the tty_flags in process_read_urb on errors.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Clean up set_termios somewhat.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Clean up baud-rate handling somewhat.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Break out baud-rate handling from set_termios.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The port drain delay is constant and should be set at port probe rather
than open.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This moves the allocation of minor device numbers from a static array to
be dynamic, using the idr interface.  This means that you could
potentially get "gaps" in a minor number range for a single USB serial
device with multiple ports, but all should still work properly.

We remove the 'minor' field from the usb_serial structure, as it no
longer makes any sense for it (use the field in the usb_serial_port
structure if you really want to know this number), and take the fact
that we were overloading a number in this field to determine if we had
initialized the minor numbers or not, and just use a flag variable
instead.

Note, we still have the limitation of 255 USB to serial devices in the
system, as that is all we are registering with the TTY layer at this
point in time.
Tested-by: NTobias Winter <tobias@linuxdingsda.de>
Reviewed-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_serial_port structure had the number field, which was the minor
number for the port, which almost no one really cared about.  They
really wanted the number of the port within the device, which you had to
subtract from the minor of the parent usb_serial_device structure.  To
clean this up, provide the real minor number of the port, and the number
of the port within the serial device separately, as these numbers might
not be related in the future.

Bonus is that this cleans up a lot of logic in the drivers, and saves
lines overall.
Tested-by: NTobias Winter <tobias@linuxdingsda.de>
Reviewed-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

--
 drivers/staging/serqt_usb2/serqt_usb2.c |   21 +++--------
 drivers/usb/serial/ark3116.c            |    2 -
 drivers/usb/serial/bus.c                |    6 +--
 drivers/usb/serial/console.c            |    2 -
 drivers/usb/serial/cp210x.c             |    2 -
 drivers/usb/serial/cypress_m8.c         |    4 +-
 drivers/usb/serial/digi_acceleport.c    |    6 ---
 drivers/usb/serial/f81232.c             |    5 +-
 drivers/usb/serial/garmin_gps.c         |    6 +--
 drivers/usb/serial/io_edgeport.c        |   58 ++++++++++++--------------------
 drivers/usb/serial/io_ti.c              |   21 ++++-------
 drivers/usb/serial/keyspan.c            |   29 +++++++---------
 drivers/usb/serial/metro-usb.c          |    4 +-
 drivers/usb/serial/mos7720.c            |   37 +++++++++-----------
 drivers/usb/serial/mos7840.c            |   52 +++++++++-------------------
 drivers/usb/serial/opticon.c            |    2 -
 drivers/usb/serial/pl2303.c             |    2 -
 drivers/usb/serial/quatech2.c           |    7 +--
 drivers/usb/serial/sierra.c             |    2 -
 drivers/usb/serial/ti_usb_3410_5052.c   |   10 ++---
 drivers/usb/serial/usb-serial.c         |    7 ++-
 drivers/usb/serial/usb_wwan.c           |    2 -
 drivers/usb/serial/whiteheat.c          |   20 +++++------
 include/linux/usb/serial.h              |    6 ++-
 24 files changed, 133 insertions(+), 180 deletions(-)

Do not use uninitialised termios data to determine when to configure the
device at open.

This also prevents stack data from leaking to userspace in the OOM error
path.

Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

My PL2303HX works at 500kbps after applying this patch.
I suppose that it could work at other non standard speeds since this fix

"correctly handle baudrates above 115200"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/serial/pl2303.c?id=8d48fdf689fed2c73c493e5146d1463689246442

came after this one

"fix baud rate handling in case of unsupported values"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/serial/pl2303.c?id=25b8286805e856c8c7fda127018e31032c918015

but I only can test it with 500000.
Patch made against mainline but tested with 3.4.45
Signed-off-by: NLuca Olivetti <luca@ventoso.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a specifier we may use to dump small buffers.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove unnecessary disconnect test in tiocmset. No ioctls will be made
after disconnect returns.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure we return 0 or a negative error number appropriate for
userspace on errors.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use tty-port modem-status-change wait queue on which processes are woken
up at hangup and disconnect.

Currently a process waiting on modem-status changes will not be woken on
device disconnect.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Break out TIOCMIWAIT handling from custom ioctl operation and use
tiocmiwait operation field instead.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Pass usb-serial port rather than usb device to set_control_lines, and
make sure port device is used for all port related debugging.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use interface rather than usb-serial device for debugging interface
related operations. This gives more descriptive messages, such as

[  905.669436] pl2303 1-4.1:1.0: 0x40:0x1:0x8:0x0  0

rather than

[  341.943535] usb 1-4.1: 0x40:0x1:0x8:0x0  0
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.

This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

Now, the one where most of tty_port_tty_get gets removed:
tty_flip_buffer_push.

IOW we also closed all the races in drivers not using tty_port_tty_get
at all yet.

Also we move tty_flip_buffer_push declaration from include/linux/tty.h
to include/linux/tty_flip.h to all others while we are changing it
anyway.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

tty_insert_flip_char is the next one to proceed. This one is used all
over the code, so the patch is huge.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty pointer in
many call sites. Only tty_port will be needed and hence no more
tty_port_tty_get calls in those paths.

Now 4 string flipping ones are on turn:
* tty_insert_flip_string_flags
* tty_insert_flip_string_fixed_flag
* tty_prepare_flip_string
* tty_prepare_flip_string_flags
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>