---

yaml
---
r: 367559
b: refs/heads/master
c: c13085e
h: refs/heads/master
i:
  367557: f9a58fe
  367555: f27eeee
  367551: d49d9d8
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 2467d7b7037438f2d1fed826fc5217dddf4b37fb
+refs/heads/master: c13085e519e8984fede41fa3d6a5502523b10996

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/ABI/testing/sysfs-firmware-acpi

@@ -18,32 +18,6 @@ Description:
 		yoffset: The number of pixels between the top of the screen
 			 and the top edge of the image.
 
-What:		/sys/firmware/acpi/hotplug/
-Date:		February 2013
-Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Description:
-		There are separate hotplug profiles for different classes of
-		devices supported by ACPI, such as containers, memory modules,
-		processors, PCI root bridges etc.  A hotplug profile for a given
-		class of devices is a collection of settings defining the way
-		that class of devices will be handled by the ACPI core hotplug
-		code.  Those profiles are represented in sysfs as subdirectories
-		of /sys/firmware/acpi/hotplug/.
-
-		The following setting is available to user space for each
-		hotplug profile:
-
-		enabled: If set, the ACPI core will handle notifications of
-			hotplug events associated with the given class of
-			devices and will allow those devices to be ejected with
-			the help of the _EJ0 control method.  Unsetting it
-			effectively disables hotplug for the correspoinding
-			class of devices.
-
-		The value of the above attribute is an integer number: 1 (set)
-		or 0 (unset).  Attempts to write any other values to it will
-		cause -EINVAL to be returned.
-
 What:		/sys/firmware/acpi/interrupts/
 Date:		February 2008
 Contact:	Len Brown <lenb@kernel.org>

trunk/Documentation/DocBook/device-drivers.tmpl

@@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
   <chapter id="uart16x50">
      <title>16x50 UART Driver</title>
 !Edrivers/tty/serial/serial_core.c
-!Edrivers/tty/serial/8250/8250_core.c
+!Edrivers/tty/serial/8250/8250.c
   </chapter>
 
   <chapter id="fbdev">

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/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/kernel-parameters.txt

@@ -596,33 +596,16 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86] parts under 4G.
+
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
 			start-[end] where start and end are both
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
-	crashkernel=size[KMG],high
-			[KNL, x86_64] range could be above 4G. Allow kernel
-			to allocate physical memory region from top, so could
-			be above 4G if system have more than 4G ram installed.
-			Otherwise memory region will be allocated below 4G, if
-			available.
-			It will be ignored if crashkernel=X is specified.
-	crashkernel=size[KMG],low
-			[KNL, x86_64] range under 4G. When crashkernel=X,high
-			is passed, kernel could allocate physical memory region
-			above 4G, that cause second kernel crash on system
-			that require some amount of low memory, e.g. swiotlb
-			requires at least 64M+32K low memory.  Kernel would
-			try to allocate 72M below 4G automatically.
-			This one let user to specify own low range under 4G
-			for second kernel instead.
-			0: to disable low allocation.
-			It will be ignored when crashkernel=X,high is not used
-			or memory reserved is below 4G.
-
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 
@@ -805,12 +788,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 	edd=		[EDD]
 			Format: {"off" | "on" | "skip[mbr]"}
 
-	efi_no_storage_paranoia [EFI; X86]
-			Using this parameter you can use more than 50% of
-			your efi variable storage. Use this parameter only if
-			you are really sure that your UEFI does sane gc and
-			fulfills the spec otherwise your board may brick.
-
 	eisa_irq_edge=	[PARISC,HW]
 			See header of drivers/parisc/eisa.c.
 

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 ?