---

yaml
---
r: 126897
b: refs/heads/master
c: 2b6a2f5
h: refs/heads/master
i:
  126895: e87a51f
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 76052749143d03006271cc0ce8205ad756917062
+refs/heads/master: 2b6a2f535dda8c60721b78699618d13d6799a29e

trunk/.mailmap

@@ -32,7 +32,6 @@ Christoph Hellwig <hch@lst.de>
 Corey Minyard <minyard@acm.org>
 David Brownell <david-b@pacbell.net>
 David Woodhouse <dwmw2@shinybook.infradead.org>
-Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
 Domen Puncer <domen@coderock.org>
 Douglas Gilbert <dougg@torque.net>
 Ed L. Cashin <ecashin@coraid.com>

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

@@ -6,6 +6,7 @@ Description:
 		internal state of the kernel memory blocks. Files could be
 		added or removed dynamically to represent hot-add/remove
 		operations.
+
 Users:		hotplug memory add/remove tools
 		https://w3.opensource.ibm.com/projects/powerpc-utils/
 
@@ -18,56 +19,6 @@ Description:
 		This is useful for a user-level agent to determine
 		identify removable sections of the memory before attempting
 		potentially expensive hot-remove memory operation
-Users:		hotplug memory remove tools
-		https://w3.opensource.ibm.com/projects/powerpc-utils/
-
-What:		/sys/devices/system/memory/memoryX/phys_device
-Date:		September 2008
-Contact:	Badari Pulavarty <pbadari@us.ibm.com>
-Description:
-		The file /sys/devices/system/memory/memoryX/phys_device
-		is read-only and is designed to show the name of physical
-		memory device.  Implementation is currently incomplete.
 
-What:		/sys/devices/system/memory/memoryX/phys_index
-Date:		September 2008
-Contact:	Badari Pulavarty <pbadari@us.ibm.com>
-Description:
-		The file /sys/devices/system/memory/memoryX/phys_index
-		is read-only and contains the section ID in hexadecimal
-		which is equivalent to decimal X contained in the
-		memory section directory name.
-
-What:		/sys/devices/system/memory/memoryX/state
-Date:		September 2008
-Contact:	Badari Pulavarty <pbadari@us.ibm.com>
-Description:
-		The file /sys/devices/system/memory/memoryX/state
-		is read-write.  When read, it's contents show the
-		online/offline state of the memory section.  When written,
-		root can toggle the the online/offline state of a removable
-		memory section (see removable file description above)
-		using the following commands.
-		# echo online > /sys/devices/system/memory/memoryX/state
-		# echo offline > /sys/devices/system/memory/memoryX/state
-
-		For example, if /sys/devices/system/memory/memory22/removable
-		contains a value of 1 and
-		/sys/devices/system/memory/memory22/state contains the
-		string "online" the following command can be executed by
-		by root to offline that section.
-		# echo offline > /sys/devices/system/memory/memory22/state
 Users:		hotplug memory remove tools
 		https://w3.opensource.ibm.com/projects/powerpc-utils/
-
-What:		/sys/devices/system/node/nodeX/memoryY
-Date:		September 2008
-Contact:	Gary Hade <garyhade@us.ibm.com>
-Description:
-		When CONFIG_NUMA is enabled
-		/sys/devices/system/node/nodeX/memoryY is a symbolic link that
-		points to the corresponding /sys/devices/system/memory/memoryY
-		memory section directory.  For example, the following symbolic
-		link is created for memory section 9 on node0.
-		/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
-

trunk/Documentation/DMA-mapping.txt

@@ -26,7 +26,7 @@ mapped only for the time they are actually used and unmapped after the DMA
 transfer.
 
 The following API will work of course even on platforms where no such
-hardware exists, see e.g. arch/x86/include/asm/pci.h for how it is implemented on
+hardware exists, see e.g. include/asm-i386/pci.h for how it is implemented on
 top of the virt_to_bus interface.
 
 First of all, you should make sure

trunk/Documentation/DocBook/uio-howto.tmpl

@@ -41,12 +41,6 @@ GPL version 2.
 </abstract>
 
 <revhistory>
-	<revision>
-	<revnumber>0.6</revnumber>
-	<date>2008-12-05</date>
-	<authorinitials>hjk</authorinitials>
-	<revremark>Added description of portio sysfs attributes.</revremark>
-	</revision>
 	<revision>
 	<revnumber>0.5</revnumber>
 	<date>2008-05-22</date>
@@ -324,54 +318,6 @@ interested in translating it, please email me
 offset = N * getpagesize();
 </programlisting>
 
-<para>
-	Sometimes there is hardware with memory-like regions that can not be
-	mapped with the technique described here, but there are still ways to
-	access them from userspace. The most common example are x86 ioports.
-	On x86 systems, userspace can access these ioports using
-	<function>ioperm()</function>, <function>iopl()</function>,
-	<function>inb()</function>, <function>outb()</function>, and similar
-	functions.
-</para>
-<para>
-	Since these ioport regions can not be mapped, they will not appear under
-	<filename>/sys/class/uio/uioX/maps/</filename> like the normal memory
-	described above. Without information about the port regions a hardware
-	has to offer, it becomes difficult for the userspace part of the
-	driver to find out which ports belong to which UIO device.
-</para>
-<para>
-	To address this situation, the new directory
-	<filename>/sys/class/uio/uioX/portio/</filename> was added. It only
-	exists if the driver wants to pass information about one or more port
-	regions to userspace. If that is the case, subdirectories named
-	<filename>port0</filename>, <filename>port1</filename>, and so on,
-	will appear underneath
-	<filename>/sys/class/uio/uioX/portio/</filename>.
-</para>
-<para>
-	Each <filename>portX/</filename> directory contains three read-only
-	files that show start, size, and type of the port region:
-</para>
-<itemizedlist>
-<listitem>
-	<para>
-	<filename>start</filename>: The first port of this region.
-	</para>
-</listitem>
-<listitem>
-	<para>
-	<filename>size</filename>: The number of ports in this region.
-	</para>
-</listitem>
-<listitem>
-	<para>
-	<filename>porttype</filename>: A string describing the type of port.
-	</para>
-</listitem>
-</itemizedlist>
-
-
 </sect1>
 </chapter>
 
@@ -393,12 +339,12 @@ offset = N * getpagesize();
 
 <itemizedlist>
 <listitem><para>
-<varname>const char *name</varname>: Required. The name of your driver as
+<varname>char *name</varname>: Required. The name of your driver as
 it will appear in sysfs. I recommend using the name of your module for this.
 </para></listitem>
 
 <listitem><para>
-<varname>const char *version</varname>: Required. This string appears in
+<varname>char *version</varname>: Required. This string appears in
 <filename>/sys/class/uio/uioX/version</filename>.
 </para></listitem>
 
@@ -409,13 +355,6 @@ mapping you need to fill one of the <varname>uio_mem</varname> structures.
 See the description below for details.
 </para></listitem>
 
-<listitem><para>
-<varname>struct uio_port port[ MAX_UIO_PORTS_REGIONS ]</varname>: Required
-if you want to pass information about ioports to userspace. For each port
-region you need to fill one of the <varname>uio_port</varname> structures.
-See the description below for details.
-</para></listitem>
-
 <listitem><para>
 <varname>long irq</varname>: Required. If your hardware generates an
 interrupt, it's your modules task to determine the irq number during
@@ -509,42 +448,6 @@ Please do not touch the <varname>kobj</varname> element of
 <varname>struct uio_mem</varname>! It is used by the UIO framework
 to set up sysfs files for this mapping. Simply leave it alone.
 </para>
-
-<para>
-Sometimes, your device can have one or more port regions which can not be
-mapped to userspace. But if there are other possibilities for userspace to
-access these ports, it makes sense to make information about the ports
-available in sysfs. For each region, you have to set up a
-<varname>struct uio_port</varname> in the <varname>port[]</varname> array.
-Here's a description of the fields of <varname>struct uio_port</varname>:
-</para>
-
-<itemizedlist>
-<listitem><para>
-<varname>char *porttype</varname>: Required. Set this to one of the predefined
-constants. Use <varname>UIO_PORT_X86</varname> for the ioports found in x86
-architectures.
-</para></listitem>
-
-<listitem><para>
-<varname>unsigned long start</varname>: Required if the port region is used.
-Fill in the number of the first port of this region.
-</para></listitem>
-
-<listitem><para>
-<varname>unsigned long size</varname>: Fill in the number of ports in this
-region. If <varname>size</varname> is zero, the region is considered unused.
-Note that you <emphasis>must</emphasis> initialize <varname>size</varname>
-with zero for all unused regions.
-</para></listitem>
-</itemizedlist>
-
-<para>
-Please do not touch the <varname>portio</varname> element of
-<varname>struct uio_port</varname>! It is used internally by the UIO
-framework to set up sysfs files for this region. Simply leave it alone.
-</para>
-
 </sect1>
 
 <sect1 id="adding_irq_handler">

trunk/Documentation/feature-removal-schedule.txt

@@ -315,15 +315,3 @@ When:	2.6.29 (ideally) or 2.6.30 (more likely)
 Why:	Deprecated by the new (standard) device driver binding model. Use
 	i2c_driver->probe() and ->remove() instead.
 Who:	Jean Delvare <khali@linux-fr.org>
-
----------------------------
-
-What:	SELinux "compat_net" functionality
-When:	2.6.30 at the earliest
-Why:	In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
-	network access control functionality of SELinux.  Secmark offers both
-	better performance and greater flexibility than the "compat_net"
-	mechanism.  Now that the major Linux distributions have moved to
-	Secmark, it is time to deprecate the older mechanism and start the
-	process of removing the old code.
-Who:	Paul Moore <paul.moore@hp.com>

trunk/Documentation/filesystems/Locking

@@ -397,7 +397,7 @@ prototypes:
 };
 
 locking rules:
-	All may block.
+	All except ->poll() may block.
 			BKL
 llseek:			no	(see below)
 read:			no

trunk/Documentation/filesystems/proc.txt

@@ -1385,15 +1385,6 @@ swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
 to retain dentry and inode caches.  Increasing vfs_cache_pressure beyond 100
 causes the kernel to prefer to reclaim dentries and inodes.
 
-dirty_background_bytes
-----------------------
-
-Contains the amount of dirty memory at which the pdflush background writeback
-daemon will start writeback.
-
-If dirty_background_bytes is written, dirty_background_ratio becomes a function
-of its value (dirty_background_bytes / the amount of dirtyable system memory).
-
 dirty_background_ratio
 ----------------------
 
@@ -1402,29 +1393,14 @@ pages + file cache, not including locked pages and HugePages), the number of
 pages at which the pdflush background writeback daemon will start writing out
 dirty data.
 
-If dirty_background_ratio is written, dirty_background_bytes becomes a function
-of its value (dirty_background_ratio * the amount of dirtyable system memory).
-
-dirty_bytes
------------
-
-Contains the amount of dirty memory at which a process generating disk writes
-will itself start writeback.
-
-If dirty_bytes is written, dirty_ratio becomes a function of its value
-(dirty_bytes / the amount of dirtyable system memory).
-
 dirty_ratio
------------
+-----------------
 
 Contains, as a percentage of the dirtyable system memory (free pages + mapped
 pages + file cache, not including locked pages and HugePages), the number of
 pages at which a process which is generating disk writes will itself start
 writing out dirty data.
 
-If dirty_ratio is written, dirty_bytes becomes a function of its value
-(dirty_ratio * the amount of dirtyable system memory).
-
 dirty_writeback_centisecs
 -------------------------
 

trunk/Documentation/hwmon/adt7470

@@ -31,11 +31,15 @@ Each of the measured inputs (temperature, fan speed) has corresponding high/low
 limit values. The ADT7470 will signal an ALARM if any measured value exceeds
 either limit.
 
-The ADT7470 samples all inputs continuously.  A kernel thread is started up for
-the purpose of periodically querying the temperature sensors, thus allowing the
-automatic fan pwm control to set the fan speed.  The driver will not read the
-registers more often than once every 5 seconds.  Further, configuration data is
-only read once per minute.
+The ADT7470 DOES NOT sample all inputs continuously.  A single pin on the
+ADT7470 is connected to a multitude of thermal diodes, but the chip must be
+instructed explicitly to read the multitude of diodes.  If you want to use
+automatic fan control mode, you must manually read any of the temperature
+sensors or the fan control algorithm will not run.  The chip WILL NOT DO THIS
+AUTOMATICALLY; this must be done from userspace.  This may be a bug in the chip
+design, given that many other AD chips take care of this.  The driver will not
+read the registers more often than once every 5 seconds.  Further,
+configuration data is only read once per minute.
 
 Special Features
 ----------------
@@ -68,6 +72,5 @@ pwm#_auto_point2_temp.
 Notes
 -----
 
-The temperature inputs no longer need to be read periodically from userspace in
-order for the automatic pwm algorithm to run.  This was the case for earlier
-versions of the driver.
+As stated above, the temperature inputs must be read periodically from
+userspace in order for the automatic pwm algorithm to run.

trunk/Documentation/ide/warm-plug-howto.txt

@@ -11,8 +11,3 @@ unplug old device(s) and plug new device(s)
 # echo -n "1" > /sys/class/ide_port/idex/scan
 
 done
-
-NOTE: please make sure that partitions are unmounted and that there are
-no other active references to devices before doing "delete_devices" step,
-also do not attempt "scan" step on devices currently in use -- otherwise
-results may be unpredictable and lead to data loss if you're unlucky