23 files changed, 484 insertions, 689 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 72dc90f8f4a7..8de8a01a2474 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -12,8 +12,6 @@ Following translations are available on the WWW:
 00-INDEX
        - this file.
-BK-usage/
-        - directory with info on BitKeeper.
 BUG-HUNTING
        - brute force method of doing binary search of patches to find bug.
 Changes
diff --git a/Documentation/BK-usage/00-INDEX b/Documentation/BK-usage/00-INDEX
deleted file mode 100644
index 82768784ea52..000000000000
--- a/Documentation/BK-usage/00-INDEX
+++ /dev/null
@@ -1,51 +0,0 @@
-bk-kernel-howto.txt: Description of kernel workflow under BitKeeper
-bk-make-sum: Create summary of changesets in one repository and not
-another, typically in preparation to be sent to an upstream maintainer.
-Typical usage:
-        cd my-updated-repo
-        bk-make-sum ~/repo/original-repo
-        mv /tmp/linus.txt ../original-repo.txt
-bksend: Create readable text output containing summary of changes, GNU
-patch of the changes, and BK metadata of changes (as needed for proper
-importing into BitKeeper by an upstream maintainer).  This output is
-suitable for emailing BitKeeper changes.  The recipient of this output
-may pipe it directly to 'bk receive'.
-bz64wrap: helper script. Uncompressed input is piped to this script,
-which compresses its input, and then outputs the uu-/base64-encoded
-version of the compressed input.
-cpcset: Copy changeset between unrelated repositories.
-Attempts to preserve changeset user, user address, description, in
-addition to the changeset (the patch) itself.
-Typical usage:
-        cd my-updated-repo
-        bk changes      # looking for a changeset...
-        cpcset 1.1511 . ../another-repo
-csets-to-patches: Produces a delta of two BK repositories, in the form
-of individual files, each containing a single cset as a GNU patch.
-Output is several files, each with the filename "/tmp/rev-$REV.patch"
-Typical usage:
-        cd my-updated-repo
-        bk changes -L ~/repo/original-repo 2>&1 | \
-                perl csets-to-patches
-cset-to-linus: Produces a delta of two BK repositories, in the form of
-changeset descriptions, with 'diffstat' output created for each
-individual changset.
-Typical usage:
-        cd my-updated-repo
-        bk changes -L ~/repo/original-repo 2>&1 | \
-                perl cset-to-linus > summary.txt
-gcapatch:  Generates patch containing changes in local repository.
-Typical usage:
-        cd my-updated-repo
-        gcapatch > foo.patch
-unbz64wrap: Reverse an encoded, compressed data stream created by
-bz64wrap into an uncompressed, typically text/plain output.
diff --git a/Documentation/BK-usage/bk-kernel-howto.txt b/Documentation/BK-usage/bk-kernel-howto.txt
deleted file mode 100644
index b7b9075d2910..000000000000
--- a/Documentation/BK-usage/bk-kernel-howto.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-                   Doing the BK Thing, Penguin-Style
-This set of notes is intended mainly for kernel developers, occasional
-or full-time, but sysadmins and power users may find parts of it useful
-as well.  It assumes at least a basic familiarity with CVS, both at a
-user level (use on the cmd line) and at a higher level (client-server model).
-Due to the author's background, an operation may be described in terms
-of CVS, or in terms of how that operation differs from CVS.
-This is -not- intended to be BitKeeper documentation.  Always run
-"bk help <command>" or in X "bk helptool <command>" for reference
-documentation.
-BitKeeper Concepts
------------------
-In the true nature of the Internet itself, BitKeeper is a distributed
-system.  When applied to revision control, this means doing away with
-client-server, and changing to a parent-child model... essentially
-peer-to-peer.  On the developer's end, this also represents a
-fundamental disruption in the standard workflow of changes, commits,
-and merges.  You will need to take a few minutes to think about
-how to best work under BitKeeper, and re-optimize things a bit.
-In some sense it is a bit radical, because it might described as
-tossing changes out into a maelstrom and having them magically
-land at the right destination... but I'm getting ahead of myself.
-Let's start with this progression:
-Each BitKeeper source tree on disk is a repository unto itself.
-Each repository has a parent (except the root/original, of course).
-Each repository contains a set of a changesets ("csets").
-Each cset is one or more changed files, bundled together.
-Each tree is a repository, so all changes are checked into the local
-tree.  When a change is checked in, all modified files are grouped
-into a logical unit, the changeset.  Internally, BK links these
-changesets in a tree, representing various converging and diverging
-lines of development.  These changesets are the bread and butter of
-the BK system.
-After the concept of changesets, the next thing you need to get used
-to is having multiple copies of source trees lying around.  This -really-
-takes some getting used to, for some people.  Separate source trees
-are the means in BitKeeper by which you delineate parallel lines
-of development, both minor and major.  What would be branches in
-CVS become separate source trees, or "clones" in BitKeeper [heh,
-or Star Wars] terminology.
-Clones and changesets are the tools from which most of the power of
-BitKeeper is derived.  As mentioned earlier, each clone has a parent,
-the tree used as the source when the new clone was created.  In a
-CVS-like setup, the parent would be a remote server on the Internet,
-and the child is your local clone of that tree.
-Once you have established a common baseline between two source trees --
-a common parent -- then you can merge changesets between those two
-trees with ease.  Merging changes into a tree is called a "pull", and
-is analagous to 'cvs update'.  A pull downloads all the changesets in
-the remote tree you do not have, and merges them.  Sending changes in
-one tree to another tree is called a "push".  Push sends all changes
-in the local tree the remote does not yet have, and merges them.
-From these concepts come some initial command examples:
-1) bk clone -q http://linux.bkbits.net/linux-2.5 linus-2.5
-Download a 2.5 stock kernel tree, naming it "linus-2.5" in the local dir.
-The "-q" disables listing every single file as it is downloaded.
-2) bk clone -ql linus-2.5 alpha-2.5
-Create a separate source tree for the Alpha AXP architecture.
-The "-l" uses hard links instead of copying data, since both trees are
-on the local disk.  You can also replace the above with "bk lclone -q ..."
-You only clone a tree -once-.  After cloning the tree lives a long time
-on disk, being updating by pushes and pulls.
-3) cd alpha-2.5 ; bk pull http://gkernel.bkbits.net/alpha-2.5
-Download changes in "alpha-2.5" repository which are not present
-in the local repository, and merge them into the source tree.
-4) bk -r co -q
-Because every tree is a repository, files must be checked out before
-they will be in their standard places in the source tree.
-5)      bk vi fs/inode.c                                # example change...
-        bk citool                                       # checkin, using X tool
-        bk push bk://gkernel@bkbits.net/alpha-2.5       # upload change
-Typical example of a BK sequence that would replace the analagous CVS
-situation,
-        vi fs/inode.c
-        cvs commit
-As this is just supposed to be a quick BK intro, for more in-depth
-tutorials, live working demos, and docs, see http://www.bitkeeper.com/
-BK and Kernel Development Workflow
----------------------------------
-Currently the latest 2.5 tree is available via "bk clone $URL"
-and "bk pull $URL" at http://linux.bkbits.net/linux-2.5
-This should change in a few weeks to a kernel.org URL.
-A big part of using BitKeeper is organizing the various trees you have
-on your local disk, and organizing the flow of changes among those
-trees, and remote trees.  If one were to graph the relationships between
-a desired BK setup, you are likely to see a few-many-few graph, like
-this:
-                    linux-2.5
-                        |
-               merge-to-linus-2.5
-                 /    |      |
-                /     |      |
-        vm-hacks  bugfixes  filesys   personal-hacks
-              \       |      |          /
-               \      |      |         /
-                \     |      |        /
-                 testing-and-validation
-Since a "bk push" sends all changes not in the target tree, and
-since a "bk pull" receives all changes not in the source tree, you want
-to make sure you are only pushing specific changes to the desired tree,
-not all changes from "peer parent" trees.  For example, pushing a change
-from the testing-and-validation tree would probably be a bad idea,
-because it will push all changes from vm-hacks, bugfixes, filesys, and
-personal-hacks trees into the target tree.
-One would typically work on only one "theme" at a time, either
-vm-hacks or bugfixes or filesys, keeping those changes isolated in
-their own tree during development, and only merge the isolated with
-other changes when going upstream (to Linus or other maintainers) or
-downstream (to your "union" trees, like testing-and-validation above).
-It should be noted that some of this separation is not just recommended
-practice, it's actually [for now] -enforced- by BitKeeper.  BitKeeper
-requires that changesets maintain a certain order, which is the reason
-that "bk push" sends all local changesets the remote doesn't have.  This
-separation may look like a lot of wasted disk space at first, but it
-helps when two unrelated changes may "pollute" the same area of code, or
-don't follow the same pace of development, or any other of the standard
-reasons why one creates a development branch.
-Small development branches (clones) will appear and disappear:
-        -------- A --------- B --------- C --------- D -------
-                  \                                 /
-                   -----short-term devel branch-----
-While long-term branches will parallel a tree (or trees), with period
-merge points.  In this first example, we pull from a tree (pulls,
-"\") periodically, such as what occurs when tracking changes in a
-vendor tree, never pushing changes back up the line:
-        -------- A --------- B --------- C --------- D -------
-                  \                       \           \
-                   ----long-term devel branch-----------------
-And then a more common case in Linux kernel development, a long term
-branch with periodic merges back into the tree (pushes, "/"):
-        -------- A --------- B --------- C --------- D -------
-                  \                       \         / \
-                   ----long-term devel branch-----------------
-Submitting Changes to Linus
---------------------------
-There's a bit of an art, or style, of submitting changes to Linus.
-Since Linus's tree is now (you might say) fully integrated into the
-distributed BitKeeper system, there are several prerequisites to
-properly submitting a BitKeeper change.  All these prereq's are just
-general cleanliness of BK usage, so as people become experts at BK, feel
-free to optimize this process further (assuming Linus agrees, of
-course).
-0) Make sure your tree was originally cloned from the linux-2.5 tree
-created by Linus.  If your tree does not have this as its ancestor, it
-is impossible to reliably exchange changesets.
-1) Pay attention to your commit text.  The commit message that
-accompanies each changeset you submit will live on forever in history,
-and is used by Linus to accurately summarize the changes in each
-pre-patch.  Remember that there is no context, so
-        "fix for new scheduler changes"
-would be too vague, but
-        "fix mips64 arch for new scheduler switch_to(), TIF_xxx semantics"
-would be much better.
-You can and should use the command "bk comment -C<rev>" to update the
-commit text, and improve it after the fact.  This is very useful for
-development: poor, quick descriptions during development, which get
-cleaned up using "bk comment" before issuing the "bk push" to submit the
-changes.
-2) Include an Internet-available URL for Linus to pull from, such as
-        Pull from:  http://gkernel.bkbits.net/net-drivers-2.5
-3) Include a summary and "diffstat -p1" of each changeset that will be
-downloaded, when Linus issues a "bk pull".  The author auto-generates
-these summaries using "bk changes -L <parent>", to obtain a listing
-of all the pending-to-send changesets, and their commit messages.
-It is important to show Linus what he will be downloading when he issues
-a "bk pull", to reduce the time required to sift the changes once they
-are downloaded to Linus's local machine.
-IMPORTANT NOTE:  One of the features of BK is that your repository does
-not have to be up to date, in order for Linus to receive your changes.
-It is considered a courtesy to keep your repository fairly recent, to
-lessen any potential merge work Linus may need to do.
-4) Split up your changes.  Each maintainer<->Linus situation is likely
-to be slightly different here, so take this just as general advice.  The
-author splits up changes according to "themes" when merging with Linus.
-Simultaneous pushes from local development go to special trees which
-exist solely to house changes "queued" for Linus.  Example of the trees:
-        net-drivers-2.5 -- on-going net driver maintenance
-        vm-2.5 -- VM-related changes
-        fs-2.5 -- filesystem-related changes
-Linus then has much more freedom for pulling changes.  He could (for
-example) issue a "bk pull" on vm-2.5 and fs-2.5 trees, to merge their
-changes, but hold off net-drivers-2.5 because of a change that needs
-more discussion.
-Other maintainers may find that a single linus-pull-from tree is
-adequate for passing BK changesets to him.
-Frequently Answered Questions
-----------------------------
-1) How do I change the e-mail address shown in the changelog?
-A. When you run "bk citool" or "bk commit", set environment
-   variables BK_USER and BK_HOST to the desired username
-   and host/domain name.
-2) How do I use tags / get a diff between two kernel versions?
-A. Pass the tags Linus uses to 'bk export'.
-ChangeSets are in a forward-progressing order, so it's pretty easy
-to get a snapshot starting and ending at any two points in time.
-Linus puts tags on each release and pre-release, so you could use
-these two examples:
-    bk export -tpatch -hdu -rv2.5.4,v2.5.5 | less
-        # creates patch-2.5.5 essentially
-    bk export -tpatch -du -rv2.5.5-pre1,v2.5.5 | less
-        # changes from pre1 to final
-A tag is just an alias for a specific changeset... and since changesets
-are ordered, a tag is thus a marker for a specific point in time (or
-specific state of the tree).
-3) Is there an easy way to generate One Big Patch versus mainline,
-   for my long-lived kernel branch?
-A. Yes.  This requires BK 3.x, though.
-        bk export -tpatch -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+
diff --git a/Documentation/BK-usage/bk-make-sum b/Documentation/BK-usage/bk-make-sum
deleted file mode 100755
index 58ca46a0fcc6..000000000000
--- a/Documentation/BK-usage/bk-make-sum
+++ /dev/null
@@ -1,34 +0,0 @@
-#!/bin/sh -e
-# DIR=$HOME/BK/axp-2.5
-# cd $DIR
-LINUS_REPO=$1
-DIRBASE=`basename $PWD`
-{
-cat <<EOT
-Please do a
-        bk pull bk://gkernel.bkbits.net/$DIRBASE
-This will update the following files:
-EOT
-bk export -tpatch -hdu -r`bk repogca $LINUS_REPO`,+ | diffstat -p1 2>/dev/null
-cat <<EOT
-through these ChangeSets:
-EOT
-bk changes -L -d'$unless(:MERGE:){ChangeSet|:CSETREV:\n}' $LINUS_REPO |
-bk -R prs -h -d'$unless(:MERGE:){<:P:@:HOST:> (:D: :I:)\n$each(:C:){   (:C:)\n}\n}' -
-} > /tmp/linus.txt
-cat <<EOT
-Mail text in /tmp/linus.txt; please check and send using your favourite
-mailer.
-EOT
diff --git a/Documentation/BK-usage/bksend b/Documentation/BK-usage/bksend
deleted file mode 100755
index 836ca943694f..000000000000
--- a/Documentation/BK-usage/bksend
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/bin/sh
-# A script to format BK changeset output in a manner that is easy to read.
-# Andreas Dilger <adilger@turbolabs.com>  13/02/2002
-#
-# Add diffstat output after Changelog <adilger@turbolabs.com>   21/02/2002
-PROG=bksend
-usage() {
-        echo "usage: $PROG -r<rev>"
-        echo -e "\twhere <rev> is of the form '1.23', '1.23..', '1.23..1.27',"
-        echo -e "\tor '+' to indicate the most recent revision"
-        exit 1
-}
-case $1 in
-r) REV=$2; shift ;;
-r*) REV=`echo $1 | sed 's/^-r//'` ;;
-*) echo "$PROG: no revision given, you probably don't want that";;
-esac
-[ -z "$REV" ] && usage
-echo "You can import this changeset into BK by piping this whole message to:"
-echo "'| bk receive [path to repository]' or apply the patch as usual."
-SEP="\n===================================================================\n\n"
-echo -e $SEP
-env PAGER=/bin/cat bk changes -r$REV
-echo
-bk export -tpatch -du -h -r$REV | diffstat
-echo; echo
-bk export -tpatch -du -h -r$REV
-echo -e $SEP
-bk send -wgzip_uu -r$REV -
diff --git a/Documentation/BK-usage/bz64wrap b/Documentation/BK-usage/bz64wrap
deleted file mode 100755
index be780876849f..000000000000
--- a/Documentation/BK-usage/bz64wrap
+++ /dev/null
@@ -1,41 +0,0 @@
-#!/bin/sh
-# bz64wrap - the sending side of a bzip2 | base64 stream
-# Andreas Dilger <adilger@clusterfs.com>   Jan 2002
-PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin
-# A program to generate base64 encoding on stdout
-BASE64_ENCODE="uuencode -m /dev/stdout"
-BASE64_BEGIN=
-BASE64_END=
-BZIP=NO
-BASE64=NO
-# Test if we have the bzip program installed
-bzip2 -c /dev/null > /dev/null 2>&1 && BZIP=YES
-# Test if uuencode can handle the -m (MIME) encoding option
-$BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES
-if [ $BASE64 = NO ]; then
-        BASE64_ENCODE=mimencode
-        BASE64_BEGIN="begin-base64 644 -"
-        BASE64_END="===="
-        $BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES
-fi
-if [ $BZIP = NO -o $BASE64 = NO ]; then
-        echo "$0: can't use bz64 encoding: bzip2=$BZIP, $BASE64_ENCODE=$BASE64"
-        exit 1
-fi
-# Sadly, mimencode does not appear to have good "begin" and "end" markers
-# like uuencode does, and it is picky about getting the right start/end of
-# the base64 stream, so we handle this internally.
-echo "$BASE64_BEGIN"
-bzip2 -9 | $BASE64_ENCODE
-echo "$BASE64_END"
diff --git a/Documentation/BK-usage/cpcset b/Documentation/BK-usage/cpcset
deleted file mode 100755
index b8faca97dab9..000000000000
--- a/Documentation/BK-usage/cpcset
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/bin/sh
-#
-# Purpose: Copy changeset patch and description from one
-#          repository to another, unrelated one.
-#
-# usage:  cpcset [revision] [from-repository] [to-repository]
-#
-REV=$1
-FROM=$2
-TO=$3
-TMPF=/tmp/cpcset.$$
-rm -f $TMPF*
-CWD_SAVE=`pwd`
-cd $FROM
-bk changes -r$REV                       |       \
-        grep -v '^ChangeSet'            |       \
-        sed -e 's/^  //g' > $TMPF.log
-USERHOST=`bk changes -r$REV | grep '^ChangeSet' | awk '{print $4}'`
-export BK_USER=`echo $USERHOST | awk '-F@' '{print $1}'`
-export BK_HOST=`echo $USERHOST | awk '-F@' '{print $2}'`
-bk export -tpatch -hdu -r$REV > $TMPF.patch && \
-cd $CWD_SAVE && \
-cd $TO && \
-bk import -tpatch -CFR -y"`cat $TMPF.log`" $TMPF.patch . && \
-bk commit -y"`cat $TMPF.log`"
-rm -f $TMPF*
-echo changeset $REV copied.
-echo ""
diff --git a/Documentation/BK-usage/cset-to-linus b/Documentation/BK-usage/cset-to-linus
deleted file mode 100755
index d28a96f8c618..000000000000
--- a/Documentation/BK-usage/cset-to-linus
+++ /dev/null
@@ -1,49 +0,0 @@
-#!/usr/bin/perl -w
-use strict;
-my ($lhs, $rev, $tmp, $rhs, $s);
-my @cset_text = ();
-my @pipe_text = ();
-my $have_cset = 0;
-while (<>) {
-        next if /^---/;
-        if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) {
-                &cset_rev if ($have_cset);
-                $rev = $tmp;
-                $have_cset = 1;
-                push(@cset_text, $_);
-        }
-        elsif ($have_cset) {
-                push(@cset_text, $_);
-        }
-}
-&cset_rev if ($have_cset);
-exit(0);
-sub cset_rev {
-        my $empty_cset = 0;
-        open PIPE, "bk export -tpatch -hdu -r $rev | diffstat -p1 2>/dev/null |" or die;
-        while ($s = <PIPE>) {
-                $empty_cset = 1 if ($s =~ /0 files changed/);
-                push(@pipe_text, $s);
-        }
-        close(PIPE);
-        if (! $empty_cset) {
-                print @cset_text;
-                print @pipe_text;
-                print "\n\n";
-        }
-        @pipe_text = ();
-        @cset_text = ();
-}
diff --git a/Documentation/BK-usage/csets-to-patches b/Documentation/BK-usage/csets-to-patches
deleted file mode 100755
index e2b81c35883f..000000000000
--- a/Documentation/BK-usage/csets-to-patches
+++ /dev/null
@@ -1,44 +0,0 @@
-#!/usr/bin/perl -w
-use strict;
-my ($lhs, $rev, $tmp, $rhs, $s);
-my @cset_text = ();
-my @pipe_text = ();
-my $have_cset = 0;
-while (<>) {
-        next if /^---/;
-        if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) {
-                &cset_rev if ($have_cset);
-                $rev = $tmp;
-                $have_cset = 1;
-                push(@cset_text, $_);
-        }
-        elsif ($have_cset) {
-                push(@cset_text, $_);
-        }
-}
-&cset_rev if ($have_cset);
-exit(0);
-sub cset_rev {
-        my $empty_cset = 0;
-        system("bk export -tpatch -du -r $rev > /tmp/rev-$rev.patch");
-        if (! $empty_cset) {
-                print @cset_text;
-                print @pipe_text;
-                print "\n\n";
-        }
-        @pipe_text = ();
-        @cset_text = ();
-}
diff --git a/Documentation/BK-usage/gcapatch b/Documentation/BK-usage/gcapatch
deleted file mode 100755
index aaeb17dc7c7f..000000000000
--- a/Documentation/BK-usage/gcapatch
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/bin/sh
-#
-# Purpose: Generate GNU diff of local changes versus canonical top-of-tree
-#
-# Usage: gcapatch > foo.patch
-#
-bk export -tpatch -hdu -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+
diff --git a/Documentation/BK-usage/unbz64wrap b/Documentation/BK-usage/unbz64wrap
deleted file mode 100755
index 4fc3e73e9a81..000000000000
--- a/Documentation/BK-usage/unbz64wrap
+++ /dev/null
@@ -1,25 +0,0 @@
-#!/bin/sh
-# unbz64wrap - the receiving side of a bzip2 | base64 stream
-# Andreas Dilger <adilger@clusterfs.com>   Jan 2002
-# Sadly, mimencode does not appear to have good "begin" and "end" markers
-# like uuencode does, and it is picky about getting the right start/end of
-# the base64 stream, so we handle this explicitly here.
-PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin
-if mimencode -u < /dev/null > /dev/null 2>&1 ; then
-        SHOW=
-        while read LINE; do
-                case $LINE in
-                begin-base64*) SHOW=YES ;;
-                ====) SHOW= ;;
-                *) [ "$SHOW" ] && echo "$LINE" ;;
-                esac
-        done | mimencode -u | bunzip2
-        exit $?
-else
-        cat - | uudecode -o /dev/stdout | bunzip2
-        exit $?
-fi
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt
index 1ad26d2c20ae..2f8f24eaefd9 100644
--- a/Documentation/cpusets.txt
+++ b/Documentation/cpusets.txt
@@ -252,8 +252,7 @@ in a tasks processor placement.
 There is an exception to the above.  If hotplug funtionality is used
 to remove all the CPUs that are currently assigned to a cpuset,
 then the kernel will automatically update the cpus_allowed of all
-tasks attached to CPUs in that cpuset with the online CPUs of the
+tasks attached to CPUs in that cpuset to allow all CPUs.  When memory
-nearest parent cpuset that still has some CPUs online.  When memory
 hotplug functionality for removing Memory Nodes is available, a
 similar exception is expected to apply there as well.  In general,
 the kernel prefers to violate cpuset placement, over starving a task
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 7c2496426ab9..9a33bb94f74f 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -27,6 +27,7 @@
 *.so
 *.tex
 *.ver
+*.xml
 *_MODULES
 *_vga16.c
 *cscope*
@@ -110,6 +111,7 @@ mkdep
 mktables
 modpost
 modversions.h*
+offsets.h
 oui.c*
 parse.c*
 parse.h*
@@ -134,4 +136,5 @@ vmlinux-*
 vmlinux.lds
 vsyscall.lds
 wanxlfw.inc
+uImage
 zImage
diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop
new file mode 100644
index 000000000000..a50c70f9ca72
--- /dev/null
+++ b/Documentation/dvb/README.flexcop
@@ -0,0 +1,205 @@
+This README escorted the skystar2-driver rewriting procedure. It describes the
+state of the new flexcop-driver set and some internals are written down here
+too.
+This document hopefully describes things about the flexcop and its
+device-offsprings. Goal was to write an easy-to-write and easy-to-read set of
+drivers based on the skystar2.c and other information.
+Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been
+touched and rewritten.
+History & News
+==============
+  2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana)
+General coding processing
+=========================
+We should proceed as follows (as long as no one complains):
+0) Think before start writing code!
+1) rewriting the skystar2.c with the help of the flexcop register descriptions
+and splitting up the files to a pci-bus-part and a flexcop-part.
+The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the
+device-specific part and b2c2-flexcop.ko for the common flexcop-functions.
+2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c
+and other pci drivers)
+3) make some beautification (see 'Improvements when rewriting (refactoring) is
+done')
+4) Testing the new driver and maybe substitute the skystar2.c with it, to reach
+a wider tester audience.
+5) creating an usb-bus-part using the already written flexcop code for the pci
+card.
+Idea: create a kernel-object for the flexcop and export all important
+functions. This option saves kernel-memory, but maybe a lot of functions have
+to be exported to kernel namespace.
+Current situation
+=================
+0) Done :)
+1) Done (some minor issues left)
+2) Done
+3) Not ready yet, more information is necessary
+4) next to be done (see the table below)
+5) USB driver is working (yes, there are some minor issues)
+What seems to be ready?
+-----------------------
+1) Rewriting
+1a) i2c is cut off from the flexcop-pci.c and seems to work
+1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c
+1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c
+1e) eeprom (reading MAC address)
+1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me))
+1f) misc. register accesses for reading parameters (e.g. resetting, revision)
+1g) pid/mac filter (flexcop-hw-filter.c)
+1i) dvb-stuff initialization in flexcop.c (done)
+1h) dma stuff (now just using the size-irq, instead of all-together, to be done)
+1j) remove flexcop initialization from flexcop-pci.c completely (done)
+1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO')
+1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from
+non-static where possible, moved code to proper places)
+2) Search for errors in the leftover of flexcop-pci.c (partially done)
+5a) add MAC address reading
+5c) feeding of ISOC data to the software demux (format of the isochronous data
+and speed optimization, no real error) (thanks to Vadim Catana)
+What to do in the near future?
+--------------------------------------
+(no special order here)
+5) USB driver
+5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting)
+Testing changes
+---------------
+O             = item is working
+P             = item is partially working
+X             = item is not working
+N             = item does not apply here
+<empty field> = item need to be examined
+       | PCI                               | USB
+item   | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312
+-------+-------+---------+---------+-------+-------+---------+---------+-------
+1a)    | O     |         |         |       | N     | N       | N       | N
+1b)    | O     |         |         |       |       |         | O       |
+1c)    | N     | N       |         |       | N     | N       | O       |
+1d)    |                 O                 |                 O
+1e)    |                 O                 |                 O
+1f)    |                                   P
+1g)    |                                   O
+1h)    |                 P                 |
+1i)    |                 O                 |                 N
+1j)    |                 O                 |                 N
+1l)    |                 O                 |                 N
+2)     |                 O                 |                 N
+5a)    |                 N                 |                 O
+5b)*   |                 N                 |
+5c)    |                 N                 |                 O
+* - not done yet
+Known bugs and problems and TODO
+--------------------------------
+1g/h/l) when pid filtering is enabled on the pci card
+DMA usage currently:
+  The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first
+  address and triggers an IRQ when it's full and starts writing to the second
+  address. When the second address is full, the IRQ is triggered again, and
+  the flexcop writes to first address again, and so on.
+  The buffersize of each address is currently 640*188 bytes.
+  Problem is, when using hw-pid-filtering and doing some low-bandwidth
+  operation (like scanning) the buffers won't be filled enough to trigger
+  the IRQ. That's why:
+  When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ
+  is triggered.  Is the current write address of DMA1 different to the one
+  during the last IRQ, then the data is passed to the demuxer.
+  There is an additional DMA-IRQ-method: packet count IRQ. This isn't
+  implemented correctly yet.
+  The solution is to disable HW PID filtering, but I don't know how the DVB
+  API software demux behaves on slow systems with 45MBit/s TS.
+Solved bugs :)
+--------------
+1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't
+working)
+SOLUTION: also index 0 was affected, because net_translation is done for
+these indexes by default
+5b) isochronous transfer does only work in the first attempt (for the Sky2PC
+USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really
+woke up again (don't know if this need fixes, see
+flexcop-fe-tuner.c:flexcop_sleep)
+NEWS: when the driver is loaded and unloaded and loaded again (w/o doing
+anything in the while the driver is loaded the first time), no transfers take
+place anymore.
+Improvements when rewriting (refactoring) is done
+=================================================
+- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control
+  (enable sleeping for other demods than dvb-s)
+- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA)
+Debugging
+---------
+- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it
+  with this flexcop, this is important, because i2c is now using the
+  flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for
+  that, please tell us so).
+Everything which is identical in the following table, can be put into a common
+flexcop-module.
+                  PCI                  USB
+-------------------------------------------------------------------------------
+Different:
+Register access:  accessing IO memory  USB control message
+I2C bus:          I2C bus of the FC    USB control message
+Data transfer:    DMA                  isochronous transfer
+EEPROM transfer:  through i2c bus      not clear yet
+Identical:
+Streaming:                 accessing registers
+PID Filtering:             accessing registers
+Sram destinations:         accessing registers
+Tuner/Demod:                     I2C bus
+DVB-stuff:            can be written for common use
+Acknowledgements (just for the rewriting part)
+================
+Bjarne Steinsbo thought a lot in the first place of the pci part for this code
+sharing idea.
+Andreas Oberritter for providing a recent PCI initialization template
+(pluto2.c).
+Boleslaw Ciesielski for pointing out a problem with firmware loader.
+Vadim Catana for correcting the USB transfer.
+comments, critics and ideas to linux-dvb@linuxtv.org.
diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt
index e3cacf4f2345..d64430bf4bb6 100644
--- a/Documentation/dvb/bt8xx.txt
+++ b/Documentation/dvb/bt8xx.txt
@@ -17,74 +17,53 @@ Because of this, you need to enable
 "Device drivers" => "Multimedia devices"
  => "Video For Linux" => "BT848 Video For Linux"
+Furthermore you need to enable
+"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
+  => "DVB for Linux" "DVB Core Support" "Nebula/Pinnacle PCTV/TwinHan PCI Cards"
 2) Loading Modules
 ==================
 In general you need to load the bttv driver, which will handle the gpio and
-i2c communication for us. Next you need the common dvb-bt8xx device driver
+i2c communication for us, plus the common dvb-bt8xx device driver.
-and one frontend driver.
+The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and
+TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver.
-The bttv driver will HANG YOUR SYSTEM IF YOU DO NOT SPECIFY THE CORRECT 
-CARD ID!
-(If you don't get your card running and you suspect that the card id you're
-using is wrong, have a look at "bttv-cards.c" for a list of possible card
-ids.)
-Pay attention to failures when you load the frontend drivers
-(e.g. dmesg, /var/log/messages).
 3a) Nebula / Pinnacle PCTV
 --------------------------
-   $ modprobe bttv i2c_hw=1 card=0x68
+   $ modprobe bttv (normally bttv is being loaded automatically by kmod)
-   $ modprobe dvb-bt8xx
+   $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading)
-   
-For Nebula cards use the "nxt6000" frontend driver:
-   $ modprobe nxt6000
-For Pinnacle PCTV cards use the "cx24110" frontend driver:
-   $ modprobe cx24110
-3b) TwinHan
+3b) TwinHan and Clones
-----------
+--------------------------
   $ modprobe bttv i2c_hw=1 card=0x71
   $ modprobe dvb-bt8xx
   $ modprobe dst
-The value 0x71 will override the PCI type detection for dvb-bt8xx, which 
+The value 0x71 will override the PCI type detection for dvb-bt8xx,
-is necessary for TwinHan cards.#
+which  is necessary for TwinHan cards.
-If you're having an older card (blue color circuit) and card=0x71 locks your
+If you're having an older card (blue color circuit) and card=0x71 locks
-machine, try using 0x68, too. If that does not work, ask on the DVB mailing list.
+your machine, try using 0x68, too. If that does not work, ask on the
+mailing list.
-The DST module takes a couple of useful parameters, in case the
+The DST module takes a couple of useful parameters.
-dst drivers fails to detect your type of card correctly.
-dst_type takes values 0 (satellite), 1 (terrestial TV), 2 (cable).
+verbose takes values 0 to 5. These values control the verbosity level.
-dst_type_flags takes bit combined values:
+debug takes values 0 and 1. You can either disable or enable debugging.
-1 = new tuner type packets. You can use this if your card is detected
-    and you have debug and you continually see the tuner packets not
-    working (make sure not a basic problem like dish alignment etc.)
-2 = TS 204. If your card tunes OK, but the picture is terrible, seemingly
+dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card.
-    breaking up in one half continually, and crc fails a lot, then
+0x20 means it has a Conditional Access slot.
-    this is worth a try (or trying to turn off)
-4 = has symdiv. Some cards, mostly without new tuner packets, require
+The autodected values are determined bythe cards 'response
-    a symbol division algorithm. Doesn't apply to terrestial TV.
-You can also specify a value to have the autodetected values turned off
-(e.g. 0). The autodected values are determined bythe cards 'response
 string' which you can see in your logs e.g.
-dst_check_ci: recognize DST-MOT
+dst_get_device_id: Recognise [DSTMCI]
-or 
-dst_check_ci: unable to recognize DSTXCI or STXCI
 --
-Authors: Richard Walker, Jamie Honan, Michael Hunold
+Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham
diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt
new file mode 100644
index 000000000000..62e0701b542a
--- /dev/null
+++ b/Documentation/dvb/ci.txt
@@ -0,0 +1,219 @@
+* For the user
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+NOTE: This document describes the usage of the high level CI API as
+in accordance to the Linux DVB API. This is a not a documentation for the,
+existing low level CI API.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To utilize the High Level CI capabilities,
+(1*) This point is valid only for the Twinhan/clones
+  For the Twinhan/Twinhan clones, the dst_ca module handles the CI
+  hardware handling.This module is loaded automatically if a CI
+  (Common Interface, that holds the CAM (Conditional Access Module)
+  is detected.
+(2) one requires a userspace application, ca_zap. This small userland
+  application is in charge of sending the descrambling related information
+  to the CAM.
+This application requires the following to function properly as of now.
+        (a) Tune to a valid channel, with szap.
+          eg: $ szap -c channels.conf -r "TMC" -x
+        (b) a channels.conf containing a valid PMT PID
+          eg: TMC:11996:h:0:27500:278:512:650:321
+          here 278 is a valid PMT PID. the rest of the values are the
+          same ones that szap uses.
+        (c) after running a szap, you have to run ca_zap, for the
+          descrambler to function,
+          eg: $ ca_zap patched_channels.conf "TMC"
+          The patched means a patch to apply to scan, such that scan can
+          generate a channels.conf_with pmt, which has this PMT PID info
+          (NOTE: szap cannot use this channels.conf with the PMT_PID)
+        (d) Hopeflly Enjoy your favourite subscribed channel as you do with
+          a FTA card.
+(3) Currently ca_zap, and dst_test, both are meant for demonstration
+  purposes only, they can become full fledged applications if necessary.
+* Cards that fall in this category
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+At present the cards that fall in this category are the Twinhan and it's
+clones, these cards are available as VVMER, Tomato, Hercules, Orange and
+so on.
+* CI modules that are supported
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The CI module support is largely dependant upon the firmware on the cards
+Some cards do support almost all of the available CI modules. There is
+nothing much that can be done in order to make additional CI modules
+working with these cards.
+Modules that have been tested by this driver at present are
+(1) Irdeto 1 and 2 from SCM
+(2) Viaccess from SCM
+(3) Dragoncam
+* The High level CI API
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* For the programmer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+With the High Level CI approach any new card with almost any random
+architecture can be implemented with this style, the definitions
+insidethe switch statement can be easily adapted for any card, thereby
+eliminating the need for any additional ioctls.
+The disadvantage is that the driver/hardware has to manage the rest. For
+the application programmer it would be as simple as sending/receiving an
+array to/from the CI ioctls as defined in the Linux DVB API. No changes
+have been made in the API to accomodate this feature.
+* Why the need for another CI interface ?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This is one of the most commonly asked question. Well a nice question.
+Strictly speaking this is not a new interface.
+The CI interface is defined in the DVB API in ca.h as
+typedef struct ca_slot_info {
+        int num;               /* slot number */
+        int type;              /* CA interface this slot supports */
+#define CA_CI            1     /* CI high level interface */
+#define CA_CI_LINK       2     /* CI link layer level interface */
+#define CA_CI_PHYS       4     /* CI physical layer level interface */
+#define CA_DESCR         8     /* built-in descrambler */
+#define CA_SC          128     /* simple smart card interface */
+        unsigned int flags;
+#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */
+#define CA_CI_MODULE_READY   2
+} ca_slot_info_t;
+This CI interface follows the CI high level interface, which is not
+implemented by most applications. Hence this area is revisited.
+This CI interface is quite different in the case that it tries to
+accomodate all other CI based devices, that fall into the other categories
+This means that this CI interface handles the EN50221 style tags in the
+Application layer only and no session management is taken care of by the
+application. The driver/hardware will take care of all that.
+This interface is purely an EN50221 interface exchanging APDU's. This
+means that no session management, link layer or a transport layer do
+exist in this case in the application to driver communication. It is
+as simple as that. The driver/hardware has to take care of that.
+With this High Level CI interface, the interface can be defined with the
+regular ioctls.
+All these ioctls are also valid for the High level CI interface
+#define CA_RESET          _IO('o', 128)
+#define CA_GET_CAP        _IOR('o', 129, ca_caps_t)
+#define CA_GET_SLOT_INFO  _IOR('o', 130, ca_slot_info_t)
+#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t)
+#define CA_GET_MSG        _IOR('o', 132, ca_msg_t)
+#define CA_SEND_MSG       _IOW('o', 133, ca_msg_t)
+#define CA_SET_DESCR      _IOW('o', 134, ca_descr_t)
+#define CA_SET_PID        _IOW('o', 135, ca_pid_t)
+On querying the device, the device yields information thus
+CA_GET_SLOT_INFO
+----------------------------
+Command = [info]
+APP: Number=[1]
+APP: Type=[1]
+APP: flags=[1]
+APP: CI High level interface
+APP: CA/CI Module Present
+CA_GET_CAP
+----------------------------
+Command = [caps]
+APP: Slots=[1]
+APP: Type=[1]
+APP: Descrambler keys=[16]
+APP: Type=[1]
+CA_SEND_MSG
+----------------------------
+Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1]
+Found CA descriptor @ program level
+(20) ES type=[2] ES pid=[201]  ES length =[0 (0x0)]
+(25) ES type=[4] ES pid=[301]  ES length =[0 (0x0)]
+ca_message length is 25 (0x19) bytes
+EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00]
+Not all ioctl's are implemented in the driver from the API, the other
+features of the hardware that cannot be implemented by the API are achieved
+using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is
+used to exchange the data to maintain compatibility with other hardware.
+/* a message to/from a CI-CAM */
+typedef struct ca_msg {
+        unsigned int index;
+        unsigned int type;
+        unsigned int length;
+        unsigned char msg[256];
+} ca_msg_t;
+The flow of data can be described thus,
+        App (User)
+        -----
+        parse
+          |
+          |
+          v
+        en50221 APDU (package)
+   --------------------------------------
+   |      |                             | High Level CI driver
+   |      |                             |
+   |      v                             |
+   |    en50221 APDU (unpackage)        |
+   |      |                             |
+   |      |                             |
+   |      v                             |
+   |    sanity checks                   |
+   |      |                             |
+   |      |                             |
+   |      v                             |
+   |    do (H/W dep)                    |
+   --------------------------------------
+          |    Hardware
+          |
+          v
+The High Level CI interface uses the EN50221 DVB standard, following a
+standard ensures futureproofness.
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 3ffdcb394299..a750f0101d9d 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -107,7 +107,7 @@ sub tda10045 {
 sub tda10046 {
    my $sourcefile = "tt_budget_217g.zip";
    my $url = "http://www.technotrend.de/new/217g/$sourcefile";
-    my $hash = "a25b579e37109af60f4a36c37893957c";
+    my $hash = "6a7e1e2f2644b162ff0502367553c72d";
    my $outfile = "dvb-fe-tda10046.fw";
    my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
@@ -115,7 +115,7 @@ sub tda10046 {
    wgetfile($sourcefile, $url);
    unzip($sourcefile, $tmpdir);
-    extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24479, "$tmpdir/fwtmp");
+    extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp");
    verify("$tmpdir/fwtmp", $hash);
    copy("$tmpdir/fwtmp", $outfile);
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index d3c52dd24a2a..b9eb209318ab 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -63,3 +63,23 @@ Why:	Outside of Linux, the only implementations of anything even
        people, who might be using implementations that I am not aware
        of, to adjust to this upcoming change.
 Who:    Paul E. McKenney <paulmck@us.ibm.com>
+---------------------------
+What:   IEEE1394 Audio and Music Data Transmission Protocol driver,
+        Connection Management Procedures driver
+When:   November 2005
+Files:  drivers/ieee1394/{amdtp,cmp}*
+Why:    These are incomplete, have never worked, and are better implemented
+        in userland via raw1394 (see http://freebob.sourceforge.net/ for
+        example.)
+Who:    Jody McIntyre <scjody@steamballoon.com>
+---------------------------
+What:   raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
+When:   November 2005
+Why:    Deprecated in favour of the new ioctl-based rawiso interface, which is
+        more efficient.  You should really be using libraw1394 for raw1394
+        access anyway.
+Who:    Jody McIntyre <scjody@steamballoon.com>
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
index e97d024eae77..988a62fae11f 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -7,7 +7,6 @@ that support it.  For example, a given bus might look like this:
     |-- 0000:17:00.0
     |   |-- class
     |   |-- config
-     |   |-- detach_state
     |   |-- device
     |   |-- irq
     |   |-- local_cpus
@@ -19,7 +18,7 @@ that support it.  For example, a given bus might look like this:
     |   |-- subsystem_device
     |   |-- subsystem_vendor
     |   `-- vendor
-     `-- detach_state
+     `-- ...
 The topmost element describes the PCI domain and bus number.  In this case,
 the domain number is 0000 and the bus number is 17 (both values are in hex).
@@ -31,7 +30,6 @@ files, each with their own function.
       ----                --------
       class               PCI class (ascii, ro)
       config              PCI config space (binary, rw)
-       detach_state        connection status (bool, rw)
       device              PCI device (ascii, ro)
       irq                 IRQ number (ascii, ro)
       local_cpus          nearby CPU mask (cpumask, ro)
@@ -85,4 +83,4 @@ useful return codes should be provided.
 Legacy resources are protected by the HAVE_PCI_LEGACY define.  Platforms
 wishing to support legacy functionality should define it and provide
-pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions.
-\ No newline at end of file
+pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions.
diff --git a/Documentation/networking/DLINK.txt b/Documentation/networking/DLINK.txt
index 083d24752b83..55d24433d151 100644
--- a/Documentation/networking/DLINK.txt
+++ b/Documentation/networking/DLINK.txt
@@ -178,10 +178,9 @@ Released 1994-06-13
        7. ACKNOWLEDGMENTS.
        These drivers wouldn't have been done without the base
-        (and support) from Ross Biro <bir7@leland.stanford.edu>,
+        (and support) from Ross Biro, and D-Link Systems Inc.
-        and D-Link Systems Inc.  The driver relies upon GPL-ed
+        The driver relies upon GPL-ed source from D-Link Systems Inc.
-        source from D-Link Systems Inc. and from Russel Nelson at
+        and from Russel Nelson at Crynwr Software <nelson@crynwr.com>.
-        Crynwr Software <nelson@crynwr.com>.
        Additional input also from:
        Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk>
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 5d4ae9a39f1d..f987afe43e28 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -207,27 +207,6 @@ SYSTEM_SHUTDOWN, I do not understand this one too much. probably event
 #READY_AFTER_RESUME
 #
-Driver Detach Power Management
-The kernel now supports the ability to place a device in a low-power
-state when it is detached from its driver, which happens when its
-module is removed. 
-Each device contains a 'detach_state' file in its sysfs directory
-which can be used to control this state. Reading from this file
-displays what the current detach state is set to. This is 0 (On) by
-default. A user may write a positive integer value to this file in the
-range of 1-4 inclusive. 
-A value of 1-3 will indicate the device should be placed in that
-low-power state, which will cause ->suspend() to be called for that
-device. A value of 4 indicates that the device should be shutdown, so
->shutdown() will be called for that device. 
-The driver is responsible for reinitializing the device when the
-module is re-inserted during it's ->probe() (or equivalent) method. 
-The driver core will not call any extra functions when binding the
-device to the driver. 
 pm_message_t meaning
diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt
index c0a62e116e6e..dca75cbda6f8 100644
--- a/Documentation/powerpc/hvcs.txt
+++ b/Documentation/powerpc/hvcs.txt
@@ -347,8 +347,8 @@ address that is created by firmware.  An example vty-server sysfs entry
 looks like the following:
        Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls
-        .   current_vty   devspec  name          partner_vtys
+        .   current_vty   devspec       name          partner_vtys
-        ..  detach_state  index    partner_clcs  vterm_state
+        ..  index         partner_clcs  vterm_state
 Each entry is provided, by default with a "name" attribute.  Reading the
 "name" attribute will reveal the device type as shown in the following
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index 44b6eea60ece..b9e6be00cadf 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -25,6 +25,9 @@ APICs
   noapictimer   Don't set up the APIC timer
+   no_timer_check Don't check the IO-APIC timer. This can work around
+                 problems with incorrect timer initialization on some boards.
 Early Console
   syntax: earlyprintk=vga