Re: Piggy-backing new hardware using old usb-serial
On Wed, Mar 27, 2013 at 08:45:38PM +0100, Wesley W. Terpstra wrote: > 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. Yes, Sierra will get mad at you :) 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. > 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. 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. > What driver should I target? What chip do you use for your device? If you just want "raw" data, then do something like the drivers/usb/serial/zio.c driver, tiny, simple, and trivial. Hope this helps, greg k-h -- 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 Wed, Mar 27, 2013 at 09:28:11PM +0100, Wesley W. Terpstra wrote: > 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. Not true at all, we take drivers for _anything_ :) > I take it then, that just adding support to an existing driver is > acceptable? That's also ok, if you are using the same chip that the driver supports. > 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. You can use the CDC-ACM driver, as you have pointed out, which should allow your device to work on any OS with no driver needed, so maybe just use that instead. There's no need to support modem commands in your device if you use it. > > > 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 use the ftdi chip, then use the ftdi driver, and add the device id that ftdi gives you to it. Hope this helps, greg k-h -- 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 16:13 -0700, Greg KH wrote: > On Wed, Mar 27, 2013 at 09:28:11PM +0100, Wesley W. Terpstra wrote: > > 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. > > Not true at all, we take drivers for _anything_ :) > > > I take it then, that just adding support to an existing driver is > > acceptable? > > That's also ok, if you are using the same chip that the driver supports. > > > 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. > > You can use the CDC-ACM driver, as you have pointed out, which should > allow your device to work on any OS with no driver needed, so maybe just > use that instead. There's no need to support modem commands in your > device if you use it. 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. That's kind of hard to do without a unique USB VID/PID though :) Dan > > > > 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 use the ftdi chip, then use the ftdi driver, and add the device > id that ftdi gives you to it. > > Hope this helps, > > greg k-h > -- > 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 -- 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
Re: Piggy-backing new hardware using old usb-serial
On Thu, 2013-03-28 at 15:58 +0100, Wesley W. Terpstra wrote: > 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. ModemManager looks at a certain set of serial devices and probes each TTY the device provides with AT commands, Qualcomm DIAG (QCDM) requests, Qualcomm MSM Interface (QMI) requests, and potentially other protocols. It does filter devices based on driver name (eg, 'sierra' is certainly a modem while 'whiteheat' certainly is not). Probing is necessary because there are a *ton* of devices out there, manufacturers often use the same VID/PID for wildly different devices (even completely different modem chipsets *cough* TCT Mobile *cough*), or don't bother to use a unique VID/PID at all. Sometimes firmware updates change the USB interface layout, so what used to be an AT port is now a DIAG port, or even the PID has changed. We've seen it all. We've tried the tag-every-known-modem-by-USB-details approach before, and that simply isn't scalable, especially when you throw tethering your handset into the mix. There are even more phones than there are USB dongles. Windows doesn't have this problem, because your dongle provider or cellular provider provides the drivers for their specific device, and you're never expected to install more than one set of drivers at a time. Get a new device? Great! Install the connection manager specific for that device and uninstall the old one. Probing does break things on devices that don't expect it, like UPSs or other stuff, which is why we have a blacklist for stuff we know MM shouldn't probe. Happy to add to it. Dan > 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 -- 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, Mar 28, 2013 at 10:58 PM, Wesley W. Terpstra wrote: > 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. It is not allowed by USBIF to resell PIDs and the mcselec vendor ID has been revoked by USBIF. So you may not want to go that route either. Ref: in the above URL, it is mentioned by mcselec that "That changed in June 2009 when USB-ORG wrote an email that it was not permitted to sell VID or PID. MCS pointed out that in The Netherlands you can not enforce or change rules AFTER a product/service is sold. So we continued as usual." If you do not want to pay US$5000 for the VID, then you can try to use some chip vendor's PID sub-licensing scheme, eg, from FTDI, TI, Microchip, etc. They will offer you a free PID if you use their product subject to some terms and conditions. -- Xiaofan -- 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
