The zte_ev driver is based on code (once) distributed by ZTE that still appears to originally have been reverse-engineered and bolted onto the generic driver. A closer analysis of the zte_ev setup code reveals that it consists of standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE) but unfortunately fails to get some of those right. In particular, as reported by Lei Liu, it fails to lower DTR/RTS on close. It also appears that the control requests lack the interface argument. Since line control is already handled properly by the option driver, and the SET/GET_LINE_CODING requests appears to be redundant (amounts to a SET 9600 8N1) let's remove the redundant zte_ev driver. Also move the remaining ZTE PIDs to the generic option modem driver. Reported-by: Lei Liu <liu.lei78@zte.com.cn> Signed-off-by: Johan Hovold <johan@kernel.org>
Add a driver which supports the following Moxa USB to serial converters: * 2 ports : UPort 1250, UPort 1250I * 4 ports : UPort 1410, UPort 1450, UPort 1450I * 8 ports : UPort 1610-8, UPort 1650-8 * 16 ports : UPort 1610-16, UPort 1650-16 The UPORT devices don't directly fit the USB serial model. USB serial assumes a bulk in/out endpoint pair per serial port. Thus a dual port USB serial device is expected to have two bulk in/out pairs. The Moxa UPORT only has one pair for data transfer and places a header on each transfer over the endpoint indicating for which port the transfer relates to. There is a second endpoint pair for events, such as modem control lines changing state, setting baud rates etc. Again, a multiplexing header is used on these endpoints. Some ports need to have a kfifo explicitly allocated since the framework does not allocate one if there is no associated endpoints. The framework will however free it on unload of the module. All data transfers are made on port0, yet the locks are taken on PortN. urb->context points to PortN, even though the URB is for port0. Where possible, code from the generic driver is called. However mxuport_process_read_urb_data() is mostly a cut/paste of usb_serial_generic_process_read_urb(). The driver will attempt to load firmware from userspace and compare the available version and the running version. If the available version is newer, it will be download into RAM of the device and started. This is optional and the driver appears to work O.K. with older firmware in the devices ROM. This driver is based on the MOXA driver and retains MOXAs copyright. [jhovold@gmail.com: fix get_fw_version error path and some style issues] Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of having to create a new driver for a "simple" usb to serial device, mush them all into one file, with a macro, so as to make it easy to add new ones. Cc: "René Bürgel" <rene.buergel@sohard.de> Acked-by: Wei Shuai <cpuwolf@gmail.com> Cc: Josh Triplett <josh@joshtriplett.org> Acked-by: Frans Klaver <frans.klaver@xsens.com> Cc: "Wesley W. Terpstra" <w.terpstra@gsi.de> Cc: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds a driver for the Suunto ANT+ USB device, exposing it as a usb serial device. This lets the userspace "gant" program to talk to the device to communicate over the ANT+ protocol to any devices it finds. Reported-by: Steinar Gunderson <sgunderson@bigfoot.com> Tested-by: Steinar Gunderson <sgunderson@bigfoot.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If you want to download Infineon modem via USB, this Infineon USB flashloader driver is required. Signed-off-by: Wei Shuai <cpuwolf@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wishbone is an open hardware SoC bus commonly used in FPGA designs. Bus access can be serialized using the Etherbone protocol <http://www.ohwr.org/projects/etherbone-core>. This driver is intended to be used with devices which attach their internal Wishbone bus to a USB serial interface using the Etherbone protocol. A userspace library is required to speak the protocol made available by this driver as ttyUSBx. Signed-off-by: Wesley W. Terpstra <w.terpstra@gsi.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frans Klaver <frans.klaver@xsens.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch - moves drivers/usb/serial/ezusb.c to drivers/usb/misc/ - renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors - adapts Makefiles and Kconfigs switching from bool to tristate for CONFIG_USB_EZUSB_FX2 Signed-off-by: René Bürgel <rene.buergel@sohard.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's out-dated for the tty-layer stuff, and would require a bunch of work. That's not really a big deal, the big issue is that there is no company contact for the hardware, so questions we have about it (like why isn't this just handled by the cdc-acm driver instead?) go unanswered. So drop the driver. If someone comes along to help answer the questions, we can easily revert this and fix up the code. Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Rob Duncan <rob.duncan@exar.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here's a driver for the Vizzini USB to serial device. It looks to be copied from cdc-acm, and probably can be cleaned up a lot more. Also, there's some odd "try to grab another interface" that is probably wrong. And, if this really is a cdc-acm device, it probably should just be a quirk of the cdc-acm device, but I can't figure that out, and people have been using this driver for a long time now. So merge it to let people use their hardware and clean it up over time. Driver written by Rob Duncan but cleaned up and forward ported to the latest kernel tree by me. Cc: Rob Duncan <rob.duncan@exar.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>