Merge tag 'docs-for-linus' of git://git.lwn.net/linux

!Iinclude/linux/input-polldev.h

!Edrivers/input/input-polldev.c

     </sect1>

     <sect1><title>Matrix keyboars/keypads</title>

     <sect1><title>Matrix keyboards/keypads</title>

!Iinclude/linux/input/matrix_keypad.h

     </sect1>

     <sect1><title>Sparse keymap support</title>

Documentation

------------

-------------

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

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

    release a new -rc kernel every week.

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

    process should last around 6 weeks.

  - Known regressions in each release are periodically posted to the 

    linux-kernel mailing list.  The goal is to reduce the length of 

    that list to zero before declaring the kernel to be "ready," but, in

    the real world, a small number of regressions often remain at 

    release time.

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

mailing list about kernel releases:

	preconceived timeline."

4.x.y -stable kernel tree

---------------------------

-------------------------

Kernels with 3-part versions are -stable kernels. They contain

relatively small and critical fixes for security problems or significant

regressions discovered in a given 4.x kernel.

how the release process works.

4.x -git patches

------------------

----------------

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

http://patchwork.kernel.org/.

4.x -next kernel tree for integration tests

---------------------------------------------

-------------------------------------------

Before updates from subsystem trees are merged into the mainline 4.x

tree, they need to be integration-tested.  For this purpose, a special

testing repository exists into which virtually all subsystem trees are

--------------------------------

It can be helpful to manually add In-Reply-To: headers to a patch

(e.g., when using "git send email") to associate the patch with

(e.g., when using "git send-email") to associate the patch with

previous relevant discussion, e.g. to link a bug fix to the email with

the bug report.  However, for a multi-patch series, it is generally

best to avoid using In-Reply-To: to link to older versions of the

    else if (f ~ /0xf/)

	return 4

    printf "unknown legnth " f "\n" > "/dev/stderr"

    printf "unknown length " f "\n" > "/dev/stderr"

    exit

}

# (If no arguments are given then it will print the host architecture's status.)

#

ARCH=${1:-$(arch | sed 's/x86_64/x86/' | sed 's/i386/x86/')}

ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}

cd $(dirname $0)

echo "#"