Linux-2.6.12-rc2v2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

1 files changed, 201 insertions, 0 deletions

diff --git a/drivers/usb/serial/keyspan_usa28msg.h b/drivers/usb/serial/keyspan_usa28msg.h
new file mode 100644
index 000000000000..dee454c4609a
--- /dev/null
+++ b/drivers/usb/serial/keyspan_usa28msg.h
@@ -0,0 +1,201 @@
+/*
+        usa28msg.h
+
+        Copyright (C) 1998-2000 InnoSys Incorporated.  All Rights Reserved
+        This file is available under a BSD-style copyright
+
+        Keyspan USB Async Message Formats for the USA26X
+
+        Redistribution and use in source and binary forms, with or without
+        modification, are permitted provided that the following conditions are
+        met:
+
+        1. Redistributions of source code must retain this licence text
+        without modification, this list of conditions, and the following
+        disclaimer.  The following copyright notice must appear immediately at
+        the beginning of all source files:
+
+                Copyright (C) 1998-2000 InnoSys Incorporated.  All Rights Reserved
+
+                This file is available under a BSD-style copyright
+
+        2. The name of InnoSys Incorporated may not be used to endorse or promote
+        products derived from this software without specific prior written
+        permission.
+
+        THIS SOFTWARE IS PROVIDED BY INNOSYS CORP. ``AS IS'' AND ANY EXPRESS OR
+        IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+        OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+        NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+        INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+        (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+        SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+        CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+        LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+        OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+        SUCH DAMAGE.    
+
+        Note: these message formats are common to USA18, USA19, and USA28;
+        (for USA28X, see usa26msg.h)
+
+        Buffer formats for RX/TX data messages are not defined by
+        a structure, but are described here:
+
+        USB OUT (host -> USA28, transmit) messages contain a 
+        REQUEST_ACK indicator (set to 0xff to request an ACK at the 
+        completion of transmit; 0x00 otherwise), followed by data.
+        If the port is configured for parity, the data will be an 
+        alternating string of parity and data bytes, so the message
+        format will be:
+
+                RQSTACK PAR DAT PAR DAT ...
+
+        so the maximum length is 63 bytes (1 + 62, or 31 data bytes);
+        always an odd number for the total message length.
+
+        If there is no parity, the format is simply:
+
+                RQSTACK DAT DAT DAT ...
+
+        with a total data length of 63.
+
+        USB IN (USA28 -> host, receive) messages contain data and parity
+        if parity is configred, thusly:
+        
+                DAT PAR DAT PAR DAT PAR ...
+
+        for a total of 32 data bytes;
+        
+        If parity is not configured, the format is:
+
+                DAT DAT DAT ...
+
+        for a total of 64 data bytes.
+
+        In the TX messages (USB OUT), the 0x01 bit of the PARity byte is 
+        the parity bit.  In the RX messages (USB IN), the PARity byte is 
+        the content of the 8051's status register; the parity bit 
+        (RX_PARITY_BIT) is the 0x04 bit.
+
+        revision history:
+
+        1999may06       add resetDataToggle to control message
+        2000mar21       add rs232invalid to status response message
+        2000apr04       add 230.4Kb definition to setBaudRate
+        2000apr13       add/remove loopbackMode switch
+        2000apr13       change definition of setBaudRate to cover 115.2Kb, too
+        2000jun01       add extended BSD-style copyright text
+*/
+
+#ifndef __USA28MSG__
+#define __USA28MSG__
+
+
+struct keyspan_usa28_portControlMessage
+{
+        /*
+                there are four types of "commands" sent in the control message:
+
+                1.      configuration changes which must be requested by setting
+                        the corresponding "set" flag (and should only be requested
+                        when necessary, to reduce overhead on the USA28):
+        */
+        u8      setBaudRate,    // 0=don't set, 1=baudLo/Hi, 2=115.2K, 3=230.4K
+                baudLo,                 // host does baud divisor calculation
+                baudHi;                 // baudHi is only used for first port (gives lower rates)
+
+        /*
+                2.      configuration changes which are done every time (because it's
+                        hardly more trouble to do them than to check whether to do them):
+        */
+        u8      parity,                 // 1=use parity, 0=don't
+                ctsFlowControl,         // all except 19Q: 1=use CTS flow control, 0=don't
+                                        // 19Q: 0x08:CTSflowControl 0x10:DSRflowControl
+                xonFlowControl, // 1=use XON/XOFF flow control, 0=don't
+                rts,                    // 1=on, 0=off
+                dtr;                    // 1=on, 0=off
+
+        /*
+                3.      configuration data which is simply used as is (no overhead,
+                        but must be correct in every host message).
+        */
+        u8      forwardingLength,  // forward when this number of chars available
+                forwardMs,              // forward this many ms after last rx data
+                breakThreshold, // specified in ms, 1-255 (see note below)
+                xonChar,                // specified in current character format
+                xoffChar;               // specified in current character format
+
+        /*
+                4.      commands which are flags only; these are processed in order
+                        (so that, e.g., if both _txOn and _txOff flags are set, the
+                        port ends in a TX_OFF state); any non-zero value is respected
+        */
+        u8      _txOn,                  // enable transmitting (and continue if there's data)
+                _txOff,                 // stop transmitting
+                txFlush,                // toss outbound data
+                txForceXoff,    // pretend we've received XOFF
+                txBreak,                // turn on break (leave on until txOn clears it)
+                rxOn,                   // turn on receiver
+                rxOff,                  // turn off receiver
+                rxFlush,                // toss inbound data
+                rxForward,              // forward all inbound data, NOW
+                returnStatus,   // return current status n times (1 or 2)
+                resetDataToggle;// reset data toggle state to DATA0
+        
+};
+
+struct keyspan_usa28_portStatusMessage
+{
+        u8      port,                   // 0=first, 1=second, 2=global (see below)
+                cts,
+                dsr,                    // (not used in all products)
+                dcd,
+
+                ri,                             // (not used in all products)
+                _txOff,                 // port has been disabled (by host)
+                _txXoff,                // port is in XOFF state (either host or RX XOFF)
+                dataLost,               // count of lost chars; wraps; not guaranteed exact
+
+                rxEnabled,              // as configured by rxOn/rxOff 1=on, 0=off
+                rxBreak,                // 1=we're in break state
+                rs232invalid,   // 1=no valid signals on rs-232 inputs
+                controlResponse;// 1=a control messages has been processed
+};
+
+// bit defines in txState
+#define TX_OFF                  0x01    // requested by host txOff command
+#define TX_XOFF                 0x02    // either real, or simulated by host
+
+struct keyspan_usa28_globalControlMessage
+{
+        u8      sendGlobalStatus,       // 2=request for two status responses
+                resetStatusToggle,      // 1=reset global status toggle
+                resetStatusCount;       // a cycling value
+};
+
+struct keyspan_usa28_globalStatusMessage
+{
+        u8      port,                           // 3
+                sendGlobalStatus,       // from request, decremented
+                resetStatusCount;       // as in request
+};
+
+struct keyspan_usa28_globalDebugMessage
+{
+        u8      port,                           // 2
+                n,                                      // typically a count/status byte
+                b;                                      // typically a data byte
+};
+
+// ie: the maximum length of an EZUSB endpoint buffer
+#define MAX_DATA_LEN                    64
+
+// the parity bytes have only one significant bit
+#define RX_PARITY_BIT                   0x04
+#define TX_PARITY_BIT                   0x01
+
+// update status approx. 60 times a second (16.6666 ms)
+#define STATUS_UPDATE_INTERVAL  16
+
+#endif
+