2017-11-03 18:28:30 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Prolific PL2303 USB to serial adaptor driver
|
|
|
|
*
|
2007-06-13 02:43:37 +08:00
|
|
|
* Copyright (C) 2001-2007 Greg Kroah-Hartman (greg@kroah.com)
|
2005-04-17 06:20:36 +08:00
|
|
|
* Copyright (C) 2003 IBM Corp.
|
|
|
|
*
|
|
|
|
* Original driver for 2.2.x by anonymous
|
|
|
|
*
|
2019-06-19 05:05:38 +08:00
|
|
|
* See Documentation/usb/usb-serial.rst for more information on using this
|
2008-07-22 18:14:49 +08:00
|
|
|
* driver
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/tty.h>
|
|
|
|
#include <linux/tty_driver.h>
|
|
|
|
#include <linux/tty_flip.h>
|
|
|
|
#include <linux/serial.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/moduleparam.h>
|
|
|
|
#include <linux/spinlock.h>
|
2008-07-22 18:14:49 +08:00
|
|
|
#include <linux/uaccess.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/usb.h>
|
2006-07-12 12:22:58 +08:00
|
|
|
#include <linux/usb/serial.h>
|
2013-06-26 22:47:28 +08:00
|
|
|
#include <asm/unaligned.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "pl2303.h"
|
|
|
|
|
2013-12-30 02:23:05 +08:00
|
|
|
|
|
|
|
#define PL2303_QUIRK_UART_STATE_IDX0 BIT(0)
|
2013-12-30 02:23:08 +08:00
|
|
|
#define PL2303_QUIRK_LEGACY BIT(1)
|
2017-03-17 00:13:35 +08:00
|
|
|
#define PL2303_QUIRK_ENDPOINT_HACK BIT(2)
|
2013-12-30 02:23:05 +08:00
|
|
|
|
2010-01-10 22:34:24 +08:00
|
|
|
static const struct usb_device_id id_table[] = {
|
2017-03-17 00:13:35 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID),
|
|
|
|
.driver_info = PL2303_QUIRK_ENDPOINT_HACK },
|
2005-04-17 06:20:36 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) },
|
2006-06-19 20:47:49 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) },
|
2005-04-17 06:20:36 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) },
|
2018-01-25 16:48:55 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) },
|
2005-04-17 06:20:36 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_PHAROS) },
|
2008-03-20 17:43:56 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ALDIGA) },
|
2008-05-24 02:09:05 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_MMX) },
|
2008-07-03 04:25:41 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GPRS) },
|
2010-04-13 05:25:10 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_HCR331) },
|
2011-01-21 22:35:19 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_MOTOROLA) },
|
2014-08-15 15:22:21 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ZTEK) },
|
2019-01-15 23:13:56 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_TB) },
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GC) },
|
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GB) },
|
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GT) },
|
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GL) },
|
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GE) },
|
|
|
|
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GS) },
|
2005-04-17 06:20:36 +08:00
|
|
|
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID) },
|
2007-10-23 12:51:57 +08:00
|
|
|
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
|
2017-03-17 00:13:35 +08:00
|
|
|
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID),
|
|
|
|
.driver_info = PL2303_QUIRK_ENDPOINT_HACK },
|
2017-08-11 02:54:12 +08:00
|
|
|
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC485),
|
|
|
|
.driver_info = PL2303_QUIRK_ENDPOINT_HACK },
|
2018-07-19 02:20:48 +08:00
|
|
|
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC232B),
|
|
|
|
.driver_info = PL2303_QUIRK_ENDPOINT_HACK },
|
2017-01-31 02:26:40 +08:00
|
|
|
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
|
2005-04-17 06:20:36 +08:00
|
|
|
{ USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID_UCSGT) },
|
|
|
|
{ USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID) },
|
2006-04-19 16:32:07 +08:00
|
|
|
{ USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID_2080) },
|
2005-04-17 06:20:36 +08:00
|
|
|
{ USB_DEVICE(MA620_VENDOR_ID, MA620_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(TRIPP_VENDOR_ID, TRIPP_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(RADIOSHACK_VENDOR_ID, RADIOSHACK_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(SITECOM_VENDOR_ID, SITECOM_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_ID) },
|
2013-12-30 02:23:05 +08:00
|
|
|
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_SX1),
|
|
|
|
.driver_info = PL2303_QUIRK_UART_STATE_IDX0 },
|
|
|
|
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X65),
|
|
|
|
.driver_info = PL2303_QUIRK_UART_STATE_IDX0 },
|
|
|
|
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X75),
|
|
|
|
.driver_info = PL2303_QUIRK_UART_STATE_IDX0 },
|
2017-03-17 00:13:35 +08:00
|
|
|
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_EF81),
|
|
|
|
.driver_info = PL2303_QUIRK_ENDPOINT_HACK },
|
2009-04-07 00:35:12 +08:00
|
|
|
{ USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_ID_S81) }, /* Benq/Siemens S81 */
|
2005-04-19 08:39:32 +08:00
|
|
|
{ USB_DEVICE(SYNTECH_VENDOR_ID, SYNTECH_PRODUCT_ID) },
|
2006-02-01 21:10:52 +08:00
|
|
|
{ USB_DEVICE(NOKIA_CA42_VENDOR_ID, NOKIA_CA42_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(CA_42_CA42_VENDOR_ID, CA_42_CA42_PRODUCT_ID) },
|
2006-01-19 21:52:38 +08:00
|
|
|
{ USB_DEVICE(SAGEM_VENDOR_ID, SAGEM_PRODUCT_ID) },
|
2006-02-01 21:10:52 +08:00
|
|
|
{ USB_DEVICE(LEADTEK_VENDOR_ID, LEADTEK_9531_PRODUCT_ID) },
|
2006-03-01 16:53:33 +08:00
|
|
|
{ USB_DEVICE(SPEEDDRAGON_VENDOR_ID, SPEEDDRAGON_PRODUCT_ID) },
|
2006-06-22 03:25:53 +08:00
|
|
|
{ USB_DEVICE(DATAPILOT_U2_VENDOR_ID, DATAPILOT_U2_PRODUCT_ID) },
|
2006-07-25 13:54:59 +08:00
|
|
|
{ USB_DEVICE(BELKIN_VENDOR_ID, BELKIN_PRODUCT_ID) },
|
2017-03-17 00:13:35 +08:00
|
|
|
{ USB_DEVICE(ALCOR_VENDOR_ID, ALCOR_PRODUCT_ID),
|
|
|
|
.driver_info = PL2303_QUIRK_ENDPOINT_HACK },
|
2007-01-26 21:51:38 +08:00
|
|
|
{ USB_DEVICE(WS002IN_VENDOR_ID, WS002IN_PRODUCT_ID) },
|
2007-11-08 15:45:46 +08:00
|
|
|
{ USB_DEVICE(COREGA_VENDOR_ID, COREGA_PRODUCT_ID) },
|
2008-01-07 02:51:39 +08:00
|
|
|
{ USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
|
2008-12-13 19:42:53 +08:00
|
|
|
{ USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
|
2008-12-17 04:30:14 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
|
2018-12-13 19:01:47 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LD220TA_PRODUCT_ID) },
|
2020-03-11 14:14:23 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LD381_PRODUCT_ID) },
|
2020-09-24 14:27:45 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LD381GC_PRODUCT_ID) },
|
2014-03-31 21:54:21 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
|
2018-12-13 19:01:47 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LD960TA_PRODUCT_ID) },
|
2014-03-31 21:54:21 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
|
2018-12-13 19:01:47 +08:00
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LM920_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_LM940_PRODUCT_ID) },
|
|
|
|
{ USB_DEVICE(HP_VENDOR_ID, HP_TD620_PRODUCT_ID) },
|
2009-06-06 04:57:52 +08:00
|
|
|
{ USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
|
2010-08-09 21:55:32 +08:00
|
|
|
{ USB_DEVICE(ZEAGLE_VENDOR_ID, ZEAGLE_N2ITION3_PRODUCT_ID) },
|
2009-07-29 01:41:17 +08:00
|
|
|
{ USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
|
2009-08-27 20:15:50 +08:00
|
|
|
{ USB_DEVICE(SANWA_VENDOR_ID, SANWA_PRODUCT_ID) },
|
2010-03-30 05:51:57 +08:00
|
|
|
{ USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530_PRODUCT_ID) },
|
2011-09-24 14:04:50 +08:00
|
|
|
{ USB_DEVICE(SMART_VENDOR_ID, SMART_PRODUCT_ID) },
|
2019-05-14 13:35:42 +08:00
|
|
|
{ USB_DEVICE(AT_VENDOR_ID, AT_VTKIT3_PRODUCT_ID) },
|
2005-04-17 06:20:36 +08:00
|
|
|
{ } /* Terminating entry */
|
|
|
|
};
|
|
|
|
|
2006-08-01 02:39:27 +08:00
|
|
|
MODULE_DEVICE_TABLE(usb, id_table);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#define SET_LINE_REQUEST_TYPE 0x21
|
|
|
|
#define SET_LINE_REQUEST 0x20
|
|
|
|
|
|
|
|
#define SET_CONTROL_REQUEST_TYPE 0x21
|
|
|
|
#define SET_CONTROL_REQUEST 0x22
|
|
|
|
#define CONTROL_DTR 0x01
|
|
|
|
#define CONTROL_RTS 0x02
|
|
|
|
|
|
|
|
#define BREAK_REQUEST_TYPE 0x21
|
2008-07-22 18:14:49 +08:00
|
|
|
#define BREAK_REQUEST 0x23
|
2005-04-17 06:20:36 +08:00
|
|
|
#define BREAK_ON 0xffff
|
|
|
|
#define BREAK_OFF 0x0000
|
|
|
|
|
|
|
|
#define GET_LINE_REQUEST_TYPE 0xa1
|
|
|
|
#define GET_LINE_REQUEST 0x21
|
|
|
|
|
|
|
|
#define VENDOR_WRITE_REQUEST_TYPE 0x40
|
|
|
|
#define VENDOR_WRITE_REQUEST 0x01
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
#define VENDOR_WRITE_NREQUEST 0x80
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#define VENDOR_READ_REQUEST_TYPE 0xc0
|
|
|
|
#define VENDOR_READ_REQUEST 0x01
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
#define VENDOR_READ_NREQUEST 0x81
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-12-30 02:23:05 +08:00
|
|
|
#define UART_STATE_INDEX 8
|
2014-01-03 05:49:22 +08:00
|
|
|
#define UART_STATE_MSR_MASK 0x8b
|
2005-04-17 06:20:36 +08:00
|
|
|
#define UART_STATE_TRANSIENT_MASK 0x74
|
|
|
|
#define UART_DCD 0x01
|
|
|
|
#define UART_DSR 0x02
|
|
|
|
#define UART_BREAK_ERROR 0x04
|
|
|
|
#define UART_RING 0x08
|
|
|
|
#define UART_FRAME_ERROR 0x10
|
|
|
|
#define UART_PARITY_ERROR 0x20
|
|
|
|
#define UART_OVERRUN_ERROR 0x40
|
|
|
|
#define UART_CTS 0x80
|
|
|
|
|
2019-04-02 16:19:31 +08:00
|
|
|
#define PL2303_FLOWCTRL_MASK 0xf0
|
|
|
|
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
#define PL2303_READ_TYPE_HX_STATUS 0x8080
|
|
|
|
|
|
|
|
#define PL2303_HXN_RESET_REG 0x07
|
|
|
|
#define PL2303_HXN_RESET_UPSTREAM_PIPE 0x02
|
|
|
|
#define PL2303_HXN_RESET_DOWNSTREAM_PIPE 0x01
|
|
|
|
|
|
|
|
#define PL2303_HXN_FLOWCTRL_REG 0x0a
|
|
|
|
#define PL2303_HXN_FLOWCTRL_MASK 0x1c
|
|
|
|
#define PL2303_HXN_FLOWCTRL_NONE 0x1c
|
|
|
|
#define PL2303_HXN_FLOWCTRL_RTS_CTS 0x18
|
|
|
|
#define PL2303_HXN_FLOWCTRL_XON_XOFF 0x0c
|
|
|
|
|
2015-02-26 23:50:24 +08:00
|
|
|
static void pl2303_set_break(struct usb_serial_port *port, bool enable);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
enum pl2303_type {
|
2013-12-30 02:23:07 +08:00
|
|
|
TYPE_01, /* Type 0 and 1 (difference unknown) */
|
|
|
|
TYPE_HX, /* HX version of the pl2303 chip */
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
TYPE_HXN, /* HXN version of the pl2303 chip */
|
2013-12-30 02:23:09 +08:00
|
|
|
TYPE_COUNT
|
|
|
|
};
|
|
|
|
|
|
|
|
struct pl2303_type_data {
|
|
|
|
speed_t max_baud_rate;
|
|
|
|
unsigned long quirks;
|
2019-04-02 16:19:30 +08:00
|
|
|
unsigned int no_autoxonxoff:1;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2012-10-15 21:47:21 +08:00
|
|
|
struct pl2303_serial_private {
|
2014-01-03 05:49:20 +08:00
|
|
|
const struct pl2303_type_data *type;
|
2013-12-30 02:23:05 +08:00
|
|
|
unsigned long quirks;
|
2012-10-15 21:47:21 +08:00
|
|
|
};
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct pl2303_private {
|
|
|
|
spinlock_t lock;
|
|
|
|
u8 line_control;
|
|
|
|
u8 line_status;
|
2013-12-30 02:22:53 +08:00
|
|
|
|
|
|
|
u8 line_settings[7];
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2014-01-03 05:49:20 +08:00
|
|
|
static const struct pl2303_type_data pl2303_type_data[TYPE_COUNT] = {
|
2013-12-30 02:23:09 +08:00
|
|
|
[TYPE_01] = {
|
2019-04-02 16:19:30 +08:00
|
|
|
.max_baud_rate = 1228800,
|
|
|
|
.quirks = PL2303_QUIRK_LEGACY,
|
|
|
|
.no_autoxonxoff = true,
|
2013-12-30 02:23:09 +08:00
|
|
|
},
|
2014-08-13 20:02:53 +08:00
|
|
|
[TYPE_HX] = {
|
2019-04-02 16:19:30 +08:00
|
|
|
.max_baud_rate = 12000000,
|
2014-08-13 20:02:53 +08:00
|
|
|
},
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
[TYPE_HXN] = {
|
|
|
|
.max_baud_rate = 12000000,
|
|
|
|
},
|
2013-12-30 02:23:09 +08:00
|
|
|
};
|
|
|
|
|
2013-12-30 02:23:01 +08:00
|
|
|
static int pl2303_vendor_read(struct usb_serial *serial, u16 value,
|
|
|
|
unsigned char buf[1])
|
2007-12-15 06:08:00 +08:00
|
|
|
{
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
2013-12-30 02:23:01 +08:00
|
|
|
struct device *dev = &serial->interface->dev;
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
u8 request;
|
2013-12-30 02:23:00 +08:00
|
|
|
int res;
|
|
|
|
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (spriv->type == &pl2303_type_data[TYPE_HXN])
|
|
|
|
request = VENDOR_READ_NREQUEST;
|
|
|
|
else
|
|
|
|
request = VENDOR_READ_REQUEST;
|
|
|
|
|
2013-12-30 02:23:00 +08:00
|
|
|
res = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
request, VENDOR_READ_REQUEST_TYPE,
|
2013-12-30 02:23:01 +08:00
|
|
|
value, 0, buf, 1, 100);
|
|
|
|
if (res != 1) {
|
|
|
|
dev_err(dev, "%s - failed to read [%04x]: %d\n", __func__,
|
|
|
|
value, res);
|
|
|
|
if (res >= 0)
|
|
|
|
res = -EIO;
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2013-12-30 02:23:01 +08:00
|
|
|
dev_dbg(dev, "%s - [%04x] = %02x\n", __func__, value, buf[0]);
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2013-12-30 02:23:01 +08:00
|
|
|
return 0;
|
2007-12-15 06:08:00 +08:00
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:01 +08:00
|
|
|
static int pl2303_vendor_write(struct usb_serial *serial, u16 value, u16 index)
|
2007-12-15 06:08:00 +08:00
|
|
|
{
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
2013-12-30 02:23:01 +08:00
|
|
|
struct device *dev = &serial->interface->dev;
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
u8 request;
|
2013-12-30 02:23:00 +08:00
|
|
|
int res;
|
|
|
|
|
2013-12-30 02:23:01 +08:00
|
|
|
dev_dbg(dev, "%s - [%04x] = %02x\n", __func__, value, index);
|
|
|
|
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (spriv->type == &pl2303_type_data[TYPE_HXN])
|
|
|
|
request = VENDOR_WRITE_NREQUEST;
|
|
|
|
else
|
|
|
|
request = VENDOR_WRITE_REQUEST;
|
|
|
|
|
2013-12-30 02:23:00 +08:00
|
|
|
res = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
request, VENDOR_WRITE_REQUEST_TYPE,
|
2007-12-15 06:08:00 +08:00
|
|
|
value, index, NULL, 0, 100);
|
2013-12-30 02:23:01 +08:00
|
|
|
if (res) {
|
|
|
|
dev_err(dev, "%s - failed to write [%04x]: %d\n", __func__,
|
|
|
|
value, res);
|
|
|
|
return res;
|
|
|
|
}
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2013-12-30 02:23:01 +08:00
|
|
|
return 0;
|
2007-12-15 06:08:00 +08:00
|
|
|
}
|
|
|
|
|
2019-04-02 16:19:31 +08:00
|
|
|
static int pl2303_update_reg(struct usb_serial *serial, u8 reg, u8 mask, u8 val)
|
|
|
|
{
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
2019-04-02 16:19:31 +08:00
|
|
|
int ret = 0;
|
|
|
|
u8 *buf;
|
|
|
|
|
|
|
|
buf = kmalloc(1, GFP_KERNEL);
|
|
|
|
if (!buf)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (spriv->type == &pl2303_type_data[TYPE_HXN])
|
|
|
|
ret = pl2303_vendor_read(serial, reg, buf);
|
|
|
|
else
|
|
|
|
ret = pl2303_vendor_read(serial, reg | 0x80, buf);
|
|
|
|
|
2019-04-02 16:19:31 +08:00
|
|
|
if (ret)
|
|
|
|
goto out_free;
|
|
|
|
|
|
|
|
*buf &= ~mask;
|
|
|
|
*buf |= val & mask;
|
|
|
|
|
|
|
|
ret = pl2303_vendor_write(serial, reg, *buf);
|
|
|
|
out_free:
|
|
|
|
kfree(buf);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:05 +08:00
|
|
|
static int pl2303_probe(struct usb_serial *serial,
|
|
|
|
const struct usb_device_id *id)
|
|
|
|
{
|
|
|
|
usb_set_serial_data(serial, (void *)id->driver_info);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-17 00:13:35 +08:00
|
|
|
/*
|
|
|
|
* Use interrupt endpoint from first interface if available.
|
|
|
|
*
|
|
|
|
* This is needed due to the looney way its endpoints are set up.
|
|
|
|
*/
|
|
|
|
static int pl2303_endpoint_hack(struct usb_serial *serial,
|
2017-03-17 00:13:34 +08:00
|
|
|
struct usb_serial_endpoints *epds)
|
|
|
|
{
|
|
|
|
struct usb_interface *interface = serial->interface;
|
|
|
|
struct usb_device *dev = serial->dev;
|
|
|
|
struct device *ddev = &interface->dev;
|
|
|
|
struct usb_host_interface *iface_desc;
|
|
|
|
struct usb_endpoint_descriptor *endpoint;
|
|
|
|
unsigned int i;
|
|
|
|
|
2017-03-17 00:13:35 +08:00
|
|
|
if (interface == dev->actconfig->interface[0])
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* check out the endpoints of the other interface */
|
|
|
|
iface_desc = dev->actconfig->interface[0]->cur_altsetting;
|
|
|
|
|
|
|
|
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
|
|
|
|
endpoint = &iface_desc->endpoint[i].desc;
|
|
|
|
|
|
|
|
if (!usb_endpoint_is_int_in(endpoint))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
dev_dbg(ddev, "found interrupt in on separate interface\n");
|
|
|
|
if (epds->num_interrupt_in < ARRAY_SIZE(epds->interrupt_in))
|
|
|
|
epds->interrupt_in[epds->num_interrupt_in++] = endpoint;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pl2303_calc_num_ports(struct usb_serial *serial,
|
|
|
|
struct usb_serial_endpoints *epds)
|
|
|
|
{
|
|
|
|
unsigned long quirks = (unsigned long)usb_get_serial_data(serial);
|
|
|
|
struct device *dev = &serial->interface->dev;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (quirks & PL2303_QUIRK_ENDPOINT_HACK) {
|
|
|
|
ret = pl2303_endpoint_hack(serial, epds);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2017-03-17 00:13:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (epds->num_interrupt_in < 1) {
|
2017-03-17 00:13:35 +08:00
|
|
|
dev_err(dev, "required interrupt-in endpoint missing\n");
|
2017-03-17 00:13:34 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-08-01 02:39:27 +08:00
|
|
|
static int pl2303_startup(struct usb_serial *serial)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-10-15 21:47:21 +08:00
|
|
|
struct pl2303_serial_private *spriv;
|
2013-12-30 02:23:07 +08:00
|
|
|
enum pl2303_type type = TYPE_01;
|
2007-12-15 06:08:35 +08:00
|
|
|
unsigned char *buf;
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
int res;
|
2012-10-15 21:47:21 +08:00
|
|
|
|
|
|
|
spriv = kzalloc(sizeof(*spriv), GFP_KERNEL);
|
|
|
|
if (!spriv)
|
|
|
|
return -ENOMEM;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-12-30 02:23:01 +08:00
|
|
|
buf = kmalloc(1, GFP_KERNEL);
|
2012-10-15 21:47:21 +08:00
|
|
|
if (!buf) {
|
|
|
|
kfree(spriv);
|
2007-12-15 06:08:35 +08:00
|
|
|
return -ENOMEM;
|
2012-10-15 21:47:21 +08:00
|
|
|
}
|
2007-12-15 06:08:35 +08:00
|
|
|
|
2013-11-02 00:17:50 +08:00
|
|
|
if (serial->dev->descriptor.bDeviceClass == 0x02)
|
2013-12-30 02:23:07 +08:00
|
|
|
type = TYPE_01; /* type 0 */
|
2013-11-02 00:17:50 +08:00
|
|
|
else if (serial->dev->descriptor.bMaxPacketSize0 == 0x40)
|
2013-12-30 02:23:07 +08:00
|
|
|
type = TYPE_HX;
|
2013-11-02 00:18:10 +08:00
|
|
|
else if (serial->dev->descriptor.bDeviceClass == 0x00)
|
2013-12-30 02:23:07 +08:00
|
|
|
type = TYPE_01; /* type 1 */
|
2013-11-02 00:18:10 +08:00
|
|
|
else if (serial->dev->descriptor.bDeviceClass == 0xFF)
|
2013-12-30 02:23:07 +08:00
|
|
|
type = TYPE_01; /* type 1 */
|
2013-11-02 00:17:50 +08:00
|
|
|
dev_dbg(&serial->interface->dev, "device type: %d\n", type);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (type == TYPE_HX) {
|
|
|
|
res = usb_control_msg(serial->dev,
|
|
|
|
usb_rcvctrlpipe(serial->dev, 0),
|
|
|
|
VENDOR_READ_REQUEST, VENDOR_READ_REQUEST_TYPE,
|
|
|
|
PL2303_READ_TYPE_HX_STATUS, 0, buf, 1, 100);
|
|
|
|
if (res != 1)
|
|
|
|
type = TYPE_HXN;
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:09 +08:00
|
|
|
spriv->type = &pl2303_type_data[type];
|
2013-12-30 02:23:05 +08:00
|
|
|
spriv->quirks = (unsigned long)usb_get_serial_data(serial);
|
2013-12-30 02:23:09 +08:00
|
|
|
spriv->quirks |= spriv->type->quirks;
|
2013-12-30 02:23:05 +08:00
|
|
|
|
2012-10-15 21:47:21 +08:00
|
|
|
usb_set_serial_data(serial, spriv);
|
2007-12-15 06:08:35 +08:00
|
|
|
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (type != TYPE_HXN) {
|
|
|
|
pl2303_vendor_read(serial, 0x8484, buf);
|
|
|
|
pl2303_vendor_write(serial, 0x0404, 0);
|
|
|
|
pl2303_vendor_read(serial, 0x8484, buf);
|
|
|
|
pl2303_vendor_read(serial, 0x8383, buf);
|
|
|
|
pl2303_vendor_read(serial, 0x8484, buf);
|
|
|
|
pl2303_vendor_write(serial, 0x0404, 1);
|
|
|
|
pl2303_vendor_read(serial, 0x8484, buf);
|
|
|
|
pl2303_vendor_read(serial, 0x8383, buf);
|
|
|
|
pl2303_vendor_write(serial, 0, 1);
|
|
|
|
pl2303_vendor_write(serial, 1, 0);
|
|
|
|
if (spriv->quirks & PL2303_QUIRK_LEGACY)
|
|
|
|
pl2303_vendor_write(serial, 2, 0x24);
|
|
|
|
else
|
|
|
|
pl2303_vendor_write(serial, 2, 0x44);
|
|
|
|
}
|
2007-12-15 06:08:35 +08:00
|
|
|
|
|
|
|
kfree(buf);
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
2012-10-15 21:47:21 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-10-15 21:47:21 +08:00
|
|
|
static void pl2303_release(struct usb_serial *serial)
|
|
|
|
{
|
2013-12-30 02:23:00 +08:00
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
2012-10-15 21:47:21 +08:00
|
|
|
|
|
|
|
kfree(spriv);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pl2303_port_probe(struct usb_serial_port *port)
|
|
|
|
{
|
|
|
|
struct pl2303_private *priv;
|
|
|
|
|
|
|
|
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
|
|
|
|
if (!priv)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
spin_lock_init(&priv->lock);
|
|
|
|
|
|
|
|
usb_set_serial_port_data(port, priv);
|
|
|
|
|
2013-06-26 22:47:23 +08:00
|
|
|
port->port.drain_delay = 256;
|
|
|
|
|
2012-10-15 21:47:21 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pl2303_port_remove(struct usb_serial_port *port)
|
|
|
|
{
|
2013-12-30 02:23:00 +08:00
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
2012-10-15 21:47:21 +08:00
|
|
|
|
|
|
|
kfree(priv);
|
|
|
|
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-03-21 19:36:22 +08:00
|
|
|
static int pl2303_set_control_lines(struct usb_serial_port *port, u8 value)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-03-21 19:36:22 +08:00
|
|
|
struct usb_device *dev = port->serial->dev;
|
2005-04-17 06:20:36 +08:00
|
|
|
int retval;
|
2008-07-22 18:14:49 +08:00
|
|
|
|
2013-12-30 02:23:02 +08:00
|
|
|
dev_dbg(&port->dev, "%s - %02x\n", __func__, value);
|
|
|
|
|
2006-08-01 02:39:27 +08:00
|
|
|
retval = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
|
|
|
|
SET_CONTROL_REQUEST, SET_CONTROL_REQUEST_TYPE,
|
|
|
|
value, 0, NULL, 0, 100);
|
2013-12-30 02:23:02 +08:00
|
|
|
if (retval)
|
|
|
|
dev_err(&port->dev, "%s - failed: %d\n", __func__, retval);
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:11 +08:00
|
|
|
/*
|
2013-12-30 02:23:15 +08:00
|
|
|
* Returns the nearest supported baud rate that can be set directly without
|
|
|
|
* using divisors.
|
2013-12-30 02:23:11 +08:00
|
|
|
*/
|
|
|
|
static speed_t pl2303_get_supported_baud_rate(speed_t baud)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-12-30 02:23:11 +08:00
|
|
|
static const speed_t baud_sup[] = {
|
|
|
|
75, 150, 300, 600, 1200, 1800, 2400, 3600, 4800, 7200, 9600,
|
|
|
|
14400, 19200, 28800, 38400, 57600, 115200, 230400, 460800,
|
2013-12-30 02:23:15 +08:00
|
|
|
614400, 921600, 1228800, 2457600, 3000000, 6000000
|
2013-12-30 02:23:11 +08:00
|
|
|
};
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-12-30 02:23:11 +08:00
|
|
|
unsigned i;
|
2013-11-02 00:19:03 +08:00
|
|
|
|
2013-11-02 00:19:34 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(baud_sup); ++i) {
|
|
|
|
if (baud_sup[i] > baud)
|
|
|
|
break;
|
|
|
|
}
|
2013-11-02 00:19:03 +08:00
|
|
|
|
2013-11-02 00:19:34 +08:00
|
|
|
if (i == ARRAY_SIZE(baud_sup))
|
|
|
|
baud = baud_sup[i - 1];
|
|
|
|
else if (i > 0 && (baud_sup[i] - baud) > (baud - baud_sup[i - 1]))
|
|
|
|
baud = baud_sup[i - 1];
|
|
|
|
else
|
|
|
|
baud = baud_sup[i];
|
2013-11-02 00:19:03 +08:00
|
|
|
|
2013-12-30 02:23:11 +08:00
|
|
|
return baud;
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:14 +08:00
|
|
|
/*
|
|
|
|
* NOTE: If unsupported baud rates are set directly, the PL2303 seems to
|
|
|
|
* use 9600 baud.
|
|
|
|
*/
|
|
|
|
static speed_t pl2303_encode_baud_rate_direct(unsigned char buf[4],
|
|
|
|
speed_t baud)
|
|
|
|
{
|
|
|
|
put_unaligned_le32(baud, buf);
|
|
|
|
|
|
|
|
return baud;
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:13 +08:00
|
|
|
static speed_t pl2303_encode_baud_rate_divisor(unsigned char buf[4],
|
|
|
|
speed_t baud)
|
|
|
|
{
|
USB: pl2303: fix baud-rate divisor calculations
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.
2. Loop iterations doubled the exponent instead of incrementing.
3. The exponent wasn't checked for overflow.
4. The function returned requested rate instead of actual rate.
Due to issue #2, the old code deviated from the wrong formula
described in #1 and actually yielded correct rates when divisor
was lower than 4096 by using exponents of 0, 2 or 4 base-2,
interpreted as 0, 1, 2 base-4 with the 9th mantissa bit clear.
However, at 93.75 kbaud or less the rate turned out too slow
due to #2 or too fast due to #2 and #3.
I tested this patch by sending and validating 0x00,0x01,..,0xff
to an FTDI dongle at 234, 987, 2401, 9601, 31415, 115199, 250k,
500k, 750k, 1M, 1.5M, 3M+1 baud. All rates passed.
I also used pv to check speed at some rates unsupported by FTDI:
45 (the lowest possible), 2M, 4M, 5M and 6M-1. Looked sane.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Fixes: 399aa9a75ad3 ("USB: pl2303: use divisors for unsupported baud
rates")
Cc: stable <stable@vger.kernel.org> # v3.18
[johan: update summary ]
Signed-off-by: Johan Hovold <johan@kernel.org>
2015-07-26 17:14:34 +08:00
|
|
|
unsigned int baseline, mantissa, exponent;
|
2013-12-30 02:23:13 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Apparently the formula is:
|
USB: pl2303: fix baud-rate divisor calculations
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.
2. Loop iterations doubled the exponent instead of incrementing.
3. The exponent wasn't checked for overflow.
4. The function returned requested rate instead of actual rate.
Due to issue #2, the old code deviated from the wrong formula
described in #1 and actually yielded correct rates when divisor
was lower than 4096 by using exponents of 0, 2 or 4 base-2,
interpreted as 0, 1, 2 base-4 with the 9th mantissa bit clear.
However, at 93.75 kbaud or less the rate turned out too slow
due to #2 or too fast due to #2 and #3.
I tested this patch by sending and validating 0x00,0x01,..,0xff
to an FTDI dongle at 234, 987, 2401, 9601, 31415, 115199, 250k,
500k, 750k, 1M, 1.5M, 3M+1 baud. All rates passed.
I also used pv to check speed at some rates unsupported by FTDI:
45 (the lowest possible), 2M, 4M, 5M and 6M-1. Looked sane.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Fixes: 399aa9a75ad3 ("USB: pl2303: use divisors for unsupported baud
rates")
Cc: stable <stable@vger.kernel.org> # v3.18
[johan: update summary ]
Signed-off-by: Johan Hovold <johan@kernel.org>
2015-07-26 17:14:34 +08:00
|
|
|
* baudrate = 12M * 32 / (mantissa * 4^exponent)
|
|
|
|
* where
|
|
|
|
* mantissa = buf[8:0]
|
|
|
|
* exponent = buf[11:9]
|
2013-12-30 02:23:13 +08:00
|
|
|
*/
|
USB: pl2303: fix baud-rate divisor calculations
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.
2. Loop iterations doubled the exponent instead of incrementing.
3. The exponent wasn't checked for overflow.
4. The function returned requested rate instead of actual rate.
Due to issue #2, the old code deviated from the wrong formula
described in #1 and actually yielded correct rates when divisor
was lower than 4096 by using exponents of 0, 2 or 4 base-2,
interpreted as 0, 1, 2 base-4 with the 9th mantissa bit clear.
However, at 93.75 kbaud or less the rate turned out too slow
due to #2 or too fast due to #2 and #3.
I tested this patch by sending and validating 0x00,0x01,..,0xff
to an FTDI dongle at 234, 987, 2401, 9601, 31415, 115199, 250k,
500k, 750k, 1M, 1.5M, 3M+1 baud. All rates passed.
I also used pv to check speed at some rates unsupported by FTDI:
45 (the lowest possible), 2M, 4M, 5M and 6M-1. Looked sane.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Fixes: 399aa9a75ad3 ("USB: pl2303: use divisors for unsupported baud
rates")
Cc: stable <stable@vger.kernel.org> # v3.18
[johan: update summary ]
Signed-off-by: Johan Hovold <johan@kernel.org>
2015-07-26 17:14:34 +08:00
|
|
|
baseline = 12000000 * 32;
|
|
|
|
mantissa = baseline / baud;
|
|
|
|
if (mantissa == 0)
|
|
|
|
mantissa = 1; /* Avoid dividing by zero if baud > 32*12M. */
|
|
|
|
exponent = 0;
|
|
|
|
while (mantissa >= 512) {
|
|
|
|
if (exponent < 7) {
|
|
|
|
mantissa >>= 2; /* divide by 4 */
|
|
|
|
exponent++;
|
|
|
|
} else {
|
|
|
|
/* Exponent is maxed. Trim mantissa and leave. */
|
|
|
|
mantissa = 511;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:13 +08:00
|
|
|
buf[3] = 0x80;
|
|
|
|
buf[2] = 0;
|
USB: pl2303: fix baud-rate divisor calculations
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.
2. Loop iterations doubled the exponent instead of incrementing.
3. The exponent wasn't checked for overflow.
4. The function returned requested rate instead of actual rate.
Due to issue #2, the old code deviated from the wrong formula
described in #1 and actually yielded correct rates when divisor
was lower than 4096 by using exponents of 0, 2 or 4 base-2,
interpreted as 0, 1, 2 base-4 with the 9th mantissa bit clear.
However, at 93.75 kbaud or less the rate turned out too slow
due to #2 or too fast due to #2 and #3.
I tested this patch by sending and validating 0x00,0x01,..,0xff
to an FTDI dongle at 234, 987, 2401, 9601, 31415, 115199, 250k,
500k, 750k, 1M, 1.5M, 3M+1 baud. All rates passed.
I also used pv to check speed at some rates unsupported by FTDI:
45 (the lowest possible), 2M, 4M, 5M and 6M-1. Looked sane.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Fixes: 399aa9a75ad3 ("USB: pl2303: use divisors for unsupported baud
rates")
Cc: stable <stable@vger.kernel.org> # v3.18
[johan: update summary ]
Signed-off-by: Johan Hovold <johan@kernel.org>
2015-07-26 17:14:34 +08:00
|
|
|
buf[1] = exponent << 1 | mantissa >> 8;
|
|
|
|
buf[0] = mantissa & 0xff;
|
|
|
|
|
|
|
|
/* Calculate and return the exact baud rate. */
|
|
|
|
baud = (baseline / mantissa) >> (exponent << 1);
|
2013-12-30 02:23:13 +08:00
|
|
|
|
|
|
|
return baud;
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:11 +08:00
|
|
|
static void pl2303_encode_baud_rate(struct tty_struct *tty,
|
|
|
|
struct usb_serial_port *port,
|
|
|
|
u8 buf[4])
|
|
|
|
{
|
|
|
|
struct usb_serial *serial = port->serial;
|
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
2013-12-30 02:23:15 +08:00
|
|
|
speed_t baud_sup;
|
2013-12-30 02:23:11 +08:00
|
|
|
speed_t baud;
|
|
|
|
|
|
|
|
baud = tty_get_baud_rate(tty);
|
|
|
|
dev_dbg(&port->dev, "baud requested = %u\n", baud);
|
|
|
|
if (!baud)
|
|
|
|
return;
|
2013-12-30 02:23:12 +08:00
|
|
|
|
|
|
|
if (spriv->type->max_baud_rate)
|
|
|
|
baud = min_t(speed_t, baud, spriv->type->max_baud_rate);
|
2013-12-30 02:23:15 +08:00
|
|
|
/*
|
2014-08-13 20:02:53 +08:00
|
|
|
* Use direct method for supported baud rates, otherwise use divisors.
|
2013-12-30 02:23:15 +08:00
|
|
|
*/
|
|
|
|
baud_sup = pl2303_get_supported_baud_rate(baud);
|
2013-12-30 02:23:14 +08:00
|
|
|
|
2014-08-13 20:02:53 +08:00
|
|
|
if (baud == baud_sup)
|
|
|
|
baud = pl2303_encode_baud_rate_direct(buf, baud);
|
2013-12-30 02:23:15 +08:00
|
|
|
else
|
2014-08-13 20:02:53 +08:00
|
|
|
baud = pl2303_encode_baud_rate_divisor(buf, baud);
|
2013-11-02 00:19:03 +08:00
|
|
|
|
2013-06-26 22:47:27 +08:00
|
|
|
/* Save resulting baud rate */
|
2013-06-26 22:47:28 +08:00
|
|
|
tty_encode_baud_rate(tty, baud, baud);
|
2013-12-30 02:23:06 +08:00
|
|
|
dev_dbg(&port->dev, "baud set = %u\n", baud);
|
2013-06-26 22:47:27 +08:00
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:03 +08:00
|
|
|
static int pl2303_get_line_request(struct usb_serial_port *port,
|
|
|
|
unsigned char buf[7])
|
|
|
|
{
|
|
|
|
struct usb_device *udev = port->serial->dev;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
|
|
|
|
GET_LINE_REQUEST, GET_LINE_REQUEST_TYPE,
|
|
|
|
0, 0, buf, 7, 100);
|
|
|
|
if (ret != 7) {
|
|
|
|
dev_err(&port->dev, "%s - failed: %d\n", __func__, ret);
|
|
|
|
|
2017-01-12 21:56:19 +08:00
|
|
|
if (ret >= 0)
|
2013-12-30 02:23:03 +08:00
|
|
|
ret = -EIO;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_dbg(&port->dev, "%s - %7ph\n", __func__, buf);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pl2303_set_line_request(struct usb_serial_port *port,
|
|
|
|
unsigned char buf[7])
|
|
|
|
{
|
|
|
|
struct usb_device *udev = port->serial->dev;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
SET_LINE_REQUEST, SET_LINE_REQUEST_TYPE,
|
|
|
|
0, 0, buf, 7, 100);
|
2017-01-12 21:56:19 +08:00
|
|
|
if (ret < 0) {
|
2013-12-30 02:23:03 +08:00
|
|
|
dev_err(&port->dev, "%s - failed: %d\n", __func__, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_dbg(&port->dev, "%s - %7ph\n", __func__, buf);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-05-20 08:23:12 +08:00
|
|
|
static bool pl2303_termios_change(const struct ktermios *a, const struct ktermios *b)
|
|
|
|
{
|
|
|
|
bool ixon_change;
|
|
|
|
|
|
|
|
ixon_change = ((a->c_iflag ^ b->c_iflag) & (IXON | IXANY)) ||
|
|
|
|
a->c_cc[VSTART] != b->c_cc[VSTART] ||
|
|
|
|
a->c_cc[VSTOP] != b->c_cc[VSTOP];
|
|
|
|
|
|
|
|
return tty_termios_hw_change(a, b) || ixon_change;
|
|
|
|
}
|
|
|
|
|
2019-04-02 16:19:30 +08:00
|
|
|
static bool pl2303_enable_xonxoff(struct tty_struct *tty, const struct pl2303_type_data *type)
|
|
|
|
{
|
|
|
|
if (!I_IXON(tty) || I_IXANY(tty))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (START_CHAR(tty) != 0x11 || STOP_CHAR(tty) != 0x13)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (type->no_autoxonxoff)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-06-26 22:47:27 +08:00
|
|
|
static void pl2303_set_termios(struct tty_struct *tty,
|
|
|
|
struct usb_serial_port *port, struct ktermios *old_termios)
|
|
|
|
{
|
|
|
|
struct usb_serial *serial = port->serial;
|
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
|
|
|
unsigned long flags;
|
|
|
|
unsigned char *buf;
|
2013-12-30 02:23:03 +08:00
|
|
|
int ret;
|
2013-06-26 22:47:27 +08:00
|
|
|
u8 control;
|
|
|
|
|
2018-05-20 08:23:12 +08:00
|
|
|
if (old_termios && !pl2303_termios_change(&tty->termios, old_termios))
|
2013-06-26 22:47:27 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
buf = kzalloc(7, GFP_KERNEL);
|
|
|
|
if (!buf) {
|
|
|
|
/* Report back no change occurred */
|
|
|
|
if (old_termios)
|
|
|
|
tty->termios = *old_termios;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-12-30 02:23:03 +08:00
|
|
|
pl2303_get_line_request(port, buf);
|
2013-06-26 22:47:27 +08:00
|
|
|
|
2013-11-05 02:40:43 +08:00
|
|
|
switch (C_CSIZE(tty)) {
|
|
|
|
case CS5:
|
|
|
|
buf[6] = 5;
|
|
|
|
break;
|
|
|
|
case CS6:
|
|
|
|
buf[6] = 6;
|
|
|
|
break;
|
|
|
|
case CS7:
|
|
|
|
buf[6] = 7;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
case CS8:
|
|
|
|
buf[6] = 8;
|
2013-06-26 22:47:27 +08:00
|
|
|
}
|
2013-11-05 02:40:43 +08:00
|
|
|
dev_dbg(&port->dev, "data bits = %d\n", buf[6]);
|
2013-06-26 22:47:27 +08:00
|
|
|
|
2013-11-02 00:19:03 +08:00
|
|
|
/* For reference buf[0]:buf[3] baud rate value */
|
2013-12-30 02:23:10 +08:00
|
|
|
pl2303_encode_baud_rate(tty, port, &buf[0]);
|
2013-06-26 22:47:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* For reference buf[4]=0 is 1 stop bits */
|
|
|
|
/* For reference buf[4]=1 is 1.5 stop bits */
|
|
|
|
/* For reference buf[4]=2 is 2 stop bits */
|
2013-06-26 22:47:29 +08:00
|
|
|
if (C_CSTOPB(tty)) {
|
|
|
|
/*
|
|
|
|
* NOTE: Comply with "real" UARTs / RS232:
|
2009-08-19 02:34:24 +08:00
|
|
|
* use 1.5 instead of 2 stop bits with 5 data bits
|
|
|
|
*/
|
2013-06-26 22:47:29 +08:00
|
|
|
if (C_CSIZE(tty) == CS5) {
|
2009-08-19 02:34:24 +08:00
|
|
|
buf[4] = 1;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "stop bits = 1.5\n");
|
2009-08-19 02:34:24 +08:00
|
|
|
} else {
|
|
|
|
buf[4] = 2;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "stop bits = 2\n");
|
2009-08-19 02:34:24 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
|
|
|
buf[4] = 0;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "stop bits = 1\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-06-26 22:47:29 +08:00
|
|
|
if (C_PARENB(tty)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
/* For reference buf[5]=0 is none parity */
|
|
|
|
/* For reference buf[5]=1 is odd parity */
|
|
|
|
/* For reference buf[5]=2 is even parity */
|
|
|
|
/* For reference buf[5]=3 is mark parity */
|
|
|
|
/* For reference buf[5]=4 is space parity */
|
2013-06-26 22:47:29 +08:00
|
|
|
if (C_PARODD(tty)) {
|
2013-12-30 02:23:18 +08:00
|
|
|
if (C_CMSPAR(tty)) {
|
2009-08-19 02:31:11 +08:00
|
|
|
buf[5] = 3;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "parity = mark\n");
|
2009-08-19 02:31:11 +08:00
|
|
|
} else {
|
|
|
|
buf[5] = 1;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "parity = odd\n");
|
2009-08-19 02:31:11 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2013-12-30 02:23:18 +08:00
|
|
|
if (C_CMSPAR(tty)) {
|
2009-08-19 02:31:11 +08:00
|
|
|
buf[5] = 4;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "parity = space\n");
|
2009-08-19 02:31:11 +08:00
|
|
|
} else {
|
|
|
|
buf[5] = 2;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "parity = even\n");
|
2009-08-19 02:31:11 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
buf[5] = 0;
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "parity = none\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-12-30 02:22:53 +08:00
|
|
|
/*
|
|
|
|
* Some PL2303 are known to lose bytes if you change serial settings
|
|
|
|
* even to the same values as before. Thus we actually need to filter
|
|
|
|
* in this specific case.
|
|
|
|
*
|
|
|
|
* Note that the tty_termios_hw_change check above is not sufficient
|
|
|
|
* as a previously requested baud rate may differ from the one
|
|
|
|
* actually used (and stored in old_termios).
|
|
|
|
*
|
|
|
|
* NOTE: No additional locking needed for line_settings as it is
|
|
|
|
* only used in set_termios, which is serialised against itself.
|
|
|
|
*/
|
|
|
|
if (!old_termios || memcmp(buf, priv->line_settings, 7)) {
|
2013-12-30 02:23:03 +08:00
|
|
|
ret = pl2303_set_line_request(port, buf);
|
|
|
|
if (!ret)
|
2013-12-30 02:22:53 +08:00
|
|
|
memcpy(priv->line_settings, buf, 7);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* change control lines if we are switching to or from B0 */
|
|
|
|
spin_lock_irqsave(&priv->lock, flags);
|
|
|
|
control = priv->line_control;
|
2013-06-26 22:47:29 +08:00
|
|
|
if (C_BAUD(tty) == B0)
|
2005-04-17 06:20:36 +08:00
|
|
|
priv->line_control &= ~(CONTROL_DTR | CONTROL_RTS);
|
2013-06-11 00:29:38 +08:00
|
|
|
else if (old_termios && (old_termios->c_cflag & CBAUD) == B0)
|
2005-04-17 06:20:36 +08:00
|
|
|
priv->line_control |= (CONTROL_DTR | CONTROL_RTS);
|
|
|
|
if (control != priv->line_control) {
|
|
|
|
control = priv->line_control;
|
|
|
|
spin_unlock_irqrestore(&priv->lock, flags);
|
2013-03-21 19:36:22 +08:00
|
|
|
pl2303_set_control_lines(port, control);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
|
|
|
spin_unlock_irqrestore(&priv->lock, flags);
|
|
|
|
}
|
2006-08-01 02:39:27 +08:00
|
|
|
|
2013-06-26 22:47:29 +08:00
|
|
|
if (C_CRTSCTS(tty)) {
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (spriv->quirks & PL2303_QUIRK_LEGACY) {
|
2019-04-02 16:19:31 +08:00
|
|
|
pl2303_update_reg(serial, 0, PL2303_FLOWCTRL_MASK, 0x40);
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
} else if (spriv->type == &pl2303_type_data[TYPE_HXN]) {
|
|
|
|
pl2303_update_reg(serial, PL2303_HXN_FLOWCTRL_REG,
|
|
|
|
PL2303_HXN_FLOWCTRL_MASK,
|
|
|
|
PL2303_HXN_FLOWCTRL_RTS_CTS);
|
|
|
|
} else {
|
2019-04-02 16:19:31 +08:00
|
|
|
pl2303_update_reg(serial, 0, PL2303_FLOWCTRL_MASK, 0x60);
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
}
|
2019-04-02 16:19:30 +08:00
|
|
|
} else if (pl2303_enable_xonxoff(tty, spriv->type)) {
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (spriv->type == &pl2303_type_data[TYPE_HXN]) {
|
|
|
|
pl2303_update_reg(serial, PL2303_HXN_FLOWCTRL_REG,
|
|
|
|
PL2303_HXN_FLOWCTRL_MASK,
|
|
|
|
PL2303_HXN_FLOWCTRL_XON_XOFF);
|
|
|
|
} else {
|
|
|
|
pl2303_update_reg(serial, 0, PL2303_FLOWCTRL_MASK, 0xc0);
|
|
|
|
}
|
2007-04-25 21:05:22 +08:00
|
|
|
} else {
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (spriv->type == &pl2303_type_data[TYPE_HXN]) {
|
|
|
|
pl2303_update_reg(serial, PL2303_HXN_FLOWCTRL_REG,
|
|
|
|
PL2303_HXN_FLOWCTRL_MASK,
|
|
|
|
PL2303_HXN_FLOWCTRL_NONE);
|
|
|
|
} else {
|
|
|
|
pl2303_update_reg(serial, 0, PL2303_FLOWCTRL_MASK, 0);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2006-07-29 21:46:37 +08:00
|
|
|
|
|
|
|
kfree(buf);
|
|
|
|
}
|
|
|
|
|
2009-06-11 19:26:29 +08:00
|
|
|
static void pl2303_dtr_rts(struct usb_serial_port *port, int on)
|
|
|
|
{
|
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
|
|
|
unsigned long flags;
|
|
|
|
u8 control;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&priv->lock, flags);
|
|
|
|
if (on)
|
|
|
|
priv->line_control |= (CONTROL_DTR | CONTROL_RTS);
|
|
|
|
else
|
|
|
|
priv->line_control &= ~(CONTROL_DTR | CONTROL_RTS);
|
|
|
|
control = priv->line_control;
|
|
|
|
spin_unlock_irqrestore(&priv->lock, flags);
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2013-03-21 19:36:22 +08:00
|
|
|
pl2303_set_control_lines(port, control);
|
2009-06-11 19:26:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void pl2303_close(struct usb_serial_port *port)
|
2006-07-29 21:46:37 +08:00
|
|
|
{
|
2010-03-18 06:06:04 +08:00
|
|
|
usb_serial_generic_close(port);
|
2006-07-29 21:46:37 +08:00
|
|
|
usb_kill_urb(port->interrupt_in_urb);
|
2015-02-26 23:50:24 +08:00
|
|
|
pl2303_set_break(port, false);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2009-09-20 04:13:26 +08:00
|
|
|
static int pl2303_open(struct tty_struct *tty, struct usb_serial_port *port)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct usb_serial *serial = port->serial;
|
2012-10-15 21:47:21 +08:00
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
2005-04-17 06:20:36 +08:00
|
|
|
int result;
|
|
|
|
|
2013-12-30 02:23:08 +08:00
|
|
|
if (spriv->quirks & PL2303_QUIRK_LEGACY) {
|
2005-07-29 00:06:13 +08:00
|
|
|
usb_clear_halt(serial->dev, port->write_urb->pipe);
|
|
|
|
usb_clear_halt(serial->dev, port->read_urb->pipe);
|
2007-12-15 06:08:35 +08:00
|
|
|
} else {
|
2005-04-17 06:20:36 +08:00
|
|
|
/* reset upstream data pipes */
|
USB: serial: pl2303: add support for PL2303HXN
Prolific has developed a new USB to UART chip: PL2303HXN
PL2303HXN : PL2303GC/PL2303GS/PL2303GT/PL2303GL/PL2303GE/PL2303GB
The Vendor request used by the PL2303HXN (TYPE_HXN) is different from
the existing PL2303 series (TYPE_HX & TYPE_01).
Therefore, different Vendor requests are used to issue related commands.
1. Added a new TYPE_HXN type in pl2303_type_data, and then executes
new Vendor request,new flow control and other related instructions
if TYPE_HXN is recognized.
2. Because the new PL2303HXN only accept the new Vendor request,
the old Vendor request cannot be accepted (the error message
will be returned)
So first determine the TYPE_HX or TYPE_HXN through
PL2303_READ_TYPE_HX_STATUS in pl2303_startup.
2.1 If the return message is "1", then the PL2303 is the existing
TYPE_HX/ TYPE_01 series.
The other settings in pl2303_startup are to continue execution.
2.2 If the return message is "not 1", then the PL2303 is the new
TYPE_HXN series.
The other settings in pl2303_startup are ignored.
(PL2303HXN will directly use the default value in the hardware,
no need to add additional settings through the software)
3. In pl2303_open: Because TYPE_HXN is different from the instruction of reset
down/up stream used by TYPE_HX.
Therefore, we will also execute different instructions here.
4. In pl2303_set_termios: The UART flow control instructions used by
TYPE_HXN/TYPE_HX/TYPE_01 are different.
Therefore, we will also execute different instructions here.
5. In pl2303_vendor_read & pl2303_vendor_write, since TYPE_HXN is different
from the vendor request instruction used by TYPE_HX/TYPE_01,
it will also execute different instructions here.
6. In pl2303_update_reg: TYPE_HXN used different register for flow control.
Therefore, we will also execute different instructions here.
Signed-off-by: Charles Yeh <charlesyeh522@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
2019-09-24 20:14:00 +08:00
|
|
|
if (spriv->type == &pl2303_type_data[TYPE_HXN]) {
|
|
|
|
pl2303_vendor_write(serial, PL2303_HXN_RESET_REG,
|
|
|
|
PL2303_HXN_RESET_UPSTREAM_PIPE |
|
|
|
|
PL2303_HXN_RESET_DOWNSTREAM_PIPE);
|
|
|
|
} else {
|
|
|
|
pl2303_vendor_write(serial, 8, 0);
|
|
|
|
pl2303_vendor_write(serial, 9, 0);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Setup termios */
|
2008-07-22 18:09:07 +08:00
|
|
|
if (tty)
|
2013-06-11 00:29:38 +08:00
|
|
|
pl2303_set_termios(tty, port, NULL);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-08-01 02:39:27 +08:00
|
|
|
result = usb_submit_urb(port->interrupt_in_urb, GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (result) {
|
2013-12-30 02:23:00 +08:00
|
|
|
dev_err(&port->dev, "failed to submit interrupt urb: %d\n",
|
|
|
|
result);
|
2011-11-07 02:06:34 +08:00
|
|
|
return result;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2011-11-07 02:06:35 +08:00
|
|
|
|
2011-11-07 02:06:36 +08:00
|
|
|
result = usb_serial_generic_open(tty, port);
|
2011-11-07 02:06:35 +08:00
|
|
|
if (result) {
|
|
|
|
usb_kill_urb(port->interrupt_in_urb);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-02-15 00:26:50 +08:00
|
|
|
static int pl2303_tiocmset(struct tty_struct *tty,
|
2006-08-01 02:39:27 +08:00
|
|
|
unsigned int set, unsigned int clear)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-07-22 18:09:07 +08:00
|
|
|
struct usb_serial_port *port = tty->driver_data;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
|
|
|
unsigned long flags;
|
|
|
|
u8 control;
|
2012-04-25 21:56:31 +08:00
|
|
|
int ret;
|
2005-04-19 08:39:31 +08:00
|
|
|
|
2006-08-01 02:39:27 +08:00
|
|
|
spin_lock_irqsave(&priv->lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (set & TIOCM_RTS)
|
|
|
|
priv->line_control |= CONTROL_RTS;
|
|
|
|
if (set & TIOCM_DTR)
|
|
|
|
priv->line_control |= CONTROL_DTR;
|
|
|
|
if (clear & TIOCM_RTS)
|
|
|
|
priv->line_control &= ~CONTROL_RTS;
|
|
|
|
if (clear & TIOCM_DTR)
|
|
|
|
priv->line_control &= ~CONTROL_DTR;
|
|
|
|
control = priv->line_control;
|
2006-08-01 02:39:27 +08:00
|
|
|
spin_unlock_irqrestore(&priv->lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-03-21 19:37:45 +08:00
|
|
|
ret = pl2303_set_control_lines(port, control);
|
|
|
|
if (ret)
|
|
|
|
return usb_translate_errors(ret);
|
2012-04-25 21:56:31 +08:00
|
|
|
|
2013-03-21 19:37:45 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2011-02-15 00:26:14 +08:00
|
|
|
static int pl2303_tiocmget(struct tty_struct *tty)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-07-22 18:09:07 +08:00
|
|
|
struct usb_serial_port *port = tty->driver_data;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
|
|
|
unsigned long flags;
|
|
|
|
unsigned int mcr;
|
|
|
|
unsigned int status;
|
|
|
|
unsigned int result;
|
|
|
|
|
2006-08-01 02:39:27 +08:00
|
|
|
spin_lock_irqsave(&priv->lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
mcr = priv->line_control;
|
|
|
|
status = priv->line_status;
|
2006-08-01 02:39:27 +08:00
|
|
|
spin_unlock_irqrestore(&priv->lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
result = ((mcr & CONTROL_DTR) ? TIOCM_DTR : 0)
|
|
|
|
| ((mcr & CONTROL_RTS) ? TIOCM_RTS : 0)
|
|
|
|
| ((status & UART_CTS) ? TIOCM_CTS : 0)
|
|
|
|
| ((status & UART_DSR) ? TIOCM_DSR : 0)
|
|
|
|
| ((status & UART_RING) ? TIOCM_RI : 0)
|
|
|
|
| ((status & UART_DCD) ? TIOCM_CD : 0);
|
|
|
|
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "%s - result = %x\n", __func__, result);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2009-06-11 19:26:29 +08:00
|
|
|
static int pl2303_carrier_raised(struct usb_serial_port *port)
|
|
|
|
{
|
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2009-06-11 19:26:29 +08:00
|
|
|
if (priv->line_status & UART_DCD)
|
|
|
|
return 1;
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2009-06-11 19:26:29 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-09-12 19:23:18 +08:00
|
|
|
static int pl2303_get_serial(struct tty_struct *tty,
|
|
|
|
struct serial_struct *ss)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-07-22 18:09:07 +08:00
|
|
|
struct usb_serial_port *port = tty->driver_data;
|
2012-05-04 07:39:27 +08:00
|
|
|
|
2018-09-12 19:23:18 +08:00
|
|
|
ss->type = PORT_16654;
|
|
|
|
ss->line = port->minor;
|
|
|
|
ss->port = port->port_number;
|
|
|
|
ss->baud_base = 460800;
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-02-26 23:50:24 +08:00
|
|
|
static void pl2303_set_break(struct usb_serial_port *port, bool enable)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct usb_serial *serial = port->serial;
|
|
|
|
u16 state;
|
|
|
|
int result;
|
|
|
|
|
2015-02-26 23:50:24 +08:00
|
|
|
if (enable)
|
2005-04-17 06:20:36 +08:00
|
|
|
state = BREAK_ON;
|
2015-02-26 23:50:24 +08:00
|
|
|
else
|
|
|
|
state = BREAK_OFF;
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "%s - turning break %s\n", __func__,
|
2008-07-22 18:14:49 +08:00
|
|
|
state == BREAK_OFF ? "off" : "on");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-08-01 02:39:27 +08:00
|
|
|
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
|
|
|
|
BREAK_REQUEST, BREAK_REQUEST_TYPE, state,
|
|
|
|
0, NULL, 0, 100);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (result)
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_err(&port->dev, "error sending break = %d\n", result);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-02-26 23:50:24 +08:00
|
|
|
static void pl2303_break_ctl(struct tty_struct *tty, int state)
|
|
|
|
{
|
|
|
|
struct usb_serial_port *port = tty->driver_data;
|
|
|
|
|
|
|
|
pl2303_set_break(port, state);
|
|
|
|
}
|
|
|
|
|
2005-04-19 08:39:31 +08:00
|
|
|
static void pl2303_update_line_status(struct usb_serial_port *port,
|
|
|
|
unsigned char *data,
|
|
|
|
unsigned int actual_length)
|
|
|
|
{
|
2013-12-30 02:23:05 +08:00
|
|
|
struct usb_serial *serial = port->serial;
|
|
|
|
struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
|
2005-04-19 08:39:31 +08:00
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
2011-01-14 21:30:21 +08:00
|
|
|
struct tty_struct *tty;
|
2005-04-19 08:39:31 +08:00
|
|
|
unsigned long flags;
|
2013-12-30 02:23:05 +08:00
|
|
|
unsigned int status_idx = UART_STATE_INDEX;
|
2014-01-03 05:49:21 +08:00
|
|
|
u8 status;
|
|
|
|
u8 delta;
|
2005-04-19 08:39:31 +08:00
|
|
|
|
2013-12-30 02:23:05 +08:00
|
|
|
if (spriv->quirks & PL2303_QUIRK_UART_STATE_IDX0)
|
|
|
|
status_idx = 0;
|
2005-04-19 08:39:31 +08:00
|
|
|
|
2013-12-30 02:23:05 +08:00
|
|
|
if (actual_length < status_idx + 1)
|
2006-07-26 03:58:30 +08:00
|
|
|
return;
|
2005-04-19 08:39:31 +08:00
|
|
|
|
2014-01-03 05:49:21 +08:00
|
|
|
status = data[status_idx];
|
|
|
|
|
2008-07-22 18:14:49 +08:00
|
|
|
/* Save off the uart status for others to look at */
|
2005-04-19 08:39:31 +08:00
|
|
|
spin_lock_irqsave(&priv->lock, flags);
|
2014-01-03 05:49:21 +08:00
|
|
|
delta = priv->line_status ^ status;
|
|
|
|
priv->line_status = status;
|
2005-04-19 08:39:31 +08:00
|
|
|
spin_unlock_irqrestore(&priv->lock, flags);
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2014-01-03 05:49:21 +08:00
|
|
|
if (status & UART_BREAK_ERROR)
|
2009-05-30 02:34:16 +08:00
|
|
|
usb_serial_handle_break(port);
|
2013-12-30 02:23:00 +08:00
|
|
|
|
2014-01-03 05:49:22 +08:00
|
|
|
if (delta & UART_STATE_MSR_MASK) {
|
2014-01-03 05:49:23 +08:00
|
|
|
if (delta & UART_CTS)
|
|
|
|
port->icount.cts++;
|
|
|
|
if (delta & UART_DSR)
|
|
|
|
port->icount.dsr++;
|
|
|
|
if (delta & UART_RING)
|
|
|
|
port->icount.rng++;
|
2014-01-03 05:49:22 +08:00
|
|
|
if (delta & UART_DCD) {
|
2014-01-03 05:49:23 +08:00
|
|
|
port->icount.dcd++;
|
2014-01-03 05:49:22 +08:00
|
|
|
tty = tty_port_tty_get(&port->port);
|
|
|
|
if (tty) {
|
|
|
|
usb_serial_handle_dcd_change(port, tty,
|
2014-01-03 05:49:21 +08:00
|
|
|
status & UART_DCD);
|
2014-01-03 05:49:22 +08:00
|
|
|
tty_kref_put(tty);
|
|
|
|
}
|
2014-01-03 05:49:21 +08:00
|
|
|
}
|
2014-01-03 05:49:22 +08:00
|
|
|
|
|
|
|
wake_up_interruptible(&port->port.delta_msr_wait);
|
2014-01-03 05:49:21 +08:00
|
|
|
}
|
2005-04-19 08:39:31 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 21:55:46 +08:00
|
|
|
static void pl2303_read_int_callback(struct urb *urb)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-02-24 18:41:47 +08:00
|
|
|
struct usb_serial_port *port = urb->context;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned char *data = urb->transfer_buffer;
|
2005-04-19 08:39:31 +08:00
|
|
|
unsigned int actual_length = urb->actual_length;
|
2007-06-16 06:44:13 +08:00
|
|
|
int status = urb->status;
|
|
|
|
int retval;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-06-16 06:44:13 +08:00
|
|
|
switch (status) {
|
2005-04-17 06:20:36 +08:00
|
|
|
case 0:
|
|
|
|
/* success */
|
|
|
|
break;
|
|
|
|
case -ECONNRESET:
|
|
|
|
case -ENOENT:
|
|
|
|
case -ESHUTDOWN:
|
|
|
|
/* this urb is terminated, clean up */
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "%s - urb shutting down with status: %d\n",
|
|
|
|
__func__, status);
|
2005-04-17 06:20:36 +08:00
|
|
|
return;
|
|
|
|
default:
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_dbg(&port->dev, "%s - nonzero urb status received: %d\n",
|
|
|
|
__func__, status);
|
2005-04-17 06:20:36 +08:00
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
2012-09-18 16:58:57 +08:00
|
|
|
usb_serial_debug_data(&port->dev, __func__,
|
2006-08-01 02:39:27 +08:00
|
|
|
urb->actual_length, urb->transfer_buffer);
|
|
|
|
|
2005-04-19 08:39:31 +08:00
|
|
|
pl2303_update_line_status(port, data, actual_length);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
exit:
|
2007-06-16 06:44:13 +08:00
|
|
|
retval = usb_submit_urb(urb, GFP_ATOMIC);
|
2013-12-30 02:23:00 +08:00
|
|
|
if (retval) {
|
2012-05-04 07:39:27 +08:00
|
|
|
dev_err(&port->dev,
|
2006-08-01 02:39:27 +08:00
|
|
|
"%s - usb_submit_urb failed with result %d\n",
|
2008-03-04 08:08:34 +08:00
|
|
|
__func__, retval);
|
2013-12-30 02:23:00 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-03-18 06:05:58 +08:00
|
|
|
static void pl2303_process_read_urb(struct urb *urb)
|
2009-07-09 20:36:58 +08:00
|
|
|
{
|
2010-03-18 06:05:58 +08:00
|
|
|
struct usb_serial_port *port = urb->context;
|
|
|
|
struct pl2303_private *priv = usb_get_serial_port_data(port);
|
2009-07-09 20:36:58 +08:00
|
|
|
unsigned char *data = urb->transfer_buffer;
|
|
|
|
char tty_flag = TTY_NORMAL;
|
2010-03-18 06:05:58 +08:00
|
|
|
unsigned long flags;
|
|
|
|
u8 line_status;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* update line status */
|
|
|
|
spin_lock_irqsave(&priv->lock, flags);
|
|
|
|
line_status = priv->line_status;
|
|
|
|
priv->line_status &= ~UART_STATE_TRANSIENT_MASK;
|
|
|
|
spin_unlock_irqrestore(&priv->lock, flags);
|
|
|
|
|
|
|
|
if (!urb->actual_length)
|
|
|
|
return;
|
|
|
|
|
2013-12-30 02:23:00 +08:00
|
|
|
/*
|
|
|
|
* Break takes precedence over parity, which takes precedence over
|
|
|
|
* framing errors.
|
|
|
|
*/
|
2009-07-09 20:36:58 +08:00
|
|
|
if (line_status & UART_BREAK_ERROR)
|
|
|
|
tty_flag = TTY_BREAK;
|
|
|
|
else if (line_status & UART_PARITY_ERROR)
|
|
|
|
tty_flag = TTY_PARITY;
|
|
|
|
else if (line_status & UART_FRAME_ERROR)
|
|
|
|
tty_flag = TTY_FRAME;
|
|
|
|
|
2013-06-26 22:47:30 +08:00
|
|
|
if (tty_flag != TTY_NORMAL)
|
|
|
|
dev_dbg(&port->dev, "%s - tty_flag = %d\n", __func__,
|
|
|
|
tty_flag);
|
2009-07-09 20:36:58 +08:00
|
|
|
/* overrun is special, not associated with a char */
|
|
|
|
if (line_status & UART_OVERRUN_ERROR)
|
2013-01-03 22:53:03 +08:00
|
|
|
tty_insert_flip_char(&port->port, 0, TTY_OVERRUN);
|
2009-10-08 17:36:46 +08:00
|
|
|
|
2020-07-08 20:49:54 +08:00
|
|
|
if (port->sysrq) {
|
2009-07-09 20:36:58 +08:00
|
|
|
for (i = 0; i < urb->actual_length; ++i)
|
2010-08-18 12:15:47 +08:00
|
|
|
if (!usb_serial_handle_sysrq_char(port, data[i]))
|
2013-01-03 22:53:03 +08:00
|
|
|
tty_insert_flip_char(&port->port, data[i],
|
|
|
|
tty_flag);
|
2010-05-08 21:18:41 +08:00
|
|
|
} else {
|
2013-01-03 22:53:02 +08:00
|
|
|
tty_insert_flip_string_fixed_flag(&port->port, data, tty_flag,
|
2010-05-08 21:18:41 +08:00
|
|
|
urb->actual_length);
|
2009-10-08 17:36:46 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-01-03 22:53:06 +08:00
|
|
|
tty_flip_buffer_push(&port->port);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-07-29 21:46:37 +08:00
|
|
|
static struct usb_serial_driver pl2303_device = {
|
|
|
|
.driver = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.name = "pl2303",
|
|
|
|
},
|
|
|
|
.id_table = id_table,
|
2017-03-02 19:51:31 +08:00
|
|
|
.num_bulk_in = 1,
|
|
|
|
.num_bulk_out = 1,
|
2017-03-17 00:13:34 +08:00
|
|
|
.num_interrupt_in = 0, /* see pl2303_calc_num_ports */
|
2010-03-18 06:00:41 +08:00
|
|
|
.bulk_in_size = 256,
|
2010-03-18 06:00:40 +08:00
|
|
|
.bulk_out_size = 256,
|
2006-07-29 21:46:37 +08:00
|
|
|
.open = pl2303_open,
|
|
|
|
.close = pl2303_close,
|
2013-12-30 02:23:00 +08:00
|
|
|
.dtr_rts = pl2303_dtr_rts,
|
2009-06-11 19:26:29 +08:00
|
|
|
.carrier_raised = pl2303_carrier_raised,
|
2018-09-12 19:23:18 +08:00
|
|
|
.get_serial = pl2303_get_serial,
|
2006-07-29 21:46:37 +08:00
|
|
|
.break_ctl = pl2303_break_ctl,
|
|
|
|
.set_termios = pl2303_set_termios,
|
|
|
|
.tiocmget = pl2303_tiocmget,
|
|
|
|
.tiocmset = pl2303_tiocmset,
|
2014-01-03 05:49:23 +08:00
|
|
|
.tiocmiwait = usb_serial_generic_tiocmiwait,
|
2010-03-18 06:05:58 +08:00
|
|
|
.process_read_urb = pl2303_process_read_urb,
|
2006-07-29 21:46:37 +08:00
|
|
|
.read_int_callback = pl2303_read_int_callback,
|
2013-12-30 02:23:05 +08:00
|
|
|
.probe = pl2303_probe,
|
2017-03-17 00:13:34 +08:00
|
|
|
.calc_num_ports = pl2303_calc_num_ports,
|
2006-07-29 21:46:37 +08:00
|
|
|
.attach = pl2303_startup,
|
2009-06-02 23:53:55 +08:00
|
|
|
.release = pl2303_release,
|
2012-10-15 21:47:21 +08:00
|
|
|
.port_probe = pl2303_port_probe,
|
|
|
|
.port_remove = pl2303_port_remove,
|
2006-07-29 21:46:37 +08:00
|
|
|
};
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-02-24 03:57:18 +08:00
|
|
|
static struct usb_serial_driver * const serial_drivers[] = {
|
|
|
|
&pl2303_device, NULL
|
|
|
|
};
|
|
|
|
|
2012-05-09 06:46:14 +08:00
|
|
|
module_usb_serial_driver(serial_drivers, id_table);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-12-30 02:23:00 +08:00
|
|
|
MODULE_DESCRIPTION("Prolific PL2303 USB to serial adaptor driver");
|
2017-11-04 01:12:08 +08:00
|
|
|
MODULE_LICENSE("GPL v2");
|