---

yaml
---
r: 70807
b: refs/heads/master
c: 30c8264
h: refs/heads/master
i:
  70805: 229a368
  70803: 8e2c2b2
  70799: 844d52e
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: cbfee34520666862f8ff539e580c48958fbb7706
+refs/heads/master: 30c826451d3e5bbc6e11bba0e7fee5d2f49d9b75

trunk/Documentation/00-INDEX

@@ -22,8 +22,6 @@ CodingStyle
 	- how the boss likes the C code in the kernel to look.
 DMA-API.txt
 	- DMA API, pci_ API & extensions for non-consistent memory machines.
-DMA-ISA-LPC.txt
-	- How to do DMA with ISA (and LPC) devices.
 DMA-mapping.txt
 	- info for PCI drivers using DMA portably across all platforms.
 DocBook/
@@ -52,8 +50,6 @@ README.cycladesZ
 	- info on Cyclades-Z firmware loading.
 SAK.txt
 	- info on Secure Attention Keys.
-SM501.txt
-	- Silicon Motion SM501 multimedia companion chip
 SecurityBugs
 	- procedure for reporting security bugs found in the kernel.
 SubmitChecklist
@@ -248,8 +244,6 @@ md.txt
 	- info on boot arguments for the multiple devices driver.
 memory-barriers.txt
 	- info on Linux kernel memory barriers.
-memory-hotplug.txt
-	- Hotpluggable memory support, how to use and current status.
 memory.txt
 	- info on typical Linux memory problems.
 mips/
@@ -300,8 +294,6 @@ pm.txt
 	- info on Linux power management support.
 pnp.txt
 	- Linux Plug and Play documentation.
-power_supply_class.txt
-	- Tells userspace about battery, UPS, AC or DC power supply properties
 power/
 	- directory with info on Linux PCI power management.
 powerpc/
@@ -338,12 +330,8 @@ sched-coding.txt
 	- reference for various scheduler-related methods in the O(1) scheduler.
 sched-design.txt
 	- goals, design and implementation of the Linux O(1) scheduler.
-sched-design-CFS.txt
-	- goals, design and implementation of the Complete Fair Scheduler.
 sched-domains.txt
 	- information on scheduling domains.
-sched-nice-design.txt
-	- How and why the scheduler's nice levels are implemented.
 sched-stats.txt
 	- information on schedstats (Linux Scheduler Statistics).
 scsi/
@@ -388,8 +376,6 @@ stallion.txt
 	- info on using the Stallion multiport serial driver.
 svga.txt
 	- short guide on selecting video modes at boot via VGA BIOS.
-sysfs-rules.txt
-	- How not to use sysfs.
 sx.txt
 	- info on the Specialix SX/SI multiport serial driver.
 sysctl/
@@ -420,8 +406,6 @@ video4linux/
 	- directory with info regarding video/TV/radio cards and linux.
 vm/
 	- directory with info on the Linux vm code.
-volatile-considered-harmful.txt
-	- Why the "volatile" type class should not be used
 voyager.txt
 	- guide to running Linux on the Voyager architecture.
 w1/
@@ -430,5 +414,7 @@ watchdog/
 	- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
 x86_64/
 	- directory with info on Linux support for AMD x86-64 (Hammer) machines.
+xterm-linux.xpm
+	- XPM image of penguin logo (see logo.txt) sitting on an xterm.
 zorro.txt
 	- info on writing drivers for Zorro bus devices found on Amigas.

trunk/Documentation/CodingStyle

@@ -77,15 +77,12 @@ Get a decent editor and don't leave whitespace at the end of lines.
 Coding style is all about readability and maintainability using commonly
 available tools.
 
-The limit on the length of lines is 80 columns and this is a strongly
-preferred limit.
+The limit on the length of lines is 80 columns and this is a hard limit.
 
 Statements longer than 80 columns will be broken into sensible chunks.
 Descendants are always substantially shorter than the parent and are placed
 substantially to the right. The same applies to function headers with a long
-argument list. Long strings are as well broken into shorter strings. The
-only exception to this is where exceeding 80 columns significantly increases
-readability and does not hide information.
+argument list. Long strings are as well broken into shorter strings.
 
 void fun(int a, int b, int c)
 {

trunk/Documentation/DMA-mapping.txt

@@ -189,6 +189,12 @@ smaller mask as pci_set_dma_mask(). However for the rare case that a
 device driver only uses consistent allocations, one would have to
 check the return value from pci_set_consistent_dma_mask().
 
+If your 64-bit device is going to be an enormous consumer of DMA
+mappings, this can be problematic since the DMA mappings are a
+finite resource on many platforms.  Please see the "DAC Addressing
+for Address Space Hungry Devices" section near the end of this
+document for how to handle this case.
+
 Finally, if your device can only drive the low 24-bits of
 address during PCI bus mastering you might do something like:
 
@@ -197,6 +203,8 @@ address during PCI bus mastering you might do something like:
 		       "mydev: 24-bit DMA addressing not available.\n");
 		goto ignore_this_device;
 	}
+[Better use DMA_24BIT_MASK instead of 0x00ffffff.
+See linux/include/dma-mapping.h for reference.]
 
 When pci_set_dma_mask() is successful, and returns zero, the PCI layer
 saves away this mask you have provided.  The PCI layer will use this
@@ -644,6 +652,18 @@ It is planned to completely remove virt_to_bus() and bus_to_virt() as
 they are entirely deprecated.  Some ports already do not provide these
 as it is impossible to correctly support them.
 
+		64-bit DMA and DAC cycle support
+
+Do you understand all of the text above?  Great, then you already
+know how to use 64-bit DMA addressing under Linux.  Simply make
+the appropriate pci_set_dma_mask() calls based upon your cards
+capabilities, then use the mapping APIs above.
+
+It is that simple.
+
+Well, not for some odd devices.  See the next section for information
+about that.
+
 		Optimizing Unmap State Space Consumption
 
 On many platforms, pci_unmap_{single,page}() is simply a nop.

trunk/Documentation/DocBook/deviceiobook.tmpl

@@ -85,7 +85,7 @@
 
   <chapter id="mmio">
     <title>Memory Mapped IO</title>
-    <sect1 id="getting_access_to_the_device">
+    <sect1>
       <title>Getting Access to the Device</title>
       <para>
 	The most widely supported form of IO is memory mapped IO.
@@ -114,7 +114,7 @@
       </para>
     </sect1>
 
-    <sect1 id="accessing_the_device">
+    <sect1>
       <title>Accessing the device</title>
       <para>
 	The part of the interface most used by drivers is reading and
@@ -272,9 +272,9 @@ CPU B:  spin_unlock_irqrestore(&amp;dev_lock, flags)
 
   </chapter>
 
-  <chapter id="port_space_accesses">
+  <chapter>
     <title>Port Space Accesses</title>
-    <sect1 id="port_space_explained">
+    <sect1>
       <title>Port Space Explained</title>
 
       <para>
@@ -291,7 +291,7 @@ CPU B:  spin_unlock_irqrestore(&amp;dev_lock, flags)
       </para>
 
     </sect1>
-    <sect1 id="accessing_port_space">
+    <sect1>
       <title>Accessing Port Space</title>
       <para>
 	Accesses to this space are provided through a set of functions

trunk/Documentation/DocBook/filesystems.tmpl

@@ -40,25 +40,25 @@
 
   <chapter id="vfs">
      <title>The Linux VFS</title>
-     <sect1 id="the_filesystem_types"><title>The Filesystem types</title>
+     <sect1><title>The Filesystem types</title>
 !Iinclude/linux/fs.h
      </sect1>
-     <sect1 id="the_directory_cache"><title>The Directory Cache</title>
+     <sect1><title>The Directory Cache</title>
 !Efs/dcache.c
 !Iinclude/linux/dcache.h
      </sect1>
-     <sect1 id="inode_handling"><title>Inode Handling</title>
+     <sect1><title>Inode Handling</title>
 !Efs/inode.c
 !Efs/bad_inode.c
      </sect1>
-     <sect1 id="registration_and_superblocks"><title>Registration and Superblocks</title>
+     <sect1><title>Registration and Superblocks</title>
 !Efs/super.c
      </sect1>
-     <sect1 id="file_locks"><title>File Locks</title>
+     <sect1><title>File Locks</title>
 !Efs/locks.c
 !Ifs/locks.c
      </sect1>
-     <sect1 id="other_functions"><title>Other Functions</title>
+     <sect1><title>Other Functions</title>
 !Efs/mpage.c
 !Efs/namei.c
 !Efs/buffer.c
@@ -73,11 +73,11 @@
   <chapter id="proc">
      <title>The proc filesystem</title>
 
-     <sect1 id="sysctl_interface"><title>sysctl interface</title>
+     <sect1><title>sysctl interface</title>
 !Ekernel/sysctl.c
      </sect1>
 
-     <sect1 id="proc_filesystem_interface"><title>proc filesystem interface</title>
+     <sect1><title>proc filesystem interface</title>
 !Ifs/proc/base.c
      </sect1>
   </chapter>
@@ -92,7 +92,7 @@
   <chapter id="debugfs">
      <title>The debugfs filesystem</title>
 
-     <sect1 id="debugfs_interface"><title>debugfs interface</title>
+     <sect1><title>debugfs interface</title>
 !Efs/debugfs/inode.c
 !Efs/debugfs/file.c
      </sect1>
@@ -134,9 +134,9 @@
 
   <title>The Linux Journalling API</title>
 
-    <sect1 id="journaling_overview">
+    <sect1>
      <title>Overview</title>
-    <sect2 id="journaling_details">
+    <sect2>
      <title>Details</title>
 <para>
 The journalling layer is  easy to use. You need to
@@ -307,7 +307,7 @@ particular inode.
 
     </sect2>
 
-    <sect2 id="jbd_summary">
+    <sect2>
      <title>Summary</title>
 <para>
 Using the journal is a matter of wrapping the different context changes,
@@ -349,7 +349,7 @@ an example.
 
     </sect1>
 
-    <sect1 id="data_types">
+    <sect1>
      <title>Data Types</title>
      <para>
 	The journalling layer uses typedefs to 'hide' the concrete definitions
@@ -358,27 +358,27 @@ an example.
 
 	Obviously the hiding is not enforced as this is 'C'.
      </para>
-	<sect2 id="structures"><title>Structures</title>
+	<sect2><title>Structures</title>
 !Iinclude/linux/jbd.h
 	</sect2>
     </sect1>
 
-    <sect1 id="functions">
+    <sect1>
      <title>Functions</title>
      <para>
 	The functions here are split into two groups those that
 	affect a journal as a whole, and those which are used to
 	manage transactions
      </para>
-	<sect2 id="journal_level"><title>Journal Level</title>
+	<sect2><title>Journal Level</title>
 !Efs/jbd/journal.c
 !Ifs/jbd/recovery.c
 	</sect2>
-	<sect2 id="transaction_level"><title>Transasction Level</title>
+	<sect2><title>Transasction Level</title>
 !Efs/jbd/transaction.c
 	</sect2>
     </sect1>
-    <sect1 id="see_also">
+    <sect1>
      <title>See also</title>
 	<para>
 	  <citation>

trunk/Documentation/DocBook/gadget.tmpl

@@ -144,7 +144,7 @@ with the lowest level (which directly handles hardware).
 	<para>This is the lowest software level.
 	It is the only layer that talks to hardware,
 	through registers, fifos, dma, irqs, and the like.
-	The <filename>&lt;linux/usb/gadget.h&gt;</filename> API abstracts
+	The <filename>&lt;linux/usb_gadget.h&gt;</filename> API abstracts
 	the peripheral controller endpoint hardware.
 	That hardware is exposed through endpoint objects, which accept
 	streams of IN/OUT buffers, and through callbacks that interact
@@ -494,7 +494,7 @@ side drivers (and usbcore).
 <sect1 id="core"><title>Core Objects and Methods</title>
 
 <para>These are declared in
-<filename>&lt;linux/usb/gadget.h&gt;</filename>,
+<filename>&lt;linux/usb_gadget.h&gt;</filename>,
 and are used by gadget drivers to interact with
 USB peripheral controller drivers.
 </para>
@@ -509,7 +509,7 @@ USB peripheral controller drivers.
 	     unless the explanations are trivial.
 	  -->
 
-!Iinclude/linux/usb/gadget.h
+!Iinclude/linux/usb_gadget.h
 </sect1>
 
 <sect1 id="utils"><title>Optional Utilities</title>

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -340,7 +340,7 @@ X!Earch/x86/kernel/mca_32.c
 
   <chapter id="security">
      <title>Security Framework</title>
-!Isecurity/security.c
+!Esecurity/security.c
   </chapter>
 
   <chapter id="audit">
@@ -386,7 +386,8 @@ X!Edrivers/base/interface.c
 !Edrivers/base/bus.c
      </sect1>
      <sect1><title>Device Drivers Power Management</title>
-!Edrivers/base/power/main.c
+!Edrivers/base/power/resume.c
+!Edrivers/base/power/suspend.c
      </sect1>
      <sect1><title>Device Drivers ACPI Support</title>
 <!-- Internal functions only

trunk/Documentation/HOWTO

@@ -77,7 +77,7 @@ documentation files are also added which explain how to use the feature.
 When a kernel change causes the interface that the kernel exposes to
 userspace to change, it is recommended that you send the information or
 a patch to the manual pages explaining the change to the manual pages
-maintainer at mtk.manpages@gmail.com.
+maintainer at mtk-manpages@gmx.net.
 
 Here is a list of files that are in the kernel source tree that are
 required reading:

trunk/Documentation/SM501.txt

@@ -3,11 +3,6 @@
 
 Copyright 2006, 2007 Simtec Electronics
 
-The Silicon Motion SM501 multimedia companion chip is a multifunction device
-which may provide numerous interfaces including USB host controller USB gadget,
-Asyncronous Serial ports, Audio functions and a dual display video interface.
-The device may be connected by PCI or local bus with varying functions enabled.
-
 Core
 ----
 

trunk/Documentation/accounting/getdelays.c

@@ -21,6 +21,7 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/socket.h>
+#include <sys/types.h>
 #include <signal.h>
 
 #include <linux/genetlink.h>