Piggy-backing new hardware using old usb-serial
Good evening, We are developing a custom piece of hardware that provides the equivalent of two serial console interfaces. They do not speak the AT command set. One port provides an interactive console to the user for configuration purposes (via minicom/etc). The other speaks a proprietary protocol used by purpose-built userspace tools. Neither port has an inherent baud rate limit; both can fully utilize USB2 bandwidth. The closest standard USB-IF class I could find is the cdc-acm device class. However, this seems to be very much targeted at modems with ATx commands. The linux cdc-acm drivers would put the hardware at /dev/ttyACM and software seems to treat these like modems. The closer matching usb-serial dongles all appear to have unstandardized drivers. We would like our hardware to work "out of the box" on released Linux versions (and to a lesser extent on windows). Our current prototypes borrow the Sierra VID to trick the kernel into loading the sierra driver. This works well for the interactive console. However, I assume that distributing the device like this will have legal consequences. I could write a custom driver, but then end users need to compile +install it. Our device will never be widely available and thus our driver will never be included in linux, ie: even future users will have to compile+install for themselves. Because the USB logic is inside an FPGA, I can readily change the hardware to suite any existing driver. What driver should I target? Is there a way to AUTOload an older driver despite the new VID:PID? Should I give up and require a custom driver? Thank you for any and all feedback/advice. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Piggy-backing new hardware using old usb-serial
On Wed, 2013-03-27 at 13:06 -0700, Greg KH wrote: > > Our current prototypes borrow the Sierra VID > And the USB-IF might revoke your vendor id, if they find you shipping a > device with a different vendor id than the one you have been assigned. One of the reasons we borrowed that VID is that we do not currently have a VID assigned. We are still deciding whether it is worth joining the USB-IF just to get a vendor ID for a few thousands of devices. I am of the opinion that it is, but I cannot sign the membership forms on behalf of GSI. We probably will end up buying a VID soon. > Why not just add your device id to an existing driver, sending in a > patch to do so. All distros will pick that up and then your device will > "just work" on all Linux distros. I was under the impression that drivers in the linux mainline had to be for hardware that was widely available. I take it then, that just adding support to an existing driver is acceptable? That wouldn't address people with older linux distributions, but would definitely be a good long term solution. It's really a shame there is no USB-IF standard for usb-serial... then things would even potentially work out of the box on windows. > > What driver should I target? > What chip do you use for your device? The device I am concerned about right now has an Altera arria2 connected to a cy7c68013a-56baxc (fx2lp). We have several form factor variations. A few have FTDI chips where I don't need to care, but can also do less. > If you just want "raw" data, then do something like the > drivers/usb/serial/zio.c driver, tiny, simple, and trivial. Yes, if I make source-level changes to the kernel I have many options. PS. Thank you for the very prompt reply! -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Piggy-backing new hardware using old usb-serial
On Thu, 2013-03-28 at 09:39 -0500, Dan Williams wrote: > Greg's right, there's no reason not to use cdc-acm if you want to do > that, since not all cdc-acm devices are modems. If you get a USBIF > vendor ID, then I'll happily add your device to the ModemManager probing > blacklist too. Yes, the cdc-acm approach has the distinct advantage of not having to write one driver for each OS. What does ModemManager probing consist of? Sending a few ATx commands to see what the device is? On the interactive console that wouldn't hurt, but on the proprietary data channel it could break things. I assume that it poses no problem to the linux cdc enumeration if my device reports two data interfaces (with two endpoints each). Once I have added an interrupt endpoint and ignore the class specific requests to meet the CDC-ACM interface and have a valid VID+PID pair, I'll get back to you. In case anyone else cares, I found some nice Dutch folks who resell PIDs under their VID for cheap: http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1 I will probably go this route for now. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB-Wishbone bridge adapter
ass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 5 USB-Wishbone Bridge
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x
(Bus Powered)
/*
* USB-WB adapter driver
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License version
* 2 as published by the Free Software Foundation.
*/
#include
#include
#include
#include
#include
#include
#include
#define GSI_VENDOR_OPENCLOSE 0xB0
static const struct usb_device_id id_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x1D50, 0x6062, 0xFF, 0xFF, 0xFF) },
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
static struct usb_driver usb_wb_driver = {
.name = "usb_wb",
.probe = usb_serial_probe,
.disconnect = usb_serial_disconnect,
.id_table = id_table,
.no_dynamic_id = 1,
};
static int usb_wb_open(struct tty_struct *tty, struct usb_serial_port *port)
{
struct usb_device *dev = port->serial->dev;
int result;
result = usb_control_msg(
dev,
usb_sndctrlpipe(dev, 0), /* Send to EP0OUT */
GSI_VENDOR_OPENCLOSE,
USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
1, /* wValue (2..3) = device is open */
port->serial->interface->cur_altsetting->desc.bInterfaceNumber,
0, 0, /* no data stage */
5000); /* timeout */
if (result < 0)
dev_err(&dev->dev, "Could not mark device as open (result = %d)\n", result);
return usb_serial_generic_open(tty, port);
}
static void usb_wb_close(struct usb_serial_port *port)
{
struct usb_device *dev = port->serial->dev;
int result;
result = usb_control_msg(
dev,
usb_sndctrlpipe(dev, 0), /* Send to EP0OUT */
GSI_VENDOR_OPENCLOSE,
USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
0, /* wValue (2..3) = device is closed */
port->serial->interface->cur_altsetting->desc.bInterfaceNumber,
0, 0, /* no data stage */
5000); /* timeout */
if (result < 0)
dev_err(&dev->dev, "Could not mark device as closed (result = %d)\n", result);
return usb_serial_generic_close(port);
}
static struct usb_serial_driver usb_wb_device = {
.driver = {
.owner = THIS_MODULE,
.name = "usb_wb",
},
.id_table = id_table,
.usb_driver = &usb_wb_driver,
.num_ports = 1,
.open = &usb_wb_open,
.close = &usb_wb_close,
};
static int __init usb_wb_init(void)
{
int retval;
retval = usb_serial_register(&usb_wb_device);
if (retval)
return retval;
retval = usb_register(&usb_wb_driver);
if (retval)
usb_serial_deregister(&usb_wb_device);
return retval;
}
static void __exit usb_wb_exit(void)
{
usb_deregister(&usb_wb_driver);
usb_serial_deregister(&usb_wb_device);
}
MODULE_AUTHOR("Wesley W. Terpstra ");
MODULE_DESCRIPTION("Wishbone-USB adapter");
MODULE_LICENSE("GPL");
module_init(usb_wb_init);
module_exit(usb_wb_exit);
Re: USB-Wishbone bridge adapter
On Wed, 2013-04-10 at 19:01 +0200, Wesley W. Terpstra wrote: > I've attached the output of lsusb -v ... and of course attached the output of an older version of the device. The capabilities should read: CDC ACM: bmCapabilities 0x02 line coding and serial state ... otherwise it is the same. I am not 100% certain if the "CDC Call Management" record should be present in a non-modem device. This record may disappear once I've clarified this detail of standard. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-Wishbone bridge adapter
On Wed, 2013-04-10 at 10:08 -0700, Greg KH wrote: > On Wed, Apr 10, 2013 at 07:01:40PM +0200, Wesley W. Terpstra wrote: > > Greg, I've attached a small Linux driver which recognizes and the > > USB-Wishbone functionality of the device. It just adds two vendor > > messages to signal to the FPGA that the device has been opened. Please > > let me know what needs to be improved before it could be considered for > > inclusion in the kernel proper. > > You need to send it in a format that I can use to apply it (hint, read > the file, Documentation/SubmittingPatches.) If you do that, I will be > glad to review it, and if all is good, apply it to the kernel tree. Alrighty. I will prepare a patch version of it tomorrow. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb-serial: add support for USB Wishbone-serial adapters
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
---
drivers/usb/serial/Kconfig | 17 ++
drivers/usb/serial/Makefile |1 +
drivers/usb/serial/wishbone-serial.c | 95 ++
3 files changed, 113 insertions(+)
create mode 100644 drivers/usb/serial/wishbone-serial.c
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 17b7f9a..504f26e 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -667,6 +667,23 @@ config USB_SERIAL_ZIO
To compile this driver as a module, choose M here: the
module will be called zio.
+config USB_SERIAL_WISHBONE
+ tristate "USB-Wishbone adapter interface driver"
+ help
+ Say Y here if you want to use a USB attached Wishbone bus.
+
+ 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.
+
+ To compile this driver as a module, choose M here: the
+ module will be called wishbone-serial.
+
config USB_SERIAL_ZTE
tristate "ZTE USB serial driver"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index eaf5ca1..cec63fa 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_USB_SERIAL_SYMBOL) +=
symbolserial.o
obj-$(CONFIG_USB_SERIAL_WWAN) += usb_wwan.o
obj-$(CONFIG_USB_SERIAL_TI)+= ti_usb_3410_5052.o
obj-$(CONFIG_USB_SERIAL_VISOR) += visor.o
+obj-$(CONFIG_USB_SERIAL_WISHBONE) += wishbone-serial.o
obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
obj-$(CONFIG_USB_SERIAL_XIRCOM)+= keyspan_pda.o
obj-$(CONFIG_USB_SERIAL_VIVOPAY_SERIAL)+= vivopay-serial.o
diff --git a/drivers/usb/serial/wishbone-serial.c
b/drivers/usb/serial/wishbone-serial.c
new file mode 100644
index 000..481ec66
--- /dev/null
+++ b/drivers/usb/serial/wishbone-serial.c
@@ -0,0 +1,95 @@
+/*
+ * USB Wishbone-Serial adapter driver
+ *
+ * Copyright (C) 2013 Wesley W. Terpstra
+ * Copyright (C) 2013 GSI Helmholtz Centre for Heavy Ion Research GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GSI_VENDOR_OPENCLOSE 0xB0
+
+static const struct usb_device_id id_table[] = {
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1D50, 0x6062, 0xFF, 0xFF, 0xFF) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table);
+
+/*
+ * Etherbone must be told that a new stream has begun before data arrives.
+ * This is necessary to restart the negotiation of Wishbone bus parameters.
+ * Similarly, when the stream ends, Etherbone must be told so that the cycle
+ * line can be driven low in the case that userspace failed to do so.
+ */
+static int usb_gsi_openclose(struct usb_serial_port *port, int value)
+{
+ struct usb_device *dev = port->serial->dev;
+
+ return usb_control_msg(
+ dev,
+ usb_sndctrlpipe(dev, 0), /* Send to EP0OUT */
+ GSI_VENDOR_OPENCLOSE,
+ USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
+ value, /* wValue = device is open(1) or closed(0) */
+ port->serial->interface->cur_altsetting->desc.bInterfaceNumber,
+ 0, 0, /* There is no data stage */
+ 5000); /* Timeout till operation fails */
+}
+
+static int wishbone_serial_open(struct tty_struct *tty,
+ struct usb_serial_port *port)
+{
+ int retval;
+
+ retval = usb_gsi_openclose(port, 1);
+ if (retval) {
+ dev_err(&port->serial->dev->dev,
+ "Could not mark device as open (%d)\n",
+ retval);
+ return retval;
+ }
+
+ retval = usb_serial_generic_open(
Re: [PATCH] usb-serial: add support for USB Wishbone-serial adapters
On Thu, 2013-04-11 at 06:45 -0700, Greg KH wrote: > I only have one very minor question about the code: > > > +++ b/drivers/usb/serial/wishbone-serial.c > > @@ -0,0 +1,95 @@ > > +/* > > + * USB Wishbone-Serial adapter driver > > + * > > + * Copyright (C) 2013 Wesley W. Terpstra > > + * Copyright (C) 2013 GSI Helmholtz Centre for Heavy Ion Research GmbH > > + * > > + * This program is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License > > + * as published by the Free Software Foundation; either version 2 > > + * of the License, or (at your option) any later version. > > + */ > > Do you really mean "or any later version" for the license of this > driver? I ask as the kernel itself is GPLv2-only. It's fine if you > want this to be GPLv2+, I just have to ask. Yes, I know the kernel is v2. Which is a shame because the FSF made the v3 licence which some people would prefer. If in the distant future, the kernel were to slowly be relicenced as v2+ or v3, I don't want to contribute to the migration problem. A question for you in turn: why were usb_serial_[de]register removed? The new usb_serial_deregister_drivers isn't available in older kernels. So drivers cannot support (without ifdefs) both old and new kernels -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb-serial: add support for USB Wishbone-serial adapters
On Thu, 2013-04-11 at 08:15 -0700, Greg KH wrote: > Fair enough, although this driver would probably be the least of our > worries if that were to happen :) Of course. > Documenation/stable_api_nonsense.txt Tactfully named. :) Is there a document that describes how to track the progress a patch makes on its way to a released kernel version? I understand that subsystem maintainers aggregate changes which then are aggregated in turn by Linus, but beyond that I have no understanding of the flow. Also: Thank you very much for all your help. I've made several kernel modules over the years, but never submitted any of them for inclusion because I had the (it seems false) impression that the linux kernel development process was full of angry people who would make it unpleasant. Glad to learn that this is just a myth! I will probably contribute more patches in the future. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
