commit b50f8f09c6 upstream.
Add the device id for NCR's Retail IO box (CP2105) used in NCR FastLane
SelfServ Checkout - R6C:
https://www.ncr.com/product-catalog/ncr-fastlane-selfserv-checkout-r6c
Reported-by: Scott Russell <Scott.Russell2@ncr.com>
Cc: stable@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 83b67041f3 upstream.
When generalising GPIO support and adding support for CP2102N, the GPIO
registration for some CP2105 devices accidentally broke. Specifically,
when all the pins of a port are in "modem" mode, and thus unavailable
for GPIO use, the GPIO chip would now be registered without having
initialised the number of GPIO lines. This would in turn be rejected by
gpiolib and some errors messages would be printed (but importantly probe
would still succeed).
Fix this by initialising the number of GPIO lines before registering the
GPIO chip.
Note that as for the other device types, and as when all CP2105 pins are
muxed for LED function, the GPIO chip is registered also when no pins
are available for GPIO use.
Reported-by: Maarten Brock <m.brock@vanmierlo.com>
Link: https://lore.kernel.org/r/5eb560c81d2ea1a2b4602a92d9f48a89@vanmierlo.com
Fixes: c8acfe0aad ("USB: serial: cp210x: implement GPIO support for CP2102N")
Cc: stable@vger.kernel.org # 4.19
Cc: Karoly Pados <pados@pados.hu>
Link: https://lore.kernel.org/r/20211126094348.31698-1-johan@kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Maarten Brock <m.brock@vanmierlo.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some CP2102 do not support event-insertion mode but return no error when
attempting to enable it.
This means that any event escape characters in the input stream will not
be escaped by the device and consequently regular data may be
interpreted as escape sequences and be removed from the stream by the
driver.
The reporter's device has batch number DCL00X etched into it and as
discovered by the SHA2017 Badge team, counterfeit devices with that
marking can be detected by sending malformed vendor requests. [1][2]
Tests confirm that the possibly counterfeit CP2102 returns a single byte
in response to a malformed two-byte part-number request, while an
original CP2102 returns two bytes. Assume that every CP2102 that behaves
this way also does not support event-insertion mode (e.g. cannot report
parity errors).
[1] https://mobile.twitter.com/sha2017badge/status/1167902087289532418
[2] https://hackaday.com/2017/08/14/hands-on-with-the-shacamp-2017-badge/#comment-3903376
Reported-by: Malte Di Donato <malte@neo-soft.org>
Tested-by: Malte Di Donato <malte@neo-soft.org>
Fixes: a7207e9835 ("USB: serial: cp210x: add support for line-status events")
Cc: stable@vger.kernel.org # 5.9
Link: https://lore.kernel.org/r/20210922113100.20888-1-johan@kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
CP2105, CP2108 and CP2102N have vendor requests that can be used to
retrieve the firmware version. Having this information available is
essential when trying to work around buggy firmware as a recent CP2102N
regression showed.
Determine and log the firmware version also for CP2105 and CP2108
during type detection at probe.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Clean up attach somewhat by moving type detection into the quirk helper
and giving it a more generic name.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Use the generic control request helper to implement the SET_CHARS
request.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
For consistency use the USB_CTRL_GET_TIMEOUT define for the
read-register request timeout (same value as USB_CTRL_SET_TIMEOUT).
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Make sure that the driver crtscts state is not updated in the unlikely
event that the flow-control request fails. Not doing so could break RTS
control.
Fixes: 5951b85088 ("USB: serial: cp210x: suppress modem-control errors")
Cc: stable@vger.kernel.org # 5.11
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
In the unlikely event that setting the software flow-control characters
fails the other flow-control settings should still be updated (just like
all other terminal settings).
Move out the error message printed by the set_chars() helper to make it
more obvious that this is intentional.
Fixes: 7748feffcd ("USB: serial: cp210x: add support for software flow control")
Cc: stable@vger.kernel.org # 5.11
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Add the USB serial device ID for the CEL ZigBee EM3588 radio stick.
Signed-off-by: John Keeping <john@metanate.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Fix comments for GE CS1000 CP210x USB ID assignments.
Fixes: 42213a0190 ("USB: serial: cp210x: add some more GE USB IDs")
Signed-off-by: Ian Ray <ian.ray@ge.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Here are the USB-serial updates for 5.14-rc1, including:
- gpio support for CP2108
- chars_in_buffer and write_room return-value updates
- chars_in_buffer and write_room clean ups
Included are also various clean ups.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCYNRHtQAKCRALxc3C7H1l
CD96AQDYFm0ssrdV61bejQLX+9LrIfNuISXNJy9cLhCxi3ZYJwD/ZLJhz0K/Xby1
+Xm4J5UVbPuIKMkNKMc0ezH0XZfURwU=
=61V6
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-5.14-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
Johan writes:
USB-serial updates for 5.14-rc1
Here are the USB-serial updates for 5.14-rc1, including:
- gpio support for CP2108
- chars_in_buffer and write_room return-value updates
- chars_in_buffer and write_room clean ups
Included are also various clean ups.
All have been in linux-next with no reported issues.
* tag 'usb-serial-5.14-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: cp210x: add support for GPIOs on CP2108
USB: serial: drop irq-flags initialisations
USB: serial: mos7840: drop buffer-callback return-value comments
USB: serial: mos7720: drop buffer-callback sanity checks
USB: serial: io_edgeport: drop buffer-callback sanity checks
USB: serial: digi_acceleport: add chars_in_buffer locking
USB: serial: digi_acceleport: reduce chars_in_buffer over-reporting
USB: serial: make usb_serial_driver::chars_in_buffer return uint
USB: serial: make usb_serial_driver::write_room return uint
Similar to some other CP210x device types, CP2108 has a number of GPIO
pins that can be exposed through gpiolib.
CP2108 has four serial interfaces but only one set of GPIO pins, which
is modelled as a single gpio chip and registered as a child of the first
interface.
CP2108 has 16 GPIOs so the width of the state variables needs to be
extended to 16 bits and this is also reflected in the control requests.
Like CP2104, CP2108 have GPIO pins with configurable alternate
functions and pins unavailable for GPIO use are determined and reported
to gpiolib at probe.
Signed-off-by: Pho Tran <pho.tran@silabs.com>
Co-developed-by: Tung Pham <tung.pham@silabs.com>
Signed-off-by: Tung Pham <tung.pham@silabs.com>
[ johan: rewrite gpio get() and set(); misc cleanups; amend commit
message ]
Link: https://lore.kernel.org/r/20210610132844.25495-1-johan@kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
CP2102N revision A01 (firmware version <= 1.0.4) has a buggy
flow-control implementation that uses the ulXonLimit instead of
ulFlowReplace field of the flow-control settings structure (erratum
CP2102N_E104).
A recent change that set the input software flow-control limits
incidentally broke RTS control for these devices when CRTSCTS is not set
as the new limits would always enable hardware flow control.
Fix this by explicitly disabling flow control for the buggy firmware
versions and only updating the input software flow-control limits when
IXOFF is requested. This makes sure that the terminal settings matches
the default zero ulXonLimit (ulFlowReplace) for these devices.
Link: https://lore.kernel.org/r/20210609161509.9459-1-johan@kernel.org
Reported-by: David Frey <dpfrey@gmail.com>
Reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
Tested-by: Alex Villacís Lasso <a_villacis@palosanto.com>
Fixes: f61309d9c9 ("USB: serial: cp210x: set IXOFF thresholds")
Cc: stable@vger.kernel.org # 5.12
Signed-off-by: Johan Hovold <johan@kernel.org>
The QFN20 part has a different GPIO/port function assignment. The
configuration struct bit field ordered as TX/RX/RS485/WAKEUP/CLK
which exactly matches GPIO0-3 for QFN24/28. However, QFN20 has a
different GPIO to primary function assignment.
Special case QFN20 to follow to properly detect which GPIOs are
available.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Link: https://lore.kernel.org/r/51830b2b24118eb0f77c5c9ac64ffb2f519dbb1d.1622218300.git.stefan@agner.ch
Fixes: c8acfe0aad ("USB: serial: cp210x: implement GPIO support for CP2102N")
Cc: stable@vger.kernel.org # 4.19
Signed-off-by: Johan Hovold <johan@kernel.org>
Add a debug printk to dump the GPIO configuration stored in EEPROM
during probe.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Use the new GPIO valid-mask feature to inform gpiolib which pins are
available for use instead of handling that in a request callback.
This also allows user space to figure out which pins are available
through the chardev interface without having to request each pin in
turn.
Note that the return value when requesting an unavailable pin will now
be -EINVAL instead of -ENODEV.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
GE CS1000 has some more custom USB IDs for CP2102N; add them
to the driver to have working auto-probing.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Here are the USB-serial updates for 5.12-rc1, including:
- a line-speed fix for newer pl2303 devices
- a line-speed fix for FTDI FT-X devices
- a new xr_serial driver for MaxLinear/Exar devices (non-ACM mode)
- a cdc-acm blacklist entry for when the xr_serial driver is enabled
- cp210x support for software flow control
- various cp210x modem-control fixes
- an updated ZTE P685M modem entry to stop claiming the QMI interface
- an update to drop the port_remove() driver-callback return value
Included are also various clean ups.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCYCPxBQAKCRALxc3C7H1l
CP1iAQCRn7/4ulkGXgSjVL2o8TfGAQRhvxL14qtzysOyPLwgrAD6ApuJdPRHnetL
q0TDaRqnXqVTV6uUfoSC5eVEF4dS/Qs=
=5ZLn
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-5.12-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
Johan writes:
USB-serial updates for 5.12-rc1
Here are the USB-serial updates for 5.12-rc1, including:
- a line-speed fix for newer pl2303 devices
- a line-speed fix for FTDI FT-X devices
- a new xr_serial driver for MaxLinear/Exar devices (non-ACM mode)
- a cdc-acm blacklist entry for when the xr_serial driver is enabled
- cp210x support for software flow control
- various cp210x modem-control fixes
- an updated ZTE P685M modem entry to stop claiming the QMI interface
- an update to drop the port_remove() driver-callback return value
Included are also various clean ups.
All have been in linux-next with no reported issues.
* tag 'usb-serial-5.12-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (41 commits)
USB: serial: drop bogus to_usb_serial_port() checks
USB: serial: make remove callback return void
USB: serial: drop if with an always false condition
USB: serial: option: update interface mapping for ZTE P685M
USB: serial: ftdi_sio: restore divisor-encoding comments
USB: serial: ftdi_sio: fix FTX sub-integer prescaler
USB: serial: cp210x: clean up auto-RTS handling
USB: serial: cp210x: fix RTS handling
USB: serial: cp210x: clean up printk zero padding
USB: serial: cp210x: clean up flow-control debug message
USB: serial: cp210x: drop shift macros
USB: serial: cp210x: fix modem-control handling
USB: serial: cp210x: suppress modem-control errors
USB: serial: mos7720: fix error code in mos7720_write()
USB: serial: xr: fix B0 handling
USB: serial: xr: fix pin configuration
USB: serial: xr: fix gpio-mode handling
USB: serial: xr: simplify line-speed logic
USB: serial: xr: clean up line-settings handling
USB: serial: xr: document vendor-request recipient
...
All usb_serial drivers return 0 in their remove callbacks and driver
core ignores the value returned by usb_serial_device_remove(). So change
the remove callback to return void and return 0 unconditionally in
usb_serial_device_remove().
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20210208143149.963644-2-uwe@kleine-koenig.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Clear the RTS bits of the flow-control request before determining the
new value when updating the settings.
Signed-off-by: Johan Hovold <johan@kernel.org>
Clearing TIOCM_RTS should always deassert RTS and setting the same bit
should enable auto-RTS if hardware flow control is enabled.
This allows user space to throttle input directly at the source also
when hardware-assisted flow control is enabled and makes dtr_rts()
always deassert both lines during close (when HUPCL is set).
Signed-off-by: Johan Hovold <johan@kernel.org>
Shorten the flow-control debug message by abbreviating the field names
and reducing the value width to two characters. The latter improves
readability since all but the least significant byte will almost always
be zero anyway.
Signed-off-by: Johan Hovold <johan@kernel.org>
Drop the macros used to shift the flow-control settings to make the code
more readable for consistency with the other requests.
Signed-off-by: Johan Hovold <johan@kernel.org>
The vendor request used to set the flow-control settings also sets the
state of the modem-control lines.
Add state variables to keep track of the modem-control lines to avoid
always asserting the lines whenever the flow-control settings are
updated.
This specifically also avoids asserting DTR/RTS when opening a port with
the line speed set to B0.
Signed-off-by: Johan Hovold <johan@kernel.org>
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: Pho Tran <pho.tran@silabs.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Information pid/vid of WSDA-200-USB, Lord corporation company:
vid: 199b
pid: ba30
Signed-off-by: Pho Tran <pho.tran@silabs.com>
[ johan: amend comment with product name ]
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Drop include directives that are no longer used.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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: Wang 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Teraoka AD2000 uses the CP210x driver, but the chip VID/PID is
customized with 0988/0578. We need the driver to support the new
VID/PID.
Signed-off-by: Chenxin Jin <bg4akv@hotmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan 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: Johan 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: Johan 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: Johan 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: Johan 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.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan 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.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Bruno Thomsen
Johan Hovold
Uwe Brandt
John Keeping
Ian Ray
Greg Kroah-Hartman
Pho Tran
Stefan Agner
Sebastian Reichel
Karan Singhal
Uwe Kleine-König
Wang Sheng Long
Chenxin Jin