5 files changed, 48 insertions, 16 deletions

diff --git a/Documentation/ABI/obsolete/dv1394 b/Documentation/ABI/obsolete/dv1394
new file mode 100644
index 000000000000..2ee36864ca10
--- /dev/null
+++ b/Documentation/ABI/obsolete/dv1394
@@ -0,0 +1,9 @@
+What:           dv1394 (a.k.a. "OHCI-DV I/O support" for FireWire)
+Contact:        linux1394-devel@lists.sourceforge.net
+Description:
+        New application development should use raw1394 + userspace libraries
+        instead, notably libiec61883 which is functionally equivalent.
+
+Users:
+        ffmpeg/libavformat (used by a variety of media players)
+        dvgrab v1.x (replaced by dvgrab2 on top of raw1394 and resp. libraries)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 0bc8b0b2e103..19b4c96b2a49 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -39,17 +39,6 @@ Who:	Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
 
 ---------------------------
 
-What:   dv1394 driver (CONFIG_IEEE1394_DV1394)
-When:   June 2007
-Why:    Replaced by raw1394 + userspace libraries, notably libiec61883.  This
-        shift of application support has been indicated on www.linux1394.org
-        and developers' mailinglists for quite some time.  Major applications
-        have been converted, with the exception of ffmpeg and hence xine.
-        Piped output of dvgrab2 is a partial equivalent to dv1394.
-Who:    Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
-
----------------------------
-
 What:   Video4Linux API 1 ioctls and video_decoder.h from Video devices.
 When:   December 2006
 Why:    V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 989f1130f4f3..f8528db967fa 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -27,7 +27,7 @@ The exact capabilities of GPIOs vary between systems.  Common options:
   - Output values are writable (high=1, low=0).  Some chips also have
     options about how that value is driven, so that for example only one
     value might be driven ... supporting "wire-OR" and similar schemes
-    for the other value.
+    for the other value (notably, "open drain" signaling).
 
   - Input values are likewise readable (1, 0).  Some chips support readback
     of pins configured as "output", which is very useful in such "wire-OR"
@@ -247,6 +247,35 @@ with gpio_get_value(), for example to initialize or update driver state
 when the IRQ is edge-triggered.
 
 
+Emulating Open Drain Signals
+----------------------------
+Sometimes shared signals need to use "open drain" signaling, where only the
+low signal level is actually driven.  (That term applies to CMOS transistors;
+"open collector" is used for TTL.)  A pullup resistor causes the high signal
+level.  This is sometimes called a "wire-AND"; or more practically, from the
+negative logic (low=true) perspective this is a "wire-OR".
+
+One common example of an open drain signal is a shared active-low IRQ line.
+Also, bidirectional data bus signals sometimes use open drain signals.
+
+Some GPIO controllers directly support open drain outputs; many don't.  When
+you need open drain signaling but your hardware doesn't directly support it,
+there's a common idiom you can use to emulate it with any GPIO pin that can
+be used as either an input or an output:
+
+ LOW:   gpio_direction_output(gpio, 0) ... this drives the signal
+        and overrides the pullup.
+
+ HIGH:  gpio_direction_input(gpio) ... this turns off the output,
+        so the pullup (or some other device) controls the signal.
+
+If you are "driving" the signal high but gpio_get_value(gpio) reports a low
+value (after the appropriate rise time passes), you know some other component
+is driving the shared signal low.  That's not necessarily an error.  As one
+common example, that's how I2C clocks are stretched:  a slave that needs a
+slower clock delays the rising edge of SCK, and the I2C master adjusts its
+signaling rate accordingly.
+
 
 What do these conventions omit?
 ===============================
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index d3aae1f9b4c1..702d1d8dd04a 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -851,6 +851,15 @@ accept_redirects - BOOLEAN
         Functional default: enabled if local forwarding is disabled.
                             disabled if local forwarding is enabled.
 
+accept_source_route - INTEGER
+        Accept source routing (routing extension header).
+
+        > 0: Accept routing header.
+        = 0: Accept only routing header type 2.
+        < 0: Do not accept routing header.
+
+        Default: 0
+
 autoconf - BOOLEAN
         Autoconfigure addresses using Prefix Information in Router 
         Advertisements.
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index 625a21db0c2a..85f51e5a749f 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -293,7 +293,3 @@ Debugging
                         stuck (default)
 
 Miscellaneous
-
-  noreplacement  Don't replace instructions with more appropriate ones
-                 for the CPU. This may be useful on asymmetric MP systems
-                 where some CPUs have less capabilities than others.