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>

This code should return -ENOMEM if the kmalloc() fails but instead
it returns success.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: 0f64478c ("USB: add USB serial mos7720 driver")
Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <johan@kernel.org>

Fix up B0 handling which should leave the baud rate unchanged and
specifically not report back a non-B0 rate when B0 is requested; must
temporarily disable hardware flow control so that RTS can be deasserted;
and should reassert DTR/RTS when moving from B0.

Fixes: c2d405aa ("USB: serial: add MaxLinear/Exar USB to Serial driver")
Signed-off-by: NJohan Hovold <johan@kernel.org>

Make sure that the modem pins are set up correctly when opening the
port to avoid leaving, for example, DTR and RTS configured as inputs,
which is the device default.

This is specifically needed to be able to control DTR and RTS when
hardware flow control is disabled.

Fixes: c2d405aa ("USB: serial: add MaxLinear/Exar USB to Serial driver")
Signed-off-by: NJohan Hovold <johan@kernel.org>

Fix the gpio-mode handling so that all the pins are under driver control
(i.e. in gpio mode) when hardware flow control is disabled.

This is specifically needed to be able to control RTS.

Fixes: c2d405aa ("USB: serial: add MaxLinear/Exar USB to Serial driver")
Signed-off-by: NJohan Hovold <johan@kernel.org>

Simplify the changed-line-speed conditional expression.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Shift the line-setting values when defining them rather than in
set_termios() for consistency and improved readability.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add the missing device-recipient define to the vendor control requests
for completeness.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Use the termios flag helpers consistently, including for CRTSCTS.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Use the subsystem struct usb_device pointer at probe instead of
deriving it from the interface pointer.
Signed-off-by: NJohan Hovold <johan@kernel.org>

Make sure to release the control interface at disconnect so that the
driver can be unbound without leaking resources (and later rebound).

Fixes: c2d405aa ("USB: serial: add MaxLinear/Exar USB to Serial driver")
Signed-off-by: NJohan Hovold <johan@kernel.org>

Make sure that the probed device has an interface 0 to avoid
dereferencing a NULL pointer in case of a malicious device or during
USB-descriptor fuzzing.

Fixes: c2d405aa ("USB: serial: add MaxLinear/Exar USB to Serial driver")
Signed-off-by: NJohan Hovold <johan@kernel.org>

This should return -ENOMEM instead of 0 if the kmalloc() fails.

Fixes: 3f542974 ("USB: Moschip 7840 USB-Serial Driver")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add support for MaxLinear/Exar USB to Serial converters. This driver
only supports XR21V141X series but it can be extended to other series
from Exar as well in future.

This driver is inspired from the initial one submitted by Patong Yang:

https://lore.kernel.org/r/20180404070634.nhspvmxcjwfgjkcv@advantechmxl-desktop

While the initial driver was a custom tty USB driver exposing whole
new serial interface ttyXRUSBn, this version is completely based on USB
serial core thus exposing the interfaces as ttyUSBn. This will avoid
the overhead of exposing a new USB serial interface which the userspace
tools are unaware of.

The Exar XR21V141X can be used in either ACM mode using the cdc-acm
driver or in "custom driver" mode in which further features such as
hardware and software flow control, GPIO control and in-band line-status
reporting are available.

In ACM mode the device always enables RTS/CTS flow control, something
which could prevent transmission in case the CTS input isn't wired up
corrently.

A follow-on patch will prevent cdc_acm from binding whenever this driver
is enabled.
Signed-off-by: NManivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/20201122170822.21715-2-mani@kernel.org
[ johan: fix some style nits, group related functions, drop unused
	 callbacks, and amend commit message; a few remaining
	 non-trivial issues will be fixed separately ]
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 check.
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>

Fix a copy-paste error in the ti_vread_sync() debug message.
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 check.
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 check.
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 check.
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
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>

The latest chip family (HXN) apparently does not support setting the
line speed using divisors and instead needs to use the direct encoding
scheme for all rates.

This specifically enables 50, 110, 134, 200 bps and other rates not
supported by the original chip type.

Fixes: ebd09f1c ("USB: serial: pl2303: add support for PL2303HXN")
Cc: stable@vger.kernel.org      # 5.5
Cc: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>

clang static analysis reports this problem

mos7720.c:352:2: warning: Undefined or garbage value returned to caller
        return d;
        ^~~~~~~~

In the parport_mos7715_read_data()'s call to read_mos_reg(), 'd' is
only set after the alloc block.

	buf = kmalloc(1, GFP_KERNEL);
	if (!buf)
		return -ENOMEM;

Although the problem is reported in parport_most7715_read_data(),
none of the callee's of read_mos_reg() check the return status.

Make sure to clear the return-value buffer also on allocation failures.

Fixes: 0d130367 ("USB: serial: mos7720: fix control-message error handling")
Signed-off-by: NTom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20210111220904.1035957-1-trix@redhat.com
[ johan: only clear the buffer on errors, amend commit message ]
Signed-off-by: NJohan Hovold <johan@kernel.org>

Stack-allocated buffers cannot be used for DMA (on all architectures) so
allocate the flush command buffer using kmalloc().

Fixes: 60a8fc01 ("USB: add iuu_phoenix driver")
Cc: stable <stable@vger.kernel.org>     # 2.6.25
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add a device-id entry for the LongSung M5710 module.

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=2df3 ProdID=9d03 Rev= 1.00
S:  Manufacturer=Marvell
S:  Product=Mobile Composite Device Bus
S:  SerialNumber=<snip>
C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: NDaniel Palmer <daniel@0x0f.com>
https://lore.kernel.org/r/20201227031716.1343300-1-daniel@0x0f.com
[ johan: drop id defines, only bind to vendor class ]
Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <johan@kernel.org>

New modem using ff/ff/30 for QCDM, ff/00/00 for  AT and NMEA,
and ff/ff/ff for RMNET/QMI.

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=2c7c ProdID=0620 Rev= 4.09
S: Manufacturer=Quectel
S: Product=EM160R-GL
S: SerialNumber=e31cedc1
C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms

Cc: stable@vger.kernel.org
Signed-off-by: NBjørn Mork <bjorn@mork.no>
[ johan: add model comment ]
Signed-off-by: NJohan Hovold <johan@kernel.org>

The validity of the ftdi CBUS GPIO is pretty hidden so far,
and finding out *why* some GPIOs don't work is sometimes
hard to identify. So let's help the user by displaying the
map of the CBUS pins that are valid for a GPIO.
Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201204164739.781812-4-maz@kernel.orgReviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
[johan: demote to KERN_DEBUG, rephrase messages, drop ftx-prog warning]
Signed-off-by: NJohan Hovold <johan@kernel.org>

Now that gpiolib can track the validity of GPIO pins, there is no need
to check whether the line is valid in request().
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201204164739.781812-5-maz@kernel.orgReviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
[johan: amend commit message]
Signed-off-by: NJohan Hovold <johan@kernel.org>

Since it is pretty common for only some of the CBUS lines to be
valid as GPIO lines, let's report such validity to the rest of
the kernel.
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201204164739.781812-3-maz@kernel.orgReviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Add an interface-number sanity check before testing the device flags to
avoid relying on undefined behaviour when left shifting in case a device
uses an interface number greater than or equal to BITS_PER_LONG (i.e. 64
or 32).

Reported-by: syzbot+8881b478dad0a7971f79@syzkaller.appspotmail.com
Fixes: c3a65808 ("USB: serial: option: reimplement interface masking")
Cc: stable@vger.kernel.org
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>