---

yaml
---
r: 96537
b: refs/heads/master
c: f9af857
h: refs/heads/master
i:
  96535: 8c9cce0
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 362a61ad61199e19a61b8e432015e2586b288f5b
+refs/heads/master: f9af857489cc19ee3acd0d5248dca7d243e353a5

trunk/Documentation/DocBook/kgdb.tmpl

@@ -72,7 +72,7 @@
     kgdb is a source level debugger for linux kernel. It is used along
     with gdb to debug a linux kernel.  The expectation is that gdb can
     be used to "break in" to the kernel to inspect memory, variables
-    and look through call stack information similar to what an
+    and look through a cal stack information similar to what an
     application developer would use gdb for.  It is possible to place
     breakpoints in kernel code and perform some limited execution
     stepping.
@@ -93,10 +93,8 @@
   <chapter id="CompilingAKernel">
     <title>Compiling a kernel</title>
     <para>
-    To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
-    "Prompt for development and/or incomplete code/drivers"
-    (CONFIG_EXPERIMENTAL) in  "General setup", then under the
-    "Kernel debugging" select "KGDB: kernel debugging with remote gdb".
+    To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging"
+    and then select "KGDB: kernel debugging with remote gdb".
     </para>
     <para>
     Next you should choose one of more I/O drivers to interconnect debugging

trunk/Documentation/cgroups.txt

@@ -310,8 +310,8 @@ and then start a subshell 'sh' in that cgroup:
   cd /dev/cgroup
   mkdir Charlie
   cd Charlie
-  /bin/echo 2-3 > cpuset.cpus
-  /bin/echo 1 > cpuset.mems
+  /bin/echo 2-3 > cpus
+  /bin/echo 1 > mems
   /bin/echo $$ > tasks
   sh
   # The subshell 'sh' is now running in cgroup Charlie

trunk/Documentation/filesystems/Locking

@@ -92,6 +92,7 @@ prototypes:
 	void (*destroy_inode)(struct inode *);
 	void (*dirty_inode) (struct inode *);
 	int (*write_inode) (struct inode *, int);
+	void (*put_inode) (struct inode *);
 	void (*drop_inode) (struct inode *);
 	void (*delete_inode) (struct inode *);
 	void (*put_super) (struct super_block *);
@@ -114,6 +115,7 @@ alloc_inode:		no	no	no
 destroy_inode:		no
 dirty_inode:		no				(must not sleep)
 write_inode:		no
+put_inode:		no
 drop_inode:		no				!!!inode_lock!!!
 delete_inode:		no
 put_super:		yes	yes	no

trunk/Documentation/filesystems/vfs.txt

@@ -205,6 +205,7 @@ struct super_operations {
 
         void (*dirty_inode) (struct inode *);
         int (*write_inode) (struct inode *, int);
+        void (*put_inode) (struct inode *);
         void (*drop_inode) (struct inode *);
         void (*delete_inode) (struct inode *);
         void (*put_super) (struct super_block *);
@@ -245,6 +246,9 @@ or bottom half).
 	inode to disc.  The second parameter indicates whether the write
 	should be synchronous or not, not all filesystems check this flag.
 
+  put_inode: called when the VFS inode is removed from the inode
+	cache.
+
   drop_inode: called when the last access to the inode is dropped,
 	with the inode_lock spinlock held.
 

trunk/Documentation/hwmon/adt7473

@@ -69,8 +69,7 @@ point2: Set the pwm speed at a higher temperature bound.
 
 The ADT7473 will scale the pwm between the lower and higher pwm speed when
 the temperature is between the two temperature boundaries.  PWM values range
-from 0 (off) to 255 (full speed).  Fan speed will be set to maximum when the
-temperature sensor associated with the PWM control exceeds temp#_max.
+from 0 (off) to 255 (full speed).
 
 Notes
 -----

trunk/Documentation/hwmon/w83l785ts

@@ -33,8 +33,7 @@ Known Issues
 ------------
 
 On some systems (Asus), the BIOS is known to interfere with the driver
-and cause read errors. Or maybe the W83L785TS-S chip is simply unreliable,
-we don't really know. The driver will retry a given number of times
+and cause read errors. The driver will retry a given number of times
 (5 by default) and then give up, returning the old value (or 0 if
 there is no old value). It seems to work well enough so that you should
 not notice anything. Thanks to James Bolt for helping test this feature.

trunk/Documentation/i2c/functionality

@@ -51,72 +51,63 @@ A few combinations of the above flags are also defined for your convenience:
                                   the transparent emulation layer)
 
 
-ADAPTER IMPLEMENTATION
-----------------------
+ALGORITHM/ADAPTER IMPLEMENTATION
+--------------------------------
 
-When you write a new adapter driver, you will have to implement a
-function callback `functionality'. Typical implementations are given
-below.
+When you write a new algorithm driver, you will have to implement a
+function callback `functionality', that gets an i2c_adapter structure
+pointer as its only parameter:
 
-A typical SMBus-only adapter would list all the SMBus transactions it
-supports. This example comes from the i2c-piix4 driver:
-
-  static u32 piix4_func(struct i2c_adapter *adapter)
-  {
-	return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
-	       I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
-	       I2C_FUNC_SMBUS_BLOCK_DATA;
+  struct i2c_algorithm {
+	/* Many other things of course; check <linux/i2c.h>! */
+	u32 (*functionality) (struct i2c_adapter *);
   }
 
-A typical full-I2C adapter would use the following (from the i2c-pxa
-driver):
+A typically implementation is given below, from i2c-algo-bit.c:
 
-  static u32 i2c_pxa_functionality(struct i2c_adapter *adap)
+  static u32 bit_func(struct i2c_adapter *adap)
   {
-	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | 
+	       I2C_FUNC_PROTOCOL_MANGLING;
   }
 
-I2C_FUNC_SMBUS_EMUL includes all the SMBus transactions (with the
-addition of I2C block transactions) which i2c-core can emulate using
-I2C_FUNC_I2C without any help from the adapter driver. The idea is
-to let the client drivers check for the support of SMBus functions
-without having to care whether the said functions are implemented in
-hardware by the adapter, or emulated in software by i2c-core on top
-of an I2C adapter.
 
 
 CLIENT CHECKING
 ---------------
 
 Before a client tries to attach to an adapter, or even do tests to check
 whether one of the devices it supports is present on an adapter, it should
-check whether the needed functionality is present. The typical way to do
-this is (from the lm75 driver):
+check whether the needed functionality is present. There are two functions
+defined which should be used instead of calling the functionality hook
+in the algorithm structure directly:
+
+  /* Return the functionality mask */
+  extern u32 i2c_get_functionality (struct i2c_adapter *adap);
+
+  /* Return 1 if adapter supports everything we need, 0 if not. */
+  extern int i2c_check_functionality (struct i2c_adapter *adap, u32 func);
 
-  static int lm75_detect(...)
+This is a typical way to use these functions (from the writing-clients
+document):
+  int foo_detect_client(struct i2c_adapter *adapter, int address, 
+                          unsigned short flags, int kind)
   {
-	(...)
-	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
-				     I2C_FUNC_SMBUS_WORD_DATA))
-		goto exit;
-	(...)
-  }
+	/* Define needed variables */
+
+	/* As the very first action, we check whether the adapter has the
+	   needed functionality: we need the SMBus read_word_data,
+           write_word_data and write_byte functions in this example. */
+	if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
+	                                     I2C_FUNC_SMBUS_WRITE_BYTE))
+		goto ERROR0;
 
-Here, the lm75 driver checks if the adapter can do both SMBus byte data
-and SMBus word data transactions. If not, then the driver won't work on
-this adapter and there's no point in going on. If the check above is
-successful, then the driver knows that it can call the following
-functions: i2c_smbus_read_byte_data(), i2c_smbus_write_byte_data(),
-i2c_smbus_read_word_data() and i2c_smbus_write_word_data(). As a rule of
-thumb, the functionality constants you test for with
-i2c_check_functionality() should match exactly the i2c_smbus_* functions
-which you driver is calling.
+	/* Now we can do the real detection */
+
+	ERROR0:
+		/* Return an error */
+  }
 
-Note that the check above doesn't tell whether the functionalities are
-implemented in hardware by the underlying adapter or emulated in
-software by i2c-core. Client drivers don't have to care about this, as
-i2c-core will transparently implement SMBus transactions on top of I2C
-adapters.
 
 
 CHECKING THROUGH /DEV
@@ -125,19 +116,19 @@ CHECKING THROUGH /DEV
 If you try to access an adapter from a userspace program, you will have
 to use the /dev interface. You will still have to check whether the
 functionality you need is supported, of course. This is done using
-the I2C_FUNCS ioctl. An example, adapted from the i2cdetect program, is
-below:
+the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2cdetect
+program, is below:
 
   int file;
-  if (file = open("/dev/i2c-0", O_RDWR) < 0) {
+  if (file = open("/dev/i2c-0",O_RDWR) < 0) {
 	/* Some kind of error handling */
 	exit(1);
   }
-  if (ioctl(file, I2C_FUNCS, &funcs) < 0) {
+  if (ioctl(file,I2C_FUNCS,&funcs) < 0) {
 	/* Some kind of error handling */
 	exit(1);
   }
-  if (!(funcs & I2C_FUNC_SMBUS_QUICK)) {
+  if (! (funcs & I2C_FUNC_SMBUS_QUICK)) {
 	/* Oops, the needed functionality (SMBus write_quick function) is
            not available! */
 	exit(1);