Merge tag 'v3.9-rc3' into next/multiplatform

                                  4 = active high level-sensitive

                                  8 = active low level-sensitive

Optional parent device properties:

- reg                    : contains the PRCMU mailbox address for the AB8500 i2c port

The AB8500 consists of a large and varied group of sub-devices:

Device                     IRQ Names              Supply Names   Description

   - stericsson,amic2-bias-vamic1           : Analoge Mic wishes to use a non-standard Vamic

   - stericsson,earpeice-cmv                : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)

ab8500@5 {

ab8500 {

         compatible = "stericsson,ab8500";

         reg = <5>; /* mailbox 5 is i2c */

         interrupts = <0 40 0x4>;

         interrupt-controller;

         #interrupt-cells = <2>;

	- "nvidia,tegra20-uart"

	- "nxp,lpc3220-uart"

	- "ibm,qpace-nwp-serial"

	- "altr,16550-FIFO32"

	- "altr,16550-FIFO64"

	- "altr,16550-FIFO128"

	- "serial" if the port type is unknown.

- reg : offset and length of the register set for the device.

- interrupts : should contain uart interrupt.

Introduction

------------

Currently the ALPS touchpad driver supports four protocol versions in use by

ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various

protocol versions is contained in the following sections.

Currently the ALPS touchpad driver supports five protocol versions in use by

ALPS touchpads, called versions 1, 2, 3, 4 and 5.

Since roughly mid-2010 several new ALPS touchpads have been released and

integrated into a variety of laptops and netbooks.  These new touchpads

have enough behavior differences that the alps_model_data definition

table, describing the properties of the different versions, is no longer

adequate.  The design choices were to re-define the alps_model_data

table, with the risk of regression testing existing devices, or isolate

the new devices outside of the alps_model_data table.  The latter design

choice was made.  The new touchpad signatures are named: "Rushmore",

"Pinnacle", and "Dolphin", which you will see in the alps.c code.

For the purposes of this document, this group of ALPS touchpads will

generically be called "new ALPS touchpads".

We experimented with probing the ACPI interface _HID (Hardware ID)/_CID

(Compatibility ID) definition as a way to uniquely identify the

different ALPS variants but there did not appear to be a 1:1 mapping.

In fact, it appeared to be an m:n mapping between the _HID and actual

hardware type.

Detection

---------

report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is

matched against known models in the alps_model_data_array.

With protocol versions 3 and 4, the E7 report model signature is always

73-02-64. To differentiate between these versions, the response from the

"Enter Command Mode" sequence must be inspected as described below.

For older touchpads supporting protocol versions 3 and 4, the E7 report

model signature is always 73-02-64. To differentiate between these

versions, the response from the "Enter Command Mode" sequence must be

inspected as described below.

The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but

seem to be better differentiated by the EC Command Mode response.

Command Mode

------------

register. Registers are written by writing the value one nibble at a time

using the same encoding used for addresses.

For the new ALPS touchpads, the EC command is used to enter command

mode. The response in the new ALPS touchpads is significantly different,

and more important in determining the behavior.  This code has been

separated from the original alps_model_data table and put in the

alps_identify function.  For example, there seem to be two hardware init

sequences for the "Dolphin" touchpads as determined by the second byte

of the EC response.

Packet Format

-------------

    well.

So far no v4 devices with tracksticks have been encountered.

ALPS Absolute Mode - Protocol Version 5

---------------------------------------

This is basically Protocol Version 3 but with different logic for packet

decode.  It uses the same alps_process_touchpad_packet_v3 call with a

specialized decode_fields function pointer to correctly interpret the

packets.  This appears to only be used by the Dolphin devices.

For single-touch, the 6-byte packet format is:

 byte 0:    1    1    0    0    1    0    0    0

 byte 1:    0   x6   x5   x4   x3   x2   x1   x0

 byte 2:    0   y6   y5   y4   y3   y2   y1   y0

 byte 3:    0    M    R    L    1    m    r    l

 byte 4:   y10  y9   y8   y7  x10   x9   x8   x7

 byte 5:    0   z6   z5   z4   z3   z2   z1   z0

For mt, the format is:

 byte 0:    1    1    1    n3   1   n2   n1   x24

 byte 1:    1   y7   y6    y5  y4   y3   y2    y1

 byte 2:    ?   x2   x1   y12 y11  y10   y9    y8

 byte 3:    0  x23  x22   x21 x20  x19  x18   x17

 byte 4:    0   x9   x8    x7  x6   x5   x4    x3

 byte 5:    0  x16  x15   x14 x13  x12  x11   x10

     Proto [2 bytes]

     Raw protocol(IP, IPv6, etc) frame.

  3.3 Multiqueue tuntap interface:

  From version 3.8, Linux supports multiqueue tuntap which can uses multiple

  file descriptors (queues) to parallelize packets sending or receiving. The

  device allocation is the same as before, and if user wants to create multiple

  queues, TUNSETIFF with the same device name must be called many times with

  IFF_MULTI_QUEUE flag.

  char *dev should be the name of the device, queues is the number of queues to

  be created, fds is used to store and return the file descriptors (queues)

  created to the caller. Each file descriptor were served as the interface of a

  queue which could be accessed by userspace.

  #include <linux/if.h>

  #include <linux/if_tun.h>

  int tun_alloc_mq(char *dev, int queues, int *fds)

  {

      struct ifreq ifr;

      int fd, err, i;

      if (!dev)

          return -1;

      memset(&ifr, 0, sizeof(ifr));

      /* Flags: IFF_TUN   - TUN device (no Ethernet headers)

       *        IFF_TAP   - TAP device

       *

       *        IFF_NO_PI - Do not provide packet information

       *        IFF_MULTI_QUEUE - Create a queue of multiqueue device

       */

      ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE;

      strcpy(ifr.ifr_name, dev);

      for (i = 0; i < queues; i++) {

          if ((fd = open("/dev/net/tun", O_RDWR)) < 0)

             goto err;

          err = ioctl(fd, TUNSETIFF, (void *)&ifr);

          if (err) {

             close(fd);

             goto err;

          }

          fds[i] = fd;

      }

      return 0;

  err:

      for (--i; i >= 0; i--)

          close(fds[i]);

      return err;

  }

  A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When

  calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when

  calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were

  enabled by default after it was created through TUNSETIFF.

  fd is the file descriptor (queue) that we want to enable or disable, when

  enable is true we enable it, otherwise we disable it

  #include <linux/if.h>

  #include <linux/if_tun.h>

  int tun_set_queue(int fd, int enable)

  {

      struct ifreq ifr;

      memset(&ifr, 0, sizeof(ifr));

      if (enable)

         ifr.ifr_flags = IFF_ATTACH_QUEUE;

      else

         ifr.ifr_flags = IFF_DETACH_QUEUE;

      return ioctl(fd, TUNSETQUEUE, (void *)&ifr);

  }

Universal TUN/TAP device driver Frequently Asked Question.

1. What platforms are supported by TUN/TAP driver ?

	status\input  |     0      |     1      |    else    |

	--------------+------------+------------+------------+

	not allocated |(do nothing)| alloc+swap |   EINVAL   |

	not allocated |(do nothing)| alloc+swap |(do nothing)|

	--------------+------------+------------+------------+

	allocated     |    free    |    swap    |   clear    |

	--------------+------------+------------+------------+