aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/serial/ch341.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2022-09-05Merge 6.0-rc4 into tty-nextGreg Kroah-Hartman1-2/+14
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-31USB: serial: ch341: fix disabled rx timer on older devicesJohan Hovold1-1/+5
At least one older CH341 appears to have the RX timer enable bit inverted so that setting it disables the RX timer and prevents the FIFO from emptying until it is full. Only set the RX timer enable bit for devices with version newer than 0x27 (even though this probably affects all pre-0x30 devices). Reported-by: Jonathan Woithe <jwoithe@just42.net> Tested-by: Jonathan Woithe <jwoithe@just42.net> Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au Fixes: 4e46c410e050 ("USB: serial: ch341: reinitialize chip on reconfiguration") Cc: stable@vger.kernel.org # 4.10 Signed-off-by: Johan Hovold <johan@kernel.org>
2022-08-31USB: serial: ch341: fix lost character on LCR updatesJohan Hovold1-1/+9
Disable LCR updates for pre-0x30 devices which use a different (unknown) protocol for line control and where the current register write causes the next received character to be lost. Note that updating LCR using the INIT command has no effect on these devices either. Reported-by: Jonathan Woithe <jwoithe@just42.net> Tested-by: Jonathan Woithe <jwoithe@just42.net> Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au Fixes: 4e46c410e050 ("USB: serial: ch341: reinitialize chip on reconfiguration") Fixes: 55fa15b5987d ("USB: serial: ch341: fix baud rate and line-control handling") Cc: stable@vger.kernel.org # 4.10 Signed-off-by: Johan Hovold <johan@kernel.org>
2022-08-30usb: serial: Make ->set_termios() old ktermios constIlpo Järvinen1-2/+3
There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220816115739.10928-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-21Revert "USB: serial: ch341: add new Product ID for CH341A"Dmytro Bagrii1-1/+0
This reverts commit 46ee4abb10a07bd8f8ce910ee6b4ae6a947d7f63. CH341 has Product ID 0x5512 in EPP/MEM mode which is used for I2C/SPI/GPIO interfaces. In asynchronous serial interface mode CH341 has PID 0x5523 which is already in the table. Mode is selected by corresponding jumper setting. Signed-off-by: Dmytro Bagrii <dimich.dmb@gmail.com> Link: https://lore.kernel.org/r/20220210164137.4376-1-dimich.dmb@gmail.com Link: https://lore.kernel.org/r/YJ0OCS/sh+1ifD/q@hovoldconsulting.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2022-01-31USB: serial: ch341: add support for GW Instek USB2.0-Serial devicesStephan Brunner1-0/+1
Programmable lab power supplies made by GW Instek, such as the GPP-2323, have a USB port exposing a serial port to control the device. Stringing the supplied Windows driver, references to the ch341 chip are found. Binding the existing ch341 driver to the VID/PID of the GPP-2323 ("GW Instek USB2.0-Serial" as per the USB product name) works out of the box, communication and control is now possible. This patch should work with any GPP series power supply due to similarities in the product line. Signed-off-by: Stephan Brunner <s.brunner@stephan-brunner.net> Link: https://lore.kernel.org/r/4a47b864-0816-6f6a-efee-aa20e74bcdc6@stephan-brunner.net Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2021-10-27USB: serial: ch314: use usb_control_msg_recv()Himadri Pandya1-59/+26
usb_control_msg_recv() is a new wrapper function for usb_control_msg() that has error checks for short reads. This function also accepts data buffer on stack. Hence use this function to simplify error handling for short reads. Short reads will now get reported as -EREMOTEIO with no indication of how short the transfer was. Signed-off-by: Himadri Pandya <himadrispandya@gmail.com> Link: https://lore.kernel.org/r/20211001065720.21330-2-himadrispandya@gmail.com [ johan: fix quirk-detection breakage, style changes ] Signed-off-by: Johan Hovold <johan@kernel.org>
2021-08-25Revert "USB: serial: ch341: fix character loss at high transfer rates"Johan Hovold1-1/+0
This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b. These devices do not appear to send a zero-length packet when the transfer size is a multiple of the bulk-endpoint max-packet size. This means that incoming data may not be processed by the driver until a short packet is received or the receive buffer is full. Revert back to using endpoint-sized receive buffers to avoid stalled reads. Reported-by: Paul Größel <pb.g@gmx.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131 Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates") Cc: stable@vger.kernel.org Cc: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2021-07-29USB: serial: ch341: fix character loss at high transfer ratesWilly Tarreau1-0/+1
The chip supports high transfer rates, but with the small default buffers (64 bytes read), some entire blocks are regularly lost. This typically happens at 1.5 Mbps (which is the default speed on Rockchip devices) when used as a console to access U-Boot where the output of the "help" command misses many lines and where "printenv" mangles the environment. The FTDI driver doesn't suffer at all from this. One difference is that it uses 512 bytes rx buffers and 256 bytes tx buffers. Adopting these values completely resolved the issue, even the output of "dmesg" is reliable. I preferred to leave the Tx value unchanged as it is not involved in this issue, while a change could increase the risk of triggering the same issue with other devices having too small buffers. I verified that it backports well (and works) at least to 5.4. It's of low importance enough to be dropped where it doesn't trivially apply anymore. Cc: stable@vger.kernel.org Signed-off-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20210724152739.18726-1-w@1wt.eu Signed-off-by: Johan Hovold <johan@kernel.org>
2021-03-09USB: serial: ch341: add new Product IDNiv Sardi1-0/+1
Add PID for CH340 that's found on cheap programmers. The driver works flawlessly as soon as the new PID (0x9986) is added to it. These look like ANU232MI but ship with a ch341 inside. They have no special identifiers (mine only has the string "DB9D20130716" printed on the PCB and nothing identifiable on the packaging. The merchant i bought it from doesn't sell these anymore). the lsusb -v output is: Bus 001 Device 009: ID 9986:7523 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x9986 idProduct 0x7523 bcdDevice 2.54 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 96mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Signed-off-by: Niv Sardi <xaiki@evilgiggle.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2021-02-09USB: serial: make remove callback return voidUwe Kleine-König1-3/+1
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>
2020-12-03USB: serial: ch341: sort device-id entriesJohan Hovold1-3/+3
Keep the device-id entries sorted to make it easier to add new ones in the right spot. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2020-12-03USB: serial: ch341: add new Product ID for CH341AJan-Niklas Burfeind1-0/+1
Add PID for CH340 that's found on a ch341 based Programmer made by keeyees. The specific device that contains the serial converter is described here: http://www.keeyees.com/a/Products/ej/36.html The driver works flawlessly as soon as the new PID (0x5512) is added to it. Signed-off-by: Jan-Niklas Burfeind <kernel@aiyionpri.me> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-28Merge tag 'usb-serial-5.9-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-nextGreg Kroah-Hartman1-12/+115
Johan writes: USB-serial updates for 5.9-rc1 Here are the USB-serial updates for 5.9-rc1, including: - console flow-control support - simulated line-breaks on some ch341 - hardware flow-control fixes for cp210x - break-detection and sysrq fixes for ftdi_sio - sysrq optimisations - input parity checking for cp210x Included are also some new device ids and various clean ups. All have been in linux-next with no reported issues. * tag 'usb-serial-5.9-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (31 commits) USB: serial: qcserial: add EM7305 QDL product ID USB: serial: iuu_phoenix: fix led-activity helpers USB: serial: sierra: clean up special-interface handling USB: serial: cp210x: use in-kernel types in port data USB: serial: cp210x: drop unnecessary packed attributes USB: serial: cp210x: add support for TIOCGICOUNT USB: serial: cp210x: add support for line-status events USB: serial: cp210x: disable interface on errors in open USB: serial: drop redundant transfer-buffer casts USB: serial: drop extern keyword from function declarations USB: serial: drop unnecessary sysrq include USB: serial: add sysrq break-handler dummy USB: serial: inline sysrq dummy function USB: serial: only process sysrq when enabled USB: serial: only set sysrq timestamp for consoles USB: serial: ftdi_sio: fix break and sysrq handling USB: serial: ftdi_sio: clean up receive processing USB: serial: ftdi_sio: make process-packet buffer unsigned USB: serial: use fallthrough pseudo-keyword USB: serial: ch341: fix missing simulated-break margin ...
2020-07-07USB: serial: ch341: fix missing simulated-break marginMichael Hanselmann1-4/+6
On devices which do not support break signalling a break condition is simulated by sending a NUL byte at the lowest possible speed. The break condition will be 9 bit periods long (start bit and eight data bits), but the transmission itself also includes the stop bit. Add the missing safety margin of one bit which is intended to account for timing differences, and fix up the corresponding comment. Signed-off-by: Michael Hanselmann <public@hansmi.ch> Link: https://lore.kernel.org/r/9909b288-294d-16b9-9f14-51eb79c63b6c@msgid.hansmi.ch [ johan: amend commit message ] Signed-off-by: Johan Hovold <johan@kernel.org>
2020-07-06USB: serial: ch341: simulate break condition if not supportedMichael Hanselmann1-9/+93
A subset of all CH341 devices don't support a real break condition. This fact is already used in the "ch341_detect_quirks" function. With this change a quirk is implemented to simulate a break condition by temporarily lowering the baud rate and sending a NUL byte. The primary drawbacks of this approach are that the duration of the break can't be controlled by userland and that data incoming during a simulated break is corrupted. The "TTY_DRIVER_HARDWARE_BREAK" serial driver flag was investigated as an alternative. It's a driver-wide flag and would've required significant changes to the serial and USB-serial driver frameworks to expose it for individual USB-serial adapters. Tested by sending a break condition and watching the TX pin using an oscilloscope. Signed-off-by: Michael Hanselmann <public@hansmi.ch> Link: https://lore.kernel.org/r/f34a9b6e-ec2a-0873-e97b-2d5b2170e2ff@msgid.hansmi.ch [ johan: condense info message ] Signed-off-by: Johan Hovold <johan@kernel.org>
2020-06-30USB: serial: ch341: add min and max line-speed macrosJohan Hovold1-1/+5
The line-speed algorithm clamps the requested value to the supported range instead of bailing out on unsupported values. Provide min and max macros and indicate how they are derived instead of hardcoding the limits. Note that the algorithm depends on the minimum rate (45.78 bps) being rounded up (and the maximum rate being rounded down) to avoid special casing. Suggested-by: Michael Hanselmann <public@hansmi.ch> Link: https://lore.kernel.org/r/20200630095756.GZ3334@localhost Signed-off-by: Johan Hovold <johan@kernel.org>
2020-06-29USB: serial: ch341: name prescaler, divisor registersMichael Hanselmann1-2/+15
Add constants for the prescaler and divisor registers. Document and name register 0x25, and put the LCR define to more use. The 0x25 register (CH341_REG_LCR2) is only used by CH341 chips before version 0x30 and is involved in configuring the line control parameters. It's not known to the author whether there any such chips in the wild, and Linux' ch341 driver never supported them. For chip version 0x30 and above the 0x25 register is always set to zero. The alternative would've been to not set the register at all, but that may have unintended effects. Signed-off-by: Michael Hanselmann <public@hansmi.ch> Link: https://lore.kernel.org/r/2e80916d-1be8-dc0f-abf9-adc0feea1803@msgid.hansmi.ch [ johan: fix up comment ] Signed-off-by: Johan Hovold <johan@kernel.org>
2020-06-23USB: serial: ch341: add new Product ID for CH340Igor Moura1-0/+1
Add PID for CH340 that's found on some ESP8266 dev boards made by LilyGO. The specific device that contains such serial converter can be seen here: https://github.com/LilyGO/LILYGO-T-OI. Apparently, it's a regular CH340, but I've confirmed with others that also bought this board that the PID found on this device (0x7522) differs from other devices with the "same" converter (0x7523). Simply adding its PID to the driver and rebuilding it made it work as expected. Signed-off-by: Igor Moura <imphilippini@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2020-05-27USB: serial: ch341: fix lockup of devices with limited prescalerJohan Hovold1-3/+12
Michael Hanselmann reports that [a] subset of all CH341 devices stop responding to bulk transfers, usually after the third byte, when the highest prescaler bit (0b100) is set. There is one exception, namely a prescaler of exactly 0b111 (fact=1, ps=3). Fix this by forcing a lower base clock (fact = 0) whenever needed. This specifically makes the standard rates 110, 134 and 200 bps work again with these devices. Fixes: 35714565089e ("USB: serial: ch341: reimplement line-speed handling") Cc: stable <stable@vger.kernel.org> # 5.5 Reported-by: Michael Hanselmann <public@hansmi.ch> Link: https://lore.kernel.org/r/20200514141743.GE25962@localhost Signed-off-by: Johan Hovold <johan@kernel.org>
2020-05-27USB: serial: ch341: add basis for quirk detectionMichael Hanselmann1-0/+53
A subset of CH341 devices does not support all features, namely the prescaler is limited to a reduced precision and there is no support for sending a RS232 break condition. This patch adds a detection function which will be extended to set quirk flags as they're implemented. The author's affected device has an imprint of "340" on the turquoise-colored plug, but not all such devices appear to be affected. Signed-off-by: Michael Hanselmann <public@hansmi.ch> Link: https://lore.kernel.org/r/1e1ae0da6082bb528a44ef323d4e1d3733d38858.1585697281.git.public@hansmi.ch [ johan: use long type for quirks; rephrase and use port device for messages; handle short reads; set quirk flags directly in helper function ] Cc: stable <stable@vger.kernel.org> # 5.5 Signed-off-by: Johan Hovold <johan@kernel.org>
2020-02-10USB: serial: ch341: fix receiver regressionJohan Hovold1-0/+10
While assumed not to make a difference, not using the factor-2 prescaler makes the receiver more susceptible to errors. Specifically, there have been reports of problems with devices that cannot generate a 115200 rate with a smaller error than 2.1% (e.g. 117647 bps). But this can also be reproduced with a low-speed RS232 tranceiver at 115200 when the input rate matches the nominal rate. So whenever possible, enable the factor-2 prescaler and halve the divisor in order to use settings closer to that of the previous algorithm. Fixes: 35714565089e ("USB: serial: ch341: reimplement line-speed handling") Cc: stable <stable@vger.kernel.org> # 5.5 Reported-by: Jakub Nantl <jn@forever.cz> Tested-by: Jakub Nantl <jn@forever.cz> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17USB: serial: ch341: handle unbound port at reset_resumeJohan Hovold1-1/+5
Check for NULL port data in reset_resume() to avoid dereferencing a NULL pointer in case the port device isn't bound to a driver (e.g. after a failed control request at port probe). Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after resume") Cc: stable <stable@vger.kernel.org> # 2.6.30 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-11-04USB: serial: ch341: reimplement line-speed handlingJohan Hovold1-22/+75
The current ch341 divisor algorithm was known to give inaccurate results for certain higher line speeds. Jonathan Olds <jontio@i4free.co.nz> investigated this, determined the basic equations used to derive the divisors and confirmed them experimentally [1]. The equations Jonathan used could be generalised further to: baudrate = 48000000 / (2^(12 - 3 * ps - fact) * div), where 0 <= ps <= 3, 0 <= fact <= 1, 2 <= div <= 256 if fact = 0, or 9 <= div <= 256 if fact = 1 which will also give better results for lower rates. Notably the error is reduced for the following standard rates: 1152000 (4.0% instead of 15% error) 921600 (0.16% instead of -7.5% error) 576000 (-0.80% instead of -5.6% error) 200 (0.16% instead of -0.69% error) 134 (-0.05% instead of -0.63% error) 110 (0.03% instead of -0.44% error) but also for many non-standard ones. The current algorithm also suffered from rounding issues (e.g. requesting 2950000 Bd resulted in a rate of 2 MBd instead of 3 MBd and thus a -32% instead of 1.7% error). The new algorithm was inspired by the current vendor driver even if that one only handles two higher rates that require fact=1 by hard coding the corresponding divisors [2]. Michael Dreher <michael@5dot1.de> also did a similar generalisation of Jonathan's work and has published his results with a very good summary that provides further insights into how this device works [3]. [1] https://lkml.kernel.org/r/000001d51f34$bad6afd0$30840f70$@co.nz [2] http://www.wch.cn/download/CH341SER_LINUX_ZIP.html [3] https://github.com/nospam2000/ch341-baudrate-calculation Reported-by: Jonathan Olds <jontio@i4free.co.nz> Tested-by: Jonathan Olds <jontio@i4free.co.nz> Cc: Michael Dreher <michael@5dot1.de> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-07-04USB: serial: ch341: fix type promotion bug in ch341_control_in()Dan Carpenter1-1/+1
The "r" variable is an int and "bufsize" is an unsigned int so the comparison is type promoted to unsigned. If usb_control_msg() returns a negative that is treated as a high positive value and the error handling doesn't work. Fixes: 2d5a9c72d0c4 ("USB: serial: ch341: fix control-message error handling") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-11-04USB: serial: fix module-license macrosJohan Hovold1-1/+1
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-04USB: serial: Remove redundant license textGreg Kroah-Hartman1-4/+0
Now that the SPDX tag is in all USB files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-04USB: add SPDX identifiers to all remaining files in drivers/usb/Greg Kroah-Hartman1-0/+1
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-01-16USB: serial: ch341: change initial line-control settingsJohan Hovold1-9/+5
Some CH340 devices appear unable to change the initial LCR settings, so set a sane 8N1 default during probe to enable basic support for such devices. Also drop a redundant LCR read during device initialisation. Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-16USB: serial: ch341: rename LCR variable in set_termiosJohan Hovold1-12/+12
Rename the line-control-register variable in set_termios to "lcr" and use u8 type to match the shadow register. Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-16USB: serial: ch341: rename modem-status registerJohan Hovold1-8/+8
Rename the shadow modem-status register currently named "line_status" to the less confusing "msr". Also rename the helper function used to parse the interrupt data. Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-16USB: serial: ch341: rename shadow modem-control registerJohan Hovold1-14/+14
Rename the shadow modem-control register currently named "line_control" to the less confusing "mcr". Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-16USB: serial: ch341: clean up control debug messagesJohan Hovold1-5/+4
Clean up the control-transfer debug messages by dropping redundant information and unnecessary casts. Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-16USB: serial: ch341: fix modem-status handlingJohan Hovold1-15/+12
The modem-status register was read as part of device configuration at port_probe and then again at open (and reset-resume). During open (and reset-resume) the MSR was read before submitting the interrupt URB, something which could lead to an MSR-change going unnoticed when it races with open (reset-resume). Fix this by dropping the redundant reconfiguration of the port at every open, and only read the MSR after the interrupt URB has been submitted. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-11USB: serial: ch341: fix control-message error handlingJohan Hovold1-11/+21
A short control transfer would currently fail to be detected, something which could lead to stale buffer data being used as valid input. Check for short transfers, and make sure to log any transfer errors. Note that this also avoids leaking heap data to user space (TIOCMGET) and the remote device (break control). Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-09USB: serial: ch341: fix baud rate and line-control handlingJohan Hovold1-7/+17
Revert to using direct register writes to set the divisor and line-control registers. A recent change switched to using the init vendor command to update these registers, something which also enabled support for CH341A devices. It turns out that simply setting bit 7 in the divisor register is sufficient to support CH341A and specifically prevent data from being buffered until a full endpoint-size packet (32 bytes) has been received. Using the init command also had the side-effect of temporarily deasserting the DTR/RTS signals on every termios change (including initialisation on open) something which for example could cause problems in setups where DTR is used to trigger a reset. Fixes: 4e46c410e050 ("USB: serial: ch341: reinitialize chip on reconfiguration") Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-09USB: serial: ch341: fix line settings after reset-resumeJohan Hovold1-1/+4
A recent change added support for modifying the default line-control settings, but did not make sure that the modified settings were used as part of reconfiguration after a device has been reset during resume. This caused a port that was open before suspend to be unusable until being closed and reopened. Fixes: ba781bdf8662 ("USB: serial: ch341: add support for parity, frame length, stop bits") Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-09USB: serial: ch341: fix resume after resetJohan Hovold1-4/+13
Fix reset-resume handling which failed to resubmit the read and interrupt URBs, thereby leaving a port that was open before suspend in a broken state until closed and reopened. Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after resume") Fixes: 2bfd1c96a9fb ("USB: serial: ch341: remove reset_resume callback") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-09USB: serial: ch341: fix open error handlingJohan Hovold1-3/+10
Make sure to stop the interrupt URB before returning on errors during open. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-09USB: serial: ch341: fix modem-control and B0 handlingJohan Hovold1-9/+7
The modem-control signals are managed by the tty-layer during open and should not be asserted prematurely when set_termios is called from driver open. Also make sure that the signals are asserted only when changing speed from B0. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-09USB: serial: ch341: fix open and resume after B0Johan Hovold1-1/+3
The private baud_rate variable is used to configure the port at open and reset-resume and must never be set to (and left at) zero or reset-resume and all further open attempts will fail. Fixes: aa91def41a7b ("USB: ch341: set tty baud speed according to tty struct") Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2017-01-09USB: serial: ch341: fix initial modem-control stateJohan Hovold1-1/+0
DTR and RTS will be asserted by the tty-layer when the port is opened and deasserted on close (if HUPCL is set). Make sure the initial state is not-asserted before the port is first opened as well. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-24USB: serial: ch341: add debug output for chip versionAidan Thornton1-0/+1
Will probably be helpful if there are any more compatibility issues. Signed-off-by: Aidan Thornton <makosoft@gmail.com> Reviewed-by: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-24USB: serial: ch341: add support for parity, frame length, stop bitsAidan Thornton1-6/+26
With the new reinitialization method, configuring parity, different frame lengths and different stop bit settings should work as expected on both CH340G and CH341A. Tested on a loopback-connected CH340G with a logic analyzer in a number of different configurations. Based on a patch by Grigori Goronzy Signed-off-by: Aidan Thornton <makosoft@gmail.com> Reviewed-by: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-24USB: serial: ch341: reinitialize chip on reconfigurationAidan Thornton1-17/+20
Changing the LCR register after initialization does not seem to be reliable on all chips (particularly not on CH341A). Restructure initialization and configuration to always reinit the chip on configuration changes instead and pass the LCR register value directly to the initialization command. (Note that baud rates above 500kbaud are incorrect, but they're incorrect in the same way both before and after this patch at least on the CH340G. Fixing this isn't a priority as higher baud rates don't seem that reliable anyway.) Cleaned-up version of a patch by Grigori Goronzy Signed-off-by: Aidan Thornton <makosoft@gmail.com> Reviewed-by: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-24USB: serial: ch341: add register and USB request definitionsAidan Thornton1-19/+32
No functional changes, this just gives names to some registers and USB requests based on Grigori Goronzy's work and WinChipTech's Linux driver (which reassuringly agree), then uses them in place of magic numbers. This also renames the misnamed BREAK2 register (actually UART config) Signed-off-by: Aidan Thornton <makosoft@gmail.com> Reviewed-by: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-02-28USB: serial: fix compare_const_fl.cocci warningsMathieu OTHACEHE1-1/+1
Move constants to the right of binary operators where it increases readability. Generated by: scripts/coccinelle/misc/compare_const_fl.cocci Signed-off-by: Mathieu OTHACEHE <m.othacehe@gmail.com> [johan: drop some chunks and fix others, amend commit message ] Signed-off-by: Johan Hovold <johan@kernel.org>
2015-04-03Merge tag 'usb-serial-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-nextGreg Kroah-Hartman1-1/+0
Johan writes: USB-serial updates for v4.1-rc1 Fix up the f81232 driver, which up to this point has mostly been a placeholder without a proper implementation. Included is also a minor clean up of ch341. Signed-off-by: Johan Hovold <johan@kernel.org>
2015-03-02USB: ch341: set tty baud speed according to tty structNicolas PLANEL1-9/+6
The ch341_set_baudrate() function initialize the device baud speed according to the value on priv->baud_rate. By default the ch341_open() set it to a hardcoded value (DEFAULT_BAUD_RATE 9600). Unfortunately, the tty_struct is not initialized with the same default value. (usually 56700) This means that the tty_struct and the device baud rate generator are not synchronized after opening the port. Fixup is done by calling ch341_set_termios() if tty exist. Remove unnecessary variable priv->baud_rate setup as it's already done by ch341_port_probe(). Remove unnecessary call to ch341_set_{handshake,baudrate}() in ch341_open() as there already called in ch341_configure() and ch341_set_termios() Signed-off-by: Nicolas PLANEL <nicolas.planel@enovance.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-02-26USB: ch341: remove redundant close from open error pathJohan Hovold1-1/+0
Remove redundant call to ch341_close from error path when submission of the interrupt urb fails in open. Signed-off-by: Johan Hovold <johan@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.