---

yaml
---
r: 211248
b: refs/heads/master
c: 86cf147
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 989cd445b48dc996426ab739d002ed504c5c43c9
+refs/heads/master: 86cf1474948a91c67b3dd58f8b360006c82e0068

trunk/CREDITS

@@ -3554,12 +3554,12 @@ E: cvance@nai.com
 D: portions of the Linux Security Module (LSM) framework and security modules
 
 N: Petr Vandrovec
-E: petr@vandrovec.name
+E: vandrove@vc.cvut.cz
 D: Small contributions to ncpfs
 D: Matrox framebuffer driver
-S: 21513 Conradia Ct
-S: Cupertino, CA 95014
-S: USA
+S: Chudenicka 8
+S: 10200 Prague 10, Hostivar
+S: Czech Republic
 
 N: Thibaut Varene
 E: T-Bone@parisc-linux.org

trunk/Documentation/DMA-API-HOWTO.txt

@@ -738,17 +738,17 @@ to "Closing".
    CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs
    (including software IOMMU).
 
-2) ARCH_DMA_MINALIGN
+2) ARCH_KMALLOC_MINALIGN
 
    Architectures must ensure that kmalloc'ed buffer is
    DMA-safe. Drivers and subsystems depend on it. If an architecture
    isn't fully DMA-coherent (i.e. hardware doesn't ensure that data in
    the CPU cache is identical to data in main memory),
-   ARCH_DMA_MINALIGN must be set so that the memory allocator
+   ARCH_KMALLOC_MINALIGN must be set so that the memory allocator
    makes sure that kmalloc'ed buffer doesn't share a cache line with
    the others. See arch/arm/include/asm/cache.h as an example.
 
-   Note that ARCH_DMA_MINALIGN is about DMA memory alignment
+   Note that ARCH_KMALLOC_MINALIGN is about DMA memory alignment
    constraints. You don't need to worry about the architecture data
    alignment constraints (e.g. the alignment constraints about 64-bit
    objects).

trunk/Documentation/DocBook/device-drivers.tmpl

@@ -46,6 +46,7 @@
 
      <sect1><title>Atomic and pointer manipulation</title>
 !Iarch/x86/include/asm/atomic.h
+!Iarch/x86/include/asm/unaligned.h
      </sect1>
 
      <sect1><title>Delaying, scheduling, and timer routines</title>

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -57,6 +57,7 @@
      </para>
 
      <sect1><title>String Conversions</title>
+!Ilib/vsprintf.c
 !Elib/vsprintf.c
      </sect1>
      <sect1><title>String Manipulation</title>

trunk/Documentation/DocBook/kernel-locking.tmpl

@@ -1922,12 +1922,9 @@ machines due to caching.
       <function>mutex_lock()</function>
       </para>
       <para>
-       There is a <function>mutex_trylock()</function> which does not
-       sleep.  Still, it must not be used inside interrupt context since
-       its implementation is not safe for that.
+       There is a <function>mutex_trylock()</function> which can be
+       used inside interrupt context, as it will not sleep.
        <function>mutex_unlock()</function> will also never sleep.
-       It cannot be used in interrupt context either since a mutex
-       must be released by the same task that acquired it.
       </para>
      </listitem>
     </itemizedlist>
@@ -1961,12 +1958,6 @@ machines due to caching.
    </sect1>
   </chapter>
 
-  <chapter id="apiref">
-   <title>Mutex API reference</title>
-!Iinclude/linux/mutex.h
-!Ekernel/mutex.c
-  </chapter>
-
   <chapter id="references">
    <title>Further reading</title>
 

trunk/Documentation/DocBook/tracepoint.tmpl

@@ -104,9 +104,4 @@
    <title>Block IO</title>
 !Iinclude/trace/events/block.h
   </chapter>
-
-  <chapter id="workqueue">
-   <title>Workqueue</title>
-!Iinclude/trace/events/workqueue.h
-  </chapter>
 </book>

trunk/Documentation/acpi/method-customizing.txt

@@ -19,8 +19,6 @@ Note: Only ACPI METHOD can be overridden, any other object types like
       "Device", "OperationRegion", are not recognized.
 Note: The same ACPI control method can be overridden for many times,
       and it's always the latest one that used by Linux/kernel.
-Note: To get the ACPI debug object output (Store (AAAA, Debug)),
-      please run "echo 1 > /sys/module/acpi/parameters/aml_debug_output".
 
 1. override an existing method
    a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT,

trunk/Documentation/cgroups/blkio-controller.txt

@@ -217,7 +217,6 @@ Details of cgroup files
 CFQ sysfs tunable
 =================
 /sys/block/<disk>/queue/iosched/group_isolation
------------------------------------------------
 
 If group_isolation=1, it provides stronger isolation between groups at the
 expense of throughput. By default group_isolation is 0. In general that
@@ -244,33 +243,6 @@ By default one should run with group_isolation=0. If that is not sufficient
 and one wants stronger isolation between groups, then set group_isolation=1
 but this will come at cost of reduced throughput.
 
-/sys/block/<disk>/queue/iosched/slice_idle
-------------------------------------------
-On a faster hardware CFQ can be slow, especially with sequential workload.
-This happens because CFQ idles on a single queue and single queue might not
-drive deeper request queue depths to keep the storage busy. In such scenarios
-one can try setting slice_idle=0 and that would switch CFQ to IOPS
-(IO operations per second) mode on NCQ supporting hardware.
-
-That means CFQ will not idle between cfq queues of a cfq group and hence be
-able to driver higher queue depth and achieve better throughput. That also
-means that cfq provides fairness among groups in terms of IOPS and not in
-terms of disk time.
-
-/sys/block/<disk>/queue/iosched/group_idle
-------------------------------------------
-If one disables idling on individual cfq queues and cfq service trees by
-setting slice_idle=0, group_idle kicks in. That means CFQ will still idle
-on the group in an attempt to provide fairness among groups.
-
-By default group_idle is same as slice_idle and does not do anything if
-slice_idle is enabled.
-
-One can experience an overall throughput drop if you have created multiple
-groups and put applications in that group which are not driving enough
-IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle
-on individual groups and throughput should improve.
-
 What works
 ==========
 - Currently only sync IO queues are support. All the buffered writes are

trunk/Documentation/filesystems/Locking

@@ -374,6 +374,8 @@ prototypes:
 	ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
 	int (*readdir) (struct file *, void *, filldir_t);
 	unsigned int (*poll) (struct file *, struct poll_table_struct *);
+	int (*ioctl) (struct inode *, struct file *, unsigned int,
+			unsigned long);
 	long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
 	long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
 	int (*mmap) (struct file *, struct vm_area_struct *);
@@ -407,7 +409,8 @@ write:			no
 aio_write:		no
 readdir: 		no
 poll:			no
-unlocked_ioctl:		no
+ioctl:			yes	(see below)
+unlocked_ioctl:		no	(see below)
 compat_ioctl:		no
 mmap:			no
 open:			no
@@ -450,6 +453,9 @@ move ->readdir() to inode_operations and use a separate method for directory
 anything that resembles union-mount we won't have a struct file for all
 components. And there are other reasons why the current interface is a mess...
 
+->ioctl() on regular files is superceded by the ->unlocked_ioctl() that
+doesn't take the BKL.
+
 ->read on directories probably must go away - we should just enforce -EISDIR
 in sys_read() and friends.
 

trunk/Documentation/filesystems/vfs.txt

@@ -727,6 +727,7 @@ struct file_operations {
 	ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
 	int (*readdir) (struct file *, void *, filldir_t);
 	unsigned int (*poll) (struct file *, struct poll_table_struct *);
+	int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
 	long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
 	long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
 	int (*mmap) (struct file *, struct vm_area_struct *);
@@ -767,7 +768,10 @@ otherwise noted.
 	activity on this file and (optionally) go to sleep until there
 	is activity. Called by the select(2) and poll(2) system calls
 
-  unlocked_ioctl: called by the ioctl(2) system call.
+  ioctl: called by the ioctl(2) system call
+
+  unlocked_ioctl: called by the ioctl(2) system call. Filesystems that do not
+  	require the BKL should use this method instead of the ioctl() above.
 
   compat_ioctl: called by the ioctl(2) system call when 32 bit system calls
  	 are used on 64 bit kernels.

trunk/Documentation/gpio.txt

@@ -109,19 +109,17 @@ use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
 
 If you want to initialize a structure with an invalid GPIO number, use
 some negative number (perhaps "-EINVAL"); that will never be valid.  To
-test if such number from such a structure could reference a GPIO, you
-may use this predicate:
+test if a number could reference a GPIO, you may use this predicate:
 
 	int gpio_is_valid(int number);
 
 A number that's not valid will be rejected by calls which may request
 or free GPIOs (see below).  Other numbers may also be rejected; for
-example, a number might be valid but temporarily unused on a given board.
+example, a number might be valid but unused on a given board.
+
+Whether a platform supports multiple GPIO controllers is currently a
+platform-specific implementation issue.
 
-Whether a platform supports multiple GPIO controllers is a platform-specific
-implementation issue, as are whether that support can leave "holes" in the space
-of GPIO numbers, and whether new controllers can be added at runtime.  Such issues
-can affect things including whether adjacent GPIO numbers are both valid.
 
 Using GPIOs
 -----------
@@ -482,16 +480,12 @@ To support this framework, a platform's Kconfig will "select" either
 ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB
 and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines
 three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep().
+They may also want to provide a custom value for ARCH_NR_GPIOS.
 
-It may also provide a custom value for ARCH_NR_GPIOS, so that it better
-reflects the number of GPIOs in actual use on that platform, without
-wasting static table space.  (It should count both built-in/SoC GPIOs and
-also ones on GPIO expanders.
-
-ARCH_REQUIRE_GPIOLIB means that the gpiolib code will always get compiled
+ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled
 into the kernel on that architecture.
 
-ARCH_WANT_OPTIONAL_GPIOLIB means the gpiolib code defaults to off and the user
+ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user
 can enable it and build it into the kernel optionally.
 
 If neither of these options are selected, the platform does not support

trunk/Documentation/hwmon/f71882fg

@@ -2,6 +2,10 @@ Kernel driver f71882fg
 ======================
 
 Supported chips:
+  * Fintek F71808E
+    Prefix: 'f71808fg'
+    Addresses scanned: none, address read from Super I/O config space
+    Datasheet: Not public
   * Fintek F71858FG
     Prefix: 'f71858fg'
     Addresses scanned: none, address read from Super I/O config space

trunk/Documentation/hwmon/ltc4245

@@ -72,31 +72,9 @@ in6_min_alarm		5v  output undervoltage alarm
 in7_min_alarm		3v  output undervoltage alarm
 in8_min_alarm		Vee (-12v) output undervoltage alarm
 
-in9_input		GPIO voltage data (see note 1)
-in10_input		GPIO voltage data (see note 1)
-in11_input		GPIO voltage data (see note 1)
+in9_input		GPIO voltage data
 
 power1_input		12v power usage (mW)
 power2_input		5v  power usage (mW)
 power3_input		3v  power usage (mW)
 power4_input		Vee (-12v) power usage (mW)
-
-
-Note 1
-------
-
-If you have NOT configured the driver to sample all GPIO pins as analog
-voltages, then the in10_input and in11_input sysfs attributes will not be
-created. The driver will sample the GPIO pin that is currently connected to the
-ADC as an analog voltage, and report the value in in9_input.
-
-If you have configured the driver to sample all GPIO pins as analog voltages,
-then they will be sampled in round-robin fashion. If userspace reads too
-slowly, -EAGAIN will be returned when you read the sysfs attribute containing
-the sensor reading.
-
-The LTC4245 chip can be configured to sample all GPIO pins with two methods:
-1) platform data -- see include/linux/i2c/ltc4245.h
-2) OF device tree -- add the "ltc4245,use-extra-gpios" property to each chip
-
-The default mode of operation is to sample a single GPIO pin.