diff --git a/CREDITS b/CREDITS --- a/CREDITS +++ b/CREDITS @@ -34,8 +34,9 @@ N: Dave Airlie E: airlied@linux.ie W: http://www.csn.ul.ie/~airlied D: NFS over TCP patches -S: University of Limerick -S: Ireland +D: in-kernel DRM Maintainer +S: Longford, Ireland +S: Sydney, Australia N: Tigran A. Aivazian E: tigran@veritas.com @@ -328,8 +329,6 @@ S: Brimson, MN 55602 S: USA N: Hennus Bergman -E: hennus@cybercomm.nl -W: http://www.cybercomm.nl/~hennus/ P: 1024/77D50909 76 99 FD 31 91 E1 96 1C 90 BB 22 80 62 F6 BD 63 D: Author and maintainer of the QIC-02 tape driver S: The Netherlands @@ -340,7 +339,7 @@ W: http://tomas.nocrew.org/ D: dsp56k device driver N: Ross Biro -E: bir7@leland.Stanford.Edu +E: ross.biro@gmail.com D: Original author of the Linux networking code N: Anton Blanchard @@ -841,6 +840,11 @@ E: cort@fsmlabs.com W: http://www.fsmlabs.com/linuxppcbk.html D: PowerPC +N: Daniel Drake +E: dsd@gentoo.org +D: USBAT02 CompactFlash support in usb-storage +S: UK + N: Oleg Drokin E: green@ccssu.crimea.ua W: http://www.ccssu.crimea.ua/~green @@ -878,13 +882,12 @@ S: Blacksburg, Virginia 24061 S: USA N: Randy Dunlap -E: rddunlap@osdl.org +E: rdunlap@xenotime.net W: http://www.xenotime.net/linux/linux.html W: http://www.linux-usb.org D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers D: x86 SMP, ACPI, bootflag hacking -S: 12725 SW Millikan Way, Suite 400 -S: Beaverton, Oregon 97005 +S: (ask for current address) S: USA N: Bob Dunlop @@ -1095,7 +1098,7 @@ S: Brazil N: Kumar Gala E: kumar.gala@freescale.com -D: Embedded PowerPC 6xx/7xx/74xx/82xx/85xx support +D: Embedded PowerPC 6xx/7xx/74xx/82xx/83xx/85xx support S: Austin, Texas 78729 S: USA @@ -1954,7 +1957,8 @@ S: Germany N: Colin Leroy E: colin@colino.net W: http://www.geekounet.org/ -D: PowerMac adt7467 fan driver +D: PowerMac adt746x fan driver +D: Random fixing of various drivers (macintosh, usb, sound) S: Toulouse S: France @@ -2471,13 +2475,9 @@ S: Potsdam, New York 13676 S: USA N: Dave Neuer -E: dneuer@innovation-charter.com -E: mr_fred_smoothie@yahoo.com +E: dave.neuer@pobox.com D: Helped implement support for Compaq's H31xx series iPAQs D: Other mostly minor tweaks & bugfixes -S: 325 E. Main St., Suite 3 -S: Carnegie, PA 15105 -S: USA N: Michael Neuffer E: mike@i-Connect.Net @@ -3294,6 +3294,7 @@ D: Author of the new e2fsck D: Author of job control and system call restart code D: Author of ramdisk device driver D: Author of loopback device driver +D: Author of /dev/random driver S: MIT Room E40-343 S: 1 Amherst Street S: Cambridge, Massachusetts 02139 @@ -3351,10 +3352,11 @@ S: Santa Clara, CA 95054 S: USA N: Matthias Urlichs -E: urlichs@noris.de -E: urlichs@smurf.sub.org +E: smurf@smurf.noris.de +E: smurf@debian.org +E: matthias@urlichs.de D: Consultant, developer, kernel hacker -D: Playing with Streams, ISDN, and BSD networking code for Linux +D: In a previous life, worked on Streams/ISDN/BSD networking code for Linux S: Schleiermacherstrasse 12 S: 90491 Nuernberg S: Germany @@ -3426,6 +3428,7 @@ N: Jeroen Vreeken E: pe1rxq@amsat.org W: http://www.chello.nl/~j.vreeken/ D: SE401 usb webcam driver +D: ZD1201 usb wireless lan driver S: Maastrichterweg 63 S: 5554 GG Valkenswaard S: The Netherlands diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -12,8 +12,6 @@ Following translations are available on 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 --- 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 --- 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 " or in X "bk helptool " 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" 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 ", 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 --- 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 </dev/null - -cat < (:D: :I:)\n$each(:C:){ (:C:)\n}\n}' - - -} > /tmp/linus.txt - -cat < 13/02/2002 -# -# Add diffstat output after Changelog 21/02/2002 - -PROG=bksend - -usage() { - echo "usage: $PROG -r" - echo -e "\twhere 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 -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 --- a/Documentation/BK-usage/bz64wrap +++ /dev/null @@ -1,41 +0,0 @@ -#!/bin/sh - -# bz64wrap - the sending side of a bzip2 | base64 stream -# Andreas Dilger 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 --- 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 --- 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 = ) { - $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 --- 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 --- 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 --- a/Documentation/BK-usage/unbz64wrap +++ /dev/null @@ -1,25 +0,0 @@ -#!/bin/sh - -# unbz64wrap - the receiving side of a bzip2 | base64 stream -# Andreas Dilger 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/Changes b/Documentation/Changes --- a/Documentation/Changes +++ b/Documentation/Changes @@ -339,7 +339,7 @@ o +o Reiserfsprogs ------------- @@ -357,14 +357,14 @@ Quota-tools ---------- o -Jade ----- -o - DocBook Stylesheets ------------------- o +XMLTO XSLT Frontend +------------------- +o + Intel P6 microcode ------------------ o diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt @@ -443,15 +443,9 @@ Only streaming mappings specify a direct implicitly have a direction attribute setting of PCI_DMA_BIDIRECTIONAL. -The SCSI subsystem provides mechanisms for you to easily obtain -the direction to use, in the SCSI command: - - scsi_to_pci_dma_dir(SCSI_DIRECTION) - -Where SCSI_DIRECTION is obtained from the 'sc_data_direction' -member of the SCSI command your driver is working on. The -mentioned interface above returns a value suitable for passing -into the streaming DMA mapping interfaces below. +The SCSI subsystem tells you the direction to use in the +'sc_data_direction' member of the SCSI command your driver is +working on. For Networking drivers, it's a rather simple affair. For transmit packets, map/unmap them with the PCI_DMA_TODEVICE direction diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -6,56 +6,58 @@ # To add a new book the only step required is to add the book to the # list of DOCBOOKS. -DOCBOOKS := wanbook.sgml z8530book.sgml mcabook.sgml videobook.sgml \ - kernel-hacking.sgml kernel-locking.sgml via-audio.sgml \ - deviceiobook.sgml procfs-guide.sgml tulip-user.sgml \ - writing_usb_driver.sgml scsidrivers.sgml sis900.sgml \ - kernel-api.sgml journal-api.sgml lsm.sgml usb.sgml \ - gadget.sgml libata.sgml mtdnand.sgml librs.sgml +DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ + kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ + procfs-guide.xml writing_usb_driver.xml scsidrivers.xml \ + sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \ + gadget.xml libata.xml mtdnand.xml librs.xml ### # The build process is as follows (targets): -# (sgmldocs) -# file.tmpl --> file.sgml +--> file.ps (psdocs) -# +--> file.pdf (pdfdocs) -# +--> DIR=file (htmldocs) -# +--> man/ (mandocs) +# (xmldocs) +# file.tmpl --> file.xml +--> file.ps (psdocs) +# +--> file.pdf (pdfdocs) +# +--> DIR=file (htmldocs) +# +--> man/ (mandocs) ### # The targets that may be used. -.PHONY: sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs +.PHONY: xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) -sgmldocs: $(BOOKS) +xmldocs: $(BOOKS) +sgmldocs: xmldocs -PS := $(patsubst %.sgml, %.ps, $(BOOKS)) +PS := $(patsubst %.xml, %.ps, $(BOOKS)) psdocs: $(PS) -PDF := $(patsubst %.sgml, %.pdf, $(BOOKS)) +PDF := $(patsubst %.xml, %.pdf, $(BOOKS)) pdfdocs: $(PDF) -HTML := $(patsubst %.sgml, %.html, $(BOOKS)) +HTML := $(patsubst %.xml, %.html, $(BOOKS)) htmldocs: $(HTML) -MAN := $(patsubst %.sgml, %.9, $(BOOKS)) +MAN := $(patsubst %.xml, %.9, $(BOOKS)) mandocs: $(MAN) installmandocs: mandocs - $(MAKEMAN) install Documentation/DocBook/man + mkdir -p /usr/local/man/man9/ + install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/ ### #External programs used KERNELDOC = scripts/kernel-doc DOCPROC = scripts/basic/docproc -SPLITMAN = $(PERL) $(srctree)/scripts/split-man -MAKEMAN = $(PERL) $(srctree)/scripts/makeman + +XMLTOFLAGS = -m Documentation/DocBook/stylesheet.xsl +#XMLTOFLAGS += --skip-validation ### # DOCPROC is used for two purposes: # 1) To generate a dependency list for a .tmpl file # 2) To preprocess a .tmpl file and call kernel-doc with # appropriate parameters. -# The following rules are used to generate the .sgml documentation +# The following rules are used to generate the .xml documentation # required to generate the final targets. (ps, pdf, html). quiet_cmd_docproc = DOCPROC $@ cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@ @@ -69,7 +71,7 @@ define rule_docproc ) > $(dir $@).$(notdir $@).cmd endef -%.sgml: %.tmpl FORCE +%.xml: %.tmpl FORCE $(call if_changed_rule,docproc) ### @@ -87,53 +89,52 @@ $(BOOKS): $(KERNELDOC) ### # procfs guide uses a .c file as example code. # This requires an explicit dependency -C-procfs-example = procfs_example.sgml +C-procfs-example = procfs_example.xml C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example)) -$(obj)/procfs-guide.sgml: $(C-procfs-example2) +$(obj)/procfs-guide.xml: $(C-procfs-example2) ### # Rules to generate postscript, PDF and HTML # db2html creates a directory. Generate a html file used for timestamp -quiet_cmd_db2ps = DB2PS $@ - cmd_db2ps = db2ps -o $(dir $@) $< -%.ps : %.sgml - @(which db2ps > /dev/null 2>&1) || \ - (echo "*** You need to install DocBook stylesheets ***"; \ +quiet_cmd_db2ps = XMLTO $@ + cmd_db2ps = xmlto ps $(XMLTOFLAGS) -o $(dir $@) $< +%.ps : %.xml + @(which xmlto > /dev/null 2>&1) || \ + (echo "*** You need to install xmlto ***"; \ exit 1) $(call cmd,db2ps) -quiet_cmd_db2pdf = DB2PDF $@ - cmd_db2pdf = db2pdf -o $(dir $@) $< -%.pdf : %.sgml - @(which db2pdf > /dev/null 2>&1) || \ - (echo "*** You need to install DocBook stylesheets ***"; \ +quiet_cmd_db2pdf = XMLTO $@ + cmd_db2pdf = xmlto pdf $(XMLTOFLAGS) -o $(dir $@) $< +%.pdf : %.xml + @(which xmlto > /dev/null 2>&1) || \ + (echo "*** You need to install xmlto ***"; \ exit 1) $(call cmd,db2pdf) -quiet_cmd_db2html = DB2HTML $@ - cmd_db2html = db2html -o $(patsubst %.html,%,$@) $< && \ - echo ' \ +quiet_cmd_db2html = XMLTO $@ + cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ + echo ' \ Goto $(patsubst %.html,%,$(notdir $@))

' > $@ -%.html: %.sgml - @(which db2html > /dev/null 2>&1) || \ - (echo "*** You need to install DocBook stylesheets ***"; \ +%.html: %.xml + @(which xmlto > /dev/null 2>&1) || \ + (echo "*** You need to install xmlto ***"; \ exit 1) @rm -rf $@ $(patsubst %.html,%,$@) $(call cmd,db2html) @if [ ! -z "$(PNG-$(basename $(notdir $@)))" ]; then \ cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi -### -# Rule to generate man files - output is placed in the man subdirectory - -%.9: %.sgml -ifneq ($(KBUILD_SRC),) - $(Q)mkdir -p $(objtree)/Documentation/DocBook/man -endif - $(SPLITMAN) $< $(objtree)/Documentation/DocBook/man "$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)" - $(MAKEMAN) convert $(objtree)/Documentation/DocBook/man $< +quiet_cmd_db2man = XMLTO $@ + cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi +%.9 : %.xml + @(which xmlto > /dev/null 2>&1) || \ + (echo "*** You need to install xmlto ***"; \ + exit 1) + $(call cmd,db2man) + @touch $@ ### # Rules to generate postscripts and PNG imgages from .fig format files @@ -156,8 +157,8 @@ quiet_cmd_fig2png = FIG2PNG $@ $(call cmd,fig2png) ### -# Rule to convert a .c file to inline SGML documentation -%.sgml: %.c +# Rule to convert a .c file to inline XML documentation +%.xml: %.c @echo ' GEN $@' @( \ echo ""; \ @@ -171,24 +172,24 @@ quiet_cmd_fig2png = FIG2PNG $@ # Help targets as used by the top-level makefile dochelp: @echo ' Linux kernel internal documentation in different formats:' - @echo ' sgmldocs (SGML), psdocs (Postscript), pdfdocs (PDF)' + @echo ' xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)' @echo ' htmldocs (HTML), mandocs (man pages, use installmandocs to install)' ### # Temporary files left by various tools clean-files := $(DOCBOOKS) \ - $(patsubst %.sgml, %.dvi, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.aux, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.tex, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.log, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.out, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.ps, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.pdf, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.html, $(DOCBOOKS)) \ - $(patsubst %.sgml, %.9, $(DOCBOOKS)) \ + $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ + $(patsubst %.xml, %.aux, $(DOCBOOKS)) \ + $(patsubst %.xml, %.tex, $(DOCBOOKS)) \ + $(patsubst %.xml, %.log, $(DOCBOOKS)) \ + $(patsubst %.xml, %.out, $(DOCBOOKS)) \ + $(patsubst %.xml, %.ps, $(DOCBOOKS)) \ + $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ + $(patsubst %.xml, %.html, $(DOCBOOKS)) \ + $(patsubst %.xml, %.9, $(DOCBOOKS)) \ $(C-procfs-example) -clean-dirs := $(patsubst %.sgml,%,$(DOCBOOKS)) +clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) #man put files in man subdir - traverse down subdir- := man/ diff --git a/Documentation/DocBook/deviceiobook.tmpl b/Documentation/DocBook/deviceiobook.tmpl --- a/Documentation/DocBook/deviceiobook.tmpl +++ b/Documentation/DocBook/deviceiobook.tmpl @@ -1,4 +1,6 @@ - + + diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl @@ -1,4 +1,7 @@ - + + + USB Gadget API for Linux diff --git a/Documentation/DocBook/journal-api.tmpl b/Documentation/DocBook/journal-api.tmpl --- a/Documentation/DocBook/journal-api.tmpl +++ b/Documentation/DocBook/journal-api.tmpl @@ -1,4 +1,7 @@ - + + + The Linux Journalling API diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -1,4 +1,7 @@ - + + + The Linux Kernel API @@ -46,13 +49,33 @@ !Iinclude/asm-i386/unaligned.h - + + Kernel objects manipulation + +!Elib/kobject.c + + + Kernel utility functions +!Iinclude/linux/kernel.h + +!Ekernel/panic.c +!Ekernel/sys.c +!Ekernel/rcupdate.c + + @@ -78,7 +101,9 @@ KAO --> !Elib/vsprintf.c String Manipulation -!Ilib/string.c + !Elib/string.c Bit Operations @@ -95,6 +120,33 @@ KAO --> !Iinclude/asm-i386/uaccess.h !Iarch/i386/lib/usercopy.c + More Memory Management Functions +!Iinclude/linux/rmap.h +!Emm/readahead.c +!Emm/filemap.c +!Emm/memory.c +!Emm/vmalloc.c +!Emm/mempool.c +!Emm/page-writeback.c +!Emm/truncate.c + + + + + + Kernel IPC facilities + + IPC utilities +!Iipc/util.c + + + + + FIFO Buffer + kfifo interface +!Iinclude/linux/kfifo.h +!Ekernel/kfifo.c + @@ -103,6 +155,10 @@ KAO --> sysctl interface !Ekernel/sysctl.c + + proc filesystem interface +!Ifs/proc/base.c + @@ -116,6 +172,10 @@ KAO --> The Linux VFS + The Filesystem types +!Iinclude/linux/fs.h +!Einclude/linux/fs.h + The Directory Cache !Efs/dcache.c !Iinclude/linux/dcache.h @@ -131,13 +191,31 @@ KAO --> !Efs/locks.c !Ifs/locks.c + Other Functions +!Efs/mpage.c +!Efs/namei.c +!Efs/buffer.c +!Efs/bio.c +!Efs/seq_file.c +!Efs/filesystems.c +!Efs/fs-writeback.c +!Efs/block_dev.c + Linux Networking + Networking Base Types +!Iinclude/linux/net.h + Socket Buffer Functions !Iinclude/linux/skbuff.h +!Iinclude/net/sock.h +!Enet/socket.c !Enet/core/skbuff.c +!Enet/core/sock.c +!Enet/core/datagram.c +!Enet/core/stream.c Socket Filter !Enet/core/filter.c @@ -147,6 +225,14 @@ KAO --> !Enet/core/gen_stats.c !Enet/core/gen_estimator.c + SUN RPC subsystem + +!Enet/sunrpc/xdr.c +!Enet/sunrpc/svcsock.c +!Enet/sunrpc/sched.c + @@ -183,11 +269,26 @@ X!Ekernel/module.c !Iarch/i386/kernel/irq.c + Resources Management +!Ekernel/resource.c + + MTRR Handling !Earch/i386/kernel/cpu/mtrr/main.c PCI Support Library !Edrivers/pci/pci.c +!Edrivers/pci/pci-driver.c +!Edrivers/pci/remove.c +!Edrivers/pci/pci-acpi.c + +!Edrivers/pci/msi.c +!Edrivers/pci/bus.c +!Edrivers/pci/hotplug.c +!Edrivers/pci/probe.c +!Edrivers/pci/rom.c PCI Hotplug Support Library !Edrivers/pci/hotplug/pci_hotplug_core.c @@ -212,6 +313,14 @@ X!Earch/i386/kernel/mca.c !Efs/devfs/base.c + + The Filesystem for Exporting Kernel Objects +!Efs/sysfs/file.c +!Efs/sysfs/dir.c +!Efs/sysfs/symlink.c +!Efs/sysfs/bin.c + + Security Framework !Esecurity/security.c @@ -222,6 +331,61 @@ X!Earch/i386/kernel/mca.c !Ekernel/power/pm.c + + Device drivers infrastructure + Device Drivers Base + +!Edrivers/base/driver.c +!Edrivers/base/class_simple.c +!Edrivers/base/core.c +!Edrivers/base/firmware_class.c +!Edrivers/base/transport_class.c +!Edrivers/base/dmapool.c + +!Edrivers/base/sys.c + +!Edrivers/base/platform.c +!Edrivers/base/bus.c + + Device Drivers Power Management +!Edrivers/base/power/main.c +!Edrivers/base/power/resume.c +!Edrivers/base/power/suspend.c + + Device Drivers ACPI Support + +!Edrivers/acpi/scan.c + + + Device drivers PnP support +!Edrivers/pnp/core.c + +!Edrivers/pnp/card.c +!Edrivers/pnp/driver.c +!Edrivers/pnp/manager.c +!Edrivers/pnp/support.c + + + + Block Devices !Edrivers/block/ll_rw_blk.c @@ -239,7 +403,23 @@ X!Earch/i386/kernel/mca.c Sound Devices +!Iinclude/sound/core.h !Esound/sound_core.c +!Iinclude/sound/pcm.h +!Esound/core/pcm.c +!Esound/core/device.c +!Esound/core/info.c +!Esound/core/rawmidi.c +!Esound/core/sound.c +!Esound/core/memory.c +!Esound/core/pcm_memory.c +!Esound/core/init.c +!Esound/core/isadma.c +!Esound/core/control.c +!Esound/core/pcm_lib.c +!Esound/core/hwdep.c +!Esound/core/pcm_native.c +!Esound/core/memalloc.c @@ -247,6 +427,7 @@ X!Isound/sound_firmware.c 16x50 UART Driver +!Iinclude/linux/serial_core.h !Edrivers/serial/serial_core.c !Edrivers/serial/8250.c @@ -299,9 +480,11 @@ X!Isound/sound_firmware.c Frame Buffer Memory !Edrivers/video/fbmem.c + Frame Buffer Colormap !Edrivers/video/fbcmap.c diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -1,4 +1,6 @@ - + + diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1,4 +1,6 @@ - + + @@ -236,12 +238,12 @@ your task will put itself on the queue, and be woken up when the semaphore is released. This means the CPU will do something else while you are waiting, but there are many cases when you - simply can't sleep (see ), and so + simply can't sleep (see ), and so have to use a spinlock instead. Neither type of lock is recursive: see - . + . @@ -326,7 +328,7 @@ Note that you can also use spin_lock_irq() or spin_lock_irqsave() here, which stop - hardware interrupts as well: see . + hardware interrupts as well: see . @@ -403,7 +405,7 @@ The same softirq can run on the other CPUs: you can use a - per-CPU array (see ) for better + per-CPU array (see ) for better performance. If you're going so far as to use a softirq, you probably care about scalable performance enough to justify the extra complexity. @@ -545,120 +547,120 @@ Table of Locking Requirements - - - - -IRQ Handler A -IRQ Handler B -Softirq A -Softirq B -Tasklet A -Tasklet B -Timer A -Timer B -User Context A -User Context B - - - -IRQ Handler A -None - - - -IRQ Handler B -spin_lock_irqsave -None - - - -Softirq A -spin_lock_irq -spin_lock_irq -spin_lock - - - -Softirq B -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock - - - -Tasklet A -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock -None - - - -Tasklet B -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock -spin_lock -None - - - -Timer A -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock -spin_lock -spin_lock -None - - - -Timer B -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock -spin_lock -spin_lock -spin_lock -None - - - -User Context A -spin_lock_irq -spin_lock_irq -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -None - - - -User Context B -spin_lock_irq -spin_lock_irq -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -down_interruptible -None - - - - -
+ + + + +IRQ Handler A +IRQ Handler B +Softirq A +Softirq B +Tasklet A +Tasklet B +Timer A +Timer B +User Context A +User Context B + + + +IRQ Handler A +None + + + +IRQ Handler B +spin_lock_irqsave +None + + + +Softirq A +spin_lock_irq +spin_lock_irq +spin_lock + + + +Softirq B +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock + + + +Tasklet A +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock +None + + + +Tasklet B +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock +spin_lock +None + + + +Timer A +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock +spin_lock +spin_lock +None + + + +Timer B +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock +spin_lock +spin_lock +spin_lock +None + + + +User Context A +spin_lock_irq +spin_lock_irq +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +None + + + +User Context B +spin_lock_irq +spin_lock_irq +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +down_interruptible +None + + + + + diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -1,4 +1,6 @@ - + + @@ -12,7 +14,7 @@ - 2003 + 2003-2005 Jeff Garzik @@ -42,30 +44,38 @@ - - Thanks + + Introduction - The bulk of the ATA knowledge comes thanks to long conversations with - Andre Hedrick (www.linux-ide.org). + libATA is a library used inside the Linux kernel to support ATA host + controllers and devices. libATA provides an ATA driver API, class + transports for ATA and ATAPI devices, and SCSI<->ATA translation + for ATA devices according to the T10 SAT specification. - Thanks to Alan Cox for pointing out similarities - between SATA and SCSI, and in general for motivation to hack on - libata. - - - libata's device detection - method, ata_pio_devchk, and in general all the early probing was - based on extensive study of Hale Landis's probe/reset code in his - ATADRVR driver (www.ata-atapi.com). + This Guide documents the libATA driver API, library functions, library + internals, and a couple sample ATA low-level drivers. libata Driver API + + struct ata_port_operations is defined for every low-level libata + hardware driver, and it controls how the low-level driver + interfaces with the ATA and SCSI layers. + + + FIS-based drivers will hook into the system with ->qc_prep() and + ->qc_issue() high-level hooks. Hardware which behaves in a manner + similar to PCI IDE hardware may utilize several generic helpers, + defining at a bare minimum the bus I/O addresses of the ATA shadow + register blocks. + struct ata_port_operations + Disable ATA port void (*port_disable) (struct ata_port *); @@ -76,6 +86,9 @@ void (*port_disable) (struct ata_port *) unplug). + + + Post-IDENTIFY device configuration void (*dev_config) (struct ata_port *, struct ata_device *); @@ -86,6 +99,9 @@ void (*dev_config) (struct ata_port *, s issue of SET FEATURES - XFER MODE, and prior to operation. + + + Set PIO/DMA mode void (*set_piomode) (struct ata_port *, struct ata_device *); void (*set_dmamode) (struct ata_port *, struct ata_device *); @@ -106,6 +122,9 @@ void (*post_set_mode) (struct ata_port * ->set_dma_mode() is only called if DMA is possible. + + + Taskfile read/write void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf); void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); @@ -118,6 +137,9 @@ void (*tf_read) (struct ata_port *ap, st taskfile register values. + + + ATA command execute void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); @@ -127,17 +149,37 @@ void (*exec_command)(struct ata_port *ap ->tf_load(), to be initiated in hardware. + + + Per-cmd ATAPI DMA capabilities filter + +int (*check_atapi_dma) (struct ata_queued_cmd *qc); + + + +Allow low-level driver to filter ATA PACKET commands, returning a status +indicating whether or not it is OK to use DMA for the supplied PACKET +command. + + + + + Read specific ATA shadow registers u8 (*check_status)(struct ata_port *ap); -void (*dev_select)(struct ata_port *ap, unsigned int device); +u8 (*check_altstatus)(struct ata_port *ap); +u8 (*check_err)(struct ata_port *ap); - Reads the Status ATA shadow register from hardware. On some - hardware, this has the side effect of clearing the interrupt - condition. + Reads the Status/AltStatus/Error ATA shadow register from + hardware. On some hardware, reading the Status register has + the side effect of clearing the interrupt condition. + + + Select ATA device on bus void (*dev_select)(struct ata_port *ap, unsigned int device); @@ -145,9 +187,13 @@ void (*dev_select)(struct ata_port *ap, Issues the low-level hardware command(s) that causes one of N hardware devices to be considered 'selected' (active and - available for use) on the ATA bus. + available for use) on the ATA bus. This generally has no +meaning on FIS-based devices. + + + Reset ATA bus void (*phy_reset) (struct ata_port *ap); @@ -160,17 +206,31 @@ void (*phy_reset) (struct ata_port *ap); functions ata_bus_reset() or sata_phy_reset() for this hook. + + + Control PCI IDE BMDMA engine void (*bmdma_setup) (struct ata_queued_cmd *qc); void (*bmdma_start) (struct ata_queued_cmd *qc); +void (*bmdma_stop) (struct ata_port *ap); +u8 (*bmdma_status) (struct ata_port *ap); - When setting up an IDE BMDMA transaction, these hooks arm - (->bmdma_setup) and fire (->bmdma_start) the hardware's DMA - engine. +When setting up an IDE BMDMA transaction, these hooks arm +(->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop) +the hardware's DMA engine. ->bmdma_status is used to read the standard +PCI IDE DMA Status register. + +These hooks are typically either no-ops, or simply not implemented, in +FIS-based drivers. + + + + + High-level taskfile hooks void (*qc_prep) (struct ata_queued_cmd *qc); int (*qc_issue) (struct ata_queued_cmd *qc); @@ -188,20 +248,26 @@ int (*qc_issue) (struct ata_queued_cmd * ->qc_issue is used to make a command active, once the hardware and S/G tables have been prepared. IDE BMDMA drivers use the helper function ata_qc_issue_prot() for taskfile protocol-based - dispatch. More advanced drivers roll their own ->qc_issue - implementation, using this as the "issue new ATA command to - hardware" hook. + dispatch. More advanced drivers implement their own ->qc_issue. + + + Timeout (error) handling void (*eng_timeout) (struct ata_port *ap); - This is a high level error handling function, called from the - error handling thread, when a command times out. +This is a high level error handling function, called from the +error handling thread, when a command times out. Most newer +hardware will implement its own error handling code here. IDE BMDMA +drivers may use the helper function ata_eng_timeout(). + + + Hardware interrupt handling irqreturn_t (*irq_handler)(int, void *, struct pt_regs *); void (*irq_clear) (struct ata_port *); @@ -214,6 +280,9 @@ void (*irq_clear) (struct ata_port *); is quiet. + + + SATA phy read/write u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg); void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, @@ -225,6 +294,9 @@ void (*scr_write) (struct ata_port *ap, if ->phy_reset hook called the sata_phy_reset() helper function. + + + Init and shutdown int (*port_start) (struct ata_port *ap); void (*port_stop) (struct ata_port *ap); @@ -238,15 +310,17 @@ void (*host_stop) (struct ata_host_set * tasks. - ->host_stop() is called when the rmmod or hot unplug process - begins. The hook must stop all hardware interrupts, DMA - engines, etc. - - ->port_stop() is called after ->host_stop(). It's sole function is to release DMA/memory resources, now that they are no longer actively being used. + + ->host_stop() is called after all ->port_stop() calls +have completed. The hook must finalize hardware shutdown, release DMA +and other resources, etc. + + + @@ -277,4 +351,24 @@ void (*host_stop) (struct ata_host_set * !Idrivers/scsi/sata_sil.c + + Thanks + + The bulk of the ATA knowledge comes thanks to long conversations with + Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA + and SCSI specifications. + + + Thanks to Alan Cox for pointing out similarities + between SATA and SCSI, and in general for motivation to hack on + libata. + + + libata's device detection + method, ata_pio_devchk, and in general all the early probing was + based on extensive study of Hale Landis's probe/reset code in his + ATADRVR driver (www.ata-atapi.com). + + + diff --git a/Documentation/DocBook/librs.tmpl b/Documentation/DocBook/librs.tmpl --- a/Documentation/DocBook/librs.tmpl +++ b/Documentation/DocBook/librs.tmpl @@ -1,4 +1,6 @@ - + + @@ -223,7 +225,7 @@ int numerr, errpos[8]; ..... /* Decode 512 byte in data8.*/ numerr = decode_rs8 (rs_decoder, NULL, NULL, 512, syn, 0, errpos, 0, corr); -for (i = 0; i < numerr; i++) { +for (i = 0; i < numerr; i++) { do_error_correction_in_your_buffer(errpos[i], corr[i]); } diff --git a/Documentation/DocBook/lsm.tmpl b/Documentation/DocBook/lsm.tmpl --- a/Documentation/DocBook/lsm.tmpl +++ b/Documentation/DocBook/lsm.tmpl @@ -1,6 +1,9 @@ - + + +

- + Linux Security Modules: General Security Hooks for Linux @@ -28,7 +31,7 @@ - + Introduction @@ -84,7 +87,7 @@ security; it merely provides the infrast modules. The LSM kernel patch also moves most of the capabilities logic into an optional security module, with the system defaulting to the traditional superuser logic. This capabilities module -is discussed further in . +is discussed further in . diff --git a/Documentation/DocBook/mcabook.tmpl b/Documentation/DocBook/mcabook.tmpl --- a/Documentation/DocBook/mcabook.tmpl +++ b/Documentation/DocBook/mcabook.tmpl @@ -1,4 +1,6 @@ - + + diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -1,4 +1,6 @@ - + + @@ -238,9 +240,9 @@ static void board_hwcontrol(struct mtd_i struct nand_chip *this = (struct nand_chip *) mtd->priv; switch(cmd){ case NAND_CTL_SETCLE: this->IO_ADDR_W |= CLE_ADRR_BIT; break; - case NAND_CTL_CLRCLE: this->IO_ADDR_W &= ~CLE_ADRR_BIT; break; + case NAND_CTL_CLRCLE: this->IO_ADDR_W &= ~CLE_ADRR_BIT; break; case NAND_CTL_SETALE: this->IO_ADDR_W |= ALE_ADRR_BIT; break; - case NAND_CTL_CLRALE: this->IO_ADDR_W &= ~ALE_ADRR_BIT; break; + case NAND_CTL_CLRALE: this->IO_ADDR_W &= ~ALE_ADRR_BIT; break; } } @@ -391,7 +393,7 @@ static void board_select_chip (struct mt /* Deselect all chips, set all nCE pins high */ GPIO(BOARD_NAND_NCE) |= 0xff; if (chip >= 0) - GPIO(BOARD_NAND_NCE) &= ~ (1 << chip); + GPIO(BOARD_NAND_NCE) &= ~ (1 << chip); } @@ -405,8 +407,8 @@ static void board_select_chip (struct mt struct nand_chip *this = (struct nand_chip *) mtd->priv; /* Deselect all chips */ - this->IO_ADDR_R &= ~BOARD_NAND_ADDR_MASK; - this->IO_ADDR_W &= ~BOARD_NAND_ADDR_MASK; + this->IO_ADDR_R &= ~BOARD_NAND_ADDR_MASK; + this->IO_ADDR_W &= ~BOARD_NAND_ADDR_MASK; switch (chip) { case 0: this->IO_ADDR_R |= BOARD_NAND_ADDR_CHIP0; diff --git a/Documentation/DocBook/procfs-guide.tmpl b/Documentation/DocBook/procfs-guide.tmpl --- a/Documentation/DocBook/procfs-guide.tmpl +++ b/Documentation/DocBook/procfs-guide.tmpl @@ -1,6 +1,7 @@ - - + + ]> @@ -205,7 +206,7 @@ function will return a pointer to the freshly created struct proc_dir_entry; otherwise it will return NULL. describes how to do something useful with + linkend="userland"/> describes how to do something useful with regular files. @@ -221,7 +222,7 @@ If you only want to be able to read the file, the function create_proc_read_entry described in may be used to create and initialise + linkend="convenience"/> may be used to create and initialise the procfs entry in one single call. @@ -298,7 +299,7 @@ the struct proc_dir_entry before remove_proc_entry is called (that is: if there was some data allocated, of - course). See for more information + course). See for more information on using the data entry. @@ -333,7 +334,7 @@ entry->write_proc = write_proc_foo; If you only want to use a the read_proc, the function create_proc_read_entry described in may be used to create and initialise the + linkend="convenience"/> may be used to create and initialise the procfs entry in one single call. @@ -386,7 +387,7 @@ entry->write_proc = write_proc_foo; The parameter start doesn't seem to be used anywhere in the kernel. The data parameter can be used to create a single call back function for - several files, see . + several files, see . @@ -395,7 +396,7 @@ entry->write_proc = write_proc_foo; - shows how to use a read call back + shows how to use a read call back function. @@ -429,12 +430,12 @@ entry->write_proc = write_proc_foo; kernel's memory space, so it should first be copied to kernel space with copy_from_user. The file parameter is usually - ignored. shows how to use the + ignored. shows how to use the data parameter. - Again, shows how to use this call back + Again, shows how to use this call back function. @@ -525,10 +526,10 @@ int foo_read_func(char *page, char **sta This function creates a regular file in exactly the same way as create_proc_entry from does, but also allows to set the read + linkend="regularfile"/> does, but also allows to set the read function read_proc in one call. This function can set the data as well, like - explained in . + explained in . diff --git a/Documentation/DocBook/scsidrivers.tmpl b/Documentation/DocBook/scsidrivers.tmpl --- a/Documentation/DocBook/scsidrivers.tmpl +++ b/Documentation/DocBook/scsidrivers.tmpl @@ -1,5 +1,6 @@ - - + + diff --git a/Documentation/DocBook/sis900.tmpl b/Documentation/DocBook/sis900.tmpl --- a/Documentation/DocBook/sis900.tmpl +++ b/Documentation/DocBook/sis900.tmpl @@ -1,25 +1,27 @@ - + + -SiS 900/7016 Fast Ethernet Device Driver +SiS 900/7016 Fast Ethernet Device Driver -Ollie +Ollie Lho -Lei Chun +Lei Chun Chang -Document Revision: 0.3 for SiS900 driver v1.06 & v1.07 -November 16, 2000 +Document Revision: 0.3 for SiS900 driver v1.06 & v1.07 +November 16, 2000 1999 @@ -48,21 +50,21 @@ - - + + This document gives some information on installation and usage of SiS 900/7016 device driver under Linux. - - + + - Introduction + Introduction - + This document describes the revision 1.06 and 1.07 of SiS 900/7016 Fast Ethernet device driver under Linux. The driver is developed by Silicon Integrated System Corp. and distributed freely under the GNU General Public License (GPL). @@ -70,265 +72,265 @@ The driver can be compiled as a loadable version 2.2.x. (rev. 1.06) With minimal changes, the driver can also be used under 2.3.x and 2.4.x kernel (rev. 1.07), please see -. If you are intended to +. If you are intended to use the driver for earlier kernels, you are on your own. - + - + The driver is tested with usual TCP/IP applications including FTP, Telnet, Netscape etc. and is used constantly by the developers. - + - + Please send all comments/fixes/questions to -Lei-Chun Chang. - +Lei-Chun Chang. + - Changes + Changes - + Changes made in Revision 1.07 - - - + + + Separation of sis900.c and sis900.h in order to move most constant definition to sis900.h (many of those constants were corrected) - - + + - - + + Clean up PCI detection, the pci-scan from Donald Becker were not used, just simple pci_find_*. - - + + - - + + MII detection is modified to support multiple mii transceiver. - - + + - - + + Bugs in read_eeprom, mdio_* were removed. - - + + - - + + Lot of sis900 irrelevant comments were removed/changed and more comments were added to reflect the real situation. - - + + - - + + Clean up of physical/virtual address space mess in buffer descriptors. - - + + - - + + Better transmit/receive error handling. - - + + - - + + The driver now uses zero-copy single buffer management scheme to improve performance. - - + + - - + + Names of variables were changed to be more consistent. - - + + - - + + Clean up of auo-negotiation and timer code. - - + + - - + + Automatic detection and change of PHY on the fly. - - + + - - + + Bug in mac probing fixed. - - + + - - + + Fix 630E equalier problem by modifying the equalizer workaround rule. - - + + - - + + Support for ICS1893 10/100 Interated PHYceiver. - - + + - - + + Support for media select by ifconfig. - - + + - - + + Added kernel-doc extratable documentation. - - + + - - + + - Tested Environment + Tested Environment - + This driver is developed on the following hardware - - + + - + Intel Celeron 500 with SiS 630 (rev 02) chipset - - - + + + - + SiS 900 (rev 01) and SiS 7016/7014 Fast Ethernet Card - - + + - + and tested with these software environments - - + + - + Red Hat Linux version 6.2 - - - + + + - + Linux kernel version 2.4.0 - - - + + + - + Netscape version 4.6 - - - + + + - + NcFTP 3.0.0 beta 18 - - - + + + - + Samba version 2.0.3 - - + + - + - + -Files in This Package +Files in This Package - + In the package you can find these files: - + - - + + - -sis900.c - - + +sis900.c + + Driver source file in C - - - - - -sis900.h - - + + + + + +sis900.h + + Header file for sis900.c - - - - - -sis900.sgml - - + + + + + +sis900.sgml + + DocBook SGML source of the document - - - - - -sis900.txt - - + + + + + +sis900.txt + + Driver document in plain text - - - + + + - - + + - Installation + Installation - + Silicon Integrated System Corp. is cooperating closely with core Linux Kernel developers. The revisions of SiS 900 driver are distributed by the usuall channels for kernel tar files and patches. Those kernel tar files for official kernel and patches for kernel pre-release can be download at -official kernel ftp site +official kernel ftp site and its mirrors. The 1.06 revision can be found in kernel version later than 2.3.15 and pre-2.2.14, and 1.07 revision can be found in kernel version 2.4.0. If you have no prior experience in networking under Linux, please read -Ethernet HOWTO and -Networking HOWTO available from +Ethernet HOWTO and +Networking HOWTO available from Linux Documentation Project (LDP). - + - + The driver is bundled in release later than 2.2.11 and 2.3.15 so this is the most easy case. Be sure you have the appropriate packages for compiling kernel source. @@ -338,63 +340,63 @@ in kernel release, you should have your sis900.c and sis900.h copied into /usr/src/linux/drivers/net/ first. There are two alternative ways to install the driver - + - -Building the driver as loadable module + +Building the driver as loadable module - + To build the driver as a loadable kernel module you have to reconfigure the kernel to activate network support by - + - + make menuconfig - + - + Choose Loadable module support --->, then select Enable loadable module support. - + - + Choose Network Device Support --->, select Ethernet (10 or 100Mbit). Then select EISA, VLB, PCI and on board controllers, and choose SiS 900/7016 PCI Fast Ethernet Adapter support to M. - + - + After reconfiguring the kernel, you can make the driver module by - + - + make modules - + - + The driver should be compiled with no errors. After compiling the driver, the driver can be installed to proper place by - + - + make modules_install - + - + Load the driver into kernel by - + - + insmod sis900 - + - + When loading the driver into memory, some information message can be view by - + - + dmesg @@ -404,103 +406,103 @@ or cat /var/log/message - + - + If the driver is loaded properly you will have messages similar to this: - + - + sis900.c: v1.07.06 11/07/2000 eth0: SiS 900 PCI Fast Ethernet at 0xd000, IRQ 10, 00:00:e8:83:7f:a4. eth0: SiS 900 Internal MII PHY transceiver found at address 1. eth0: Using SiS 900 Internal MII PHY as default - + - + showing the version of the driver and the results of probing routine. - + - + Once the driver is loaded, network can be brought up by - + - + /sbin/ifconfig eth0 IPADDR broadcast BROADCAST netmask NETMASK media TYPE - + - + where IPADDR, BROADCAST, NETMASK are your IP address, broadcast address and netmask respectively. TYPE is used to set medium type used by the device. Typical values are "10baseT"(twisted-pair 10Mbps Ethernet) or "100baseT" (twisted-pair 100Mbps Ethernet). For more information on how to configure network interface, please refer to -Networking HOWTO. - +Networking HOWTO. + - + The link status is also shown by kernel messages. For example, after the network interface is activated, you may have the message: - + - + eth0: Media Link On 100mbps full-duplex - + - + If you try to unplug the twist pair (TP) cable you will get - + - + eth0: Media Link Off - + - + indicating that the link is failed. - - + + - -Building the driver into kernel + +Building the driver into kernel - + If you want to make the driver into kernel, choose Y rather than M on SiS 900/7016 PCI Fast Ethernet Adapter support when configuring the kernel. Build the kernel image in the usual way - + - + make clean make bzlilo - + - + Next time the system reboot, you have the driver in memory. - + - + - Known Problems and Bugs + Known Problems and Bugs - + There are some known problems and bugs. If you find any other bugs please -mail to lcchang@sis.com.tw +mail to lcchang@sis.com.tw - + - - + + AM79C901 HomePNA PHY is not thoroughly tested, there may be some bugs in the on the fly change of transceiver. - - + + - - + + A bug is hidden somewhere in the receive buffer management code, the bug causes NULL pointer reference in the kernel. This fault is caught before bad things happen and reported with the message: @@ -509,70 +511,70 @@ caught before bad things happen and repo eth0: NULL pointer encountered in Rx ring, skipping -which can be viewed with dmesg or -cat /var/log/message. - - +which can be viewed with dmesg or +cat /var/log/message. + + - - + + The media type change from 10Mbps to 100Mbps twisted-pair ethernet by ifconfig causes the media link down. - - + + - - + + - Revision History + Revision History - - + + - - + + November 13, 2000, Revision 1.07, seventh release, 630E problem fixed and further clean up. - - + + - - + + November 4, 1999, Revision 1.06, Second release, lots of clean up and optimization. - - + + - - + + August 8, 1999, Revision 1.05, Initial Public Release - - + + - - + + - Acknowledgements + Acknowledgements - + This driver was originally derived form -Donald Becker's -pci-skeleton and -rtl8139 drivers. Donald also provided various suggestion +Donald Becker's +pci-skeleton and +rtl8139 drivers. Donald also provided various suggestion regarded with improvements made in revision 1.06. - + - + The 1.05 revision was created by -Jim Huang, AMD 79c901 -support was added by Chin-Shan Li. - +Jim Huang, AMD 79c901 +support was added by Chin-Shan Li. + diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl new file mode 100644 --- /dev/null +++ b/Documentation/DocBook/stylesheet.xsl @@ -0,0 +1,5 @@ + + +1 +ansi + diff --git a/Documentation/DocBook/tulip-user.tmpl b/Documentation/DocBook/tulip-user.tmpl deleted file mode 100644 --- a/Documentation/DocBook/tulip-user.tmpl +++ /dev/null @@ -1,325 +0,0 @@ - - - - - Tulip Driver User's Guide - - - - Jeff - Garzik - -
- jgarzik@pobox.com -
- - - - - - 2001 - Jeff Garzik - - - - - This documentation is free software; you can redistribute - it and/or modify it under the terms of the GNU General Public - License as published by the Free Software Foundation; either - version 2 of the License, or (at your option) any later - version. - - - - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - See the GNU General Public License for more details. - - - - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - - - - For more details see the file COPYING in the source - distribution of Linux. - - - - - - - - Introduction - -The Tulip Ethernet Card Driver -is maintained by Jeff Garzik (jgarzik@pobox.com). - - - -The Tulip driver was developed by Donald Becker and changed by -Jeff Garzik, Takashi Manabe and a cast of thousands. - - - -For 2.4.x and later kernels, the Linux Tulip driver is available at -http://sourceforge.net/projects/tulip/ - - - - This driver is for the Digital "Tulip" Ethernet adapter interface. - It should work with most DEC 21*4*-based chips/ethercards, as well as - with work-alike chips from Lite-On (PNIC) and Macronix (MXIC) and ASIX. - - - - The original author may be reached as becker@scyld.com, or C/O - Scyld Computing Corporation, - 410 Severn Ave., Suite 210, - Annapolis MD 21403 - - - - Additional information on Donald Becker's tulip.c - is available at http://www.scyld.com/network/tulip.html - - - - - - Driver Compatibility - - -This device driver is designed for the DECchip "Tulip", Digital's -single-chip ethernet controllers for PCI (now owned by Intel). -Supported members of the family -are the 21040, 21041, 21140, 21140A, 21142, and 21143. Similar work-alike -chips from Lite-On, Macronics, ASIX, Compex and other listed below are also -supported. - - - -These chips are used on at least 140 unique PCI board designs. The great -number of chips and board designs supported is the reason for the -driver size and complexity. Almost of the increasing complexity is in the -board configuration and media selection code. There is very little -increasing in the operational critical path length. - - - - - Board-specific Settings - - -PCI bus devices are configured by the system at boot time, so no jumpers -need to be set on the board. The system BIOS preferably should assign the -PCI INTA signal to an otherwise unused system IRQ line. - - - -Some boards have EEPROMs tables with default media entry. The factory default -is usually "autoselect". This should only be overridden when using -transceiver connections without link beat e.g. 10base2 or AUI, or (rarely!) -for forcing full-duplex when used with old link partners that do not do -autonegotiation. - - - - - Driver Operation - -Ring buffers - - -The Tulip can use either ring buffers or lists of Tx and Rx descriptors. -This driver uses statically allocated rings of Rx and Tx descriptors, set at -compile time by RX/TX_RING_SIZE. This version of the driver allocates skbuffs -for the Rx ring buffers at open() time and passes the skb->data field to the -Tulip as receive data buffers. When an incoming frame is less than -RX_COPYBREAK bytes long, a fresh skbuff is allocated and the frame is -copied to the new skbuff. When the incoming frame is larger, the skbuff is -passed directly up the protocol stack and replaced by a newly allocated -skbuff. - - - -The RX_COPYBREAK value is chosen to trade-off the memory wasted by -using a full-sized skbuff for small frames vs. the copying costs of larger -frames. For small frames the copying cost is negligible (esp. considering -that we are pre-loading the cache with immediately useful header -information). For large frames the copying cost is non-trivial, and the -larger copy might flush the cache of useful data. A subtle aspect of this -choice is that the Tulip only receives into longword aligned buffers, thus -the IP header at offset 14 isn't longword aligned for further processing. -Copied frames are put into the new skbuff at an offset of "+2", thus copying -has the beneficial effect of aligning the IP header and preloading the -cache. - - - - -Synchronization - -The driver runs as two independent, single-threaded flows of control. One -is the send-packet routine, which enforces single-threaded use by the -dev->tbusy flag. The other thread is the interrupt handler, which is single -threaded by the hardware and other software. - - - -The send packet thread has partial control over the Tx ring and 'dev->tbusy' -flag. It sets the tbusy flag whenever it's queuing a Tx packet. If the next -queue slot is empty, it clears the tbusy flag when finished otherwise it sets -the 'tp->tx_full' flag. - - - -The interrupt handler has exclusive control over the Rx ring and records stats -from the Tx ring. (The Tx-done interrupt can't be selectively turned off, so -we can't avoid the interrupt overhead by having the Tx routine reap the Tx -stats.) After reaping the stats, it marks the queue entry as empty by setting -the 'base' to zero. Iff the 'tp->tx_full' flag is set, it clears both the -tx_full and tbusy flags. - - - - - - - - Errata - - -The old DEC databooks were light on details. -The 21040 databook claims that CSR13, CSR14, and CSR15 should each be the last -register of the set CSR12-15 written. Hmmm, now how is that possible? - - - -The DEC SROM format is very badly designed not precisely defined, leading to -part of the media selection junkheap below. Some boards do not have EEPROM -media tables and need to be patched up. Worse, other boards use the DEC -design kit media table when it isn't correct for their board. - - - -We cannot use MII interrupts because there is no defined GPIO pin to attach -them. The MII transceiver status is polled using an kernel timer. - - - - - Driver Change History - - Version 0.9.14 (February 20, 2001) - - Fix PNIC problems (Manfred Spraul) - Add new PCI id for Accton comet - Support Davicom tulips - Fix oops in eeprom parsing - Enable workarounds for early PCI chipsets - IA64, hppa csr0 support - Support media types 5, 6 - Interpret a bit more of the 21142 SROM extended media type 3 - Add missing delay in eeprom reading - - - - Version 0.9.11 (November 3, 2000) - - Eliminate extra bus accesses when sharing interrupts (prumpf) - Barrier following ownership descriptor bit flip (prumpf) - Endianness fixes for >14 addresses in setup frames (prumpf) - Report link beat to kernel/userspace via netif_carrier_*. (kuznet) - Better spinlocking in set_rx_mode. - Fix I/O resource request failure error messages (DaveM catch) - Handle DMA allocation failure. - - - - Version 0.9.10 (September 6, 2000) - - Simple interrupt mitigation (via jamal) - More PCI ids - - - - Version 0.9.9 (August 11, 2000) - - More PCI ids - - - - Version 0.9.8 (July 13, 2000) - - Correct signed/unsigned comparison for dummy frame index - Remove outdated references to struct enet_statistics - - - - Version 0.9.7 (June 17, 2000) - - Timer cleanups (Andrew Morton) - Alpha compile fix (somebody?) - - - - Version 0.9.6 (May 31, 2000) - - Revert 21143-related support flag patch - Add HPPA/media-table debugging printk - - - - Version 0.9.5 (May 30, 2000) - - HPPA support (willy@puffingroup) - CSR6 bits and tulip.h cleanup (Chris Smith) - Improve debugging messages a bit - Add delay after CSR13 write in t21142_start_nway - Remove unused ETHER_STATS code - Convert 'extern inline' to 'static inline' in tulip.h (Chris Smith) - Update DS21143 support flags in tulip_chip_info[] - Use spin_lock_irq, not _irqsave/restore, in tulip_start_xmit() - Add locking to set_rx_mode() - Fix race with chip setting DescOwned bit (Hal Murray) - Request 100% of PIO and MMIO resource space assigned to card - Remove error message from pci_enable_device failure - - - - Version 0.9.4.3 (April 14, 2000) - - mod_timer fix (Hal Murray) - PNIC2 resuscitation (Chris Smith) - - - - Version 0.9.4.2 (March 21, 2000) - - Fix 21041 CSR7, CSR13/14/15 handling - Merge some PCI ids from tulip 0.91x - Merge some HAS_xxx flags and flag settings from tulip 0.91x - asm/io.h fix (submitted by many) and cleanup - s/HAS_NWAY143/HAS_NWAY/ - Cleanup 21041 mode reporting - Small code cleanups - - - - Version 0.9.4.1 (March 18, 2000) - - Finish PCI DMA conversion (davem) - Do not netif_start_queue() at end of tulip_tx_timeout() (kuznet) - PCI DMA fix (kuznet) - eeprom.c code cleanup - Remove Xircom Tulip crud - - - - - diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -1,4 +1,7 @@ - + + + The Linux-USB Host Side API diff --git a/Documentation/DocBook/via-audio.tmpl b/Documentation/DocBook/via-audio.tmpl deleted file mode 100644 --- a/Documentation/DocBook/via-audio.tmpl +++ /dev/null @@ -1,595 +0,0 @@ - - - - - Via 686 Audio Driver for Linux - - - - Jeff - Garzik - - - - - 1999-2001 - Jeff Garzik - - - - - This documentation is free software; you can redistribute - it and/or modify it under the terms of the GNU General Public - License as published by the Free Software Foundation; either - version 2 of the License, or (at your option) any later - version. - - - - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - See the GNU General Public License for more details. - - - - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - - - - For more details see the file COPYING in the source - distribution of Linux. - - - - - - - - Introduction - - The Via VT82C686A "super southbridge" chips contain - AC97-compatible audio logic which features dual 16-bit stereo - PCM sound channels (full duplex), plus a third PCM channel intended for use - in hardware-assisted FM synthesis. - - - The current Linux kernel audio driver for this family of chips - supports audio playback and recording, but hardware-assisted - FM features, and hardware buffer direct-access (mmap) - support are not yet available. - - - This driver supports any Linux kernel version after 2.4.10. - - - Please send bug reports to the mailing list linux-via@gtf.org. - To subscribe, e-mail majordomo@gtf.org with - - - subscribe linux-via - - - in the body of the message. - - - - - Driver Installation - - To use this audio driver, select the - CONFIG_SOUND_VIA82CXXX option in the section Sound during kernel configuration. - Follow the usual kernel procedures for rebuilding the kernel, - or building and installing driver modules. - - - To make this driver the default audio driver, you can add the - following to your /etc/conf.modules file: - - - alias sound via82cxxx_audio - - - Note that soundcore and ac97_codec support modules - are also required for working audio, in addition to - the via82cxxx_audio module itself. - - - - - Submitting a bug report - Description of problem - - Describe the application you were using to play/record sound, and how - to reproduce the problem. - - - Diagnostic output - - Obtain the via-audio-diag diagnostics program from - http://sf.net/projects/gkernel/ and provide a dump of the - audio chip's registers while the problem is occurring. Sample command line: - - - ./via-audio-diag -aps > diag-output.txt - - - Driver debug output - - Define VIA_DEBUG at the beginning of the driver, then capture and email - the kernel log output. This can be viewed in the system kernel log (if - enabled), or via the dmesg program. Sample command line: - - - dmesg > /tmp/dmesg-output.txt - - - Bigger kernel message buffer - - If you wish to increase the size of the buffer displayed by dmesg, then - change the LOG_BUF_LEN macro at the top of linux/kernel/printk.c, recompile - your kernel, and pass the LOG_BUF_LEN value to dmesg. Sample command line with - LOG_BUF_LEN == 32768: - - - dmesg -s 32768 > /tmp/dmesg-output.txt - - - - - - Known Bugs And Assumptions - - - Low volume - - - Volume too low on many systems. Workaround: use mixer program - such as xmixer to increase volume. - - - - - - - - - - Thanks - - Via for providing e-mail support, specs, and NDA'd source code. - - - MandrakeSoft for providing hacking time. - - - AC97 mixer interface fixes and debugging by Ron Cemer roncemer@gte.net. - - - Rui Sousa rui.sousa@conexant.com, for bugfixing - MMAP support, and several other notable fixes that resulted from - his hard work and testing. - - - Adrian Cox adrian@humboldt.co.uk, for bugfixing - MMAP support, and several other notable fixes that resulted from - his hard work and testing. - - - Thomas Sailer for further bugfixes. - - - - - Random Notes - - Two /proc pseudo-files provide diagnostic information. This is generally - not useful to most users. Power users can disable CONFIG_SOUND_VIA82CXXX_PROCFS, - and remove the /proc support code. Once - version 2.0.0 is released, the /proc support code will be disabled by - default. Available /proc pseudo-files: - - - /proc/driver/via/0/info - /proc/driver/via/0/ac97 - - - This driver by default supports all PCI audio devices which report - a vendor id of 0x1106, and a device id of 0x3058. Subsystem vendor - and device ids are not examined. - - - GNU indent formatting options: - --kr -i8 -ts8 -br -ce -bap -sob -l80 -pcs -cs -ss -bs -di1 -nbc -lp -psl - - - - Via has graciously donated e-mail support and source code to help further - the development of this driver. Their assistance has been invaluable - in the design and coding of the next major version of this driver. - - - The Via audio chip apparently provides a second PCM scatter-gather - DMA channel just for FM data, but does not have a full hardware MIDI - processor. I haven't put much thought towards a solution here, but it - might involve using SoftOSS midi wave table, or simply disabling MIDI - support altogether and using the FM PCM channel as a second (input? output?) - - - - - Driver ChangeLog - - -Version 1.9.1 - - - - - DSP read/write bugfixes from Thomas Sailer. - - - - - - Add new PCI id for single-channel use of Via 8233. - - - - - - Other bug fixes, tweaks, new ioctls. - - - - - - - -Version 1.1.15 - - - - - Support for variable fragment size and variable fragment number (Rui - Sousa) - - - - - - Fixes for the SPEED, STEREO, CHANNELS, FMT ioctls when in read & - write mode (Rui Sousa) - - - - - - Mmaped sound is now fully functional. (Rui Sousa) - - - - - - Make sure to enable PCI device before reading any of its PCI - config information. (fixes potential hotplug problems) - - - - - - Clean up code a bit and add more internal function documentation. - - - - - - AC97 codec access fixes (Adrian Cox) - - - - - - Big endian fixes (Adrian Cox) - - - - - - MIDI support (Adrian Cox) - - - - - - Detect and report locked-rate AC97 codecs. If your hardware only - supports 48Khz (locked rate), then your recording/playback software - must upsample or downsample accordingly. The hardware cannot do it. - - - - - - Use new pci_request_regions and pci_disable_device functions in - kernel 2.4.6. - - - - - - - -Version 1.1.14 - - - - - Use VM_RESERVE when available, to eliminate unnecessary page faults. - - - - - - -Version 1.1.12 - - - - - mmap bug fixes from Linus. - - - - - - -Version 1.1.11 - - - - - Many more bug fixes. mmap enabled by default, but may still be buggy. - - - - - - Uses new and spiffy method of mmap'ing the DMA buffer, based - on a suggestion from Linus. - - - - - - -Version 1.1.10 - - - - - Many bug fixes. mmap enabled by default, but may still be buggy. - - - - - - -Version 1.1.9 - - - - - Redesign and rewrite audio playback implementation. (faster and smaller, hopefully) - - - - - - Implement recording and full duplex (DSP_CAP_DUPLEX) support. - - - - - - Make procfs support optional. - - - - - - Quick interrupt status check, to lessen overhead in interrupt - sharing situations. - - - - - - Add mmap(2) support. Disabled for now, it is still buggy and experimental. - - - - - - Surround all syscalls with a semaphore for cheap and easy SMP protection. - - - - - - Fix bug in channel shutdown (hardware channel reset) code. - - - - - - Remove unnecessary spinlocks (better performance). - - - - - - Eliminate "unknown AFMT" message by using a different method - of selecting the best AFMT_xxx sound sample format for use. - - - - - - Support for realtime hardware pointer position reporting - (DSP_CAP_REALTIME, SNDCTL_DSP_GETxPTR ioctls) - - - - - - Support for capture/playback triggering - (DSP_CAP_TRIGGER, SNDCTL_DSP_SETTRIGGER ioctls) - - - - - - SNDCTL_DSP_SETDUPLEX and SNDCTL_DSP_POST ioctls now handled. - - - - - - Rewrite open(2) and close(2) logic to allow only one user at - a time. All other open(2) attempts will sleep until they succeed. - FIXME: open(O_RDONLY) and open(O_WRONLY) should be allowed to succeed. - - - - - - Reviewed code to ensure that SMP and multiple audio devices - are fully supported. - - - - - - - -Version 1.1.8 - - - - - Clean up interrupt handler output. Fixes the following kernel error message: - - - unhandled interrupt ... - - - - - - Convert documentation to DocBook, so that PDF, HTML and PostScript (.ps) output is readily - available. - - - - - - - -Version 1.1.7 - - - - - Fix module unload bug where mixer device left registered - after driver exit - - - - - - -Version 1.1.6 - - - - - Rewrite via_set_rate to mimic ALSA basic AC97 rate setting - - - - - Remove much dead code - - - - - Complete spin_lock_irqsave -> spin_lock_irq conversion in via_dsp_ioctl - - - - - Fix build problem in via_dsp_ioctl - - - - - Optimize included headers to eliminate headers found in linux/sound - - - - - - -Version 1.1.5 - - - - - Disable some overly-verbose debugging code - - - - - Remove unnecessary sound locks - - - - - Fix some ioctls for better time resolution - - - - - Begin spin_lock_irqsave -> spin_lock_irq conversion in via_dsp_ioctl - - - - - - -Version 1.1.4 - - - - - Completed rewrite of driver. Eliminated SoundBlaster compatibility - completely, and now uses the much-faster scatter-gather DMA engine. - - - - - - - - - Internal Functions -!Isound/oss/via82cxxx_audio.c - - - - - diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl --- a/Documentation/DocBook/videobook.tmpl +++ b/Documentation/DocBook/videobook.tmpl @@ -1,4 +1,6 @@ - + + @@ -180,23 +182,23 @@ int __init myradio_init(struct video_ini - VFL_TYPE_RADIO/dev/radio{n} + VFL_TYPE_RADIO/dev/radio{n} Radio devices are assigned in this block. As with all of these selections the actual number assignment is done by the video layer accordijng to what is free. - VFL_TYPE_GRABBER/dev/video{n} + VFL_TYPE_GRABBER/dev/video{n} Video capture devices and also -- counter-intuitively for the name -- hardware video playback devices such as MPEG2 cards. - VFL_TYPE_VBI/dev/vbi{n} + VFL_TYPE_VBI/dev/vbi{n} The VBI devices capture the hidden lines on a television picture that carry further information like closed caption data, teletext (primarily in Europe) and now Intercast and the ATVEC internet television encodings. - VFL_TYPE_VTX/dev/vtx[n} + VFL_TYPE_VTX/dev/vtx[n} VTX is 'Videotext' also known as 'Teletext'. This is a system for sending numbered, 40x25, mostly textual page images over the hidden lines. Unlike the /dev/vbi interfaces, this is for 'smart' decoder @@ -301,25 +303,25 @@ static int radio_ioctl(struct video_devi - nameThe device text name. This is intended for the user. + nameThe device text name. This is intended for the user. - channelsThe number of different channels you can tune on + channelsThe number of different channels you can tune on this card. It could even by zero for a card that has no tuning capability. For our simple FM radio it is 1. An AM/FM radio would report 2. - audiosThe number of audio inputs on this device. For our + audiosThe number of audio inputs on this device. For our radio there is only one audio input. - minwidth,minheightThe smallest size the card is capable of capturing + minwidth,minheightThe smallest size the card is capable of capturing images in. We set these to zero. Radios do not capture pictures - maxwidth,maxheightThe largest image size the card is capable of + maxwidth,maxheightThe largest image size the card is capable of capturing. For our radio we report 0. - typeThis reports the capabilities of the device, and + typeThis reports the capabilities of the device, and matches the field we filled in in the struct video_device when registering. @@ -375,26 +377,26 @@ static int radio_ioctl(struct video_devi - int tunerThe number of the tuner in question + int tunerThe number of the tuner in question - char name[32]A text description of this tuner. "FM" will do fine. + char name[32]A text description of this tuner. "FM" will do fine. This is intended for the application. - u32 flags + u32 flags Tuner capability flags - u16 modeThe current reception mode + u16 modeThe current reception mode - u16 signalThe signal strength scaled between 0 and 65535. If + u16 signalThe signal strength scaled between 0 and 65535. If a device cannot tell the signal strength it should report 65535. Many simple cards contain only a signal/no signal bit. Such cards will report either 0 or 65535. - u32 rangelow, rangehigh + u32 rangelow, rangehigh The range of frequencies supported by the radio or TV. It is scaled according to the VIDEO_TUNER_LOW flag. @@ -408,20 +410,20 @@ static int radio_ioctl(struct video_devi - VIDEO_TUNER_PALA PAL TV tuner + VIDEO_TUNER_PALA PAL TV tuner - VIDEO_TUNER_NTSCAn NTSC (US) TV tuner + VIDEO_TUNER_NTSCAn NTSC (US) TV tuner - VIDEO_TUNER_SECAMA SECAM (French) TV tuner + VIDEO_TUNER_SECAMA SECAM (French) TV tuner - VIDEO_TUNER_LOW + VIDEO_TUNER_LOW The tuner frequency is scaled in 1/16th of a KHz steps. If not it is in 1/16th of a MHz steps - VIDEO_TUNER_NORMThe tuner can set its format + VIDEO_TUNER_NORMThe tuner can set its format - VIDEO_TUNER_STEREO_ONThe tuner is currently receiving a stereo signal + VIDEO_TUNER_STEREO_ONThe tuner is currently receiving a stereo signal @@ -431,13 +433,13 @@ static int radio_ioctl(struct video_devi - VIDEO_MODE_PALPAL Format + VIDEO_MODE_PALPAL Format - VIDEO_MODE_NTSCNTSC Format (USA) + VIDEO_MODE_NTSCNTSC Format (USA) - VIDEO_MODE_SECAMFrench Format + VIDEO_MODE_SECAMFrench Format - VIDEO_MODE_AUTOA device that does not need to do + VIDEO_MODE_AUTOA device that does not need to do TV format switching @@ -521,7 +523,7 @@ static unsigned long current_freq; if(copy_from_user(arg, &freq, sizeof(unsigned long))!=0) return -EFAULT; - if(hardware_set_freq(freq)<0) + if(hardware_set_freq(freq)<0) return -EINVAL; current_freq = freq; return 0; @@ -582,32 +584,32 @@ static int current_volume=0; - audioThe input the user wishes to query + audioThe input the user wishes to query - volumeThe volume setting on a scale of 0-65535 + volumeThe volume setting on a scale of 0-65535 - baseThe base level on a scale of 0-65535 + baseThe base level on a scale of 0-65535 - trebleThe treble level on a scale of 0-65535 + trebleThe treble level on a scale of 0-65535 - flagsThe features this audio device supports + flagsThe features this audio device supports - nameA text name to display to the user. We picked - "Radio" as it explains things quite nicely. + nameA text name to display to the user. We picked + "Radio" as it explains things quite nicely. - modeThe current reception mode for the audio + modeThe current reception mode for the audio We report MONO because our card is too stupid to know if it is in mono or stereo. - balanceThe stereo balance on a scale of 0-65535, 32768 is - middle. + balanceThe stereo balance on a scale of 0-65535, 32768 is + middle. - stepThe step by which the volume control jumps. This is + stepThe step by which the volume control jumps. This is used to help make it easy for applications to set - slider behaviour. + slider behaviour. @@ -617,15 +619,15 @@ static int current_volume=0; - VIDEO_AUDIO_MUTEThe audio is currently muted. We + VIDEO_AUDIO_MUTEThe audio is currently muted. We could fake this in our driver but we choose not to bother. - VIDEO_AUDIO_MUTABLEThe input has a mute option + VIDEO_AUDIO_MUTABLEThe input has a mute option - VIDEO_AUDIO_TREBLEThe input has a treble control + VIDEO_AUDIO_TREBLEThe input has a treble control - VIDEO_AUDIO_BASSThe input has a base control + VIDEO_AUDIO_BASSThe input has a base control @@ -635,13 +637,13 @@ static int current_volume=0; - VIDEO_SOUND_MONOMono sound + VIDEO_SOUND_MONOMono sound - VIDEO_SOUND_STEREOStereo sound + VIDEO_SOUND_STEREOStereo sound - VIDEO_SOUND_LANG1Alternative language 1 (TV specific) + VIDEO_SOUND_LANG1Alternative language 1 (TV specific) - VIDEO_SOUND_LANG2Alternative language 2 (TV specific) + VIDEO_SOUND_LANG2Alternative language 2 (TV specific) @@ -866,37 +868,37 @@ static struct video_device my_camera -VID_TYPE_CAPTUREWe support image capture +VID_TYPE_CAPTUREWe support image capture -VID_TYPE_TELETEXTA teletext capture device (vbi{n]) +VID_TYPE_TELETEXTA teletext capture device (vbi{n]) -VID_TYPE_OVERLAYThe image can be directly overlaid onto the - frame buffer +VID_TYPE_OVERLAYThe image can be directly overlaid onto the + frame buffer -VID_TYPE_CHROMAKEYChromakey can be used to select which parts - of the image to display +VID_TYPE_CHROMAKEYChromakey can be used to select which parts + of the image to display -VID_TYPE_CLIPPINGIt is possible to give the board a list of - rectangles to draw around. +VID_TYPE_CLIPPINGIt is possible to give the board a list of + rectangles to draw around. -VID_TYPE_FRAMERAMThe video capture goes into the video memory +VID_TYPE_FRAMERAMThe video capture goes into the video memory and actually changes it. Applications need to know this so they can clean up after the - card + card -VID_TYPE_SCALESThe image can be scaled to various sizes, - rather than being a single fixed size. +VID_TYPE_SCALESThe image can be scaled to various sizes, + rather than being a single fixed size. -VID_TYPE_MONOCHROMEThe capture will be monochrome. This isn't a +VID_TYPE_MONOCHROMEThe capture will be monochrome. This isn't a complete answer to the question since a mono camera on a colour capture card will still - produce mono output. + produce mono output. -VID_TYPE_SUBCAPTUREThe card allows only part of its field of +VID_TYPE_SUBCAPTUREThe card allows only part of its field of view to be captured. This enables applications to avoid copying all of a large image into memory when only some section is - relevant. + relevant. @@ -1207,18 +1209,18 @@ static int camera_ioctl(struct video_dev - channelThe channel number we are selecting + channelThe channel number we are selecting - nameThe name for this channel. This is intended + nameThe name for this channel. This is intended to describe the port to the user. Appropriate names are therefore things like "Camera" "SCART input" - flagsChannel properties + flagsChannel properties - typeInput type + typeInput type - normThe current television encoding being used + normThe current television encoding being used if relevant for this channel. @@ -1229,9 +1231,9 @@ static int camera_ioctl(struct video_dev - VIDEO_VC_TUNERChannel has a tuner. + VIDEO_VC_TUNERChannel has a tuner. - VIDEO_VC_AUDIOChannel has audio. + VIDEO_VC_AUDIOChannel has audio. @@ -1240,11 +1242,11 @@ static int camera_ioctl(struct video_dev - VIDEO_TYPE_TVTelevision input. + VIDEO_TYPE_TVTelevision input. - VIDEO_TYPE_CAMERAFixed camera input. + VIDEO_TYPE_CAMERAFixed camera input. - 0Type is unknown. + 0Type is unknown. @@ -1253,13 +1255,13 @@ static int camera_ioctl(struct video_dev - VIDEO_MODE_PALPAL encoded Television + VIDEO_MODE_PALPAL encoded Television - VIDEO_MODE_NTSCNTSC (US) encoded Television + VIDEO_MODE_NTSCNTSC (US) encoded Television - VIDEO_MODE_SECAMSECAM (French) Television + VIDEO_MODE_SECAMSECAM (French) Television - VIDEO_MODE_AUTOAutomatic switching, or format does not + VIDEO_MODE_AUTOAutomatic switching, or format does not matter @@ -1339,14 +1341,14 @@ static int camera_ioctl(struct video_dev - GREYLinear greyscale. This is for simple cameras and the - like + GREYLinear greyscale. This is for simple cameras and the + like - RGB565The top 5 bits hold 32 red levels, the next six bits - hold green and the low 5 bits hold blue. + RGB565The top 5 bits hold 32 red levels, the next six bits + hold green and the low 5 bits hold blue. - RGB555The top bit is clear. The red green and blue levels - each occupy five bits. + RGB555The top bit is clear. The red green and blue levels + each occupy five bits. @@ -1477,32 +1479,32 @@ static struct video_buffer capture_fb; - widthThe width in pixels of the desired image. The card - may use a smaller size if this size is not available + widthThe width in pixels of the desired image. The card + may use a smaller size if this size is not available - heightThe height of the image. The card may use a smaller - size if this size is not available. + heightThe height of the image. The card may use a smaller + size if this size is not available. - x The X position of the top left of the window. This + x The X position of the top left of the window. This is in pixels relative to the left hand edge of the picture. Not all cards can display images aligned on any pixel boundary. If the position is unsuitable the card adjusts the image right and reduces the - width. + width. - y The Y position of the top left of the window. This + y The Y position of the top left of the window. This is counted in pixels relative to the top edge of the picture. As with the width if the card cannot display starting on this line it will adjust the - values. + values. - chromakeyThe colour (expressed in RGB32 format) for the - chromakey colour if chroma keying is being used. + chromakeyThe colour (expressed in RGB32 format) for the + chromakey colour if chroma keying is being used. - clipsAn array of rectangles that must not be drawn - over. + clipsAn array of rectangles that must not be drawn + over. - clipcountThe number of clips in this array. + clipcountThe number of clips in this array. @@ -1514,11 +1516,11 @@ static struct video_buffer capture_fb; - x, yCo-ordinates relative to the display + x, yCo-ordinates relative to the display - width, heightWidth and height in pixels + width, heightWidth and height in pixels - nextA spare field for the application to use + nextA spare field for the application to use @@ -1550,9 +1552,9 @@ static struct video_buffer capture_fb; struct video_window v; if(copy_from_user(&v, arg, sizeof(v))) return -EFAULT; - if(v.width > 640 || v.height > 480) + if(v.width > 640 || v.height > 480) return -EINVAL; - if(v.width < 16 || v.height < 16) + if(v.width < 16 || v.height < 16) return -EINVAL; hardware_set_key(v.chromakey); hardware_set_window(v); diff --git a/Documentation/DocBook/wanbook.tmpl b/Documentation/DocBook/wanbook.tmpl --- a/Documentation/DocBook/wanbook.tmpl +++ b/Documentation/DocBook/wanbook.tmpl @@ -1,4 +1,6 @@ - + + diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl --- a/Documentation/DocBook/writing_usb_driver.tmpl +++ b/Documentation/DocBook/writing_usb_driver.tmpl @@ -1,4 +1,6 @@ - + + diff --git a/Documentation/DocBook/z8530book.tmpl b/Documentation/DocBook/z8530book.tmpl --- a/Documentation/DocBook/z8530book.tmpl +++ b/Documentation/DocBook/z8530book.tmpl @@ -1,4 +1,6 @@ - + + diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt @@ -342,6 +342,7 @@ You can change this at module load time irqs=,... trydefaults=[0|1] regspacings=,,... regsizes=,,... regshifts=,,... + slave_addrs=,,... Each of these except si_trydefaults is a list, the first item for the first interface, second item for the second interface, etc. @@ -383,6 +384,10 @@ Since the register size may be larger th be in the lower 8 bits. The regshifts parameter give the amount to shift the data to get to the actual IPMI data. +The slave_addrs specifies the IPMI address of the local BMC. This is +usually 0x20 and the driver defaults to that, but in case it's not, it +can be specified when the driver starts up. + When compiled into the kernel, the addresses can be specified on the kernel command line as: @@ -392,6 +397,7 @@ kernel command line as: ipmi_si.regspacings=,,... ipmi_si.regsizes=,,... ipmi_si.regshifts=,,... + ipmi_si.slave_addrs=,,... It works the same as the module parameters of the same names. diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -108,8 +108,9 @@ year saw a paper describing an RCU imple 2004 has seen a Linux-Journal article on use of RCU in dcache [McKenney04a], a performance comparison of locking to RCU on several different CPUs [McKenney04b], a dissertation describing use of RCU in a -number of operating-system kernels [PaulEdwardMcKenneyPhD], and a paper -describing how to make RCU safe for soft-realtime applications [Sarma04c]. +number of operating-system kernels [PaulEdwardMcKenneyPhD], a paper +describing how to make RCU safe for soft-realtime applications [Sarma04c], +and a paper describing SELinux performance with RCU [JamesMorris04b]. Bibtex Entries @@ -341,6 +342,17 @@ Dipankar Sarma" ,pages="18-26" } +@techreport{Friedberg03a +,author="Stuart A. Friedberg" +,title="Lock-Free Wild Card Search Data Structure and Method" +,institution="US Patent and Trademark Office" +,address="Washington, DC" +,year="2003" +,number="US Patent 6,662,184 (contributed under GPL)" +,month="December" +,pages="112" +} + @article{McKenney04a ,author="Paul E. McKenney and Dipankar Sarma and Maneesh Soni" ,title="Scaling dcache with {RCU}" @@ -373,6 +385,9 @@ in Operating System Kernels" ,school="OGI School of Science and Engineering at Oregon Health and Sciences University" ,year="2004" +,note="Available: +\url{http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf} +[Viewed October 15, 2004]" } @Conference{Sarma04c @@ -385,3 +400,13 @@ Oregon Health and Sciences University" ,month="June" ,pages="182-191" } + +@unpublished{JamesMorris04b +,Author="James Morris" +,Title="Recent Developments in {SELinux} Kernel Performance" +,month="December" +,year="2004" +,note="Available: +\url{http://www.livejournal.com/users/james_morris/2153.html} +[Viewed December 10, 2004]" +} diff --git a/Documentation/RCU/UP.txt b/Documentation/RCU/UP.txt --- a/Documentation/RCU/UP.txt +++ b/Documentation/RCU/UP.txt @@ -2,11 +2,11 @@ RCU on Uniprocessor Systems A common misconception is that, on UP systems, the call_rcu() primitive -may immediately invoke its function, and that the synchronize_kernel +may immediately invoke its function, and that the synchronize_rcu() primitive may return immediately. The basis of this misconception is that since there is only one CPU, it should not be necessary to wait for anything else to get done, since there are no other CPUs for -anything else to be happening on. Although this approach will sort of +anything else to be happening on. Although this approach will -sort- -of- work a surprising amount of the time, it is a very bad idea in general. This document presents two examples that demonstrate exactly how bad an idea this is. @@ -44,14 +44,14 @@ its arguments would cause it to fail to underlying RCU, namely that call_rcu() defers invoking its arguments until all RCU read-side critical sections currently executing have completed. -Quick Quiz: why is it -not- legal to invoke synchronize_kernel() in +Quick Quiz: why is it -not- legal to invoke synchronize_rcu() in this case? Summary Permitting call_rcu() to immediately invoke its arguments or permitting -synchronize_kernel() to immediately return breaks RCU, even on a UP system. +synchronize_rcu() to immediately return breaks RCU, even on a UP system. So do not do it! Even on a UP system, the RCU infrastructure -must- respect grace periods. diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -32,7 +32,10 @@ over a rather long period of time, but i them -- even x86 allows reads to be reordered), and be prepared to explain why this added complexity is worthwhile. If you choose #c, be prepared to explain how this single task does not - become a major bottleneck on big multiprocessor machines. + become a major bottleneck on big multiprocessor machines (for + example, if the task is updating information relating to itself + that other tasks can read, there by definition can be no + bottleneck). 2. Do the RCU read-side critical sections make proper use of rcu_read_lock() and friends? These primitives are needed @@ -89,27 +92,34 @@ over a rather long period of time, but i "_rcu()" list-traversal primitives, such as the list_for_each_entry_rcu(). - b. If the list macros are being used, the list_del_rcu(), - list_add_tail_rcu(), and list_del_rcu() primitives must - be used in order to prevent weakly ordered machines from - misordering structure initialization and pointer planting. + b. If the list macros are being used, the list_add_tail_rcu() + and list_add_rcu() primitives must be used in order + to prevent weakly ordered machines from misordering + structure initialization and pointer planting. Similarly, if the hlist macros are being used, the - hlist_del_rcu() and hlist_add_head_rcu() primitives - are required. + hlist_add_head_rcu() primitive is required. - c. Updates must ensure that initialization of a given + c. If the list macros are being used, the list_del_rcu() + primitive must be used to keep list_del()'s pointer + poisoning from inflicting toxic effects on concurrent + readers. Similarly, if the hlist macros are being used, + the hlist_del_rcu() primitive is required. + + The list_replace_rcu() primitive may be used to + replace an old structure with a new one in an + RCU-protected list. + + d. Updates must ensure that initialization of a given structure happens before pointers to that structure are publicized. Use the rcu_assign_pointer() primitive when publicizing a pointer to a structure that can be traversed by an RCU read-side critical section. - [The rcu_assign_pointer() primitive is in process.] - 5. If call_rcu(), or a related primitive such as call_rcu_bh(), is used, the callback function must be written to be called from softirq context. In particular, it cannot block. -6. Since synchronize_kernel() blocks, it cannot be called from +6. Since synchronize_rcu() can block, it cannot be called from any sort of irq context. 7. If the updater uses call_rcu(), then the corresponding readers @@ -125,9 +135,9 @@ over a rather long period of time, but i such cases is a must, of course! And the jury is still out on whether the increased speed is worth it. -8. Although synchronize_kernel() is a bit slower than is call_rcu(), +8. Although synchronize_rcu() is a bit slower than is call_rcu(), it usually results in simpler code. So, unless update performance - is important or the updaters cannot block, synchronize_kernel() + is important or the updaters cannot block, synchronize_rcu() should be used in preference to call_rcu(). 9. All RCU list-traversal primitives, which include @@ -155,3 +165,14 @@ over a rather long period of time, but i you -must- use the "_rcu()" variants of the list macros. Failing to do so will break Alpha and confuse people reading your code. + +11. Note that synchronize_rcu() -only- guarantees to wait until + all currently executing rcu_read_lock()-protected RCU read-side + critical sections complete. It does -not- necessarily guarantee + that all currently running interrupts, NMIs, preempt_disable() + code, or idle loops will complete. Therefore, if you do not have + rcu_read_lock()-protected read-side critical sections, do -not- + use synchronize_rcu(). + + If you want to wait for some of these other things, you might + instead need to use synchronize_irq() or synchronize_sched(). diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt --- a/Documentation/RCU/listRCU.txt +++ b/Documentation/RCU/listRCU.txt @@ -32,6 +32,7 @@ implementation of audit_filter_task() mi enum audit_state state; read_lock(&auditsc_lock); + /* Note: audit_netlink_sem held by caller. */ list_for_each_entry(e, &audit_tsklist, list) { if (audit_filter_rules(tsk, &e->rule, NULL, &state)) { read_unlock(&auditsc_lock); @@ -55,6 +56,7 @@ This means that RCU can be easily applie enum audit_state state; rcu_read_lock(); + /* Note: audit_netlink_sem held by caller. */ list_for_each_entry_rcu(e, &audit_tsklist, list) { if (audit_filter_rules(tsk, &e->rule, NULL, &state)) { rcu_read_unlock(); @@ -139,12 +141,15 @@ Normally, the write_lock() and write_unl a spin_lock() and a spin_unlock(), but in this case, all callers hold audit_netlink_sem, so no additional locking is required. The auditsc_lock can therefore be eliminated, since use of RCU eliminates the need for -writers to exclude readers. +writers to exclude readers. Normally, the write_lock() calls would +be converted into spin_lock() calls. The list_del(), list_add(), and list_add_tail() primitives have been replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu(). The _rcu() list-manipulation primitives add memory barriers that are -needed on weakly ordered CPUs (most of them!). +needed on weakly ordered CPUs (most of them!). The list_del_rcu() +primitive omits the pointer poisoning debug-assist code that would +otherwise cause concurrent readers to fail spectacularly. So, when readers can tolerate stale data and when entries are either added or deleted, without in-place modification, it is very easy to use RCU! @@ -166,6 +171,7 @@ otherwise, the added fields would need t struct audit_newentry *ne; write_lock(&auditsc_lock); + /* Note: audit_netlink_sem held by caller. */ list_for_each_entry(e, list, list) { if (!audit_compare_rule(rule, &e->rule)) { e->rule.action = newaction; @@ -199,8 +205,7 @@ RCU ("read-copy update") its name. The audit_copy_rule(&ne->rule, &e->rule); ne->rule.action = newaction; ne->rule.file_count = newfield_count; - list_add_rcu(ne, e); - list_del(e); + list_replace_rcu(e, ne); call_rcu(&e->rcu, audit_free_rule, e); return 0; } diff --git a/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt --- a/Documentation/RCU/rcu.txt +++ b/Documentation/RCU/rcu.txt @@ -43,7 +43,9 @@ o If I am running on a uniprocessor kern o How can I see where RCU is currently used in the Linux kernel? - Search for "rcu_read_lock", "call_rcu", and "synchronize_kernel". + Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu", + "rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh", + "synchronize_rcu", and "synchronize_net". o What guidelines should I follow when writing code that uses RCU? diff --git a/Documentation/SecurityBugs b/Documentation/SecurityBugs new file mode 100644 --- /dev/null +++ b/Documentation/SecurityBugs @@ -0,0 +1,38 @@ +Linux kernel developers take security very seriously. As such, we'd +like to know when a security bug is found so that it can be fixed and +disclosed as quickly as possible. Please report security bugs to the +Linux kernel security team. + +1) Contact + +The Linux kernel security team can be contacted by email at +. This is a private list of security officers +who will help verify the bug report and develop and release a fix. +It is possible that the security team will bring in extra help from +area maintainers to understand and fix the security vulnerability. + +As it is with any bug, the more information provided the easier it +will be to diagnose and fix. Please review the procedure outlined in +REPORTING-BUGS if you are unclear about what information is helpful. +Any exploit code is very helpful and will not be released without +consent from the reporter unless it has already been made public. + +2) Disclosure + +The goal of the Linux kernel security team is to work with the +bug submitter to bug resolution as well as disclosure. We prefer +to fully disclose the bug as soon as possible. It is reasonable to +delay disclosure when the bug or the fix is not yet fully understood, +the solution is not well-tested or for vendor coordination. However, we +expect these delays to be short, measurable in days, not weeks or months. +A disclosure date is negotiated by the security team working with the +bug submitter as well as vendors. However, the kernel security team +holds the final say when setting a disclosure date. The timeframe for +disclosure is from immediate (esp. if it's already publically known) +to a few weeks. As a basic default policy, we expect report date to +disclosure date to be on the order of 7 days. + +3) Non-disclosure agreements + +The Linux kernel security team is not a formal body and therefore unable +to enter any non-disclosure agreements. diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers --- a/Documentation/SubmittingDrivers +++ b/Documentation/SubmittingDrivers @@ -118,13 +118,18 @@ Linux kernel mailing list: linux-kernel@vger.kernel.org [mail majordomo@vger.kernel.org to subscribe] +Linux Device Drivers, Third Edition (covers 2.6.10): + http://lwn.net/Kernel/LDD3/ (free version) + Kernel traffic: Weekly summary of kernel list activity (much easier to read) http://www.kerneltraffic.org/kernel-traffic/ LWN.net: Weekly summary of kernel development activity - http://lwn.net/ - 2.6 driver porting information: + 2.6 API changes: + http://lwn.net/Articles/2.6-kernel-api/ + Porting drivers from prior kernels to 2.6: http://lwn.net/Articles/driver-porting/ KernelTrap: diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -271,7 +271,7 @@ patch, which certifies that you wrote it pass it on as a open-source patch. The rules are pretty simple: if you can certify the below: - Developer's Certificate of Origin 1.0 + Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: @@ -291,6 +291,12 @@ can certify the below: person who certified (a), (b) or (c) and I have not modified it. + (d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. + then you just add a line saying Signed-off-by: Random J Developer diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt --- a/Documentation/aoe/aoe.txt +++ b/Documentation/aoe/aoe.txt @@ -4,11 +4,28 @@ The EtherDrive (R) HOWTO for users of 2. It has many tips and hints! +The aoetools are userland programs that are designed to work with this +driver. The aoetools are on sourceforge. + + http://aoetools.sourceforge.net/ + +The scripts in this Documentation/aoe directory are intended to +document the use of the driver and are not necessary if you install +the aoetools. + + CREATING DEVICE NODES - Users of udev should find device nodes created automatically. Two - scripts are provided in Documentation/aoe as examples of static - device node creation for using the aoe driver. + Users of udev should find the block device nodes created + automatically, but to create all the necessary device nodes, use the + udev configuration rules provided in udev.txt (in this directory). + + There is a udev-install.sh script that shows how to install these + rules on your system. + + If you are not using udev, two scripts are provided in + Documentation/aoe as examples of static device node creation for + using the aoe driver. rm -rf /dev/etherd sh Documentation/aoe/mkdevs.sh /dev/etherd @@ -28,14 +45,15 @@ USING DEVICE NODES "echo eth2 eth4 > /dev/etherd/interfaces" tells the aoe driver to limit ATA over Ethernet traffic to eth2 and eth4. AoE traffic from - untrusted networks should be ignored as a matter of security. + untrusted networks should be ignored as a matter of security. See + also the aoe_iflist driver option described below. "echo > /dev/etherd/discover" tells the driver to find out what AoE devices are available. These character devices may disappear and be replaced by sysfs - counterparts, so distribution maintainers are encouraged to create - scripts that use these devices. + counterparts. Using the commands in aoetools insulates users from + these implementation details. The block devices are named like this: @@ -59,7 +77,8 @@ USING SYSFS through which we are communicating with the remote AoE device. There is a script in this directory that formats this information - in a convenient way. + in a convenient way. Users with aoetools can use the aoe-stat + command. root@makki root# sh Documentation/aoe/status.sh e10.0 eth3 up @@ -82,3 +101,23 @@ USING SYSFS e4.7 eth1 up e4.8 eth1 up e4.9 eth1 up + + Use /sys/module/aoe/parameters/aoe_iflist (or better, the driver + option discussed below) instead of /dev/etherd/interfaces to limit + AoE traffic to the network interfaces in the given + whitespace-separated list. Unlike the old character device, the + sysfs entry can be read from as well as written to. + + It's helpful to trigger discovery after setting the list of allowed + interfaces. The aoetools package provides an aoe-discover script + for this purpose. You can also directly use the + /dev/etherd/discover special file described above. + +DRIVER OPTIONS + + There is a boot option for the built-in aoe driver and a + corresponding module parameter, aoe_iflist. Without this option, + all network interfaces may be used for ATA over Ethernet. Here is a + usage example for the module parameter. + + modprobe aoe_iflist="eth1 eth3" diff --git a/Documentation/aoe/mkdevs.sh b/Documentation/aoe/mkdevs.sh --- a/Documentation/aoe/mkdevs.sh +++ b/Documentation/aoe/mkdevs.sh @@ -5,6 +5,7 @@ n_partitions=${n_partitions:-16} if test "$#" != "1"; then echo "Usage: sh `basename $0` {dir}" 1>&2 + echo " n_partitions=16 sh `basename $0` {dir}" 1>&2 exit 1 fi dir=$1 diff --git a/Documentation/aoe/mkshelf.sh b/Documentation/aoe/mkshelf.sh --- a/Documentation/aoe/mkshelf.sh +++ b/Documentation/aoe/mkshelf.sh @@ -2,6 +2,7 @@ if test "$#" != "2"; then echo "Usage: sh `basename $0` {dir} {shelfaddress}" 1>&2 + echo " n_partitions=16 sh `basename $0` {dir} {shelfaddress}" 1>&2 exit 1 fi n_partitions=${n_partitions:-16} diff --git a/Documentation/aoe/status.sh b/Documentation/aoe/status.sh --- a/Documentation/aoe/status.sh +++ b/Documentation/aoe/status.sh @@ -4,19 +4,18 @@ set -e format="%8s\t%8s\t%8s\n" me=`basename $0` +sysd=${sysfs_dir:-/sys} # printf "$format" device mac netif state -test -z "`mount | grep sysfs`" && { +# Suse 9.1 Pro doesn't put /sys in /etc/mtab +#test -z "`mount | grep sysfs`" && { +test ! -d "$sysd/block" && { echo "$me Error: sysfs is not mounted" 1>&2 exit 1 } -test -z "`lsmod | grep '^aoe'`" && { - echo "$me Error: aoe module is not loaded" 1>&2 - exit 1 -} -for d in `ls -d /sys/block/etherd* 2>/dev/null | grep -v p` end; do +for d in `ls -d $sysd/block/etherd* 2>/dev/null | grep -v p` end; do # maybe ls comes up empty, so we use "end" test $d = end && continue diff --git a/Documentation/aoe/todo.txt b/Documentation/aoe/todo.txt new file mode 100644 --- /dev/null +++ b/Documentation/aoe/todo.txt @@ -0,0 +1,14 @@ +There is a potential for deadlock when allocating a struct sk_buff for +data that needs to be written out to aoe storage. If the data is +being written from a dirty page in order to free that page, and if +there are no other pages available, then deadlock may occur when a +free page is needed for the sk_buff allocation. This situation has +not been observed, but it would be nice to eliminate any potential for +deadlock under memory pressure. + +Because ATA over Ethernet is not fragmented by the kernel's IP code, +the destructore member of the struct sk_buff is available to the aoe +driver. By using a mempool for allocating all but the first few +sk_buffs, and by registering a destructor, we should be able to +efficiently allocate sk_buffs without introducing any potential for +deadlock. diff --git a/Documentation/aoe/udev-install.sh b/Documentation/aoe/udev-install.sh new file mode 100644 --- /dev/null +++ b/Documentation/aoe/udev-install.sh @@ -0,0 +1,30 @@ +# install the aoe-specific udev rules from udev.txt into +# the system's udev configuration +# + +me="`basename $0`" + +# find udev.conf, often /etc/udev/udev.conf +# (or environment can specify where to find udev.conf) +# +if test -z "$conf"; then + if test -r /etc/udev/udev.conf; then + conf=/etc/udev/udev.conf + else + conf="`find /etc -type f -name udev.conf 2> /dev/null`" + if test -z "$conf" || test ! -r "$conf"; then + echo "$me Error: no udev.conf found" 1>&2 + exit 1 + fi + fi +fi + +# find the directory where udev rules are stored, often +# /etc/udev/rules.d +# +rules_d="`sed -n '/^udev_rules=/{ s!udev_rules=!!; s!\"!!g; p; }' $conf`" +if test -z "$rules_d" || test ! -d "$rules_d"; then + echo "$me Error: cannot find udev rules directory" 1>&2 + exit 1 +fi +sh -xc "cp `dirname $0`/udev.txt $rules_d/60-aoe.rules" diff --git a/Documentation/aoe/udev.txt b/Documentation/aoe/udev.txt new file mode 100644 --- /dev/null +++ b/Documentation/aoe/udev.txt @@ -0,0 +1,23 @@ +# These rules tell udev what device nodes to create for aoe support. +# They may be installed along the following lines (adjusted to what +# you see on your system). +# +# ecashin@makki ~$ su +# Password: +# bash# find /etc -type f -name udev.conf +# /etc/udev/udev.conf +# bash# grep udev_rules= /etc/udev/udev.conf +# udev_rules="/etc/udev/rules.d/" +# bash# ls /etc/udev/rules.d/ +# 10-wacom.rules 50-udev.rules +# bash# cp /path/to/linux-2.6.xx/Documentation/aoe/udev.txt \ +# /etc/udev/rules.d/60-aoe.rules +# + +# aoe char devices +SUBSYSTEM="aoe", KERNEL="discover", NAME="etherd/%k", GROUP="disk", MODE="0220" +SUBSYSTEM="aoe", KERNEL="err", NAME="etherd/%k", GROUP="disk", MODE="0440" +SUBSYSTEM="aoe", KERNEL="interfaces", NAME="etherd/%k", GROUP="disk", MODE="0220" + +# aoe block devices +KERNEL="etherd*", NAME="%k", GROUP="disk" diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000 --- a/Documentation/arm/IXP2000 +++ b/Documentation/arm/IXP2000 @@ -45,7 +45,7 @@ MAILING LISTS REGARDING THE INTEL SDK. 4. Usage Notes -- The IXP2000 platforms ususally have rather complex PCI bus topologies +- The IXP2000 platforms usually have rather complex PCI bus topologies with large memory space requirements. In addition, b/c of the way the Intel SDK is designed, devices are enumerated in a very specific way. B/c of this this, we use "pci=firmware" option in the kernel diff --git a/Documentation/arm/Samsung-S3C24XX/H1940.txt b/Documentation/arm/Samsung-S3C24XX/H1940.txt new file mode 100644 --- /dev/null +++ b/Documentation/arm/Samsung-S3C24XX/H1940.txt @@ -0,0 +1,40 @@ + HP IPAQ H1940 + ============= + +http://www.handhelds.org/projects/h1940.html + +Introduction +------------ + + The HP H1940 is a S3C2410 based handheld device, with + bluetooth connectivity. + + +Support +------- + + A variety of information is available + + handhelds.org project page: + + http://www.handhelds.org/projects/h1940.html + + handhelds.org wiki page: + + http://handhelds.org/moin/moin.cgi/HpIpaqH1940 + + Herbert Pötzl pages: + + http://vserver.13thfloor.at/H1940/ + + +Maintainers +----------- + + This project is being maintained and developed by a variety + of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl. + + Thanks to the many others who have also provided support. + + +(c) 2005 Ben Dooks \ No newline at end of file diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -7,8 +7,8 @@ Introduction ------------ The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported - by the 's3c2410' architecture of ARM Linux. Currently the S3C2410 is - the only supported CPU in this range. + by the 's3c2410' architecture of ARM Linux. Currently the S3C2410 and + the S3C2440 are supported CPUs. Configuration @@ -36,6 +36,10 @@ Machines Samsung's own development board, geared for PDA work. + Samsung/Meritech SMDK2440 + + The S3C2440 compatible version of the SMDK2440 + Thorcom VR1000 Custom embedded board @@ -44,12 +48,41 @@ Machines Handheld (IPAQ), available in several varieties - HP iPAQ rx3715 S3C2440 based IPAQ, with a number of variations depending on features shipped. + Acer N30 + + A S3C2410 based PDA from Acer. There is a Wiki page at + http://handhelds.org/moin/moin.cgi/AcerN30Documentation . + + +Adding New Machines +------------------- + + The archicture has been designed to support as many machines as can + be configured for it in one kernel build, and any future additions + should keep this in mind before altering items outside of their own + machine files. + + Machine definitions should be kept in linux/arch/arm/mach-s3c2410, + and there are a number of examples that can be looked at. + + Read the kernel patch submission policies as well as the + Documentation/arm directory before submitting patches. The + ARM kernel series is managed by Russell King, and has a patch system + located at http://www.arm.linux.org.uk/developer/patches/ + as well as mailing lists that can be found from the same site. + + As a courtesy, please notify of any new + machines or other modifications. + + Any large scale modifications, or new drivers should be discussed + on the ARM kernel mailing list (linux-arm-kernel) before being + attempted. + NAND ---- @@ -98,6 +131,9 @@ Port Contributors Klaus Fetscher Dimitry Andric Shannon Holland + Guillaume Gourat (NexVision) + Christer Weinigel (wingel) (Acer N30) + Lucas Correia Villa Real (S3C2400 port) Document Changes @@ -108,6 +144,11 @@ Document Changes 25 Oct 2004 - BJD - Added Dimitry Andric to list of contributors 25 Oct 2004 - BJD - Updated the MTD from the 2.6.9 merge 21 Jan 2005 - BJD - Added rx3715, added Shannon to contributors + 10 Feb 2005 - BJD - Added Guillaume Gourat to contributors + 02 Mar 2005 - BJD - Added SMDK2440 to list of machines + 06 Mar 2005 - BJD - Added Christer Weinigel + 08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction + 08 Mar 2005 - BJD - Added section on adding machines Document Author --------------- diff --git a/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt b/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt new file mode 100644 --- /dev/null +++ b/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt @@ -0,0 +1,56 @@ + Samsung/Meritech SMDK2440 + ========================= + +Introduction +------------ + + The SMDK2440 is a two part evaluation board for the Samsung S3C2440 + processor. It includes support for LCD, SmartMedia, Audio, SD and + 10MBit Ethernet, and expansion headers for various signals, including + the camera and unused GPIO. + + +Configuration +------------- + + To set the default configuration, use `make smdk2440_defconfig` which + will configure the common features of this board, or use + `make s3c2410_config` to include support for all s3c2410/s3c2440 machines + + +Support +------- + + Ben Dooks' SMDK2440 site at http://www.fluff.org/ben/smdk2440/ which + includes linux based USB download tools. + + Some of the h1940 patches that can be found from the H1940 project + site at http://www.handhelds.org/projects/h1940.html can also be + applied to this board. + + +Peripherals +----------- + + There is no current support for any of the extra peripherals on the + base-board itself. + + +MTD +--- + + The NAND flash should be supported by the in kernel MTD NAND support, + NOR flash will be added later. + + +Maintainers +----------- + + This board is being maintained by Ben Dooks, for more info, see + http://www.fluff.org/ben/smdk2440/ + + Many thanks to Dimitry Andric of TomTom for the loan of the SMDK2440, + and to Simtec Electronics for allowing me time to work on this. + + +(c) 2004 Ben Dooks \ No newline at end of file diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt --- a/Documentation/cachetlb.txt +++ b/Documentation/cachetlb.txt @@ -142,6 +142,11 @@ changes occur: The ia64 sn2 platform is one example of a platform that uses this interface. +8) void lazy_mmu_prot_update(pte_t pte) + This interface is called whenever the protection on + any user PTEs change. This interface provides a notification + to architecture specific code to take appropiate action. + Next, we have the cache flushing interfaces. In general, when Linux is changing an existing virtual-->physical mapping to a new value, @@ -155,7 +160,7 @@ the sequence will be in one of the follo change_range_of_page_tables(mm, start, end); flush_tlb_range(vma, start, end); - 3) flush_cache_page(vma, addr); + 3) flush_cache_page(vma, addr, pfn); set_pte(pte_pointer, new_pte_val); flush_tlb_page(vma, addr); @@ -203,7 +208,7 @@ Here are the routines, one by one: call flush_cache_page (see below) for each entry which may be modified. -3) void flush_cache_page(struct vm_area_struct *vma, unsigned long addr) +3) void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn) This time we need to remove a PAGE_SIZE sized range from the cache. The 'vma' is the backing structure used by @@ -213,8 +218,14 @@ Here are the routines, one by one: executable (and thus could be in the 'instruction cache' in "Harvard" type cache layouts). + The 'pfn' indicates the physical page frame (shift this value + left by PAGE_SHIFT to get the physical address) that 'addr' + translates to. It is this mapping which should be removed from + the cache. + After running, there will be no entries in the cache for - 'vma->vm_mm' for virtual address 'addr'. + 'vma->vm_mm' for virtual address 'addr' which translates + to 'pfn'. This is used primarily during fault processing. diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt --- a/Documentation/cciss.txt +++ b/Documentation/cciss.txt @@ -15,6 +15,8 @@ This driver is known to work with the fo * SA 6400 U320 Expansion Module * SA 6i * SA P600 + * SA P800 + * SA E400 If nodes are not already created in the /dev/cciss directory, run as root: diff --git a/Documentation/cdrom/mcd b/Documentation/cdrom/mcd deleted file mode 100644 --- a/Documentation/cdrom/mcd +++ /dev/null @@ -1,4 +0,0 @@ -This driver does not support XA or MultiSession CDs (PhotoCDs). Use the -experimental driver mcdx.c for that. - -You can use mcd for one interface, and mcdx for another. diff --git a/Documentation/cdrom/mcdx b/Documentation/cdrom/mcdx --- a/Documentation/cdrom/mcdx +++ b/Documentation/cdrom/mcdx @@ -1,16 +1,3 @@ -This is a first attempt to create an `improved' driver for the Mitsumi drives. -It is able to "live together" with mcd.c, if you have at least two Mitsumi -drives: each driver can use its own drive. - -To allow this "coexistence" as long as mcdx.c is not a superset of mcd.c, -this driver has to use its own device files. We use MAJOR 20 for it. So, -you have to do - - # mknod /dev/mcdx0 b 20 0 - # mknod /dev/mcdx1 b 20 1 - -and so on, one entry for each drive to support, once. - If you are using the driver as a module, you can specify your ports and IRQs like @@ -25,9 +12,7 @@ This driver: ordinary CDs; o supports up to 5 drives (of course, you'll need free IRQs, i/o ports and slots); - o uses much less kernel memory than the standard mcd driver - (no extra driver internal buffers!). - o plays audio (like the `old' driver, I hope) + o plays audio This version doesn't support yet: diff --git a/Documentation/cdrom/packet-writing.txt b/Documentation/cdrom/packet-writing.txt --- a/Documentation/cdrom/packet-writing.txt +++ b/Documentation/cdrom/packet-writing.txt @@ -62,6 +62,14 @@ generates aligned writes. # mount /dev/pktcdvd/dev_name /cdrom -t udf -o rw,noatime +Packet writing for DVD-RAM media +-------------------------------- + +DVD-RAM discs are random writable, so using the pktcdvd driver is not +necessary. However, using the pktcdvd driver can improve performance +in the same way it does for DVD+RW media. + + Notes ----- diff --git a/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt new file mode 100644 --- /dev/null +++ b/Documentation/cpu-freq/cpufreq-stats.txt @@ -0,0 +1,128 @@ + + CPU frequency and voltage scaling statictics in the Linux(TM) kernel + + + L i n u x c p u f r e q - s t a t s d r i v e r + + - information for users - + + + Venkatesh Pallipadi + +Contents +1. Introduction +2. Statistics Provided (with example) +3. Configuring cpufreq-stats + + +1. Introduction + +cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. +This statistics is provided in /sysfs as a bunch of read_only interfaces. This +interface (when configured) will appear in a seperate directory under cpufreq +in /sysfs (/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. +Various statistics will form read_only files under this directory. + +This driver is designed to be independent of any particular cpufreq_driver +that may be running on your CPU. So, it will work with any cpufreq_driver. + + +2. Statistics Provided (with example) + +cpufreq stats provides following statistics (explained in detail below). +- time_in_state +- total_trans +- trans_table + +All the statistics will be from the time the stats driver has been inserted +to the time when a read of a particular statistic is done. Obviously, stats +driver will not have any information about the the frequcny transitions before +the stats driver insertion. + +-------------------------------------------------------------------------------- +:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l +total 0 +drwxr-xr-x 2 root root 0 May 14 16:06 . +drwxr-xr-x 3 root root 0 May 14 15:58 .. +-r--r--r-- 1 root root 4096 May 14 16:06 time_in_state +-r--r--r-- 1 root root 4096 May 14 16:06 total_trans +-r--r--r-- 1 root root 4096 May 14 16:06 trans_table +-------------------------------------------------------------------------------- + +- time_in_state +This gives the amount of time spent in each of the frequencies supported by +this CPU. The cat output will have "