The CP210X_SET_MHS request cannot be used to control RTS when hardware
flow control (auto-RTS) is enabled and instead returns an error which is
currently logged as:

	cp210x ttyUSB0: failed set request 0x7 status: -32

when opening and closing a port (and on TIOCMSET requests).

Add a crtscts flag to keep track of the hardware flow-control setting
and use it to suppress any request to change RTS when auto-RTS is
enabled.

Note that RTS is still deasserted when disabling the UART as part of
close.
Reported-by: NPho Tran <pho.tran@silabs.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add a copyright notice for myself.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Drop include directives that are no longer used.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

There's no need to check for short control transfers when sending data
so remove the redundant sanity checks.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Update the XON/XOFF control characters also when no other flow-control
flag has changed and software flow control is enabled.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

At least CP2102 requires the XON/XOFF limits to be initialised in order
for software input flow control (IXOFF) to work. Specifically, XOFF is
never sent if the XOFF limit is left at its default value of zero.

Set the limits so that input is throttled when the FIFO free level drops
below 128 bytes and restarted when the FIFO fill level drops below 128
bytes.

Note that the threshold values have been chosen so that they can be used
also with CP2105 which has the smallest FIFO of the currently supported
device types (288 byte for the SCI port). If needed the limits can be
made device specific later.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

When data is transmitted between two serial ports, the phenomenon of
data loss often occurs. The two kinds of flow control commonly used in
serial communication are hardware flow control and software flow
control.

In serial communication, If you only use RX/TX/GND Pins, you can't do
hardware flow. So we often used software flow control and prevent data
loss. The user sets the software flow control through the application
program, and the application program sets the software flow control mode
for the serial port chip through the driver.

For the cp210 serial port chip, its driver lacks the software flow
control setting code, so the user cannot set the software flow control
function through the application program. This adds the missing software
flow control.
Signed-off-by: NWang Sheng Long <shenglong.wang.ext@siemens.com>
Link: https://lore.kernel.org/r/20210104094502.3942-1-china_shenglong@163.com
[ johan: rework properly on top of recent termios changes ]
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Clean up dtr_rts() by renaming the port parameter and adding missing
whitespace.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add a helper function to be used to configure flow control.

The flow-control code was the last caller that relied on the
memset-on-failure behaviour of cp210x_read_reg_block(), which we can now
drop in favour of bailing out on errors when retrieving the flow-control
settings.

This should also simplify adding support for software flow control.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Drop some unnecessary flow-control debugging.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Unlike other drivers cp210x have been retrieving the current terminal
settings from the device on open and reflecting those in termios.

Due to how set_termios() used to be implemented, this saved a few
control requests on open but has instead caused problems like broken
flow control and has required adding workarounds for swapped
line-control in cp2108 and line-speed initialisation on cp2104.

This unusual implementation also complicates adding new features for no
good reason.

Rip out the corresponding code and the above mentioned workarounds and
instead initialise the terminal settings unconditionally on open.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Update the line-control settings in one request unconditionally instead
of setting the word-length, parity and stop-bit settings separately.

This avoids multiple requests when several settings are changed even if
this scheme could potentially also be used to detect unsupported device
settings. Since all device types but CP2101 appears to support all
settings, let's handle that one specifically and also report back the
unsupported settings properly through termios by clearing the
corresponding bits.

Also drop the related unnecessary debug printks.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Return early from set_termios() in case no relevant terminal settings
have changed.

This avoids testing each parameter in turn and specifically allows the
line-control handling to be cleaned up further.
Signed-off-by: NJohan Hovold <johan@kernel.org>

The port data is not exported to user space so use the in-kernel u8
type.

Link: https://lore.kernel.org/r/20200713105517.27796-6-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Drop unnecessary packed attributes from structs without padding.

Link: https://lore.kernel.org/r/20200713105517.27796-5-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Enable TIOCGICOUNT to allow reading out the (unused) interrupt counters
and error statistics.

Note that modem-status events are currently left unimplemented as they
appear to be buffered on at least CP2102 and therefore cannot be used to
implement TIOCMIWAIT.

Link: https://lore.kernel.org/r/20200713105517.27796-4-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add support for line-status events that specifically can be used to
detect and report parity errors.

Enable the device's event-insertion mode whenever input-parity checking
is requested. This will insert line and modem status events into the
data stream.

Note that modem-status changes appear to be buffered until a character
is received (at least on CP2102) and support is therefore left
unimplemented.

On at least one type of these chips (CP2102), line breaks are not
reported as expected either (regardless of whether SERIAL_BREAK_CHAR is
set) so do not enable event-mode when !IGNBRK is requested for now.

Link: https://lore.kernel.org/r/20200713105517.27796-3-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Try to disable the serial interface in the unlikely event that generic
open() fails.

Link: https://lore.kernel.org/r/20200713105517.27796-2-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

CP210x hardware disables auto-RTS but leaves auto-CTS when in hardware
flow control mode and UART on cp210x hardware is disabled. When
re-opening the port, if auto-CTS is enabled on the cp210x, then auto-RTS
must be re-enabled in the driver.
Signed-off-by: NBrant Merryman <brant.merryman@silabs.com>
Co-developed-by: NPhu Luu <phu.luu@silabs.com>
Signed-off-by: NPhu Luu <phu.luu@silabs.com>
Link: https://lore.kernel.org/r/ECCF8E73-91F3-4080-BE17-1714BC8818FB@silabs.com
[ johan: fix up tags and problem description ]
Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
Cc: stable <stable@vger.kernel.org>     # 2.6.12
Signed-off-by: NJohan Hovold <johan@kernel.org>

Assign the .throttle and .unthrottle functions to be generic function
in the driver structure to prevent data loss that can otherwise occur
if the host does not enable USB throttling.
Signed-off-by: NBrant Merryman <brant.merryman@silabs.com>
Co-developed-by: NPhu Luu <phu.luu@silabs.com>
Signed-off-by: NPhu Luu <phu.luu@silabs.com>
Link: https://lore.kernel.org/r/57401AF3-9961-461F-95E1-F8AFC2105F5E@silabs.com
[ johan: fix up tags ]
Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
Cc: stable <stable@vger.kernel.org>     # 2.6.12
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add support for the Mark-10 digital force gauge device to the cp201x
driver.

Based on a report and a larger patch from Joel Jennings
Reported-by: NJoel Jennings <joel.jennings@makeitlabs.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NJohan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Lorenz Messtechnik has a device that is controlled by the cp210x driver,
so add the device id to the driver.  The device id was provided by
Silicon-Labs for the devices from this vendor.
Reported-by: NUli <t9cpu@web.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Current GPIO code in cp210x fails to take USB autosuspend into account,
making it practically impossible to use GPIOs with autosuspend enabled
without user configuration. Fix this like for ftdi_sio in a previous patch.
Tested on a CP2102N.
Signed-off-by: NKaroly Pados <pados@pados.hu>
Fixes: cf5276ce ("USB: serial: cp210x: Adding GPIO support for CP2105")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Here is how this device appears in kernel log:

	usb 3-1: new full-speed USB device number 18 using xhci_hcd
	usb 3-1: New USB device found, idVendor=0b00, idProduct=3070
	usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
	usb 3-1: Product: Ingenico 3070
	usb 3-1: Manufacturer: Silicon Labs
	usb 3-1: SerialNumber: 0001

Apparently this is a POS terminal with embedded USB-to-Serial converter.

Cc: stable@vger.kernel.org
Signed-off-by: NIvan Mironov <mironov.ivan@gmail.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add minimum baud rate to the cp210x driver.

According to the datasheet for CP2105, the SCI supports 2400 as the
lowest baud rate. As this is not heeded in the current code, an error
message 'failed set req 0x1e size 4 status: -32' when trying to set a
lower baud rate such as 300.
The other cp210x models to date supports a minimum baud rate of 300.
Signed-off-by: NJohanna Abrahamsson <johanna.abrahamsson@afconsult.com>
[ johan: simplify min_speed init, move clamp after comment, and drop
         unused serial-data pointer from cp210x_get_actual_rate() ]
Signed-off-by: NJohan Hovold <johan@kernel.org>

The CP2104 chips feature 4 controllable GPIO pins, which are similar to
the ones on CP2102N chip (output-only when push-pull, output or
simulated input mode when open-drain).

Add support for the GPIO pins for cp210x driver. The pin get/set routine
is shared with CP2102N, but the pinconf initialization code is not
shared because the acquisition of GPIO configuration in OTP ROM is
similar to CP2105, not CP2102N.
Signed-off-by: NIcenowy Zheng <icenowy@aosc.io>
Signed-off-by: NJohan Hovold <johan@kernel.org>

The QFN28 package version of the CP2102N has three additional gpio pins.
Add support for these.
Signed-off-by: NMans Rullgard <mans@mansr.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>

This patch adds GPIO support for CP2102N devices.

It introduces new generic code to support emulating separate
input and outputs directions even though these devices
only know output modes (open-drain and pushpull). Existing
GPIO support for CP2105 has been migrated over to the new
code structure.

Only limitation is that for the QFN28 variant, only 4 out of
7 GPIOs are supported. This is because the config array
locations of the last 3 pins are not documented, and reverse
engineering revealed offsets that conflicted with other
documented functions. Hence we'll play it safe instead
until somebody clears this up further.
Signed-off-by: NKaroly Pados <pados@pados.hu>
[ johan: fix style issues and a couple of minor bugs; use Karoly's
         updated commit message ]
Acked-by: NMartyn Welch <martyn.welch@collabora.co.uk>
Signed-off-by: NJohan Hovold <johan@kernel.org>

CP2104 and the ECI interface of CP2105 support further baud rates than
the ones specified in AN205 table 1, and we can use the same equations
as for CP2102N to determine and report back the actual baud rates used.

Note that this could eventually be generalised also to CP2108, which
uses a different base clock. There appears to be an error in the CP2108
equations which needs to be confirmed on actual hardware first however
(specifically, the subtraction of one from the divisor appears to be
incorrect as it introduces larger errors).
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

The CP2102N equations for determining the actual baud rate can be used
also for other device types, so let's factor it out.

Note that this removes the now unused cp210x_is_cp2102n() helper.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

CP2102N devices support a lot more baudrates than earlier chips by
SiLabs. These devices are not constrained anymore by the table in AN205,
and are able to generate almost any baudrate in the supported range
with only minimal errors. This has also been verified with a scope on
a physical device. This patch adds support for all baudrates supported
by the CP2102N.
Signed-off-by: NKaroly Pados <pados@pados.hu>
[johan: rework on top of an205 and max-speed patches ]
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Newer cp210x devices support higher line speeds than the older ones
which supported a discrete set of speeds up to 921.6 kbaud.

To support these higher speeds, we have for some time mapped speeds
lower than 1 Mbaud to the speeds supported by older devices, while
allowing the device to pick the closest possible rate for higher speeds
(without trying to guess and report back what rate was actually chosen).

As this implementation can lead to undefined behaviour for older devices
which do not support the higher rates, let's use the later-added
device-type detection to determine the maximum supported speed.

This will also be useful when adding support for cp2102n which can
handle rates up to 3 Mbaud.

As per the data sheets the following maximum speeds are used

	cp2101		921.6 kbaud
	cp2102/3	1 Mbaud
	cp2104/8	2 Mbaud
	cp2105
	 - ECI port	2 Mbaud
	 - SCI port	921.6 kbaud

while keeping the maximum 2 Mbaud for unknown device types in order to
avoid any regressions.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Older cp210x devices only support a fixed set of line speeds to which a
requested speed is mapped. Reimplement this mapping using a table
instead of a long if-else construct.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

There are two versions of the Qivicon Zigbee stick in circulation. This
adds the second USB ID to the cp210x driver.
Signed-off-by: NOlli Salonen <olli.salonen@iki.fi>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add device ids for CESINEL products.
Reported-by: NCarlos Barcala Lara <cabl@cesinel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Silicon Labs defines alternative VID/PID pairs for some chips that when
used will automatically install drivers for Windows users without manual
intervention. Unfortunately, these IDs are not recognized by the Linux
module, so using these IDs improves user experience on one platform but
degrades it on Linux. This patch addresses this problem.
Signed-off-by: NKaroly Pados <pados@pados.hu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Added the USB VID and PID for the USB serial console on some National
Instruments devices.
Signed-off-by: NKyle Roeschley <kyle.roeschley@ni.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add device id for ELDAT Easywave RX09 tranceiver.
Reported-by: NJan Jansen <nattelip@hotmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds the ELV ALC 8xxx Battery Charging device
to the list of USB IDs of drivers/usb/serial/cp210x.c
Signed-off-by: NChristian Holl <cyborgx1@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add IDs for the OneTouch Verio IQ that comes with an embedded
USB-to-serial converter.
Signed-off-by: NDiego Elio Pettenò <flameeyes@flameeyes.eu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>