From sacadmin Tue Mar 24 21:55:08 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2P4t8F8002777; Tue, 24 Mar 2009 21:55:08 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2P4t8fo157046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 21:55:08 -0700 (PDT) Received: (from tpm@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n2P4t8jD157042; Tue, 24 Mar 2009 21:55:08 -0700 (PDT) Date: Tue, 24 Mar 2009 21:55:08 -0700 (PDT) From: Tim Marsland Message-Id: <200903250455.n2P4t8jD157042@jurassic-x4600.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: UFTDI [PSARC/2009/197 FastTrack] Status: RO Content-Length: 539 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: UFTDI 1.2. Name of Document Author/Supplier: Author: Tim Marsland 1.3 Date of This Document: 24 March, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Mon Mar 30 16:08:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2UN8edu010476 for ; Mon, 30 Mar 2009 16:08:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2UN8XLh022109 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Tue, 31 Mar 2009 00:08:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHC00B01DMEJX00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 16:08:38 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHC004XNDME9UA0@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 16:08:38 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2UN8b6a013413 for ; Mon, 30 Mar 2009 23:08:37 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHC00L00CVGHP00@mail-amer.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 17:08:37 -0600 (MDT) Received: from [129.146.229.25] ([unknown] [129.146.229.25]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHC00H12DLLUA00@mail-amer.sun.com>; Mon, 30 Mar 2009 17:08:10 -0600 (MDT) Date: Mon, 30 Mar 2009 16:08:03 -0700 From: Tim Marsland Subject: psarc/2009/197 - UFTDI - fast-track Sender: Tim.Marsland@sun.com To: psarc@sun.com Cc: Strony Zhang , Lin Guo , Tim.Marsland@sun.com Message-id: <49D150D3.6060305@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 3827 I'm sponsoring this fast-track for me. If approved, the case would time out April 6th 2009. The release binding sought for these changes is "Patch". The materials directory contains the manpage for the device. This project is essentially about adding yet another USB serial port driver. In that sense it is uninteresting to the ARC, because we have already established the architecture for USB serial port devices in the numerous USB cases that have come before the ARC over the past eight years. However, there are two additional issues that this device driver raises - hence this case. #1 Support for 921600 baud There are a number of peripheral devices that choose to use USB serial port devices internally for the sake of providing a simple programming model to their users. These peripherals may only use a few millimeters of actual RS232 electrical signals, and thus some surprisingly high baud rates can be supported. The desire to support 921600 baud comes from a customer application with a random number generator device that plugs into a USB port, though it presents a serial port interface using this driver to extract the random numbers. The highest baud rate currently supported by Solaris is 460800 baud; this case proposes to double that to the new maximum of 921600. Note that this is really a matter of adding a #define for B921600 to then also adding support to all the pieces of the system that "know" about the translation from the baud rate number to the encoded baud rate passed into the termios structure. Since this is also a baud rate supported by other open source OSes, and most applications that support higher baud rates conditionalize support for this baud rate under '#ifdef B921600'; recompilation against the updated termios.h header makes all the open source software i've looked at "just work" with this new (for solaris) baud rate. #2 Soft carrier properties (ignore-cd) The current default for "off-board" serial ports is to carefully honor the carrier detect line i.e. before /dev/term/N can be opened, the device must assert DCD. A complex interaction between /dev/term/N (a dial-in connection, e.g. enabled for login) and /dev/cua/N (a dial-out connection, for use with tip etc.) is supported in all Solaris serial devices which uses the DCD behaviour to implement this "shared" access method. However, for as long as I can recall, SPARC firmware and the simulation of it on x64 systems sets up *onboard* serial ports to ignore the carrier detect line, enabling "3-wire" connections - just gnd/rx/tx for a serial port. This is normally controlled by the 'ignore-cd?' property in SPARC firmware, or 'tty*-ignore-cd' in bootenv.rc on x86 -- both these properties are set to 'true', causing cause the state of the DCD line to be ignored by SW. This case asserts that, moving forward, the default behaviour for "off-board" serial ports should be the same as "on-board" serial ports -- the distinction being particularly ambiguous in the case of USB simulations of RS232 devices. To implement this for the UFTDI driver (usbftdi), the driver ships with a usbftdi.conf file that simply contains the property ignore-cd = 1; with an additional note that explains that finer-grain control for this behaviour (on a device instance basis) can be achieved using port-N-ignore-cd = 1; (e.g. port-4-ignore-cd for instance 4 of the device) These properties are decoded by the non-device specific part of the USB serial port infrastructure and have been present continuously, but have not been documented/exposed - this case would assign these properties an interface committment level of 'Stable'. This case proposes to make the same behaviour true for this new USB device, and to document the means of enabling this default for other USB serial devices too. From sacadmin Mon Mar 30 16:15:32 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2UNFWH2024437 for ; Mon, 30 Mar 2009 16:15:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2UNFWhQ017718 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Mon, 30 Mar 2009 16:15:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHC00B0XDXVZO00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 16:15:31 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHC004WTDXU9MB0@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 16:15:30 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2UNFUe9027336 for ; Mon, 30 Mar 2009 16:15:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHC00B00DPZYX00@fe-sfbay-10.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 16:15:29 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHC00KENDXL59F0@fe-sfbay-10.sun.com>; Mon, 30 Mar 2009 16:15:22 -0700 (PDT) Date: Mon, 30 Mar 2009 16:15:20 -0700 From: "Garrett D'Amore" Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <49D150D3.6060305@sun.com> Sender: Garrett.Damore@Sun.COM To: Tim Marsland Cc: psarc@Sun.COM, Strony Zhang , Lin Guo Message-id: <49D15288.5050906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D150D3.6060305@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4152 Looks good to me. +1. Does the ARC infrastructure deal with lower case ARC names properly ("psarc" vs. "PSARC")? -- Garrett Tim Marsland wrote: > I'm sponsoring this fast-track for me. > If approved, the case would time out April 6th 2009. > The release binding sought for these changes is "Patch". > The materials directory contains the manpage for the device. > > This project is essentially about adding yet another USB serial > port driver. In that sense it is uninteresting to the ARC, > because we have already established the architecture for USB > serial port devices in the numerous USB cases that have come > before the ARC over the past eight years. > > However, there are two additional issues that this device > driver raises - hence this case. > > #1 Support for 921600 baud > > There are a number of peripheral devices that choose to use USB > serial port devices internally for the sake of providing a simple > programming model to their users. These peripherals may only use > a few millimeters of actual RS232 electrical signals, and thus > some surprisingly high baud rates can be supported. > > The desire to support 921600 baud comes from a customer > application with a random number generator device that plugs into a > USB port, though it presents a serial port interface using this driver > to extract the random numbers. > > The highest baud rate currently supported by Solaris is 460800 baud; > this case proposes to double that to the new maximum of 921600. Note > that this is really a matter of adding a #define for B921600 to > then also adding support to all the pieces of the > system that "know" about the translation from the baud rate > number to the encoded baud rate passed into the termios structure. > > Since this is also a baud rate supported by other open source OSes, > and most applications that support higher baud rates > conditionalize support for this baud rate under > '#ifdef B921600'; recompilation against the updated termios.h > header makes all the open source software i've looked at > "just work" with this new (for solaris) baud rate. > > #2 Soft carrier properties (ignore-cd) > > The current default for "off-board" serial ports is to carefully > honor the carrier detect line i.e. before /dev/term/N can be opened, > the device must assert DCD. A complex interaction between /dev/term/N > (a dial-in connection, e.g. enabled for login) and /dev/cua/N (a > dial-out connection, for use with tip etc.) is supported in all > Solaris serial devices which uses the DCD behaviour to implement > this "shared" access method. > > However, for as long as I can recall, SPARC firmware and the > simulation of it on x64 systems sets up *onboard* serial > ports to ignore the carrier detect line, enabling "3-wire" > connections - just gnd/rx/tx for a serial port. This is normally > controlled by the 'ignore-cd?' property in SPARC firmware, > or 'tty*-ignore-cd' in bootenv.rc on x86 -- both these properties > are set to 'true', causing cause the state of the DCD line > to be ignored by SW. > > This case asserts that, moving forward, the default behaviour > for "off-board" serial ports should be the same as "on-board" > serial ports -- the distinction being particularly ambiguous > in the case of USB simulations of RS232 devices. > > To implement this for the UFTDI driver (usbftdi), the driver > ships with a usbftdi.conf file that simply contains the > property > > ignore-cd = 1; > > with an additional note that explains that finer-grain > control for this behaviour (on a device instance basis) > can be achieved using > > port-N-ignore-cd = 1; > > (e.g. port-4-ignore-cd for instance 4 of the device) > > These properties are decoded by the non-device specific > part of the USB serial port infrastructure and have been > present continuously, but have not been documented/exposed > - this case would assign these properties an interface > committment level of 'Stable'. > > This case proposes to make the same behaviour true for this > new USB device, and to document the means of enabling this > default for other USB serial devices too. > From sacadmin Mon Mar 30 20:00:00 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2V300Dp012659 for ; Mon, 30 Mar 2009 20:00:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2V2xxkn009120 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Mon, 30 Mar 2009 19:59:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHC00309OBWL900@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 19:59:56 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHC00FYROBVMA90@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 19:59:55 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2V2xtGB024739 for ; Mon, 30 Mar 2009 19:59:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHC00L00O86CC00@fe-sfbay-10.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 30 Mar 2009 19:59:55 -0700 (PDT) Received: from [129.146.104.83] ([unknown] [129.146.104.83]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHC00HEIOBUR410@fe-sfbay-10.sun.com>; Mon, 30 Mar 2009 19:59:55 -0700 (PDT) Date: Mon, 30 Mar 2009 19:59:45 -0700 From: Artem Kachitchkine Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <49D150D3.6060305@sun.com> Sender: Artem.Kachitchkin@Sun.COM To: Tim Marsland Cc: psarc@Sun.COM, Strony Zhang , Lin Guo Message-id: <49D18721.5090902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D150D3.6060305@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 647 +1 on the case. One nit: > with an additional note that explains that finer-grain > control for this behaviour (on a device instance basis) > can be achieved using > > port-N-ignore-cd = 1; > > (e.g. port-4-ignore-cd for instance 4 of the device) The way usbser is currently coded, N is not an instance number, but a port number. Instance numbers are pretty useless for USB, they change wildly depending on the bus topology. (USB allows devices to have serial numbers, but they are not required). So back then we felt that port-N-ignore-cd, while useful, was "architecturally incomplete". I have no problem exposing it now. -Artem From sacadmin Mon Mar 30 20:08:10 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2V38Awh013531 for ; Mon, 30 Mar 2009 20:08:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2V388QU012047 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Mon, 30 Mar 2009 20:08:10 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHC00817OPM1800@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@Sun.COM); Mon, 30 Mar 2009 21:08:10 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHC00KKMOPMID70@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@Sun.COM); Mon, 30 Mar 2009 21:08:10 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2V38A7T010652 for ; Mon, 30 Mar 2009 20:08:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHC00L00ONJQZ00@fe-sfbay-09.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 30 Mar 2009 20:08:10 -0700 (PDT) Received: from [129.146.104.83] ([unknown] [129.146.104.83]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHC00A2UOP7FU40@fe-sfbay-09.sun.com>; Mon, 30 Mar 2009 20:07:56 -0700 (PDT) Date: Mon, 30 Mar 2009 20:07:45 -0700 From: Artem Kachitchkine Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <49D18721.5090902@sun.com> Sender: Artem.Kachitchkin@sun.com To: Tim Marsland Cc: psarc@sun.com, Strony Zhang , Lin Guo Message-id: <49D18901.90309@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D150D3.6060305@sun.com> <49D18721.5090902@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 322 >> port-N-ignore-cd = 1; >> >> (e.g. port-4-ignore-cd for instance 4 of the device) > > The way usbser is currently coded, N is not an instance number, but a > port number. ... This refers to a serial port (some of these devices provide up to eight RS232 ports, like the Edgeport series). Not a USB port. -Artem From sacadmin Wed Apr 1 04:49:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31BnBUp000867 for ; Wed, 1 Apr 2009 04:49:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n31Bn5eg001977; Wed, 1 Apr 2009 04:49:07 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF0001H7HTQ200@nwk-avmta-1.sfbay.Sun.COM>; Wed, 01 Apr 2009 04:49:05 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF000DS7HQ2L00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 01 Apr 2009 04:49:02 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n31BmjcM016341; Wed, 01 Apr 2009 07:48:45 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n31BmiXK016338; Wed, 01 Apr 2009 07:48:45 -0400 (EDT) Date: Wed, 01 Apr 2009 07:48:44 -0400 From: James Carlson Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <49D15288.5050906@sun.com> To: "Garrett D'Amore" Cc: Tim Marsland , psarc@sun.com, Strony Zhang , Lin Guo Message-id: <18899.21660.985530.511249@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D150D3.6060305@sun.com> <49D15288.5050906@sun.com> Status: RO Content-Length: 907 Garrett D'Amore writes: > Looks good to me. +1. > > Does the ARC infrastructure deal with lower case ARC names properly > ("psarc" vs. "PSARC")? It doesn't matter. The infrastructure just looks at the number; you can omit the name if you like (and I usually do). The numbers are unique across the ARC. Of more consequence here are: - The fast-track timer is not running on this case, so this isn't a fast-track and won't be handled during normal ARC business. It's in "waiting need spec" state. - This is nominally an "open" exposure case, but all of the discussion is taking place on the closed "psarc@sun.com" list. I'm not sure why that's happening. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From tim.marsland@sun.com Wed Apr 1 10:53:13 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31HrDOD023078 for ; Wed, 1 Apr 2009 10:53:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n31Hr6VG017705; Wed, 1 Apr 2009 10:53:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF0000HOCL4J00@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Apr 2009 10:53:09 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF00LYSOCLSK10@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Apr 2009 10:53:09 -0700 (PDT) Received: from [129.150.12.89] (vpn-129-150-12-89.SFBay.Sun.COM [129.150.12.89]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n31Hr8QM271545; Wed, 01 Apr 2009 10:53:09 -0700 (PDT) Date: Wed, 01 Apr 2009 10:55:06 -0700 From: Tim Marsland Subject: psarc/2009/197 - UFTDI - fast-track To: psarc-ext@sun.com Cc: Strony Zhang , tim.marsland@sun.com, Lin Guo , Artem Kachitchkine Message-id: <49D3AA7A.5090204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 3989 [Resubmitting with correct 'To:' line and new timeout date - apologies for duplication. The case already has a '+1' from Garrett and Artem - they don't need to resend it!] I'm sponsoring this fast-track for me. If approved, the case would time out April 8th 2009. The release binding sought for these changes is "Patch". The materials directory contains the manpage for the device. This project is essentially about adding yet another USB serial port driver. In that sense it is uninteresting to the ARC, because we have already established the architecture for USB serial port devices in the numerous USB cases that have come before the ARC over the past eight years. However, there are two additional issues that this device driver raises - hence this case. #1 Support for 921600 baud There are a number of peripheral devices that choose to use USB serial port devices internally for the sake of providing a simple programming model to their users. These peripherals may only use a few millimeters of actual RS232 electrical signals, and thus some surprisingly high baud rates can be supported. The desire to support 921600 baud comes from a customer application with a random number generator device that plugs into a USB port, though it presents a serial port interface using this driver to extract the random numbers. The highest baud rate currently supported by Solaris is 460800 baud; this case proposes to double that to the new maximum of 921600. Note that this is really a matter of adding a #define for B921600 to then also adding support to all the pieces of the system that "know" about the translation from the baud rate number to the encoded baud rate passed into the termios structure. Since this is also a baud rate supported by other open source OSes, and most applications that support higher baud rates conditionalize support for this baud rate under '#ifdef B921600'; recompilation against the updated termios.h header makes all the open source software i've looked at "just work" with this new (for solaris) baud rate. #2 Soft carrier properties (ignore-cd) The current default for "off-board" serial ports is to carefully honor the carrier detect line i.e. before /dev/term/N can be opened, the device must assert DCD. A complex interaction between /dev/term/N (a dial-in connection, e.g. enabled for login) and /dev/cua/N (a dial-out connection, for use with tip etc.) is supported in all Solaris serial devices which uses the DCD behaviour to implement this "shared" access method. However, for as long as I can recall, SPARC firmware and the simulation of it on x64 systems sets up *onboard* serial ports to ignore the carrier detect line, enabling "3-wire" connections - just gnd/rx/tx for a serial port. This is normally controlled by the 'ignore-cd?' property in SPARC firmware, or 'tty*-ignore-cd' in bootenv.rc on x86 -- both these properties are set to 'true', causing cause the state of the DCD line to be ignored by SW. This case asserts that, moving forward, the default behaviour for "off-board" serial ports should be the same as "on-board" serial ports -- the distinction being particularly ambiguous in the case of USB simulations of RS232 devices. To implement this for the UFTDI driver (usbftdi), the driver ships with a usbftdi.conf file that simply contains the property ignore-cd = 1; with an additional note that explains that finer-grain control for this behaviour (on a device instance basis) can be achieved using port-N-ignore-cd = 1; (e.g. port-4-ignore-cd for serial port 4) These properties are decoded by the non-device specific part of the USB serial port infrastructure and have been present continuously, but have not been documented/exposed - this case would assign these properties an interface committment level of 'Stable'. This case proposes to make the same behaviour true for this new USB device, and to document the means of enabling this default for other USB serial devices too. From carlsonj@phorcys.east.sun.com Wed Apr 1 11:16:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31IGmHZ025559 for ; Wed, 1 Apr 2009 11:16:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n31IGfH8029473; Wed, 1 Apr 2009 19:16:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF00103PFRDG00@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Apr 2009 11:16:39 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF00LTEPFQS930@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Apr 2009 11:16:39 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n31IGK9T018790; Wed, 01 Apr 2009 14:16:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n31IGK59018787; Wed, 01 Apr 2009 14:16:20 -0400 (EDT) Date: Wed, 01 Apr 2009 14:16:20 -0400 From: James Carlson Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <49D3AA7A.5090204@sun.com> To: Tim Marsland Cc: psarc-ext@sun.com, Strony Zhang , Lin Guo , Artem Kachitchkine Message-id: <18899.44916.323819.283549@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D3AA7A.5090204@sun.com> Status: RO Content-Length: 1824 Tim Marsland writes: > This case asserts that, moving forward, the default behaviour > for "off-board" serial ports should be the same as "on-board" > serial ports -- the distinction being particularly ambiguous > in the case of USB simulations of RS232 devices. I can understand why this is the default for possibly broken hardware (devices ordinarily lacking standard modem control lines), and when we discussed the issue, I had thought that was the context for the change. However, I don't think it makes sense as a general rule for all off-board serial ports. The only reason it's the default for on-board ports is because of the common (and legacy) usage of /dev/term/a as a console port with a three-wire connection to an ASCII terminal. In fact, given the legacy nature, I'd be much more in favor of saying that going forward all ports -- both on-board and off-board -- should *NOT* have the "ignore-cd" property set by default. I'd settle for saying that ignore-cd=1 is the default for UFTDI, because of an unusual risk of broken hardware in this particular usage case (as I thought we'd discussed), but I don't think it's right as a general rule. It provides for strange operation at best, and security problems (such as disconnected lines being left logged in) at worst. (The better answer is for the driver to supply the default: if the hardware is known to be deficient or otherwise "special," then using ignore-cd=1 as the default is fine. If it's known to be a properly functioning serial port with a reasonble complement of modem control lines, then it should be ignore-cd=0.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From tim.marsland@sun.com Wed Apr 1 11:24:01 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31IO0wM026520 for ; Wed, 1 Apr 2009 11:24:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n31INghe029359; Thu, 2 Apr 2009 02:23:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF0011DPRTSE00@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Apr 2009 11:23:53 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF00L6OPRTSM40@nwk-avmta-2.sfbay.sun.com>; Wed, 01 Apr 2009 11:23:53 -0700 (PDT) Received: from [129.150.12.89] (vpn-129-150-12-89.SFBay.Sun.COM [129.150.12.89]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n31INrQU279129; Wed, 01 Apr 2009 11:23:53 -0700 (PDT) Date: Wed, 01 Apr 2009 11:25:51 -0700 From: Tim Marsland Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <18899.44916.323819.283549@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@sun.com, Strony Zhang , Lin Guo , Artem Kachitchkine Message-id: <49D3B1AF.4070604@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D3AA7A.5090204@sun.com> <18899.44916.323819.283549@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 2039 James Carlson wrote: > Tim Marsland writes: >> This case asserts that, moving forward, the default behaviour >> for "off-board" serial ports should be the same as "on-board" >> serial ports -- the distinction being particularly ambiguous >> in the case of USB simulations of RS232 devices. > > I can understand why this is the default for possibly broken hardware > (devices ordinarily lacking standard modem control lines), and when we > discussed the issue, I had thought that was the context for the > change. > > However, I don't think it makes sense as a general rule for all > off-board serial ports. The only reason it's the default for on-board > ports is because of the common (and legacy) usage of /dev/term/a as a > console port with a three-wire connection to an ASCII terminal. In > fact, given the legacy nature, I'd be much more in favor of saying > that going forward all ports -- both on-board and off-board -- should > *NOT* have the "ignore-cd" property set by default. > > I'd settle for saying that ignore-cd=1 is the default for UFTDI, > because of an unusual risk of broken hardware in this particular usage > case (as I thought we'd discussed), but I don't think it's right as a > general rule. It provides for strange operation at best, and security > problems (such as disconnected lines being left logged in) at worst. > > (The better answer is for the driver to supply the default: if the > hardware is known to be deficient or otherwise "special," then using > ignore-cd=1 as the default is fine. If it's known to be a properly > functioning serial port with a reasonble complement of modem control > lines, then it should be ignore-cd=0.) I was really trying to capture the class of USB serial devices that are mostly *not* used in the role of modems. Which increasingly seems to be all of them, as modems become an increasingly arcane concept except for debugging and low-level hardware hacking. However, if you want to restrict that statement to the usbftdi driver, I'm fine with that too. tim From Andrew.Gabriel@sun.com Wed Apr 1 11:30:07 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31IU7dx026978 for ; Wed, 1 Apr 2009 11:30:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n31IU5MA006398 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 1 Apr 2009 11:30:07 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF00111Q254C00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 01 Apr 2009 11:30:05 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF00MGHQ23EK30@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 01 Apr 2009 11:30:04 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n31IU3b5021818 for ; Wed, 01 Apr 2009 18:30:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHF00000PUIUZ00@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 01 Apr 2009 19:30:03 +0100 (BST) Received: from [81.187.162.109] ([unknown] [81.187.162.109]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHF00L58Q22G2B0@fe-emea-09.sun.com>; Wed, 01 Apr 2009 19:30:03 +0100 (BST) Date: Wed, 01 Apr 2009 19:31:08 +0100 From: Andrew Gabriel Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <49D3AA7A.5090204@sun.com> Sender: Andrew.Gabriel@sun.com To: Tim Marsland Cc: psarc-ext@sun.com, Strony Zhang , Lin Guo , Artem Kachitchkine Message-id: <49D3B2EC.5030304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D3AA7A.5090204@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090209) Status: RO Content-Length: 4215 Tim Marsland wrote: > [Resubmitting with correct 'To:' line and new timeout date > - apologies for duplication. The case already has a '+1' > from Garrett and Artem - they don't need to resend it!] > > I'm sponsoring this fast-track for me. > If approved, the case would time out April 8th 2009. > The release binding sought for these changes is "Patch". > The materials directory contains the manpage for the device. > > This project is essentially about adding yet another USB serial > port driver. In that sense it is uninteresting to the ARC, > because we have already established the architecture for USB > serial port devices in the numerous USB cases that have come > before the ARC over the past eight years. > > However, there are two additional issues that this device > driver raises - hence this case. > > #1 Support for 921600 baud > > There are a number of peripheral devices that choose to use USB > serial port devices internally for the sake of providing a simple > programming model to their users. These peripherals may only use > a few millimeters of actual RS232 electrical signals, and thus > some surprisingly high baud rates can be supported. Even standard serial ports with several feet of cable work fine at 921600 baud nowadays. I have been using a modified asy(7D) for some years, and part of my testing of it includes operating at 921600 baud and checking for no data loss. (You do have to ensure asy(7D) is running at IPL 12 for this to work, and that doesn't work if it ends up sharing a PCI IRQ with a device who's IPL is below LOCK_LEVEL (10), as most other devices are.) > The desire to support 921600 baud comes from a customer > application with a random number generator device that plugs into a > USB port, though it presents a serial port interface using this driver > to extract the random numbers. > > The highest baud rate currently supported by Solaris is 460800 baud; > this case proposes to double that to the new maximum of 921600. Note > that this is really a matter of adding a #define for B921600 to > then also adding support to all the pieces of the > system that "know" about the translation from the baud rate > number to the encoded baud rate passed into the termios structure. > > Since this is also a baud rate supported by other open source OSes, > and most applications that support higher baud rates > conditionalize support for this baud rate under > '#ifdef B921600'; recompilation against the updated termios.h > header makes all the open source software i've looked at > "just work" with this new (for solaris) baud rate. > > #2 Soft carrier properties (ignore-cd) > > The current default for "off-board" serial ports is to carefully > honor the carrier detect line i.e. before /dev/term/N can be opened, > the device must assert DCD. A complex interaction between /dev/term/N > (a dial-in connection, e.g. enabled for login) and /dev/cua/N (a > dial-out connection, for use with tip etc.) is supported in all > Solaris serial devices which uses the DCD behaviour to implement > this "shared" access method. > > However, for as long as I can recall, SPARC firmware and the > simulation of it on x64 systems sets up *onboard* serial > ports to ignore the carrier detect line, enabling "3-wire" > connections - just gnd/rx/tx for a serial port. This is normally > controlled by the 'ignore-cd?' property in SPARC firmware, > or 'tty*-ignore-cd' in bootenv.rc on x86 -- both these properties > are set to 'true', causing cause the state of the DCD line > to be ignored by SW. I believe this is because these ports can be console ports, and having the console not work because DCD isn't connected somewhere in the cable is a right royal pain in the behind. We don't currently have any way in Solaris to make a non-motherboard port a console port. > This case asserts that, moving forward, the default behaviour > for "off-board" serial ports should be the same as "on-board" > serial ports -- the distinction being particularly ambiguous > in the case of USB simulations of RS232 devices. Why not simply use the /dev/cua/N ports when you want this behaviour, as they behave this way anyway? -- Andrew From carlsonj@phorcys.east.sun.com Wed Apr 1 11:37:55 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31IbsIP027787 for ; Wed, 1 Apr 2009 11:37:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n31IboUa010540; Wed, 1 Apr 2009 11:37:52 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF00D0JQF34O00@brm-avmta-1.central.sun.com>; Wed, 01 Apr 2009 12:37:51 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF008HDQF20E60@brm-avmta-1.central.sun.com>; Wed, 01 Apr 2009 12:37:51 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n31IbW3O018980; Wed, 01 Apr 2009 14:37:32 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n31IbWBV018977; Wed, 01 Apr 2009 14:37:32 -0400 (EDT) Date: Wed, 01 Apr 2009 14:37:32 -0400 From: James Carlson Subject: Re: psarc/2009/197 - UFTDI - fast-track In-reply-to: <49D3B1AF.4070604@sun.com> To: Tim Marsland Cc: psarc-ext@sun.com, Strony Zhang , Lin Guo , Artem Kachitchkine Message-id: <18899.46188.725599.403736@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D3AA7A.5090204@sun.com> <18899.44916.323819.283549@gargle.gargle.HOWL> <49D3B1AF.4070604@sun.com> Status: RO Content-Length: 1549 Tim Marsland writes: > James Carlson wrote: > > (The better answer is for the driver to supply the default: if the > > hardware is known to be deficient or otherwise "special," then using > > ignore-cd=1 as the default is fine. If it's known to be a properly > > functioning serial port with a reasonble complement of modem control > > lines, then it should be ignore-cd=0.) > > I was really trying to capture the class of USB serial devices that > are mostly *not* used in the role of modems. Which increasingly > seems to be all of them, as modems become an increasingly arcane > concept except for debugging and low-level hardware hacking. In contrast, *all* of the USB serial devices (three different brands so far) I've been able to use on Solaris are USB-to-DB9 affairs with full modem controls. Go figure. ;-} > However, if you want to restrict that statement to the > usbftdi driver, I'm fine with that too. OK. If it turns out that nobody ever manufactures a DCD wire again, then we can certainly yank support later. (For what it's worth, just because they're called "modem controls," they're not just for modems. For instance, on a V.120 TA, it's not uncommon for DCD to be wired into the protocol negotiation, so that you get carrier when the circuit is live, even though there's no "modem" involved.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677