/Documentation/

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000000000000..5014bfa48ac1
--- /dev/null
+++ b/.gitignore

diff --git a/CREDITS b/CREDITS
index a347520bef2d..1b4f8694fa48 100644
--- a/CREDITS
+++ b/CREDITS

+P: 1024D/B7D2F063 E67C 0D43 A75E 12A5 BB1C FA2F 1E32 C3DA B7D2 F063

+D: PA-RISC port minion, PDC and GSCPS2 drivers, debuglocks and other bits

+D: Some bits in an ARM port, S1D13XXX FB driver, random patches here and there

D: Co-author of Multi-Protocol Over ATM (MPOA), some LANE hacks

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 433cf5e9ae04..5f7f7d7f77d2 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX

- info for PCI drivers using DMA portably across all platforms.

- directory with DocBook templates etc. for kernel documentation.

+ - The process and procedures of how to do Linux kernel development.

- info on hardware/driver for specialix IO8+ multiport serial card.

- info on using spinlocks to provide exclusive access in kernel.

+ - info on why the kernel does not have a stable in-kernel api or abi.

diff --git a/Documentation/Changes b/Documentation/Changes
index 5eaab0441d76..86b86399d61d 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes

@@ -65,7 +65,7 @@ o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version

-If the unthinkable happens and your kernel oopses, you'll need a 2.4

-version of ksymoops to decode the report; see REPORTING-BUGS in the

+If the unthinkable happens and your kernel oopses, you may need the

+In the 2.6 kernel it is generally preferred to build the kernel with

+CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is

+If for some reason your kernel is not build with CONFIG_KALLSYMS and

+you have no way to rebuild and reproduce the Oops with that option, then

udev is a userspace application for populating /dev dynamically with

only entries for devices actually present. udev replaces devfs.

+Needs libfuse 2.4.0 or later. Absolute minimum is 2.3.0 but mount

o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html>

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index fa3e29ad8a46..1c955883cf58 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile

@@ -10,7 +10,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \

@@ -20,6 +20,12 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \

+# for PDF and PS output you can choose between xmlto and docbook-utils tools

.PHONY: xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs

-# db2html creates a directory. Generate a html file used for timestamp

+notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \

+ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found)

+ifeq ($(shell which xmlto >/dev/null 2>&1 && echo found),found)

cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \

echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \

cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi

cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi

diff --git a/Documentation/DocBook/journal-api.tmpl b/Documentation/DocBook/journal-api.tmpl
index 341aaa4ce481..2077f9a28c19 100644
--- a/Documentation/DocBook/journal-api.tmpl
+++ b/Documentation/DocBook/journal-api.tmpl

diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index d650ce36485f..767433bdbc40 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl

+<!-- FIXME: Removed for now since no structured comments in source

<sect1><title>Frame Buffer Macintosh Video Mode Database</title>

diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl
index 375ae760dc1e..d260d92089ad 100644
--- a/Documentation/DocBook/libata.tmpl
+++ b/Documentation/DocBook/libata.tmpl

+ (Documentation/scsi/scsi_eh.txt) and ATA exceptions doc first.

+ In libata, a command is represented with struct ata_queued_cmd

+ repetitively used for command executions. Currently only one

+ allocates one for each tag and maps each qc to NCQ tag 1-to-1.

+ libata commands can originate from two sources - libata itself

+ available, internal commands are currently issued only during

+ Once allocated qc's taskfile is initialized for the command to

+ commands and qc->waiting is the synchronous (issuer sleeps in

+ midlayer's completion notification function pointer is stored

+ ATAPI commands use atapi_qc_complete(). Both functions end up

+ discussion, a controller which uses taskfile interface and all

+ ata_qc_complete() or time out. For commands which are handled

+ by interrupts, ata_host_intr() invokes ata_qc_complete(), and,

+ qc->complete_fn() callback is invoked. If the return value of

+ qc is deallocated by clearing appropriate bit in ap->qactive.

+ So, it basically notifies upper layer and deallocates qc. One

+ command fails, ata_qc_complete() is invoked with error status,

+ SAM_STAT_CHECK_CONDITION, complete the scmd and return 1. As

+ the sense data is empty but scmd->result is CHECK CONDITION,

+ makes ata_qc_complete() to return without deallocating the qc.

+ This leads us to ata_scsi_error() with partially completed qc.

+ ata_scsi_error() is the current hostt->eh_strategy_handler()

+ if a qc is active and calls ata_qc_timeout() on the qc if so.

+ If EH is invoked for timeout, ata_qc_timeout() stops BMDMA and

+ Here, we override qc->scsidone with scsi_finish_command() and

+ Once control reaches here, the qc is deallocated by invoking

+ __ata_qc_complete() explicitly. Then, internal qc for REQUEST

+ scmd. Note that as we already have completed and deallocated

+ registers. Errors which aren't ATA device errors are treated

+ forget about the timed out command and ready for new commands.

+ from usual command processing. On EH entrance, the device is

+ fail any time. pio_task and atapi_task may still be running.

+ mismatch errors and other errors quite often require reset to

+ ATA errors are directly handled in the interrupt handler and

+ information gathering and could trigger complex error handling

+ Third, scattered EH code makes implementing low level drivers

+ EH is scattered over several places, each affected callbacks

+ should perform its part of error handling. This can be error

+ This chapter tries to identify what error/exception conditions exist

+ for ATA/ATAPI devices and describe how they should be handled in

+ The term 'error' is used to describe conditions where either an

+ explicit error condition is reported from device or a command has

+ conditions which are not errors (say, power or hotplug events), or

+ to describe both errors and non-error exceptional conditions. Where

+ explicit distinction between error and exception is necessary, the

+ taskfile + bus master IDE interface. If a controller provides

+ other better mechanism for error reporting, mapping those into

+ reconfiguring transport - are mentioned. These are described

+ requirement during issuing or excution any ATA/ATAPI command.

+ ATA_STATUS doesn't contain !BSY && DRDY && !DRQ while trying

+ with an error before the last byte of the command packet has

+ As HSM is violated, reset is necessary to restore known state.

+ Reconfiguring transport for lower speed might be helpful too

+ <title>ATA/ATAPI device error (non-NCQ / non-CHECK CONDITION)</title>

+ of CDB is transferred *probably* indicates CHECK CONDITION and

+ Of errors detected as above, the followings are not ATA/ATAPI

+ <term>ABRT error during data transfer or on completion</term>

+ ATA/ATAPI device errors can be further categorized as follows.

+ cleared to zero by devices and thus need no explicit masking.

+ ATAPI device CHECK CONDITION error is indicated by set CHK bit

+ (ERR bit) in the STATUS register after the last byte of CDB is

+ sense data should be acquired to gather information regarding

+ may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR

+ cases, the error should be considered as an ATA bus error and

+ NCQ command error is indicated by cleared BSY and set ERR bit

+ required to clear the error condition, determine which command

+ information the failed command can be handled as a normal ATA

+ retried this way would have completed normally if it were not

+ transmission over ATA bus (SATA or PATA). This type of errors

+ ICRC or ABRT error as described in <xref linkend="excatDevErr"/>.

+ On some controllers, command timeout. In this case, there may

+ Unknown/random errors, timeouts and all sorts of weirdities.

+ As described above, transmission errors can cause wide variety

+ Data corruption or other failures during transmission over PCI

+ (or other system bus). For standard BMDMA, this is indicated

+ errors must be logged as it indicates something is very wrong

+ This occurs when timeout occurs and the timeout handler finds

+ out that the timed out command has completed successfully or

+ processing or the host and device are in unknown state. When

+ bring the device to known state and make it forget about the

+ Timeouts can also be caused by transmission errors. Refer to

+ Many controllers require its error registers to be cleared by

+ For SATA, it's strongly recommended to clear at least SError

+ Resetting during EH might be a good idea regardless of error

+ condition to improve EH robustness. Whether to reset both or

+ transaction may be sufficient iff BMDMA state is the only HBA

+ controllers may have implementation specific requirements and

+ <varlistentry><term>EXECUTE DEVICE DIAGNOSTIC command</term>

+ CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)

+ Parameters set with SET FEATURES including transfer mode setting

+ parameters after reset is required for robustness. Note that

+ this also applies when resuming from deep sleep (power-off).

+ parameter is updated or a hardware reset and the result used

+ connectors, cables or controllers and it's quite common to see

+ If more than $N (3?) transmission errors happen in 15 minutes,

+ if SATA, decrease SATA PHY speed. if speed cannot be decreased,

diff --git a/Documentation/DocBook/rapidio.tmpl b/Documentation/DocBook/rapidio.tmpl
new file mode 100644
index 000000000000..1becf27ba27e
--- /dev/null
+++ b/Documentation/DocBook/rapidio.tmpl

+ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [

+ it and/or modify it under the terms of the GNU General Public

+ License version 2 as published by the Free Software Foundation.

+ warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,

+ <listitem><para>Access/management of RapidIO memory regions is not supported</para></listitem>

+ <listitem><para>Multiple host enumeration is not supported</para></listitem>

+ This chapter contains the autogenerated documentation of the RapidIO

+ <listitem><para>Matt Porter<email>mporter@kernel.crashing.org</email></para></listitem>

+ <listitem><para>Randy Vinson<email>rvinson@mvista.com</email></para></listitem>

+ <listitem><para>Dan Malek<email>dan@embeddedalley.com</email></para></listitem>

+ <listitem><para>Matt Porter<email>mporter@kernel.crashing.org</email></para></listitem>

diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl
index 64be9f7ee3bb..3ccce886c349 100644
--- a/Documentation/DocBook/stylesheet.xsl
+++ b/Documentation/DocBook/stylesheet.xsl

diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl
index 705c442c7bf4..15ce0f21e5e0 100644
--- a/Documentation/DocBook/usb.tmpl
+++ b/Documentation/DocBook/usb.tmpl

diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl
index 51f3bfb6fb6e..008a341234d0 100644
--- a/Documentation/DocBook/writing_usb_driver.tmpl
+++ b/Documentation/DocBook/writing_usb_driver.tmpl

diff --git a/Documentation/HOWTO b/Documentation/HOWTO
new file mode 100644
index 000000000000..6c9e746267da
--- /dev/null
+++ b/Documentation/HOWTO

+This is the be-all, end-all document on this topic. It contains

+instructions on how to become a Linux kernel developer and how to learn

+to work with the Linux kernel development community. It tries to not

+contain anything related to the technical aspects of kernel programming,

+If anything in this document becomes out of date, please send in patches

+to the maintainer of this file, who is listed at the bottom of the

+So, you want to learn how to become a Linux kernel developer? Or you

+have been told by your manager, "Go write a Linux driver for this

+device." This document's goal is to teach you everything you need to

+know to achieve this by describing the process you need to go through,

+and hints on how to work with the community. It will also try to

+explain some of the reasons why the community works like it does.

+The kernel is written mostly in C, with some architecture-dependent

+parts written in assembly. A good understanding of C is required for

+kernel development. Assembly (any architecture) is not required unless

+you plan to do low-level development for that architecture. Though they

+are not a good substitute for a solid C education and/or years of

+experience, the following books are good for, if anything, reference:

+ - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]

+The kernel is written using GNU C and the GNU toolchain. While it

+adheres to the ISO C89 standard, it uses a number of extensions that are

+environment, with no reliance on the standard C library, so some

+portions of the C standard are not supported. Arbitrary long long

+divisions and floating point are not allowed. It can sometimes be

+difficult to understand the assumptions the kernel has on the toolchain

+and the extensions that it uses, and unfortunately there is no

+definitive reference for them. Please check the gcc info pages (`info

+Please remember that you are trying to learn how to work with the

+existing development community. It is a diverse group of people, with

+high standards for coding, style and procedure. These standards have

+been created over time based on what they have found to work best for

+such a large and geographically dispersed team. Try to learn as much as

+possible about these standards ahead of time, as they are well

+documented; do not expect people to adapt to you or your company's way

+The Linux kernel source code is released under the GPL. Please see the

+file, COPYING, in the main directory of the source tree, for details on

+the license. If you have further questions about the license, please

+contact a lawyer, and do not ask on the Linux kernel mailing list. The

+people on the mailing lists are not lawyers, and you should not rely on

+The Linux kernel source tree has a large range of documents that are

+invaluable for learning how to interact with the kernel community. When

+new features are added to the kernel, it is recommended that new

+documentation files are also added which explain how to use the feature.

+When a kernel change causes the interface that the kernel exposes to

+userspace to change, it is recommended that you send the information or

+a patch to the manual pages explaining the change to the manual pages

+Here is a list of files that are in the kernel source tree that are

+ This file gives a short background on the Linux kernel and describes

+ what is necessary to do to configure and build the kernel. People

+ This file gives a list of the minimum levels of various software

+ This describes the Linux kernel coding style, and some of the

+ guidelines in this document. Most maintainers will only accept

+ patches if these rules are followed, and many people will only

+ These files describe in explicit detail how to successfully create

+ Following these rules will not guarantee success (as all patches are

+ subject to scrutiny for content and style), but not following them

+ Other excellent descriptions of how to create patches properly are:

+ This file describes the rationale behind the conscious decision to

+ not have a stable API within the kernel, including things like:

+ This document is crucial for understanding the Linux development

+ philosophy and is very important for people moving to Linux from

+ If you feel you have found a security problem in the Linux kernel,

+ please follow the steps in this document to help notify the kernel

+ This document describes how Linux kernel maintainers operate and the

+ shared ethos behind their methodologies. This is important reading

+ for anyone new to kernel development (or anyone simply curious about

+ it), as it resolves a lot of common misconceptions and confusion

+ This file describes the rules on how the stable kernel releases

+ happen, and what to do if you want to get a change into one of these

+ development. Please consult this list if you do not find what you

+ A good introduction describing exactly what a patch is and how to

+ apply it to the different development branches of the kernel.

+automatically generated from the source code itself. This includes a

+full description of the in-kernel API, and rules on how to handle

+Documentation/DocBook/ directory and can be generated as PDF,

+If you do not know anything about Linux kernel development, you should

+It consists of a helpful mailing list where you can ask almost any type

+of basic kernel development question (make sure to search the archives

+first, before asking something that has already been answered in the

+past.) It also has an IRC channel that you can use to ask questions in

+real-time, and a lot of helpful documentation that is useful for

+The website has basic information about code organization, subsystems,

+and current projects (both in-tree and out-of-tree). It also describes

+some basic logistical information, like how to compile a kernel and

+If you do not know where you want to start, but you want to look for

+some task to start doing to join into the kernel development community,

+It is a great place to start. It describes a list of relatively simple

+problems that need to be cleaned up and fixed within the Linux kernel

+source tree. Working with the developers in charge of this project, you

+will learn the basics of getting your patch into the Linux kernel tree,

+and possibly be pointed in the direction of what to go work on next, if

+If you already have a chunk of code that you want to put into the kernel

+kernel-mentors project was created to help you out with this. It is a

+Before making any actual modifications to the Linux kernel code, it is

+imperative to understand how the code in question works. For this

+purpose, nothing is better than reading through it directly (most tricky

+bits are commented well), perhaps even with the help of specialized

+tools. One such tool that is particularly recommended is the Linux

+Cross-Reference project, which is able to present source code in a

+self-referential, indexed webpage format. An excellent up-to-date

+Linux kernel development process currently consists of a few different

+main kernel "branches" and lots of different subsystem-specific kernel

+2.6.x kernels are maintained by Linus Torvalds, and can be found on

+kernel.org in the pub/linux/kernel/v2.6/ directory. Its development

+ - As soon as a new kernel is released a two weeks window is open,

+ during this period of time maintainers can submit big diffs to

+ Linus, usually the patches that have already been included in the

+ -mm kernel for a few weeks. The preferred way to submit big changes

+ is using git (the kernel's source management tool, more information

+ can be found at http://git.or.cz/) but plain patches are also just

+ - After two weeks a -rc1 kernel is released it is now possible to push

+ only patches that do not include new features that could affect the

+ stability of the whole kernel. Please note that a whole new driver

+ (or filesystem) might be accepted after -rc1 because there is no

+ risk of causing regressions with such a change as long as the change

+ is self-contained and does not affect areas outside of the code that

+ is being added. git can be used to send patches to Linus after -rc1

+ is released, but the patches need to also be sent to a public

+ - A new -rc is released whenever Linus deems the current git tree to

+ be in a reasonably sane state adequate for testing. The goal is to

+ - Process continues until the kernel is considered "ready", the

+It is worth mentioning what Andrew Morton wrote on the linux-kernel

+ released according to perceived bug status, not according to a

+Kernels with 4 digit versions are -stable kernels. They contain

+relatively small and critical fixes for security problems or significant

+This is the recommended branch for users who want the most recent stable

+kernel and are not interested in helping test development/experimental

+If no 2.6.x.y kernel is available, then the highest numbered 2.6.x

+2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are

+The file Documentation/stable_kernel_rules.txt in the kernel tree

+documents what kinds of changes are acceptable for the -stable tree, and

+These are daily snapshots of Linus' kernel tree which are managed in a

+git repository (hence the name.) These patches are usually released

+daily and represent the current state of Linus' tree. They are more

+experimental than -rc kernels since they are generated automatically

+These are experimental kernel patches released by Andrew Morton. Andrew

+takes all of the different subsystem kernel trees and patches and mushes

+them together, along with a lot of patches that have been plucked from

+the linux-kernel mailing list. This tree serves as a proving ground for

+new features and patches. Once a patch has proved its worth in -mm for

+a while Andrew or the subsystem maintainer pushes it on to Linus for

+It is heavily encouraged that all new patches get tested in the -mm tree

+before they are sent to Linus for inclusion in the main kernel tree.

+These kernels are not appropriate for use on systems that are supposed

+to be stable and they are more risky to run than any of the other

+If you wish to help out with the kernel development process, please test

+and use these kernel releases and provide feedback to the linux-kernel

+mailing list if you have any problems, and if everything works properly.

+In addition to all the other experimental patches, these kernels usually

+also contain any changes in the mainline -git kernels available at the

+The -mm kernels are not released on a fixed schedule, but usually a few

+-mm kernels are released in between each -rc kernel (1 to 3 is common).

+A number of the different kernel subsystem developers expose their

+development trees so that others can see what is happening in the

+different areas of the kernel. These trees are pulled into the -mm

+Here is a list of some of the different kernel trees available:

+ kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

+ kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

+ - ieee1394 development tree, Jody McIntyre <scjody@modernduck.com>

+ Other git kernel trees can be found listed at http://kernel.org/git

+ - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>

+bugzilla.kernel.org is where the Linux kernel developers track kernel

+bugs. Users are encouraged to report all bugs that they find in this

+tool. For details on how to use the kernel bugzilla, please see:

+The file REPORTING-BUGS in the main kernel source directory has a good

+template for how to report a possible kernel bug, and details what kind

+of information is needed by the kernel developers to help track down the

+As some of the above documents describe, the majority of the core kernel

+developers participate on the Linux Kernel Mailing list. Details on how

+There are archives of the mailing list on the web in many different

+places. Use a search engine to find these archives. For example:

+It is highly recommended that you search the archives about the topic

+you want to bring up, before you post it to the list. A lot of things

+already discussed in detail are only recorded at the mailing list

+Most of the individual kernel subsystems also have their own separate

+mailing list where they do their development efforts. See the

+MAINTAINERS file for a list of what these lists are for the different

+Many of the lists are hosted on kernel.org. Information on them can be

+Please remember to follow good behavioral habits when using the lists.

+Though a bit cheesy, the following URL has some simple guidelines for

+If multiple people respond to your mail, the CC: list of recipients may

+get pretty large. Don't remove anybody from the CC: list without a good

+reason, or don't reply only to the list address. Get used to receiving the

+mail twice, one from the sender and the one from the list, and don't try

+to tune that by adding fancy mail-headers, people will not like it.

+Remember to keep the context and the attribution of your replies intact,

+keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and

+add your statements between the individual quoted sections instead of

+If you add patches to your mail, make sure they are plain readable text

+as stated in Documentation/SubmittingPatches. Kernel developers don't

+want to deal with attachments or compressed patches; they may want

+to comment on individual lines of your patch, which works only that way.

+Make sure you use a mail program that does not mangle spaces and tab

+characters. A good first test is to send the mail to yourself and try

+to apply your own patch by yourself. If that doesn't work, get your

+Above all, please remember to show respect to other subscribers.

+The goal of the kernel community is to provide the best possible kernel

+there is. When you submit a patch for acceptance, it will be reviewed

+on its technical merits and those alone. So, what should you be

+Remember, this is part of getting your patch into the kernel. You have

+to be able to take criticism and comments about your patches, evaluate

+them at a technical level and either rework your patches or provide

+clear and concise reasoning as to why those changes should not be made.

+If there are no responses to your posting, wait a few days and try

+ - resubmit the patch without making any of the requested changes

+In a community that is looking for the best technical solution possible,

+there will always be differing opinions on how beneficial a patch is.

+You have to be cooperative, and willing to adapt your idea to fit within

+the kernel. Or at least be willing to prove your idea is worth it.

+Remember, being wrong is acceptable as long as you are willing to work

+It is normal that the answers to your first patch might simply be a list

+of a dozen things you should correct. This does _not_ imply that your

+patch will not be accepted, and it is _not_ meant against you

+personally. Simply correct all issues raised against your patch and

+Differences between the kernel community and corporate structures

+-----------------------------------------------------------------

+The kernel community works differently than most traditional corporate

+development environments. Here are a list of things that you can try to

+ - "Here is a patch that explains what I am trying to describe."

+ - "We did it this way in AIX/ptx/Solaris, so therefore it must be

+ - "Here is my 1000 page design document that describes my idea"

+ - "I have a deadline, and this patch needs to be applied now."

+Another way the kernel community is different than most traditional

+software engineering work environments is the faceless nature of

+interaction. One benefit of using email and irc as the primary forms of

+communication is the lack of discrimination based on gender or race.

+The Linux kernel work environment is accepting of women and minorities

+because all you are is an email address. The international aspect also

+helps to level the playing field because you can't guess gender based on

+a person's name. A man may be named Andrea and a woman may be named Pat.

+Most women who have worked in the Linux kernel and have expressed an

+The language barrier can cause problems for some people who are not

+comfortable with English. A good grasp of the language can be needed in

+order to get ideas across properly on mailing lists, so it is

+recommended that you check your emails to make sure they make sense in

+The Linux kernel community does not gladly accept large chunks of code

+dropped on it all at once. The changes need to be properly introduced,

+discussed, and broken up into tiny, individual portions. This is almost

+the exact opposite of what companies are used to doing. Your proposal

+should also be introduced very early in the development process, so that

+you can receive feedback on what you are doing. It also lets the

+community feel that you are working with them, and not simply using them

+as a dumping ground for your feature. However, don't send 50 emails at

+one time to a mailing list, your patch series should be smaller than

+1) Small patches increase the likelihood that your patches will be

+ applied, since they don't take much time or effort to verify for

+ correctness. A 5 line patch can be applied by a maintainer with

+ barely a second glance. However, a 500 line patch may take hours to

+ Small patches also make it very easy to debug when something goes

+ wrong. It's much easier to back out patches one by one than it is

+ to dissect a very large patch after it's been applied (and broken

+2) It's important not only to send small patches, but also to rewrite

+ and simplify (or simply re-order) patches before submitting them.

+ "Think of a teacher grading homework from a math student. The

+ teacher does not want to see the student's trials and errors

+ cleanest, most elegant answer. A good student knows this, and

+It may be challenging to keep the balance between presenting an elegant

+solution and working together with the community and discussing your

+unfinished work. Therefore it is good to get early in the process to

+get feedback to improve your work, but also keep your changes in small

+chunks that they may get already accepted, even when your whole task is

+Also realize that it is not acceptable to send patches for inclusion

+Along with breaking up your patches, it is very important for you to let

+the Linux community know why they should add this change. New features

+When sending in your patches, pay special attention to what you say in

+the text in your email. This information will become the ChangeLog

+information for the patch, and will be preserved for everyone to see for

+all time. It should describe the patch completely, containing:

+For more details on what this should all look like, please see the

+All of these things are sometimes very hard to do. It can take years to

+perfect these practices (if at all). It's a continuous process of

+improvement that requires a lot of patience and determination. But

+don't give up, it's possible. Many have done it before, and each had to

+Thanks to Paolo Ciarrocchi who allowed the "Development Process" section

+to be based on text he had written, and to Randy Dunlap and Gerrit

+Huizenga for some of the list of things you should and should not say.

+Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,

+Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi

+Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,

+David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for

+their review, comments, and contributions. Without their help, this

diff --git a/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt
index 63edc5f847c4..3ec6c720b016 100644
--- a/Documentation/MSI-HOWTO.txt
+++ b/Documentation/MSI-HOWTO.txt

This guide describes the basics of Message Signaled Interrupts (MSI),

the advantages of using MSI over traditional interrupt mechanisms,

and how to enable your driver to use MSI or MSI-X. Also included is

+PCI devices can be single-function or multi-function. In either case,

+when this text talks about enabling or disabling MSI on a "device

+function," it is referring to one specific PCI device and function and

+not to all functions on a PCI device (unless the PCI device has only

Message Signaled Interrupt (MSI), as described in the PCI Local Bus

-Specification Revision 2.3 or latest, is an optional feature, and a

+Specification Revision 2.3 or later, is an optional feature, and a

required feature for PCI Express devices. MSI enables a device function

to request service by sending an Inbound Memory Write on its PCI bus to

the FSB as a Message Signal Interrupt transaction. Because MSI is

A PCI device that supports MSI must also support pin IRQ assertion

interrupt mechanism to provide backward compatibility for systems that

-do not support MSI. In Systems, which support MSI, the bus driver is

+do not support MSI. In systems which support MSI, the bus driver is

responsible for initializing the message address and message data of

the device function's MSI/MSI-X capability structure during device

@@ -61,17 +69,17 @@ over the MSI capability structure as described below.

+ feature for MSI-X. Per-vector masking provides the kernel the

-As a benefit the simplification of board design, MSI allows board

-designers to remove out of band interrupt routing. MSI is another

+As a benefit to the simplification of board design, MSI allows board

+designers to remove out-of-band interrupt routing. MSI is another

Due to increasing pressure on chipset and processor packages to

@@ -87,7 +95,7 @@ support. As a result, the PCI Express technology requires MSI

-vectors, which can be configured to target different CPU's to

-With this new API, any existing device driver, which like to have

-MSI enabled on its device function, must call this API to enable MSI

+enabled on its device function must call this API to enable MSI.

A successful call will initialize the MSI capability structure

capable of supporting multiple messages. This vector replaces the

-pre-assigned dev->irq with a new MSI vector. To avoid the conflict

-of new assigned vector with existing pre-assigned vector requires

+pre-assigned dev->irq with a new MSI vector. To avoid a conflict

+of the new assigned vector with existing pre-assigned vector requires

a device driver to call this API before calling request_irq().

@@ -137,14 +145,14 @@ when a device driver is unloading. This API restores dev->irq with

the pre-assigned IOAPIC vector and switches a device's interrupt

-Note that a device driver should always call free_irq() on MSI vector

-it has done request_irq() on before calling this API. Failure to do

-so results a BUG_ON() and a device will be left with MSI enabled and

+Note that a device driver should always call free_irq() on the MSI vector

+that it has done request_irq() on before calling this API. Failure to do

+so results in a BUG_ON() and a device will be left with MSI enabled and

-The below diagram shows the events, which switches the interrupt

+The below diagram shows the events which switch the interrupt

-In Figure 1.0, a device operates by default in legacy mode. Legacy

+In Figure 1, a device operates by default in legacy mode. Legacy

in this context means PCI pin-irq assertion or PCI-Express INTx

emulation. A successful MSI request (using pci_enable_msi()) switches

a device's interrupt mode to MSI mode. A pre-assigned IOAPIC vector

@@ -166,11 +174,11 @@ assigned MSI vector will replace dev->irq.

To return back to its default mode, a device driver should always call

pci_disable_msi() to undo the effect of pci_enable_msi(). Note that a

-device driver should always call free_irq() on MSI vector it has done

-request_irq() on before calling pci_disable_msi(). Failure to do so

-results a BUG_ON() and a device will be left with MSI enabled and

+device driver should always call free_irq() on the MSI vector it has

+done request_irq() on before calling pci_disable_msi(). Failure to do

+so results in a BUG_ON() and a device will be left with MSI enabled and

leaks its vector. Otherwise, the PCI subsystem restores a device's

-dev->irq with a pre-assigned IOAPIC vector and marks released

+dev->irq with a pre-assigned IOAPIC vector and marks the released

Once being marked as unused, there is no guarantee that the PCI

@@ -178,8 +186,8 @@ subsystem will reserve this MSI vector for a device. Depending on

the availability of current PCI vector resources and the number of

MSI/MSI-X requests from other drivers, this MSI may be re-assigned.

-For the case where the PCI subsystem re-assigned this MSI vector

-another driver, a request to switching back to MSI mode may result

+For the case where the PCI subsystem re-assigns this MSI vector to

+another driver, a request to switch back to MSI mode may result

in being assigned a different MSI vector or a failure if no more

@@ -208,12 +216,12 @@ Unlike the function pci_enable_msi(), the function pci_enable_msix()

does not replace the pre-assigned IOAPIC dev->irq with a new MSI

vector because the PCI subsystem writes the 1:1 vector-to-entry mapping

into the field vector of each element contained in a second argument.

-Note that the pre-assigned IO-APIC dev->irq is valid only if the device

-operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt of

+Note that the pre-assigned IOAPIC dev->irq is valid only if the device

+operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at

using dev->irq by the device driver to request for interrupt service

-For each MSI-X vector granted, a device driver is responsible to call

+For each MSI-X vector granted, a device driver is responsible for calling

other functions like request_irq(), enable_irq(), etc. to enable

this vector with its corresponding interrupt service handler. It is

The PCI 3.0 specification has implementation notes that MMIO address

space for a device's MSI-X structure should be isolated so that the

-software system can set different page for controlling accesses to

-the MSI-X structure. The implementation of MSI patch requires the PCI

+software system can set different pages for controlling accesses to the

+MSI-X structure. The implementation of MSI support requires the PCI

subsystem, not a device driver, to maintain full control of the MSI-X

-table/MSI-X PBA and MMIO address space of the MSI-X table/MSI-X PBA.

-A device driver is prohibited from requesting the MMIO address space

-of the MSI-X table/MSI-X PBA. Otherwise, the PCI subsystem will fail

-enabling MSI-X on its hardware device when it calls the function

+table/MSI-X PBA (Pending Bit Array) and MMIO address space of the MSI-X

+table/MSI-X PBA. A device driver is prohibited from requesting the MMIO

+address space of the MSI-X table/MSI-X PBA. Otherwise, the PCI subsystem

+will fail enabling MSI-X on its hardware device when it calls the function

@@ -274,9 +282,9 @@ For the case where fewer MSI-X vectors are allocated to a function

than requested, the function pci_enable_msix() will return the

maximum number of MSI-X vectors available to the caller. A device

driver may re-send its request with fewer or equal vectors indicated

-in a return. For example, if a device driver requests 5 vectors, but

-the number of available vectors is 3 vectors, a value of 3 will be a

-return as a result of pci_enable_msix() call. A function could be

+in the return. For example, if a device driver requests 5 vectors, but

+the number of available vectors is 3 vectors, a value of 3 will be

+returned as a result of pci_enable_msix() call. A function could be

different combinations as ABC--, A-B-C, A--CB, etc. Note that this

patch does not support multiple entries with the same vector. Such

@@ -285,49 +293,46 @@ as ABBCC, AABCC, BCCBA, etc will result as a failure by the function

pci_enable_msix(). Below are the reasons why supporting multiple

+ - Walking through all MSI-X table entries (2048 max) to handle

-int pci_enable_msix(struct pci_dev *dev, u32 *entries, int nvec)

+int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)

-for enabling MSI-X messages on its hardware device. Depending on

+to enable MSI-X messages on its hardware device. Depending on

the availability of PCI vectors resources, the PCI subsystem enables

-Argument entries is a pointer of unsigned integer type. The number of

-elements is indicated in argument nvec. The content of each element

-will be mapped to the following struct defined in /driver/pci/msi.h.

+Argument 'entries' is a pointer to an array of msix_entry structs.

-A device driver is responsible for initializing the field entry of

-each element with unique entry supported by MSI-X table. Otherwise,

+A device driver is responsible for initializing the field 'entry' of

+each element with a unique entry supported by MSI-X table. Otherwise,

-EINVAL will be returned as a result. A successful return of zero

-indicates the PCI subsystem completes initializing each of requested

+indicates the PCI subsystem completed initializing each of the requested

entries of the MSI-X table with message address and message data.

-vector-to-entry mapping into the field vector of each element. A

-device driver is responsible of keeping track of allocated MSI-X

+vector-to-entry mapping into the field 'vector' of each element. A

+device driver is responsible for keeping track of allocated MSI-X

-Argument nvec is an integer indicating the number of messages

-A return of zero indicates that the number of MSI-X vectors is

+A return of zero indicates that the number of MSI-X vectors was

successfully allocated. A return of greater than zero indicates

MSI-X vector shortage. Or a return of less than zero indicates

@@ -341,12 +346,12 @@ void pci_disable_msix(struct pci_dev *dev)

This API should always be used to undo the effect of pci_enable_msix()

when a device driver is unloading. Note that a device driver should

always call free_irq() on all MSI-X vectors it has done request_irq()

-on before calling this API. Failure to do so results a BUG_ON() and

+on before calling this API. Failure to do so results in a BUG_ON() and

a device will be left with MSI-X enabled and leaks its vectors.

-The below diagram shows the events, which switches the interrupt

+The below diagram shows the events which switch the interrupt

mode on the MSI-X capable device function between MSI-X mode and

-In Figure 2.0, a device operates by default in legacy mode. A

device's interrupt mode to MSI-X mode. A pre-assigned IOAPIC vector

stored in dev->irq will be saved by the PCI subsystem; however,

unlike MSI mode, the PCI subsystem will not replace dev->irq with

assigned MSI-X vector because the PCI subsystem already writes the 1:1

-vector-to-entry mapping into the field vector of each element

+vector-to-entry mapping into the field 'vector' of each element

To return back to its default mode, a device driver should always call

pci_disable_msix() to undo the effect of pci_enable_msix(). Note that

a device driver should always call free_irq() on all MSI-X vectors it

has done request_irq() on before calling pci_disable_msix(). Failure

-to do so results a BUG_ON() and a device will be left with MSI-X

+to do so results in a BUG_ON() and a device will be left with MSI-X

enabled and leaks its vectors. Otherwise, the PCI subsystem switches a

device function's interrupt mode from MSI-X mode to legacy mode and

@@ -383,53 +388,56 @@ MSI/MSI-X requests from other drivers, these MSI-X vectors may be

For the case where the PCI subsystem re-assigned these MSI-X vectors

-to other driver, a request to switching back to MSI-X mode may result

+to other drivers, a request to switch back to MSI-X mode may result

being assigned with another set of MSI-X vectors or a failure if no

-5.4 Handling function implementng both MSI and MSI-X capabilities

+5.4 Handling function implementing both MSI and MSI-X capabilities

capabilities, the PCI subsystem enables a device to run either in MSI

mode or MSI-X mode but not both. A device driver determines whether it

wants MSI or MSI-X enabled on its hardware device. Once a device

-driver requests for MSI, for example, it is prohibited to request for

+driver requests for MSI, for example, it is prohibited from requesting

MSI-X; in other words, a device driver is not permitted to ping-pong

MSI/MSI-X support requires support from both system hardware and

Since the target of MSI address is the local APIC CPU, enabling

-MSI/MSI-X support in Linux kernel is dependent on whether existing

-system hardware supports local APIC. Users should verify their

+MSI/MSI-X support in the Linux kernel is dependent on whether existing

+system hardware supports local APIC. Users should verify that their

+system supports local APIC operation by testing that it runs when

In SMP environment, CONFIG_X86_LOCAL_APIC is automatically set;

-the option for MSI-capable device drivers to selectively enable

+CONFIG_PCI_MSI enables the VECTOR based scheme and the option for

Note that CONFIG_X86_IO_APIC setting is irrelevant because MSI/MSI-X

vector is allocated new during runtime and MSI/MSI-X support does not

depend on BIOS support. This key independency enables MSI/MSI-X

the kernel to enable MSI during the system boot. In other words,

the device function is running on its default pin assertion mode.

Note that in many cases the hardware supporting MSI have bugs,

-which may result in system hang. The software driver of specific

+which may result in system hangs. The software driver of specific

+MSI-capable hardware is responsible for deciding whether to call

-successfully initializes the MSI/MSI-X capability structure of the

+successfully initialized the MSI/MSI-X capability structure of the

device function. The device function is now running on MSI/MSI-X mode.

5.6 How to tell whether MSI/MSI-X is enabled on device function

@@ -439,10 +447,10 @@ pci_enable_msi()/pci_enable_msix() indicates to a device driver that

its device function is initialized successfully and ready to run in

-At the user level, users can use command 'cat /proc/interrupts'

-to display the vector allocated for a device and its interrupt

-MSI/MSI-X mode ("PCI MSI"/"PCI MSIX"). Below shows below MSI mode is

+At the user level, users can use the command 'cat /proc/interrupts'

+to display the vectors allocated for devices and their interrupt

+MSI/MSI-X modes ("PCI-MSI"/"PCI-MSI-X"). Below shows MSI mode is

@@ -453,8 +461,8 @@ enabled on a SCSI Adaptec 39320D Ultra320.

@@ -490,8 +498,8 @@ target address set as 0xfeexxxxx, as conformed to PCI

diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
new file mode 100644
index 000000000000..e4c38152f7f7
--- /dev/null
+++ b/Documentation/RCU/torture.txt

+The CONFIG_RCU_TORTURE_TEST config option is available for all RCU

+implementations. It creates an rcutorture kernel module that can

+be loaded to run a torture test. The test periodically outputs

+status messages via printk(), which can be examined via the dmesg

+command (perhaps grepping for "rcutorture"). The test is started

+when the module is loaded, and stops when the module is unloaded.

+However, actually setting this config option to "y" results in the system

+running the test immediately upon boot, and ending only when the system

+is taken down. Normally, one will instead want to build the system

+with CONFIG_RCU_TORTURE_TEST=m and to use modprobe and rmmod to control

+the test, perhaps using a script similar to the one shown at the end of

+this document. Note that you will need CONFIG_MODULE_UNLOAD in order

+nreaders This is the number of RCU reading threads supported.

+stat_interval The number of seconds between output of torture

+ rcutorture: --- Start of test: nreaders=16 stat_interval=0 verbose=0

+ rcutorture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915

+ rcutorture: Free-Block Circulation: 1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0

+The command "dmesg | grep rcutorture:" will extract this information on

+most systems. On more esoteric configurations, it may be necessary to

+use other commands to access the output of the printk()s used by

+the RCU torture test. The printk()s use KERN_ALERT, so they should

+o "ggp": The number of counter flips (or batches) since boot.

+o "rtc": The hexadecimal address of the structure currently visible

+o "ver": The number of times since boot that the rcutw writer task

+ containing structure to be placed into the "rtc" area is empty.

+ This condition is important, since it can fool you into thinking

+o "rta": Number of structures allocated from the torture freelist.

+o "rtaf": Number of allocations from the torture freelist that have

+o "Reader Pipe": Histogram of "ages" of structures seen by readers.

+ If any entries past the first two are non-zero, RCU is broken.

+ And rcutorture prints the error flag string "!!!" to make sure

+ incremented once per grace period subsequently -- and is freed

+ after passing through (RCU_TORTURE_PIPE_LEN-2) grace periods.

+ The output displayed above was taken from a correctly working

+ RCU. If you want to see what it looks like when broken, break

+o "Reader Batch": Another histogram of "ages" of structures seen

+ by readers, but in terms of counter flips (or batches) rather

+ than in terms of grace periods. The legal number of non-zero

+o "Free-Block Circulation": Shows the number of torture structures

+ that have reached a given point in the pipeline. The first element

+ should closely correspond to the number of structures allocated,

+ the second to the number that have been removed from reader view,

+ and all but the last remaining to the corresponding number of

+ passes through a grace period. The last entry should be zero,

+The output can be manually inspected for the error flag of "!!!".

+One could of course create a more elaborate script that automatically

diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 354d89c78377..15da16861fa3 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 7f43b040311e..237d54c44bc5 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches

@@ -301,8 +301,84 @@ now, but you can do this to mark internal company procedures or just

+The Subject line format makes it very easy to sort the emails

+alphabetically by subject line - pretty much any email reader will

+support that - since because the sequence number is zero-padded,

+phrase" should not be a filename. Do not use the same "summary

+later be used in developer discussions which refer to the patch.

+ Subject: [patch 2/5] ext2: improve scalability of bitmap searching

+The "from" line must be the very first line in the message body,

+The "from" line specifies who will be credited as the author of the

+patch in the permanent changelog. If the "from" line is missing,

+then the "From:" line from the email header will be used to determine

+The explanation body will be committed to the permanent source

+changelog, so should make sense to a competent reader who has long

+since forgotten the immediate details of the discussion that might

+The "---" marker line serves the essential purpose of marking for patch

+One good use for the additional comments after the "---" marker is for

+a diffstat, to show what files have changed, and the number of inserted

+and deleted lines per file. A diffstat is especially useful on bigger

+patches. Other comments relevant only to the moment or the maintainer,

+not suitable for the permanent changelog, should also go here.

@@ -310,6 +386,14 @@ Andrew Morton, "The perfect patch" (tpp).

+ <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>

diff --git a/Documentation/arm/README b/Documentation/arm/README
index a6f718e90a86..5ed6f3530b86 100644
--- a/Documentation/arm/README
+++ b/Documentation/arm/README

In order to compile ARM Linux, you will need a compiler capable of

- generating ARM ELF code with GNU extensions. GCC 2.95.1, EGCS

- 1.1.2, and GCC 3.3 are known to be good compilers. Fortunately, you

- needn't guess. The kernel will report an error if your compiler is

+ generating ARM ELF code with GNU extensions. GCC 3.3 is known to be

+ a good compiler. Fortunately, you needn't guess. The kernel will report

To build ARM Linux natively, you shouldn't have to alter the ARCH = line

in the top level Makefile. However, if you don't have the ARM Linux ELF

diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt
index 3af4d29a8938..89aa89d526ac 100644
--- a/Documentation/arm/Samsung-S3C24XX/Overview.txt
+++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt

Any large scale modifications, or new drivers should be discussed

on the ARM kernel mailing list (linux-arm-kernel) before being

+ attempted. See http://www.arm.linux.org.uk/mailinglists/ for the

+ Whenever a device has platform specific data that is specified

+ 1) that default data is not left in the device to confuse the

+ the function `__init` takes care of ensuring it is discarded

+ static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd)

+ npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL);

08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction

diff --git a/Documentation/arm/VFP/release-notes.txt b/Documentation/arm/VFP/release-notes.txt
index f28e0222f5e5..28a2795705ca 100644
--- a/Documentation/arm/VFP/release-notes.txt
+++ b/Documentation/arm/VFP/release-notes.txt

@@ -12,7 +12,7 @@ This release has been validated against the SoftFloat-2b library by

John R. Hauser using the TestFloat-2a test suite. Details of this

- http://www.cs.berkeley.edu/~jhauser/arithmetic/SoftFloat.html

diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
index 4b1c93a8177b..dc6045577a8b 100644
--- a/Documentation/arm/memory.txt
+++ b/Documentation/arm/memory.txt

This document describes the virtual memory layout which the Linux

kernel uses for ARM processors. It indicates which regions are

@@ -37,6 +37,8 @@ ff000000 ffbfffff Reserved for future expansion of DMA

diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index 8eedaa24f5e2..23a1c2402bcc 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt

@@ -115,6 +115,33 @@ boolean is return which indicates whether the resulting counter value

is negative. It requires explicit memory barrier semantics around the

+This performs an atomic compare exchange operation on the atomic value v,

+with the given old and new values. Like all atomic_xxx operations,

+atomic_cmpxchg will only satisfy its atomicity semantics as long as all

+other accesses of *v are performed through atomic_xxx operations.

+atomic_cmpxchg requires explicit memory barriers around the operation.

+The semantics for atomic_cmpxchg are the same as those defined for 'cas'

+If the atomic value v is not equal to u, this function adds a to v, and

+returns non zero. If v is equal to u then it returns zero. This is done as

+atomic_add_unless requires explicit memory barriers around the operation.

+atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)

If a caller requires memory barrier semantics around an atomic_t

operation which does not return a value, a set of interfaces are

diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 6dd274d7e1cf..0fe01c805480 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt

-I/O schedulers are now per queue. They should be runtime switchable and modular

-but aren't yet. Jens has most bits to do this, but the sysfs implementation is

+I/O scheduler, a.k.a. elevator, is implemented in two layers. Generic dispatch

+queue and specific I/O schedulers. Unless stated otherwise, elevator is used

+to refer to both parts and I/O scheduler to specific I/O schedulers.

+Block layer implements generic dispatch queue in ll_rw_blk.c and elevator.c.

+The generic dispatch queue is responsible for properly ordering barrier

+requests, requeueing, handling non-fs requests and all other subtleties.

+Specific I/O schedulers are responsible for ordering normal filesystem

+requests. They can also choose to delay certain requests to improve

+throughput or whatever purpose. As the plural form indicates, there are

+multiple I/O schedulers. They can be built as modules but at least one should

+be built inside the kernel. Each queue can choose different one and can also

A block layer call to the i/o scheduler follows the convention elv_xxx(). This

calls elevator_xxx_fn in the elevator switch (drivers/block/elevator.c). Oh,

The functions an elevator may implement are: (* are mandatory)

elevator_merge_fn called to query requests for merge with a bio

+elevator_merge_req_fn called when two requests get merged. the one

elevator_merged_fn called when a request in the scheduler has been

-*elevator_next_req_fn returns the next scheduled request, or NULL

+elevator_dispatch_fn fills the dispatch queue with ready requests.

-*elevator_add_req_fn called to add a new request into the scheduler

+elevator_add_req_fn called to add a new request into the scheduler

elevator_queue_empty_fn returns true if the merge queue is empty.

-elevator_remove_req_fn This is called when a driver claims ownership of

-elevator_requeue_req_fn called to add a request to the scheduler. This

elevator_latter_req_fn These return the request before or after the

-elevator_completed_req_fn called when a request is completed. This might

+elevator_completed_req_fn called when a request is completed.

elevator_may_queue_fn returns true if the scheduler wants to allow the

@@ -967,13 +970,33 @@ elevator_may_queue_fn returns true if the scheduler wants to allow the

elevator_put_req_fn Must be used to allocate and free any elevator

+elevator_activate_req_fn Called when device driver first sees a request.

+elevator_deactivate_req_fn Called when device driver decides to delay

elevator_exit_fn Allocate and free any elevator specific storage

+All requests seens by I/O schedulers strictly follow one of the following three

+ i. add_req_fn -> (merged_fn ->)* -> dispatch_fn -> activate_req_fn ->

+ (deactivate_req_fn -> activate_req_fn ->)* -> completed_req_fn

The generic i/o scheduler algorithm attempts to sort/merge/batch requests for

optimal disk scan and request servicing performance (based on generic

@@ -993,18 +1016,7 @@ request in sort order to prevent binary tree lookups.

This arrangement is not a generic block layer characteristic however, so

-The last merge hint is part of the generic queue layer. I/O schedulers must do

-some management on it. For the most part, the most important thing is to make

-sure q->last_merge is cleared (set to NULL) when the request on it is no longer

-a candidate for merging (for example if it has been sent to the driver).

-The last merge performed is cached as a hint for the subsequent request. If

-sequential data is being submitted, the hint is used to perform merges without

-any scanning. This is not sufficient when there are multiple processes doing

AS and deadline use a hash table indexed by the last sector of a request. This

enables merging code to quickly look up "back merge" candidates, even when

@@ -1013,29 +1025,8 @@ multiple I/O streams are being performed at once on one disk.

are far less common than "back merges" due to the nature of most I/O patterns.

Front merges are handled by the binary trees in AS and deadline schedulers.

-A request with flags REQ_HARDBARRIER or REQ_SOFTBARRIER must not be ordered

-around. That is, they must be processed after all older requests, and before

-In AS and deadline schedulers, barriers have the effect of flushing the reorder

-queue. The performance cost of this will vary from nothing to a lot depending

-on i/o patterns and device characteristics. Obviously they won't improve

-A request may be inserted with a position directive. The directives are one of

-ELEVATOR_INSERT_BACK, ELEVATOR_INSERT_FRONT, ELEVATOR_INSERT_SORT.

-ELEVATOR_INSERT_SORT is a general directive for non-barrier requests.

-ELEVATOR_INSERT_BACK is used to insert a barrier to the back of the queue.

-ELEVATOR_INSERT_FRONT is used to insert a barrier to the front of the queue, and

-overrides the ordering requested by any previous barriers. In practice this is

-harmless and required, because it is used for SCSI requeueing. This does not

-require flushing the reorder queue, so does not impose a performance penalty.

-vi. Plugging the queue to batch requests in anticipation of opportunities for

+iii. Plugging the queue to batch requests in anticipation of opportunities for

This is just the same as in 2.4 so far, though per-device unplugging

support is anticipated for 2.5. Also with a priority-based i/o scheduler,

I/O contexts provide a dynamically allocated per process data area. They may

be used in I/O schedulers, and in the block layer (could be used for IO statis,

-priorities for example). See *io_context in drivers/block/ll_rw_blk.c, and

+priorities for example). See *io_context in block/ll_rw_blk.c, and as-iosched.c

diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index e132fb1163b0..7eb715e07eda 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt

4) void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)

diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt
index 68a711fb82cf..15378422fc46 100644
--- a/Documentation/cciss.txt
+++ b/Documentation/cciss.txt

@@ -133,3 +133,32 @@ hardware and it is important to prevent the kernel from attempting to directly

access these devices too, as if the array controller were merely a SCSI

controller in the same way that we are allowing it to access SCSI tape drives.

+The linux SCSI mid layer provides an error handling protocol which

+kicks into gear whenever a SCSI command fails to complete within a

+certain amount of time (which can vary depending on the command).

+The cciss driver participates in this protocol to some extent. The

+normal protocol is a four step process. First the device is told

+to abort the command. If that doesn't work, the device is reset.

+If that doesn't work, the SCSI bus is reset. If that doesn't work

+the host bus adapter is reset. Because the cciss driver is a block

+driver as well as a SCSI driver and only the tape drives and medium

+changers are presented to the SCSI mid layer, and unlike more

+straightforward SCSI drivers, disk i/o continues through the block

+side during the SCSI error recovery process, the cciss driver only

+implements the first two of these actions, aborting the command, and

+resetting the device. Additionally, most tape drives will not oblige

+in aborting commands, and sometimes it appears they will not even

+obey a reset coommand, though in most circumstances they will. In

+the case that the command cannot be aborted and the device cannot be

+In the event the error handling code is triggered and a tape drive is

+successfully reset or the tardy command is successfully aborted, the

+tape drive may still not allow i/o to continue until some command

+is issued which positions the tape to a known position. Typically you

+must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example)

+before i/o can proceed again to a tape drive which was reset.

diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c
index b7de82e9c0e0..3e73231695b3 100644
--- a/Documentation/connector/cn_test.c
+++ b/Documentation/connector/cn_test.c

diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt
index 54a0a14bfbe3..57a314b14cf8 100644
--- a/Documentation/connector/connector.txt
+++ b/Documentation/connector/connector.txt

@@ -131,3 +131,47 @@ Netlink itself is not reliable protocol, that means that messages can

be lost due to memory pressure or process' receiving queue overflowed,

so caller is warned must be prepared. That is why struct cn_msg [main

connector's message header] contains u32 seq and u32 ack fields.

+2.6.14 has a new netlink socket implementation, which by default does not

+with different group number userspace application must subscribe to

+if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) {

+Where 270 above is SOL_NETLINK, and 1 is a NETLINK_ADD_MEMBERSHIP socket

+option. To drop multicast subscription one should call above socket option

+with NETLINK_DROP_MEMBERSHIP parameter which is defined as 0.

+2.6.14 netlink code only allows to select a group which is less or equal to

+the maximum group number, which is used at netlink_kernel_create() time.

+In case of connector it is CN_NETLINK_USERS + 0xf, so if you want to use

+group number 12345, you must increment CN_NETLINK_USERS to that number.

+Additional 0xf numbers are allocated to be used by non-in-kernel users.

+Due to this limitation, group 0xffffffff does not work now, so one can

+not use add/remove connector's group notifications, but as far as I know,

+Some work in netlink area is still being done, so things can be changed in

+2.6.15 timeframe, if it will happen, documentation will be updated for that

diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt
index d17b7d2dd771..a09a8eb80665 100644
--- a/Documentation/cpusets.txt
+++ b/Documentation/cpusets.txt

@@ -94,7 +94,7 @@ the available CPU and Memory resources amongst the requesting tasks.

But larger systems, which benefit more from careful processor and

memory placement to reduce memory access times and contention,

and which typically represent a larger investment for the customer,

-can benefit from explictly placing jobs on properly sized subsets of

+can benefit from explicitly placing jobs on properly sized subsets of

diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
index 95d7f62e4dbc..941343a7a265 100644
--- a/Documentation/dell_rbu.txt
+++ b/Documentation/dell_rbu.txt

@@ -35,6 +35,7 @@ The driver load creates the following directories under the /sys file system.

The driver supports two types of update mechanism; monolithic and packetized.

These update mechanism depends upon the BIOS currently running on the system.

@@ -47,8 +48,26 @@ By default the driver uses monolithic memory for the update type. This can be

changed to packets during the driver load time by specifying the load

parameter image_type=packet. This can also be changed later as below

-Also echoing either mono ,packet or init in to image_type will free up the

+In packet update mode the packet size has to be given before any packets can

+In the packet update mechanism, the user neesd to create a new file having

+packets of data arranged back to back. It can be done as follows

+The user creates packets header, gets the chunk of the BIOS image and

+placs it next to the packetheader; now, the packetheader + BIOS image chunk

+added to geather should match the specified packet_size. This makes one

+packet, the user needs to create more such packets out of the entire BIOS

+image file and then arrange all these packets back to back in to one single

+This file is then copied to /sys/class/firmware/dell_rbu/data.

+Once this file gets to the driver, the driver extracts packet_size data from

+the file and spreads it accross the physical memory in contiguous packet_sized

+This method makes sure that all the packets get to the driver in a single operation.

+In monolithic update the user simply get the BIOS image (.hdr file) and copies

+to the data file as is without any change to the BIOS image itself.

@@ -58,7 +77,10 @@ Do the steps below to download the BIOS image.

The /sys/class/firmware/dell_rbu/ entries will remain till the following is

+Also echoing either mono ,packet or init in to image_type will free up the

If an user by accident executes steps 1 and 3 above without executing step 2;

it will make the /sys/class/firmware/dell_rbu/ entries to disappear.

@@ -66,15 +88,11 @@ echo init > /sys/devices/platform/dell_rbu/image_type

NOTE: echoing init in image_type does not change it original value.

Also the driver provides /sys/devices/platform/dell_rbu/data readonly file to

-read back the image downloaded. This is useful in case of packet update

-mechanism where the above steps 1,2,3 will repeated for every packet.

-By reading the /sys/devices/platform/dell_rbu/data file all packet data

-The packets are arranged in this file one after the other in a FIFO order.

-This driver requires a patch for firmware_class.c which has the addition

+This driver requires a patch for firmware_class.c which has the modified

Also after updating the BIOS image an user mdoe application neeeds to execute

code which message the BIOS update request to the BIOS. So on the next reboot

the BIOS knows about the new image downloaded and it updates it self.

diff --git a/Documentation/device-mapper/snapshot.txt b/Documentation/device-mapper/snapshot.txt
new file mode 100644
index 000000000000..a5009c8300f3
--- /dev/null
+++ b/Documentation/device-mapper/snapshot.txt

+*) To create snapshots of any block device i.e. mountable, saved states of

+the block device which are also writable without interfering with the

+*) To create device "forks", i.e. multiple different versions of the

+In both cases, dm copies only the chunks of data that get changed and

+uses a separate copy-on-write (COW) block device for storage.

+There are two dm targets available: snapshot and snapshot-origin.

+Reads will be mapped directly to the backing device. For each write, the

+original data will be saved in the <COW device> of each snapshot to keep

+its visible content unchanged, at least until the <COW device> fills up.

+A snapshot of the <origin> block device is created. Changed chunks of

+<chunksize> sectors will be stored on the <COW device>. Writes will

+only go to the <COW device>. Reads will come from the <COW device> or

+smaller than the origin and if it fills up the snapshot will become

+useless and be disabled, returning errors. So it is important to monitor

+the amount of free space and expand the <COW device> before it fills up.

+<persistent?> is P (Persistent) or N (Not persistent - will not survive

+The difference is that for transient snapshots less metadata must be

+When you create the first LVM2 snapshot of a volume, four dm devices are used:

+1) a device containing the original mapping table of the source volume;

+3) a "snapshot" device, combining #1 and #2, which is the visible snapshot

+4) the "original" volume (which uses the device number used by the original

+ source volume), whose table is replaced by a "snapshot-origin" mapping

+A fixed naming scheme is used, so with the following commands:

+brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real

+brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow

+brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap

+brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base

diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 0f515175c72a..3c406acd4dfa 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt

196 = /dev/dvb/adapter3/video0 first video decoder of fourth card

diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index fabaca1ab1b0..59806c9761f7 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt

- int (*suspend) (struct device * dev, pm_message_t state, u32 level);

@@ -194,69 +194,13 @@ device; i.e. anything in the device's driver_data field.

If the device is still present, it should quiesce the device and place

- int (*suspend) (struct device * dev, pm_message_t state, u32 level);

-suspend is called to put the device in a low power state. There are

-several stages to successfully suspending a device, which is denoted in

-the @level parameter. Breaking the suspend transition into several

-stages affords the platform flexibility in performing device power

-SUSPEND_NOTIFY notifies the device that a suspend transition is about

-to happen. This happens on system power state transitions to verify

-A driver may choose to fail on this call, which should cause the

-entire suspend transition to fail. A driver should fail only if it

-knows that the device will not be able to be resumed properly when the

-system wakes up again. It could also fail if it somehow determines it

-SUSPEND_DISABLE tells the device to stop I/O transactions. When it

-stops transactions, or what it should do with unfinished transactions

-is a policy of the driver. After this call, the driver should not

-SUSPEND_SAVE_STATE tells the device to save the context of the

-device-specific hardware state. A pointer to this saved state can be

-SUSPEND_POWER_DOWN tells the driver to place the device in the low

-Whether suspend is called with a given level is a policy of the

-platform. Some levels may be omitted; drivers must not assume the

-reception of any level. However, all levels must be called in the

-order above; i.e. notification will always come before disabling;

-Resume is used to bring a device back from a low power state. Like the

-RESUME_POWER_ON tells the driver to set the power state to the state

-before the suspend call (The device could have already been in a low

-power state before the suspend call to put in a lower power state).

-RESUME_RESTORE_STATE tells the driver to restore the state saved by

-RESUME_ENABLE tells the driver to start accepting I/O transactions

-again. Depending on driver policy, the device may already have pending

-RESUME_POWER_ON is called with interrupts disabled. The other resume

-As with the various suspend stages, the driver must not assume that

-any other resume calls have been or will be made. Each call should be

+Resume is used to bring a device back from a low power state.

diff --git a/Documentation/driver-model/porting.txt b/Documentation/driver-model/porting.txt
index ff2fef2107f0..98b233cb8b36 100644
--- a/Documentation/driver-model/porting.txt
+++ b/Documentation/driver-model/porting.txt

@@ -350,7 +350,7 @@ When a driver is registered, the bus's list of devices is iterated

over. bus->match() is called for each device that is not already

-When a device is successfully bound to a device, device->driver is

+When a device is successfully bound to a driver, device->driver is

set, the device is added to a per-driver list of devices, and a

symlink is created in the driver's sysfs directory that points to the

diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt
index cb63b7a93c82..df6c05453cb5 100644
--- a/Documentation/dvb/bt8xx.txt
+++ b/Documentation/dvb/bt8xx.txt

+How to get the Nebula, PCTV, FusionHDTV Lite and Twinhan DST cards working

+==========================================================================

In general you need to load the bttv driver, which will handle the gpio and

i2c communication for us, plus the common dvb-bt8xx device driver.

-The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and

-TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver.

+The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110), TwinHan (dst),

+FusionHDTV DVB-T Lite (mt352) and FusionHDTV5 Lite (lgdt330x) are loaded

$ modprobe bttv (normally bttv is being loaded automatically by kmod)

- $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading)

+(or just place dvb-bt8xx in /etc/modules for automatic loading)

The value 0x71 will override the PCI type detection for dvb-bt8xx,

+which is necessary for TwinHan cards. Omission of this parameter might result

-If you're having an older card (blue color circuit) and card=0x71 locks

+If you're having an older card (blue color PCB) and card=0x71 locks up

your machine, try using 0x68, too. If that does not work, ask on the

@@ -64,11 +68,47 @@ verbose=0 means complete disabling of messages

dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card.

+The autodetected values are determined by the cards 'response string'

+If you need to sent in bug reports on the dst, please do send in a complete

+log with the verbose=4 module parameter. For general usage, the default setting

+If you happen to be running multiple cards, it would be advisable to load

+the bttv module with the card id. This would help to solve any module loading

+For example, if you have a Twinhan and Clones card along with a FusionHDTV5 Lite

+Here the order of the card id is important and should be the same as that of the

+physical order of the cards. Here card=0x71 represents the Twinhan and clones

+and card=0x87 represents Fusion HDTV5 Lite. These arguments can also be

+For a full list of card-id's, see the V4L Documentation within the kernel

+If you have problems with this please do ask on the mailing list.

Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham

diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt
index efdc4ee9d40c..19329cf7b097 100644
--- a/Documentation/dvb/cards.txt
+++ b/Documentation/dvb/cards.txt

o Cards based on the Phillips saa7146 multimedia PCI bridge chip:

@@ -62,6 +68,10 @@ o Cards based on the Conexant Bt8xx PCI bridge:

o Experimental support for the analog module of the Siemens DVB-C PCI card

diff --git a/Documentation/dvb/contributors.txt b/Documentation/dvb/contributors.txt
index c9d5ce370701..2cbd2d0f6fdf 100644
--- a/Documentation/dvb/contributors.txt
+++ b/Documentation/dvb/contributors.txt

(If you think you should be in this list, but you are not, drop a

diff --git a/Documentation/dvb/faq.txt b/Documentation/dvb/faq.txt
index 3bf51e45c972..a42132d60dc8 100644
--- a/Documentation/dvb/faq.txt
+++ b/Documentation/dvb/faq.txt

@@ -60,7 +60,6 @@ Some very frequently asked questions about linuxtv-dvb

diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index a750f0101d9d..be6eb4c75991 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware

@components = ( "sp8870", "sp887x", "tda10045", "tda10046", "av7110", "dec2000t",

+ "dec2540t", "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",

+ my $url = "http://www.aver.com/support/Drivers/$sourcefile";

diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README
index 270a88e22fb9..cddbac456c29 100644
--- a/Documentation/early-userspace/README
+++ b/Documentation/early-userspace/README

You can create a cpio archive that contains the early userspace image.

-Youre cpio archive should be specified in CONFIG_INITRAMFS_SOURCE and it

+Your cpio archive should be specified in CONFIG_INITRAMFS_SOURCE and it

will be used directly. Only a single cpio file may be specified in

CONFIG_INITRAMFS_SOURCE and directory and file names are not allowed in

diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt
new file mode 100644
index 000000000000..08dce0f631bf
--- /dev/null
+++ b/Documentation/fb/fbcon.txt

+ The framebuffer console (fbcon), as its name implies, is a text

+console running on top of the framebuffer device. It has the functionality of

+any standard text console driver, such as the VGA console, with the added

+features that can be attributed to the graphical nature of the framebuffer.

+ In the x86 architecture, the framebuffer console is optional, and

+some even treat it as a toy. For other architectures, it is the only available

+ What are the features of fbcon? The framebuffer console supports

+high resolutions, varying font types, display rotation, primitive multihead,

+etc. Theoretically, multi-colored fonts, blending, aliasing, and any feature

+made available by the underlying graphics card are also possible.

+ The framebuffer console can be enabled by using your favorite kernel

+configuration tool. It is under Device Drivers->Graphics Support->Support for

+framebuffer devices->Framebuffer Console Support. Select 'y' to compile

+support statically, or 'm' for module support. The module will be fbcon.

+ In order for fbcon to activate, at least one framebuffer driver is

+required, so choose from any of the numerous drivers available. For x86

+systems, they almost universally have VGA cards, so vga16fb and vesafb will

+always be available. However, using a chipset-specific driver will give you

+more speed and features, such as the ability to change the video mode

+ To display the penguin logo, choose any logo available in Logo

+ Also, you will need to select at least one compiled-in fonts, but if

+you don't do anything, the kernel configuration tool will select one for you,

+GOTCHA: A common bug report is enabling the framebuffer without enabling the

+framebuffer console. Depending on the driver, you may get a blanked or

+garbled display, but the system still boots to completion. If you are

+fortunate to have a driver that does not alter the graphics chip, then you

+ Usually, fbcon will automatically take over your console. The notable

+ exception is vesafb. It needs to be explicitly activated with the

+2. Driver is compiled statically, fbcon is compiled as a module

+ Depending on the driver, you either get a standard console, or a

+ garbled display, as mentioned above. To get a framebuffer console,

+3. Driver is compiled as a module, fbcon is compiled statically

+ You get your standard console. Once the driver is loaded with

+ 'modprobe xxxfb', fbcon automatically takes over the console with

+ the possible exception of using the fbcon=map:n option. See below.

+ You can load them in any order. Once both are loaded, fbcon will take

+ The framebuffer console has several, largely unknown, boot options

+ Select the initial font to use. The value 'name' can be any of the

+ compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6, RomanLarge,

+ Note, not all drivers can handle font with widths not divisible by 8,

+ The scrollback buffer is memory that is used to preserve display

+ contents that has already scrolled past your view. This is accessed

+ by using the Shift-PageUp key combination. The value 'value' is any

+ integer. It defaults to 32KB. The 'k' suffix is optional, and will

+ This is an interesting option. It tells which driver gets mapped to

+ which console. The value '0123' is a sequence that gets repeated until

+ the total length is 64 which is the number of consoles available. In

+ the above example, it is expanded to 012301230123... and the mapping

+ One side effect that may be useful is using a map value that exceeds

+ the number of loaded fb drivers. For example, if only one driver is

+ available, fb0, adding fbcon=map:1 tells fbcon not to take over the

+ Later on, when you want to map the console the to the framebuffer

+ This option tells fbcon to take over only a range of consoles as

+ specified by the values 'n1' and 'n2'. The rest of the consoles

+ outside the given range will still be controlled by the standard

+ NOTE: For x86 machines, the standard console is the VGA console which

+ is typically located on the same video card. Thus, the consoles that

+ This option changes the orientation angle of the console display. The

+ The angle can be changed anytime afterwards by 'echoing' the same

+ Console rotation will only become available if Console Rotation

+ NOTE: This is purely console rotation. Any other applications that

+ use the framebuffer will remain at their 'normal'orientation.

+ Actually, the underlying fb driver is totally ignorant of console

diff --git a/Documentation/fb/vesafb.txt b/Documentation/fb/vesafb.txt
index 62db6758d1c1..ee277dd204b0 100644
--- a/Documentation/fb/vesafb.txt
+++ b/Documentation/fb/vesafb.txt

@@ -146,10 +146,10 @@ pmipal Use the protected mode interface for palette changes.

mtrr:n setup memory type range registers for the vesafb framebuffer

If you see the following in dmesg, choose the type that matches the

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index b67189a8d8d4..9b743198f77a 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt

@@ -60,6 +67,21 @@ Who: Jody McIntyre <scjody@steamballoon.com>

+What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.

+Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6

+ series. The old API have lots of drawbacks and don't provide enough

+ means to work with all video and audio standards. The newer API is

+ already available on the main drivers and should be used instead.

+ Newer drivers should use v4l_compat_translate_ioctl function to handle

+ Decoder iocts are using internally to allow video drivers to

+ communicate with video decoders. This should also be improved to allow

+ V4L2 calls being translated into compatible internal ioctls.

What: i2c sysfs name change: in1_ref, vid deprecated in favour of cpu0_vid

Files: drivers/i2c/chips/adm1025.c, drivers/i2c/chips/adm1026.c

What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])

@@ -95,3 +133,29 @@ Why: This interface has been obsoleted by the new layer3-independent

to link against API-compatible library on top of libnfnetlink_queue

+Why: Too low-level interface. Use lookup_one_len or lookup_create instead.

+Why: The 8250 serial driver now has the ability to deal with the differences

+ between the standard 8250 family of UARTs and their slightly strange

+ brother on Alchemy SOCs. The loss of features is not considered an

diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt
index 30c9738590f4..2d1524469c25 100644
--- a/Documentation/filesystems/affs.txt
+++ b/Documentation/filesystems/affs.txt

@@ -216,4 +216,4 @@ due to an incompatibility with the Amiga floppy controller.

diff --git a/Documentation/filesystems/dentry-locking.txt b/Documentation/filesystems/dentry-locking.txt
new file mode 100644
index 000000000000..4c0c575a4012
--- /dev/null
+++ b/Documentation/filesystems/dentry-locking.txt

+On many workloads, the most common operation on dcache is to look up a

+dentry, given a parent dentry and the name of the child. Typically,

+for every open(), stat() etc., the dentry corresponding to the

+pathname will be looked up by walking the tree starting with the first

+component of the pathname and using that dentry along with the next

+component to look up the next level and so on. Since it is a frequent

+operation for workloads like multiuser environments and web servers,

+Prior to 2.5.10, dcache_lock was acquired in d_lookup and thus in

+every component during path look-up. Since 2.5.10 onwards, fast-walk

+algorithm changed this by holding the dcache_lock at the beginning and

+walking as many cached path component dentries as possible. This

+significantly and affects performance in large SMP machines. Since

+2.5.62 kernel, dcache has been using a new locking model that uses RCU

+The current dcache locking model is not very different from the

+existing dcache locking model. Prior to 2.5.62 kernel, dcache_lock

+protected the hash chain, d_child, d_alias, d_lru lists as well as

+d_inode and several other things like mount look-up. RCU-based changes

+affect only the way the hash chain is protected. For everything else

+updating. The hash chain updates too take the dcache_lock. The

+significant change is the way d_lookup traverses the hash chain, it

+doesn't acquire the dcache_lock for this and rely on RCU to ensure

+For many multi-user workloads, open() and stat() on files are very

+frequently occurring operations. Both involve walking of path names to

+find the dentry corresponding to the concerned file. In 2.4 kernel,

+dcache_lock was held during look-up of each path component. Contention

+and cache-line bouncing of this global lock caused significant

+scalability problems. With the introduction of RCU in Linux kernel,

+this was worked around by making the look-up of path components during

+Dcache is a complex data structure with the hash table entries also

+linked together in other lists. In 2.4 kernel, dcache_lock protected

+all the lists. We applied RCU only on hash chain walking. The rest of

+the lists are still protected by dcache_lock. Some of the important

+1. The deletion from hash chain is done using hlist_del_rcu() macro

+ which doesn't initialize next pointer of the deleted dentry and

+ hlist_add_head_rcu() which take care of ordering the writes - the

+ inserted. This works in conjunction with hlist_for_each_rcu() while

+ hlist_add_head_rcu() since we don't have dcache_lock protection

+ while traversing the hash chain. This isn't different from the

+3. The dentry looked up without holding dcache_lock by cannot be

+ returned for walking if it is unhashed. It then may have a NULL

+ d_inode or other bogosity since RCU doesn't protect the other

+ fields in the dentry. We therefore use a flag DCACHE_UNHASHED to

+ indicate unhashed dentries and use this in conjunction with a

+ per-dentry lock (d_lock). Once looked up without the dcache_lock,

+ we acquire the per-dentry lock (d_lock) and check if the dentry is

+ unhashed. If so, the look-up is failed. If not, the reference count

+4. Once a dentry is looked up, it must be ensured during the path walk

+ for that component it doesn't go away. In pre-2.5.10 code, this was

+ done holding a reference to the dentry. dcache_rcu does the same.

+ In some sense, dcache_rcu path walking looks like the pre-2.5.10

+5. All dentry hash chain updates must take the dcache_lock as well as

+ the per-dentry lock in that order. dput() does this to ensure that

+ a dentry that has just been looked up in another CPU doesn't get

+6. There are several ways to do reference counting of RCU protected

+ objects. One such example is in ipv4 route cache where deferred

+ freeing (using call_rcu()) is done as soon as the reference count

+ goes to zero. This cannot be done in the case of dentries because

+ tearing down of dentries require blocking (dentry_iput()) which

+ isn't supported from RCU callbacks. Instead, tearing down of

+ dentries happen synchronously in dput(), but actual freeing happens

+ later when RCU grace period is over. This allows safe lock-free

+ walking of the hash chains, but a matched dentry may have been

+ partially torn down. The checking of DCACHE_UNHASHED flag with

+ d_lock held detects such dentries and prevents them from being

+Since look-up of dentries is lock-free, it can race against a

+concurrent rename operation. For example, during rename of file A to

+B, look-up of either A or B must succeed. So, if look-up of B happens

+after A has been removed from the hash chain but not added to the new

+hash chain, it may fail. Also, a comparison while the name is being

+written concurrently by a rename may result in false positive matches

+violating rename semantics. Issues related to race with rename are

+1. Look-up can be done in two ways - d_lookup() which is safe from

+ __d_lookup() fails, it must be followed up by a d_lookup() to

+ correctly determine whether a dentry is in the hash table or

+2. The name associated with a dentry (d_name) may be changed if a

+ rename is allowed to happen simultaneously. To avoid memcmp() in

+ __d_lookup() go out of bounds due to a rename and false positive

+ per-dentry lock. This prevents concurrent renames during this

+3. Hash table walking during look-up may move to a different bucket as

+ the current dentry is moved to a different bucket due to rename.

+ null-terminated. So, even if a dentry moves to a different bucket,

+ hash chain walk will terminate. [with a list_head list, it may not

+ since termination is when the list_head in the original bucket is

+ reached]. Since we redo the d_parent check and compare name while

+ holding d_lock, lock-free look-up will not race against d_move().

+4. There can be a theoretical race when a dentry keeps coming back to

+ original bucket due to double moves. Due to this look-up may

+ consider that it has never moved and can end up in a infinite loop.

+ But this is not any worse that theoretical livelocks we already

+Important guidelines for filesystem developers related to dcache_rcu

+====================================================================

+1. Existing dcache interfaces (pre-2.5.62) exported to filesystem

+ don't change. Only dcache internal implementation changes. However

+ filesystems *must not* delete from the dentry hash chains directly

+ using the list macros like allowed earlier. They must use dcache

+ APIs like d_drop() or __d_drop() depending on the situation.

+2. d_flags is now protected by a per-dentry lock (d_lock). All access

+3. For a hashed dentry, checking of d_count needs to be protected by

+1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).

diff --git a/Documentation/filesystems/devfs/README b/Documentation/filesystems/devfs/README
index 54366ecc241f..aabfba24bc2e 100644
--- a/Documentation/filesystems/devfs/README
+++ b/Documentation/filesystems/devfs/README

@@ -1812,11 +1812,6 @@ it may overflow the messages buffer, but try to get as much of it as

-names of the offending functions are provided. A non-decoded Oops is

diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt
index d16334ec48ba..3dd2872416a1 100644
--- a/Documentation/filesystems/ext2.txt
+++ b/Documentation/filesystems/ext2.txt

@@ -17,8 +17,6 @@ set using tune2fs(8). Kernel-determined defaults are indicated by (*).

check=none, nocheck (*) Don't do extra checking of bitmaps on mount

@@ -371,9 +369,8 @@ The kernel source file:/usr/src/linux/fs/ext2/

Design & Implementation http://e2fsprogs.sourceforge.net/ext2intro.html

Journaling (ext3) ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/

Windows 95/98/NT/2000 http://uranus.it.swin.edu.au/~jn/linux/Explore2fs.htm

diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index a5fbc8e897fa..614de3124901 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt

-- This is a complete rewrite of the NTFS driver that used to be in the kernel.

- This new driver implements NTFS read support and is functionally equivalent

+- This is a complete rewrite of the NTFS driver that used to be in the 2.4 and

+ earlier kernels. This new driver implements NTFS read support and is

+ functionally equivalent to the old ntfs driver and it also implements limited

+ write support. The biggest limitation at present is that files/directories

+ cannot be created or deleted. See below for the list of write features that

+ are so far supported. Another limitation is that writing to compressed files

+ is not implemented at all. Also, neither read nor write access to encrypted

- The new driver has full support for sparse files on NTFS 3.x volumes which

- The new driver supports execution of binaries due to mmap() now being

- The new driver supports fsync(2), fdatasync(2), and msync(2).

- The new driver supports access time updates (including mtime and ctime).

+- The new driver supports truncate(2) and open(2) with O_TRUNC. But at present

+ only very limited support for highly fragmented files, i.e. ones which have

+ their data attribute split across multiple extents, is included. Another

+ limitation is that at present truncate(2) will never create sparse files,

+ since to mark a file sparse we need to modify the directory entry for the

+- The new driver supports write(2) which can both overwrite existing data and

+ extend the file size so that you can write beyond the existing data. Also,

+ writing into sparse regions is supported and the holes are filled in with

+ clusters. But at present only limited support for highly fragmented files,

+ i.e. ones which have their data attribute split across multiple extents, is

+ included. Another limitation is that write(2) will never create sparse

+ files, since to mark a file sparse we need to modify the directory entry for

+ the file and we do not implement directory modifications yet.

Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.

+ - Write support is now extended with write(2) being able to both

+ overwrite existing file data and to extend files. Also, if a write

+ to a sparse region occurs, write(2) will fill in the hole. Note,

+ mmap(2) based writes still do not support writing into holes or

+ - Write support has a new feature and that is that truncate(2) and

+ open(2) with O_TRUNC are now implemented thus files can be both made

+ - Note: Both write(2) and truncate(2)/open(2) with O_TRUNC still have

+ - only work on regular, i.e. uncompressed and unencrypted files.

+ - never create sparse files although this will change once directory

- Support journals ($LogFile) which have been modified by chkdsk. This

means users can boot into Windows after we marked the volume dirty.

diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
new file mode 100644
index 000000000000..b3404a032596
--- /dev/null
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt

+Ramfs is a very simple filesystem that exports Linux's disk caching

+mechanisms (the page cache and dentry cache) as a dynamically resizable

+Normally all files are cached in memory by Linux. Pages of data read from

+backing store (usually the block device the filesystem is mounted on) are kept

+around in case it's needed again, but marked as clean (freeable) in case the

+Virtual Memory system needs the memory for something else. Similarly, data

+written to files is marked clean as soon as it has been written to backing

+store, but kept around for caching purposes until the VM reallocates the

+memory. A similar mechanism (the dentry cache) greatly speeds up access to

+With ramfs, there is no backing store. Files written into ramfs allocate

+dentries and page cache as usual, but there's nowhere to write them to.

+This means the pages are never marked clean, so they can't be freed by the

+The amount of code required to implement ramfs is tiny, because all the

+work is done by the existing Linux caching infrastructure. Basically,

+you're mounting the disk cache as a filesystem. Because of this, ramfs is not

+an optional component removable via menuconfig, since there would be negligible

+The older "ram disk" mechanism created a synthetic block device out of

+an area of ram and used it as backing store for a filesystem. This block

+device was of fixed size, so the filesystem mounted on it was of fixed

+size. Using a ram disk also required unnecessarily copying memory from the

+fake block device into the page cache (and copying changes back out), as well

+as creating and destroying dentries. Plus it needed a filesystem driver

+Compared to ramfs, this wastes memory (and memory bus bandwidth), creates

+unnecessary work for the CPU, and pollutes the CPU caches. (There are tricks

+to avoid this copying by playing with the page tables, but they're unpleasantly

+complicated and turn out to be about as expensive as the copying anyway.)

+More to the point, all the work ramfs is doing has to happen _anyway_,

+since all file access goes through the page and dentry caches. The ram

+disk is simply unnecessary, ramfs is internally much simpler.

+Another reason ramdisks are semi-obsolete is that the introduction of

+loopback devices offered a more flexible and convenient way to create

+synthetic block devices, now from files instead of from chunks of memory.

+One downside of ramfs is you can keep writing data into it until you fill

+up all memory, and the VM can't free it because the VM thinks that files

+should get written to backing store (rather than swap space), but ramfs hasn't

+got any backing store. Because of this, only root (or a trusted user) should

+A ramfs derivative called tmpfs was created to add size limits, and the ability

+to write the data to swap space. Normal users can be allowed write access to

+tmpfs mounts. See Documentation/filesystems/tmpfs.txt for more information.

+Rootfs is a special instance of ramfs, which is always present in 2.6 systems.

+(It's used internally as the starting and stopping point for searches of the

+Most systems just mount another filesystem over it and ignore it. The

+All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is

+extracted into rootfs when the kernel boots up. After extracting, the kernel

+checks to see if rootfs contains a file "init", and if so it executes it as PID

+1. If found, this init process is responsible for bringing the system the

+rest of the way up, including locating and mounting the real root device (if

+any). If rootfs does not contain an init program after the embedded cpio

+archive is extracted into it, the kernel will fall through to the older code

+to locate and mount a root partition, then exec some variant of /sbin/init

+ - The old initrd was a separate file, while the initramfs archive is linked

+ into the linux kernel image. (The directory linux-*/usr is devoted to

+ - The old initrd file was a gzipped filesystem image (in some file format,

+ such as ext2, that had to be built into the kernel), while the new

+ initramfs archive is a gzipped cpio archive (like tar only simpler,

+ see cpio(1) and Documentation/early-userspace/buffer-format.txt).

+ - The program run by the old initrd (which was called /initrd, not /init) did

+ some setup and then returned to the kernel, while the init program from

+ initramfs is not expected to return to the kernel. (If /init needs to hand

+ off control it can overmount / with a new root device and exec another init

+ - When switching another root device, initrd would pivot_root and then

+ umount the ramdisk. But initramfs is rootfs: you can neither pivot_root

+ rootfs, nor unmount it. Instead delete everything out of rootfs to

+ free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs

+ with the new root (cd /newmount; mount --move . /; chroot .), attach

+ stdin/stdout/stderr to the new /dev/console, and exec the new init.

+ Since this is a remarkably persnickity process (and involves deleting

+ commands before you can run them), the klibc package introduced a helper

+ program (utils/run_init.c) to do all this for you. Most other packages

+The 2.6 kernel build process always creates a gzipped cpio format initramfs

+archive and links it into the resulting kernel binary. By default, this

+archive is empty (consuming 134 bytes on x86). The config option

+CONFIG_INITRAMFS_SOURCE (for some reason buried under devices->block devices

+in menuconfig, and living in usr/Kconfig) can be used to specify a source for

+the initramfs archive, which will automatically be incorporated into the

+resulting binary. This option can point to an existing gzipped cpio archive, a

+directory containing files to be archived, or a text file specification such

+One advantage of the text file is that root access is not required to

+set permissions or create device nodes in the new archive. (Note that those

+two example "file" entries expect to find files named "init.sh" and "busybox" in

+a directory called "initramfs", under the linux-2.6.* directory. See

+If you don't already understand what shared libraries, devices, and paths

+you need to get a minimal root filesystem up and running, here are some

+http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html

+The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is

+designed to be a tiny C library to statically link early userspace

+code against, along with some related utilities. It is BSD licensed.

+I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net)

+In theory you could use glibc, but that's not well suited for small embedded

+uses like this. (A "hello world" program statically linked against glibc is

+over 400k. With uClibc it's 7k. Also note that glibc dlopens libnss to do

+Today (2.6.14), initramfs is always compiled in, but not always used. The

+kernel falls back to legacy boot code that is reached only if initramfs does

+not contain an /init program. The fallback is legacy code, there to ensure a

+smooth transition and allowing early boot functionality to gradually move to

+The move to early userspace is necessary because finding and mounting the real

+root device is complex. Root partitions can span multiple devices (raid or

+separate journal). They can be out on the network (requiring dhcp, setting a

+specific mac address, logging into a server, etc). They can live on removable

+media, with dynamically allocated major/minor numbers and persistent naming

+issues requiring a full udev implementation to sort out. They can be

+compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,

+This kind of complexity (which inevitably includes policy) is rightly handled

+in userspace. Both klibc and busybox/uClibc are working on simple initramfs

+packages to drop into a kernel build, and when standard solutions are ready

+and widely deployed, the kernel's legacy early boot code will become obsolete

diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index f042c12e0ed2..ee4c0a8b8db7 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt

-The Virtual File System (otherwise known as the Virtual Filesystem

-Switch) is the software layer in the kernel that provides the

-filesystem interface to userspace programs. It also provides an

-abstraction within the kernel which allows different filesystem

+The Virtual File System (also known as the Virtual Filesystem Switch)

+is the software layer in the kernel that provides the filesystem

+interface to userspace programs. It also provides an abstraction

+within the kernel which allows different filesystem implementations to

+VFS system calls open(2), stat(2), read(2), write(2), chmod(2) and so

+on are called from a process context. Filesystem locking is described

-In this section I'll briefly describe how things work, before

-launching into the details. I'll start with describing what happens

-when user programs open and manipulate files, and then look from the

-other view which is how a filesystem is supported and subsequently

-The VFS implements the open(2), stat(2), chmod(2) and similar system

-calls. The pathname argument is used by the VFS to search through the

-directory entry cache (dentry cache or "dcache"). This provides a very

-fast look-up mechanism to translate a pathname (filename) into a

-An individual dentry usually has a pointer to an inode. Inodes are the

-things that live on disc drives, and can be regular files (you know:

-those things that you write data into), directories, FIFOs and other

-beasts. Dentries live in RAM and are never saved to disc: they exist

-only for performance. Inodes live on disc and are copied into memory

-when required. Later any changes are written back to disc. The inode

-that lives in RAM is a VFS inode, and it is this which the dentry

-points to. A single inode can be pointed to by multiple dentries

-The dcache is meant to be a view into your entire filespace. Unlike

-Linus, most of us losers can't fit enough dentries into RAM to cover

-all of our filespace, so the dcache has bits missing. In order to

-resolve your pathname into a dentry, the VFS may have to resort to

-creating dentries along the way, and then loading the inode. This is

-To look up an inode (usually read from disc) requires that the VFS

-calls the lookup() method of the parent directory inode. This method

-is installed by the specific filesystem implementation that the inode

-Once the VFS has the required dentry (and hence the inode), we can do

-all those boring things like open(2) the file, or stat(2) it to peek

-at the inode data. The stat(2) operation is fairly simple: once the

-VFS has the dentry, it peeks at the inode data and passes some of it

+The VFS implements the open(2), stat(2), chmod(2), and similar system

+calls. The pathname argument that is passed to them is used by the VFS

+to search through the directory entry cache (also known as the dentry

+cache or dcache). This provides a very fast look-up mechanism to

+translate a pathname (filename) into a specific dentry. Dentries live

+in RAM and are never saved to disc: they exist only for performance.

+The dentry cache is meant to be a view into your entire filespace. As

+most computers cannot fit all dentries in the RAM at the same time,

+some bits of the cache are missing. In order to resolve your pathname

+into a dentry, the VFS may have to resort to creating dentries along

+the way, and then loading the inode. This is done by looking up the

+An individual dentry usually has a pointer to an inode. Inodes are

+filesystem objects such as regular files, directories, FIFOs and other

+beasts. They live either on the disc (for block device filesystems)

+or in the memory (for pseudo filesystems). Inodes that live on the

+disc are copied into the memory when required and changes to the inode

+are written back to disc. A single inode can be pointed to by multiple

+To look up an inode requires that the VFS calls the lookup() method of

+the parent directory inode. This method is installed by the specific

+filesystem implementation that the inode lives in. Once the VFS has

+the required dentry (and hence the inode), we can do all those boring

+things like open(2) the file, or stat(2) it to peek at the inode

+data. The stat(2) operation is fairly simple: once the VFS has the

+dentry, it peeks at the inode data and passes some of it back to

Opening a file requires another operation: allocation of a file

@@ -74,51 +73,39 @@ descriptors). The freshly allocated file structure is initialized with

a pointer to the dentry and a set of file operation member functions.

These are taken from the inode data. The open() file method is then

called so the specific filesystem implementation can do it's work. You

-The file structure is placed into the file descriptor table for the

+can see that this is another switch performed by the VFS. The file

+structure is placed into the file descriptor table for the process.

Reading, writing and closing files (and other assorted VFS operations)

is done by using the userspace file descriptor to grab the appropriate

-file structure, and then calling the required file structure method

-For as long as the file is open, it keeps the dentry "open" (in use),

-All VFS system calls (i.e. open(2), stat(2), read(2), write(2),

-chmod(2) and so on) are called from a process context. You should

-assume that these calls are made without any kernel locks being

-held. This means that the processes may be executing the same piece of

-processors. You should ensure that access to shared resources is

+file structure, and then calling the required file structure method to

+do whatever is required. For as long as the file is open, it keeps the

+dentry in use, which in turn means that the VFS inode is still in use.

-If you want to support a new kind of filesystem in the kernel, all you

-need to do is call register_filesystem(). You pass a structure

-describing the filesystem implementation (struct file_system_type)

-which is then added to an internal table of supported filesystems. You

+To register and unregister a filesystem, use the following API

-to see what filesystems are currently available on your system.

+ extern int unregister_filesystem(struct file_system_type *);

-When a request is made to mount a block device onto a directory in

-your filespace the VFS will call the appropriate method for the

-specific filesystem. The dentry for the mount point will then be

+The passed struct file_system_type describes your filesystem. When a

+request is made to mount a device onto a directory in your filespace,

+the VFS will call the appropriate get_sb() method for the specific

+filesystem. The dentry for the mount point will then be updated to

+You can see all filesystems that are registered to the kernel in the

This describes the filesystem. As of kernel 2.6.13, the following

@@ -197,8 +184,14 @@ A fill_super() method implementation has the following arguments:

This describes how the VFS can manipulate the superblock of your

filesystem. As of kernel 2.6.13, the following members are defined:

a superblock. The second parameter indicates whether the method

- write_super_lockfs: called when VFS is locking a filesystem and forcing

- it into a consistent state. This function is currently used by the

+ write_super_lockfs: called when VFS is locking a filesystem and

+ forcing it into a consistent state. This method is currently

unlockfs: called when VFS is unlocking a filesystem and making it writable

@@ -317,8 +310,14 @@ field. This is a pointer to a "struct inode_operations" which

describes the methods that can be performed on individual inodes.

filesystem. As of kernel 2.6.13, the following members are defined:

+ rename: called by the rename(2) system call to rename the object to

+ have the parent and name given by the second inode and dentry.

readlink: called by the readlink(2) system call. Only required if

follow_link: called by the VFS to follow a symbolic link to the

- follow_link(). The cookie returned by follow_link() is passed to

- to this function as the last parameter. It is used by filesystems

- such as NFS where page cache is not stable (i.e. page that was

- installed when the symbolic link walk started might not be in the

- truncate: called by the VFS to change the size of a file. The i_size

- field of the inode is set to the desired size by the VFS before

- this function is called. This function is called by the truncate(2)

+ follow_link(). The cookie returned by follow_link() is passed

+ truncate: called by the VFS to change the size of a file. The

permission: called by the VFS to check for access rights on a POSIX-like

- setattr: called by the VFS to set attributes for a file. This function is

+ setattr: called by the VFS to set attributes for a file. This method

- getattr: called by the VFS to get attributes of a file. This function is

+ getattr: called by the VFS to get attributes of a file. This method

setxattr: called by the VFS to set an extended attribute for a file.

- Extended attribute is a name:value pair associated with an inode. This

+ getxattr: called by the VFS to retrieve the value of an extended

+ attribute name. This method is called by getxattr(2) function

- getxattr: called by the VFS to retrieve the value of an extended attribute

+ listxattr: called by the VFS to list all extended attributes for a

+ given file. This method is called by listxattr(2) system call.

- listxattr: called by the VFS to list all extended attributes for a given

+ removexattr: called by the VFS to remove an extended attribute from

+ a file. This method is called by removexattr(2) system call.

- removexattr: called by the VFS to remove an extended attribute from a file.

+The address space object is used to identify pages in the page cache.

This describes how the VFS can manipulate mapping of a file to page cache in

your filesystem. As of kernel 2.6.13, the following members are defined:

This describes how the VFS can manipulate an open file. As of kernel

@@ -661,7 +677,7 @@ of child dentries. Child dentries are basically like files in a

There are a number of functions defined which permit a filesystem to

+For further information on dentry locking, please refer to the document

-Prior to 2.5.10, dcache_lock was acquired in d_lookup and thus

-in every component during path look-up. Since 2.5.10 onwards,

-dentries as possible. This significantly decreases the number

-lock hold time significantly and affects performance in large

-The current dcache locking model is not very different from the existing

-protected the hash chain, d_child, d_alias, d_lru lists as well

-as d_inode and several other things like mount look-up. RCU-based

-changes affect only the way the hash chain is protected. For everything

-else the dcache_lock must be taken for both traversing as well as

-The significant change is the way d_lookup traverses the hash chain,

-it doesn't acquire the dcache_lock for this and rely on RCU to

+(Note some of these resources are not up-to-date with the latest kernel

+ <http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/vfs.html>

-For many multi-user workloads, open() and stat() on files are

-the look-up of path components during path walking lock-free.

-Dcache is a complex data structure with the hash table entries

-also linked together in other lists. In 2.4 kernel, dcache_lock

-walking. The rest of the lists are still protected by dcache_lock.

-1. The deletion from hash chain is done using hlist_del_rcu() macro which

- doesn't initialize next pointer of the deleted dentry and this

- allows us to walk safely lock-free while a deletion is happening.

- hlist_add_head_rcu() which take care of ordering the writes -

- is inserted. This works in conjunction with hlist_for_each_rcu()

- all initialization to the dentry must be done before hlist_add_head_rcu()

- the hash chain. This isn't different from the existing code.

-3. The dentry looked up without holding dcache_lock by cannot be

- returned for walking if it is unhashed. It then may have a NULL

- d_inode or other bogosity since RCU doesn't protect the other

- fields in the dentry. We therefore use a flag DCACHE_UNHASHED to

- indicate unhashed dentries and use this in conjunction with a

- per-dentry lock (d_lock). Once looked up without the dcache_lock,

- dentry is unhashed. If so, the look-up is failed. If not, the

- reference count of the dentry is increased and the dentry is returned.

-4. Once a dentry is looked up, it must be ensured during the path

- walk for that component it doesn't go away. In pre-2.5.10 code,

- this was done holding a reference to the dentry. dcache_rcu does

-5. All dentry hash chain updates must take the dcache_lock as well as

- the per-dentry lock in that order. dput() does this to ensure

-6. There are several ways to do reference counting of RCU protected

-So, if look-up of B happens after A has been removed from the

-Also, a comparison while the name is being written concurrently

-1. Look-up can be done in two ways - d_lookup() which is safe

- If __d_lookup() fails, it must be followed up by a d_lookup()

- to correctly determine whether a dentry is in the hash table

-2. The name associated with a dentry (d_name) may be changed if

- a rename is allowed to happen simultaneously. To avoid memcmp()

- positive comparison, the name comparison is done while holding the

- per-dentry lock. This prevents concurrent renames during this

-3. Hash table walking during look-up may move to a different bucket as

- the current dentry is moved to a different bucket due to rename.

- But we use hlists in dcache hash table and they are null-terminated.

- So, even if a dentry moves to a different bucket, hash chain

- walk will terminate. [with a list_head list, it may not since

- termination is when the list_head in the original bucket is reached].

- Since we redo the d_parent check and compare name while holding

-4. There can be a theoretical race when a dentry keeps coming back

- to original bucket due to double moves. Due to this look-up may

- consider that it has never moved and can end up in a infinite loop.

- But this is not any worse that theoretical livelocks we already

-Important guidelines for filesystem developers related to dcache_rcu

-====================================================================

-1. Existing dcache interfaces (pre-2.5.62) exported to filesystem

- don't change. Only dcache internal implementation changes. However

- filesystems *must not* delete from the dentry hash chains directly

- using the list macros like allowed earlier. They must use dcache

- APIs like d_drop() or __d_drop() depending on the situation.

-2. d_flags is now protected by a per-dentry lock (d_lock). All

-3. For a hashed dentry, checking of d_count needs to be protected

-1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).

+A small trail through the Linux kernel by Andries Brouwer. 2001

diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index c7d5d0c7067d..74aeb142ae5f 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt

When mounting an XFS filesystem, the following options are accepted.

+ The options enable/disable (default is disabled for backward

+ made in the way inline extended attributes are stored on-disk.

+ removing extended attributes) the on-disk superblock feature

+ bit field will be updated to reflect this format being in use.

+ Enables the use of block layer write barriers for writes into

+ the journal and unwritten extent conversion. This allows for

+ These options define what group ID a newly created file gets.

+ When grpid is set, it takes the group ID of the directory in

+ which it is created; otherwise (the default) it takes the fsgid

+ of the current process, unless the directory has the setgid bit

+ set, in which case it takes the gid from the parent directory,

+ and also gets the setgid bit set if it is a directory itself.

+ of zero is used, the value selected by the default algorithm

@@ -35,12 +63,31 @@ When mounting an XFS filesystem, the following options are accepted.

+ Indicates that XFS is allowed to create inodes at any location

+ in the filesystem, including those which will result in inode

+ numbers occupying more than 32 bits of significance. This is

+ provided for backwards compatibility, but causes problems for

+ st_blksize by stat(2) will be as small as possible to allow user

+ If "largeio" specified, a filesystem that has a "swidth" specified

+ will return the "swidth" value (in bytes) in st_blksize. If the

+ filesystem does not have a "swidth" specified but does specify

+ If neither of these two options are specified, then filesystem

- blocksize of 64K, 4 buffers for filesystems with a blocksize

+ blocksize of 64KiB, 4 buffers for filesystems with a blocksize

+ of 32KiB, 3 buffers for filesystems with a blocksize of 16KiB

@@ -49,10 +96,10 @@ When mounting an XFS filesystem, the following options are accepted.

Size may be specified in bytes, or in kilobytes with a "k" suffix.

- Valid sizes for version 1 and version 2 logs are 16384 (16k) and

+ Valid sizes for version 1 and version 2 logs are 16384 (16k) and

- The default value for machines with more than 32MB of memory

+ The default value for machines with more than 32MiB of memory

@@ -62,6 +109,11 @@ When mounting an XFS filesystem, the following options are accepted.

+ Use with the "dmapi" option. The value specified here will be

+ included in the DMAPI mount event, and should be the path of

Data allocations will not be aligned at stripe unit boundaries.

@@ -91,13 +143,17 @@ When mounting an XFS filesystem, the following options are accepted.

If timestamp updates are critical, use the osyncisosync option.

+ Project disk quota accounting enabled and limits (optionally)

Used to specify the stripe unit and width for a RAID device or

@@ -113,15 +169,21 @@ When mounting an XFS filesystem, the following options are accepted.

The "swidth" option is required if the "sunit" option has been

+ Data allocations will be rounded up to stripe width boundaries

fs.xfs.xfssyncd_centisecs (Min: 100 Default: 3000 Max: 720000)

@@ -143,9 +205,9 @@ The following sysctls are available for the XFS filesystem:

- Causes certain error conditions to call BUG(). Value is a bitmask;

+ Causes certain error conditions to call BUG(). Value is a bitmask;

AND together the tags which represent errors which should cause panics:

@@ -155,7 +217,7 @@ The following sysctls are available for the XFS filesystem:

Controls whether symlinks are created with mode 0777 (default)

@@ -164,25 +226,37 @@ The following sysctls are available for the XFS filesystem:

If the group ID of the new file does not match the effective group

- ID or one of the supplementary group IDs of the parent dir, the

- ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl

+ ID or one of the supplementary group IDs of the parent dir, the

+ ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl

Controls whether unprivileged users can use chown to "give away"

+ In "inode32" allocation mode, this option determines how many

+ files the allocator attempts to allocate in the same allocation

+ group before moving to the next allocation group. The intent

diff --git a/Documentation/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c
index 4bef8c25172c..d3ad2c24490a 100644
--- a/Documentation/firmware_class/firmware_sample_driver.c
+++ b/Documentation/firmware_class/firmware_sample_driver.c

diff --git a/Documentation/firmware_class/firmware_sample_firmware_class.c b/Documentation/firmware_class/firmware_sample_firmware_class.c
index 09eab2f1b373..57b956aecbc5 100644
--- a/Documentation/firmware_class/firmware_sample_firmware_class.c
+++ b/Documentation/firmware_class/firmware_sample_firmware_class.c

diff --git a/Documentation/floppy.txt b/Documentation/floppy.txt
index 6fb10fcd82fb..6ccab88705cb 100644
--- a/Documentation/floppy.txt
+++ b/Documentation/floppy.txt

A FAQ list may be found in the fdutils package (see below), and also

@@ -217,10 +217,10 @@ It also contains additional documentation about the floppy driver.

- ftp://metalab.unc.edu/pub/Linux/utils/disk-management/fdutils-5.4.src.tar.gz

diff --git a/Documentation/hpet.txt b/Documentation/hpet.txt
index 4e7cc8d3359b..e52457581f47 100644
--- a/Documentation/hpet.txt
+++ b/Documentation/hpet.txt

-The High Precision Event Timer (HPET) hardware is the future replacement for the 8254 and Real

-Time Clock (RTC) periodic timer functionality. Each HPET can have up two 32 timers. It is possible

-to configure the first two timers as legacy replacements for 8254 and RTC periodic. A specification

-done by INTEL and Microsoft can be found at http://www.intel.com/labs/platcomp/hpet/hpetspec.htm.

-The driver supports detection of HPET driver allocation and initialization of the HPET before the

-driver module_init routine is called. This enables platform code which uses timer 0 or 1 as the

-main timer to intercept HPET initialization. An example of this initialization can be found in

+The High Precision Event Timer (HPET) hardware is the future replacement

+for the 8254 and Real Time Clock (RTC) periodic timer functionality.

+Each HPET can have up two 32 timers. It is possible to configure the

+first two timers as legacy replacements for 8254 and RTC periodic timers.

+The driver supports detection of HPET driver allocation and initialization

+of the HPET before the driver module_init routine is called. This enables

+platform code which uses timer 0 or 1 as the main timer to intercept HPET

+initialization. An example of this initialization can be found in

-The driver provides two APIs which are very similar to the API found in the rtc.c driver.

-There is a user space API and a kernel space API. An example user space program is provided

+The driver provides two APIs which are very similar to the API found in

+the rtc.c driver. There is a user space API and a kernel space API.

@@ -290,9 +293,8 @@ The kernel API has three interfaces exported from the driver:

hpet_control(struct hpet_task *tp, unsigned int cmd, unsigned long arg)

-The kernel module using this interface fills in the ht_func and ht_data members of the

-hpet_task structure before calling hpet_register. hpet_control simply vectors to the hpet_ioctl

-routine and has the same commands and respective arguments as the user API. hpet_unregister

+The kernel module using this interface fills in the ht_func and ht_data

+members of the hpet_task structure before calling hpet_register.

+hpet_control simply vectors to the hpet_ioctl routine and has the same

+commands and respective arguments as the user API. hpet_unregister

is used to terminate usage of the HPET timer reserved by hpet_register.

diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 0d0195040d88..7f42e441c645 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87

- Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)

+ Addresses scanned: from Super I/O config space (8 I/O ports)

- from Super I/O config space, or default ISA 0x290 (8 I/O ports)

- Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)

+ Addresses scanned: from Super I/O config space (8 I/O ports)

diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index 2c4cf39471f4..438cb24cee5b 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90

- http://products.analog.com/products/info.asp?product=ADM1032

- http://products.analog.com/products/info.asp?product=ADT7461

@@ -71,8 +71,8 @@ increased resolution of the remote temperature measurement.

The different chipsets of the family are not strictly identical, although

very similar. This driver doesn't handle any specific feature for now,

-but could if there ever was a need for it. For reference, here comes a

+with the exception of SMBus PEC. For reference, here comes a non-exhaustive

+ * SMBus PEC support for Write Byte and Receive Byte transactions.

@@ -119,3 +120,37 @@ The lm90 driver will not update its values more frequently than every

other second; reading them more often will do no harm, but will return

+The ADM1032 is the only chip of the family which supports PEC. It does

+not support PEC on all transactions though, so some care must be taken.

+When reading a register value, the PEC byte is computed and sent by the

+ADM1032 chip. However, in the case of a combined transaction (SMBus Read

+Byte), the ADM1032 computes the CRC value over only the second half of

+the message rather than its entirety, because it thinks the first half

+of the message belongs to a different transaction. As a result, the CRC

+value differs from what the SMBus master expects, and all reads fail.

+For this reason, the lm90 driver will enable PEC for the ADM1032 only if

+the bus supports the SMBus Send Byte and Receive Byte transaction types.

+These transactions will be used to read register values, instead of

+Additionally, the ADM1032 doesn't support SMBus Send Byte with PEC.

+Instead, it will try to write the PEC value to the register (because the

+SMBus Send Byte transaction with PEC is similar to a Write Byte transaction

+without PEC), which is not what we want. Thus, PEC is explicitely disabled

+PEC on byte data transactions represents a significant increase in bandwidth

+usage (+33% for writes, +25% for reads) in normal conditions. With the need

+to use two SMBus transaction for reads, this overhead jumps to +50%. Worse,

+two transactions will typically mean twice as much delay waiting for

+transaction completion, effectively doubling the register cache refresh time.

+I guess reliability comes at a price, but it's quite expensive this time.

+So, as not everyone might enjoy the slowdown, PEC can be disabled through

+sysfs. Just write 0 to the "pec" file and PEC will be disabled. Write 1

diff --git a/Documentation/hwmon/smsc47b397 b/Documentation/hwmon/smsc47b397
index da9d80c96432..20682f15ae41 100644
--- a/Documentation/hwmon/smsc47b397
+++ b/Documentation/hwmon/smsc47b397

Addresses scanned: none, address read from Super I/O config space

@@ -12,11 +13,14 @@ Authors: Mark M. Hoffman <mhoffman@lightlink.com>

-The following specification describes the SMSC LPC47B397-NC sensor chip

+The following specification describes the SMSC LPC47B397-NC[1] sensor chip

(for which there is no public datasheet available). This document was

provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected

+[1] And SMSC SCH5307-NS, which has a different device ID but is otherwise

Methods for detecting the HP SIO and reading the thermal data on a dc7100.

The registers of interest for identifying the SIO on the dc7100 are Device ID

diff --git a/Documentation/hwmon/smsc47m1 b/Documentation/hwmon/smsc47m1
index 34e6478c1425..c15bbe68264e 100644
--- a/Documentation/hwmon/smsc47m1
+++ b/Documentation/hwmon/smsc47m1

+ Addresses scanned: none, address read from Super I/O config space

@@ -30,6 +34,9 @@ The 47M15x and 47M192 chips contain a full 'hardware monitoring block'

in addition to the fan monitoring and control. The hardware monitoring

+No documentation is available for the 47M997, but it has the same device

+ID as the 47M15x and 47M192 chips and seems to be compatible.

Fan rotation speeds are reported in RPM (rotations per minute). An alarm is

triggered if the rotation speed has dropped below a programmable limit. Fan

readings can be divided by a programmable divider (1, 2, 4 or 8) to give

diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 346400519d0d..764cdc5480e7 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface

diff --git a/Documentation/hwmon/via686a b/Documentation/hwmon/via686a
index b82014cb7c53..a936fb3824b2 100644
--- a/Documentation/hwmon/via686a
+++ b/Documentation/hwmon/via686a

-force_addr=0xaddr Set the I/O base address. Useful for Asus A7V boards

+force_addr=0xaddr Set the I/O base address. Useful for boards that

The driver only updates its values each 1.5 seconds; reading it more often

+This driver handles sensors integrated in some VIA south bridges. It is

+possible that a motherboard maker used a VT82C686A/B chip as part of a

+product design but was not interested in its hardware monitoring features,

+in which case the sensor inputs will not be wired. This is the case of

+the Asus K7V, A7V and A7V133 motherboards, to name only a few of them.

+So, if you need the force_addr parameter, and end up with values which

+don't seem to make any sense, don't look any further: your chip is simply

diff --git a/Documentation/i2c/busses/i2c-i810 b/Documentation/i2c/busses/i2c-i810
index 0544eb332887..83c3b9743c3c 100644
--- a/Documentation/i2c/busses/i2c-i810
+++ b/Documentation/i2c/busses/i2c-i810

diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro
index 702f5ac68c09..16775663b9f5 100644
--- a/Documentation/i2c/busses/i2c-viapro
+++ b/Documentation/i2c/busses/i2c-viapro

- * VIA Technologies, Inc. VT8231, VT8233, VT8233A, VT8235, VT8237

+ * VIA Technologies, Inc. VT8231, VT8233, VT8233A, VT8235, VT8237R

i2c-viapro is a true SMBus host driver for motherboards with one of the

If none of these show up, you should look in the BIOS for settings like

+Except for the oldest chips (VT82C596A/B, VT82C686A and most probably

+VT8231), this driver supports I2C block transactions. Such transactions

diff --git a/Documentation/i2c/chips/x1205 b/Documentation/i2c/chips/x1205
new file mode 100644
index 000000000000..09407c991fe5
--- /dev/null
+++ b/Documentation/i2c/chips/x1205

+ Datasheet: http://www.intersil.com/cda/deviceinfo/0,1477,X1205,00.html

+This module aims to provide complete access to the Xicor X1205 RTC.

+This chip is located at address 0x6f and uses a 2-byte register addressing.

+Two bytes need to be written to read a single register, while most

+other chips just require one and take the second one as the data

+to be written. To prevent corrupting unknown chips, the user must

+The module supports one more option, hctosys, which is used to set the

+software clock from the x1205. On systems where the x1205 is the

+only hardware rtc, this parameter could be used to achieve a correct

diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index 41ffefbdc60c..60cca249e452 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality

@@ -17,9 +17,10 @@ For the most up-to-date list of functionality constants, please check

- I2C_FUNC_PROTOCOL_MANGLING Knows about the I2C_M_REV_DIR_ADDR,

+ I2C_FUNC_PROTOCOL_MANGLING Knows about the I2C_M_IGNORE_NAK,

I2C_FUNC_SMBUS_WRITE_BYTE Handles the SMBus write_byte command

diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients
index 4849dfd6961c..184fac2377aa 100644
--- a/Documentation/i2c/porting-clients
+++ b/Documentation/i2c/porting-clients

exit and exit_free. For i2c+isa drivers, labels should be named

ERROR0, ERROR1 and ERROR2. Don't forget to properly set err before

jumping to error labels. By the way, labels should be left-aligned.

diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 077275722a7c..d19993cc0604 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients

-The name can be chosen freely, and may be upto 40 characters long. Please

+The name field must match the driver name, including the case. It must not

Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This

means that your driver will be notified when new adapters are found.

All other fields are for call-back functions which will be explained

-There use to be two additional fields in this structure, inc_use et dec_use,

-for module usage count, but these fields were obsoleted and removed.

struct semaphore lock; /* For ISA access in `sensors' drivers. */

@@ -275,6 +273,7 @@ For now, you can ignore the `flags' parameter. It is there for future use.

+ /* FIXME: never use check_region(), only request_region() */

@@ -310,22 +309,15 @@ For now, you can ignore the `flags' parameter. It is there for future use.

client structure, even though we cannot fill it completely yet.

- /* Note that we reserve some space for foo_data too. If you don't

+ if (!(data = kzalloc(sizeof(struct foo_data), GFP_KERNEL))) {

- /* This is tricky, but it will set the data to the right value. */

@@ -420,7 +412,7 @@ For now, you can ignore the `flags' parameter. It is there for future use.

@@ -451,7 +443,7 @@ much simpler than the attachment code, fortunately!

- kfree(client); /* Frees client data too, if allocated at the same time */

extern s32 i2c_smbus_write_block_data(struct i2c_client * client,

+ extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,

These ones were removed in Linux 2.6.10 because they had no users, but could

- extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,

extern s32 i2c_smbus_read_block_data(struct i2c_client * client,

extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,

diff --git a/Documentation/input/yealink.txt b/Documentation/input/yealink.txt
index 85f095a7ad04..0962c5c948be 100644
--- a/Documentation/input/yealink.txt
+++ b/Documentation/input/yealink.txt

@@ -2,7 +2,6 @@ Driver documentation for yealink usb-p1k phones

@@ -17,9 +16,8 @@ For vendor documentation see http://www.yealink.com

@@ -28,6 +26,21 @@ the Makefile is pointing to the location where your kernel sources

+Q: Module yealink compiled and installed without any problem but phone

+ hiddev0: USB HID v1.00 Device [Yealink Network Technology Ltd. VOIP USB Phone

+ in dmesg, it means that the hid driver has grabbed the device first. Try to

+ load module yealink before any other usb hid driver. Please see the

+ instructions provided by your distribution on module configuration.

+Q: Phone is working now (displays version and accepts keypad input) but I can't

+A: The sysfs files are located on the particular usb endpoint. On most

+ distributions you can do: "find /sys/ -name get_icons" for a hint.

diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 769f925c8526..aa7ba00ec082 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt

'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system

diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt
index cb89fb3b61ef..99d24f2943ee 100644
--- a/Documentation/kernel-docs.txt
+++ b/Documentation/kernel-docs.txt

+ URL: http://users.evitech.fi/~tk/rtos/writing_linux_device_d.html

Keywords: files, VFS, file operations, kernel interface, character

vs block devices, I/O access, hardware interrupts, DMA, access to

Description: Very nice 92 pages GPL book on the topic of modules

+ URL: http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html

Keywords: filesystem, /dev, devfs, dynamic devices, major/minor

Description: Document describing Richard Gooch's controversial

- http://www.lisoleg.net/doc/Kernel-Hacking-HOWTO/kernel-hacking-HOW

+ Location: in kernel tree, Documentation/DocBook/kernel-hacking/

+ URL: http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html

Description: Advanced Linux Sound Architecture for developers,

- both at kernel and user-level sides. Work in progress. ALSA is

+ both at kernel and user-level sides. ALSA is the Linux kernel

Description: From the introduction: "This glossary is intended as

a brief description of some of the acronyms and terms you may hear

- http://netfilter.kernelnotes.org/unreliable-guides/kernel-locking-

+ Location: in kernel tree, Documentation/DocBook/kernel-locking/

- URL: http://www.ednmag.com/ednmag/reg/2000/06222000/13df2.htm

Keywords: data-acquisition boards, drivers, modules, interrupts,

Description: Article written for people wishing to make their data

- URL: http://packetstorm.securify.com/groups/thc/LKM_HACKING.html

+ URL: http://packetstormsecurity.org/docs/hack/LKM_HACKING.html

Description: Interesting paper on how to abuse the Linux kernel in

write kernel modules based virus... and solutions for admins to

+ Authors: Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman

* Name: "linux-kernel mailing list archives and search engines"

URL: http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html

Description: Some of the linux-kernel mailing list archivers. If

_________________________________________________________________

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 7086f0a90d14..5dffcfefc3c7 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt

@@ -17,7 +17,7 @@ are specified on the kernel command line with the module name plus

-The text in square brackets at the beginning of the description state the

+The text in square brackets at the beginning of the description states the

restrictions on the kernel for the said kernel parameter to be valid. The

restrictions referred to are that the relevant option is valid if:

@@ -27,8 +27,8 @@ restrictions referred to are that the relevant option is valid if:

@@ -71,7 +71,7 @@ restrictions referred to are that the relevant option is valid if:

acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode

- acpi_irq_nobalance [HW,ACPI] ACPI will not move active IRQs (default)

- acpi_irq_pci= [HW,ACPI] If irq_balance, Clear listed IRQs for use by PCI

+ acpi_irq_pci= [HW,ACPI] If irq_balance, clear listed IRQs for

- acpi_irq_isa= [HW,ACPI] If irq_balance, Mark listed IRQs used by ISA

+ acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA

- Can be useful to work around chipset bugs (in particular on some ATI chipsets)

- Format: <host-scsi-id>,<target-scsi-id>,<max-rate>,<max-offset>

- apc= [HW,SPARC] Power management functions (SPARCstation-4/5 + deriv.)

- apic= [APIC,i386] Change the output verbosity whilst booting

+ apic= [APIC,i386] Change the output verbosity whilst booting

arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards

atkbd.scroll= [HW] Enable scroll wheel on MS Office and similar

atkbd.softraw= [HW] Choose between synthetic and real raw mode

- baycom_ser_fdx= [HW,AX25] BayCom Serial Port AX.25 Modem (Full Duplex Mode)

- baycom_ser_hdx= [HW,AX25] BayCom Serial Port AX.25 Modem (Half Duplex Mode)

- bttv.radio= Most important insmod options are available as kernel args too.

- 0 -- check protection applied by kernel (includes any implied execute protection).

- Format: <io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]]

com90io= [HW,NET] ARCnet - COM90xx chipset (IO-mapped buffers)

- com90xx= [HW,NET] ARCnet - COM90xx chipset (memory-mapped buffers)

- Format: <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]

db9.dev[2|3]= [HW,JOY] Multisystem joystick support via parallel port

- kstack=N [IA-32, X86-64] Print N words from the kernel stack

- lapic [IA-32,APIC] Enable the local APIC even if BIOS disabled it.

log_buf_len=n Sets the size of the printk ring buffer, in bytes.

lp=port[,port...] lp=none,parport0 (lp0 not configured, lp1 uses

- Format: <can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>

+ <can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>

- Format: <num_esps>,<disconnect>,<nosync>,<can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>

+ <num_esps>,<disconnect>,<nosync>,<can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>

- Force the use of a particular machine-vector (machvec) in a generic

+ machvec= [IA64] Force the use of a particular machine-vector

- Format: <io>,<irq>,<dma>,<dma16>,<mpu_io>,<mpu_irq>,<joystick>

- max_loop= [LOOP] Maximum number of loopback devices that can

+ max_loop= [LOOP] Maximum number of loopback devices that can

max_addr=[KMG] [KNL,BOOT,ia64] All physical memory greater than or

mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory

- Format: <name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]

+ <name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]

- [HW] Make the MicroTouch USB driver use raw coordinates ('y', default)

- noresume [SWSUSP] Disables resume and restore original swap space.

+ noresume [SWSUSP] Disables resume and restores original swap

- Format: <io>,<irq>,<dma>,<dma2>,<mss_io>,<mpu_io>,<ymode>,<loopback>[,<isapnp>,<multiple]

+ <io>,<irq>,<dma>,<dma2>,<mss_io>,<mpu_io>,<ymode>,<loopback>[,<isapnp>,<multiple]

parkbd.mode= [HW] Parallel port keyboard adapter mode of operation,

- parport=0xBBB[,IRQ[,DMA]] any IRQ/DMA settings detected (the

- Format: <io>,<irq>,<dma>,<dma16>,<sb_io>,<sb_irq>,<sb_dma>,<sb_dma16>

+ <io>,<irq>,<dma>,<dma16>,<sb_io>,<sb_irq>,<sb_dma>,<sb_dma16>

- irqmask=0xMMMM [IA-32] Set a bit mask of IRQs allowed to be assigned

pnp_reserve_io= [ISAPNP] Exclude I/O ports for the autoconfiguration

- psmouse.proto= [HW,MOUSE] Highest PS2 mouse protocol extension to

+ psmouse.proto= [HW,MOUSE] Highest PS2 mouse protocol extension to

psmouse.rate= [HW,MOUSE] Set desired mouse report rate, in reports

- [HW,MOUSE] Try to reset the device after so many bad packets

- Format: <io>,<mss_io>,<mss_irq>,<mss_dma>,<mpu_io>,<mpu_irq>

reserve= [KNL,BUGS] Force the kernel to ignore some iomem area

- resume= [SWSUSP] Specify the partition device for software suspension

- Format: <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq>

+ <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq>

- vmalloc=nn[KMG] [KNL,BOOT] forces the vmalloc area to have an exact

+ vmalloc=nn[KMG] [KNL,BOOT] Forces the vmalloc area to have an exact

- Format: <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]

+ <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]

+______________________________________________________________________

The last known update (for 2.4.0) - the changelog was not kept before.

Update for 2.5.49, description for most of the options introduced,

references to other documentation (C files, READMEs, ..), added S390,

diff --git a/Documentation/keys-request-key.txt b/Documentation/keys-request-key.txt
new file mode 100644
index 000000000000..5f2b9c5edbb5
--- /dev/null
+++ b/Documentation/keys-request-key.txt

+The key request service is part of the key retention service (refer to

+Documentation/keys.txt). This document explains more fully how that the

+The process starts by either the kernel requesting a service by calling

+The main difference between the two access points is that the in-kernel

+interface does not need to link the key to a keyring to prevent it from being

+immediately destroyed. The kernel interface returns a pointer directly to the

+The userspace interface links the key to a keyring associated with the process

+to prevent the key from going away, and returns the serial number of the key to

+ (1) Process A calls request_key() [the userspace syscall calls the kernel

+ (2) request_key() searches the process's subscribed keyrings to see if there's

+ a suitable key there. If there is, it returns the key. If there isn't, and

+ callout_info is not set, an error is returned. Otherwise the process

+ (3) request_key() sees that A doesn't have the desired key yet, so it creates

+ (a) An uninstantiated key U of requested type and description.

+ (b) An authorisation key V that refers to key U and notes that process A

+ is the context in which key U should be instantiated and secured, and

+ (4) request_key() then forks and executes /sbin/request-key with a new session

+ (5) /sbin/request-key execs an appropriate program to perform the actual

+ (6) The program may want to access another key from A's context (say a

+ Kerberos TGT key). It just requests the appropriate key, and the keyring

+ search notes that the session keyring has auth key V in its bottom level.

+ This will permit it to then search the keyrings of process A with the

+ UID, GID, groups and security info of process A as if it was process A,

+ (7) The program then does what it must to get the data with which to

+ instantiate key U, using key W as a reference (perhaps it contacts a

+ (8) Upon instantiating key U, auth key V is automatically revoked so that it

+ (9) The program then exits 0 and request_key() deletes key V and returns key

+This also extends further. If key W (step 5 above) didn't exist, key W would be

+created uninstantiated, another auth key (X) would be created [as per step 3]

+and another copy of /sbin/request-key spawned [as per step 4]; but the context

+specified by auth key X will still be process A, as it was in auth key V.

+This is because process A's keyrings can't simply be attached to

+/sbin/request-key at the appropriate places because (a) execve will discard two

+of them, and (b) it requires the same UID/GID/Groups all the way through.

+Rather than instantiating a key, it is possible for the possessor of an

+authorisation key to negatively instantiate a key that's under construction.

+This is a short duration placeholder that causes any attempt at re-requesting

+This is provided to prevent excessive repeated spawning of /sbin/request-key

+Should the /sbin/request-key process exit anything other than 0 or die on a

+signal, the key under construction will be automatically negatively

+A search of any particular keyring proceeds in the following fashion:

+ (1) When the key management code searches for a key (keyring_search_aux) it

+ firstly calls key_permission(SEARCH) on the keyring it's starting with,

+ (2) It considers all the non-keyring keys within that keyring and, if any key

+ matches the criteria specified, calls key_permission(SEARCH) on it to see

+ if the key is allowed to be found. If it is, that key is returned; if

+ not, the search continues, and the error code is retained if of higher

+ (3) It then considers all the keyring-type keys in the keyring it's currently

+ searching. It calls key_permission(SEARCH) on each keyring, and if this

+ grants permission, it recurses, executing steps (2) and (3) on that

+The process stops immediately a valid key is found with permission granted to

+use it. Any error from a previous match attempt is discarded and the key is

+When search_process_keyrings() is invoked, it performs the following searches

+ (4) If the process has a request_key() authorisation key in its session

+ (a) If extant, the calling process's thread keyring is searched.

+ (b) If extant, the calling process's process keyring is searched.

+The moment one succeeds, all pending errors are discarded and the found key is

+Only if all these fail does the whole thing fail with the highest priority

+EACCES/EPERM are only returned on a direct search of a specific keyring where

diff --git a/Documentation/keys.txt b/Documentation/keys.txt
index 0321ded4b9ae..31154882000a 100644
--- a/Documentation/keys.txt
+++ b/Documentation/keys.txt

Keys have an owner user ID, a group access ID, and a permissions mask. The mask

-has up to eight bits each for user, group and other access. Only five of each

-set of eight bits are defined. These permissions granted are:

+has up to eight bits each for possessor, user, group and other access. Only

+six of each set of eight bits are defined. These permissions granted are:

@@ -224,6 +224,10 @@ set of eight bits are defined. These permissions granted are:

keyring to a key, a process must have Write permission on the keyring and

+ This permits a key's UID, GID and permissions mask to be changed.

For changing the ownership, group ID or permissions mask, being the owner of

type, description and permissions. The payload of the key is not available

- SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY

- 000004d3 I--Q-- 3 perm 1f0000 32 -1 keyring _uid_ses.32: empty

+ SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY

+ 00000001 I----- 39 perm 1f3f0000 0 0 keyring _uid_ses.0: 1/4

+ 000004d3 I--Q-- 3 perm 1f3f0000 32 -1 keyring _uid_ses.32: empty

/sbin/request-key will be invoked in an attempt to obtain a key. The

callout_info string will be passed as an argument to the program.

- key_serial_t keyctl(KEYCTL_READ, key_serial_t keyring, char *buffer,

+ long keyctl(KEYCTL_READ, key_serial_t keyring, char *buffer,

This function attempts to read the payload data from the specified key

into the buffer. The process must have read permission on the key to

If the kernel calls back to userspace to complete the instantiation of a

key, userspace should use this call to supply data for the key before the

If the kernel calls back to userspace to complete the instantiation of a

key, userspace should use this call mark the key as negative before the

@@ -637,6 +643,34 @@ call, and the key released upon close. How to deal with conflicting keys due to

two different users opening the same file is left to the filesystem author to

+Note that there are two different types of pointers to keys that may be

+ This simply points to the key structure itself. Key structures will be at

+ This is equivalent to a struct key *, but the least significant bit is set

+ if the caller "possesses" the key. By "possession" it is meant that the

+ calling processes has a searchable link to the key from one of its

+ The first function constructs a key reference from a key pointer and

+ possession information (which must be 0 or 1 and not any other value).

+ The second function retrieves the key pointer from a reference and the

When accessing a key's payload contents, certain precautions must be taken to

prevent access vs modification races. See the section "Notes on accessing

If successful, the key will have been attached to the default keyring for

implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.

(*) When it is no longer required, the key should be released using:

- This can be called from interrupt context. If CONFIG_KEYS is not set then

+ These can be called from interrupt context. If CONFIG_KEYS is not set then

(*) If a keyring was found in the search, this can be further searched by:

This searches the keyring tree specified for a matching key. Error ENOKEY

- is returned upon failure. If successful, the returned key will need to be

+ is returned upon failure (use IS_ERR/PTR_ERR to determine). If successful,

+ The possession attribute from the keyring reference is used to control

+ access through the permissions mask and is propagated to the returned key

(*) To check the validity of a key, this function can be called:

@@ -732,7 +776,7 @@ More complex payload contents must be allocated and a pointer to them set in

key->payload.data. One of the following ways must be selected to access the

If the key type does not have a modify method, then the key's payload can

be accessed without any form of locking, provided that it's known to be

diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt
index e191baad8308..d5d3f064f552 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt

can be performed in optimal order. Not all SCSI devices support

- This option is available only if the kernel has been compiled with

-CONFIG_STRAM_SWAP enabled. Normally, the kernel then determines

-dynamically whether to actually use ST-RAM as swap space. (Currently,

-the fraction of ST-RAM must be less or equal 1/3 of total memory to

-enable this swapping.) You can override the kernel's decision by

-specifying this option. 1 for <do_swap> means always enable the swap,

-even if you have less alternate RAM. 0 stands for never swap to

-ST-RAM, even if it's small enough compared to the rest of memory.

- If ST-RAM swapping is enabled, the kernel usually uses all free

-ST-RAM as swap "device". If the kernel resides in ST-RAM, the region

-allocated by it is obviously never used for swapping :-) You can also

-limit this amount by specifying the second parameter, <max_swap>, if

-you want to use parts of ST-RAM as normal system memory. <max_swap> is

-in kBytes and the number should be a multiple of 4 (otherwise: rounded

diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
index bd8eefa17587..af67faccf4de 100644
--- a/Documentation/magic-number.txt
+++ b/Documentation/magic-number.txt

@@ -120,7 +120,7 @@ ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_li

TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c

diff --git a/Documentation/mca.txt b/Documentation/mca.txt
index 6e32c305c65a..60913354cb7d 100644
--- a/Documentation/mca.txt
+++ b/Documentation/mca.txt

@@ -252,7 +252,7 @@ their names here, but I don't have a list handy. Check the MCA Linux

=====================================================================

diff --git a/Documentation/md.txt b/Documentation/md.txt
index e2b536992a27..23e6cce40f9c 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt

Once started with RUN_ARRAY, uninitialized spares can be added with

+Each 'md' device will contain a subdirectory called 'md' which

+ a text file indicating the 'raid level'. This may be a standard

+ numerical level prefixed by "RAID-" - e.g. "RAID-5", or some

+ a text file with a simple number indicating the number of devices

+ in a fully functional array. If this is not yet known, the file

+ possible) this will contain the larger of the old and new sizes.

+As component devices are added to an md array, they appear in the 'md'

+where XXX is a name that the kernel knows for the device, e.g. hdb1.

+ /sys/block/md0/md/dev-hdb1/block -> ../../../../block/hdb/hdb1

+ A file recording the current state of the device in the array

+An active md device will also contain and entry for each active device

+Active md devices for levels that support data redundancy (1,4,5,6)

+ a text file that can be used to monitor and control the rebuild

+ This file is writable, and each of the strings that could be

+ guarantee that another resync/recovery may not be automatically

+ performing 'resync', md will count the number of errors that are

+ re-written. As most raid levels work in units of pages rather

+ than sectors, this my be larger than the number of actual errors

+Each active md device may also have attributes specific to the

+These are specific to the implementation of the module and could

+ number of entries in the stripe cache. This is writable, but

+ there are upper and lower limits (32768, 16). Default is 128.

diff --git a/Documentation/mips/AU1xxx_IDE.README b/Documentation/mips/AU1xxx_IDE.README
new file mode 100644
index 000000000000..a7e4c4ea3560
--- /dev/null
+++ b/Documentation/mips/AU1xxx_IDE.README

+This file describes the 'drivers/ide/mips/au1xxx-ide.c', related files and the

+If you are short in patience and just want to know how to add your hard disc to

+the white or black list, go to the 'ADD NEW HARD DISC TO WHITE OR BLACK LIST'

+This program 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

+THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,

+INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND

+FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR

+BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR

+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF

+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS

+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN

+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)

+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE

+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.,

+Note: for more information, please refer "AMD Alchemy Au1200/Au1550 IDE

+ CONFIG_BLK_DEV_IDE_AU1XXX_PIO_DBDMA - enable the PIO+DBDMA mode

+ CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA - enable the MWDMA mode

+ CONFIG_BLK_DEV_IDE_AU1XXX_BURSTABLE_ON - set Burstable FIFO in DBDMA

+ CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ - maximum transfer size

+If MWDMA is enabled and the connected hard disc is not on the white list, the

+kernel switches to a "safe mwdma mode" at boot time. In this mode the IDE

+performance is substantial slower then in full speed mwdma. In this case

+please add your hard disc to the white list (follow instruction from 'ADD NEW

+The AU1XXX IDE driver supported all PIO modes - PIO mode 0/1/2/3/4 - and all

+MWDMA modes - MWDMA 0/1/2 -. There is no support for SWDMA and UDMA mode.

+To change the PIO mode use the program hdparm with option -p, e.g.

+'hdparm -p0 [device]' for PIO mode 0. To enable the MWDMA mode use the option

+If the used system doesn't need USB support enable the following kernel configs:

+If the used system need the USB support enable the following kernel configs for

+ ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx

+ hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63, (U)DMA

+ Add your hard disc to the dma_white_list or dma_black_list structur.

+ Enable MWDMA support in the kernel configuration. Recompile the kernel and

+ If you have add a hard disc to the white list, please run some stress tests

+These drivers wouldn't have been done without the base of kernel 2.4.x AU1XXX

diff --git a/Documentation/networking/README.ipw2100 b/Documentation/networking/README.ipw2100
index 2046948b020d..3ab40379d1cf 100644
--- a/Documentation/networking/README.ipw2100
+++ b/Documentation/networking/README.ipw2100

-Intel(R) PRO/Wireless 2100 Network Connection Driver for Linux

+Intel wireless LAN adapters are engineered, manufactured, tested, and

+quality checked to ensure that they meet all necessary local and

+governmental regulatory agency requirements for the regions that they

+are designated and/or marked to ship into. Since wireless LANs are

+generally unlicensed devices that share spectrum with radars,

+satellites, and other licensed and unlicensed devices, it is sometimes

+necessary to dynamically detect, avoid, and limit usage to avoid

+interference with these devices. In many instances Intel is required to

+provide test data to prove regional and local compliance to regional and

+governmental regulations before certification or approval to use the

+product is granted. Intel's wireless LAN's EEPROM, firmware, and

+software driver are designed to carefully control parameters that affect

+radio operation and to ensure electromagnetic compliance (EMC). These

+parameters include, without limitation, RF power, spectrum usage,

+For these reasons Intel cannot permit any manipulation by third parties

+of the software provided in binary format with the wireless WLAN

+adapters (e.g., the EEPROM and firmware). Furthermore, if you use any

+patches, utilities, or code with the Intel wireless LAN adapters that

+have been manipulated by an unauthorized party (i.e., patches,

+utilities, or code (including open source code modifications) which have

+not been validated by Intel), (i) you will be solely responsible for

+ensuring the regulatory compliance of the products, (ii) Intel will bear

+no liability, under any theory of liability for any issues associated

+with the modified products, including without limitation, claims under

+the warranty and/or issues arising from regulatory non-compliance, and

+(iii) Intel will not provide or be required to assist in providing

+Note: Many regulatory agencies consider Wireless LAN adapters to be

+modules, and accordingly, condition system-level regulatory approval

+upon receipt and review of test data documenting that the antennas and

+system configuration do not cause the EMC and radio operation to be

+The drivers available for download from SourceForge are provided as a

+part of a development project. Conformance to local regulatory

+requirements is the responsibility of the individual developer. As

+such, if you are interested in deploying or shipping a driver as part of

+solution intended to be used for purposes other than development, please

This document provides a brief overview of the features supported by the

IPW2100 driver project. The main project website, where the latest

@@ -34,9 +89,8 @@ potential fixes and patches, as well as links to the development mailing list

@@ -51,9 +105,8 @@ on the amount of validation and interoperability testing that has been

If the driver is built as a module, the following optional parameters are used

by entering them on the command line with the modprobe command using this

@@ -75,9 +128,9 @@ associate boolean associate=0 /* Do NOT auto associate */

There are several ways to control the behavior of the driver. Many of the

general capabilities are exposed through the Wireless Tools (iwconfig). There

@@ -120,9 +173,8 @@ For the device level files, see /sys/bus/pci/drivers/ipw2100:

based RF kill from ON -> OFF -> ON, the radio will NOT come back on

Most laptops provide the ability for the user to physically disable the radio.

Some vendors have implemented this as a physical switch that requires no

software to turn the radio off and on. On other laptops, however, the switch

@@ -134,9 +186,8 @@ See the Sysfs helper file 'rf_kill' for determining the state of the RF switch

As the firmware is licensed under a restricted use license, it can not be

included within the kernel sources. To enable the IPW2100 you will need a

@@ -146,9 +197,8 @@ You can obtain these images from <http://ipw2100.sf.net/firmware.php>.

The IPW2100 supports the configuration of the Power Save Protocol

through a private wireless extension interface. The IPW2100 supports

@@ -200,9 +250,8 @@ xxxx/yyyy will be replaced with 'off' -- the level reported will be the active

@@ -218,9 +267,8 @@ For installation support on the ipw2100 1.1.0 driver on Linux kernels

diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
index 6916080c5f03..c6492d3839fa 100644
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200

-Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)

-PRO/Wireless 2200BG Driver for Linux is a unified driver that works on

-both hardware adapters listed above. In this document the Intel(R)

-PRO/Wireless 2915ABG Driver for Linux will be used to reference the

+Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)

+PRO/Wireless 2200BG Driver for Linux is a unified driver that works on

+both hardware adapters listed above. In this document the Intel(R)

+PRO/Wireless 2915ABG Driver for Linux will be used to reference the