Signed-off-by: Movie Song <MovieSong@aten-itlab.cn>
Cc: Johan Hovold <johan@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The device exposes AT, NMEA and DIAG ports in both USB configurations.

The patch explicitly ignores interfaces 0 and 1, as they're bound to
other drivers already; and also interface 6, which is a GNSS interface
for which we don't have a driver yet.

T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 18 Spd=480 MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
P:  Vendor=413c ProdID=81d7 Rev=03.18
S:  Manufacturer=DELL
S:  Product=DW5821e Snapdragon X20 LTE
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
P:  Vendor=413c ProdID=81d7 Rev=03.18
S:  Manufacturer=DELL
S:  Product=DW5821e Snapdragon X20 LTE
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Johan writes:

USB-serial updates for v4.19-rc1

Here are the USB-serial updates for 4.19-rc1, including:

 - gpio support for CP2102N devices
 - improved line-speed handling for cp210x
 - conversion to spin_lock_irqsave() in completion handlers
 - dropped kl5kusb105 support from the kl5kusb105 driver (sic!)

Included are also various lower-priority fixes and clean ups.

All but the final commit have been in linux-next, and with no reported
issues.

Signed-off-by: Johan 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: Karoly Pados <pados@pados.hu>
[ johan: fix style issues and a couple of minor bugs; use Karoly's
         updated commit message ]
Acked-by: Martyn Welch <martyn.welch@collabora.co.uk>
Signed-off-by: Johan 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Karoly Pados <pados@pados.hu>
[johan: rework on top of an205 and max-speed patches ]
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>

Drop redundant input-speed re-encoding at every open(). The output and
input speeds are initialised to the same value and are kept in sync on
termios updates.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>