- 10 6月, 2021 1 次提交
-
-
由 Stefan Agner 提交于
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: NStefan Agner <stefan@agner.ch> Link: https://lore.kernel.org/r/51830b2b24118eb0f77c5c9ac64ffb2f519dbb1d.1622218300.git.stefan@agner.ch Fixes: c8acfe0a ("USB: serial: cp210x: implement GPIO support for CP2102N") Cc: stable@vger.kernel.org # 4.19 Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 12 4月, 2021 2 次提交
-
-
由 Johan Hovold 提交于
Add a debug printk to dump the GPIO configuration stored in EEPROM during probe. Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
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: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 09 3月, 2021 2 次提交
-
-
由 Sebastian Reichel 提交于
GE CS1000 has some more custom USB IDs for CP2102N; add them to the driver to have working auto-probing. Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Karan Singhal 提交于
IDs of nLight Air Adapter, Acuity Brands, Inc.: vid: 10c4 pid: 88d8 Signed-off-by: NKaran Singhal <karan.singhal@acuitybrands.com> Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 09 2月, 2021 1 次提交
-
-
由 Uwe Kleine-König 提交于
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: NUwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210208143149.963644-2-uwe@kleine-koenig.orgSigned-off-by: NJohan Hovold <johan@kernel.org>
-
- 01 2月, 2021 7 次提交
-
-
由 Johan Hovold 提交于
Clear the RTS bits of the flow-control request before determining the new value when updating the settings. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
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: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Use the 0-flag and a field width to specify zero-padding consistently in printk messages. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
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: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
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: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
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: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
The CP210X_SET_MHS request cannot be used to control RTS when hardware flow control (auto-RTS) is enabled and instead returns an error which is currently logged as: cp210x ttyUSB0: failed set request 0x7 status: -32 when opening and closing a port (and on TIOCMSET requests). Add a crtscts flag to keep track of the hardware flow-control setting and use it to suppress any request to change RTS when auto-RTS is enabled. Note that RTS is still deasserted when disabling the UART as part of close. Reported-by: NPho Tran <pho.tran@silabs.com> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 25 1月, 2021 1 次提交
-
-
由 Pho Tran 提交于
Information pid/vid of WSDA-200-USB, Lord corporation company: vid: 199b pid: ba30 Signed-off-by: NPho Tran <pho.tran@silabs.com> [ johan: amend comment with product name ] Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 18 1月, 2021 6 次提交
-
-
由 Johan Hovold 提交于
Add a copyright notice for myself. Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Drop include directives that are no longer used. Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
There's no need to check for short control transfers when sending data so remove the redundant sanity checks. Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Update the XON/XOFF control characters also when no other flow-control flag has changed and software flow control is enabled. Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
At least CP2102 requires the XON/XOFF limits to be initialised in order for software input flow control (IXOFF) to work. Specifically, XOFF is never sent if the XOFF limit is left at its default value of zero. Set the limits so that input is throttled when the FIFO free level drops below 128 bytes and restarted when the FIFO fill level drops below 128 bytes. Note that the threshold values have been chosen so that they can be used also with CP2105 which has the smallest FIFO of the currently supported device types (288 byte for the SCI port). If needed the limits can be made device specific later. Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Wang Sheng Long 提交于
When data is transmitted between two serial ports, the phenomenon of data loss often occurs. The two kinds of flow control commonly used in serial communication are hardware flow control and software flow control. In serial communication, If you only use RX/TX/GND Pins, you can't do hardware flow. So we often used software flow control and prevent data loss. The user sets the software flow control through the application program, and the application program sets the software flow control mode for the serial port chip through the driver. For the cp210 serial port chip, its driver lacks the software flow control setting code, so the user cannot set the software flow control function through the application program. This adds the missing software flow control. Signed-off-by: NWang Sheng Long <shenglong.wang.ext@siemens.com> Link: https://lore.kernel.org/r/20210104094502.3942-1-china_shenglong@163.com [ johan: rework properly on top of recent termios changes ] Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 13 1月, 2021 1 次提交
-
-
由 Chenxin Jin 提交于
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: NChenxin Jin <bg4akv@hotmail.com> Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 04 12月, 2020 6 次提交
-
-
由 Johan Hovold 提交于
Clean up dtr_rts() by renaming the port parameter and adding missing whitespace. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Add a helper function to be used to configure flow control. The flow-control code was the last caller that relied on the memset-on-failure behaviour of cp210x_read_reg_block(), which we can now drop in favour of bailing out on errors when retrieving the flow-control settings. This should also simplify adding support for software flow control. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Drop some unnecessary flow-control debugging. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Unlike other drivers cp210x have been retrieving the current terminal settings from the device on open and reflecting those in termios. Due to how set_termios() used to be implemented, this saved a few control requests on open but has instead caused problems like broken flow control and has required adding workarounds for swapped line-control in cp2108 and line-speed initialisation on cp2104. This unusual implementation also complicates adding new features for no good reason. Rip out the corresponding code and the above mentioned workarounds and instead initialise the terminal settings unconditionally on open. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Update the line-control settings in one request unconditionally instead of setting the word-length, parity and stop-bit settings separately. This avoids multiple requests when several settings are changed even if this scheme could potentially also be used to detect unsupported device settings. Since all device types but CP2101 appears to support all settings, let's handle that one specifically and also report back the unsupported settings properly through termios by clearing the corresponding bits. Also drop the related unnecessary debug printks. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Return early from set_termios() in case no relevant terminal settings have changed. This avoids testing each parameter in turn and specifically allows the line-control handling to be cleaned up further. Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 14 7月, 2020 5 次提交
-
-
由 Johan Hovold 提交于
The port data is not exported to user space so use the in-kernel u8 type. Link: https://lore.kernel.org/r/20200713105517.27796-6-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Drop unnecessary packed attributes from structs without padding. Link: https://lore.kernel.org/r/20200713105517.27796-5-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Enable TIOCGICOUNT to allow reading out the (unused) interrupt counters and error statistics. Note that modem-status events are currently left unimplemented as they appear to be buffered on at least CP2102 and therefore cannot be used to implement TIOCMIWAIT. Link: https://lore.kernel.org/r/20200713105517.27796-4-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Add support for line-status events that specifically can be used to detect and report parity errors. Enable the device's event-insertion mode whenever input-parity checking is requested. This will insert line and modem status events into the data stream. Note that modem-status changes appear to be buffered until a character is received (at least on CP2102) and support is therefore left unimplemented. On at least one type of these chips (CP2102), line breaks are not reported as expected either (regardless of whether SERIAL_BREAK_CHAR is set) so do not enable event-mode when !IGNBRK is requested for now. Link: https://lore.kernel.org/r/20200713105517.27796-3-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Try to disable the serial interface in the unlikely event that generic open() fails. Link: https://lore.kernel.org/r/20200713105517.27796-2-johan@kernel.orgReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 06 7月, 2020 2 次提交
-
-
由 Brant Merryman 提交于
CP210x hardware disables auto-RTS but leaves auto-CTS when in hardware flow control mode and UART on cp210x hardware is disabled. When re-opening the port, if auto-CTS is enabled on the cp210x, then auto-RTS must be re-enabled in the driver. Signed-off-by: NBrant Merryman <brant.merryman@silabs.com> Co-developed-by: NPhu Luu <phu.luu@silabs.com> Signed-off-by: NPhu Luu <phu.luu@silabs.com> Link: https://lore.kernel.org/r/ECCF8E73-91F3-4080-BE17-1714BC8818FB@silabs.com [ johan: fix up tags and problem description ] Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control") Cc: stable <stable@vger.kernel.org> # 2.6.12 Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Brant Merryman 提交于
Assign the .throttle and .unthrottle functions to be generic function in the driver structure to prevent data loss that can otherwise occur if the host does not enable USB throttling. Signed-off-by: NBrant Merryman <brant.merryman@silabs.com> Co-developed-by: NPhu Luu <phu.luu@silabs.com> Signed-off-by: NPhu Luu <phu.luu@silabs.com> Link: https://lore.kernel.org/r/57401AF3-9961-461F-95E1-F8AFC2105F5E@silabs.com [ johan: fix up tags ] Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control") Cc: stable <stable@vger.kernel.org> # 2.6.12 Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 18 11月, 2019 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Add support for the Mark-10 digital force gauge device to the cp201x driver. Based on a report and a larger patch from Joel Jennings Reported-by: NJoel Jennings <joel.jennings@makeitlabs.com> Cc: stable <stable@vger.kernel.org> Acked-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 28 3月, 2019 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Lorenz Messtechnik has a device that is controlled by the cp210x driver, so add the device id to the driver. The device id was provided by Silicon-Labs for the devices from this vendor. Reported-by: NUli <t9cpu@web.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 20 2月, 2019 1 次提交
-
-
由 Karoly Pados 提交于
Current GPIO code in cp210x fails to take USB autosuspend into account, making it practically impossible to use GPIOs with autosuspend enabled without user configuration. Fix this like for ftdi_sio in a previous patch. Tested on a CP2102N. Signed-off-by: NKaroly Pados <pados@pados.hu> Fixes: cf5276ce ("USB: serial: cp210x: Adding GPIO support for CP2105") Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 07 2月, 2019 2 次提交
-
-
由 Ivan Mironov 提交于
Here is how this device appears in kernel log: usb 3-1: new full-speed USB device number 18 using xhci_hcd usb 3-1: New USB device found, idVendor=0b00, idProduct=3070 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1: Product: Ingenico 3070 usb 3-1: Manufacturer: Silicon Labs usb 3-1: SerialNumber: 0001 Apparently this is a POS terminal with embedded USB-to-Serial converter. Cc: stable@vger.kernel.org Signed-off-by: NIvan Mironov <mironov.ivan@gmail.com> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johanna Abrahamsson 提交于
Add minimum baud rate to the cp210x driver. According to the datasheet for CP2105, the SCI supports 2400 as the lowest baud rate. As this is not heeded in the current code, an error message 'failed set req 0x1e size 4 status: -32' when trying to set a lower baud rate such as 300. The other cp210x models to date supports a minimum baud rate of 300. Signed-off-by: NJohanna Abrahamsson <johanna.abrahamsson@afconsult.com> [ johan: simplify min_speed init, move clamp after comment, and drop unused serial-data pointer from cp210x_get_actual_rate() ] Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 05 2月, 2019 1 次提交
-
-
由 Icenowy Zheng 提交于
The CP2104 chips feature 4 controllable GPIO pins, which are similar to the ones on CP2102N chip (output-only when push-pull, output or simulated input mode when open-drain). Add support for the GPIO pins for cp210x driver. The pin get/set routine is shared with CP2102N, but the pinconf initialization code is not shared because the acquisition of GPIO configuration in OTP ROM is similar to CP2105, not CP2102N. Signed-off-by: NIcenowy Zheng <icenowy@aosc.io> Signed-off-by: NJohan Hovold <johan@kernel.org>
-