This project is mirrored from Pull mirroring updated .
  1. 01 Nov, 2013 10 commits
  2. 17 Sep, 2013 1 commit
    • Frank Schäfer's avatar
      USB: pl2303: distinguish between original and cloned HX chips · 7d26a78f
      Frank Schäfer authored
      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.
      Signed-off-by: default avatarFrank Schäfer <>
      Signed-off-by: default avatarGreg Kroah-Hartman <>
  3. 14 Aug, 2013 3 commits
    • Frank Schäfer's avatar
      pl2303: improve the chip type detection/distinction · 034d1527
      Frank Schäfer authored
      The driver currently knows about 3 different PL2303 chip types:
      The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX
      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
       "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: default avatarFrank Schäfer <>
      Signed-off-by: default avatarGreg Kroah-Hartman <>
    • Frank Schäfer's avatar
      pl2303: improve the chip type information output on startup · a77a8c23
      Frank Schäfer authored
      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: default avatarFrank Schäfer <>
      Signed-off-by: default avatarGreg Kroah-Hartman <>
    • Frank Schäfer's avatar
      pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup() · 73b583af
      Frank Schäfer authored
      There is no need for two else-if constructs for the type_1 chip
      detection in pl2303_startup(), so merge them.
      Signed-off-by: default avatarFrank Schäfer <>
      Signed-off-by: default avatarGreg Kroah-Hartman <>
  4. 12 Aug, 2013 7 commits
  5. 01 Aug, 2013 1 commit
  6. 29 Jul, 2013 1 commit
  7. 23 Jul, 2013 5 commits
  8. 17 Jun, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      USB: serial: make minor allocation dynamic · e5b1e206
      Greg Kroah-Hartman authored
      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
      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: default avatarTobias Winter <>
      Reviewed-by: default avatarJohan Hovold <>
      Signed-off-by: default avatarGreg Kroah-Hartman <>
  9. 10 Jun, 2013 2 commits
    • Greg Kroah-Hartman's avatar
      USB: serial: ports: add minor and port number · 1143832e
      Greg Kroah-Hartman authored
      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: default avatarTobias Winter <>
      Reviewed-by: default avatarJohan Hovold <>
      Signed-off-by: default avatarGreg Kroah-Hartman <>
       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(-)
    • Johan Hovold's avatar
      USB: pl2303: fix device initialisation at open · 2d8f4447
      Johan Hovold authored
      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
      Signed-off-by: default avatarJohan Hovold <>
      Signed-off-by: default avatarGreg Kroah-Hartman <>
  10. 03 Jun, 2013 1 commit
  11. 30 May, 2013 1 commit
  12. 25 Mar, 2013 6 commits
  13. 21 Mar, 2013 1 commit