Merge branch 'mpi-master' into wip-k-fmlpwip-k-fmlp

Conflicts:
	litmus/sched_cedf.c

5 files changed, 213 insertions, 2 deletions

diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
index 07dcdb0d2a36..e09468ad3cb1 100644
--- a/Documentation/serial/00-INDEX
+++ b/Documentation/serial/00-INDEX
@@ -14,6 +14,8 @@ riscom8.txt
         - notes on using the RISCom/8 multi-port serial driver.
 rocket.txt
         - info on the Comtrol RocketPort multiport serial driver.
+serial-rs485.txt
+        - info about RS485 structures and support in the kernel.
 specialix.txt
         - info on hardware/driver for specialix IO8+ multiport serial card.
 stallion.txt
diff --git a/Documentation/serial/moxa-smartio b/Documentation/serial/moxa-smartio
index d10443918684..5d2a33be0bd8 100644
--- a/Documentation/serial/moxa-smartio
+++ b/Documentation/serial/moxa-smartio
@@ -473,7 +473,7 @@ Content
    spd_normal     Use  38.4kb  when  the application requests 38.4kb.
    spd_cust       Use  the custom divisor to set the speed when  the
                   application requests 38.4kb.
-   divisor        This option set the custom divison.
+   divisor        This option set the custom division.
    baud_base      This option set the base baud rate.
 
 -----------------------------------------------------------------------------
diff --git a/Documentation/serial/n_gsm.txt b/Documentation/serial/n_gsm.txt
new file mode 100644
index 000000000000..a5d91126a8f7
--- /dev/null
+++ b/Documentation/serial/n_gsm.txt
@@ -0,0 +1,89 @@
+n_gsm.c GSM 0710 tty multiplexor HOWTO
+===================================================
+
+This line discipline implements the GSM 07.10 multiplexing protocol
+detailed in the following 3GPP document :
+http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip
+
+This document give some hints on how to use this driver with GPRS and 3G
+modems connected to a physical serial port.
+
+How to use it
+-------------
+1- initialize the modem in 0710 mux mode (usually AT+CMUX= command) through
+its serial port. Depending on the modem used, you can pass more or less
+parameters to this command,
+2- switch the serial line to using the n_gsm line discipline by using
+TIOCSETD ioctl,
+3- configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl,
+
+Major parts of the initialization program :
+(a good starting point is util-linux-ng/sys-utils/ldattach.c)
+#include <linux/gsmmux.h>
+#define N_GSM0710       21      /* GSM 0710 Mux */
+#define DEFAULT_SPEED   B115200
+#define SERIAL_PORT     /dev/ttyS0
+
+        int ldisc = N_GSM0710;
+        struct gsm_config c;
+        struct termios configuration;
+
+        /* open the serial port connected to the modem */
+        fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY);
+
+        /* configure the serial port : speed, flow control ... */
+
+        /* send the AT commands to switch the modem to CMUX mode
+           and check that it's successful (should return OK) */
+        write(fd, "AT+CMUX=0\r", 10);
+
+        /* experience showed that some modems need some time before
+           being able to answer to the first MUX packet so a delay
+           may be needed here in some case */
+        sleep(3);
+
+        /* use n_gsm line discipline */
+        ioctl(fd, TIOCSETD, &ldisc);
+
+        /* get n_gsm configuration */
+        ioctl(fd, GSMIOC_GETCONF, &c);
+        /* we are initiator and need encoding 0 (basic) */
+        c.initiator = 1;
+        c.encapsulation = 0;
+        /* our modem defaults to a maximum size of 127 bytes */
+        c.mru = 127;
+        c.mtu = 127;
+        /* set the new configuration */
+        ioctl(fd, GSMIOC_SETCONF, &c);
+
+        /* and wait for ever to keep the line discipline enabled */
+        daemon(0,0);
+        pause();
+
+4- create the devices corresponding to the "virtual" serial ports (take care,
+each modem has its configuration and some DLC have dedicated functions,
+for example GPS), starting with minor 1 (DLC0 is reserved for the management
+of the mux)
+
+MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}`
+for i in `seq 1 4`; do
+        mknod /dev/ttygsm$i c $MAJOR $i
+done
+
+5- use these devices as plain serial ports.
+for example, it's possible :
+- and to use gnokii to send / receive SMS on ttygsm1
+- to use ppp to establish a datalink on ttygsm2
+
+6- first close all virtual ports before closing the physical port.
+
+Additional Documentation
+------------------------
+More practical details on the protocol and how it's supported by industrial
+modems can be found in the following documents :
+http://www.telit.com/module/infopool/download.php?id=616
+http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf
+http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx
+http://wm.sim.com/sim/News/photo/2010721161442.pdf
+
+11-03-08 - Eric Bénard - <eric@eukrea.com>
diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
new file mode 100644
index 000000000000..a4932387bbfb
--- /dev/null
+++ b/Documentation/serial/serial-rs485.txt
@@ -0,0 +1,120 @@
+                        RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+   EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+   electrical characteristics of drivers and receivers for use in balanced
+   digital multipoint systems.
+   This standard is widely used for communications in industrial automation
+   because it can be used effectively over long distances and in electrically
+   noisy environments.
+
+2. HARDWARE-RELATED CONSIDERATIONS
+
+   Some CPUs/UARTs (e.g., Atmel AT91 or 16C950 UART) contain a built-in
+   half-duplex mode capable of automatically controlling line direction by
+   toggling RTS or DTR signals. That can be used to control external
+   half-duplex hardware like an RS485 transceiver or any RS232-connected
+   half-duplex devices like some modems.
+
+   For these microcontrollers, the Linux driver should be made capable of
+   working in both modes, and proper ioctls (see later) should be made
+   available at user-level to allow switching from one mode to the other, and
+   vice versa.
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+   The Linux kernel provides the serial_rs485 structure (see [1]) to handle
+   RS485 communications. This data structure is used to set and configure RS485
+   parameters in the platform data and in ioctls.
+
+   Any driver for devices capable of working both as RS232 and RS485 should
+   provide at least the following ioctls:
+
+    - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
+      to enable/disable RS485 mode from user-space
+
+    - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
+      to get RS485 mode from kernel-space (i.e., driver) to user-space.
+
+   In other words, the serial driver should contain a code similar to the next
+   one:
+
+        static struct uart_ops atmel_pops = {
+                /* ... */
+                .ioctl          = handle_ioctl,
+        };
+
+        static int handle_ioctl(struct uart_port *port,
+                unsigned int cmd,
+                unsigned long arg)
+        {
+                struct serial_rs485 rs485conf;
+
+                switch (cmd) {
+                case TIOCSRS485:
+                        if (copy_from_user(&rs485conf,
+                                (struct serial_rs485 *) arg,
+                                sizeof(rs485conf)))
+                                        return -EFAULT;
+
+                        /* ... */
+                        break;
+
+                case TIOCGRS485:
+                        if (copy_to_user((struct serial_rs485 *) arg,
+                                ...,
+                                sizeof(rs485conf)))
+                                        return -EFAULT;
+                        /* ... */
+                        break;
+
+                /* ... */
+                }
+        }
+
+
+4. USAGE FROM USER-LEVEL
+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+        #include <linux/serial.h>
+
+        /* Driver-specific ioctls: */
+        #define TIOCGRS485      0x542E
+        #define TIOCSRS485      0x542F
+
+        /* Open your specific device (e.g., /dev/mydevice): */
+        int fd = open ("/dev/mydevice", O_RDWR);
+        if (fd < 0) {
+                /* Error handling. See errno. */
+        }
+
+        struct serial_rs485 rs485conf;
+
+        /* Set RS485 mode: */
+        rs485conf.flags |= SER_RS485_ENABLED;
+
+        /* Set rts delay before send, if needed: */
+        rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+        rs485conf.delay_rts_before_send = ...;
+
+        /* Set rts delay after send, if needed: */
+        rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+        rs485conf.delay_rts_after_send = ...;
+
+        if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) {
+                /* Error handling. See errno. */
+        }
+
+        /* Use read() and write() syscalls here... */
+
+        /* Close the device when finished: */
+        if (close (fd) < 0) {
+                /* Error handling. See errno. */
+        }
+
+5. REFERENCES
+
+ [1]    include/linux/serial.h
diff --git a/Documentation/serial/tty.txt b/Documentation/serial/tty.txt
index 7c900507279f..540db41dfd5d 100644
--- a/Documentation/serial/tty.txt
+++ b/Documentation/serial/tty.txt
@@ -107,7 +107,7 @@ write_wakeup()	-	May be called at any point between open and close.
 
 dcd_change()    -       Report to the tty line the current DCD pin status
                         changes and the relative timestamp. The timestamp
-                        can be NULL.
+                        cannot be NULL.
 
 
 Driver Access