---

yaml
---
r: 374179
b: refs/heads/master
c: 980ce7d
h: refs/heads/master
i:
  374177: 72cc0c7
  374175: 3db3c0b
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: aabdd2901ad0bfaeaf108eb29183cbb270dba3bf
+refs/heads/master: 980ce7d94e0738aaee3c1ea3e2d5670bddeffc04

trunk/CREDITS

@@ -1510,14 +1510,6 @@ D: Natsemi ethernet
 D: Cobalt Networks (x86) support
 D: This-and-That
 
-N: Mark M. Hoffman
-E: mhoffman@lightlink.com
-D: asb100, lm93 and smsc47b397 hardware monitoring drivers
-D: hwmon subsystem core
-D: hwmon subsystem maintainer
-D: i2c-sis96x and i2c-stub SMBus drivers
-S: USA
-
 N: Dirk Hohndel
 E: hohndel@suse.de
 D: The XFree86[tm] Project

trunk/Documentation/devicetree/bindings/arm/primecell.txt

@@ -16,31 +16,14 @@ Optional properties:
 - clocks : From common clock binding. First clock is phandle to clock for apb
 	pclk. Additional clocks are optional and specific to those peripherals.
 - clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
-- dmas : From common DMA binding. If present, refers to one or more dma channels.
-- dma-names : From common DMA binding, needs to match the 'dmas' property.
-              Devices with exactly one receive and transmit channel shall name
-              these "rx" and "tx", respectively.
-- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
-- pinctrl-names : Names corresponding to the numbered pinctrl states
-- interrupts : one or more interrupt specifiers
-- interrupt-names : names corresponding to the interrupts properties
 
 Example:
 
 serial@fff36000 {
 	compatible = "arm,pl011", "arm,primecell";
 	arm,primecell-periphid = <0x00341011>;
-
 	clocks = <&pclk>;
 	clock-names = "apb_pclk";
-
-	dmas = <&dma-controller 4>, <&dma-controller 5>;
-	dma-names = "rx", "tx";	
-
-	pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
-	pinctrl-1 = <&uart0_sleep_mode>;
-	pinctrl-names = "default","sleep";
-
-	interrupts = <0 11 0x4>;
+
 };
 

trunk/Documentation/devicetree/bindings/ata/pata-arasan.txt

@@ -6,26 +6,6 @@ Required properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
   that services interrupts for this device
 - interrupt: Should contain the CF interrupt number
-- clock-frequency: Interface clock rate, in Hz, one of
-       25000000
-       33000000
-       40000000
-       50000000
-       66000000
-       75000000
-      100000000
-      125000000
-      150000000
-      166000000
-      200000000
-
-Optional properties:
-- arasan,broken-udma: if present, UDMA mode is unusable
-- arasan,broken-mwdma: if present, MWDMA mode is unusable
-- arasan,broken-pio: if present, PIO mode is unusable
-- dmas: one DMA channel, as described in bindings/dma/dma.txt
-  required unless both UDMA and MWDMA mode are broken
-- dma-names: the corresponding channel name, must be "data"
 
 Example:
 
@@ -34,6 +14,4 @@ Example:
 		reg = <0xfc000000 0x1000>;
 		interrupt-parent = <&vic1>;
 		interrupts = <12>;
-		dmas = <&dma-controller 23>;
-		dma-names = "data";
 	};

trunk/Documentation/devicetree/bindings/mfd/ab8500.txt

@@ -13,6 +13,9 @@ Required parent device properties:
                                   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
@@ -83,8 +86,9 @@ Non-standard child device properties:
    - stericsson,amic2-bias-vamic1           : Analoge Mic wishes to use a non-standard Vamic
    - stericsson,earpeice-cmv                : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
 
-ab8500 {
+ab8500@5 {
          compatible = "stericsson,ab8500";
+         reg = <5>; /* mailbox 5 is i2c */
          interrupts = <0 40 0x4>;
          interrupt-controller;
          #interrupt-cells = <2>;

trunk/Documentation/devicetree/bindings/spi/spi_pl022.txt

@@ -16,11 +16,6 @@ Optional properties:
                             device will be suspended immediately
 - pl022,rt : indicates the controller should run the message pump with realtime
              priority to minimise the transfer latency on the bus (boolean)
-- dmas : Two or more DMA channel specifiers following the convention outlined
-         in bindings/dma/dma.txt
-- dma-names: Names for the dma channels, if present. There must be at
-	     least one channel named "tx" for transmit and named "rx" for
-             receive.
 
 
 SPI slave nodes must be children of the SPI master node and can
@@ -37,34 +32,3 @@ contain the following properties.
 - pl022,wait-state : Microwire interface: Wait state
 - pl022,duplex : Microwire interface: Full/Half duplex
 
-
-Example:
-
-	spi@e0100000 {
-		compatible = "arm,pl022", "arm,primecell";
-		reg = <0xe0100000 0x1000>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-		interrupts = <0 31 0x4>;
-		dmas = <&dma-controller 23 1>,
-			<&dma-controller 24 0>;
-		dma-names = "rx", "tx";
-
-		m25p80@1 {
-			compatible = "st,m25p80";
-			reg = <1>;
-			spi-max-frequency = <12000000>;
-			spi-cpol;
-			spi-cpha;
-			pl022,hierarchy = <0>;
-			pl022,interface = <0>;
-			pl022,slave-tx-disable;
-			pl022,com-mode = <0x2>;
-			pl022,rx-level-trig = <0>;
-			pl022,tx-level-trig = <0>;
-			pl022,ctrl-len = <0x11>;
-			pl022,wait-state = <0>;
-			pl022,duplex = <0>;
-		};
-	};
-

trunk/Documentation/devicetree/bindings/tty/serial/of-serial.txt

@@ -11,9 +11,6 @@ Required properties:
 	- "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.

trunk/Documentation/hwmon/lm75

@@ -23,7 +23,7 @@ Supported chips:
     Datasheet: Publicly available at the Maxim website
                http://www.maxim-ic.com/
   * Microchip (TelCom) TCN75
-    Prefix: 'tcn75'
+    Prefix: 'lm75'
     Addresses scanned: none
     Datasheet: Publicly available at the Microchip website
                http://www.microchip.com/

trunk/Documentation/i2c/busses/i2c-diolan-u2c

@@ -5,7 +5,7 @@ Supported adapters:
     Documentation:
 	http://www.diolan.com/i2c/u2c12.html
 
-Author: Guenter Roeck <linux@roeck-us.net>
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
 
 Description
 -----------

trunk/Documentation/input/alps.txt

@@ -3,26 +3,10 @@ ALPS Touchpad Protocol
 
 Introduction
 ------------
-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.
+
+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.
 
 Detection
 ---------
@@ -36,13 +20,9 @@ If the E6 report is successful, the touchpad model is identified using the "E7
 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.
 
-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.
+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.
 
 Command Mode
 ------------
@@ -67,14 +47,6 @@ address of the register being read, and the third contains the value of the
 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
 -------------
 
@@ -215,28 +187,3 @@ There are several things worth noting here.
     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

trunk/Documentation/networking/ipvs-sysctl.txt

@@ -15,13 +15,6 @@ amemthresh - INTEGER
         enabled and the variable is automatically set to 2, otherwise
         the strategy is disabled and the variable is  set  to 1.
 
-backup_only - BOOLEAN
-	0 - disabled (default)
-	not 0 - enabled
-
-	If set, disable the director function while the server is
-	in backup mode to avoid packet loops for DR/TUN methods.
-
 conntrack - BOOLEAN
 	0 - disabled (default)
 	not 0 - enabled

trunk/Documentation/networking/tuntap.txt

@@ -105,83 +105,6 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
      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 ?