---

yaml
---
r: 291892
b: refs/heads/master
c: 18dd2ec
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 0f0cc1687d7e41ac59e4eaf057aa2fb9e48a9dd3
+refs/heads/master: 18dd2ece3cde14cfd42e95a89eb14016699a5f15

trunk/Documentation/ABI/testing/sysfs-devices-power

@@ -165,21 +165,3 @@ Description:
 
 		Not all drivers support this attribute.  If it isn't supported,
 		attempts to read or write it will yield I/O errors.
-
-What:		/sys/devices/.../power/pm_qos_latency_us
-Date:		March 2012
-Contact:	Rafael J. Wysocki <rjw@sisk.pl>
-Description:
-		The /sys/devices/.../power/pm_qos_resume_latency_us attribute
-		contains the PM QoS resume latency limit for the given device,
-		which is the maximum allowed time it can take to resume the
-		device, after it has been suspended at run time, from a resume
-		request to the moment the device will be ready to process I/O,
-		in microseconds.  If it is equal to 0, however, this means that
-		the PM QoS resume latency may be arbitrary.
-
-		Not all drivers support this attribute.  If it isn't supported,
-		it is not present.
-
-		This attribute has no effect on system-wide suspend/resume and
-		hibernation.

trunk/Documentation/DocBook/device-drivers.tmpl

@@ -102,12 +102,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 +113,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
@@ -227,7 +219,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.c
+!Edrivers/tty/serial/8250.c
   </chapter>
 
   <chapter id="fbdev">

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/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/freezing-of-tasks.txt

@@ -63,27 +63,6 @@ devices have been reinitialized, the function thaw_processes() is called in
 order to clear the PF_FROZEN flag for each frozen task.  Then, the tasks that
 have been frozen leave __refrigerator() and continue running.
 
-
-Rationale behind the functions dealing with freezing and thawing of tasks:
--------------------------------------------------------------------------
-
-freeze_processes():
-  - freezes only userspace tasks
-
-freeze_kernel_threads():
-  - freezes all tasks (including kernel threads) because we can't freeze
-    kernel threads without freezing userspace tasks
-
-thaw_kernel_threads():
-  - thaws only kernel threads; this is particularly useful if we need to do
-    anything special in between thawing of kernel threads and thawing of
-    userspace tasks, or if we want to postpone the thawing of userspace tasks
-
-thaw_processes():
-  - thaws all tasks (including kernel threads) because we can't thaw userspace
-    tasks without thawing kernel threads
-
-
 III. Which kernel threads are freezable?
 
 Kernel threads are not freezable by default.  However, a kernel thread may clear

trunk/Documentation/sysctl/kernel.txt

@@ -601,8 +601,6 @@ can be ORed together:
         instead of using the one provided by the hardware.
  512 - A kernel warning has occurred.
 1024 - A module from drivers/staging was loaded.
-2048 - The system is working around a severe firmware bug.
-4096 - An out-of-tree module has been loaded.
 
 ==============================================================