Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure port DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg 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
8d48fdf689 "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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg 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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg 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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg 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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg 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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg 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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Mastro Gippo <gipmad@gmail.com>
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg 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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of having to create a new driver for a "simple" usb to serial
device, mush them all into one file, with a macro, so as to make it easy
to add new ones.
Cc: "René Bürgel" <rene.buergel@sohard.de>
Acked-by: Wei Shuai <cpuwolf@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Acked-by: Frans Klaver <frans.klaver@xsens.com>
Cc: "Wesley W. Terpstra" <w.terpstra@gsi.de>
Cc: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg 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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RT Systems makes many usb serial cables based on the ftdi_sio driver for
programming various amateur radios. This patch is a full listing of
their current product offerings and should allow these cables to all
be recognized.
Signed-off-by: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following regression that has been introduced recently with
commit b2d6d98fc7:
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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Silence compiler warnings on 64-bit systems introduced by commit
05cf0dec ("USB: mos7840: fix race in led handling") which uses the
usb-serial data pointer to temporarily store the device type during
probe but failed to add the required casts.
[gregkh - change uintptr_t to unsigned long]
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix race in LED handling introduced by commit 0eafe4de ("USB: serial:
mos7840: add support for MCS7810 devices") which reused the port control
urb for manipulating the LED without making sure that the urb is not
already in use. This could lead to the control urb being manipulated
while in flight.
Fix by adding a dedicated LED urb and ctrlrequest along with a LED-busy
flag to handle concurrency.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix race in device-type detection introduced by commit 0eafe4de ("USB:
serial: mos7840: add support for MCS7810 devices") which used a static
variable to hold the device type.
Move type detection to probe and use serial data to store the device
type.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix race in mos7840_get_reg which unconditionally manipulated the
control urb (which may already be in use) by adding a control-urb busy
flag.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds a driver for the Suunto ANT+ USB device, exposing it as a usb
serial device. This lets the userspace "gant" program to talk to the
device to communicate over the ANT+ protocol to any devices it finds.
Reported-by: Steinar Gunderson <sgunderson@bigfoot.com>
Tested-by: Steinar Gunderson <sgunderson@bigfoot.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allocated urbs and buffers were never freed on errors in open.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some (very few) early devices like mine, where not exposting a proper CDC
descriptor. This was fixed with an immediate firmware update from the vendor,
and pre-installed on newer devices.
So actual devices can be driven by cdc_acm.c + cdc_ether.c.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Speaks AT on interfaces 5 (command & PPP) and 3 (secondary), other
interface protocols are unknown.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prevent the option driver from binding itself to the QMI/WWAN interface, making
it unusable by the proper driver.
Signed-off-by: enrico Mioso <mrkiko.rs@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds support for the ONYX 3G device (version 1) from ALFA
NETWORK.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver failed to take the dynamic ids into account when determining
the device type and therefore all devices were detected as 2-port
devices when using the dynamic-id interface.
Match on the usb-serial-driver field instead of doing redundant id-table
searches.
Reported-by: Anders Hammarquist <iko@iko.pp.se>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the vendor and product module parameters which were added a long
time ago when we did not have the dynamic sysfs interface to add
new device ids (and which isn't limited to five new vid/pid pair).
A vid/pid pair can be added dynamically using sysfs, for example:
echo 0451 1234 >/sys/bus/usb-serial/drivers/ti_usb_3410_5052_1/new_id
for 1-port adapters, or
echo 0451 1234 >/sys/bus/usb-serial/drivers/ti_usb_3410_5052_2/new_id
for 2-port adapters.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The write wait queue is never added to since commit f1175daa5 ("USB:
ti_usb_3410_5052: kill custom closing_wait"). Remove it completely.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kill private write fifo and use the already allocated port write fifo
instead.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the vendor and product module parameters which were added a long
time ago when we did not have the dynamic sysfs interface to add
new device ids (and which isn't limited to a single new vid/pid pair).
A vid/pid pair can be added dynamically using sysfs, for example:
echo 04dd 1234 >/sys/bus/usb-serial/drivers/safe_serial/new_id
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove broken "chase" implementation which was supposed to be used to
drain the write buffers at break.
The chase implementation slept on a wait queue which was never woken up
(i.e. no hardware buffers were queried), and thus amounted to nothing
more than polling chars_in_buffer, something which has already been
taken care of by the tty layer.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move port initialisation code from open to probe where it belongs.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kill private write fifo and use the already allocated port write fifo
instead.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the vendor and product module parameters which were added a long
time ago when we did not have the dynamic sysfs interface to add
new device ids (and which isn't limited to a single new vid/pid pair).
A vid/pid pair can be added dynamically using sysfs, for example:
echo 0403 1234 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
Also fix up the in-code comment that got the sysfs path wrong.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Do not raise DTR/RTS a second time in set_termios at open -- this has
already been taken care of by the tty layer.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Do not use zeroed termios data to determine when to unconditionally
configure the device at open.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure set_termios is not called with uninitialised data at open. The
old termios struct is currently not used, but pass NULL instead to avoid
future problems (e.g. stack data leak).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Only log the tty_flags in process_read_urb on errors.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Break out baud-rate handling from set_termios.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary tests for open and write operations as these are set
to the generic implementations by usb-serial core if left unset by a
subdriver.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
