leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ab78130e6e
linux/drivers/usb/serial/cp210x.c

2184 lines
64 KiB
C
Raw Normal View History

USB: add SPDX identifiers to all remaining files in drivers/usb/ It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/usb/ and include/linux/usb* files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-03 10:28:30 +00:00
// SPDX-License-Identifier: GPL-2.0
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
/*
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
* Silicon Laboratories CP210x USB to RS232 serial adaptor driver
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
*
* Copyright (C) 2005 Craig Shelley (craig@microtron.org.uk)
USB: serial: cp210x: add copyright notice Add a copyright notice for myself. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-01-18 11:13:31 +00:00
* Copyright (C) 2010-2021 Johan Hovold (johan@kernel.org)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
*
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
* Support to set flow control line levels using TIOCMGET and TIOCMSET
* thanks to Karl Hiramoto karl@hiramoto.org. RTSCTS hardware flow
* control thanks to Munir Nassar nassarmu@real-time.com
*
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
*/
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
#include <linux/module.h>
#include <linux/usb.h>
[PATCH] USB: move usb-serial.h to include/linux/usb/ USB serial outside of the kernel tree can not build properly due to usb-serial.h being buried down in the source tree. This patch moves the location of the file to include/linux/usb and fixes up all of the usb serial drivers to handle the move properly. Cc: Sergei Organov <osv@javad.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-12 04:22:58 +00:00
#include <linux/usb/serial.h>
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
#include <linux/gpio/driver.h>
#include <linux/bitops.h>
#include <linux/mutex.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
#define DRIVER_DESC "Silicon Labs CP210x RS232 serial adaptor driver"
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
/*
* Function Prototypes
*/
tty: USB does not need the filp argument in the drivers And indeed none of them use it. Clean this up as it will make moving to a standard open method rather easier. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-09-19 20:13:26 +00:00
static int cp210x_open(struct tty_struct *tty, struct usb_serial_port *);
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
static void cp210x_close(struct usb_serial_port *);
USB: cp210x: clean up, refactor and document speed handling Clean up and refactor speed handling. Document baud rate handling for CP210{1,2,4,5,10}. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-15 23:36:51 +00:00
static void cp210x_change_speed(struct tty_struct *, struct usb_serial_port *,
struct ktermios *);
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
static void cp210x_set_termios(struct tty_struct *, struct usb_serial_port *,
usb_serial: API all change USB serial likes to use port->tty back pointers for the real work it does and to do so without any actual locking. Unfortunately when you consider hangup events, hangup/parallel reopen or even worse hangup followed by parallel close events the tty->port and port->tty pointers are not guaranteed to be the same as port->tty is the active tty while tty->port is the port the tty may or may not still be attached to. So rework the entire API to pass the tty struct. For console cases we need to pass both for now. This shows up multiple drivers that immediately crash with USB console some of which have been fixed in the process. Longer term we need a proper tty as console abstraction Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-22 10:09:07 +00:00
struct ktermios*);
USB: cp210x: add tx_empty() Added tx_empty callback needed for generic wait-until-sent support. Without this function, when the port is closed usbserial can't know that there are still data in the chip's transmit FIFO. The chip gets disabled and untransmitted data lost. When the actual byte count is reported by tx-empty the close can be delayed until all data are sent. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: modify tx_empty error handling ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-24 22:28:41 +00:00
static bool cp210x_tx_empty(struct usb_serial_port *port);
tiocmget: kill off the passing of the struct file We don't actually need this and it causes problems for internal use of this functionality. Currently there is a single use of the FILE * pointer. That is the serial core which uses it to check tty_hung_up_p. However if that is true then IO_ERROR is also already set so the check may be removed. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-14 16:26:14 +00:00
static int cp210x_tiocmget(struct tty_struct *);
tiocmset: kill the file pointer argument Doing tiocmget was such fun we should do tiocmset as well for the same reasons Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-14 16:26:50 +00:00
static int cp210x_tiocmset(struct tty_struct *, unsigned int, unsigned int);
static int cp210x_tiocmset_port(struct usb_serial_port *port,
USB: Fix cp2101 USB serial device driver termios functions for console use This is really a follow up to the modifications Alan Cox made for commit 95da310e66ee8090119596c70ca8432e57f9a97f to pass a tty_struct to various interface functions, which broke the serial configuration (termios) functions when the device is being used as a console. These changes restore the configuration to proper functioning both as a tty and as a console. As Alan notes in that commit, these changes will need to be tweaked when we have a proper console abstraction. Signed-off-by: David VomLehn <dvomlehn@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-12 21:37:42 +00:00
unsigned int, unsigned int);
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
static void cp210x_break_ctl(struct tty_struct *, int);
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
static int cp210x_attach(struct usb_serial *);
static void cp210x_disconnect(struct usb_serial *);
static void cp210x_release(struct usb_serial *);
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
static int cp210x_port_probe(struct usb_serial_port *);
USB: serial: make remove callback return void 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>
2021-02-08 14:31:49 +00:00
static void cp210x_port_remove(struct usb_serial_port *);
USB: serial: cp210x: clean up dtr_rts() Clean up dtr_rts() by renaming the port parameter and adding missing whitespace. Signed-off-by: Johan Hovold <johan@kernel.org>
2020-11-16 16:18:26 +00:00
static void cp210x_dtr_rts(struct usb_serial_port *port, int on);
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
static void cp210x_process_read_urb(struct urb *urb);
static void cp210x_enable_event_mode(struct usb_serial_port *port);
static void cp210x_disable_event_mode(struct usb_serial_port *port);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB serial: make USB device id constant The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by: Németh Márton <nm127@freemail.hu> Cc: Julia Lawall <julia@diku.dk> Cc: cocci@diku.dk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-10 14:34:24 +00:00
static const struct usb_device_id id_table[] = {
USB: cp210x: Add Renesas RX-Stick device ID RX610 development board by Renesas Bus 001 Device 024: ID 045b:0053 Hitachi, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x045b Hitachi, Ltd idProduct 0x0053 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 RX-Stick iSerial 3 0001 . . . http://am.renesas.com/rx610stick Signed-off-by: DJ Delorie <dj@delorie.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-09-17 15:09:06 +00:00
{ USB_DEVICE(0x045B, 0x0053) }, /* Renesas RX610 RX-Stick */
USB: ACE1001 patch for cp2101.c The patch which adds IDs for AKTAKOM USB->RS232 cable (http://www.aktakom.ru/product/kio/ace-1001.htm) is attached. From: M Kondrin <mkondrin@hppi.troitsk.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-14 10:02:45 +00:00
{ USB_DEVICE(0x0471, 0x066A) }, /* AKTAKOM ACE-1001 cable */
USB: CP2101 Add new device IDs Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-12 15:15:54 +00:00
{ USB_DEVICE(0x0489, 0xE000) }, /* Pirelli Broadband S.p.A, DP-L10 SIP/GSM Mobile */
USB: cp210x usb driver: add USB_DEVICE for Pirelli DP-L10 mobile. The Pirelli DP-L10 mobile is sold under various brand names. One, already supported by cp210x, is the T-COM TC300. Here is the lsusb for that version: ------------------------------------------------------------------- Bus 001 Device 002: ID 0489:e000 Foxconn / Hon Hai T-Com TC 300 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0489 Foxconn / Hon Hai idProduct 0xe000 T-Com TC 300 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 TC 300 iSerial 3 0001 [snip] --------------------------------------------------------------------------- However the native Pirelli DP-L10 is not supported: ------------------------------------------------------------------ Bus 001 Device 003: ID 0489:e003 Foxconn / Hon Hai Pirelli DP-L10 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0489 Foxconn / Hon Hai idProduct 0xe003 Pirelli DP-L10 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 DP-L10 iSerial 3 0001 [snip] ------------------------------------------------------------------------- All that is required is an extra USB_DEVICE entry: { USB_DEVICE(0x0489, 0xE003) }, /* Pirelli Broadband S.p.A, DP-L10 SIP/GSM +Mobile */ The patch adds that entry. Tested under 2.6.36-rc2 from git. Signed-off-by: A E Lawrence <lawrence_a_e@ntlworld.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-29 20:51:52 +00:00
{ USB_DEVICE(0x0489, 0xE003) }, /* Pirelli Broadband S.p.A, DP-L10 SIP/GSM Mobile */
USB: CP210X Add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:52:31 +00:00
{ USB_DEVICE(0x0745, 0x1000) }, /* CipherLab USB CCD Barcode Scanner 1000 */
usb: serial: cp210x: Add USB ID for Netgear Switches embedded serial adapter This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series USB ID (0846:0110) to the cp210x driver. Without this, the serial adapter is not recognized in Linux. Description was obtained from an Netgear Eng. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-02 02:56:25 +00:00
{ USB_DEVICE(0x0846, 0x1100) }, /* NetGear Managed Switch M4100 series, M5300 series, M7100 series */
USB: cp2101.c: add additional device ID This patch adds an additional device ID to the cp2101 USB serial driver. This device is a Gemalto Prox-PU or CU contactless card reader (ISO14443-A/B and Mifare). The reader is a standard Gemalto serial proximity reader using the Gemalto Block Protocol (see reader's documentation) bundled with a built-in CP2102 for serial/USB conversion. Signed-off-by: Edouard Lafargue (edouard@lafargue.name) Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-25 08:15:36 +00:00
{ USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless smartcard reader */
USB: CP210X Add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:52:31 +00:00
{ USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC Device */
USB: cp210x: add ID for RUGGEDCOM USB Serial Console Added the USB serial console device ID for Siemens Ruggedcom devices which have a USB port for their serial console. Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-01-21 20:24:27 +00:00
{ USB_DEVICE(0x0908, 0x01FF) }, /* Siemens RUGGEDCOM USB Serial Console */
USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000 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>
2021-01-13 08:59:05 +00:00
{ USB_DEVICE(0x0988, 0x0578) }, /* Teraoka AD2000 */
USB: serial: cp210x: add ID for Ingenico 3070 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: Ivan Mironov <mironov.ivan@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-02-06 16:14:13 +00:00
{ USB_DEVICE(0x0B00, 0x3070) }, /* Ingenico 3070 */
USB: CP210x New Device IDs 11 New device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-15 12:36:38 +00:00
{ USB_DEVICE(0x0BED, 0x1100) }, /* MEI (TM) Cashflow-SC Bill/Voucher Acceptor */
{ USB_DEVICE(0x0BED, 0x1101) }, /* MEI series 2000 Combo Acceptor */
[PATCH] USB: CP2101 New Device IDs Three new device IDs for CP2101 USB to UART Bridge Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-08-28 08:51:15 +00:00
{ USB_DEVICE(0x0FCF, 0x1003) }, /* Dynastream ANT development board */
USB: New device ID for the CP2101 driver attached please find a new device ID for CP2101 driver. This device is a usb stick from Dynastream to communicate with ANT wireless devices which I suppose is fairly similar to the ANT dev board having product id 0x1003. From: Martin Kusserow <kusserow@ife.ee.ethz.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-21 11:02:17 +00:00
{ USB_DEVICE(0x0FCF, 0x1004) }, /* Dynastream ANT2USB */
USB: CP2101 Add new device IDs Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-12 15:15:54 +00:00
{ USB_DEVICE(0x0FCF, 0x1006) }, /* Dynastream ANT development board */
USB: add OWL CM-160 support to cp210x driver This adds support for the OWL CM-160 electricity monitor to the cp210x driver. Signed-off-by: Luis Llorente <luisllorente@luisllorente.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-31 12:37:05 +00:00
{ USB_DEVICE(0x0FDE, 0xCA05) }, /* OWL Wireless Electricity Monitor CM-160 */
[PATCH] USB: CP2101 New Device IDs Three new device IDs for CP2101 USB to UART Bridge Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-08-28 08:51:15 +00:00
{ USB_DEVICE(0x10A6, 0xAA26) }, /* Knock-off DCU-11 cable */
[PATCH] USB: cp2101 Add new device IDs The attached patch adds four new device IDs for the CP2101 driver. Also 3 tab characters have been removed from device ID table. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-20 00:06:19 +00:00
{ USB_DEVICE(0x10AB, 0x10C5) }, /* Siemens MC60 Cable */
{ USB_DEVICE(0x10B5, 0xAC70) }, /* Nokia CA-42 USB */
USB: CP210X Add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:52:31 +00:00
{ USB_DEVICE(0x10C4, 0x0F91) }, /* Vstabi */
USB: Serial: Add support for Arkham Technology adapters As reported by David Potts from Arkham Technology, the current driver works with their hardware on addition of the device ids. Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-06 11:19:59 +00:00
{ USB_DEVICE(0x10C4, 0x1101) }, /* Arkham Technology DS101 Bus Monitor */
{ USB_DEVICE(0x10C4, 0x1601) }, /* Arkham Technology DS101 Adapter */
USB: CP2101 New Device IDs Six new device IDs for CP2101 driver. Cc: stable <stable@kernel.org> Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-01-03 12:45:59 +00:00
{ USB_DEVICE(0x10C4, 0x800A) }, /* SPORTident BSM7-D-USB main station */
[PATCH] USB: cp2101: add new device IDs This patch adds a new device ID to the cp2101 driver Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-11 11:29:02 +00:00
{ USB_DEVICE(0x10C4, 0x803B) }, /* Pololu USB-serial converter */
USB: CP210x New Device IDs 11 New device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-15 12:36:38 +00:00
{ USB_DEVICE(0x10C4, 0x8044) }, /* Cygnal Debug Adapter */
{ USB_DEVICE(0x10C4, 0x804E) }, /* Software Bisque Paramount ME build-in converter */
USB: CP2101 New Device IDs Two new device IDs for CP2101 driver. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-04-20 13:37:17 +00:00
{ USB_DEVICE(0x10C4, 0x8053) }, /* Enfora EDG1228 */
+ usb-serial-cp2101-add-enfora-gsm2228.patch added to -mm tree Enfora GSM2228 based on Cygnal Integrated Products chip uses the same cp2101 driver. Signed-off-by: Damir N Abdullin <damir@mimas.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-30 20:52:38 +00:00
{ USB_DEVICE(0x10C4, 0x8054) }, /* Enfora GSM2228 */
USB: serial: cp210x: add new device id 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: Uli <t9cpu@web.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-03-27 01:11:14 +00:00
{ USB_DEVICE(0x10C4, 0x8056) }, /* Lorenz Messtechnik devices */
[PATCH] USB: new cp2101 device By the way I have to ask you to add new (vid,pid) pair to cp2101 driver. This device is argussoft's avr in-system programmer AS3M, http://atmel.argussoft.ru/hard.htm it's based on cp2101 chip and works pretty well with the linux driver. It could be used with argussoft's `asisp1109.exe' (http://atmel.argussoft.ru/download/software/as-tools.soft/asisp.zip) tool run under wine. Signed-off-by: Vitja Makarov <vitja.makarov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-05-30 20:40:06 +00:00
{ USB_DEVICE(0x10C4, 0x8066) }, /* Argussoft In-System Programmer */
USB: CP210x New Device IDs 11 New device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-15 12:36:38 +00:00
{ USB_DEVICE(0x10C4, 0x806F) }, /* IMS USB to RS422 Converter Cable */
[PATCH] USB: cp2101 Add new device IDs The attached patch adds four new device IDs for the CP2101 driver. Also 3 tab characters have been removed from device ID table. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-20 00:06:19 +00:00
{ USB_DEVICE(0x10C4, 0x807A) }, /* Crumb128 board */
USB: serial: cp210x: add Optris MS Pro usb id Signed-off-by: Mikko Tuumanen <mikko.tuumanen@qemsoftware.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01 08:28:55 +00:00
{ USB_DEVICE(0x10C4, 0x80C4) }, /* Cygnal Integrated Products, Inc., Optris infrared thermometer */
[PATCH] USB: cp2101 Add new device IDs The attached patch adds four new device IDs for the CP2101 driver. Also 3 tab characters have been removed from device ID table. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-20 00:06:19 +00:00
{ USB_DEVICE(0x10C4, 0x80CA) }, /* Degree Controls Inc */
USB: CP2101 New Device IDs Two new device IDs for CP2101 driver. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-04-20 13:37:17 +00:00
{ USB_DEVICE(0x10C4, 0x80DD) }, /* Tracient RFID */
[PATCH] USB: cp2101 Add new device IDs The attached patch adds four new device IDs for the CP2101 driver. Also 3 tab characters have been removed from device ID table. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-20 00:06:19 +00:00
{ USB_DEVICE(0x10C4, 0x80F6) }, /* Suunto sports instrument */
USB: SERIAL CP2101 add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-04 20:28:21 +00:00
{ USB_DEVICE(0x10C4, 0x8115) }, /* Arygon NFC/Mifare Reader */
[PATCH] USB: cp2101 Add new device IDs The attached patch adds four new device IDs for the CP2101 driver. Also 3 tab characters have been removed from device ID table. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-20 00:06:19 +00:00
{ USB_DEVICE(0x10C4, 0x813D) }, /* Burnside Telecom Deskmobile */
USB: CP210x Add new device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-12 20:52:33 +00:00
{ USB_DEVICE(0x10C4, 0x813F) }, /* Tams Master Easy Control */
USB: New device IDs for cp2101 driver Here are two new device IDs for the cp2101 driver. The diff is with linus's tree as of this evending. From: Jon K Hellan <hellan@acm.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-28 22:04:33 +00:00
{ USB_DEVICE(0x10C4, 0x814A) }, /* West Mountain Radio RIGblaster P&P */
{ USB_DEVICE(0x10C4, 0x814B) }, /* West Mountain Radio RIGtalk */
usb: serial: Add Rigblaster Advantage to device table The Rigblaster Advantage is an amateur radio interface sold by West Mountain Radio. It contains a cp210x serial interface but the device ID is not in the driver. Signed-off-by: Steve Conklin <sconklin@canonical.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-07 23:19:33 +00:00
{ USB_DEVICE(0x2405, 0x0003) }, /* West Mountain Radio RIGblaster Advantage */
USB: cp210x: Add B&G H3000 link cable ID This is the cable between an H3000 navigation unit and a multi-function display. http://www.bandg.com/en/Products/H3000/Spares-and-Accessories/Cables/H3000-CPU-USB-Cable-Pack/ Signed-off-by: Jason Detring <jason.detring@navico.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-26 20:08:54 +00:00
{ USB_DEVICE(0x10C4, 0x8156) }, /* B&G H3000 link cable */
[PATCH] USB: cp2101 Add new device IDs The attached patch adds four new device IDs for the CP2101 driver. Also 3 tab characters have been removed from device ID table. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-20 00:06:19 +00:00
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
USB: CP210x Add 10 Device IDs This patch adds 10 device IDs for CP210x based devices from the following manufacturers: Timewave Clipsal Festo Link Instruments Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-26 22:20:04 +00:00
{ USB_DEVICE(0x10C4, 0x815F) }, /* Timewave HamLinkUSB */
USB: serial: cp210x: add CESINEL device ids Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara <cabl@cesinel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-18 08:24:03 +00:00
{ USB_DEVICE(0x10C4, 0x817C) }, /* CESINEL MEDCAL N Power Quality Monitor */
{ USB_DEVICE(0x10C4, 0x817D) }, /* CESINEL MEDCAL NT Power Quality Monitor */
{ USB_DEVICE(0x10C4, 0x817E) }, /* CESINEL MEDCAL S Power Quality Monitor */
USB: CP210x New Device IDs 11 New device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-15 12:36:38 +00:00
{ USB_DEVICE(0x10C4, 0x818B) }, /* AVIT Research USB to TTL */
USB: serial: new cp2101 device id From: Robert M. Kenney <rmk@unh.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-02-26 19:58:39 +00:00
{ USB_DEVICE(0x10C4, 0x819F) }, /* MJS USB Toslink Switcher */
usb-serial: Add ThinkOptics WavIT Add ThinkOptics WavIt to cp2101 device table Signed-off-by: Bernhard Beck <kernel@goodcoffee.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-05-11 16:23:13 +00:00
{ USB_DEVICE(0x10C4, 0x81A6) }, /* ThinkOptics WavIt */
USB: Add USB-ID for Multiplex RC serial adapter to cp210x.c Hi, below patch adds the USB-ID of the serial adapters sold by Multiplex RC (www.multiplex-rc.de). Signed-off-by: Malte Schröder <maltesch@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-05 19:34:40 +00:00
{ USB_DEVICE(0x10C4, 0x81A9) }, /* Multiplex RC Interface */
USB: CP2101 Add new device IDs Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-12 15:15:54 +00:00
{ USB_DEVICE(0x10C4, 0x81AC) }, /* MSD Dash Hawk */
USB: CP210x New Device IDs 11 New device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-15 12:36:38 +00:00
{ USB_DEVICE(0x10C4, 0x81AD) }, /* INSYS USB Modem */
USB: new VID/PID-combos for cp2101 3 new VID/PID combinations (registered with Silicon Laboratories Inc.) added for devices made by Lipowsky Industrie Elektronik GmbH all using the CP2102 usb-to-serial converter (Baby-JTAG, Baby-LIN, HARP-1). Signed-off-by: Bjorn Schneider <schneider@lipowsky.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-28 10:42:04 +00:00
{ USB_DEVICE(0x10C4, 0x81C8) }, /* Lipowsky Industrie Elektronik GmbH, Baby-JTAG */
USB: cp210x: add ID for IAI USB to RS485 adaptor Added the USB serial console device ID for IAI Corp. RCB-CV-USB USB to RS485 adaptor. Signed-off-by: Peter Dedecker <peter.dedecker@hotmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-01-08 11:34:41 +00:00
{ USB_DEVICE(0x10C4, 0x81D7) }, /* IAI Corp. RCB-CV-USB USB to RS485 Adaptor */
USB: new VID/PID-combos for cp2101 3 new VID/PID combinations (registered with Silicon Laboratories Inc.) added for devices made by Lipowsky Industrie Elektronik GmbH all using the CP2102 usb-to-serial converter (Baby-JTAG, Baby-LIN, HARP-1). Signed-off-by: Bjorn Schneider <schneider@lipowsky.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-28 10:42:04 +00:00
{ USB_DEVICE(0x10C4, 0x81E2) }, /* Lipowsky Industrie Elektronik GmbH, Baby-LIN */
USB: cp2101: new device id This adds a device ID for the Aerocomm Radio Modem, which uses the cp2102. I'm sure changing num_bulk_in/num_bulk_out to NUM_DONT_CARE is the wrong fix, but this is the only device I have with a cp2102, so I have no idea what a good global value would be, if there is one. Zero didn't work with this device. From: Jeff Long <JeffLong@mitre.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-28 16:02:09 +00:00
{ USB_DEVICE(0x10C4, 0x81E7) }, /* Aerocomm Radio */
USB: cp210x: Add 81E8 (Zephyr Bioharness) As reported in http://bugzilla.kernel.org/show_bug.cgi?id=10980 Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-02-08 10:10:44 +00:00
{ USB_DEVICE(0x10C4, 0x81E8) }, /* Zephyr Bioharness */
USB: CP210X Add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:52:31 +00:00
{ USB_DEVICE(0x10C4, 0x81F2) }, /* C1007 HF band RFID controller */
USB: new VID/PID-combos for cp2101 3 new VID/PID combinations (registered with Silicon Laboratories Inc.) added for devices made by Lipowsky Industrie Elektronik GmbH all using the CP2102 usb-to-serial converter (Baby-JTAG, Baby-LIN, HARP-1). Signed-off-by: Bjorn Schneider <schneider@lipowsky.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-28 10:42:04 +00:00
{ USB_DEVICE(0x10C4, 0x8218) }, /* Lipowsky Industrie Elektronik GmbH, HARP-1 */
USB: cp2101 device My girl use modem GSM (EDGE) Commanader 2 on iPlus Polsih provider, PLEASE add this vendor=0x10C4 and product=0x822B to USB serial driver cp2101.c From: Tomasz K <eros81@o2.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-04 11:47:11 +00:00
{ USB_DEVICE(0x10C4, 0x822B) }, /* Modem EDGE(GSM) Comander 2 */
Fix common misspellings Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-31 01:57:33 +00:00
{ USB_DEVICE(0x10C4, 0x826B) }, /* Cygnal Integrated Products, Inc., Fasttrax GPS demonstration module */
USB: cp210x: Add 8281 (Nanotec Plug & Drive) Signed-off-by: Tristan Bruns <tristan@tristanbruns.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-04-13 21:57:16 +00:00
{ USB_DEVICE(0x10C4, 0x8281) }, /* Nanotec Plug & Drive */
USB: cp210x: fix typo, Telegesys should have been Telegesis CC: David Chalmers <david.chalmers@telegesis.com> Reported-by: Xavier Carcelle <xavier.carcelle@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-10 09:17:33 +00:00
{ USB_DEVICE(0x10C4, 0x8293) }, /* Telegesis ETRX2USB */
USB: serial: cp210x: add CESINEL device ids Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara <cabl@cesinel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-18 08:24:03 +00:00
{ USB_DEVICE(0x10C4, 0x82EF) }, /* CESINEL FALCO 6105 AC Power Supply */
{ USB_DEVICE(0x10C4, 0x82F1) }, /* CESINEL MEDCAL EFD Earth Fault Detector */
{ USB_DEVICE(0x10C4, 0x82F2) }, /* CESINEL MEDCAL ST Network Analyzer */
USB: serial: cp210x: add Straizona Focusers device ids Adding VID:PID for Straizona Focusers to cp210x driver. Signed-off-by: Jasem Mutlaq <mutlaqja@ikarustech.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-04-19 07:38:27 +00:00
{ USB_DEVICE(0x10C4, 0x82F4) }, /* Starizona MicroTouch */
USB: CP210X Add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:52:31 +00:00
{ USB_DEVICE(0x10C4, 0x82F9) }, /* Procyon AVS */
USB: SERIAL CP2101 add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-04 20:28:21 +00:00
{ USB_DEVICE(0x10C4, 0x8341) }, /* Siemens MC35PU GPRS Modem */
USB: CP210x Add new device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-12 20:52:33 +00:00
{ USB_DEVICE(0x10C4, 0x8382) }, /* Cygnal Integrated Products, Inc. */
USB: CP2101 Add device ID for AMB2560 This patch adds the device vendor and product IDs for Amber Wireless AMB2560 Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-09 20:17:54 +00:00
{ USB_DEVICE(0x10C4, 0x83A8) }, /* Amber Wireless AMB2560 */
usb-serial: cp201x: support Mark-10 digital force gauge 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: Joel Jennings <joel.jennings@makeitlabs.com> Cc: stable <stable@vger.kernel.org> Acked-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-18 09:21:19 +00:00
{ USB_DEVICE(0x10C4, 0x83AA) }, /* Mark-10 Digital Force Gauge */
USB: CP210x Add two device IDs Device Ids added for IRZ Automation Teleport SG-10 GSM/GPRS Modem and DekTec DTA Plus VHF/UHF Booster/Attenuator. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-01-02 21:51:46 +00:00
{ USB_DEVICE(0x10C4, 0x83D8) }, /* DekTec DTA Plus VHF/UHF Booster/Attenuator */
USB: CP210x Add new device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-12 20:52:33 +00:00
{ USB_DEVICE(0x10C4, 0x8411) }, /* Kyocera GPS Module */
USB: CP210x Add two device IDs Device Ids added for IRZ Automation Teleport SG-10 GSM/GPRS Modem and DekTec DTA Plus VHF/UHF Booster/Attenuator. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-01-02 21:51:46 +00:00
{ USB_DEVICE(0x10C4, 0x8418) }, /* IRZ Automation Teleport SG-10 GSM/GPRS Modem */
USB: CP2101 New Device ID One new device ID for CP2101 driver. Signed-off-by: Alex Stephens alex@miranova.com
2009-03-17 00:06:19 +00:00
{ USB_DEVICE(0x10C4, 0x846E) }, /* BEI USB Sensor Interface (VCP) */
USB: serial: cp210x: Add ID for a Juniper console Signed-off-by: Kyle Jones <kyle@kf5jwc.us> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-23 18:28:37 +00:00
{ USB_DEVICE(0x10C4, 0x8470) }, /* Juniper Networks BX Series System Console */
USB: CP210x Add new device ID New device ID added for Balluff RFID reader. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-23 19:50:57 +00:00
{ USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */
USB: serial: cp210x: add Straizona Focusers device ids Adding VID:PID for Straizona Focusers to cp210x driver. Signed-off-by: Jasem Mutlaq <mutlaqja@ikarustech.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-04-19 07:38:27 +00:00
{ USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */
USB: serial: cp210x: add CESINEL device ids Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara <cabl@cesinel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-18 08:24:03 +00:00
{ USB_DEVICE(0x10C4, 0x851E) }, /* CESINEL MEDCAL PT Network Analyzer */
USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ Add IDs for the OneTouch Verio IQ that comes with an embedded USB-to-serial converter. Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-12-29 09:54:25 +00:00
{ USB_DEVICE(0x10C4, 0x85A7) }, /* LifeScan OneTouch Verio IQ */
USB: serial: cp210x: add CESINEL device ids Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara <cabl@cesinel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-18 08:24:03 +00:00
{ USB_DEVICE(0x10C4, 0x85B8) }, /* CESINEL ReCon T Energy Logger */
USB: CP210x Add 4 Device IDs for AC-Services Devices This patch adds 4 device IDs for CP2102 based devices manufactured by AC-Services. See http://www.ac-services.eu for further info. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-20 13:51:13 +00:00
{ USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */
{ USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */
USB: cp210x: add Virtenio Preon32 device id Cc: stable <stable@vger.kernel.org> Signed-off-by: Markus Becker <mab@comnets.uni-bremen.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-22 08:41:23 +00:00
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
USB: CP210x Add 4 Device IDs for AC-Services Devices This patch adds 4 device IDs for CP2102 based devices manufactured by AC-Services. See http://www.ac-services.eu for further info. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-20 13:51:13 +00:00
{ USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */
{ USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */
USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks devices. Signed-off-by: David Peterson <david.peterson@cel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-01-06 15:00:52 +00:00
{ USB_DEVICE(0x10C4, 0x8856) }, /* CEL EM357 ZigBee USB Stick - LR */
{ USB_DEVICE(0x10C4, 0x8857) }, /* CEL EM357 ZigBee USB Stick */
USB: cp210x: add MMB and PI ZigBee USB Device Support Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB devices using customized Silicon Labs' CP210x.c USB to UART bridge drivers with PIDs: 88A4, 88A5. Signed-off-by: Sami Rahman <sami.rahman@mmbresearch.com> Tested-by: Sami Rahman <sami.rahman@mmbresearch.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-08 18:28:55 +00:00
{ USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
{ USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB Device */
USB: serial: cp210x: add ID for Acuity Brands nLight Air Adapter IDs of nLight Air Adapter, Acuity Brands, Inc.: vid: 10c4 pid: 88d8 Signed-off-by: Karan Singhal <karan.singhal@acuitybrands.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2021-02-16 16:03:10 +00:00
{ USB_DEVICE(0x10C4, 0x88D8) }, /* Acuity Brands nLight Air Adapter */
USB: serial: cp210x: add CESINEL device ids Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara <cabl@cesinel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-18 08:24:03 +00:00
{ USB_DEVICE(0x10C4, 0x88FB) }, /* CESINEL MEDCAL STII Network Analyzer */
{ USB_DEVICE(0x10C4, 0x8938) }, /* CESINEL MEDCAL S II Network Analyzer */
USB: serial: cp210x: added Ketra N1 wireless interface support Added support for Ketra N1 wireless interface, which uses the Silicon Labs' CP2104 USB to UART bridge with customized PID 8946. Signed-off-by: Joe Savage <joe.savage@goketra.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2014-09-20 13:01:16 +00:00
{ USB_DEVICE(0x10C4, 0x8946) }, /* Ketra N1 Wireless Interface */
USB: serial: cp210x: add ID for the Zone DPMX The BRIM Brothers Zone DPMX is a bicycle powermeter. This ID is for the USB serial interface in its charging dock for the control pods, via which some settings for the pods can be modified. Signed-off-by: Paul Jakma <paul@jakma.org> Cc: Barry Redmond <barry@brimbrothers.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-11-16 10:13:49 +00:00
{ USB_DEVICE(0x10C4, 0x8962) }, /* Brim Brothers charging dock */
USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks devices. Signed-off-by: David Peterson <david.peterson@cel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-01-06 15:00:52 +00:00
{ USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
USB: cp210x: add ID for KCF Technologies PRN device Added the USB serial console device ID for KCF Technologies PRN device which has a USB port for its serial console. Signed-off-by: Mark Edwards <sonofaforester@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-04-14 12:52:34 +00:00
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
USB: serial: cp210x: add CESINEL device ids Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara <cabl@cesinel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-18 08:24:03 +00:00
{ USB_DEVICE(0x10C4, 0x89A4) }, /* CESINEL FTBC Flexible Thyristor Bridge Controller */
USB: serial: cp210x: add another USB ID for Qivicon ZigBee stick There are two versions of the Qivicon Zigbee stick in circulation. This adds the second USB ID to the cp210x driver. Signed-off-by: Olli Salonen <olli.salonen@iki.fi> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-07-04 11:07:42 +00:00
{ USB_DEVICE(0x10C4, 0x89FB) }, /* Qivicon ZigBee USB Radio Stick */
USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle Added the USB serial device ID for the HubZ dual ZigBee and Z-Wave radio dongle. Signed-off-by: John D. Blair <johnb@candicontrols.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-06-04 20:18:19 +00:00
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick 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>
2021-07-21 16:17:45 +00:00
{ USB_DEVICE(0x10C4, 0x8A5B) }, /* CEL EM3588 ZigBee USB Stick */
USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick Added the USB serial device ID for the CEL ZigBee EM3588 radio stick. Signed-off-by: Jeremie Rapin <rapinj@gmail.com> Cc: stable <stable@vger.kernel.org> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-28 16:23:25 +00:00
{ USB_DEVICE(0x10C4, 0x8A5E) }, /* CEL EM3588 ZigBee USB Stick Long Range */
USB: serial: cp210x: add support for Qivicon USB ZigBee dongle The German Telekom offers a ZigBee USB Stick under the brand name Qivicon for their SmartHome Home Base in its 1. Generation. The productId is not known by the according kernel module, this patch adds support for it. Signed-off-by: Stefan Triller <github@stefantriller.de> Reviewed-by: Frans Klaver <fransklaver@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-06-30 12:44:03 +00:00
{ USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick */
[PATCH] USB: cp2101 Add new device IDs The attached patch adds four new device IDs for the CP2101 driver. Also 3 tab characters have been removed from device ID table. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-20 00:06:19 +00:00
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
USB-SERIAL:cp2101 Add new device ID This patch adds device ID 0xEA61. This is another factory default ID used by SILabs. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-12 21:09:56 +00:00
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
USB: serial: cp210x: add Silicon Labs IDs for Windows Update 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: Karoly Pados <pados@pados.hu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-09 11:26:08 +00:00
{ USB_DEVICE(0x10C4, 0xEA63) }, /* Silicon Labs Windows Update (CP2101-4/CP2102N) */
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
USB: CP210x New Device IDs 11 New device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-15 12:36:38 +00:00
{ USB_DEVICE(0x10C4, 0xEA71) }, /* Infinity GPS-MIC-1 Radio Monophone */
USB: serial: cp210x: add Silicon Labs IDs for Windows Update 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: Karoly Pados <pados@pados.hu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-09 11:26:08 +00:00
{ USB_DEVICE(0x10C4, 0xEA7A) }, /* Silicon Labs Windows Update (CP2105) */
{ USB_DEVICE(0x10C4, 0xEA7B) }, /* Silicon Labs Windows Update (CP2108) */
USB: CP2101 New Device IDs Six new device IDs for CP2101 driver. Cc: stable <stable@kernel.org> Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-01-03 12:45:59 +00:00
{ USB_DEVICE(0x10C4, 0xF001) }, /* Elan Digital Systems USBscope50 */
{ USB_DEVICE(0x10C4, 0xF002) }, /* Elan Digital Systems USBwave12 */
{ USB_DEVICE(0x10C4, 0xF003) }, /* Elan Digital Systems USBpulse100 */
{ USB_DEVICE(0x10C4, 0xF004) }, /* Elan Digital Systems USBcount50 */
USB: another id for cp2101 driver This patch adds another usb id to the cp2101. It seems to work well. Please apply, thanks. Signed-off-by: Pozsar Balazs <pozsy@uhulinux.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-16 11:47:49 +00:00
{ USB_DEVICE(0x10C5, 0xEA61) }, /* Silicon Labs MobiData GPRS USB Modem */
USB: CP210X Add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:52:31 +00:00
{ USB_DEVICE(0x10CE, 0xEA6A) }, /* Silicon Labs MobiData GPRS USB Modem 100EU */
USB: serial: cp210x: add ID for Link ECU The Link ECU is an aftermarket ECU computer for vehicles that provides full tuning abilities as well as datalogging and displaying capabilities via the USB to Serial adapter built into the device. Signed-off-by: Mike Manning <michael@bsch.com.au> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-04-18 12:13:23 +00:00
{ USB_DEVICE(0x12B8, 0xEC60) }, /* Link G4 ECU */
{ USB_DEVICE(0x12B8, 0xEC62) }, /* Link G4+ ECU */
Add Baltech Reader ID to CP2101 driver this patch adds the Baltech Reader ID to the list of USB IDs in the CP2101 driver. From: Johannes Hoelzl <johannes.hoelzl@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-02 15:54:27 +00:00
{ USB_DEVICE(0x13AD, 0x9999) }, /* Baltech card reader */
USB: CP210X Add device IDs Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:52:31 +00:00
{ USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */
USB: serial: cp210x: add ELDAT Easywave RX09 id Add device id for ELDAT Easywave RX09 tranceiver. Reported-by: Jan Jansen <nattelip@hotmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-06 08:32:43 +00:00
{ USB_DEVICE(0x155A, 0x1006) }, /* ELDAT Easywave RX09 */
USB: CP210x Add 10 Device IDs This patch adds 10 device IDs for CP210x based devices from the following manufacturers: Timewave Clipsal Festo Link Instruments Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-26 22:20:04 +00:00
{ USB_DEVICE(0x166A, 0x0201) }, /* Clipsal 5500PACA C-Bus Pascal Automation Controller */
{ USB_DEVICE(0x166A, 0x0301) }, /* Clipsal 5800PC C-Bus Wireless PC Interface */
USB: CP2101 New Device IDs Six new device IDs for CP2101 driver. Cc: stable <stable@kernel.org> Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-01-03 12:45:59 +00:00
{ USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface */
USB: CP210x Add 10 Device IDs This patch adds 10 device IDs for CP210x based devices from the following manufacturers: Timewave Clipsal Festo Link Instruments Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-26 22:20:04 +00:00
{ USB_DEVICE(0x166A, 0x0304) }, /* Clipsal 5000CT2 C-Bus Black and White Touchscreen */
{ USB_DEVICE(0x166A, 0x0305) }, /* Clipsal C-5000CT2 C-Bus Spectrum Colour Touchscreen */
{ USB_DEVICE(0x166A, 0x0401) }, /* Clipsal L51xx C-Bus Architectural Dimmer */
{ USB_DEVICE(0x166A, 0x0101) }, /* Clipsal 5560884 C-Bus Multi-room Audio Matrix Switcher */
USB: serial: cp210x: Adding Seletek device id's These device ID's are not associated with the cp210x module currently, but should be. This patch allows the devices to operate upon connecting them to the usb bus as intended. Signed-off-by: Michiel van de Garde <mgparser@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-02-27 01:08:29 +00:00
{ USB_DEVICE(0x16C0, 0x09B0) }, /* Lunatico Seletek */
{ USB_DEVICE(0x16C0, 0x09B1) }, /* Lunatico Seletek */
[PATCH] USB: cp2101.c: Jablotron usb serial interface identification Jablotron usb serial interface identification Signed-off-by: Josef Balatka <balatka@email.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-17 17:47:24 +00:00
{ USB_DEVICE(0x16D6, 0x0001) }, /* Jablotron serial interface */
USB: cp210x: Add four new device IDs Signed-off-by: Alessio Igor Bogani <abogani@texware.it> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-07-27 21:05:14 +00:00
{ USB_DEVICE(0x16DC, 0x0010) }, /* W-IE-NE-R Plein & Baus GmbH PL512 Power Supply */
{ USB_DEVICE(0x16DC, 0x0011) }, /* W-IE-NE-R Plein & Baus GmbH RCM Remote Control for MARATON Power Supply */
{ USB_DEVICE(0x16DC, 0x0012) }, /* W-IE-NE-R Plein & Baus GmbH MPOD Multi Channel Power Supply */
{ USB_DEVICE(0x16DC, 0x0015) }, /* W-IE-NE-R Plein & Baus GmbH CML Control, Monitoring and Data Logger */
USB: Added Kamstrup VID/PIDs to cp210x serial driver. Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-21 22:41:37 +00:00
{ USB_DEVICE(0x17A8, 0x0001) }, /* Kamstrup Optical Eye/3-wire */
{ USB_DEVICE(0x17A8, 0x0005) }, /* Kamstrup M-Bus Master MultiPort 250D */
USB: CP210x Add new device ID New device ID added for Balluff RFID reader. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-23 19:50:57 +00:00
{ USB_DEVICE(0x17F4, 0xAAAA) }, /* Wavesense Jazz blood glucose meter */
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
USB: cp210x: add ID for ELV Marble Sound Board 1 Add the USB device ID for ELV Marble Sound Board 1. Signed-off-by: Oliver Freyermuth <o.freyermuth@googlemail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-12-28 17:37:38 +00:00
{ USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */
USB: serial: cp210x: add new device ID ELV ALC 8xxx This adds the ELV ALC 8xxx Battery Charging device to the list of USB IDs of drivers/usb/serial/cp210x.c Signed-off-by: Christian Holl <cyborgx1@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-01-03 18:53:02 +00:00
{ USB_DEVICE(0x18EF, 0xE030) }, /* ELV ALC 8xxx Battery Charger */
USB: serial: cp210x: add support for ELV TFD500 Add the USB device id for the ELV TFD500 data logger. Signed-off-by: Andreas Engel <anen-nospam@gmx.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-09-18 19:11:57 +00:00
{ USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */
USB: cp210x: add IDs for GE B650V3 and B850V3 boards Add USB ID for cp2104/5 devices on GE B650v3 and B850v3 boards. Signed-off-by: Ken Lin <ken.lin@advantech.com.tw> Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-01 19:57:25 +00:00
{ USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */
{ USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */
USB: serial: cp210x: Adding GE Healthcare Device ID The CP2105 is used in the GE Healthcare Remote Alarm Box, with the Manufacturer ID of 0x1901 and Product ID of 0x0194. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-03-29 16:47:29 +00:00
{ USB_DEVICE(0x1901, 0x0194) }, /* GE Healthcare Remote Alarm Box */
USB: serial: cp210x: add new IDs for GE Bx50v3 boards Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design change. Signed-off-by: Ken Lin <yungching0725@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-02-03 20:00:24 +00:00
{ USB_DEVICE(0x1901, 0x0195) }, /* GE B850/B650/B450 CP2104 DP UART interface */
{ USB_DEVICE(0x1901, 0x0196) }, /* GE B850 CP2105 DP UART interface */
USB: serial: cp210x: fix comments for GE CS1000 Fix comments for GE CS1000 CP210x USB ID assignments. Fixes: 42213a0190b5 ("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>
2021-07-19 16:43:49 +00:00
{ USB_DEVICE(0x1901, 0x0197) }, /* GE CS1000 M.2 Key E serial interface */
{ USB_DEVICE(0x1901, 0x0198) }, /* GE CS1000 Display serial interface */
USB: serial: cp210x: add pid/vid for WSDA-200-USB 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>
2021-01-25 09:26:54 +00:00
{ USB_DEVICE(0x199B, 0xBA30) }, /* LORD WSDA-200-USB */
USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder The Parrot NMEA GPS Flight Recorder is a USB composite device consisting of hub, flash storage, and cp210x usb to serial chip. It is an accessory to the mass-produced Parrot AR Drone 2. The device emits standard NMEA messages which make the it compatible with NMEA compatible software. It was tested using gpsd version 3.11-3 as an NMEA interpreter and using the official Parrot Flight Recorder. Signed-off-by: Vittorio Alfieri <vittorio88@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 13:40:24 +00:00
{ USB_DEVICE(0x19CF, 0x3000) }, /* Parrot NMEA GPS Flight Recorder */
usb: cp210x support SEL C662 Vendor/Device This patch adds support for the Schweitzer Engineering Laboratories C662 USB cable based off the CP210x driver. Signed-off-by: Barry Grussling <barry@grussling.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-19 21:46:12 +00:00
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
USB: cp210x: add support for Corsair usb dongle Corsair USB Dongles are shipped with Corsair AXi series PSUs. These are cp210x serial usb devices, so make driver detect these. I have a program, that can get information from these PSUs. Tested with 2 different dongles shipped with Corsair AX860i and AX1200i units. Signed-off-by: Andras Kovacs <andras@sth.sze.hu> Cc: <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2014-06-27 12:50:11 +00:00
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
USB: serial: cp210x: add Silicon Labs 358x VID and PID Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now connect to host PCs over a USB serial link. Signed-off-by: Nathaniel Ting <nathaniel.ting@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2014-10-03 16:01:20 +00:00
{ USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default */
USB: cp210x: Add WAGO 750-923 Service Cable device ID The WAGO 750-923 USB Service Cable is used for configuration and firmware updates of several industrial automation products from WAGO Kontakttechnik GmbH. Bus 004 Device 002: ID 1be3:07a6 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1be3 idProduct 0x07a6 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 WAGO USB Service Cable iSerial 3 1277796751 . . . Signed-off-by: Anders Larsen <al@alarsen.net> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-06 21:46:25 +00:00
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
USB: cp210x: add support for Seluxit USB dongle Added the Seluxit ApS USB Serial Dongle to cp210x driver. Signed-off-by: Andreas Bomholtz <andreas@seluxit.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2014-09-22 07:50:43 +00:00
{ USB_DEVICE(0x1D6F, 0x0010) }, /* Seluxit ApS RF Dongle */
USB: CP210x Add 10 Device IDs This patch adds 10 device IDs for CP210x based devices from the following manufacturers: Timewave Clipsal Festo Link Instruments Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-26 22:20:04 +00:00
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
usb: cp210x new Vendor/Device IDs This patch adds support for the Lake Shore Cryotronics devices to the CP210x driver. These lines are ported from cp210x driver distributed by Lake Shore web site: http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz and licensed under the terms of GPLv2. Moreover, I've tested this changes with Lake Shore 335 in my labs. Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-09 09:57:32 +00:00
{ USB_DEVICE(0x1FB9, 0x0100) }, /* Lake Shore Model 121 Current Source */
{ USB_DEVICE(0x1FB9, 0x0200) }, /* Lake Shore Model 218A Temperature Monitor */
{ USB_DEVICE(0x1FB9, 0x0201) }, /* Lake Shore Model 219 Temperature Monitor */
{ USB_DEVICE(0x1FB9, 0x0202) }, /* Lake Shore Model 233 Temperature Transmitter */
{ USB_DEVICE(0x1FB9, 0x0203) }, /* Lake Shore Model 235 Temperature Transmitter */
{ USB_DEVICE(0x1FB9, 0x0300) }, /* Lake Shore Model 335 Temperature Controller */
{ USB_DEVICE(0x1FB9, 0x0301) }, /* Lake Shore Model 336 Temperature Controller */
{ USB_DEVICE(0x1FB9, 0x0302) }, /* Lake Shore Model 350 Temperature Controller */
{ USB_DEVICE(0x1FB9, 0x0303) }, /* Lake Shore Model 371 AC Bridge */
{ USB_DEVICE(0x1FB9, 0x0400) }, /* Lake Shore Model 411 Handheld Gaussmeter */
{ USB_DEVICE(0x1FB9, 0x0401) }, /* Lake Shore Model 425 Gaussmeter */
{ USB_DEVICE(0x1FB9, 0x0402) }, /* Lake Shore Model 455A Gaussmeter */
{ USB_DEVICE(0x1FB9, 0x0403) }, /* Lake Shore Model 475A Gaussmeter */
{ USB_DEVICE(0x1FB9, 0x0404) }, /* Lake Shore Model 465 Three Axis Gaussmeter */
{ USB_DEVICE(0x1FB9, 0x0600) }, /* Lake Shore Model 625A Superconducting MPS */
{ USB_DEVICE(0x1FB9, 0x0601) }, /* Lake Shore Model 642A Magnet Power Supply */
{ USB_DEVICE(0x1FB9, 0x0602) }, /* Lake Shore Model 648 Magnet Power Supply */
{ USB_DEVICE(0x1FB9, 0x0700) }, /* Lake Shore Model 737 VSM Controller */
{ USB_DEVICE(0x1FB9, 0x0701) }, /* Lake Shore Model 776 Hall Matrix */
USB: cp210x: add ID for Aruba Networks controllers Add the USB serial console device ID for Aruba Networks 7xxx series controllers which have a USB port for their serial console. Signed-off-by: Peter Sanford <peter@sanford.io> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-06-26 00:40:05 +00:00
{ USB_DEVICE(0x2626, 0xEA60) }, /* Aruba Networks 7xxx USB Serial Console */
USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19 This device is a Oscilloscope/Logic Analizer/Pattern Generator/TDR, using a Silabs CP2103 USB to UART Bridge. Signed-off-by: Renato Caldas <rmsc@fe.up.pt> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-06 15:20:51 +00:00
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
USB: CP210x Add 10 Device IDs This patch adds 10 device IDs for CP210x based devices from the following manufacturers: Timewave Clipsal Festo Link Instruments Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-26 22:20:04 +00:00
{ USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
USB: serial: cp210x: add ID for NI USB serial console Added the USB VID and PID for the USB serial console on some National Instruments devices. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-04-09 15:23:55 +00:00
{ USB_DEVICE(0x3923, 0x7A0B) }, /* National Instruments USB Serial Console */
USB: CP210x Add new device ID New device ID added for Balluff RFID reader. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-23 19:50:57 +00:00
{ USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
{ } /* Terminating Entry */
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
};
cp2101: coding style Bring up to coding style Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-22 10:10:17 +00:00
MODULE_DEVICE_TABLE(usb, id_table);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
struct cp210x_serial_private {
#ifdef CONFIG_GPIOLIB
struct gpio_chip gc;
USB: serial: cp210x: use bool for registered flag Use bool rather than u8 for the gpio-chip-registered flag. Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-24 09:58:12 +00:00
bool gpio_registered;
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
u16 gpio_pushpull;
u16 gpio_altfunc;
u16 gpio_input;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
#endif
u8 partnum;
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
u32 fw_version;
USB: serial: cp210x: add minimum baud rate for CP2105 SCI 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: Johanna 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: Johan Hovold <johan@kernel.org>
2019-02-06 08:56:15 +00:00
speed_t min_speed;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
speed_t max_speed;
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
bool use_actual_rate;
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
bool no_flow_control;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
};
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
enum cp210x_event_state {
ES_DATA,
ES_ESCAPE,
ES_LSR,
ES_LSR_DATA_0,
ES_LSR_DATA_1,
ES_MSR
};
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
struct cp210x_port_private {
USB: serial: cp210x: use in-kernel types in port data 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.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-13 10:55:17 +00:00
u8 bInterfaceNumber;
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
bool event_mode;
enum cp210x_event_state event_state;
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
u8 lsr;
struct mutex mutex;
bool crtscts;
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
bool dtr;
bool rts;
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
};
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
static struct usb_serial_driver cp210x_device = {
[PATCH] USB Serial: get rid of the .owner field in usb_serial_driver Don't duplicate something that's already in struct driver. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-21 04:15:16 +00:00
.driver = {
.owner = THIS_MODULE,
USB: cp210x: fix whitespace issues Fix missing and superfluous whitespace. Fix misplaced brackets. Fix indentation. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-29 09:56:19 +00:00
.name = "cp210x",
[PATCH] USB Serial: get rid of the .owner field in usb_serial_driver Don't duplicate something that's already in struct driver. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-21 04:15:16 +00:00
},
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
.id_table = id_table,
.num_ports = 1,
USB: cp210x: increase bulk-in buffer size to 256 byte The cp210x requires a bulk-in buffer larger than endpoint size to keep up at high baudrates without loosing data. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-03-17 22:00:39 +00:00
.bulk_in_size = 256,
USB: cp210x: increase the bulk-out buffer size to 256 byte Increase the bulk-out buffer size from 64 to 256 byte. This gives a significant increase in throughput already at 1Mbaud (e.g. 710 instead of 640 KB/s) as well as lowered CPU usage. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-03-17 22:00:38 +00:00
.bulk_out_size = 256,
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
.open = cp210x_open,
.close = cp210x_close,
.break_ctl = cp210x_break_ctl,
.set_termios = cp210x_set_termios,
USB: cp210x: add tx_empty() Added tx_empty callback needed for generic wait-until-sent support. Without this function, when the port is closed usbserial can't know that there are still data in the chip's transmit FIFO. The chip gets disabled and untransmitted data lost. When the actual byte count is reported by tx-empty the close can be delayed until all data are sent. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: modify tx_empty error handling ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-24 22:28:41 +00:00
.tx_empty = cp210x_tx_empty,
USB: serial: cp210x: enable usb generic throttle/unthrottle 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: Brant Merryman <brant.merryman@silabs.com> Co-developed-by: Phu Luu <phu.luu@silabs.com> Signed-off-by: Phu Luu <phu.luu@silabs.com> Link: https://lore.kernel.org/r/57401AF3-9961-461F-95E1-F8AFC2105F5E@silabs.com [ johan: fix up tags ] Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") Cc: stable <stable@vger.kernel.org> # 2.6.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2020-06-26 04:22:58 +00:00
.throttle = usb_serial_generic_throttle,
.unthrottle = usb_serial_generic_unthrottle,
USB: cp210x: fix whitespace issues Fix missing and superfluous whitespace. Fix misplaced brackets. Fix indentation. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-29 09:56:19 +00:00
.tiocmget = cp210x_tiocmget,
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
.tiocmset = cp210x_tiocmset,
USB: serial: cp210x: add support for TIOCGICOUNT 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>
2020-07-13 10:55:15 +00:00
.get_icount = usb_serial_generic_get_icount,
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
.attach = cp210x_attach,
.disconnect = cp210x_disconnect,
.release = cp210x_release,
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
.port_probe = cp210x_port_probe,
.port_remove = cp210x_port_remove,
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
.dtr_rts = cp210x_dtr_rts,
.process_read_urb = cp210x_process_read_urb,
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
};
usb-serial: use new registration API in [a-c]* drivers This patch (as1523) modifies the following usb-serial drivers to utilize the new usb_serial_{de}register_drivers() routines: aircable, ark3116, belkin_sa, ch341, cp210x, cyberjack, and cypress_m8. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-23 19:56:17 +00:00
static struct usb_serial_driver * const serial_drivers[] = {
&cp210x_device, NULL
};
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
/* Config request types */
usb: cp210x: Corrected USB request type definitions The original request types in the cp210x driver are labled as "DEVICE_TO_HOST" and "HOST_TO_DEVICE" but the actual bit definition corresponds to a request to the interface. This has been corrected, and the actual definition for the device requests have been added. Signed-off-by: Preston Fick <preston.fick@silabs.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-01 04:06:48 +00:00
#define REQTYPE_HOST_TO_INTERFACE 0x41
#define REQTYPE_INTERFACE_TO_HOST 0xc1
#define REQTYPE_HOST_TO_DEVICE 0x40
#define REQTYPE_DEVICE_TO_HOST 0xc0
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: CP210X Use official request code definitions The CP210X driver was developed without official device specifications. This has lead to an incorrect assumption that all GET request codes are equal to the corresponding SET request code +1. This patch removes this incorrect assumption, and uses request code definitions based on the updated GPL driver from SiLabs. This modification is needed before extended functionality such as GPIO on CP2103 can be supported. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:53:30 +00:00
/* Config request codes */
#define CP210X_IFC_ENABLE 0x00
#define CP210X_SET_BAUDDIV 0x01
#define CP210X_GET_BAUDDIV 0x02
#define CP210X_SET_LINE_CTL 0x03
#define CP210X_GET_LINE_CTL 0x04
#define CP210X_SET_BREAK 0x05
#define CP210X_IMM_CHAR 0x06
#define CP210X_SET_MHS 0x07
#define CP210X_GET_MDMSTS 0x08
#define CP210X_SET_XON 0x09
#define CP210X_SET_XOFF 0x0A
#define CP210X_SET_EVENTMASK 0x0B
#define CP210X_GET_EVENTMASK 0x0C
#define CP210X_SET_CHAR 0x0D
#define CP210X_GET_CHARS 0x0E
#define CP210X_GET_PROPS 0x0F
#define CP210X_GET_COMM_STATUS 0x10
#define CP210X_RESET 0x11
#define CP210X_PURGE 0x12
#define CP210X_SET_FLOW 0x13
#define CP210X_GET_FLOW 0x14
#define CP210X_EMBED_EVENTS 0x15
#define CP210X_GET_EVENTSTATE 0x16
#define CP210X_SET_CHARS 0x19
USB: cp210x: fix CP2104 baudrate usage This fix changes the way baudrates are set on the CP210x devices from Silicon Labs. The CP2101/2/3 will respond to both a GET/SET_BAUDDIV command, and GET/SET_BAUDRATE command, while CP2104 and higher devices only respond to GET/SET_BAUDRATE. The current cp210x.ko driver in kernel version 3.2.0 only implements the GET/SET_BAUDDIV command. This patch implements the two new codes for the GET/SET_BAUDRATE commands. Then there is a change in the way that the baudrate is assigned or retrieved. This is done according to the CP210x USB specification in AN571. This document can be found here: http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/AN571.pdf&src=DocumentationWebPart Sections 5.3/5.4 describe the USB packets for the old baudrate method. Sections 5.5/5.6 describe the USB packets for the new method. This patch also implements the new request scheme, and eliminates the unnecessary baudrate calculations since it uses the "actual baudrate" method. This patch solves the problem reported for the CP2104 in bug 42586, and also keeps support for all other devices (CP2101/2/3). This patchfile is also attached to the bug report on bugzilla.kernel.org. This patch has been developed and test on the 3.2.0 mainline kernel version under Ubuntu 10.11. Signed-off-by: Preston Fick <preston.fick@silabs.com> [duplicate patch also sent by Johan - gregkh] Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-17 00:14:09 +00:00
#define CP210X_GET_BAUDRATE 0x1D
#define CP210X_SET_BAUDRATE 0x1E
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
#define CP210X_VENDOR_SPECIFIC 0xFF
USB: CP210X Use official request code definitions The CP210X driver was developed without official device specifications. This has lead to an incorrect assumption that all GET request codes are equal to the corresponding SET request code +1. This patch removes this incorrect assumption, and uses request code definitions based on the updated GPL driver from SiLabs. This modification is needed before extended functionality such as GPIO on CP2103 can be supported. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:53:30 +00:00
/* CP210X_IFC_ENABLE */
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#define UART_ENABLE 0x0001
#define UART_DISABLE 0x0000
USB: CP210X Use official request code definitions The CP210X driver was developed without official device specifications. This has lead to an incorrect assumption that all GET request codes are equal to the corresponding SET request code +1. This patch removes this incorrect assumption, and uses request code definitions based on the updated GPL driver from SiLabs. This modification is needed before extended functionality such as GPIO on CP2103 can be supported. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:53:30 +00:00
/* CP210X_(SET|GET)_BAUDDIV */
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#define BAUD_RATE_GEN_FREQ 0x384000
USB: CP210X Use official request code definitions The CP210X driver was developed without official device specifications. This has lead to an incorrect assumption that all GET request codes are equal to the corresponding SET request code +1. This patch removes this incorrect assumption, and uses request code definitions based on the updated GPL driver from SiLabs. This modification is needed before extended functionality such as GPIO on CP2103 can be supported. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:53:30 +00:00
/* CP210X_(SET|GET)_LINE_CTL */
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#define BITS_DATA_MASK 0X0f00
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
#define BITS_DATA_5 0X0500
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#define BITS_DATA_6 0X0600
#define BITS_DATA_7 0X0700
#define BITS_DATA_8 0X0800
#define BITS_DATA_9 0X0900
#define BITS_PARITY_MASK 0x00f0
#define BITS_PARITY_NONE 0x0000
#define BITS_PARITY_ODD 0x0010
#define BITS_PARITY_EVEN 0x0020
#define BITS_PARITY_MARK 0x0030
#define BITS_PARITY_SPACE 0x0040
#define BITS_STOP_MASK 0x000f
#define BITS_STOP_1 0x0000
#define BITS_STOP_1_5 0x0001
#define BITS_STOP_2 0x0002
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: CP210X Use official request code definitions The CP210X driver was developed without official device specifications. This has lead to an incorrect assumption that all GET request codes are equal to the corresponding SET request code +1. This patch removes this incorrect assumption, and uses request code definitions based on the updated GPL driver from SiLabs. This modification is needed before extended functionality such as GPIO on CP2103 can be supported. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:53:30 +00:00
/* CP210X_SET_BREAK */
USB: CP210x Fix Break On/Off The definitions for BREAK_ON and BREAK_OFF are inverted, causing break requests to fail. This patch sets BREAK_ON and BREAK_OFF to the correct values. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-18 21:13:39 +00:00
#define BREAK_ON 0x0001
#define BREAK_OFF 0x0000
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: CP210X Use official request code definitions The CP210X driver was developed without official device specifications. This has lead to an incorrect assumption that all GET request codes are equal to the corresponding SET request code +1. This patch removes this incorrect assumption, and uses request code definitions based on the updated GPL driver from SiLabs. This modification is needed before extended functionality such as GPIO on CP2103 can be supported. Signed-off-by: Craig Shelley <craig@microtron.org.uk> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:53:30 +00:00
/* CP210X_(SET_MHS|GET_MDMSTS) */
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
#define CONTROL_DTR 0x0001
#define CONTROL_RTS 0x0002
#define CONTROL_CTS 0x0010
#define CONTROL_DSR 0x0020
#define CONTROL_RING 0x0040
#define CONTROL_DCD 0x0080
#define CONTROL_WRITE_DTR 0x0100
#define CONTROL_WRITE_RTS 0x0200
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
/* CP210X_(GET|SET)_CHARS */
struct cp210x_special_chars {
u8 bEofChar;
u8 bErrorChar;
u8 bBreakChar;
u8 bEventChar;
u8 bXonChar;
u8 bXoffChar;
};
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/* CP210X_VENDOR_SPECIFIC values */
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
#define CP210X_READ_2NCONFIG 0x000E
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
#define CP210X_GET_FW_VER_2N 0x0010
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
#define CP210X_READ_LATCH 0x00C2
#define CP210X_GET_PARTNUM 0x370B
#define CP210X_GET_PORTCONFIG 0x370C
#define CP210X_GET_DEVICEMODE 0x3711
#define CP210X_WRITE_LATCH 0x37E1
/* Part number definitions */
#define CP210X_PARTNUM_CP2101 0x01
#define CP210X_PARTNUM_CP2102 0x02
#define CP210X_PARTNUM_CP2103 0x03
#define CP210X_PARTNUM_CP2104 0x04
#define CP210X_PARTNUM_CP2105 0x05
#define CP210X_PARTNUM_CP2108 0x08
USB: serial: cp210x: improve baudrate support for CP2102N 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>
2018-07-18 12:24:59 +00:00
#define CP210X_PARTNUM_CP2102N_QFN28 0x20
#define CP210X_PARTNUM_CP2102N_QFN24 0x21
#define CP210X_PARTNUM_CP2102N_QFN20 0x22
USB: serial: cp210x: fix partnum regression When adding GPIO support for the cp2105, the mentioned commit by Martyn Welch introduced a query for the part number of the chip. Unfortunately the driver aborts probing when this query fails, so currently the driver can not be used with chips not supporting this query. I have a data cable for Siemens mobile phones (ID 10ab:10c5) where this is the case. With this patch the driver can be bound even if the part number can not be queried. Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105") Signed-off-by: Sebastian Frei <dr.nop@gmx.net> [ johan: amend commit message; shorten error message and demote to warning; drop unnecessary move of usb_set_serial_data() ] Cc: stable <stable@vger.kernel.org> # 4.9 Signed-off-by: Johan Hovold <johan@kernel.org>
2017-09-12 07:50:59 +00:00
#define CP210X_PARTNUM_UNKNOWN 0xFF
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
USB: cp210x: add tx_empty() Added tx_empty callback needed for generic wait-until-sent support. Without this function, when the port is closed usbserial can't know that there are still data in the chip's transmit FIFO. The chip gets disabled and untransmitted data lost. When the actual byte count is reported by tx-empty the close can be delayed until all data are sent. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: modify tx_empty error handling ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-24 22:28:41 +00:00
/* CP210X_GET_COMM_STATUS returns these 0x13 bytes */
struct cp210x_comm_status {
__le32 ulErrors;
__le32 ulHoldReasons;
__le32 ulAmountInInQueue;
__le32 ulAmountInOutQueue;
u8 bEofReceived;
u8 bWaitForImmediate;
u8 bReserved;
} __packed;
USB: cp210x: flush device queues at close Flush all device queues at close in order to work around a cp2108 Tx queue bug. Occasionally, writing data and immediately closing the port makes cp2108 stop responding. The device has to be unplugged to clear the error. The failure is induced by shutting down the device while its Tx queue still has unsent data. This condition is avoided by issuing PURGE command from the close() callback. This change is applied to all cp210x devices. Clearing internal queues on close is generally good. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: amend commit message ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:03 +00:00
/*
* CP210X_PURGE - 16 bits passed in wValue of USB request.
* SiLabs app note AN571 gives a strange description of the 4 bits:
* bit 0 or bit 2 clears the transmit queue and 1 or 3 receive.
* writing 1 to all, however, purges cp2108 well enough to avoid the hang.
*/
#define PURGE_ALL 0x000f
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
/* CP210X_EMBED_EVENTS */
#define CP210X_ESCCHAR 0xec
#define CP210X_LSR_OVERRUN BIT(1)
#define CP210X_LSR_PARITY BIT(2)
#define CP210X_LSR_FRAME BIT(3)
#define CP210X_LSR_BREAK BIT(4)
USB: serial: cp210x: get rid of magic numbers in CRTSCTS flag code Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-05-04 21:57:02 +00:00
/* CP210X_GET_FLOW/CP210X_SET_FLOW read/write these 0x10 bytes */
struct cp210x_flow_ctl {
__le32 ulControlHandshake;
__le32 ulFlowReplace;
__le32 ulXonLimit;
__le32 ulXoffLimit;
USB: serial: cp210x: drop unnecessary packed attributes Drop unnecessary packed attributes from structs without padding. Link: https://lore.kernel.org/r/20200713105517.27796-5-johan@kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-13 10:55:16 +00:00
};
USB: serial: cp210x: get rid of magic numbers in CRTSCTS flag code Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-05-04 21:57:02 +00:00
/* cp210x_flow_ctl::ulControlHandshake */
#define CP210X_SERIAL_DTR_MASK GENMASK(1, 0)
USB: serial: cp210x: drop shift macros 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>
2021-01-25 13:48:13 +00:00
#define CP210X_SERIAL_DTR_INACTIVE (0 << 0)
#define CP210X_SERIAL_DTR_ACTIVE (1 << 0)
#define CP210X_SERIAL_DTR_FLOW_CTL (2 << 0)
USB: serial: cp210x: get rid of magic numbers in CRTSCTS flag code Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-05-04 21:57:02 +00:00
#define CP210X_SERIAL_CTS_HANDSHAKE BIT(3)
#define CP210X_SERIAL_DSR_HANDSHAKE BIT(4)
#define CP210X_SERIAL_DCD_HANDSHAKE BIT(5)
#define CP210X_SERIAL_DSR_SENSITIVITY BIT(6)
/* cp210x_flow_ctl::ulFlowReplace */
#define CP210X_SERIAL_AUTO_TRANSMIT BIT(0)
#define CP210X_SERIAL_AUTO_RECEIVE BIT(1)
#define CP210X_SERIAL_ERROR_CHAR BIT(2)
#define CP210X_SERIAL_NULL_STRIPPING BIT(3)
#define CP210X_SERIAL_BREAK_CHAR BIT(4)
#define CP210X_SERIAL_RTS_MASK GENMASK(7, 6)
USB: serial: cp210x: drop shift macros 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>
2021-01-25 13:48:13 +00:00
#define CP210X_SERIAL_RTS_INACTIVE (0 << 6)
#define CP210X_SERIAL_RTS_ACTIVE (1 << 6)
#define CP210X_SERIAL_RTS_FLOW_CTL (2 << 6)
USB: serial: cp210x: get rid of magic numbers in CRTSCTS flag code Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-05-04 21:57:02 +00:00
#define CP210X_SERIAL_XOFF_CONTINUE BIT(31)
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/* CP210X_VENDOR_SPECIFIC, CP210X_GET_DEVICEMODE call reads these 0x2 bytes. */
struct cp210x_pin_mode {
u8 eci;
u8 sci;
USB: serial: cp210x: drop unnecessary packed attributes Drop unnecessary packed attributes from structs without padding. Link: https://lore.kernel.org/r/20200713105517.27796-5-johan@kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-13 10:55:16 +00:00
};
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
#define CP210X_PIN_MODE_MODEM 0
#define CP210X_PIN_MODE_GPIO BIT(0)
/*
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
* CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0xf bytes
* on a CP2105 chip. Structure needs padding due to unused/unspecified bytes.
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
*/
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
struct cp210x_dual_port_config {
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
__le16 gpio_mode;
u8 __pad0[2];
__le16 reset_state;
u8 __pad1[4];
__le16 suspend_state;
u8 sci_cfg;
u8 eci_cfg;
u8 device_cfg;
} __packed;
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
/*
* CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0xd bytes
* on a CP2104 chip. Structure needs padding due to unused/unspecified bytes.
*/
struct cp210x_single_port_config {
__le16 gpio_mode;
u8 __pad0[2];
__le16 reset_state;
u8 __pad1[4];
__le16 suspend_state;
u8 device_cfg;
} __packed;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/* GPIO modes */
#define CP210X_SCI_GPIO_MODE_OFFSET 9
#define CP210X_SCI_GPIO_MODE_MASK GENMASK(11, 9)
#define CP210X_ECI_GPIO_MODE_OFFSET 2
#define CP210X_ECI_GPIO_MODE_MASK GENMASK(3, 2)
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
#define CP210X_GPIO_MODE_OFFSET 8
#define CP210X_GPIO_MODE_MASK GENMASK(11, 8)
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/* CP2105 port configuration values */
#define CP2105_GPIO0_TXLED_MODE BIT(0)
#define CP2105_GPIO1_RXLED_MODE BIT(1)
#define CP2105_GPIO1_RS485_MODE BIT(2)
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
/* CP2104 port configuration values */
#define CP2104_GPIO0_TXLED_MODE BIT(0)
#define CP2104_GPIO1_RXLED_MODE BIT(1)
#define CP2104_GPIO2_RS485_MODE BIT(2)
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
struct cp210x_quad_port_state {
__le16 gpio_mode_pb0;
__le16 gpio_mode_pb1;
__le16 gpio_mode_pb2;
__le16 gpio_mode_pb3;
__le16 gpio_mode_pb4;
__le16 gpio_lowpower_pb0;
__le16 gpio_lowpower_pb1;
__le16 gpio_lowpower_pb2;
__le16 gpio_lowpower_pb3;
__le16 gpio_lowpower_pb4;
__le16 gpio_latch_pb0;
__le16 gpio_latch_pb1;
__le16 gpio_latch_pb2;
__le16 gpio_latch_pb3;
__le16 gpio_latch_pb4;
};
/*
* CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0x49 bytes
* on a CP2108 chip.
*
* See https://www.silabs.com/documents/public/application-notes/an978-cp210x-usb-to-uart-api-specification.pdf
*/
struct cp210x_quad_port_config {
struct cp210x_quad_port_state reset_state;
struct cp210x_quad_port_state suspend_state;
u8 ipdelay_ifc[4];
u8 enhancedfxn_ifc[4];
u8 enhancedfxn_device;
u8 extclkfreq[4];
} __packed;
#define CP2108_EF_IFC_GPIO_TXLED 0x01
#define CP2108_EF_IFC_GPIO_RXLED 0x02
#define CP2108_EF_IFC_GPIO_RS485 0x04
#define CP2108_EF_IFC_GPIO_RS485_LOGIC 0x08
#define CP2108_EF_IFC_GPIO_CLOCK 0x10
#define CP2108_EF_IFC_DYNAMIC_SUSPEND 0x40
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
/* CP2102N configuration array indices */
#define CP210X_2NCONFIG_CONFIG_VERSION_IDX 2
#define CP210X_2NCONFIG_GPIO_MODE_IDX 581
#define CP210X_2NCONFIG_GPIO_RSTLATCH_IDX 587
#define CP210X_2NCONFIG_GPIO_CONTROL_IDX 600
USB: serial: cp210x: fix alternate function for CP2102N QFN20 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: c8acfe0aadbe ("USB: serial: cp210x: implement GPIO support for CP2102N") Cc: stable@vger.kernel.org # 4.19 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-05-28 20:39:31 +00:00
/* CP2102N QFN20 port configuration values */
#define CP2102N_QFN20_GPIO2_TXLED_MODE BIT(2)
#define CP2102N_QFN20_GPIO3_RXLED_MODE BIT(3)
#define CP2102N_QFN20_GPIO1_RS485_MODE BIT(4)
#define CP2102N_QFN20_GPIO0_CLK_MODE BIT(6)
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
/*
* CP210X_VENDOR_SPECIFIC, CP210X_WRITE_LATCH call writes these 0x02 bytes
* for CP2102N, CP2103, CP2104 and CP2105.
*/
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
struct cp210x_gpio_write {
u8 mask;
u8 state;
USB: serial: cp210x: drop unnecessary packed attributes Drop unnecessary packed attributes from structs without padding. Link: https://lore.kernel.org/r/20200713105517.27796-5-johan@kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-13 10:55:16 +00:00
};
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
/*
* CP210X_VENDOR_SPECIFIC, CP210X_WRITE_LATCH call writes these 0x04 bytes
* for CP2108.
*/
struct cp210x_gpio_write16 {
__le16 mask;
__le16 state;
};
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/*
* Helper to get interface number when we only have struct usb_serial.
*/
static u8 cp210x_interface_num(struct usb_serial *serial)
{
struct usb_host_interface *cur_altsetting;
cur_altsetting = serial->interface->cur_altsetting;
return cur_altsetting->desc.bInterfaceNumber;
}
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
/*
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
* Reads a variable-sized block of CP210X_ registers, identified by req.
* Returns data into buf in native USB byte order.
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
*/
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
static int cp210x_read_reg_block(struct usb_serial_port *port, u8 req,
void *buf, int bufsize)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
struct usb_serial *serial = port->serial;
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
void *dmabuf;
int result;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
dmabuf = kmalloc(bufsize, GFP_KERNEL);
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
if (!dmabuf)
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
return -ENOMEM;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
cp2101: coding style Bring up to coding style Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-22 10:10:17 +00:00
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
req, REQTYPE_INTERFACE_TO_HOST, 0,
port_priv->bInterfaceNumber, dmabuf, bufsize,
USB_CTRL_SET_TIMEOUT);
if (result == bufsize) {
memcpy(buf, dmabuf, bufsize);
result = 0;
} else {
dev_err(&port->dev, "failed get req 0x%x size %d status: %d\n",
req, bufsize, result);
if (result >= 0)
USB: serial: cp210x: return -EIO on short control transfers Return -EIO on short control transfers rather than -EPROTO which is used for lower-level transfer errors. Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-19 13:46:39 +00:00
result = -EIO;
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
kfree(dmabuf);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
return result;
}
USB: cp210x: forward USB errors to USB serial core Make sure we forward all error codes (e.g. ENOMEM) to USB serial core. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-10 13:58:29 +00:00
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
/*
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
* Reads any 8-bit CP210X_ register identified by req.
*/
static int cp210x_read_u8_reg(struct usb_serial_port *port, u8 req, u8 *val)
{
return cp210x_read_reg_block(port, req, val, sizeof(*val));
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/*
* Reads a variable-sized vendor block of CP210X_ registers, identified by val.
* Returns data into buf in native USB byte order.
*/
static int cp210x_read_vendor_block(struct usb_serial *serial, u8 type, u16 val,
void *buf, int bufsize)
{
void *dmabuf;
int result;
dmabuf = kmalloc(bufsize, GFP_KERNEL);
if (!dmabuf)
return -ENOMEM;
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
CP210X_VENDOR_SPECIFIC, type, val,
cp210x_interface_num(serial), dmabuf, bufsize,
USB_CTRL_GET_TIMEOUT);
if (result == bufsize) {
memcpy(buf, dmabuf, bufsize);
result = 0;
} else {
dev_err(&serial->interface->dev,
"failed to get vendor val 0x%04x size %d: %d\n", val,
bufsize, result);
if (result >= 0)
result = -EIO;
}
kfree(dmabuf);
return result;
}
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
/*
* Writes any 16-bit CP210X_ register (req) whose value is passed
* entirely in the wValue field of the USB request.
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
*/
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
static int cp210x_write_u16_reg(struct usb_serial_port *port, u8 req, u16 val)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
struct usb_serial *serial = port->serial;
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
int result;
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
req, REQTYPE_HOST_TO_INTERFACE, val,
port_priv->bInterfaceNumber, NULL, 0,
USB_CTRL_SET_TIMEOUT);
if (result < 0) {
dev_err(&port->dev, "failed set request 0x%x status: %d\n",
req, result);
}
return result;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
/*
* Writes a variable-sized block of CP210X_ registers, identified by req.
* Data in buf must be in native USB byte order.
*/
static int cp210x_write_reg_block(struct usb_serial_port *port, u8 req,
void *buf, int bufsize)
{
struct usb_serial *serial = port->serial;
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
void *dmabuf;
int result;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: use kmemdup Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-05-19 14:04:36 +00:00
dmabuf = kmemdup(buf, bufsize, GFP_KERNEL);
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
if (!dmabuf)
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
return -ENOMEM;
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
req, REQTYPE_HOST_TO_INTERFACE, 0,
port_priv->bInterfaceNumber, dmabuf, bufsize,
USB_CTRL_SET_TIMEOUT);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
kfree(dmabuf);
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: drop short control-transfer checks 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>
2021-01-18 11:13:29 +00:00
if (result < 0) {
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
dev_err(&port->dev, "failed set req 0x%x size %d status: %d\n",
req, bufsize, result);
USB: serial: cp210x: drop short control-transfer checks 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>
2021-01-18 11:13:29 +00:00
return result;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: drop short control-transfer checks 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>
2021-01-18 11:13:29 +00:00
return 0;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
/*
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
* Writes any 32-bit CP210X_ register identified by req.
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
*/
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
static int cp210x_write_u32_reg(struct usb_serial_port *port, u8 req, u32 val)
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
{
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
__le32 le32_val;
le32_val = cpu_to_le32(val);
return cp210x_write_reg_block(port, req, &le32_val, sizeof(le32_val));
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
#ifdef CONFIG_GPIOLIB
/*
* Writes a variable-sized vendor block of CP210X_ registers, identified by val.
* Data in buf must be in native USB byte order.
*/
static int cp210x_write_vendor_block(struct usb_serial *serial, u8 type,
u16 val, void *buf, int bufsize)
{
void *dmabuf;
int result;
dmabuf = kmemdup(buf, bufsize, GFP_KERNEL);
if (!dmabuf)
return -ENOMEM;
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
CP210X_VENDOR_SPECIFIC, type, val,
cp210x_interface_num(serial), dmabuf, bufsize,
USB_CTRL_SET_TIMEOUT);
kfree(dmabuf);
USB: serial: cp210x: drop short control-transfer checks 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>
2021-01-18 11:13:29 +00:00
if (result < 0) {
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
dev_err(&serial->interface->dev,
"failed to set vendor val 0x%04x size %d: %d\n", val,
bufsize, result);
USB: serial: cp210x: drop short control-transfer checks 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>
2021-01-18 11:13:29 +00:00
return result;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
USB: serial: cp210x: drop short control-transfer checks 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>
2021-01-18 11:13:29 +00:00
return 0;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
#endif
tty: USB does not need the filp argument in the drivers And indeed none of them use it. Clean this up as it will make moving to a standard open method rather easier. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-09-19 20:13:26 +00:00
static int cp210x_open(struct tty_struct *tty, struct usb_serial_port *port)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
int result;
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
result = cp210x_write_u16_reg(port, CP210X_IFC_ENABLE, UART_ENABLE);
USB: cp210x: forward USB errors to USB serial core Make sure we forward all error codes (e.g. ENOMEM) to USB serial core. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-10 13:58:29 +00:00
if (result) {
dev_err(&port->dev, "%s - Unable to enable UART\n", __func__);
return result;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
USB: serial: cp210x: set terminal settings on open 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>
2020-11-16 16:18:23 +00:00
if (tty)
cp210x_set_termios(tty, port, NULL);
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
USB: serial: cp210x: disable interface on errors in open 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.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-13 10:55:13 +00:00
result = usb_serial_generic_open(tty, port);
if (result)
goto err_disable;
return 0;
err_disable:
cp210x_write_u16_reg(port, CP210X_IFC_ENABLE, UART_DISABLE);
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
port_priv->event_mode = false;
USB: serial: cp210x: disable interface on errors in open 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.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-13 10:55:13 +00:00
return result;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
static void cp210x_close(struct usb_serial_port *port)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
USB: serial: refactor generic close Export usb_serial_generic_close so that drivers can easily kill the read and write urb and make sure that the write fifo is reset. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-03-17 22:00:45 +00:00
usb_serial_generic_close(port);
USB: cp210x: flush device queues at close Flush all device queues at close in order to work around a cp2108 Tx queue bug. Occasionally, writing data and immediately closing the port makes cp2108 stop responding. The device has to be unplugged to clear the error. The failure is induced by shutting down the device while its Tx queue still has unsent data. This condition is avoided by issuing PURGE command from the close() callback. This change is applied to all cp210x devices. Clearing internal queues on close is generally good. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: amend commit message ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:03 +00:00
/* Clear both queues; cp2108 needs this to avoid an occasional hang */
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
cp210x_write_u16_reg(port, CP210X_PURGE, PURGE_ALL);
USB: cp210x: flush device queues at close Flush all device queues at close in order to work around a cp2108 Tx queue bug. Occasionally, writing data and immediately closing the port makes cp2108 stop responding. The device has to be unplugged to clear the error. The failure is induced by shutting down the device while its Tx queue still has unsent data. This condition is avoided by issuing PURGE command from the close() callback. This change is applied to all cp210x devices. Clearing internal queues on close is generally good. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: amend commit message ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:03 +00:00
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
cp210x_write_u16_reg(port, CP210X_IFC_ENABLE, UART_DISABLE);
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
/* Disabling the interface disables event-insertion mode. */
port_priv->event_mode = false;
}
static void cp210x_process_lsr(struct usb_serial_port *port, unsigned char lsr, char *flag)
{
if (lsr & CP210X_LSR_BREAK) {
port->icount.brk++;
*flag = TTY_BREAK;
} else if (lsr & CP210X_LSR_PARITY) {
port->icount.parity++;
*flag = TTY_PARITY;
} else if (lsr & CP210X_LSR_FRAME) {
port->icount.frame++;
*flag = TTY_FRAME;
}
if (lsr & CP210X_LSR_OVERRUN) {
port->icount.overrun++;
tty_insert_flip_char(&port->port, 0, TTY_OVERRUN);
}
}
static bool cp210x_process_char(struct usb_serial_port *port, unsigned char *ch, char *flag)
{
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
switch (port_priv->event_state) {
case ES_DATA:
if (*ch == CP210X_ESCCHAR) {
port_priv->event_state = ES_ESCAPE;
break;
}
return false;
case ES_ESCAPE:
switch (*ch) {
case 0:
dev_dbg(&port->dev, "%s - escape char\n", __func__);
*ch = CP210X_ESCCHAR;
port_priv->event_state = ES_DATA;
return false;
case 1:
port_priv->event_state = ES_LSR_DATA_0;
break;
case 2:
port_priv->event_state = ES_LSR;
break;
case 3:
port_priv->event_state = ES_MSR;
break;
default:
dev_err(&port->dev, "malformed event 0x%02x\n", *ch);
port_priv->event_state = ES_DATA;
break;
}
break;
case ES_LSR_DATA_0:
port_priv->lsr = *ch;
port_priv->event_state = ES_LSR_DATA_1;
break;
case ES_LSR_DATA_1:
dev_dbg(&port->dev, "%s - lsr = 0x%02x, data = 0x%02x\n",
__func__, port_priv->lsr, *ch);
cp210x_process_lsr(port, port_priv->lsr, flag);
port_priv->event_state = ES_DATA;
return false;
case ES_LSR:
dev_dbg(&port->dev, "%s - lsr = 0x%02x\n", __func__, *ch);
port_priv->lsr = *ch;
cp210x_process_lsr(port, port_priv->lsr, flag);
port_priv->event_state = ES_DATA;
break;
case ES_MSR:
dev_dbg(&port->dev, "%s - msr = 0x%02x\n", __func__, *ch);
/* unimplemented */
port_priv->event_state = ES_DATA;
break;
}
return true;
}
static void cp210x_process_read_urb(struct urb *urb)
{
struct usb_serial_port *port = urb->context;
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
unsigned char *ch = urb->transfer_buffer;
char flag;
int i;
if (!urb->actual_length)
return;
if (port_priv->event_mode) {
for (i = 0; i < urb->actual_length; i++, ch++) {
flag = TTY_NORMAL;
if (cp210x_process_char(port, ch, &flag))
continue;
tty_insert_flip_char(&port->port, *ch, flag);
}
} else {
tty_insert_flip_string(&port->port, ch, urb->actual_length);
}
tty_flip_buffer_push(&port->port);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
USB: cp210x: add tx_empty() Added tx_empty callback needed for generic wait-until-sent support. Without this function, when the port is closed usbserial can't know that there are still data in the chip's transmit FIFO. The chip gets disabled and untransmitted data lost. When the actual byte count is reported by tx-empty the close can be delayed until all data are sent. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: modify tx_empty error handling ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-24 22:28:41 +00:00
/*
* Read how many bytes are waiting in the TX queue.
*/
static int cp210x_get_tx_queue_byte_count(struct usb_serial_port *port,
u32 *count)
{
struct usb_serial *serial = port->serial;
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
struct cp210x_comm_status *sts;
int result;
sts = kmalloc(sizeof(*sts), GFP_KERNEL);
if (!sts)
return -ENOMEM;
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
CP210X_GET_COMM_STATUS, REQTYPE_INTERFACE_TO_HOST,
0, port_priv->bInterfaceNumber, sts, sizeof(*sts),
USB_CTRL_GET_TIMEOUT);
if (result == sizeof(*sts)) {
*count = le32_to_cpu(sts->ulAmountInOutQueue);
result = 0;
} else {
dev_err(&port->dev, "failed to get comm status: %d\n", result);
if (result >= 0)
USB: serial: cp210x: return -EIO on short control transfers Return -EIO on short control transfers rather than -EPROTO which is used for lower-level transfer errors. Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-19 13:46:39 +00:00
result = -EIO;
USB: cp210x: add tx_empty() Added tx_empty callback needed for generic wait-until-sent support. Without this function, when the port is closed usbserial can't know that there are still data in the chip's transmit FIFO. The chip gets disabled and untransmitted data lost. When the actual byte count is reported by tx-empty the close can be delayed until all data are sent. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> [johan: modify tx_empty error handling ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-24 22:28:41 +00:00
}
kfree(sts);
return result;
}
static bool cp210x_tx_empty(struct usb_serial_port *port)
{
int err;
u32 count;
err = cp210x_get_tx_queue_byte_count(port, &count);
if (err)
return true;
return !count;
}
USB: serial: cp210x: make line-speed quantisation data driven 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>
2018-07-18 12:24:57 +00:00
struct cp210x_rate {
speed_t rate;
speed_t high;
};
static const struct cp210x_rate cp210x_an205_table1[] = {
{ 300, 300 },
{ 600, 600 },
{ 1200, 1200 },
{ 1800, 1800 },
{ 2400, 2400 },
{ 4000, 4000 },
{ 4800, 4803 },
{ 7200, 7207 },
{ 9600, 9612 },
{ 14400, 14428 },
{ 16000, 16062 },
{ 19200, 19250 },
{ 28800, 28912 },
{ 38400, 38601 },
{ 51200, 51558 },
{ 56000, 56280 },
{ 57600, 58053 },
{ 64000, 64111 },
{ 76800, 77608 },
{ 115200, 117028 },
{ 128000, 129347 },
{ 153600, 156868 },
{ 230400, 237832 },
{ 250000, 254234 },
{ 256000, 273066 },
{ 460800, 491520 },
{ 500000, 567138 },
{ 576000, 670254 },
{ 921600, UINT_MAX }
};
/*
* Quantises the baud rate as per AN205 Table 1
*/
static speed_t cp210x_get_an205_rate(speed_t baud)
{
int i;
for (i = 0; i < ARRAY_SIZE(cp210x_an205_table1); ++i) {
if (baud <= cp210x_an205_table1[i].high)
break;
}
return cp210x_an205_table1[i].rate;
}
USB: serial: cp210x: add minimum baud rate for CP2105 SCI 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: Johanna 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: Johan Hovold <johan@kernel.org>
2019-02-06 08:56:15 +00:00
static speed_t cp210x_get_actual_rate(speed_t baud)
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
{
unsigned int prescale = 1;
unsigned int div;
if (baud <= 365)
prescale = 4;
div = DIV_ROUND_CLOSEST(48000000, 2 * prescale * baud);
baud = 48000000 / (2 * prescale * div);
return baud;
}
USB: cp210x: clean up, refactor and document speed handling Clean up and refactor speed handling. Document baud rate handling for CP210{1,2,4,5,10}. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-15 23:36:51 +00:00
/*
* CP2101 supports the following baud rates:
*
* 300, 600, 1200, 1800, 2400, 4800, 7200, 9600, 14400, 19200, 28800,
* 38400, 56000, 57600, 115200, 128000, 230400, 460800, 921600
*
* CP2102 and CP2103 support the following additional rates:
*
* 4000, 16000, 51200, 64000, 76800, 153600, 250000, 256000, 500000,
* 576000
*
* The device will map a requested rate to a supported one, but the result
* of requests for rates greater than 1053257 is undefined (see AN205).
*
* CP2104, CP2105 and CP2110 support most rates up to 2M, 921k and 1M baud,
* respectively, with an error less than 1%. The actual rates are determined
* by
*
* div = round(freq / (2 x prescale x request))
* actual = freq / (2 x prescale x div)
*
* For CP2104 and CP2105 freq is 48Mhz and prescale is 4 for request <= 365bps
* or 1 otherwise.
* For CP2110 freq is 24Mhz and prescale is 4 for request <= 300bps or 1
* otherwise.
*/
static void cp210x_change_speed(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
USB: serial: cp210x: improve baudrate support for CP2102N 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>
2018-07-18 12:24:59 +00:00
struct usb_serial *serial = port->serial;
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
USB: cp210x: clean up, refactor and document speed handling Clean up and refactor speed handling. Document baud rate handling for CP210{1,2,4,5,10}. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-15 23:36:51 +00:00
u32 baud;
USB: serial: cp210x: improve baudrate support for CP2102N 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>
2018-07-18 12:24:59 +00:00
/*
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
* This maps the requested rate to the actual rate, a valid rate on
* cp2102 or cp2103, or to an arbitrary rate in [1M, max_speed].
USB: cp210x: clean up, refactor and document speed handling Clean up and refactor speed handling. Document baud rate handling for CP210{1,2,4,5,10}. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-15 23:36:51 +00:00
*
* NOTE: B0 is not implemented.
*/
USB: serial: cp210x: add minimum baud rate for CP2105 SCI 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: Johanna 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: Johan Hovold <johan@kernel.org>
2019-02-06 08:56:15 +00:00
baud = clamp(tty->termios.c_ospeed, priv->min_speed, priv->max_speed);
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
if (priv->use_actual_rate)
USB: serial: cp210x: add minimum baud rate for CP2105 SCI 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: Johanna 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: Johan Hovold <johan@kernel.org>
2019-02-06 08:56:15 +00:00
baud = cp210x_get_actual_rate(baud);
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
else if (baud < 1000000)
USB: serial: cp210x: make line-speed quantisation data driven 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>
2018-07-18 12:24:57 +00:00
baud = cp210x_get_an205_rate(baud);
USB: cp210x: clean up, refactor and document speed handling Clean up and refactor speed handling. Document baud rate handling for CP210{1,2,4,5,10}. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-15 23:36:51 +00:00
USB: serial: cp210x.c: remove dbg() usage dbg() was a very old USB-serial-specific macro. This patch removes it from being used in the driver and uses dev_dbg() instead. CC: Johan Hovold <jhovold@gmail.com> CC: Preston Fick <preston.fick@silabs.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-14 00:18:13 +00:00
dev_dbg(&port->dev, "%s - setting baud rate to %u\n", __func__, baud);
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
if (cp210x_write_u32_reg(port, CP210X_SET_BAUDRATE, baud)) {
USB: cp210x: clean up, refactor and document speed handling Clean up and refactor speed handling. Document baud rate handling for CP210{1,2,4,5,10}. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-15 23:36:51 +00:00
dev_warn(&port->dev, "failed to set baud rate to %u\n", baud);
if (old_termios)
baud = old_termios->c_ospeed;
else
baud = 9600;
}
tty_encode_baud_rate(tty, baud, baud);
}
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
static void cp210x_enable_event_mode(struct usb_serial_port *port)
{
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
int ret;
if (port_priv->event_mode)
return;
port_priv->event_state = ES_DATA;
port_priv->event_mode = true;
ret = cp210x_write_u16_reg(port, CP210X_EMBED_EVENTS, CP210X_ESCCHAR);
if (ret) {
dev_err(&port->dev, "failed to enable events: %d\n", ret);
port_priv->event_mode = false;
}
}
static void cp210x_disable_event_mode(struct usb_serial_port *port)
{
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
int ret;
if (!port_priv->event_mode)
return;
ret = cp210x_write_u16_reg(port, CP210X_EMBED_EVENTS, 0);
if (ret) {
dev_err(&port->dev, "failed to disable events: %d\n", ret);
return;
}
port_priv->event_mode = false;
}
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
static int cp210x_set_chars(struct usb_serial_port *port,
struct cp210x_special_chars *chars)
{
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
struct usb_serial *serial = port->serial;
void *dmabuf;
int result;
dmabuf = kmemdup(chars, sizeof(*chars), GFP_KERNEL);
if (!dmabuf)
return -ENOMEM;
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
CP210X_SET_CHARS, REQTYPE_HOST_TO_INTERFACE, 0,
port_priv->bInterfaceNumber,
dmabuf, sizeof(*chars), USB_CTRL_SET_TIMEOUT);
kfree(dmabuf);
if (result < 0) {
dev_err(&port->dev, "failed to set special chars: %d\n", result);
return result;
}
return 0;
}
USB: serial: cp210x: return early on unchanged termios 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>
2020-11-16 16:18:21 +00:00
static bool cp210x_termios_change(const struct ktermios *a, const struct ktermios *b)
{
USB: serial: cp210x: update control-characters on every change 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>
2021-01-18 11:13:28 +00:00
bool iflag_change, cc_change;
USB: serial: cp210x: return early on unchanged termios 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>
2020-11-16 16:18:21 +00:00
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
iflag_change = ((a->c_iflag ^ b->c_iflag) & (INPCK | IXON | IXOFF));
USB: serial: cp210x: update control-characters on every change 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>
2021-01-18 11:13:28 +00:00
cc_change = a->c_cc[VSTART] != b->c_cc[VSTART] ||
a->c_cc[VSTOP] != b->c_cc[VSTOP];
USB: serial: cp210x: return early on unchanged termios 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>
2020-11-16 16:18:21 +00:00
USB: serial: cp210x: update control-characters on every change 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>
2021-01-18 11:13:28 +00:00
return tty_termios_hw_change(a, b) || iflag_change || cc_change;
USB: serial: cp210x: return early on unchanged termios 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>
2020-11-16 16:18:21 +00:00
}
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
static void cp210x_set_flow_control(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
struct cp210x_serial_private *priv = usb_get_serial_data(port->serial);
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
struct cp210x_special_chars chars;
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
struct cp210x_flow_ctl flow_ctl;
u32 flow_repl;
u32 ctl_hs;
int ret;
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
/*
* Some CP2102N interpret ulXonLimit as ulFlowReplace (erratum
* CP2102N_E104). Report back that flow control is not supported.
*/
if (priv->no_flow_control) {
tty->termios.c_cflag &= ~CRTSCTS;
tty->termios.c_iflag &= ~(IXON | IXOFF);
}
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
if (old_termios &&
C_CRTSCTS(tty) == (old_termios->c_cflag & CRTSCTS) &&
I_IXON(tty) == (old_termios->c_iflag & IXON) &&
USB: serial: cp210x: update control-characters on every change 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>
2021-01-18 11:13:28 +00:00
I_IXOFF(tty) == (old_termios->c_iflag & IXOFF) &&
START_CHAR(tty) == old_termios->c_cc[VSTART] &&
STOP_CHAR(tty) == old_termios->c_cc[VSTOP]) {
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
return;
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
}
if (I_IXON(tty) || I_IXOFF(tty)) {
memset(&chars, 0, sizeof(chars));
chars.bXonChar = START_CHAR(tty);
chars.bXoffChar = STOP_CHAR(tty);
ret = cp210x_set_chars(port, &chars);
if (ret)
return;
}
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
mutex_lock(&port_priv->mutex);
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
ret = cp210x_read_reg_block(port, CP210X_GET_FLOW, &flow_ctl,
sizeof(flow_ctl));
if (ret)
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
goto out_unlock;
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
ctl_hs &= ~CP210X_SERIAL_DSR_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DCD_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DSR_SENSITIVITY;
ctl_hs &= ~CP210X_SERIAL_DTR_MASK;
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
if (port_priv->dtr)
USB: serial: cp210x: drop shift macros 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>
2021-01-25 13:48:13 +00:00
ctl_hs |= CP210X_SERIAL_DTR_ACTIVE;
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
else
USB: serial: cp210x: drop shift macros 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>
2021-01-25 13:48:13 +00:00
ctl_hs |= CP210X_SERIAL_DTR_INACTIVE;
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
USB: serial: cp210x: clean up auto-RTS handling 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>
2021-01-25 13:48:17 +00:00
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
if (C_CRTSCTS(tty)) {
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
USB: serial: cp210x: fix RTS handling 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>
2021-01-25 13:48:16 +00:00
if (port_priv->rts)
flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
else
flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
port_priv->crtscts = true;
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
if (port_priv->rts)
USB: serial: cp210x: drop shift macros 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>
2021-01-25 13:48:13 +00:00
flow_repl |= CP210X_SERIAL_RTS_ACTIVE;
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
else
USB: serial: cp210x: drop shift macros 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>
2021-01-25 13:48:13 +00:00
flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
port_priv->crtscts = false;
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
}
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
if (I_IXOFF(tty)) {
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
flow_repl |= CP210X_SERIAL_AUTO_RECEIVE;
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
flow_ctl.ulXonLimit = cpu_to_le32(128);
flow_ctl.ulXoffLimit = cpu_to_le32(128);
} else {
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
flow_repl &= ~CP210X_SERIAL_AUTO_RECEIVE;
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
}
USB: serial: cp210x: add support for software flow control 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>
2021-01-18 11:13:26 +00:00
if (I_IXON(tty))
flow_repl |= CP210X_SERIAL_AUTO_TRANSMIT;
else
flow_repl &= ~CP210X_SERIAL_AUTO_TRANSMIT;
USB: serial: cp210x: clean up flow-control debug message 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>
2021-01-25 13:48:14 +00:00
dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n", __func__,
ctl_hs, flow_repl);
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs);
flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
cp210x_write_reg_block(port, CP210X_SET_FLOW, &flow_ctl,
sizeof(flow_ctl));
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
out_unlock:
mutex_unlock(&port_priv->mutex);
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
}
USB: CP210X Replace CP2101 with CP210x This patch replaces the string "CP2101" with "CP210x" within cp210x.c This is to reduce confusion about the fact that the driver is actually compatible with CP2101, CP2102 and CP2103 devices. Signed-off-by: Craig Shelley <craig@microtron.org.uk> (Fixed some collisions merging) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11 12:54:40 +00:00
static void cp210x_set_termios(struct tty_struct *tty,
usb_serial: API all change USB serial likes to use port->tty back pointers for the real work it does and to do so without any actual locking. Unfortunately when you consider hangup events, hangup/parallel reopen or even worse hangup followed by parallel close events the tty->port and port->tty pointers are not guaranteed to be the same as port->tty is the active tty while tty->port is the port the tty may or may not still be attached to. So rework the entire API to pass the tty struct. For console cases we need to pass both for now. This shows up multiple drivers that immediately crash with USB console some of which have been fixed in the process. Longer term we need a proper tty as console abstraction Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-22 10:09:07 +00:00
struct usb_serial_port *port, struct ktermios *old_termios)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
USB: serial: cp210x: clean up line-control handling 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>
2020-11-16 16:18:22 +00:00
struct cp210x_serial_private *priv = usb_get_serial_data(port->serial);
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
u16 bits;
USB: serial: cp210x: clean up line-control handling 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>
2020-11-16 16:18:22 +00:00
int ret;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: set terminal settings on open 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>
2020-11-16 16:18:23 +00:00
if (old_termios && !cp210x_termios_change(&tty->termios, old_termios))
USB: serial: cp210x: return early on unchanged termios 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>
2020-11-16 16:18:21 +00:00
return;
USB: serial: cp210x: set terminal settings on open 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>
2020-11-16 16:18:23 +00:00
if (!old_termios || tty->termios.c_ospeed != old_termios->c_ospeed)
USB: cp210x: clean up, refactor and document speed handling Clean up and refactor speed handling. Document baud rate handling for CP210{1,2,4,5,10}. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-15 23:36:51 +00:00
cp210x_change_speed(tty, port, old_termios);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
USB: serial: cp210x: clean up line-control handling 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>
2020-11-16 16:18:22 +00:00
/* CP2101 only supports CS8, 1 stop bit and non-stick parity. */
if (priv->partnum == CP210X_PARTNUM_CP2101) {
tty->termios.c_cflag &= ~(CSIZE | CSTOPB | CMSPAR);
tty->termios.c_cflag |= CS8;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
USB: serial: cp210x: clean up line-control handling 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>
2020-11-16 16:18:22 +00:00
bits = 0;
switch (C_CSIZE(tty)) {
case CS5:
bits |= BITS_DATA_5;
break;
case CS6:
bits |= BITS_DATA_6;
break;
case CS7:
bits |= BITS_DATA_7;
break;
case CS8:
default:
bits |= BITS_DATA_8;
break;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
USB: serial: cp210x: clean up line-control handling 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>
2020-11-16 16:18:22 +00:00
if (C_PARENB(tty)) {
if (C_CMSPAR(tty)) {
if (C_PARODD(tty))
bits |= BITS_PARITY_MARK;
else
bits |= BITS_PARITY_SPACE;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
} else {
USB: serial: cp210x: clean up line-control handling 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>
2020-11-16 16:18:22 +00:00
if (C_PARODD(tty))
bits |= BITS_PARITY_ODD;
else
bits |= BITS_PARITY_EVEN;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
}
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: clean up line-control handling 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>
2020-11-16 16:18:22 +00:00
if (C_CSTOPB(tty))
bits |= BITS_STOP_2;
else
bits |= BITS_STOP_1;
ret = cp210x_write_u16_reg(port, CP210X_SET_LINE_CTL, bits);
if (ret)
dev_err(&port->dev, "failed to set line control: %d\n", ret);
USB: serial: cp210x: refactor flow-control handling 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>
2020-11-16 16:18:25 +00:00
cp210x_set_flow_control(tty, port, old_termios);
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: add support for line-status events 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>
2020-07-13 10:55:14 +00:00
/*
* Enable event-insertion mode only if input parity checking is
* enabled for now.
*/
if (I_INPCK(tty))
cp210x_enable_event_mode(port);
else
cp210x_disable_event_mode(port);
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
}
USB: cp210x: fix whitespace issues Fix missing and superfluous whitespace. Fix misplaced brackets. Fix indentation. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-29 09:56:19 +00:00
static int cp210x_tiocmset(struct tty_struct *tty,
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
unsigned int set, unsigned int clear)
{
usb_serial: API all change USB serial likes to use port->tty back pointers for the real work it does and to do so without any actual locking. Unfortunately when you consider hangup events, hangup/parallel reopen or even worse hangup followed by parallel close events the tty->port and port->tty pointers are not guaranteed to be the same as port->tty is the active tty while tty->port is the port the tty may or may not still be attached to. So rework the entire API to pass the tty struct. For console cases we need to pass both for now. This shows up multiple drivers that immediately crash with USB console some of which have been fixed in the process. Longer term we need a proper tty as console abstraction Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-22 10:09:07 +00:00
struct usb_serial_port *port = tty->driver_data;
tiocmset: kill the file pointer argument Doing tiocmget was such fun we should do tiocmset as well for the same reasons Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-14 16:26:50 +00:00
return cp210x_tiocmset_port(port, set, clear);
USB: Fix cp2101 USB serial device driver termios functions for console use This is really a follow up to the modifications Alan Cox made for commit 95da310e66ee8090119596c70ca8432e57f9a97f to pass a tty_struct to various interface functions, which broke the serial configuration (termios) functions when the device is being used as a console. These changes restore the configuration to proper functioning both as a tty and as a console. As Alan notes in that commit, these changes will need to be tweaked when we have a proper console abstraction. Signed-off-by: David VomLehn <dvomlehn@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-12 21:37:42 +00:00
}
tiocmset: kill the file pointer argument Doing tiocmget was such fun we should do tiocmset as well for the same reasons Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-14 16:26:50 +00:00
static int cp210x_tiocmset_port(struct usb_serial_port *port,
USB: Fix cp2101 USB serial device driver termios functions for console use This is really a follow up to the modifications Alan Cox made for commit 95da310e66ee8090119596c70ca8432e57f9a97f to pass a tty_struct to various interface functions, which broke the serial configuration (termios) functions when the device is being used as a console. These changes restore the configuration to proper functioning both as a tty and as a console. As Alan notes in that commit, these changes will need to be tweaked when we have a proper console abstraction. Signed-off-by: David VomLehn <dvomlehn@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-12 21:37:42 +00:00
unsigned int set, unsigned int clear)
{
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
USB: serial: cp210x: fix RTS handling 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>
2021-01-25 13:48:16 +00:00
struct cp210x_flow_ctl flow_ctl;
u32 ctl_hs, flow_repl;
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
u16 control = 0;
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
int ret;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
mutex_lock(&port_priv->mutex);
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
if (set & TIOCM_RTS) {
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
port_priv->rts = true;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
control |= CONTROL_RTS;
control |= CONTROL_WRITE_RTS;
}
if (set & TIOCM_DTR) {
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
port_priv->dtr = true;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
control |= CONTROL_DTR;
control |= CONTROL_WRITE_DTR;
}
if (clear & TIOCM_RTS) {
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
port_priv->rts = false;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
control &= ~CONTROL_RTS;
control |= CONTROL_WRITE_RTS;
}
if (clear & TIOCM_DTR) {
USB: serial: cp210x: fix modem-control handling 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>
2021-01-25 13:48:12 +00:00
port_priv->dtr = false;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
control &= ~CONTROL_DTR;
control |= CONTROL_WRITE_DTR;
}
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
/*
USB: serial: cp210x: fix RTS handling 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>
2021-01-25 13:48:16 +00:00
* Use SET_FLOW to set DTR and enable/disable auto-RTS when hardware
* flow control is enabled.
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
*/
USB: serial: cp210x: fix RTS handling 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>
2021-01-25 13:48:16 +00:00
if (port_priv->crtscts && control & CONTROL_WRITE_RTS) {
ret = cp210x_read_reg_block(port, CP210X_GET_FLOW, &flow_ctl,
sizeof(flow_ctl));
if (ret)
goto out_unlock;
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
USB: serial: cp210x: fix RTS handling 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>
2021-01-25 13:48:16 +00:00
ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: fix RTS handling 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>
2021-01-25 13:48:16 +00:00
ctl_hs &= ~CP210X_SERIAL_DTR_MASK;
if (port_priv->dtr)
ctl_hs |= CP210X_SERIAL_DTR_ACTIVE;
else
ctl_hs |= CP210X_SERIAL_DTR_INACTIVE;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: fix RTS handling 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>
2021-01-25 13:48:16 +00:00
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
if (port_priv->rts)
flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
else
flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs);
flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n",
__func__, ctl_hs, flow_repl);
ret = cp210x_write_reg_block(port, CP210X_SET_FLOW, &flow_ctl,
sizeof(flow_ctl));
} else {
dev_dbg(&port->dev, "%s - control = 0x%04x\n", __func__, control);
ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
}
out_unlock:
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
mutex_unlock(&port_priv->mutex);
return ret;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
}
USB: serial: cp210x: clean up dtr_rts() Clean up dtr_rts() by renaming the port parameter and adding missing whitespace. Signed-off-by: Johan Hovold <johan@kernel.org>
2020-11-16 16:18:26 +00:00
static void cp210x_dtr_rts(struct usb_serial_port *port, int on)
tty: cp210x: Fix carrier handling Original discussion: http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248 or http://marc.info/?l=linux-usb&m=125553790714133&w=2 9a68e39d4a701fb3be03cae9b462408664ebd205 broke carrier handling so that a cp210x setup which needed the carrier lines set up (non CLOCAL) which did not make a call which set the termios bits left the lines down even if CLOCAL was not asserted. Fix this not by reverting but by adding the proper dtr_rts and carrier_raised methods. This both sets the modem lines properly and also implements the correct blocking semantics for the port as required by POSIX. Signed-off-by: Alan Cox <alan@linux.intel.com> Reported-by: Karl Hiramoto <karl@hiramoto.org> Tested-by: Karl Hiramoto <karl@hiramoto.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 20:12:33 +00:00
{
if (on)
USB: serial: cp210x: clean up dtr_rts() Clean up dtr_rts() by renaming the port parameter and adding missing whitespace. Signed-off-by: Johan Hovold <johan@kernel.org>
2020-11-16 16:18:26 +00:00
cp210x_tiocmset_port(port, TIOCM_DTR | TIOCM_RTS, 0);
tty: cp210x: Fix carrier handling Original discussion: http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248 or http://marc.info/?l=linux-usb&m=125553790714133&w=2 9a68e39d4a701fb3be03cae9b462408664ebd205 broke carrier handling so that a cp210x setup which needed the carrier lines set up (non CLOCAL) which did not make a call which set the termios bits left the lines down even if CLOCAL was not asserted. Fix this not by reverting but by adding the proper dtr_rts and carrier_raised methods. This both sets the modem lines properly and also implements the correct blocking semantics for the port as required by POSIX. Signed-off-by: Alan Cox <alan@linux.intel.com> Reported-by: Karl Hiramoto <karl@hiramoto.org> Tested-by: Karl Hiramoto <karl@hiramoto.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 20:12:33 +00:00
else
USB: serial: cp210x: clean up dtr_rts() Clean up dtr_rts() by renaming the port parameter and adding missing whitespace. Signed-off-by: Johan Hovold <johan@kernel.org>
2020-11-16 16:18:26 +00:00
cp210x_tiocmset_port(port, 0, TIOCM_DTR | TIOCM_RTS);
tty: cp210x: Fix carrier handling Original discussion: http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248 or http://marc.info/?l=linux-usb&m=125553790714133&w=2 9a68e39d4a701fb3be03cae9b462408664ebd205 broke carrier handling so that a cp210x setup which needed the carrier lines set up (non CLOCAL) which did not make a call which set the termios bits left the lines down even if CLOCAL was not asserted. Fix this not by reverting but by adding the proper dtr_rts and carrier_raised methods. This both sets the modem lines properly and also implements the correct blocking semantics for the port as required by POSIX. Signed-off-by: Alan Cox <alan@linux.intel.com> Reported-by: Karl Hiramoto <karl@hiramoto.org> Tested-by: Karl Hiramoto <karl@hiramoto.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 20:12:33 +00:00
}
USB: cp210x: fix whitespace issues Fix missing and superfluous whitespace. Fix misplaced brackets. Fix indentation. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-29 09:56:19 +00:00
static int cp210x_tiocmget(struct tty_struct *tty)
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
{
usb_serial: API all change USB serial likes to use port->tty back pointers for the real work it does and to do so without any actual locking. Unfortunately when you consider hangup events, hangup/parallel reopen or even worse hangup followed by parallel close events the tty->port and port->tty pointers are not guaranteed to be the same as port->tty is the active tty while tty->port is the port the tty may or may not still be attached to. So rework the entire API to pass the tty struct. For console cases we need to pass both for now. This shows up multiple drivers that immediately crash with USB console some of which have been fixed in the process. Longer term we need a proper tty as console abstraction Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-22 10:09:07 +00:00
struct usb_serial_port *port = tty->driver_data;
USB: serial: cp210x: add 8-bit and 32-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 8 and 32-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:41 +00:00
u8 control;
USB: cp2101.c fix sparse signedness mismatch warnings The get/set 2101_config helpers take an unsigned int rather than an int. It is safe to change these in each case and may even produce better code as it will be an unsigned divide rather than a signed divide in places. All other manipulation was setting/masking bits which will not be affected by the sign change. Fixes the following sparse warnings: drivers/usb/serial/cp2101.c:378:44: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:378:44: expected unsigned int *data drivers/usb/serial/cp2101.c:378:44: got int *<noident> drivers/usb/serial/cp2101.c:388:40: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:388:40: expected unsigned int *data drivers/usb/serial/cp2101.c:388:40: got int *<noident> drivers/usb/serial/cp2101.c:413:42: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:413:42: expected unsigned int *data drivers/usb/serial/cp2101.c:413:42: got int *<noident> drivers/usb/serial/cp2101.c:421:42: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:421:42: expected unsigned int *data drivers/usb/serial/cp2101.c:421:42: got int *<noident> drivers/usb/serial/cp2101.c:444:42: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:444:42: expected unsigned int *data drivers/usb/serial/cp2101.c:444:42: got int *<noident> drivers/usb/serial/cp2101.c:451:42: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:451:42: expected unsigned int *data drivers/usb/serial/cp2101.c:451:42: got int *<noident> drivers/usb/serial/cp2101.c:458:42: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:458:42: expected unsigned int *data drivers/usb/serial/cp2101.c:458:42: got int *<noident> drivers/usb/serial/cp2101.c:471:42: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:471:42: expected unsigned int *data drivers/usb/serial/cp2101.c:471:42: got int *<noident> drivers/usb/serial/cp2101.c:481:42: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:481:42: expected unsigned int *data drivers/usb/serial/cp2101.c:481:42: got int *<noident> drivers/usb/serial/cp2101.c:561:41: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:561:41: expected unsigned int *data drivers/usb/serial/cp2101.c:561:41: got int *<noident> drivers/usb/serial/cp2101.c:591:45: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:591:45: expected unsigned int *data drivers/usb/serial/cp2101.c:591:45: got int *<noident> drivers/usb/serial/cp2101.c:597:41: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:597:41: expected unsigned int *data drivers/usb/serial/cp2101.c:597:41: got int *<noident> drivers/usb/serial/cp2101.c:608:45: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:608:45: expected unsigned int *data drivers/usb/serial/cp2101.c:608:45: got int *<noident> drivers/usb/serial/cp2101.c:614:41: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:614:41: expected unsigned int *data drivers/usb/serial/cp2101.c:614:41: got int *<noident> drivers/usb/serial/cp2101.c:623:45: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:623:45: expected unsigned int *data drivers/usb/serial/cp2101.c:623:45: got int *<noident> drivers/usb/serial/cp2101.c:680:50: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:680:50: expected unsigned int *data drivers/usb/serial/cp2101.c:680:50: got int *<noident> drivers/usb/serial/cp2101.c:690:43: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:690:43: expected unsigned int *data drivers/usb/serial/cp2101.c:690:43: got int *<noident> drivers/usb/serial/cp2101.c:715:41: warning: incorrect type in argument 3 (different signedness) drivers/usb/serial/cp2101.c:715:41: expected unsigned int *data drivers/usb/serial/cp2101.c:715:41: got int *<noident> Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-05-30 17:29:55 +00:00
int result;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
USB: serial: cp210x: fix tiocmget error handling The current tiocmget implementation would fail to report errors up the stack and instead leaked a few bits from the stack as a mask of modem-status flags. Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-19 13:45:07 +00:00
result = cp210x_read_u8_reg(port, CP210X_GET_MDMSTS, &control);
if (result)
return result;
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
result = ((control & CONTROL_DTR) ? TIOCM_DTR : 0)
|((control & CONTROL_RTS) ? TIOCM_RTS : 0)
|((control & CONTROL_CTS) ? TIOCM_CTS : 0)
|((control & CONTROL_DSR) ? TIOCM_DSR : 0)
|((control & CONTROL_RING)? TIOCM_RI : 0)
|((control & CONTROL_DCD) ? TIOCM_CD : 0);
USB: serial: cp210x: clean up printk zero padding Use the 0-flag and a field width to specify zero-padding consistently in printk messages. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-01-25 13:48:15 +00:00
dev_dbg(&port->dev, "%s - control = 0x%02x\n", __func__, control);
[PATCH] USB: CP2101 Add support for flow control Added support to get/set flow control line levels using TIOCMGET and TIOCMSET. Added support for RTSCTS hardware flow control. cp2101_get_config and cp2101_set_config modified to support long request strings, required for configuring flow control. Signed-off-by: Craig Shelley craig@microtron.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-26 23:09:56 +00:00
return result;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
USB: cp210x: fix whitespace issues Fix missing and superfluous whitespace. Fix misplaced brackets. Fix indentation. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-29 09:56:19 +00:00
static void cp210x_break_ctl(struct tty_struct *tty, int break_state)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
usb_serial: API all change USB serial likes to use port->tty back pointers for the real work it does and to do so without any actual locking. Unfortunately when you consider hangup events, hangup/parallel reopen or even worse hangup followed by parallel close events the tty->port and port->tty pointers are not guaranteed to be the same as port->tty is the active tty while tty->port is the port the tty may or may not still be attached to. So rework the entire API to pass the tty struct. For console cases we need to pass both for now. This shows up multiple drivers that immediately crash with USB console some of which have been fixed in the process. Longer term we need a proper tty as console abstraction Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-22 10:09:07 +00:00
struct usb_serial_port *port = tty->driver_data;
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
u16 state;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
if (break_state == 0)
state = BREAK_OFF;
else
state = BREAK_ON;
USB: serial: cp210x.c: remove dbg() usage dbg() was a very old USB-serial-specific macro. This patch removes it from being used in the driver and uses dev_dbg() instead. CC: Johan Hovold <jhovold@gmail.com> CC: Preston Fick <preston.fick@silabs.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-14 00:18:13 +00:00
dev_dbg(&port->dev, "%s - turning break %s\n", __func__,
state == BREAK_OFF ? "off" : "on");
USB: serial: cp210x: add 16-bit register access functions cp210x_get_config and cp210x_set_config are cumbersome to use. This change introduces new register access functions for 16-bit values, instead of the above functions. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28 21:51:30 +00:00
cp210x_write_u16_reg(port, CP210X_SET_BREAK, state);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
#ifdef CONFIG_GPIOLIB
static int cp210x_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
struct usb_serial *serial = gpiochip_get_data(gc);
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
u8 req_type;
u16 mask;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
int result;
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
int len;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
USB: serial: cp210x: fix GPIO in autosuspend 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: Karoly Pados <pados@pados.hu> Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-02-17 17:59:01 +00:00
result = usb_autopm_get_interface(serial->interface);
if (result)
return result;
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
switch (priv->partnum) {
case CP210X_PARTNUM_CP2105:
req_type = REQTYPE_INTERFACE_TO_HOST;
len = 1;
break;
case CP210X_PARTNUM_CP2108:
req_type = REQTYPE_INTERFACE_TO_HOST;
len = 2;
break;
default:
req_type = REQTYPE_DEVICE_TO_HOST;
len = 1;
break;
}
mask = 0;
result = cp210x_read_vendor_block(serial, req_type, CP210X_READ_LATCH,
&mask, len);
USB: serial: cp210x: fix GPIO in autosuspend 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: Karoly Pados <pados@pados.hu> Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-02-17 17:59:01 +00:00
usb_autopm_put_interface(serial->interface);
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
if (result < 0)
return result;
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
le16_to_cpus(&mask);
return !!(mask & BIT(gpio));
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
static void cp210x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
{
struct usb_serial *serial = gpiochip_get_data(gc);
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
struct cp210x_gpio_write16 buf16;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
struct cp210x_gpio_write buf;
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
u16 mask, state;
u16 wIndex;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
int result;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
if (value == 1)
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
state = BIT(gpio);
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
else
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
state = 0;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
mask = BIT(gpio);
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
USB: serial: cp210x: fix GPIO in autosuspend 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: Karoly Pados <pados@pados.hu> Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-02-17 17:59:01 +00:00
result = usb_autopm_get_interface(serial->interface);
if (result)
goto out;
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
switch (priv->partnum) {
case CP210X_PARTNUM_CP2105:
buf.mask = (u8)mask;
buf.state = (u8)state;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
result = cp210x_write_vendor_block(serial,
REQTYPE_HOST_TO_INTERFACE,
CP210X_WRITE_LATCH, &buf,
sizeof(buf));
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
break;
case CP210X_PARTNUM_CP2108:
buf16.mask = cpu_to_le16(mask);
buf16.state = cpu_to_le16(state);
result = cp210x_write_vendor_block(serial,
REQTYPE_HOST_TO_INTERFACE,
CP210X_WRITE_LATCH, &buf16,
sizeof(buf16));
break;
default:
wIndex = state << 8 | mask;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
result = usb_control_msg(serial->dev,
usb_sndctrlpipe(serial->dev, 0),
CP210X_VENDOR_SPECIFIC,
REQTYPE_HOST_TO_DEVICE,
CP210X_WRITE_LATCH,
wIndex,
NULL, 0, USB_CTRL_SET_TIMEOUT);
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
break;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
}
USB: serial: cp210x: fix GPIO in autosuspend 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: Karoly Pados <pados@pados.hu> Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-02-17 17:59:01 +00:00
usb_autopm_put_interface(serial->interface);
out:
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
if (result < 0) {
dev_err(&serial->interface->dev, "failed to set GPIO value: %d\n",
result);
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
static int cp210x_gpio_direction_get(struct gpio_chip *gc, unsigned int gpio)
{
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
struct usb_serial *serial = gpiochip_get_data(gc);
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
return priv->gpio_input & BIT(gpio);
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
static int cp210x_gpio_direction_input(struct gpio_chip *gc, unsigned int gpio)
{
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
struct usb_serial *serial = gpiochip_get_data(gc);
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
if (priv->partnum == CP210X_PARTNUM_CP2105) {
/* hardware does not support an input mode */
return -ENOTSUPP;
}
/* push-pull pins cannot be changed to be inputs */
if (priv->gpio_pushpull & BIT(gpio))
return -EINVAL;
/* make sure to release pin if it is being driven low */
cp210x_gpio_set(gc, gpio, 1);
priv->gpio_input |= BIT(gpio);
return 0;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
static int cp210x_gpio_direction_output(struct gpio_chip *gc, unsigned int gpio,
int value)
{
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
struct usb_serial *serial = gpiochip_get_data(gc);
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
priv->gpio_input &= ~BIT(gpio);
cp210x_gpio_set(gc, gpio, value);
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
return 0;
}
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-23 12:34:34 +00:00
static int cp210x_gpio_set_config(struct gpio_chip *gc, unsigned int gpio,
unsigned long config)
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
{
struct usb_serial *serial = gpiochip_get_data(gc);
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-23 12:34:34 +00:00
enum pin_config_param param = pinconf_to_config_param(config);
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/* Succeed only if in correct mode (this can't be set at runtime) */
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-23 12:34:34 +00:00
if ((param == PIN_CONFIG_DRIVE_PUSH_PULL) &&
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
(priv->gpio_pushpull & BIT(gpio)))
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
return 0;
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-23 12:34:34 +00:00
if ((param == PIN_CONFIG_DRIVE_OPEN_DRAIN) &&
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
!(priv->gpio_pushpull & BIT(gpio)))
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
return 0;
return -ENOTSUPP;
}
USB: serial: cp210x: provide gpio valid mask 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>
2021-04-09 15:52:15 +00:00
static int cp210x_gpio_init_valid_mask(struct gpio_chip *gc,
unsigned long *valid_mask, unsigned int ngpios)
{
struct usb_serial *serial = gpiochip_get_data(gc);
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
USB: serial: cp210x: add gpio-configuration debug printk 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>
2021-04-09 15:52:16 +00:00
struct device *dev = &serial->interface->dev;
USB: serial: cp210x: provide gpio valid mask 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>
2021-04-09 15:52:15 +00:00
unsigned long altfunc_mask = priv->gpio_altfunc;
bitmap_complement(valid_mask, &altfunc_mask, ngpios);
USB: serial: cp210x: add gpio-configuration debug printk 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>
2021-04-09 15:52:16 +00:00
if (bitmap_empty(valid_mask, ngpios))
dev_dbg(dev, "no pin configured for GPIO\n");
else
dev_dbg(dev, "GPIO.%*pbl configured for GPIO\n", ngpios,
valid_mask);
USB: serial: cp210x: provide gpio valid mask 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>
2021-04-09 15:52:15 +00:00
return 0;
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
/*
* This function is for configuring GPIO using shared pins, where other signals
* are made unavailable by configuring the use of GPIO. This is believed to be
* only applicable to the cp2105 at this point, the other devices supported by
* this driver that provide GPIO do so in a way that does not impact other
* signals and are thus expected to have very different initialisation.
*/
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
static int cp2105_gpioconf_init(struct usb_serial *serial)
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
struct cp210x_pin_mode mode;
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
struct cp210x_dual_port_config config;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
u8 intf_num = cp210x_interface_num(serial);
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
u8 iface_config;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
int result;
result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
CP210X_GET_DEVICEMODE, &mode,
sizeof(mode));
if (result < 0)
return result;
result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
CP210X_GET_PORTCONFIG, &config,
sizeof(config));
if (result < 0)
return result;
/* 2 banks of GPIO - One for the pins taken from each serial port */
if (intf_num == 0) {
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
if (mode.eci == CP210X_PIN_MODE_MODEM) {
/* mark all GPIOs of this interface as reserved */
priv->gpio_altfunc = 0xff;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
return 0;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
iface_config = config.eci_cfg;
priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) &
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
CP210X_ECI_GPIO_MODE_MASK) >>
CP210X_ECI_GPIO_MODE_OFFSET);
priv->gc.ngpio = 2;
} else if (intf_num == 1) {
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
if (mode.sci == CP210X_PIN_MODE_MODEM) {
/* mark all GPIOs of this interface as reserved */
priv->gpio_altfunc = 0xff;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
return 0;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
iface_config = config.sci_cfg;
priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) &
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
CP210X_SCI_GPIO_MODE_MASK) >>
CP210X_SCI_GPIO_MODE_OFFSET);
priv->gc.ngpio = 3;
} else {
return -ENODEV;
}
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
/* mark all pins which are not in GPIO mode */
if (iface_config & CP2105_GPIO0_TXLED_MODE) /* GPIO 0 */
priv->gpio_altfunc |= BIT(0);
if (iface_config & (CP2105_GPIO1_RXLED_MODE | /* GPIO 1 */
CP2105_GPIO1_RS485_MODE))
priv->gpio_altfunc |= BIT(1);
/* driver implementation for CP2105 only supports outputs */
priv->gpio_input = 0;
return 0;
}
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
static int cp2104_gpioconf_init(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
struct cp210x_single_port_config config;
u8 iface_config;
u8 gpio_latch;
int result;
u8 i;
result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
CP210X_GET_PORTCONFIG, &config,
sizeof(config));
if (result < 0)
return result;
priv->gc.ngpio = 4;
iface_config = config.device_cfg;
priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) &
CP210X_GPIO_MODE_MASK) >>
CP210X_GPIO_MODE_OFFSET);
gpio_latch = (u8)((le16_to_cpu(config.reset_state) &
CP210X_GPIO_MODE_MASK) >>
CP210X_GPIO_MODE_OFFSET);
/* mark all pins which are not in GPIO mode */
if (iface_config & CP2104_GPIO0_TXLED_MODE) /* GPIO 0 */
priv->gpio_altfunc |= BIT(0);
if (iface_config & CP2104_GPIO1_RXLED_MODE) /* GPIO 1 */
priv->gpio_altfunc |= BIT(1);
if (iface_config & CP2104_GPIO2_RS485_MODE) /* GPIO 2 */
priv->gpio_altfunc |= BIT(2);
/*
* Like CP2102N, CP2104 has also no strict input and output pin
* modes.
* Do the same input mode emulation as CP2102N.
*/
for (i = 0; i < priv->gc.ngpio; ++i) {
/*
* Set direction to "input" iff pin is open-drain and reset
* value is 1.
*/
if (!(priv->gpio_pushpull & BIT(i)) && (gpio_latch & BIT(i)))
priv->gpio_input |= BIT(i);
}
return 0;
}
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
static int cp2108_gpio_init(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
struct cp210x_quad_port_config config;
u16 gpio_latch;
int result;
u8 i;
result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
CP210X_GET_PORTCONFIG, &config,
sizeof(config));
if (result < 0)
return result;
priv->gc.ngpio = 16;
priv->gpio_pushpull = le16_to_cpu(config.reset_state.gpio_mode_pb1);
gpio_latch = le16_to_cpu(config.reset_state.gpio_latch_pb1);
/*
* Mark all pins which are not in GPIO mode.
*
* Refer to table 9.1 "GPIO Mode alternate Functions" in the datasheet:
* https://www.silabs.com/documents/public/data-sheets/cp2108-datasheet.pdf
*
* Alternate functions of GPIO0 to GPIO3 are determine by enhancedfxn_ifc[0]
* and the similarly for the other pins; enhancedfxn_ifc[1]: GPIO4 to GPIO7,
* enhancedfxn_ifc[2]: GPIO8 to GPIO11, enhancedfxn_ifc[3]: GPIO12 to GPIO15.
*/
for (i = 0; i < 4; i++) {
if (config.enhancedfxn_ifc[i] & CP2108_EF_IFC_GPIO_TXLED)
priv->gpio_altfunc |= BIT(i * 4);
if (config.enhancedfxn_ifc[i] & CP2108_EF_IFC_GPIO_RXLED)
priv->gpio_altfunc |= BIT((i * 4) + 1);
if (config.enhancedfxn_ifc[i] & CP2108_EF_IFC_GPIO_RS485)
priv->gpio_altfunc |= BIT((i * 4) + 2);
if (config.enhancedfxn_ifc[i] & CP2108_EF_IFC_GPIO_CLOCK)
priv->gpio_altfunc |= BIT((i * 4) + 3);
}
/*
* Like CP2102N, CP2108 has also no strict input and output pin
* modes. Do the same input mode emulation as CP2102N.
*/
for (i = 0; i < priv->gc.ngpio; ++i) {
/*
* Set direction to "input" iff pin is open-drain and reset
* value is 1.
*/
if (!(priv->gpio_pushpull & BIT(i)) && (gpio_latch & BIT(i)))
priv->gpio_input |= BIT(i);
}
return 0;
}
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
static int cp2102n_gpioconf_init(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
const u16 config_size = 0x02a6;
u8 gpio_rst_latch;
u8 config_version;
u8 gpio_pushpull;
u8 *config_buf;
u8 gpio_latch;
u8 gpio_ctrl;
int result;
u8 i;
/*
* Retrieve device configuration from the device.
* The array received contains all customization settings done at the
* factory/manufacturer. Format of the array is documented at the
* time of writing at:
* https://www.silabs.com/community/interface/knowledge-base.entry.html/2017/03/31/cp2102n_setconfig-xsfa
*/
config_buf = kmalloc(config_size, GFP_KERNEL);
if (!config_buf)
return -ENOMEM;
result = cp210x_read_vendor_block(serial,
REQTYPE_DEVICE_TO_HOST,
CP210X_READ_2NCONFIG,
config_buf,
config_size);
if (result < 0) {
kfree(config_buf);
return result;
}
config_version = config_buf[CP210X_2NCONFIG_CONFIG_VERSION_IDX];
gpio_pushpull = config_buf[CP210X_2NCONFIG_GPIO_MODE_IDX];
gpio_ctrl = config_buf[CP210X_2NCONFIG_GPIO_CONTROL_IDX];
gpio_rst_latch = config_buf[CP210X_2NCONFIG_GPIO_RSTLATCH_IDX];
kfree(config_buf);
/* Make sure this is a config format we understand. */
if (config_version != 0x01)
return -ENOTSUPP;
priv->gc.ngpio = 4;
/*
* Get default pin states after reset. Needed so we can determine
* the direction of an open-drain pin.
*/
gpio_latch = (gpio_rst_latch >> 3) & 0x0f;
/* 0 indicates open-drain mode, 1 is push-pull */
priv->gpio_pushpull = (gpio_pushpull >> 3) & 0x0f;
/* 0 indicates GPIO mode, 1 is alternate function */
USB: serial: cp210x: fix alternate function for CP2102N QFN20 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: c8acfe0aadbe ("USB: serial: cp210x: implement GPIO support for CP2102N") Cc: stable@vger.kernel.org # 4.19 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-05-28 20:39:31 +00:00
if (priv->partnum == CP210X_PARTNUM_CP2102N_QFN20) {
/* QFN20 is special... */
if (gpio_ctrl & CP2102N_QFN20_GPIO0_CLK_MODE) /* GPIO 0 */
priv->gpio_altfunc |= BIT(0);
if (gpio_ctrl & CP2102N_QFN20_GPIO1_RS485_MODE) /* GPIO 1 */
priv->gpio_altfunc |= BIT(1);
if (gpio_ctrl & CP2102N_QFN20_GPIO2_TXLED_MODE) /* GPIO 2 */
priv->gpio_altfunc |= BIT(2);
if (gpio_ctrl & CP2102N_QFN20_GPIO3_RXLED_MODE) /* GPIO 3 */
priv->gpio_altfunc |= BIT(3);
} else {
priv->gpio_altfunc = (gpio_ctrl >> 2) & 0x0f;
}
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
USB: serial: cp210x: support all gpios on CP2102N QFN28 package The QFN28 package version of the CP2102N has three additional gpio pins. Add support for these. Signed-off-by: Mans Rullgard <mans@mansr.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-24 13:48:39 +00:00
if (priv->partnum == CP210X_PARTNUM_CP2102N_QFN28) {
/*
* For the QFN28 package, GPIO4-6 are controlled by
* the low three bits of the mode/latch fields.
* Contrary to the document linked above, the bits for
* the SUSPEND pins are elsewhere. No alternate
* function is available for these pins.
*/
priv->gc.ngpio = 7;
gpio_latch |= (gpio_rst_latch & 7) << 4;
priv->gpio_pushpull |= (gpio_pushpull & 7) << 4;
}
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
/*
* The CP2102N does not strictly has input and output pin modes,
* it only knows open-drain and push-pull modes which is set at
* factory. An open-drain pin can function both as an
* input or an output. We emulate input mode for open-drain pins
* by making sure they are not driven low, and we do not allow
* push-pull pins to be set as an input.
*/
for (i = 0; i < priv->gc.ngpio; ++i) {
/*
* Set direction to "input" iff pin is open-drain and reset
* value is 1.
*/
if (!(priv->gpio_pushpull & BIT(i)) && (gpio_latch & BIT(i)))
priv->gpio_input |= BIT(i);
}
return 0;
}
static int cp210x_gpio_init(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
int result;
switch (priv->partnum) {
USB: serial: cp210x: add GPIO support for CP2104 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: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-01-28 05:57:17 +00:00
case CP210X_PARTNUM_CP2104:
result = cp2104_gpioconf_init(serial);
break;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
case CP210X_PARTNUM_CP2105:
result = cp2105_gpioconf_init(serial);
break;
USB: serial: cp210x: add support for GPIOs on CP2108 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>
2021-06-10 13:28:44 +00:00
case CP210X_PARTNUM_CP2108:
/*
* The GPIOs are not tied to any specific port so only register
* once for interface 0.
*/
if (cp210x_interface_num(serial) != 0)
return 0;
result = cp2108_gpio_init(serial);
break;
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
case CP210X_PARTNUM_CP2102N_QFN28:
case CP210X_PARTNUM_CP2102N_QFN24:
case CP210X_PARTNUM_CP2102N_QFN20:
result = cp2102n_gpioconf_init(serial);
break;
default:
return 0;
}
if (result < 0)
return result;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
priv->gc.label = "cp210x";
priv->gc.get_direction = cp210x_gpio_direction_get;
priv->gc.direction_input = cp210x_gpio_direction_input;
priv->gc.direction_output = cp210x_gpio_direction_output;
priv->gc.get = cp210x_gpio_get;
priv->gc.set = cp210x_gpio_set;
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-23 12:34:34 +00:00
priv->gc.set_config = cp210x_gpio_set_config;
USB: serial: cp210x: provide gpio valid mask 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>
2021-04-09 15:52:15 +00:00
priv->gc.init_valid_mask = cp210x_gpio_init_valid_mask;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
priv->gc.owner = THIS_MODULE;
priv->gc.parent = &serial->interface->dev;
priv->gc.base = -1;
priv->gc.can_sleep = true;
result = gpiochip_add_data(&priv->gc, serial);
if (!result)
USB: serial: cp210x: use bool for registered flag Use bool rather than u8 for the gpio-chip-registered flag. Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-24 09:58:12 +00:00
priv->gpio_registered = true;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
return result;
}
static void cp210x_gpio_remove(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
if (priv->gpio_registered) {
gpiochip_remove(&priv->gc);
USB: serial: cp210x: use bool for registered flag Use bool rather than u8 for the gpio-chip-registered flag. Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-24 09:58:12 +00:00
priv->gpio_registered = false;
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
}
#else
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
static int cp210x_gpio_init(struct usb_serial *serial)
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
{
return 0;
}
static void cp210x_gpio_remove(struct usb_serial *serial)
{
/* Nothing to do */
}
#endif
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
static int cp210x_port_probe(struct usb_serial_port *port)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
struct usb_serial *serial = port->serial;
struct cp210x_port_private *port_priv;
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
port_priv = kzalloc(sizeof(*port_priv), GFP_KERNEL);
if (!port_priv)
USB: cp210x: fix port-data memory leak Fix port data memory leak by replacing port private data with serial private data. Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no driver is bound) the port private data is no longer freed at release. The private data is used to store the control interface number, but as this is the same for all ports on an interface it should be stored as usb-serial data anyway. Cc: <stable@vger.kernel.org> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-15 13:47:20 +00:00
return -ENOMEM;
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
port_priv->bInterfaceNumber = cp210x_interface_num(serial);
USB: serial: cp210x: suppress modem-control errors 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>
2021-01-25 13:48:11 +00:00
mutex_init(&port_priv->mutex);
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
usb_set_serial_port_data(port, port_priv);
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
return 0;
}
USB: serial: make remove callback return void 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>
2021-02-08 14:31:49 +00:00
static void cp210x_port_remove(struct usb_serial_port *port)
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
{
USB: cp210x: relocate private data from USB interface to port This change is preparation for implementing a cp2108 bug workaround. The workaround requires storing some private data. Right now the data is attached to the USB interface and allocated in the attach() callback. The bug detection requires USB I/O which is done easier from port_probe() callback rather than attach(). Since the USB access functions take port as a parameter, and since the private data is used exclusively by these functions, it can be allocated in port_probe(). Also, all cp210x devices have exactly 1 port per USB iterface, so moving private data from the USB interface to port is trivial. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-10-28 21:02:34 +00:00
struct cp210x_port_private *port_priv;
port_priv = usb_get_serial_port_data(port);
kfree(port_priv);
usb: cp210x: Update to support CP2105 and multiple interface devices This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-24 19:42:39 +00:00
}
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
static void cp210x_init_max_speed(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
bool use_actual_rate = false;
USB: serial: cp210x: add minimum baud rate for CP2105 SCI 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: Johanna 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: Johan Hovold <johan@kernel.org>
2019-02-06 08:56:15 +00:00
speed_t min = 300;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
speed_t max;
switch (priv->partnum) {
case CP210X_PARTNUM_CP2101:
max = 921600;
break;
case CP210X_PARTNUM_CP2102:
case CP210X_PARTNUM_CP2103:
max = 1000000;
break;
case CP210X_PARTNUM_CP2104:
USB: serial: cp210x: improve line-speed handling for CP2104 and CP2105 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>
2018-07-18 12:25:01 +00:00
use_actual_rate = true;
max = 2000000;
break;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
case CP210X_PARTNUM_CP2108:
max = 2000000;
break;
case CP210X_PARTNUM_CP2105:
USB: serial: cp210x: improve line-speed handling for CP2104 and CP2105 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>
2018-07-18 12:25:01 +00:00
if (cp210x_interface_num(serial) == 0) {
use_actual_rate = true;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
max = 2000000; /* ECI */
USB: serial: cp210x: improve line-speed handling for CP2104 and CP2105 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>
2018-07-18 12:25:01 +00:00
} else {
USB: serial: cp210x: add minimum baud rate for CP2105 SCI 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: Johanna 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: Johan Hovold <johan@kernel.org>
2019-02-06 08:56:15 +00:00
min = 2400;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
max = 921600; /* SCI */
USB: serial: cp210x: improve line-speed handling for CP2104 and CP2105 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>
2018-07-18 12:25:01 +00:00
}
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
break;
USB: serial: cp210x: improve baudrate support for CP2102N 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>
2018-07-18 12:24:59 +00:00
case CP210X_PARTNUM_CP2102N_QFN28:
case CP210X_PARTNUM_CP2102N_QFN24:
case CP210X_PARTNUM_CP2102N_QFN20:
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
use_actual_rate = true;
USB: serial: cp210x: improve baudrate support for CP2102N 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>
2018-07-18 12:24:59 +00:00
max = 3000000;
break;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
default:
max = 2000000;
break;
}
USB: serial: cp210x: add minimum baud rate for CP2105 SCI 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: Johanna 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: Johan Hovold <johan@kernel.org>
2019-02-06 08:56:15 +00:00
priv->min_speed = min;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
priv->max_speed = max;
USB: serial: cp210x: generalise CP2102N line-speed handling 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>
2018-07-18 12:25:00 +00:00
priv->use_actual_rate = use_actual_rate;
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
}
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
static int cp210x_get_fw_version(struct usb_serial *serial, u16 value)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
u8 ver[3];
int ret;
ret = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST, value,
ver, sizeof(ver));
if (ret)
return ret;
dev_dbg(&serial->interface->dev, "%s - %d.%d.%d\n", __func__,
ver[0], ver[1], ver[2]);
priv->fw_version = ver[0] << 16 | ver[1] << 8 | ver[2];
return 0;
}
static void cp210x_determine_quirks(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
int ret;
switch (priv->partnum) {
case CP210X_PARTNUM_CP2102N_QFN28:
case CP210X_PARTNUM_CP2102N_QFN24:
case CP210X_PARTNUM_CP2102N_QFN20:
ret = cp210x_get_fw_version(serial, CP210X_GET_FW_VER_2N);
if (ret)
break;
if (priv->fw_version <= 0x10004)
priv->no_flow_control = true;
break;
default:
break;
}
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
static int cp210x_attach(struct usb_serial *serial)
{
int result;
struct cp210x_serial_private *priv;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
CP210X_GET_PARTNUM, &priv->partnum,
sizeof(priv->partnum));
USB: serial: cp210x: fix partnum regression When adding GPIO support for the cp2105, the mentioned commit by Martyn Welch introduced a query for the part number of the chip. Unfortunately the driver aborts probing when this query fails, so currently the driver can not be used with chips not supporting this query. I have a data cable for Siemens mobile phones (ID 10ab:10c5) where this is the case. With this patch the driver can be bound even if the part number can not be queried. Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105") Signed-off-by: Sebastian Frei <dr.nop@gmx.net> [ johan: amend commit message; shorten error message and demote to warning; drop unnecessary move of usb_set_serial_data() ] Cc: stable <stable@vger.kernel.org> # 4.9 Signed-off-by: Johan Hovold <johan@kernel.org>
2017-09-12 07:50:59 +00:00
if (result < 0) {
dev_warn(&serial->interface->dev,
"querying part number failed\n");
priv->partnum = CP210X_PARTNUM_UNKNOWN;
}
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
usb_set_serial_data(serial, priv);
USB: serial: cp210x: fix CP2102N-A01 modem control 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: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-09 16:15:09 +00:00
cp210x_determine_quirks(serial);
USB: serial: cp210x: honour device-type maximum line speed 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>
2018-07-18 12:24:58 +00:00
cp210x_init_max_speed(serial);
USB: serial: cp210x: implement GPIO support for CP2102N 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>
2018-07-20 10:52:40 +00:00
result = cp210x_gpio_init(serial);
if (result < 0) {
dev_err(&serial->interface->dev, "GPIO initialisation failed: %d\n",
result);
USB: serial: cp210x: Adding GPIO support for CP2105 This patch adds support for the GPIO found on the CP2105. Unlike the GPIO provided by some of the other devices supported by the cp210x driver, the GPIO on the CP2015 is muxed on pins otherwise used for serial control lines. The GPIO have been configured in 2 separate banks as the choice to configure the pins for GPIO is made separately for pins shared with each of the 2 serial ports this device provides, though the choice is made for all pins associated with that port in one go. The choice of whether to use the pins for GPIO or serial is made by adding configuration to a one-time programable PROM in the chip and can not be changed at runtime. The device defaults to GPIO. This device supports either push-pull or open-drain modes, it doesn't provide an explicit input mode, though the state of the GPIO can be read when used in open-drain mode. Like with pin use, the mode is configured in the one-time programable PROM and can't be changed at runtime. Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20 14:13:54 +00:00
}
return 0;
}
static void cp210x_disconnect(struct usb_serial *serial)
{
cp210x_gpio_remove(serial);
}
static void cp210x_release(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
cp210x_gpio_remove(serial);
kfree(priv);
}
USB: serial: rework usb_serial_register/deregister_drivers() This reworks the usb_serial_register_drivers() and usb_serial_deregister_drivers() to not need a pointer to a struct usb_driver anymore. The usb_driver structure is now created dynamically and registered and unregistered as needed. This saves lines of code in each usb-serial driver. All in-kernel users of these functions were also fixed up at this time. The pl2303 driver was tested that everything worked properly. Thanks for the idea to do this from Alan Stern. Cc: Adhir Ramjiawan <adhirramjiawan0@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Al Borchers <alborchers@steinerpoint.com> Cc: Aleksey Babahin <tamerlan311@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andrew Worsley <amworsley@gmail.com> Cc: Bart Hartgers <bart.hartgers@gmail.com> Cc: Bill Pemberton <wfp5p@virginia.edu> Cc: Dan Carpenter <error27@gmail.com> Cc: Dan Williams <dcbw@redhat.com> Cc: Donald Lee <donald@asix.com.tw> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Gary Brubaker <xavyer@ix.netcom.com> Cc: Jesper Juhl <jj@chaosbits.net> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Johan Hovold <jhovold@gmail.com> Cc: Julia Lawall <julia@diku.dk> Cc: Kautuk Consul <consul.kautuk@gmail.com> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: Lonnie Mendez <dignome@gmail.com> Cc: Matthias Bruestle and Harald Welte <support@reiner-sct.com> Cc: Matthias Urlichs <smurf@smurf.noris.de> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Michal Sroczynski <msroczyn@gmail.com> Cc: "Michał Wróbel" <michal.wrobel@flytronic.pl> Cc: Oliver Neukum <oliver@neukum.name> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Peter Berger <pberger@brimson.com> Cc: Preston Fick <preston.fick@silabs.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Rigbert Hamisch <rigbert@gmx.de> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Simon Arlott <simon@fire.lp0.eu> Cc: Support Department <support@connecttech.com> Cc: Thomas Tuttle <ttuttle@chromium.org> Cc: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> Cc: Wang YanQing <Udknight@gmail.com> Cc: William Greathouse <wgreathouse@smva.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-08 22:46:14 +00:00
module_usb_serial_driver(serial_drivers, id_table);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
MODULE_DESCRIPTION(DRIVER_DESC);
USB: serial: fix module-license macros Several GPL-2.0 drivers used "GPL" rather than "GPL v2" in their MODULE_LICENSE macros; fix the macros to match the licenses. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-03 17:12:08 +00:00
MODULE_LICENSE("GPL v2");
Reference in New Issue Copy Permalink