---

yaml
---
r: 288388
b: refs/heads/master
c: b2ccf06
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 8cd5c8661df33674daa67bf552a73497eeeba710
+refs/heads/master: b2ccf065f7b23147ed135a41b01d05a332ca6b7e

trunk/Documentation/DocBook/device-drivers.tmpl

@@ -50,9 +50,7 @@
 
      <sect1><title>Delaying, scheduling, and timer routines</title>
 !Iinclude/linux/sched.h
-!Ekernel/sched/core.c
-!Ikernel/sched/cpupri.c
-!Ikernel/sched/fair.c
+!Ekernel/sched.c
 !Iinclude/linux/completion.h
 !Ekernel/timer.c
      </sect1>
@@ -102,12 +100,9 @@ X!Iinclude/linux/kobject.h
 !Iinclude/linux/device.h
      </sect1>
      <sect1><title>Device Drivers Base</title>
-!Idrivers/base/init.c
 !Edrivers/base/driver.c
 !Edrivers/base/core.c
-!Edrivers/base/syscore.c
 !Edrivers/base/class.c
-!Idrivers/base/node.c
 !Edrivers/base/firmware_class.c
 !Edrivers/base/transport_class.c
 <!-- Cannot be included, because
@@ -116,18 +111,13 @@ X!Iinclude/linux/kobject.h
      exceed allowed 44 characters maximum
 X!Edrivers/base/attribute_container.c
 -->
-!Edrivers/base/dd.c
+!Edrivers/base/sys.c
 <!--
 X!Edrivers/base/interface.c
 -->
 !Iinclude/linux/platform_device.h
 !Edrivers/base/platform.c
 !Edrivers/base/bus.c
-     </sect1>
-     <sect1><title>Device Drivers DMA Management</title>
-!Edrivers/base/dma-buf.c
-!Edrivers/base/dma-coherent.c
-!Edrivers/base/dma-mapping.c
      </sect1>
      <sect1><title>Device Drivers Power Management</title>
 !Edrivers/base/power/main.c
@@ -226,8 +216,9 @@ X!Isound/sound_firmware.c
 
   <chapter id="uart16x50">
      <title>16x50 UART Driver</title>
+!Iinclude/linux/serial_core.h
 !Edrivers/tty/serial/serial_core.c
-!Edrivers/tty/serial/8250/8250.c
+!Edrivers/tty/serial/8250.c
   </chapter>
 
   <chapter id="fbdev">

trunk/Documentation/DocBook/deviceiobook.tmpl

@@ -317,7 +317,7 @@ CPU B:  spin_unlock_irqrestore(&dev_lock, flags)
   <chapter id="pubfunctions">
      <title>Public Functions Provided</title>
 !Iarch/x86/include/asm/io.h
-!Elib/pci_iomap.c
+!Elib/iomap.c
   </chapter>
 
 </book>

trunk/Documentation/devicetree/bindings/gpio/led.txt

@@ -7,9 +7,9 @@ Each LED is represented as a sub-node of the gpio-leds device.  Each
 node's name represents the name of the corresponding LED.
 
 LED sub-node properties:
-- gpios :  Should specify the LED's GPIO, see "gpios property" in
-  Documentation/devicetree/gpio.txt.  Active low LEDs should be
-  indicated using flags in the GPIO specifier.
+- gpios :  Should specify the LED's GPIO, see "Specifying GPIO information
+  for devices" in Documentation/devicetree/booting-without-of.txt.  Active
+  low LEDs should be indicated using flags in the GPIO specifier.
 - label :  (optional) The label for this LED.  If omitted, the label is
   taken from the node name (excluding the unit address).
 - linux,default-trigger :  (optional) This parameter, if present, is a

trunk/Documentation/devicetree/bindings/vendor-prefixes.txt

@@ -30,7 +30,6 @@ national	National Semiconductor
 nintendo	Nintendo
 nvidia	NVIDIA
 nxp	NXP Semiconductors
-picochip	Picochip Ltd
 powervr	Imagination Technologies
 qcom	Qualcomm, Inc.
 ramtron	Ramtron International

trunk/Documentation/driver-model/devres.txt

@@ -233,10 +233,6 @@ certainly invest a bit more effort into libata core layer).
   6. List of managed interfaces
   -----------------------------
 
-MEM
-  devm_kzalloc()
-  devm_kfree()
-
 IO region
   devm_request_region()
   devm_request_mem_region()

trunk/Documentation/feature-removal-schedule.txt

@@ -510,17 +510,3 @@ Why:	The pci_scan_bus_parented() interface creates a new root bus.  The
 	convert to using pci_scan_root_bus() so they can supply a list of
 	bus resources when the bus is created.
 Who:	Bjorn Helgaas <bhelgaas@google.com>
-
-----------------------------
-
-What:	The CAP9 SoC family will be removed
-When:	3.4
-Files:	arch/arm/mach-at91/at91cap9.c
-	arch/arm/mach-at91/at91cap9_devices.c
-	arch/arm/mach-at91/include/mach/at91cap9.h
-	arch/arm/mach-at91/include/mach/at91cap9_matrix.h
-	arch/arm/mach-at91/include/mach/at91cap9_ddrsdr.h
-	arch/arm/mach-at91/board-cap9adk.c
-Why:	The code is not actively maintained and platforms are now hard to find.
-Who:	Nicolas Ferre <nicolas.ferre@atmel.com>
-	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

trunk/Documentation/hwmon/jc42

@@ -7,29 +7,21 @@ Supported chips:
     Addresses scanned: I2C 0x18 - 0x1f
     Datasheets:
 	http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
-  * Atmel AT30TS00
-    Prefix: 'at30ts00'
+  * IDT TSE2002B3, TS3000B3
+    Prefix: 'tse2002b3', 'ts3000b3'
     Addresses scanned: I2C 0x18 - 0x1f
     Datasheets:
-	http://www.atmel.com/Images/doc8585.pdf
-  * IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2
-    Prefix: 'tse2002', 'ts3000'
-    Addresses scanned: I2C 0x18 - 0x1f
-    Datasheets:
-	http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf
-	http://www.idt.com/sites/default/files/documents/IDT_TSE2002GB2A1_DST_20111107_120303145914.pdf
-	http://www.idt.com/sites/default/files/documents/IDT_TS3000B3A_DST_20101129_120303152013.pdf
-	http://www.idt.com/sites/default/files/documents/IDT_TS3000GB2A1_DST_20111104_120303151012.pdf
+	http://www.idt.com/products/getdoc.cfm?docid=18715691
+	http://www.idt.com/products/getdoc.cfm?docid=18715692
   * Maxim MAX6604
     Prefix: 'max6604'
     Addresses scanned: I2C 0x18 - 0x1f
     Datasheets:
 	http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
-  * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843
-    Prefixes: 'mcp9804', 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843'
+  * Microchip MCP9805, MCP98242, MCP98243, MCP9843
+    Prefixes: 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843'
     Addresses scanned: I2C 0x18 - 0x1f
     Datasheets:
-	http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
 	http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
 	http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
 	http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
@@ -56,12 +48,6 @@ Supported chips:
     Datasheets:
 	http://www.st.com/stonline/products/literature/ds/13447/stts424.pdf
 	http://www.st.com/stonline/products/literature/ds/13448/stts424e02.pdf
-  * ST Microelectronics STTS2002, STTS3000
-    Prefix: 'stts2002', 'stts3000'
-    Addresses scanned: I2C 0x18 - 0x1f
-    Datasheets:
-	http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf
-	http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf
   * JEDEC JC 42.4 compliant temperature sensor chips
     Prefix: 'jc42'
     Addresses scanned: I2C 0x18 - 0x1f

trunk/Documentation/input/alps.txt

@@ -13,8 +13,7 @@ Detection
 
 All ALPS touchpads should respond to the "E6 report" command sequence:
 E8-E6-E6-E6-E9. An ALPS touchpad should respond with either 00-00-0A or
-00-00-64 if no buttons are pressed. The bits 0-2 of the first byte will be 1s
-if some buttons are pressed.
+00-00-64.
 
 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

trunk/Documentation/input/event-codes.txt

@@ -17,11 +17,11 @@ reports supported by a device are also provided by sysfs in
 class/input/event*/device/capabilities/, and the properties of a device are
 provided in class/input/event*/device/properties.
 
-Event types:
-===========
-Event types are groupings of codes under a logical input construct. Each
-type has a set of applicable codes to be used in generating events. See the
-Codes section for details on valid codes for each type.
+Types:
+==========
+Types are groupings of codes under a logical input construct. Each type has a
+set of applicable codes to be used in generating events. See the Codes section
+for details on valid codes for each type.
 
 * EV_SYN:
   - Used as markers to separate events. Events may be separated in time or in
@@ -63,9 +63,9 @@ Codes section for details on valid codes for each type.
 * EV_FF_STATUS:
   - Used to receive force feedback device status.
 
-Event codes:
-===========
-Event codes define the precise type of event.
+Codes:
+==========
+Codes define the precise type of event.
 
 EV_SYN:
 ----------
@@ -220,56 +220,6 @@ EV_PWR:
 EV_PWR events are a special type of event used specifically for power
 mangement. Its usage is not well defined. To be addressed later.
 
-Device properties:
-=================
-Normally, userspace sets up an input device based on the data it emits,
-i.e., the event types. In the case of two devices emitting the same event
-types, additional information can be provided in the form of device
-properties.
-
-INPUT_PROP_DIRECT + INPUT_PROP_POINTER:
---------------------------------------
-The INPUT_PROP_DIRECT property indicates that device coordinates should be
-directly mapped to screen coordinates (not taking into account trivial
-transformations, such as scaling, flipping and rotating). Non-direct input
-devices require non-trivial transformation, such as absolute to relative
-transformation for touchpads. Typical direct input devices: touchscreens,
-drawing tablets; non-direct devices: touchpads, mice.
-
-The INPUT_PROP_POINTER property indicates that the device is not transposed
-on the screen and thus requires use of an on-screen pointer to trace user's
-movements.  Typical pointer devices: touchpads, tablets, mice; non-pointer
-device: touchscreen.
-
-If neither INPUT_PROP_DIRECT or INPUT_PROP_POINTER are set, the property is
-considered undefined and the device type should be deduced in the
-traditional way, using emitted event types.
-
-INPUT_PROP_BUTTONPAD:
---------------------
-For touchpads where the button is placed beneath the surface, such that
-pressing down on the pad causes a button click, this property should be
-set. Common in clickpad notebooks and macbooks from 2009 and onwards.
-
-Originally, the buttonpad property was coded into the bcm5974 driver
-version field under the name integrated button. For backwards
-compatibility, both methods need to be checked in userspace.
-
-INPUT_PROP_SEMI_MT:
-------------------
-Some touchpads, most common between 2008 and 2011, can detect the presence
-of multiple contacts without resolving the individual positions; only the
-number of contacts and a rectangular shape is known. For such
-touchpads, the semi-mt property should be set.
-
-Depending on the device, the rectangle may enclose all touches, like a
-bounding box, or just some of them, for instance the two most recent
-touches. The diversity makes the rectangle of limited use, but some
-gestures can normally be extracted from it.
-
-If INPUT_PROP_SEMI_MT is not set, the device is assumed to be a true MT
-device.
-
 Guidelines:
 ==========
 The guidelines below ensure proper single-touch and multi-finger functionality.
@@ -290,8 +240,6 @@ used to report when a touch is active on the screen.
 BTN_{MOUSE,LEFT,MIDDLE,RIGHT} must not be reported as the result of touch
 contact. BTN_TOOL_<name> events should be reported where possible.
 
-For new hardware, INPUT_PROP_DIRECT should be set.
-
 Trackpads:
 ----------
 Legacy trackpads that only provide relative position information must report
@@ -302,8 +250,6 @@ location of the touch. BTN_TOUCH should be used to report when a touch is active
 on the trackpad. Where multi-finger support is available, BTN_TOOL_<name> should
 be used to report the number of touches active on the trackpad.
 
-For new hardware, INPUT_PROP_POINTER should be set.
-
 Tablets:
 ----------
 BTN_TOOL_<name> events must be reported when a stylus or other tool is active on
@@ -314,5 +260,3 @@ button may be used for buttons on the tablet except BTN_{MOUSE,LEFT}.
 BTN_{0,1,2,etc} are good generic codes for unlabeled buttons. Do not use
 meaningful buttons, like BTN_FORWARD, unless the button is labeled for that
 purpose on the device.
-
-For new hardware, both INPUT_PROP_DIRECT and INPUT_PROP_POINTER should be set.

trunk/Documentation/kernel-parameters.txt

@@ -2211,12 +2211,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 			default: off.
 
-	printk.always_kmsg_dump=
-			Trigger kmsg_dump for cases other than kernel oops or
-			panics
-			Format: <bool>  (1/Y/y=enable, 0/N/n=disable)
-			default: disabled
-
 	printk.time=	Show timing data prefixed to each printk message line
 			Format: <bool>  (1/Y/y=enable, 0/N/n=disable)
 

trunk/Documentation/pinctrl.txt

@@ -857,41 +857,42 @@ case), we define a mapping like this:
 
 ...
 {
-	.name = "2bit"
+	.name "2bit"
 	.ctrl_dev_name = "pinctrl-foo",
 	.function = "mmc0",
 	.group = "mmc0_1_grp",
 	.dev_name = "foo-mmc.0",
 },
 {
-	.name = "4bit"
+	.name "4bit"
 	.ctrl_dev_name = "pinctrl-foo",
 	.function = "mmc0",
 	.group = "mmc0_1_grp",
 	.dev_name = "foo-mmc.0",
 },
 {
-	.name = "4bit"
+	.name "4bit"
 	.ctrl_dev_name = "pinctrl-foo",
 	.function = "mmc0",
 	.group = "mmc0_2_grp",
 	.dev_name = "foo-mmc.0",
 },
 {
-	.name = "8bit"
+	.name "8bit"
 	.ctrl_dev_name = "pinctrl-foo",
+	.function = "mmc0",
 	.group = "mmc0_1_grp",
 	.dev_name = "foo-mmc.0",
 },
 {
-	.name = "8bit"
+	.name "8bit"
 	.ctrl_dev_name = "pinctrl-foo",
 	.function = "mmc0",
 	.group = "mmc0_2_grp",
 	.dev_name = "foo-mmc.0",
 },
 {
-	.name = "8bit"
+	.name "8bit"
 	.ctrl_dev_name = "pinctrl-foo",
 	.function = "mmc0",
 	.group = "mmc0_3_grp",
@@ -994,7 +995,7 @@ This is enabled by simply setting the .hog_on_boot field in the map to true,
 like this:
 
 {
-	.name = "POWERMAP"
+	.name "POWERMAP"
 	.ctrl_dev_name = "pinctrl-foo",
 	.function = "power_func",
 	.hog_on_boot = true,
@@ -1024,7 +1025,7 @@ it, disables and releases it, and muxes it in on the pins defined by group B:
 
 foo_switch()
 {
-	struct pinmux *pmx;
+	struct pinmux pmx;
 
 	/* Enable on position A */
 	pmx = pinmux_get(&device, "spi0-pos-A");

trunk/Documentation/power/basic-pm-debugging.txt

@@ -15,7 +15,7 @@ test at least a couple of times in a row for confidence.  [This is necessary,
 because some problems only show up on a second attempt at suspending and
 resuming the system.]  Moreover, hibernating in the "reboot" and "shutdown"
 modes causes the PM core to skip some platform-related callbacks which on ACPI
-systems might be necessary to make hibernation work.  Thus, if your machine fails
+systems might be necessary to make hibernation work.  Thus, if you machine fails
 to hibernate or resume in the "reboot" mode, you should try the "platform" mode:
 
 # echo platform > /sys/power/disk

trunk/Documentation/power/freezing-of-tasks.txt

@@ -120,10 +120,10 @@ So in practice, the 'at all' may become a 'why freeze kernel threads?' and
 freezing user threads I don't find really objectionable."
 
 Still, there are kernel threads that may want to be freezable.  For example, if
-a kernel thread that belongs to a device driver accesses the device directly, it
-in principle needs to know when the device is suspended, so that it doesn't try
-to access it at that time.  However, if the kernel thread is freezable, it will
-be frozen before the driver's .suspend() callback is executed and it will be
+a kernel that belongs to a device driver accesses the device directly, it in
+principle needs to know when the device is suspended, so that it doesn't try to
+access it at that time.  However, if the kernel thread is freezable, it will be
+frozen before the driver's .suspend() callback is executed and it will be
 thawed after the driver's .resume() callback has run, so it won't be accessing
 the device while it's suspended.