hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

This commit is contained in:
Jiri Kosina 2008-05-06 16:57:55 +02:00
parent aaad2b0c75 a15306365a
commit 7022b15e2a
4557 changed files with 224602 additions and 90805 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@ -27,6 +27,7 @@ TAGS
vmlinux*
!vmlinux.lds.S
System.map
Module.markers
Module.symvers
!.gitignore
@ -40,6 +41,7 @@ include/linux/autoconf.h
include/linux/compile.h
include/linux/version.h
include/linux/utsrelease.h
include/linux/bounds.h
# stgit generated dirs
patches-*

1
.mailmap
View File

@ -88,6 +88,7 @@ Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
Sachin P Sant <ssant@in.ibm.com>
Sam Ravnborg <sam@mars.ravnborg.org>
S.Çağlar Onur <caglar@pardus.org.tr>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <shemminger@osdl.org>

8
CREDITS
View File

@ -403,6 +403,8 @@ D: Linux CD and Support Giveaway List
N: Erik Inge Bolsø
E: knan@mo.himolde.no
D: Misc kernel hacks
D: Updated PC speaker driver for 2.3
S: Norway
N: Andreas E. Bombe
E: andreas.bombe@munich.netsurf.de
@ -3116,6 +3118,12 @@ S: Post Office Box 64132
S: Sunnyvale, California 94088-4132
S: USA
N: Stas Sergeev
E: stsp@users.sourceforge.net
D: PCM PC-Speaker driver
D: misc fixes
S: Russia
N: Simon Shapiro
E: shimon@i-Connect.Net
W: http://www.-i-Connect.Net/~shimon

2
Documentation/00-INDEX
View File

@ -329,8 +329,6 @@ sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
smart-config.txt
- description of the Smart Config makefile feature.
sound/
- directory with info on sound card support.
sparc/

212
Documentation/ABI/stable/sysfs-class-ubi Normal file
View File

@ -0,0 +1,212 @@
What: /sys/class/ubi/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The ubi/ class sub-directory belongs to the UBI subsystem and
provides general UBI information, per-UBI device information
and per-UBI volume information.
What: /sys/class/ubi/version
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
This file contains version of the latest supported UBI on-media
format. Currently it is 1, and there is no plan to change this.
However, if in the future UBI needs on-flash format changes
which cannot be done in a compatible manner, a new format
version will be added. So this is a mechanism for possible
future backward-compatible (but forward-incompatible)
improvements.
What: /sys/class/ubiX/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The /sys/class/ubi0, /sys/class/ubi1, etc directories describe
UBI devices (UBI device 0, 1, etc). They contain general UBI
device information and per UBI volume information (each UBI
device may have many UBI volumes)
What: /sys/class/ubi/ubiX/avail_eraseblocks
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Amount of available logical eraseblock. For example, one may
create a new UBI volume which has this amount of logical
eraseblocks.
What: /sys/class/ubi/ubiX/bad_peb_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of bad physical eraseblocks on the underlying MTD device.
What: /sys/class/ubi/ubiX/bgt_enabled
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the UBI background thread is disabled,
and ASCII "1\n" if it is enabled.
What: /sys/class/ubi/ubiX/dev
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Major and minor numbers of the character device corresponding
to this UBI device (in <major>:<minor> format).
What: /sys/class/ubi/ubiX/eraseblock_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum logical eraseblock size this UBI device may provide. UBI
volumes may have smaller logical eraseblock size because of their
alignment.
What: /sys/class/ubi/ubiX/max_ec
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum physical eraseblock erase counter value.
What: /sys/class/ubi/ubiX/max_vol_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum number of volumes which this UBI device may have.
What: /sys/class/ubi/ubiX/min_io_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Minimum input/output unit size. All the I/O may only be done
in fractions of the contained number.
What: /sys/class/ubi/ubiX/mtd_num
Date: January 2008
KernelVersion: 2.6.25
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Number of the underlying MTD device.
What: /sys/class/ubi/ubiX/reserved_for_bad
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Number of physical eraseblocks reserved for bad block handling.
What: /sys/class/ubi/ubiX/total_eraseblocks
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Total number of good (not marked as bad) physical eraseblocks on
the underlying MTD device.
What: /sys/class/ubi/ubiX/volumes_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of volumes on this UBI device.
What: /sys/class/ubi/ubiX/ubiX_Y/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The /sys/class/ubi/ubiX/ubiX_0/, /sys/class/ubi/ubiX/ubiX_1/,
etc directories describe UBI volumes on UBI device X (volumes
0, 1, etc).
What: /sys/class/ubi/ubiX/ubiX_Y/alignment
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume alignment - the value the logical eraseblock size of
this volume has to be aligned on. For example, 2048 means that
logical eraseblock size is multiple of 2048. In other words,
volume logical eraseblock size is UBI device logical eraseblock
size aligned to the alignment value.
What: /sys/class/ubi/ubiX/ubiX_Y/corrupted
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the UBI volume is OK, and ASCII "1\n"
if it is corrupted (e.g., due to an interrupted volume update).
What: /sys/class/ubi/ubiX/ubiX_Y/data_bytes
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The amount of data this volume contains. This value makes sense
only for static volumes, and for dynamic volume it equivalent
to the total volume size in bytes.
What: /sys/class/ubi/ubiX/ubiX_Y/dev
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Major and minor numbers of the character device corresponding
to this UBI volume (in <major>:<minor> format).
What: /sys/class/ubi/ubiX/ubiX_Y/name
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume name.
What: /sys/class/ubi/ubiX/ubiX_Y/reserved_ebs
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of physical eraseblock reserved for this volume.
Equivalent to the volume size in logical eraseblocks.
What: /sys/class/ubi/ubiX/ubiX_Y/type
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume type. Contains ASCII "dynamic\n" for dynamic volumes and
"static\n" for static volumes.
What: /sys/class/ubi/ubiX/ubiX_Y/upd_marker
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the update marker is not set for this
volume, and "1\n" if it is set. The update marker is set when
volume update starts, and cleaned when it ends. So the presence
of the update marker indicates that the volume is being updated
at the moment of the update was interrupted. The later may be
checked using the "corrupted" sysfs file.
What: /sys/class/ubi/ubiX/ubiX_Y/usable_eb_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Logical eraseblock size of this volume. Equivalent to logical
eraseblock size of the device aligned on the volume alignment
value.

46
Documentation/ABI/testing/sysfs-class-bdi Normal file
View File

@ -0,0 +1,46 @@
What: /sys/class/bdi/<bdi>/
Date: January 2008
Contact: Peter Zijlstra <a.p.zijlstra@chello.nl>
Description:
Provide a place in sysfs for the backing_dev_info object. This allows
setting and retrieving various BDI specific variables.
The <bdi> identifier can be either of the following:
MAJOR:MINOR
Device number for block devices, or value of st_dev on
non-block filesystems which provide their own BDI, such as NFS
and FUSE.
default
The default backing dev, used for non-block device backed
filesystems which do not provide their own BDI.
Files under /sys/class/bdi/<bdi>/
---------------------------------
read_ahead_kb (read-write)
Size of the read-ahead window in kilobytes
min_ratio (read-write)
Under normal circumstances each device is given a part of the
total write-back cache that relates to its current average
writeout speed in relation to the other devices.
The 'min_ratio' parameter allows assigning a minimum
percentage of the write-back cache to a particular device.
For example, this is useful for providing a minimum QoS.
max_ratio (read-write)
Allows limiting a particular device to use not more than the
given percentage of the write-back cache. This is useful in
situations where we want to avoid one device taking all or
most of the write-back cache. For example in case of an NFS
mount that is prone to get stuck, or a FUSE mount which cannot
be trusted to play fair.

69
Documentation/DMA-API.txt
View File

@ -145,7 +145,7 @@ Part Ic - DMA addressing limitations
int
dma_supported(struct device *dev, u64 mask)
int
pci_dma_supported(struct device *dev, u64 mask)
pci_dma_supported(struct pci_dev *hwdev, u64 mask)
Checks to see if the device can support DMA to the memory described by
mask.
@ -189,7 +189,7 @@ dma_addr_t
dma_map_single(struct device *dev, void *cpu_addr, size_t size,
enum dma_data_direction direction)
dma_addr_t
pci_map_single(struct device *dev, void *cpu_addr, size_t size,
pci_map_single(struct pci_dev *hwdev, void *cpu_addr, size_t size,
int direction)
Maps a piece of processor virtual memory so it can be accessed by the
@ -395,6 +395,71 @@ Notes: You must do this:
See also dma_map_single().
dma_addr_t
dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size,
enum dma_data_direction dir,
struct dma_attrs *attrs)
void
dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir,
struct dma_attrs *attrs)
int
dma_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
int nents, enum dma_data_direction dir,
struct dma_attrs *attrs)
void
dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sgl,
int nents, enum dma_data_direction dir,
struct dma_attrs *attrs)
The four functions above are just like the counterpart functions
without the _attrs suffixes, except that they pass an optional
struct dma_attrs*.
struct dma_attrs encapsulates a set of "dma attributes". For the
definition of struct dma_attrs see linux/dma-attrs.h.
The interpretation of dma attributes is architecture-specific, and
each attribute should be documented in Documentation/DMA-attributes.txt.
If struct dma_attrs* is NULL, the semantics of each of these
functions is identical to those of the corresponding function
without the _attrs suffix. As a result dma_map_single_attrs()
can generally replace dma_map_single(), etc.
As an example of the use of the *_attrs functions, here's how
you could pass an attribute DMA_ATTR_FOO when mapping memory
for DMA:
#include <linux/dma-attrs.h>
/* DMA_ATTR_FOO should be defined in linux/dma-attrs.h and
* documented in Documentation/DMA-attributes.txt */
...
DEFINE_DMA_ATTRS(attrs);
dma_set_attr(DMA_ATTR_FOO, &attrs);
....
n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, &attr);
....
Architectures that care about DMA_ATTR_FOO would check for its
presence in their implementations of the mapping and unmapping
routines, e.g.:
void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir,
struct dma_attrs *attrs)
{
....
int foo = dma_get_attr(DMA_ATTR_FOO, attrs);
....
if (foo)
/* twizzle the frobnozzle */
....
Part II - Advanced dma_ usage
-----------------------------

24
Documentation/DMA-attributes.txt Normal file
View File

@ -0,0 +1,24 @@
DMA attributes
==============
This document describes the semantics of the DMA attributes that are
defined in linux/dma-attrs.h.
DMA_ATTR_WRITE_BARRIER
----------------------
DMA_ATTR_WRITE_BARRIER is a (write) barrier attribute for DMA. DMA
to a memory region with the DMA_ATTR_WRITE_BARRIER attribute forces
all pending DMA writes to complete, and thus provides a mechanism to
strictly order DMA from a device across all intervening busses and
bridges. This barrier is not specific to a particular type of
interconnect, it applies to the system as a whole, and so its
implementation must account for the idiosyncracies of the system all
the way from the DMA device to memory.
As an example of a situation where DMA_ATTR_WRITE_BARRIER would be
useful, suppose that a device does a DMA write to indicate that data is
ready and available in memory. The DMA of the "completion indication"
could race with data DMA. Mapping the memory used for completion
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.

38
Documentation/DMA-mapping.txt
View File

@ -315,11 +315,11 @@ you should do:
dma_addr_t dma_handle;
cpu_addr = pci_alloc_consistent(dev, size, &dma_handle);
cpu_addr = pci_alloc_consistent(pdev, size, &dma_handle);
where dev is a struct pci_dev *. You should pass NULL for PCI like buses
where devices don't have struct pci_dev (like ISA, EISA). This may be
called in interrupt context.
where pdev is a struct pci_dev *. This may be called in interrupt context.
You should use dma_alloc_coherent (see DMA-API.txt) for buses
where devices don't have struct pci_dev (like ISA, EISA).
This argument is needed because the DMA translations may be bus
specific (and often is private to the bus which the device is attached
@ -332,7 +332,7 @@ __get_free_pages (but takes size instead of a page order). If your
driver needs regions sized smaller than a page, you may prefer using
the pci_pool interface, described below.
The consistent DMA mapping interfaces, for non-NULL dev, will by
The consistent DMA mapping interfaces, for non-NULL pdev, will by
default return a DMA address which is SAC (Single Address Cycle)
addressable. Even if the device indicates (via PCI dma mask) that it
may address the upper 32-bits and thus perform DAC cycles, consistent
@ -354,9 +354,9 @@ buffer you receive will not cross a 64K boundary.
To unmap and free such a DMA region, you call:
pci_free_consistent(dev, size, cpu_addr, dma_handle);
pci_free_consistent(pdev, size, cpu_addr, dma_handle);
where dev, size are the same as in the above call and cpu_addr and
where pdev, size are the same as in the above call and cpu_addr and
dma_handle are the values pci_alloc_consistent returned to you.
This function may not be called in interrupt context.
@ -371,9 +371,9 @@ Create a pci_pool like this:
struct pci_pool *pool;
pool = pci_pool_create(name, dev, size, align, alloc);
pool = pci_pool_create(name, pdev, size, align, alloc);
The "name" is for diagnostics (like a kmem_cache name); dev and size
The "name" is for diagnostics (like a kmem_cache name); pdev and size
are as above. The device's hardware alignment requirement for this
type of data is "align" (which is expressed in bytes, and must be a
power of two). If your device has no boundary crossing restrictions,
@ -472,11 +472,11 @@ To map a single region, you do:
void *addr = buffer->ptr;
size_t size = buffer->len;
dma_handle = pci_map_single(dev, addr, size, direction);
dma_handle = pci_map_single(pdev, addr, size, direction);
and to unmap it:
pci_unmap_single(dev, dma_handle, size, direction);
pci_unmap_single(pdev, dma_handle, size, direction);
You should call pci_unmap_single when the DMA activity is finished, e.g.
from the interrupt which told you that the DMA transfer is done.
@ -493,17 +493,17 @@ Specifically:
unsigned long offset = buffer->offset;
size_t size = buffer->len;
dma_handle = pci_map_page(dev, page, offset, size, direction);
dma_handle = pci_map_page(pdev, page, offset, size, direction);
...
pci_unmap_page(dev, dma_handle, size, direction);
pci_unmap_page(pdev, dma_handle, size, direction);
Here, "offset" means byte offset within the given page.
With scatterlists, you map a region gathered from several regions by:
int i, count = pci_map_sg(dev, sglist, nents, direction);
int i, count = pci_map_sg(pdev, sglist, nents, direction);
struct scatterlist *sg;
for_each_sg(sglist, sg, count, i) {
@ -527,7 +527,7 @@ accessed sg->address and sg->length as shown above.
To unmap a scatterlist, just call:
pci_unmap_sg(dev, sglist, nents, direction);
pci_unmap_sg(pdev, sglist, nents, direction);
Again, make sure DMA activity has already finished.
@ -550,11 +550,11 @@ correct copy of the DMA buffer.
So, firstly, just map it with pci_map_{single,sg}, and after each DMA
transfer call either:
pci_dma_sync_single_for_cpu(dev, dma_handle, size, direction);
pci_dma_sync_single_for_cpu(pdev, dma_handle, size, direction);
or:
pci_dma_sync_sg_for_cpu(dev, sglist, nents, direction);
pci_dma_sync_sg_for_cpu(pdev, sglist, nents, direction);
as appropriate.
@ -562,7 +562,7 @@ Then, if you wish to let the device get at the DMA area again,
finish accessing the data with the cpu, and then before actually
giving the buffer to the hardware call either:
pci_dma_sync_single_for_device(dev, dma_handle, size, direction);
pci_dma_sync_single_for_device(pdev, dma_handle, size, direction);
or:
@ -739,7 +739,7 @@ failure can be determined by:
dma_addr_t dma_handle;
dma_handle = pci_map_single(dev, addr, size, direction);
dma_handle = pci_map_single(pdev, addr, size, direction);
if (pci_dma_mapping_error(dma_handle)) {
/*
* reduce current DMA mapping usage,

7
Documentation/DocBook/Makefile
View File

@ -12,7 +12,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml
mac80211.xml debugobjects.xml
###
# The build process is as follows (targets):
@ -187,8 +187,11 @@ quiet_cmd_fig2png = FIG2PNG $@
###
# Rule to convert a .c file to inline XML documentation
gen_xml = :
quiet_gen_xml = echo ' GEN $@'
silent_gen_xml = :
%.xml: %.c
@echo ' GEN $@'
@$($(quiet)gen_xml)
@( \
echo "<programlisting>"; \
expand --tabs=8 < $< | \

391
Documentation/DocBook/debugobjects.tmpl Normal file
View File

@ -0,0 +1,391 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="debug-objects-guide">
<bookinfo>
<title>Debug objects life time</title>
<authorgroup>
<author>
<firstname>Thomas</firstname>
<surname>Gleixner</surname>
<affiliation>
<address>
<email>tglx@linutronix.de</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2008</year>
<holder>Thomas Gleixner</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="intro">
<title>Introduction</title>
<para>
debugobjects is a generic infrastructure to track the life time
of kernel objects and validate the operations on those.
</para>
<para>
debugobjects is useful to check for the following error patterns:
<itemizedlist>
<listitem><para>Activation of uninitialized objects</para></listitem>
<listitem><para>Initialization of active objects</para></listitem>
<listitem><para>Usage of freed/destroyed objects</para></listitem>
</itemizedlist>
</para>
<para>
debugobjects is not changing the data structure of the real
object so it can be compiled in with a minimal runtime impact
and enabled on demand with a kernel command line option.
</para>
</chapter>
<chapter id="howto">
<title>Howto use debugobjects</title>
<para>
A kernel subsystem needs to provide a data structure which
describes the object type and add calls into the debug code at
appropriate places. The data structure to describe the object
type needs at minimum the name of the object type. Optional
functions can and should be provided to fixup detected problems
so the kernel can continue to work and the debug information can
be retrieved from a live system instead of hard core debugging
with serial consoles and stack trace transcripts from the
monitor.
</para>
<para>
The debug calls provided by debugobjects are:
<itemizedlist>
<listitem><para>debug_object_init</para></listitem>
<listitem><para>debug_object_init_on_stack</para></listitem>
<listitem><para>debug_object_activate</para></listitem>
<listitem><para>debug_object_deactivate</para></listitem>
<listitem><para>debug_object_destroy</para></listitem>
<listitem><para>debug_object_free</para></listitem>
</itemizedlist>
Each of these functions takes the address of the real object and
a pointer to the object type specific debug description
structure.
</para>
<para>
Each detected error is reported in the statistics and a limited
number of errors are printk'ed including a full stack trace.
</para>
<para>
The statistics are available via debugfs/debug_objects/stats.
They provide information about the number of warnings and the
number of successful fixups along with information about the
usage of the internal tracking objects and the state of the
internal tracking objects pool.
</para>
</chapter>
<chapter id="debugfunctions">
<title>Debug functions</title>
<sect1 id="prototypes">
<title>Debug object function reference</title>
!Elib/debugobjects.c
</sect1>
<sect1 id="debug_object_init">
<title>debug_object_init</title>
<para>
This function is called whenever the initialization function
of a real object is called.
</para>
<para>
When the real object is already tracked by debugobjects it is
checked, whether the object can be initialized. Initializing
is not allowed for active and destroyed objects. When
debugobjects detects an error, then it calls the fixup_init
function of the object type description structure if provided
by the caller. The fixup function can correct the problem
before the real initialization of the object happens. E.g. it
can deactivate an active object in order to prevent damage to
the subsystem.
</para>
<para>
When the real object is not yet tracked by debugobjects,
debugobjects allocates a tracker object for the real object
and sets the tracker object state to ODEBUG_STATE_INIT. It
verifies that the object is not on the callers stack. If it is
on the callers stack then a limited number of warnings
including a full stack trace is printk'ed. The calling code
must use debug_object_init_on_stack() and remove the object
before leaving the function which allocated it. See next
section.
</para>
</sect1>
<sect1 id="debug_object_init_on_stack">
<title>debug_object_init_on_stack</title>
<para>
This function is called whenever the initialization function
of a real object which resides on the stack is called.
</para>
<para>
When the real object is already tracked by debugobjects it is
checked, whether the object can be initialized. Initializing
is not allowed for active and destroyed objects. When
debugobjects detects an error, then it calls the fixup_init
function of the object type description structure if provided
by the caller. The fixup function can correct the problem
before the real initialization of the object happens. E.g. it
can deactivate an active object in order to prevent damage to
the subsystem.
</para>
<para>
When the real object is not yet tracked by debugobjects
debugobjects allocates a tracker object for the real object
and sets the tracker object state to ODEBUG_STATE_INIT. It
verifies that the object is on the callers stack.
</para>
<para>
An object which is on the stack must be removed from the
tracker by calling debug_object_free() before the function
which allocates the object returns. Otherwise we keep track of
stale objects.
</para>
</sect1>
<sect1 id="debug_object_activate">
<title>debug_object_activate</title>
<para>
This function is called whenever the activation function of a
real object is called.
</para>
<para>
When the real object is already tracked by debugobjects it is
checked, whether the object can be activated. Activating is
not allowed for active and destroyed objects. When
debugobjects detects an error, then it calls the
fixup_activate function of the object type description
structure if provided by the caller. The fixup function can
correct the problem before the real activation of the object
happens. E.g. it can deactivate an active object in order to
prevent damage to the subsystem.
</para>
<para>
When the real object is not yet tracked by debugobjects then
the fixup_activate function is called if available. This is
necessary to allow the legitimate activation of statically
allocated and initialized objects. The fixup function checks
whether the object is valid and calls the debug_objects_init()
function to initialize the tracking of this object.
</para>
<para>
When the activation is legitimate, then the state of the
associated tracker object is set to ODEBUG_STATE_ACTIVE.
</para>
</sect1>
<sect1 id="debug_object_deactivate">
<title>debug_object_deactivate</title>
<para>
This function is called whenever the deactivation function of
a real object is called.
</para>
<para>
When the real object is tracked by debugobjects it is checked,
whether the object can be deactivated. Deactivating is not
allowed for untracked or destroyed objects.
</para>
<para>
When the deactivation is legitimate, then the state of the
associated tracker object is set to ODEBUG_STATE_INACTIVE.
</para>
</sect1>
<sect1 id="debug_object_destroy">
<title>debug_object_destroy</title>
<para>
This function is called to mark an object destroyed. This is
useful to prevent the usage of invalid objects, which are
still available in memory: either statically allocated objects
or objects which are freed later.
</para>
<para>
When the real object is tracked by debugobjects it is checked,
whether the object can be destroyed. Destruction is not
allowed for active and destroyed objects. When debugobjects
detects an error, then it calls the fixup_destroy function of
the object type description structure if provided by the
caller. The fixup function can correct the problem before the
real destruction of the object happens. E.g. it can deactivate
an active object in order to prevent damage to the subsystem.
</para>
<para>
When the destruction is legitimate, then the state of the
associated tracker object is set to ODEBUG_STATE_DESTROYED.
</para>
</sect1>
<sect1 id="debug_object_free">
<title>debug_object_free</title>
<para>
This function is called before an object is freed.
</para>
<para>
When the real object is tracked by debugobjects it is checked,
whether the object can be freed. Free is not allowed for
active objects. When debugobjects detects an error, then it
calls the fixup_free function of the object type description
structure if provided by the caller. The fixup function can
correct the problem before the real free of the object
happens. E.g. it can deactivate an active object in order to
prevent damage to the subsystem.
</para>
<para>
Note that debug_object_free removes the object from the
tracker. Later usage of the object is detected by the other
debug checks.
</para>
</sect1>
</chapter>
<chapter id="fixupfunctions">
<title>Fixup functions</title>
<sect1 id="debug_obj_descr">
<title>Debug object type description structure</title>
!Iinclude/linux/debugobjects.h
</sect1>
<sect1 id="fixup_init">
<title>fixup_init</title>
<para>
This function is called from the debug code whenever a problem
in debug_object_init is detected. The function takes the
address of the object and the state which is currently
recorded in the tracker.
</para>
<para>
Called from debug_object_init when the object state is:
<itemizedlist>
<listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
statistics.
</para>
<para>
Note, that the function needs to call the debug_object_init()
function again, after the damage has been repaired in order to
keep the state consistent.
</para>
</sect1>
<sect1 id="fixup_activate">
<title>fixup_activate</title>
<para>
This function is called from the debug code whenever a problem
in debug_object_activate is detected.
</para>
<para>
Called from debug_object_activate when the object state is:
<itemizedlist>
<listitem><para>ODEBUG_STATE_NOTAVAILABLE</para></listitem>
<listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
statistics.
</para>
<para>
Note that the function needs to call the debug_object_activate()
function again after the damage has been repaired in order to
keep the state consistent.
</para>
<para>
The activation of statically initialized objects is a special
case. When debug_object_activate() has no tracked object for
this object address then fixup_activate() is called with
object state ODEBUG_STATE_NOTAVAILABLE. The fixup function
needs to check whether this is a legitimate case of a
statically initialized object or not. In case it is it calls
debug_object_init() and debug_object_activate() to make the
object known to the tracker and marked active. In this case
the function should return 0 because this is not a real fixup.
</para>
</sect1>
<sect1 id="fixup_destroy">
<title>fixup_destroy</title>
<para>
This function is called from the debug code whenever a problem
in debug_object_destroy is detected.
</para>
<para>
Called from debug_object_destroy when the object state is:
<itemizedlist>
<listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
statistics.
</para>
</sect1>
<sect1 id="fixup_free">
<title>fixup_free</title>
<para>
This function is called from the debug code whenever a problem
in debug_object_free is detected. Further it can be called
from the debug checks in kfree/vfree, when an active object is
detected from the debug_check_no_obj_freed() sanity checks.
</para>
<para>
Called from debug_object_free() or debug_check_no_obj_freed()
when the object state is:
<itemizedlist>
<listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
statistics.
</para>
</sect1>
</chapter>
<chapter id="bugs">
<title>Known Bugs And Assumptions</title>
<para>
None (knock on wood).
</para>
</chapter>
</book>

56
Documentation/DocBook/kernel-api.tmpl
View File

@ -119,7 +119,7 @@ X!Ilib/string.c
!Elib/string.c
</sect1>
<sect1><title>Bit Operations</title>
!Iinclude/asm-x86/bitops_32.h
!Iinclude/asm-x86/bitops.h
</sect1>
</chapter>
@ -645,4 +645,58 @@ X!Idrivers/video/console/fonts.c
!Edrivers/i2c/i2c-core.c
</chapter>
<chapter id="clk">
<title>Clock Framework</title>
<para>
The clock framework defines programming interfaces to support
software management of the system clock tree.
This framework is widely used with System-On-Chip (SOC) platforms
to support power management and various devices which may need
custom clock rates.
Note that these "clocks" don't relate to timekeeping or real
time clocks (RTCs), each of which have separate frameworks.
These <structname>struct clk</structname> instances may be used
to manage for example a 96 MHz signal that is used to shift bits
into and out of peripherals or busses, or otherwise trigger
synchronous state machine transitions in system hardware.
</para>
<para>
Power management is supported by explicit software clock gating:
unused clocks are disabled, so the system doesn't waste power
changing the state of transistors that aren't in active use.
On some systems this may be backed by hardware clock gating,
where clocks are gated without being disabled in software.
Sections of chips that are powered but not clocked may be able
to retain their last state.
This low power state is often called a <emphasis>retention
mode</emphasis>.
This mode still incurs leakage currents, especially with finer
circuit geometries, but for CMOS circuits power is mostly used
by clocked state changes.
</para>
<para>
Power-aware drivers only enable their clocks when the device
they manage is in active use. Also, system sleep states often
differ according to which clock domains are active: while a
"standby" state may allow wakeup from several active domains, a
"mem" (suspend-to-RAM) state may require a more wholesale shutdown
of clocks derived from higher speed PLLs and oscillators, limiting
the number of possible wakeup event sources. A driver's suspend
method may need to be aware of system-specific clock constraints
on the target sleep state.
</para>
<para>
Some platforms support programmable clock generators. These
can be used by external chips of various kinds, such as other
CPUs, multimedia codecs, and devices with strict requirements
for interface clocking.
</para>
!Iinclude/linux/clk.h
</chapter>
</book>

8
Documentation/DocBook/kgdb.tmpl
View File

@ -72,7 +72,7 @@
kgdb is a source level debugger for linux kernel. It is used along
with gdb to debug a linux kernel. The expectation is that gdb can
be used to "break in" to the kernel to inspect memory, variables
and look through a cal stack information similar to what an
and look through call stack information similar to what an
application developer would use gdb for. It is possible to place
breakpoints in kernel code and perform some limited execution
stepping.
@ -93,8 +93,10 @@
<chapter id="CompilingAKernel">
<title>Compiling a kernel</title>
<para>
To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging"
and then select "KGDB: kernel debugging with remote gdb".
To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
"Prompt for development and/or incomplete code/drivers"
(CONFIG_EXPERIMENTAL) in "General setup", then under the
"Kernel debugging" select "KGDB: kernel debugging with remote gdb".
</para>
<para>
Next you should choose one of more I/O drivers to interconnect debugging

1
Documentation/DocBook/rapidio.tmpl
View File

@ -133,7 +133,6 @@
!Idrivers/rapidio/rio-sysfs.c
</sect1>
<sect1 id="PPC32_support"><title>PPC32 support</title>
!Iarch/powerpc/kernel/rio.c
!Earch/powerpc/sysdev/fsl_rio.c
!Iarch/powerpc/sysdev/fsl_rio.c
</sect1>

30
Documentation/HOWTO
View File

@ -249,9 +249,11 @@ process is as follows:
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- A list of known regressions present in each -rc release is
tracked at the following URI:
http://kernelnewbies.org/known_regressions
- 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:
@ -261,7 +263,7 @@ mailing list about kernel releases:
2.6.x.y -stable kernel tree
---------------------------
Kernels with 4 digit versions are -stable kernels. They contain
Kernels with 4-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 2.6.x kernel.
@ -273,7 +275,10 @@ If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
kernel is the current stable kernel.
2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
released almost every other week.
released as needs dictate. The normal release period is approximately
two weeks, but it can be longer if there are no pressing problems. A
security-related problem, instead, can cause a release to happen almost
instantly.
The file Documentation/stable_kernel_rules.txt in the kernel tree
documents what kinds of changes are acceptable for the -stable tree, and
@ -298,7 +303,9 @@ a while Andrew or the subsystem maintainer pushes it on to Linus for
inclusion in mainline.
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.
before they are sent to Linus for inclusion in the main kernel tree. Code
which does not make an appearance in -mm before the opening of the merge
window will prove hard to merge into the mainline.
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
@ -354,11 +361,12 @@ Here is a list of some of the different kernel trees available:
- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
- x86, Ingo Molnar <mingo@elte.hu>
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
- USB, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64, partly i386, Andi Kleen <ak@suse.de>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
Other kernel trees can be found listed at http://git.kernel.org/ and in
the MAINTAINERS file.
@ -392,8 +400,8 @@ If you want to be advised of the future bug reports, you can subscribe to the
bugme-new mailing list (only new bug reports are mailed here) or to the
bugme-janitor mailing list (every change in the bugzilla is mailed here)
http://lists.osdl.org/mailman/listinfo/bugme-new
http://lists.osdl.org/mailman/listinfo/bugme-janitors
http://lists.linux-foundation.org/mailman/listinfo/bugme-new
http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors

30
Documentation/arm/Samsung-S3C24XX/NAND.txt Normal file
View File

@ -0,0 +1,30 @@
S3C24XX NAND Support
====================
Introduction
------------
Small Page NAND
---------------
The driver uses a 512 byte (1 page) ECC code for this setup. The
ECC code is not directly compatible with the default kernel ECC
code, so the driver enforces its own OOB layout and ECC parameters
Large Page NAND
---------------
The driver is capable of handling NAND flash with a 2KiB page
size, with support for hardware ECC generation and correction.
Unlike the 512byte page mode, the driver generates ECC data for
each 256 byte block in an 2KiB page. This means that more than
one error in a page can be rectified. It also means that the
OOB layout remains the default kernel layout for these flashes.
Document Author
---------------
Ben Dooks, Copyright 2007 Simtec Electronics

2
Documentation/arm/Samsung-S3C24XX/Overview.txt
View File

@ -156,6 +156,8 @@ NAND
controller. If there are any problems the latest linux-mtd
code can be found from http://www.linux-mtd.infradead.org/
For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
Serial
------

34
Documentation/braille-console.txt Normal file
View File

@ -0,0 +1,34 @@
Linux Braille Console
To get early boot messages on a braille device (before userspace screen
readers can start), you first need to compile the support for the usual serial
console (see serial-console.txt), and for braille device (in Device Drivers -
Accessibility).
Then you need to specify a console=brl, option on the kernel command line, the
format is:
console=brl,serial_options...
where serial_options... are the same as described in serial-console.txt
So for instance you can use console=brl,ttyS0 if the braille device is connected
to the first serial port, and console=brl,ttyS0,115200 to override the baud rate
to 115200, etc.
By default, the braille device will just show the last kernel message (console
mode). To review previous messages, press the Insert key to switch to the VT
review mode. In review mode, the arrow keys permit to browse in the VT content,
page up/down keys go at the top/bottom of the screen, and the home key goes back
to the cursor, hence providing very basic screen reviewing facility.
Sound feedback can be obtained by adding the braille_console.sound=1 kernel
parameter.
For simplicity, only one braille console can be enabled, other uses of
console=brl,... will be discarded. Also note that it does not interfere with
the console selection mecanism described in serial-console.txt
For now, only the VisioBraille device is supported.
Samuel Thibault <samuel.thibault@ens-lyon.org>

3
Documentation/cgroups.txt
View File

@ -500,8 +500,7 @@ post-attachment activity that requires memory allocations or blocking.
void fork(struct cgroup_subsy *ss, struct task_struct *task)
Called when a task is forked into a cgroup. Also called during
registration for all existing tasks.
Called when a task is forked into a cgroup.
void exit(struct cgroup_subsys *ss, struct task_struct *task)

48
Documentation/controllers/devices.txt Normal file
View File

@ -0,0 +1,48 @@
Device Whitelist Controller
1. Description:
Implement a cgroup to track and enforce open and mknod restrictions
on device files. A device cgroup associates a device access
whitelist with each cgroup. A whitelist entry has 4 fields.
'type' is a (all), c (char), or b (block). 'all' means it applies
to all types and all major and minor numbers. Major and minor are
either an integer or * for all. Access is a composition of r
(read), w (write), and m (mknod).
The root device cgroup starts with rwm to 'all'. A child device
cgroup gets a copy of the parent. Administrators can then remove
devices from the whitelist or add new entries. A child cgroup can
never receive a device access which is denied its parent. However
when a device access is removed from a parent it will not also be
removed from the child(ren).
2. User Interface
An entry is added using devices.allow, and removed using
devices.deny. For instance
echo 'c 1:3 mr' > /cgroups/1/devices.allow
allows cgroup 1 to read and mknod the device usually known as
/dev/null. Doing
echo a > /cgroups/1/devices.deny
will remove the default 'a *:* mrw' entry.
3. Security
Any task can move itself between cgroups. This clearly won't
suffice, but we can decide the best way to adequately restrict
movement as people get some experience with this. We may just want
to require CAP_SYS_ADMIN, which at least is a separate bit from
CAP_MKNOD. We may want to just refuse moving to a cgroup which
isn't a descendent of the current one. Or we may want to use
CAP_MAC_ADMIN, since we really are trying to lock down root.
CAP_SYS_ADMIN is needed to modify the whitelist or move another
task to a new cgroup. (Again we'll probably want to change that).
A cgroup may not be granted more permissions than the cgroup's
parent has.

181
Documentation/controllers/resource_counter.txt Normal file
View File

@ -0,0 +1,181 @@
The Resource Counter
The resource counter, declared at include/linux/res_counter.h,
is supposed to facilitate the resource management by controllers
by providing common stuff for accounting.
This "stuff" includes the res_counter structure and routines
to work with it.
1. Crucial parts of the res_counter structure
a. unsigned long long usage
The usage value shows the amount of a resource that is consumed
by a group at a given time. The units of measurement should be
determined by the controller that uses this counter. E.g. it can
be bytes, items or any other unit the controller operates on.
b. unsigned long long max_usage
The maximal value of the usage over time.
This value is useful when gathering statistical information about
the particular group, as it shows the actual resource requirements
for a particular group, not just some usage snapshot.
c. unsigned long long limit
The maximal allowed amount of resource to consume by the group. In
case the group requests for more resources, so that the usage value
would exceed the limit, the resource allocation is rejected (see
the next section).
d. unsigned long long failcnt
The failcnt stands for "failures counter". This is the number of
resource allocation attempts that failed.
c. spinlock_t lock
Protects changes of the above values.
2. Basic accounting routines
a. void res_counter_init(struct res_counter *rc)
Initializes the resource counter. As usual, should be the first
routine called for a new counter.
b. int res_counter_charge[_locked]
(struct res_counter *rc, unsigned long val)
When a resource is about to be allocated it has to be accounted
with the appropriate resource counter (controller should determine
which one to use on its own). This operation is called "charging".
This is not very important which operation - resource allocation
or charging - is performed first, but
* if the allocation is performed first, this may create a
temporary resource over-usage by the time resource counter is
charged;
* if the charging is performed first, then it should be uncharged
on error path (if the one is called).
c. void res_counter_uncharge[_locked]
(struct res_counter *rc, unsigned long val)
When a resource is released (freed) it should be de-accounted
from the resource counter it was accounted to. This is called
"uncharging".
The _locked routines imply that the res_counter->lock is taken.
2.1 Other accounting routines
There are more routines that may help you with common needs, like
checking whether the limit is reached or resetting the max_usage
value. They are all declared in include/linux/res_counter.h.
3. Analyzing the resource counter registrations
a. If the failcnt value constantly grows, this means that the counter's
limit is too tight. Either the group is misbehaving and consumes too
many resources, or the configuration is not suitable for the group
and the limit should be increased.
b. The max_usage value can be used to quickly tune the group. One may
set the limits to maximal values and either load the container with
a common pattern or leave one for a while. After this the max_usage
value shows the amount of memory the container would require during
its common activity.
Setting the limit a bit above this value gives a pretty good
configuration that works in most of the cases.
c. If the max_usage is much less than the limit, but the failcnt value
is growing, then the group tries to allocate a big chunk of resource
at once.
d. If the max_usage is much less than the limit, but the failcnt value
is 0, then this group is given too high limit, that it does not
require. It is better to lower the limit a bit leaving more resource
for other groups.
4. Communication with the control groups subsystem (cgroups)
All the resource controllers that are using cgroups and resource counters
should provide files (in the cgroup filesystem) to work with the resource
counter fields. They are recommended to adhere to the following rules:
a. File names
Field name File name
---------------------------------------------------
usage usage_in_<unit_of_measurement>
max_usage max_usage_in_<unit_of_measurement>
limit limit_in_<unit_of_measurement>
failcnt failcnt
lock no file :)
b. Reading from file should show the corresponding field value in the
appropriate format.
c. Writing to file
Field Expected behavior
----------------------------------
usage prohibited
max_usage reset to usage
limit set the limit
failcnt reset to zero
5. Usage example
a. Declare a task group (take a look at cgroups subsystem for this) and
fold a res_counter into it
struct my_group {
struct res_counter res;
<other fields>
}
b. Put hooks in resource allocation/release paths
int alloc_something(...)
{
if (res_counter_charge(res_counter_ptr, amount) < 0)
return -ENOMEM;
<allocate the resource and return to the caller>
}
void release_something(...)
{
res_counter_uncharge(res_counter_ptr, amount);
<release the resource>
}
In order to keep the usage value self-consistent, both the
"res_counter_ptr" and the "amount" in release_something() should be
the same as they were in the alloc_something() when the releasing
resource was allocated.
c. Provide the way to read res_counter values and set them (the cgroups
still can help with it).
c. Compile and run :)

14
Documentation/cpu-freq/user-guide.txt
View File

@ -154,6 +154,11 @@ scaling_governor, and by "echoing" the name of another
that some governors won't load - they only
work on some specific architectures or
processors.
cpuinfo_cur_freq : Current speed of the CPU, in KHz.
scaling_available_frequencies : List of available frequencies, in KHz.
scaling_min_freq and
scaling_max_freq show the current "policy limits" (in
kHz). By echoing new values into these
@ -162,6 +167,15 @@ scaling_max_freq show the current "policy limits" (in
first set scaling_max_freq, then
scaling_min_freq.
affected_cpus : List of CPUs that require software coordination
of frequency.
related_cpus : List of CPUs that need some sort of frequency
coordination, whether software or hardware.
scaling_driver : Hardware driver for cpufreq.
scaling_cur_freq : Current frequency of the CPU, in KHz.
If you have selected the "userspace" governor which allows you to
set the CPU operating frequency to a specific value, you can read out

26
Documentation/cpusets.txt
View File

@ -171,6 +171,7 @@ files describing that cpuset:
- memory_migrate flag: if set, move pages to cpusets nodes
- cpu_exclusive flag: is cpu placement exclusive?
- mem_exclusive flag: is memory placement exclusive?
- mem_hardwall flag: is memory allocation hardwalled
- memory_pressure: measure of how much paging pressure in cpuset
In addition, the root cpuset only has the following file:
@ -222,17 +223,18 @@ If a cpuset is cpu or mem exclusive, no other cpuset, other than
a direct ancestor or descendent, may share any of the same CPUs or
Memory Nodes.
A cpuset that is mem_exclusive restricts kernel allocations for
page, buffer and other data commonly shared by the kernel across
multiple users. All cpusets, whether mem_exclusive or not, restrict
allocations of memory for user space. This enables configuring a
system so that several independent jobs can share common kernel data,
such as file system pages, while isolating each jobs user allocation in
its own cpuset. To do this, construct a large mem_exclusive cpuset to
hold all the jobs, and construct child, non-mem_exclusive cpusets for
each individual job. Only a small amount of typical kernel memory,
such as requests from interrupt handlers, is allowed to be taken
outside even a mem_exclusive cpuset.
A cpuset that is mem_exclusive *or* mem_hardwall is "hardwalled",
i.e. it restricts kernel allocations for page, buffer and other data
commonly shared by the kernel across multiple users. All cpusets,
whether hardwalled or not, restrict allocations of memory for user
space. This enables configuring a system so that several independent
jobs can share common kernel data, such as file system pages, while
isolating each job's user allocation in its own cpuset. To do this,
construct a large mem_exclusive cpuset to hold all the jobs, and
construct child, non-mem_exclusive cpusets for each individual job.
Only a small amount of typical kernel memory, such as requests from
interrupt handlers, is allowed to be taken outside even a
mem_exclusive cpuset.
1.5 What is memory_pressure ?
@ -707,7 +709,7 @@ Now you want to do something with this cpuset.
In this directory you can find several files:
# ls
cpus cpu_exclusive mems mem_exclusive tasks
cpus cpu_exclusive mems mem_exclusive mem_hardwall tasks
Reading them will give you information about the state of this cpuset:
the CPUs and Memory Nodes it can use, the processes that are using

52
Documentation/device-mapper/dm-crypt.txt Normal file
View File

@ -0,0 +1,52 @@
dm-crypt
=========
Device-Mapper's "crypt" target provides transparent encryption of block devices
using the kernel crypto API.
Parameters: <cipher> <key> <iv_offset> <device path> <offset>
<cipher>
Encryption cipher and an optional IV generation mode.
(In format cipher-chainmode-ivopts:ivmode).
Examples:
des
aes-cbc-essiv:sha256
twofish-ecb
/proc/crypto contains supported crypto modes
<key>
Key used for encryption. It is encoded as a hexadecimal number.
You can only use key sizes that are valid for the selected cipher.
<iv_offset>
The IV offset is a sector count that is added to the sector number
before creating the IV.
<device path>
This is the device that is going to be used as backend and contains the
encrypted data. You can specify it as a path like /dev/xxx or a device
number <major>:<minor>.
<offset>
Starting sector within the device where the encrypted data begins.
Example scripts
===============
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
encryption with dm-crypt using the 'cryptsetup' utility, see
http://luks.endorphin.org/
[[
#!/bin/sh
# Create a crypt device using dmsetup
dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
]]
[[
#!/bin/sh
# Create a crypt device using cryptsetup and LUKS header with default cipher
cryptsetup luksFormat $1
cryptsetup luksOpen $1 crypt1
]]

2
Documentation/dontdiff
View File

@ -141,6 +141,7 @@ mkprep
mktables
mktree
modpost
modules.order
modversions.h*
offset.h
offsets.h
@ -171,6 +172,7 @@ sm_tbl*
split-include
tags
tftpboot.img
timeconst.h
times.h*
tkparse
trix_boot.h

52
Documentation/fb/gxfb.txt Normal file
View File

@ -0,0 +1,52 @@
[This file is cloned from VesaFB/aty128fb]
What is gxfb?
=================
This is a graphics framebuffer driver for AMD Geode GX2 based processors.
Advantages:
* No need to use AMD's VSA code (or other VESA emulation layer) in the
BIOS.
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF68_FBDev on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode...
How to use it?
==============
Switching modes is done using gxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
See Documentation/fb/modedb.txt for more information on modedb
resolutions.
X11
===
XF68_FBDev should generally work fine, but it is non-accelerated.
Configuration
=============
You can pass kernel command line options to gxfb with gxfb.<option>.
For example, gxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
--
Andres Salomon <dilinger@debian.org>

2
Documentation/fb/intelfb.txt
View File

@ -14,6 +14,8 @@ graphics devices. These would include:
Intel 915GM
Intel 945G
Intel 945GM
Intel 965G
Intel 965GM
B. List of available options

52
Documentation/fb/lxfb.txt Normal file
View File

@ -0,0 +1,52 @@
[This file is cloned from VesaFB/aty128fb]
What is lxfb?
=================
This is a graphics framebuffer driver for AMD Geode LX based processors.
Advantages:
* No need to use AMD's VSA code (or other VESA emulation layer) in the
BIOS.
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF68_FBDev on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode...
How to use it?
==============
Switching modes is done using lxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
See Documentation/fb/modedb.txt for more information on modedb
resolutions.
X11
===
XF68_FBDev should generally work fine, but it is non-accelerated.
Configuration
=============
You can pass kernel command line options to lxfb with lxfb.<option>.
For example, lxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
--
Andres Salomon <dilinger@debian.org>

16
Documentation/fb/metronomefb.txt
View File

@ -1,7 +1,7 @@
Metronomefb
-----------
Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
Last revised: Nov 20, 2007
Last revised: Mar 10, 2008
Metronomefb is a driver for the Metronome display controller. The controller
is from E-Ink Corporation. It is intended to be used to drive the E-Ink
@ -11,20 +11,18 @@ display media here http://www.e-ink.com/products/matrix/metronome.html .
Metronome is interfaced to the host CPU through the AMLCD interface. The
host CPU generates the control information and the image in a framebuffer
which is then delivered to the AMLCD interface by a host specific method.
Currently, that's implemented for the PXA's LCDC controller. The display and
error status are each pulled through individual GPIOs.
The display and error status are each pulled through individual GPIOs.
Metronomefb was written for the PXA255/gumstix/lyre combination and
therefore currently has board set specific code in it. If other boards based on
other architectures are available, then the host specific code can be separated
and abstracted out.
Metronomefb is platform independent and depends on a board specific driver
to do all physical IO work. Currently, an example is implemented for the
PXA board used in the AM-200 EPD devkit. This example is am200epd.c
Metronomefb requires waveform information which is delivered via the AMLCD
interface to the metronome controller. The waveform information is expected to
be delivered from userspace via the firmware class interface. The waveform file
can be compressed as long as your udev or hotplug script is aware of the need
to uncompress it before delivering it. metronomefb will ask for waveform.wbf
which would typically go into /lib/firmware/waveform.wbf depending on your
to uncompress it before delivering it. metronomefb will ask for metronome.wbf
which would typically go into /lib/firmware/metronome.wbf depending on your
udev/hotplug setup. I have only tested with a single waveform file which was
originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for.
Caution should be exercised when manipulating the waveform as there may be

4
Documentation/fb/modedb.txt
View File

@ -125,8 +125,12 @@ There may be more modes.
amifb - Amiga chipset frame buffer
aty128fb - ATI Rage128 / Pro frame buffer
atyfb - ATI Mach64 frame buffer
pm2fb - Permedia 2/2V frame buffer
pm3fb - Permedia 3 frame buffer
sstfb - Voodoo 1/2 (SST1) chipset frame buffer
tdfxfb - 3D Fx frame buffer
tridentfb - Trident (Cyber)blade chipset frame buffer
vt8623fb - VIA 8623 frame buffer
BTW, only a few drivers use this at the moment. Others are to follow
(feel free to send patches).

27
Documentation/feature-removal-schedule.txt
View File

@ -128,15 +128,6 @@ Who: Arjan van de Ven <arjan@linux.intel.com>
---------------------------
What: vm_ops.nopage
When: Soon, provided in-kernel callers have been converted
Why: This interface is replaced by vm_ops.fault, but it has been around
forever, is used by a lot of drivers, and doesn't cost much to
maintain.
Who: Nick Piggin <npiggin@suse.de>
---------------------------
What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
When: October 2008
Why: The stacking of class devices makes these values misleading and
@ -147,6 +138,24 @@ Who: Kay Sievers <kay.sievers@suse.de>
---------------------------
What: find_task_by_pid
When: 2.6.26
Why: With pid namespaces, calling this funciton will return the
wrong task when called from inside a namespace.
The best way to save a task pid and find a task by this
pid later, is to find this task's struct pid pointer (or get
it directly from the task) and call pid_task() later.
If someone really needs to get a task by its pid_t, then
he most likely needs the find_task_by_vpid() to get the
task from the same namespace as the current task is in, but
this may be not so in general.
Who: Pavel Emelyanov <xemul@openvz.org>
---------------------------
What: ACPI procfs interface
When: July 2008
Why: ACPI sysfs conversion should be finished by January 2008.

3
Documentation/filesystems/Locking
View File

@ -511,7 +511,6 @@ prototypes:
void (*open)(struct vm_area_struct*);
void (*close)(struct vm_area_struct*);
int (*fault)(struct vm_area_struct*, struct vm_fault *);
struct page *(*nopage)(struct vm_area_struct*, unsigned long, int *);
int (*page_mkwrite)(struct vm_area_struct *, struct page *);
locking rules:
@ -519,7 +518,6 @@ locking rules:
open: no yes
close: no yes
fault: no yes
nopage: no yes
page_mkwrite: no yes no
->page_mkwrite() is called when a previously read-only page is
@ -537,4 +535,3 @@ NULL.
ipc/shm.c::shm_delete() - may need BKL.
->read() and ->write() in many drivers are (probably) missing BKL.
drivers/sgi/char/graphics.c::sgi_graphics_nopage() - may need BKL.

256
Documentation/filesystems/nfs-rdma.txt Normal file
View File

@ -0,0 +1,256 @@
################################################################################
# #
# NFS/RDMA README #
# #
################################################################################
Author: NetApp and Open Grid Computing
Date: April 15, 2008
Table of Contents
~~~~~~~~~~~~~~~~~
- Overview
- Getting Help
- Installation
- Check RDMA and NFS Setup
- NFS/RDMA Setup
Overview
~~~~~~~~
This document describes how to install and setup the Linux NFS/RDMA client
and server software.
The NFS/RDMA client was first included in Linux 2.6.24. The NFS/RDMA server
was first included in the following release, Linux 2.6.25.
In our testing, we have obtained excellent performance results (full 10Gbit
wire bandwidth at minimal client CPU) under many workloads. The code passes
the full Connectathon test suite and operates over both Infiniband and iWARP
RDMA adapters.
Getting Help
~~~~~~~~~~~~
If you get stuck, you can ask questions on the
nfs-rdma-devel@lists.sourceforge.net
mailing list.
Installation
~~~~~~~~~~~~
These instructions are a step by step guide to building a machine for
use with NFS/RDMA.
- Install an RDMA device
Any device supported by the drivers in drivers/infiniband/hw is acceptable.
Testing has been performed using several Mellanox-based IB cards, the
Ammasso AMS1100 iWARP adapter, and the Chelsio cxgb3 iWARP adapter.
- Install a Linux distribution and tools
The first kernel release to contain both the NFS/RDMA client and server was
Linux 2.6.25 Therefore, a distribution compatible with this and subsequent
Linux kernel release should be installed.
The procedures described in this document have been tested with
distributions from Red Hat's Fedora Project (http://fedora.redhat.com/).
- Install nfs-utils-1.1.1 or greater on the client
An NFS/RDMA mount point can only be obtained by using the mount.nfs
command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs
you are using, type:
> /sbin/mount.nfs -V
If the version is less than 1.1.1 or the command does not exist,
then you will need to install the latest version of nfs-utils.
Download the latest package from:
http://www.kernel.org/pub/linux/utils/nfs
Uncompress the package and follow the installation instructions.
If you will not be using GSS and NFSv4, the installation process
can be simplified by disabling these features when running configure:
> ./configure --disable-gss --disable-nfsv4
For more information on this see the package's README and INSTALL files.
After building the nfs-utils package, there will be a mount.nfs binary in
the utils/mount directory. This binary can be used to initiate NFS v2, v3,
or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4.
The standard technique is to create a symlink called mount.nfs4 to mount.nfs.
NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed
on the NFS client machine. You do not need this specific version of
nfs-utils on the server. Furthermore, only the mount.nfs command from
nfs-utils-1.1.1 is needed on the client.
- Install a Linux kernel with NFS/RDMA
The NFS/RDMA client and server are both included in the mainline Linux
kernel version 2.6.25 and later. This and other versions of the 2.6 Linux
kernel can be found at:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
Download the sources and place them in an appropriate location.
- Configure the RDMA stack
Make sure your kernel configuration has RDMA support enabled. Under
Device Drivers -> InfiniBand support, update the kernel configuration
to enable InfiniBand support [NOTE: the option name is misleading. Enabling
InfiniBand support is required for all RDMA devices (IB, iWARP, etc.)].
Enable the appropriate IB HCA support (mlx4, mthca, ehca, ipath, etc.) or
iWARP adapter support (amso, cxgb3, etc.).
If you are using InfiniBand, be sure to enable IP-over-InfiniBand support.
- Configure the NFS client and server
Your kernel configuration must also have NFS file system support and/or
NFS server support enabled. These and other NFS related configuration
options can be found under File Systems -> Network File Systems.
- Build, install, reboot
The NFS/RDMA code will be enabled automatically if NFS and RDMA
are turned on. The NFS/RDMA client and server are configured via the hidden
SUNRPC_XPRT_RDMA config option that depends on SUNRPC and INFINIBAND. The
value of SUNRPC_XPRT_RDMA will be:
- N if either SUNRPC or INFINIBAND are N, in this case the NFS/RDMA client
and server will not be built
- M if both SUNRPC and INFINIBAND are on (M or Y) and at least one is M,
in this case the NFS/RDMA client and server will be built as modules
- Y if both SUNRPC and INFINIBAND are Y, in this case the NFS/RDMA client
and server will be built into the kernel
Therefore, if you have followed the steps above and turned no NFS and RDMA,
the NFS/RDMA client and server will be built.
Build a new kernel, install it, boot it.
Check RDMA and NFS Setup
~~~~~~~~~~~~~~~~~~~~~~~~
Before configuring the NFS/RDMA software, it is a good idea to test
your new kernel to ensure that the kernel is working correctly.
In particular, it is a good idea to verify that the RDMA stack
is functioning as expected and standard NFS over TCP/IP and/or UDP/IP
is working properly.
- Check RDMA Setup
If you built the RDMA components as modules, load them at
this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel
card:
> modprobe ib_mthca
> modprobe ib_ipoib
If you are using InfiniBand, make sure there is a Subnet Manager (SM)
running on the network. If your IB switch has an embedded SM, you can
use it. Otherwise, you will need to run an SM, such as OpenSM, on one
of your end nodes.
If an SM is running on your network, you should see the following:
> cat /sys/class/infiniband/driverX/ports/1/state
4: ACTIVE
where driverX is mthca0, ipath5, ehca3, etc.
To further test the InfiniBand software stack, use IPoIB (this
assumes you have two IB hosts named host1 and host2):
host1> ifconfig ib0 a.b.c.x
host2> ifconfig ib0 a.b.c.y
host1> ping a.b.c.y
host2> ping a.b.c.x
For other device types, follow the appropriate procedures.
- Check NFS Setup
For the NFS components enabled above (client and/or server),
test their functionality over standard Ethernet using TCP/IP or UDP/IP.
NFS/RDMA Setup
~~~~~~~~~~~~~~
We recommend that you use two machines, one to act as the client and
one to act as the server.
One time configuration:
- On the server system, configure the /etc/exports file and
start the NFS/RDMA server.
Exports entries with the following formats have been tested:
/vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash)
/vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash)
The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the
cleint's iWARP address(es) for an RNIC.
NOTE: The "insecure" option must be used because the NFS/RDMA client does not
use a reserved port.
Each time a machine boots:
- Load and configure the RDMA drivers
For InfiniBand using a Mellanox adapter:
> modprobe ib_mthca
> modprobe ib_ipoib
> ifconfig ib0 a.b.c.d
NOTE: use unique addresses for the client and server
- Start the NFS server
If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
load the RDMA transport module:
> modprobe svcrdma
Regardless of how the server was built (module or built-in), start the server:
> /etc/init.d/nfs start
or
> service nfs start
Instruct the server to listen on the RDMA transport:
> echo rdma 2050 > /proc/fs/nfsd/portlist
- On the client system
If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
load the RDMA client module:
> modprobe xprtrdma.ko
Regardless of how the client was built (module or built-in), issue the mount.nfs command:
> /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050
To verify that the mount is using RDMA, run "cat /proc/mounts" and check the
"proto" field for the given mount.
Congratulations! You're using NFS/RDMA!

59
Documentation/filesystems/proc.txt
View File

@ -43,6 +43,7 @@ Table of Contents
2.13 /proc/<pid>/oom_score - Display current oom-killer score
2.14 /proc/<pid>/io - Display the IO accounting fields
2.15 /proc/<pid>/coredump_filter - Core dump filtering settings
2.16 /proc/<pid>/mountinfo - Information about mounts
------------------------------------------------------------------------------
Preface
@ -462,11 +463,17 @@ SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 968 kB
Writeback: 0 kB
AnonPages: 861800 kB
Mapped: 280372 kB
Slab: 684068 kB
Slab: 284364 kB
SReclaimable: 159856 kB
SUnreclaim: 124508 kB
PageTables: 24448 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 7669796 kB
Committed_AS: 100056 kB
PageTables: 24448 kB
VmallocTotal: 112216 kB
VmallocUsed: 428 kB
VmallocChunk: 111088 kB
@ -502,8 +509,17 @@ VmallocChunk: 111088 kB
on the disk
Dirty: Memory which is waiting to get written back to the disk
Writeback: Memory which is actively being written back to the disk
AnonPages: Non-file backed pages mapped into userspace page tables
Mapped: files which have been mmaped, such as libraries
Slab: in-kernel data structures cache
SReclaimable: Part of Slab, that might be reclaimed, such as caches
SUnreclaim: Part of Slab, that cannot be reclaimed on memory pressure
PageTables: amount of memory dedicated to the lowest level of page
tables.
NFS_Unstable: NFS pages sent to the server, but not yet committed to stable
storage
Bounce: Memory used for block device "bounce buffers"
WritebackTmp: Memory used by FUSE for temporary writeback buffers
CommitLimit: Based on the overcommit ratio ('vm.overcommit_ratio'),
this is the total amount of memory currently available to
be allocated on the system. This limit is only adhered to
@ -530,8 +546,6 @@ Committed_AS: The amount of memory presently allocated on the system.
above) will not be permitted. This is useful if one needs
to guarantee that processes will not fail due to lack of
memory once that memory has been successfully allocated.
PageTables: amount of memory dedicated to the lowest level of page
tables.
VmallocTotal: total size of vmalloc memory area
VmallocUsed: amount of vmalloc area which is used
VmallocChunk: largest contigious block of vmalloc area which is free
@ -2348,4 +2362,41 @@ For example:
$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program
2.16 /proc/<pid>/mountinfo - Information about mounts
--------------------------------------------------------
This file contains lines of the form:
36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
(1) mount ID: unique identifier of the mount (may be reused after umount)
(2) parent ID: ID of parent (or of self for the top of the mount tree)
(3) major:minor: value of st_dev for files on filesystem
(4) root: root of the mount within the filesystem
(5) mount point: mount point relative to the process's root
(6) mount options: per mount options
(7) optional fields: zero or more fields of the form "tag[:value]"
(8) separator: marks the end of the optional fields
(9) filesystem type: name of filesystem of the form "type[.subtype]"
(10) mount source: filesystem specific information or "none"
(11) super options: per super block options
Parsers should ignore all unrecognised optional fields. Currently the
possible optional fields are:
shared:X mount is shared in peer group X
master:X mount is slave to peer group X
propagate_from:X mount is slave and receives propagation from peer group X (*)
unbindable mount is unbindable
(*) X is the closest dominant peer group under the process's root. If
X is the immediate master of the mount, or if there's no dominant peer
group under the same root, then only the "master:X" field is present
and not the "propagate_from:X" field.
For more information on mount propagation see:
Documentation/filesystems/sharedsubtree.txt
------------------------------------------------------------------------------

19
Documentation/filesystems/seq_file.txt
View File

@ -122,8 +122,7 @@ stop() is the place to free it.
}
Finally, the show() function should format the object currently pointed to
by the iterator for output. It should return zero, or an error code if
something goes wrong. The example module's show() function is:
by the iterator for output. The example module's show() function is:
static int ct_seq_show(struct seq_file *s, void *v)
{
@ -132,6 +131,12 @@ something goes wrong. The example module's show() function is:
return 0;
}
If all is well, the show() function should return zero. A negative error
code in the usual manner indicates that something went wrong; it will be
passed back to user space. This function can also return SEQ_SKIP, which
causes the current item to be skipped; if the show() function has already
generated output before returning SEQ_SKIP, that output will be dropped.
We will look at seq_printf() in a moment. But first, the definition of the
seq_file iterator is finished by creating a seq_operations structure with
the four functions we have just defined:
@ -182,12 +187,18 @@ The first two output a single character and a string, just like one would
expect. seq_escape() is like seq_puts(), except that any character in s
which is in the string esc will be represented in octal form in the output.
There is also a function for printing filenames:
There is also a pair of functions for printing filenames:
int seq_path(struct seq_file *m, struct path *path, char *esc);
int seq_path_root(struct seq_file *m, struct path *path,
struct path *root, char *esc)
Here, path indicates the file of interest, and esc is a set of characters
which should be escaped in the output.
which should be escaped in the output. A call to seq_path() will output
the path relative to the current process's filesystem root. If a different
root is desired, it can be used with seq_path_root(). Note that, if it
turns out that path cannot be reached from root, the value of root will be
changed in seq_file_root() to a root which *does* work.
Making it all work

12
Documentation/filesystems/tmpfs.txt
View File

@ -92,6 +92,18 @@ NodeList format is a comma-separated list of decimal numbers and ranges,
a range being two hyphen-separated decimal numbers, the smallest and
largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15
NUMA memory allocation policies have optional flags that can be used in
conjunction with their modes. These optional flags can be specified
when tmpfs is mounted by appending them to the mode before the NodeList.
See Documentation/vm/numa_memory_policy.txt for a list of all available
memory allocation policy mode flags.
=static is equivalent to MPOL_F_STATIC_NODES
=relative is equivalent to MPOL_F_RELATIVE_NODES
For example, mpol=bind=static:NodeList, is the equivalent of an
allocation policy of MPOL_BIND | MPOL_F_STATIC_NODES.
Note that trying to mount a tmpfs with an mpol option will fail if the
running kernel does not support NUMA; and will fail if its nodelist
specifies a node which is not online. If your system relies on that

15
Documentation/filesystems/vfat.txt
View File

@ -17,6 +17,21 @@ dmask=### -- The permission mask for the directory.
fmask=### -- The permission mask for files.
The default is the umask of current process.
allow_utime=### -- This option controls the permission check of mtime/atime.
20 - If current process is in group of file's group ID,
you can change timestamp.
2 - Other users can change timestamp.
The default is set from `dmask' option. (If the directory is
writable, utime(2) is also allowed. I.e. ~dmask & 022)
Normally utime(2) checks current process is owner of
the file, or it has CAP_FOWNER capability. But FAT
filesystem doesn't have uid/gid on disk, so normal
check is too unflexible. With this option you can
relax it.
codepage=### -- Sets the codepage number for converting to shortname
characters on FAT filesystem.
By default, FAT_DEFAULT_CODEPAGE setting is used.

10
Documentation/gpio.txt
View File

@ -107,6 +107,16 @@ type of GPIO controller, and on one particular board 80-95 with an FPGA.
The numbers need not be contiguous; either of those platforms could also
use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
If you want to initialize a structure with an invalid GPIO number, use
some negative number (perhaps "-EINVAL"); that will never be valid. To
test if a number could reference a GPIO, you may use this predicate:
int gpio_is_valid(int number);
A number that's not valid will be rejected by calls which may request
or free GPIOs (see below). Other numbers may also be rejected; for
example, a number might be valid but unused on a given board.
Whether a platform supports multiple GPIO controllers is currently a
platform-specific implementation issue.

3
Documentation/hwmon/w83l785ts
View File

@ -33,7 +33,8 @@ Known Issues
------------
On some systems (Asus), the BIOS is known to interfere with the driver
and cause read errors. The driver will retry a given number of times
and cause read errors. Or maybe the W83L785TS-S chip is simply unreliable,
we don't really know. The driver will retry a given number of times
(5 by default) and then give up, returning the old value (or 0 if
there is no old value). It seems to work well enough so that you should
not notice anything. Thanks to James Bolt for helping test this feature.

3
Documentation/i2c/writing-clients
View File

@ -164,7 +164,8 @@ I2C device drivers using this binding model work just like any other
kind of driver in Linux: they provide a probe() method to bind to
those devices, and a remove() method to unbind.
static int foo_probe(struct i2c_client *client);
static int foo_probe(struct i2c_client *client,
const struct i2c_device_id *id);
static int foo_remove(struct i2c_client *client);
Remember that the i2c_driver does not create those client handles. The

36
Documentation/i386/boot.txt
View File

@ -40,8 +40,18 @@ Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable.
Introduce relocatable_kernel and kernel_alignment fields.
Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
the boot command line
the boot command line.
Protocol 2.07: (Kernel 2.6.24) Added paravirtualised boot protocol.
Introduced hardware_subarch and hardware_subarch_data
and KEEP_SEGMENTS flag in load_flags.
Protocol 2.08: (Kernel 2.6.26) Added crc32 checksum and ELF format
payload. Introduced payload_offset and payload length
fields to aid in locating the payload.
Protocol 2.09: (Kernel 2.6.26) Added a field of 64-bit physical
pointer to single linked list of struct setup_data.
**** MEMORY LAYOUT
@ -172,6 +182,8 @@ Offset Proto Name Meaning
0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
0248/4 2.08+ payload_offset Offset of kernel payload
024C/4 2.08+ payload_length Length of kernel payload
0250/8 2.09+ setup_data 64-bit physical pointer to linked list
of struct setup_data
(1) For backwards compatibility, if the setup_sects field contains 0, the
real value is 4.
@ -572,6 +584,28 @@ command line is entered using the following protocol:
covered by setup_move_size, so you may need to adjust this
field.
Field name: setup_data
Type: write (obligatory)
Offset/size: 0x250/8
Protocol: 2.09+
The 64-bit physical pointer to NULL terminated single linked list of
struct setup_data. This is used to define a more extensible boot
parameters passing mechanism. The definition of struct setup_data is
as follow:
struct setup_data {
u64 next;
u32 type;
u32 len;
u8 data[0];
};
Where, the next is a 64-bit physical pointer to the next node of
linked list, the next field of the last node is 0; the type is used
to identify the contents of data; the len is the length of data
field; the data holds the real payload.
**** MEMORY LAYOUT OF THE REAL-MODE CODE

82
Documentation/ia64/kvm.txt Normal file
View File

@ -0,0 +1,82 @@
Currently, kvm module in EXPERIMENTAL stage on IA64. This means that
interfaces are not stable enough to use. So, plase had better don't run
critical applications in virtual machine. We will try our best to make it
strong in future versions!
Guide: How to boot up guests on kvm/ia64
This guide is to describe how to enable kvm support for IA-64 systems.
1. Get the kvm source from git.kernel.org.
Userspace source:
git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git
Kernel Source:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git
2. Compile the source code.
2.1 Compile userspace code:
(1)cd ./kvm-userspace
(2)./configure
(3)cd kernel
(4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.)
(5)cd ..
(6)make qemu
(7)cd qemu; make install
2.2 Compile kernel source code:
(1) cd ./$kernel_dir
(2) Make menuconfig
(3) Enter into virtualization option, and choose kvm.
(4) make
(5) Once (4) done, make modules_install
(6) Make initrd, and use new kernel to reboot up host machine.
(7) Once (6) done, cd $kernel_dir/arch/ia64/kvm
(8) insmod kvm.ko; insmod kvm-intel.ko
Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail.
3. Get Guest Firmware named as Flash.fd, and put it under right place:
(1) If you have the guest firmware (binary) released by Intel Corp for Xen, use it directly.
(2) If you have no firmware at hand, Please download its source from
hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg
you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries.
(3) Rename the firware you owned to Flash.fd, and copy it to /usr/local/share/qemu
4. Boot up Linux or Windows guests:
4.1 Create or install a image for guest boot. If you have xen experience, it should be easy.
4.2 Boot up guests use the following command.
/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
(xx is the number of virtual processors for the guest, now the maximum value is 4)
5. Known possibile issue on some platforms with old Firmware.
If meet strange host crashe issues, try to solve it through either of the following ways:
(1): Upgrade your Firmware to the latest one.
(2): Applying the below patch to kernel source.
diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S
index 0b53344..f02b0f7 100644
--- a/arch/ia64/kernel/pal.S
+++ b/arch/ia64/kernel/pal.S
@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static)
mov ar.pfs = loc1
mov rp = loc0
;;
- srlz.d // seralize restoration of psr.l
+ srlz.i // seralize restoration of psr.l
+ ;;
br.ret.sptk.many b0
END(ia64_pal_call_static)
6. Bug report:
If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list.
https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/
Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger!
Xiantao Zhang <xiantao.zhang@intel.com>
2008.3.10

211
Documentation/ide/ide-tape.txt
View File

@ -1,146 +1,65 @@
/*
* IDE ATAPI streaming tape driver.
*
* This driver is a part of the Linux ide driver.
*
* The driver, in co-operation with ide.c, basically traverses the
* request-list for the block device interface. The character device
* interface, on the other hand, creates new requests, adds them
* to the request-list of the block device, and waits for their completion.
*
* Pipelined operation mode is now supported on both reads and writes.
*
* The block device major and minor numbers are determined from the
* tape's relative position in the ide interfaces, as explained in ide.c.
*
* The character device interface consists of the following devices:
*
* ht0 major 37, minor 0 first IDE tape, rewind on close.
* ht1 major 37, minor 1 second IDE tape, rewind on close.
* ...
* nht0 major 37, minor 128 first IDE tape, no rewind on close.
* nht1 major 37, minor 129 second IDE tape, no rewind on close.
* ...
*
* The general magnetic tape commands compatible interface, as defined by
* include/linux/mtio.h, is accessible through the character device.
*
* General ide driver configuration options, such as the interrupt-unmask
* flag, can be configured by issuing an ioctl to the block device interface,
* as any other ide device.
*
* Our own ide-tape ioctl's can be issued to either the block device or
* the character device interface.
*
* Maximal throughput with minimal bus load will usually be achieved in the
* following scenario:
*
* 1. ide-tape is operating in the pipelined operation mode.
* 2. No buffering is performed by the user backup program.
*
* Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
*
* Here are some words from the first releases of hd.c, which are quoted
* in ide.c and apply here as well:
*
* | Special care is recommended. Have Fun!
*
*
* An overview of the pipelined operation mode.
*
* In the pipelined write mode, we will usually just add requests to our
* pipeline and return immediately, before we even start to service them. The
* user program will then have enough time to prepare the next request while
* we are still busy servicing previous requests. In the pipelined read mode,
* the situation is similar - we add read-ahead requests into the pipeline,
* before the user even requested them.
*
* The pipeline can be viewed as a "safety net" which will be activated when
* the system load is high and prevents the user backup program from keeping up
* with the current tape speed. At this point, the pipeline will get
* shorter and shorter but the tape will still be streaming at the same speed.
* Assuming we have enough pipeline stages, the system load will hopefully
* decrease before the pipeline is completely empty, and the backup program
* will be able to "catch up" and refill the pipeline again.
*
* When using the pipelined mode, it would be best to disable any type of
* buffering done by the user program, as ide-tape already provides all the
* benefits in the kernel, where it can be done in a more efficient way.
* As we will usually not block the user program on a request, the most
* efficient user code will then be a simple read-write-read-... cycle.
* Any additional logic will usually just slow down the backup process.
*
* Using the pipelined mode, I get a constant over 400 KBps throughput,
* which seems to be the maximum throughput supported by my tape.
*
* However, there are some downfalls:
*
* 1. We use memory (for data buffers) in proportional to the number
* of pipeline stages (each stage is about 26 KB with my tape).
* 2. In the pipelined write mode, we cheat and postpone error codes
* to the user task. In read mode, the actual tape position
* will be a bit further than the last requested block.
*
* Concerning (1):
*
* 1. We allocate stages dynamically only when we need them. When
* we don't need them, we don't consume additional memory. In
* case we can't allocate stages, we just manage without them
* (at the expense of decreased throughput) so when Linux is
* tight in memory, we will not pose additional difficulties.
*
* 2. The maximum number of stages (which is, in fact, the maximum
* amount of memory) which we allocate is limited by the compile
* time parameter IDETAPE_MAX_PIPELINE_STAGES.
*
* 3. The maximum number of stages is a controlled parameter - We
* don't start from the user defined maximum number of stages
* but from the lower IDETAPE_MIN_PIPELINE_STAGES (again, we
* will not even allocate this amount of stages if the user
* program can't handle the speed). We then implement a feedback
* loop which checks if the pipeline is empty, and if it is, we
* increase the maximum number of stages as necessary until we
* reach the optimum value which just manages to keep the tape
* busy with minimum allocated memory or until we reach
* IDETAPE_MAX_PIPELINE_STAGES.
*
* Concerning (2):
*
* In pipelined write mode, ide-tape can not return accurate error codes
* to the user program since we usually just add the request to the
* pipeline without waiting for it to be serviced. In case an error
* occurs, I will report it on the next user request.
*
* In the pipelined read mode, subsequent read requests or forward
* filemark spacing will perform correctly, as we preserve all blocks
* and filemarks which we encountered during our excess read-ahead.
*
* For accurate tape positioning and error reporting, disabling
* pipelined mode might be the best option.
*
* You can enable/disable/tune the pipelined operation mode by adjusting
* the compile time parameters below.
*
*
* Possible improvements.
*
* 1. Support for the ATAPI overlap protocol.
*
* In order to maximize bus throughput, we currently use the DSC
* overlap method which enables ide.c to service requests from the
* other device while the tape is busy executing a command. The
* DSC overlap method involves polling the tape's status register
* for the DSC bit, and servicing the other device while the tape
* isn't ready.
*
* In the current QIC development standard (December 1995),
* it is recommended that new tape drives will *in addition*
* implement the ATAPI overlap protocol, which is used for the
* same purpose - efficient use of the IDE bus, but is interrupt
* driven and thus has much less CPU overhead.
*
* ATAPI overlap is likely to be supported in most new ATAPI
* devices, including new ATAPI cdroms, and thus provides us
* a method by which we can achieve higher throughput when
* sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
*/
IDE ATAPI streaming tape driver.
This driver is a part of the Linux ide driver.
The driver, in co-operation with ide.c, basically traverses the
request-list for the block device interface. The character device
interface, on the other hand, creates new requests, adds them
to the request-list of the block device, and waits for their completion.
The block device major and minor numbers are determined from the
tape's relative position in the ide interfaces, as explained in ide.c.
The character device interface consists of the following devices:
ht0 major 37, minor 0 first IDE tape, rewind on close.
ht1 major 37, minor 1 second IDE tape, rewind on close.
...
nht0 major 37, minor 128 first IDE tape, no rewind on close.
nht1 major 37, minor 129 second IDE tape, no rewind on close.
...
The general magnetic tape commands compatible interface, as defined by
include/linux/mtio.h, is accessible through the character device.
General ide driver configuration options, such as the interrupt-unmask
flag, can be configured by issuing an ioctl to the block device interface,
as any other ide device.
Our own ide-tape ioctl's can be issued to either the block device or
the character device interface.
Maximal throughput with minimal bus load will usually be achieved in the
following scenario:
1. ide-tape is operating in the pipelined operation mode.
2. No buffering is performed by the user backup program.
Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
Here are some words from the first releases of hd.c, which are quoted
in ide.c and apply here as well:
| Special care is recommended. Have Fun!
Possible improvements:
1. Support for the ATAPI overlap protocol.
In order to maximize bus throughput, we currently use the DSC
overlap method which enables ide.c to service requests from the
other device while the tape is busy executing a command. The
DSC overlap method involves polling the tape's status register
for the DSC bit, and servicing the other device while the tape
isn't ready.
In the current QIC development standard (December 1995),
it is recommended that new tape drives will *in addition*
implement the ATAPI overlap protocol, which is used for the
same purpose - efficient use of the IDE bus, but is interrupt
driven and thus has much less CPU overhead.
ATAPI overlap is likely to be supported in most new ATAPI
devices, including new ATAPI cdroms, and thus provides us
a method by which we can achieve higher throughput when
sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.

107
Documentation/ide/ide.txt
View File

@ -82,27 +82,26 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
For really weird situations, the apparent (fdisk) geometry can also be specified
on the kernel "command line" using LILO. The format of such lines is:
hdx=cyls,heads,sects
or hdx=cdrom
ide_core.chs=[interface_number.device_number]:cyls,heads,sects
or ide_core.cdrom=[interface_number.device_number]
where hdx can be any of hda through hdh, Three values are required
(cyls,heads,sects). For example:
For example:
hdc=1050,32,64 hdd=cdrom
ide_core.chs=1.0:1050,32,64 ide_core.cdrom=1.1
either {hda,hdb} or {hdc,hdd}. The results of successful auto-probing may
override the physical geometry/irq specified, though the "original" geometry
may be retained as the "logical" geometry for partitioning purposes (fdisk).
The results of successful auto-probing may override the physical geometry/irq
specified, though the "original" geometry may be retained as the "logical"
geometry for partitioning purposes (fdisk).
If the auto-probing during boot time confuses a drive (ie. the drive works
with hd.c but not with ide.c), then an command line option may be specified
for each drive for which you'd like the drive to skip the hardware
probe/identification sequence. For example:
hdb=noprobe
ide_core.noprobe=0.1
or
hdc=768,16,32
hdc=noprobe
ide_core.chs=1.0:768,16,32
ide_core.noprobe=1.0
Note that when only one IDE device is attached to an interface, it should be
jumpered as "single" or "master", *not* "slave". Many folks have had
@ -118,9 +117,9 @@ If for some reason your cdrom drive is *not* found at boot time, you can force
the probe to look harder by supplying a kernel command line parameter
via LILO, such as:
hdc=cdrom /* hdc = "master" on second interface */
ide_core.cdrom=1.0 /* "master" on second interface (hdc) */
or
hdd=cdrom /* hdd = "slave" on second interface */
ide_core.cdrom=1.1 /* "slave" on second interface (hdd) */
For example, a GW2000 system might have a hard drive on the primary
interface (/dev/hda) and an IDE cdrom drive on the secondary interface
@ -174,9 +173,7 @@ to /etc/modprobe.conf.
When ide.c is used as a module, you can pass command line parameters to the
driver using the "options=" keyword to insmod, while replacing any ',' with
';'. For example:
insmod ide.o options="hda=nodma hdb=nodma"
';'.
================================================================================
@ -184,57 +181,6 @@ driver using the "options=" keyword to insmod, while replacing any ',' with
Summary of ide driver parameters for kernel command line
--------------------------------------------------------
"hdx=" is recognized for all "x" from "a" to "u", such as "hdc".
"idex=" is recognized for all "x" from "0" to "9", such as "ide1".
"hdx=noprobe" : drive may be present, but do not probe for it
"hdx=none" : drive is NOT present, ignore cmos and do not probe
"hdx=nowerr" : ignore the WRERR_STAT bit on this drive
"hdx=cdrom" : drive is present, and is a cdrom drive
"hdx=cyl,head,sect" : disk drive is present, with specified geometry
"hdx=autotune" : driver will attempt to tune interface speed
to the fastest PIO mode supported,
if possible for this drive only.
Not fully supported by all chipset types,
and quite likely to cause trouble with
older/odd IDE drives.
"hdx=nodma" : disallow DMA
"idebus=xx" : inform IDE driver of VESA/PCI bus speed in MHz,
where "xx" is between 20 and 66 inclusive,
used when tuning chipset PIO modes.
For PCI bus, 25 is correct for a P75 system,
30 is correct for P90,P120,P180 systems,
and 33 is used for P100,P133,P166 systems.
If in doubt, use idebus=33 for PCI.
As for VLB, it is safest to not specify it.
Bigger values are safer than smaller ones.
"idex=serialize" : do not overlap operations on idex. Please note
that you will have to specify this option for
both the respective primary and secondary channel
to take effect.
"idex=reset" : reset interface after probe
"idex=ata66" : informs the interface that it has an 80c cable
for chipsets that are ATA-66 capable, but the
ability to bit test for detection is currently
unknown.
"ide=doubler" : probe/support IDE doublers on Amiga
There may be more options than shown -- use the source, Luke!
Everything else is rejected with a "BAD OPTION" message.
For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672)
you need to explicitly enable probing by using "probe" kernel parameter,
i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
@ -251,6 +197,33 @@ are detected automatically).
You also need to use "probe" kernel parameter for ide-4drives driver
(support for IDE generic chipset with four drives on one port).
To enable support for IDE doublers on Amiga use "doubler" kernel parameter
for gayle host driver (i.e. "gayle.doubler" if the driver is built-in).
To force ignoring cable detection (this should be needed only if you're using
short 40-wires cable which cannot be automatically detected - if this is not
a case please report it as a bug instead) use "ignore_cable" kernel parameter:
* "ide_core.ignore_cable=[interface_number]" boot option if IDE is built-in
(i.e. "ide_core.ignore_cable=1" to force ignoring cable for "ide1")
* "ignore_cable=[interface_number]" module parameter (for ide_core module)
if IDE is compiled as module
Other kernel parameters for ide_core are:
* "nodma=[interface_number.device_number]" to disallow DMA for a device
* "noflush=[interface_number.device_number]" to disable flush requests
* "noprobe=[interface_number.device_number]" to skip probing
* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit
* "cdrom=[interface_number.device_number]" to force device as a CD-ROM
* "chs=[interface_number.device_number]" to force device as a disk (using CHS)
================================================================================
Some Terminology

2
Documentation/ioctl-number.txt
View File

@ -183,6 +183,8 @@ Code Seq# Include File Comments
0xAC 00-1F linux/raw.h
0xAD 00 Netfilter device in development:
<mailto:rusty@rustcorp.com.au>
0xAE all linux/kvm.h Kernel-based Virtual Machine
<mailto:kvm-devel@lists.sourceforge.net>
0xB0 all RATIO devices in development:
<mailto:vgo@ratio.de>
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>

41
Documentation/kbuild/kconfig-language.txt
View File

@ -104,14 +104,15 @@ applicable everywhere (see syntax).
Reverse dependencies can only be used with boolean or tristate
symbols.
Note:
select is evil.... select will by brute force set a symbol
equal to 'y' without visiting the dependencies. So abusing
select you are able to select a symbol FOO even if FOO depends
on BAR that is not set. In general use select only for
non-visible symbols (no prompts anywhere) and for symbols with
no dependencies. That will limit the usefulness but on the
other hand avoid the illegal configurations all over. kconfig
should one day warn about such things.
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
kconfig should one day warn about such things.
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
This allows to limit the range of possible input values for int
@ -376,27 +377,3 @@ config FOO
limits FOO to module (=m) or disabled (=n).
Build limited by a third config symbol which may be =y or =m
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A common idiom that we see (and sometimes have problems with) is this:
When option C in B (module or subsystem) uses interfaces from A (module
or subsystem), and both A and B are tristate (could be =y or =m if they
were independent of each other, but they aren't), then we need to limit
C such that it cannot be built statically if A is built as a loadable
module. (C already depends on B, so there is no dependency issue to
take care of here.)
If A is linked statically into the kernel image, C can be built
statically or as loadable module(s). However, if A is built as loadable
module(s), then C must be restricted to loadable module(s) also. This
can be expressed in kconfig language as:
config C
depends on A = y || A = B
or for real examples, use this command in a kernel tree:
$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v orig

9
Documentation/kbuild/modules.txt
View File

@ -486,7 +486,7 @@ Module.symvers contains a list of all exported symbols from a kernel build.
Sometimes, an external module uses exported symbols from another
external module. Kbuild needs to have full knowledge on all symbols
to avoid spitting out warnings about undefined symbols.
Two solutions exist to let kbuild know all symbols of more than
Three solutions exist to let kbuild know all symbols of more than
one external module.
The method with a top-level kbuild file is recommended but may be
impractical in certain situations.
@ -523,6 +523,13 @@ Module.symvers contains a list of all exported symbols from a kernel build.
containing the sum of all symbols defined and not part of the
kernel.
Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
If it is impractical to copy Module.symvers from another
module, you can assign a space separated list of files to
KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
loaded by modpost during the initialisation of its symbol
tables.
=== 8. Tips & Tricks
--- 8.1 Testing for CONFIG_FOO_BAR

5
Documentation/kdump/kdump.txt
View File

@ -245,6 +245,8 @@ The syntax is:
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]
'start' is inclusive and 'end' is exclusive.
For example:
crashkernel=512M-2G:64M,2G-:128M
@ -253,10 +255,11 @@ This would mean:
1) if the RAM is smaller than 512M, then don't reserve anything
(this is the "rescue" case)
2) if the RAM size is between 512M and 2G, then reserve 64M
2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
3) if the RAM size is larger than 2G, then reserve 128M
Boot into System Kernel
=======================

26
Documentation/kernel-parameters.txt
View File

@ -496,6 +496,11 @@ and is between 256 and 4096 characters. It is defined in the file
switching to the matching ttyS device later. The
options are the same as for ttyS, above.
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
console=brl,ttyS0
For now, only VisioBraille is supported.
earlycon= [KNL] Output early console device and options.
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
@ -556,6 +561,8 @@ and is between 256 and 4096 characters. It is defined in the file
1 will print _a lot_ more information - normally
only useful to kernel developers.
debug_objects [KNL] Enable object debugging
decnet.addr= [HW,NET]
Format: <area>[,<node>]
See also Documentation/networking/decnet.txt.
@ -627,8 +634,7 @@ and is between 256 and 4096 characters. It is defined in the file
eata= [HW,SCSI]
edd= [EDD]
Format: {"of[f]" | "sk[ipmbr]"}
See comment in arch/i386/boot/edd.S
Format: {"off" | "on" | "skip[mbr]"}
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
@ -772,10 +778,6 @@ and is between 256 and 4096 characters. It is defined in the file
Format: ide=nodma or ide=doubler
See Documentation/ide/ide.txt.
ide?= [HW] (E)IDE subsystem
Format: ide?=ata66 or chipset specific parameters.
See Documentation/ide/ide.txt.
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
See Documentation/ide/ide.txt.
@ -1092,9 +1094,6 @@ and is between 256 and 4096 characters. It is defined in the file
mac5380= [HW,SCSI] Format:
<can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>
mac53c9x= [HW,SCSI] Format:
<num_esps>,<disconnect>,<nosync>,<can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>
machvec= [IA64] Force the use of a particular machine-vector
(machvec) in a generic kernel.
Example: machvec=hpzx1_swiotlb
@ -1393,6 +1392,13 @@ and is between 256 and 4096 characters. It is defined in the file
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
olpc_ec_timeout= [OLPC] ms delay when issuing EC commands
Rather than timing out after 20 ms if an EC
command is not properly ACKed, override the length
of the timeout. We have interrupts disabled while
waiting for the ACK, so if this is set too high
interrupts *may* be lost!
opl3= [HW,OSS]
Format: <io>
@ -1516,6 +1522,8 @@ and is between 256 and 4096 characters. It is defined in the file
This is normally done in pci_enable_device(),
so this option is a temporary workaround
for broken drivers that don't call it.
skip_isa_align [X86] do not align io start addr, so can
handle more pci cards
firmware [ARM] Do not re-enumerate the bus but instead
just use the configuration from the
bootloader. This is currently used on

11
Documentation/keys-request-key.txt
View File

@ -11,26 +11,29 @@ request_key*():
struct key *request_key(const struct key_type *type,
const char *description,
const char *callout_string);
const char *callout_info);
or:
struct key *request_key_with_auxdata(const struct key_type *type,
const char *description,
const char *callout_string,
const char *callout_info,
size_t callout_len,
void *aux);
or:
struct key *request_key_async(const struct key_type *type,
const char *description,
const char *callout_string);
const char *callout_info,
size_t callout_len);
or:
struct key *request_key_async_with_auxdata(const struct key_type *type,
const char *description,
const char *callout_string,
const char *callout_info,
size_t callout_len,
void *aux);
Or by userspace invoking the request_key system call:

59
Documentation/keys.txt
View File

@ -170,7 +170,8 @@ The key service provides a number of features besides keys:
amount of description and payload space that can be consumed.
The user can view information on this and other statistics through procfs
files.
files. The root user may also alter the quota limits through sysctl files
(see the section "New procfs files").
Process-specific and thread-specific keyrings are not counted towards a
user's quota.
@ -329,6 +330,27 @@ about the status of the key service:
<bytes>/<max> Key size quota
Four new sysctl files have been added also for the purpose of controlling the
quota limits on keys:
(*) /proc/sys/kernel/keys/root_maxkeys
/proc/sys/kernel/keys/root_maxbytes
These files hold the maximum number of keys that root may have and the
maximum total number of bytes of data that root may have stored in those
keys.
(*) /proc/sys/kernel/keys/maxkeys
/proc/sys/kernel/keys/maxbytes
These files hold the maximum number of keys that each non-root user may
have and the maximum total number of bytes of data that each of those
users may have stored in their keys.
Root may alter these by writing each new limit as a decimal number string to
the appropriate file.
===============================
USERSPACE SYSTEM CALL INTERFACE
===============================
@ -711,6 +733,27 @@ The keyctl syscall functions are:
The assumed authoritative key is inherited across fork and exec.
(*) Get the LSM security context attached to a key.
long keyctl(KEYCTL_GET_SECURITY, key_serial_t key, char *buffer,
size_t buflen)
This function returns a string that represents the LSM security context
attached to a key in the buffer provided.
Unless there's an error, it always returns the amount of data it could
produce, even if that's too big for the buffer, but it won't copy more
than requested to userspace. If the buffer pointer is NULL then no copy
will take place.
A NUL character is included at the end of the string if the buffer is
sufficiently big. This is included in the returned count. If no LSM is
in force then an empty string will be returned.
A process must have view permission on the key for this function to be
successful.
===============
KERNEL SERVICES
===============
@ -771,7 +814,7 @@ payload contents" for more information.
struct key *request_key(const struct key_type *type,
const char *description,
const char *callout_string);
const char *callout_info);
This is used to request a key or keyring with a description that matches
the description specified according to the key type's match function. This
@ -793,24 +836,28 @@ payload contents" for more information.
struct key *request_key_with_auxdata(const struct key_type *type,
const char *description,
const char *callout_string,
const void *callout_info,
size_t callout_len,
void *aux);
This is identical to request_key(), except that the auxiliary data is
passed to the key_type->request_key() op if it exists.
passed to the key_type->request_key() op if it exists, and the callout_info
is a blob of length callout_len, if given (the length may be 0).
(*) A key can be requested asynchronously by calling one of:
struct key *request_key_async(const struct key_type *type,
const char *description,
const char *callout_string);
const void *callout_info,
size_t callout_len);
or:
struct key *request_key_async_with_auxdata(const struct key_type *type,
const char *description,
const char *callout_string,
const char *callout_info,
size_t callout_len,
void *aux);
which are asynchronous equivalents of request_key() and

51
Documentation/kprobes.txt
View File

@ -37,6 +37,11 @@ registration function such as register_kprobe() specifies where
the probe is to be inserted and what handler is to be called when
the probe is hit.
There are also register_/unregister_*probes() functions for batch
registration/unregistration of a group of *probes. These functions
can speed up unregistration process when you have to unregister
a lot of probes at once.
The next three subsections explain how the different types of
probes work. They explain certain things that you'll need to
know in order to make the best use of Kprobes -- e.g., the
@ -190,10 +195,11 @@ code mapping.
4. API Reference
The Kprobes API includes a "register" function and an "unregister"
function for each type of probe. Here are terse, mini-man-page
specifications for these functions and the associated probe handlers
that you'll write. See the files in the samples/kprobes/ sub-directory
for examples.
function for each type of probe. The API also includes "register_*probes"
and "unregister_*probes" functions for (un)registering arrays of probes.
Here are terse, mini-man-page specifications for these functions and
the associated probe handlers that you'll write. See the files in the
samples/kprobes/ sub-directory for examples.
4.1 register_kprobe
@ -319,6 +325,43 @@ void unregister_kretprobe(struct kretprobe *rp);
Removes the specified probe. The unregister function can be called
at any time after the probe has been registered.
NOTE:
If the functions find an incorrect probe (ex. an unregistered probe),
they clear the addr field of the probe.
4.5 register_*probes
#include <linux/kprobes.h>
int register_kprobes(struct kprobe **kps, int num);
int register_kretprobes(struct kretprobe **rps, int num);
int register_jprobes(struct jprobe **jps, int num);
Registers each of the num probes in the specified array. If any
error occurs during registration, all probes in the array, up to
the bad probe, are safely unregistered before the register_*probes
function returns.
- kps/rps/jps: an array of pointers to *probe data structures
- num: the number of the array entries.
NOTE:
You have to allocate(or define) an array of pointers and set all
of the array entries before using these functions.
4.6 unregister_*probes
#include <linux/kprobes.h>
void unregister_kprobes(struct kprobe **kps, int num);
void unregister_kretprobes(struct kretprobe **rps, int num);
void unregister_jprobes(struct jprobe **jps, int num);
Removes each of the num probes in the specified array at once.
NOTE:
If the functions find some incorrect probes (ex. unregistered
probes) in the specified array, they clear the addr field of those
incorrect probes. However, other probes in the array are
unregistered correctly.
5. Kprobes Features and Limitations
Kprobes allows multiple probes at the same address. Currently,

139
Documentation/laptops/thinkpad-acpi.txt
View File

@ -1,7 +1,7 @@
ThinkPad ACPI Extras Driver
Version 0.19
January 06th, 2008
Version 0.20
April 09th, 2008
Borislav Deianov <borislav@users.sf.net>
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@ -18,6 +18,11 @@ This driver used to be named ibm-acpi until kernel 2.6.21 and release
moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel
2.6.22, and release 0.14.
The driver is named "thinkpad-acpi". In some places, like module
names, "thinkpad_acpi" is used because of userspace issues.
"tpacpi" is used as a shorthand where "thinkpad-acpi" would be too
long due to length limitations on some Linux kernel versions.
Status
------
@ -571,6 +576,47 @@ netlink interface and the input layer interface, and don't bother at all
with hotkey_report_mode.
Brightness hotkey notes:
These are the current sane choices for brightness key mapping in
thinkpad-acpi:
For IBM and Lenovo models *without* ACPI backlight control (the ones on
which thinkpad-acpi will autoload its backlight interface by default,
and on which ACPI video does not export a backlight interface):
1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as
these older firmware versions unfortunately won't respect the hotkey
mask for brightness keys anyway, and always reacts to them. This
usually work fine, unless X.org drivers are doing something to block
the BIOS. In that case, use (3) below. This is the default mode of
operation.
2. Enable the hotkeys, but map them to something else that is NOT
KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause
userspace to try to change the backlight level, and use that as an
on-screen-display hint.
3. IF AND ONLY IF X.org drivers find a way to block the firmware from
automatically changing the brightness, enable the hotkeys and map
them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to
something that calls xbacklight. thinkpad-acpi will not be able to
change brightness in that case either, so you should disable its
backlight interface.
For Lenovo models *with* ACPI backlight control:
1. Load up ACPI video and use that. ACPI video will report ACPI
events for brightness change keys. Do not mess with thinkpad-acpi
defaults in this case. thinkpad-acpi should not have anything to do
with backlight events in a scenario where ACPI video is loaded:
brightness hotkeys must be disabled, and the backlight interface is
to be kept disabled as well. This is the default mode of operation.
2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi,
and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process
these keys on userspace somehow (e.g. by calling xbacklight).
Bluetooth
---------
@ -647,16 +693,31 @@ while others are still having problems. For more information:
https://bugs.freedesktop.org/show_bug.cgi?id=2000
ThinkLight control -- /proc/acpi/ibm/light
------------------------------------------
ThinkLight control
------------------
The current status of the ThinkLight can be found in this file. A few
models which do not make the status available will show it as
"unknown". The available commands are:
procfs: /proc/acpi/ibm/light
sysfs attributes: as per LED class, for the "tpacpi::thinklight" LED
procfs notes:
The ThinkLight status can be read and set through the procfs interface. A
few models which do not make the status available will show the ThinkLight
status as "unknown". The available commands are:
echo on > /proc/acpi/ibm/light
echo off > /proc/acpi/ibm/light
sysfs notes:
The ThinkLight sysfs interface is documented by the LED class
documentation, in Documentation/leds-class.txt. The ThinkLight LED name
is "tpacpi::thinklight".
Due to limitations in the sysfs LED class, if the status of the thinklight
cannot be read or if it is unknown, thinkpad-acpi will report it as "off".
It is impossible to know if the status returned through sysfs is valid.
Docking / undocking -- /proc/acpi/ibm/dock
------------------------------------------
@ -815,28 +876,63 @@ The cmos command interface is prone to firmware split-brain problems, as
in newer ThinkPads it is just a compatibility layer. Do not use it, it is
exported just as a debug tool.
LED control -- /proc/acpi/ibm/led
---------------------------------
LED control
-----------
Some of the LED indicators can be controlled through this feature. The
available commands are:
procfs: /proc/acpi/ibm/led
sysfs attributes: as per LED class, see below for names
echo '<led number> on' >/proc/acpi/ibm/led
echo '<led number> off' >/proc/acpi/ibm/led
echo '<led number> blink' >/proc/acpi/ibm/led
Some of the LED indicators can be controlled through this feature. On
some older ThinkPad models, it is possible to query the status of the
LED indicators as well. Newer ThinkPads cannot query the real status
of the LED indicators.
The <led number> range is 0 to 7. The set of LEDs that can be
controlled varies from model to model. Here is the mapping on the X40:
procfs notes:
The available commands are:
echo '<LED number> on' >/proc/acpi/ibm/led
echo '<LED number> off' >/proc/acpi/ibm/led
echo '<LED number> blink' >/proc/acpi/ibm/led
The <LED number> range is 0 to 7. The set of LEDs that can be
controlled varies from model to model. Here is the common ThinkPad
mapping:
0 - power
1 - battery (orange)
2 - battery (green)
3 - UltraBase
3 - UltraBase/dock
4 - UltraBay
5 - UltraBase battery slot
6 - (unknown)
7 - standby
All of the above can be turned on and off and can be made to blink.
sysfs notes:
The ThinkPad LED sysfs interface is described in detail by the LED class
documentation, in Documentation/leds-class.txt.
The leds are named (in LED ID order, from 0 to 7):
"tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt",
"tpacpi::dock_active", "tpacpi::bay_active", "tpacpi::dock_batt",
"tpacpi::unknown_led", "tpacpi::standby".
Due to limitations in the sysfs LED class, if the status of the LED
indicators cannot be read due to an error, thinkpad-acpi will report it as
a brightness of zero (same as LED off).
If the thinkpad firmware doesn't support reading the current status,
trying to read the current LED brightness will just return whatever
brightness was last written to that attribute.
These LEDs can blink using hardware acceleration. To request that a
ThinkPad indicator LED should blink in hardware accelerated mode, use the
"timer" trigger, and leave the delay_on and delay_off parameters set to
zero (to request hardware acceleration autodetection).
ACPI sounds -- /proc/acpi/ibm/beep
----------------------------------
@ -1090,6 +1186,15 @@ it there will be the following attributes:
dim the display.
WARNING:
Whatever you do, do NOT ever call thinkpad-acpi backlight-level change
interface and the ACPI-based backlight level change interface
(available on newer BIOSes, and driven by the Linux ACPI video driver)
at the same time. The two will interact in bad ways, do funny things,
and maybe reduce the life of the backlight lamps by needlessly kicking
its level up and down at every change.
Volume control -- /proc/acpi/ibm/volume
---------------------------------------

12
Documentation/leds-class.txt
View File

@ -19,6 +19,12 @@ optimises away.
Complex triggers whilst available to all LEDs have LED specific
parameters and work on a per LED basis. The timer trigger is an example.
The timer trigger will periodically change the LED brightness between
LED_OFF and the current brightness setting. The "on" and "off" time can
be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds.
You can change the brightness value of a LED independently of the timer
trigger. However, if you set the brightness value to LED_OFF it will
also disable the timer trigger.
You can change triggers in a similar manner to the way an IO scheduler
is chosen (via /sys/class/leds/<device>/trigger). Trigger specific
@ -63,9 +69,9 @@ value if it is called with *delay_on==0 && *delay_off==0 parameters. In
this case the driver should give back the chosen value through delay_on
and delay_off parameters to the leds subsystem.
Any call to the brightness_set() callback function should cancel the
previously programmed hardware blinking function so setting the brightness
to 0 can also cancel the blinking of the LED.
Setting the brightness to zero with brightness_set() callback function
should completely turn off the LED and cancel the previously programmed
hardware blinking function, if any.
Known Issues

62
Documentation/lguest/lguest.c
View File

@ -131,6 +131,9 @@ struct device
/* Any queues attached to this device */
struct virtqueue *vq;
/* Handle status being finalized (ie. feature bits stable). */
void (*ready)(struct device *me);
/* Device-specific data. */
void *priv;
};
@ -925,24 +928,40 @@ static void enable_fd(int fd, struct virtqueue *vq)
write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd));
}
/* When the Guest asks us to reset a device, it's is fairly easy. */
static void reset_device(struct device *dev)
/* When the Guest tells us they updated the status field, we handle it. */
static void update_device_status(struct device *dev)
{
struct virtqueue *vq;
verbose("Resetting device %s\n", dev->name);
/* Clear the status. */
dev->desc->status = 0;
/* This is a reset. */
if (dev->desc->status == 0) {
verbose("Resetting device %s\n", dev->name);
/* Clear any features they've acked. */
memset(get_feature_bits(dev) + dev->desc->feature_len, 0,
dev->desc->feature_len);
/* Clear any features they've acked. */
memset(get_feature_bits(dev) + dev->desc->feature_len, 0,
dev->desc->feature_len);
/* Zero out the virtqueues. */
for (vq = dev->vq; vq; vq = vq->next) {
memset(vq->vring.desc, 0,
vring_size(vq->config.num, getpagesize()));
vq->last_avail_idx = 0;
/* Zero out the virtqueues. */
for (vq = dev->vq; vq; vq = vq->next) {
memset(vq->vring.desc, 0,
vring_size(vq->config.num, getpagesize()));
vq->last_avail_idx = 0;
}
} else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
warnx("Device %s configuration FAILED", dev->name);
} else if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK) {
unsigned int i;
verbose("Device %s OK: offered", dev->name);
for (i = 0; i < dev->desc->feature_len; i++)
verbose(" %08x", get_feature_bits(dev)[i]);
verbose(", accepted");
for (i = 0; i < dev->desc->feature_len; i++)
verbose(" %08x", get_feature_bits(dev)
[dev->desc->feature_len+i]);
if (dev->ready)
dev->ready(dev);
}
}
@ -954,9 +973,9 @@ static void handle_output(int fd, unsigned long addr)
/* Check each device and virtqueue. */
for (i = devices.dev; i; i = i->next) {
/* Notifications to device descriptors reset the device. */
/* Notifications to device descriptors update device status. */
if (from_guest_phys(addr) == i->desc) {
reset_device(i);
update_device_status(i);
return;
}
@ -1170,6 +1189,7 @@ static struct device *new_device(const char *name, u16 type, int fd,
dev->handle_input = handle_input;
dev->name = name;
dev->vq = NULL;
dev->ready = NULL;
/* Append to device list. Prepending to a single-linked list is
* easier, but the user expects the devices to be arranged on the bus
@ -1398,7 +1418,7 @@ static bool service_io(struct device *dev)
struct vblk_info *vblk = dev->priv;
unsigned int head, out_num, in_num, wlen;
int ret;
struct virtio_blk_inhdr *in;
u8 *in;
struct virtio_blk_outhdr *out;
struct iovec iov[dev->vq->vring.num];
off64_t off;
@ -1416,7 +1436,7 @@ static bool service_io(struct device *dev)
head, out_num, in_num);
out = convert(&iov[0], struct virtio_blk_outhdr);
in = convert(&iov[out_num+in_num-1], struct virtio_blk_inhdr);
in = convert(&iov[out_num+in_num-1], u8);
off = out->sector * 512;
/* The block device implements "barriers", where the Guest indicates
@ -1430,7 +1450,7 @@ static bool service_io(struct device *dev)
* It'd be nice if we supported eject, for example, but we don't. */
if (out->type & VIRTIO_BLK_T_SCSI_CMD) {
fprintf(stderr, "Scsi commands unsupported\n");
in->status = VIRTIO_BLK_S_UNSUPP;
*in = VIRTIO_BLK_S_UNSUPP;
wlen = sizeof(*in);
} else if (out->type & VIRTIO_BLK_T_OUT) {
/* Write */
@ -1453,7 +1473,7 @@ static bool service_io(struct device *dev)
errx(1, "Write past end %llu+%u", off, ret);
}
wlen = sizeof(*in);
in->status = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
*in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
} else {
/* Read */
@ -1466,10 +1486,10 @@ static bool service_io(struct device *dev)
verbose("READ from sector %llu: %i\n", out->sector, ret);
if (ret >= 0) {
wlen = sizeof(*in) + ret;
in->status = VIRTIO_BLK_S_OK;
*in = VIRTIO_BLK_S_OK;
} else {
wlen = sizeof(*in);
in->status = VIRTIO_BLK_S_IOERR;
*in = VIRTIO_BLK_S_IOERR;
}
}

6
Documentation/md.txt
View File

@ -450,3 +450,9 @@ These currently include
there are upper and lower limits (32768, 16). Default is 128.
strip_cache_active (currently raid5 only)
number of active entries in the stripe cache
preread_bypass_threshold (currently raid5 only)
number of times a stripe requiring preread will be bypassed by
a stripe that does not require preread. For fairness defaults
to 1. Setting this to 0 disables bypass accounting and
requires preread stripes to wait until all full-width stripe-
writes are complete. Valid values are 0 to stripe_cache_size.

46
Documentation/mips/AU1xxx_IDE.README
View File

@ -46,8 +46,6 @@ Two files are introduced:
a) 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
containes : struct _auide_hwif
struct drive_list_entry dma_white_list
struct drive_list_entry dma_black_list
timing parameters for PIO mode 0/1/2/3/4
timing parameters for MWDMA 0/1/2
@ -63,12 +61,6 @@ Four configs variables are introduced:
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ - maximum transfer size
per descriptor
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
HARD DISC TO WHITE OR BLACK LIST' section).
SUPPORTED IDE MODES
-------------------
@ -120,44 +112,6 @@ CONFIG_IDEDMA_AUTO=y
Also undefine 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to
disable the burst support on DBDMA controller.
ADD NEW HARD DISC TO WHITE OR BLACK LIST
----------------------------------------
Step 1 : detect the model name of your hard disc
a) connect your hard disc to the AU1XXX
b) boot your kernel and get the hard disc model.
Example boot log:
--snipped--
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
Au1xxx IDE(builtin) configured for MWDMA2
Probing IDE interface ide0...
hda: Maxtor 6E040L0, ATA DISK drive
ide0 at 0xac800000-0xac800007,0xac8001c0 on irq 64
hda: max request size: 64KiB
hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63, (U)DMA
--snipped--
In this example 'Maxtor 6E040L0'.
Step 2 : edit 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
Add your hard disc to the dma_white_list or dma_black_list structur.
Step 3 : Recompile the kernel
Enable MWDMA support in the kernel configuration. Recompile the kernel and
reboot.
Step 4 : Tests
If you have add a hard disc to the white list, please run some stress tests
for verification.
ACKNOWLEDGMENTS
---------------

38
Documentation/networking/phy.txt
View File

@ -1,7 +1,7 @@
-------
PHY Abstraction Layer
(Updated 2006-11-30)
(Updated 2008-04-08)
Purpose
@ -291,3 +291,39 @@ Writing a PHY driver
Feel free to look at the Marvell, Cicada, and Davicom drivers in
drivers/net/phy/ for examples (the lxt and qsemi drivers have
not been tested as of this writing)
Board Fixups
Sometimes the specific interaction between the platform and the PHY requires
special handling. For instance, to change where the PHY's clock input is,
or to add a delay to account for latency issues in the data path. In order
to support such contingencies, the PHY Layer allows platform code to register
fixups to be run when the PHY is brought up (or subsequently reset).
When the PHY Layer brings up a PHY it checks to see if there are any fixups
registered for it, matching based on UID (contained in the PHY device's phy_id
field) and the bus identifier (contained in phydev->dev.bus_id). Both must
match, however two constants, PHY_ANY_ID and PHY_ANY_UID, are provided as
wildcards for the bus ID and UID, respectively.
When a match is found, the PHY layer will invoke the run function associated
with the fixup. This function is passed a pointer to the phy_device of
interest. It should therefore only operate on that PHY.
The platform code can either register the fixup using phy_register_fixup():
int phy_register_fixup(const char *phy_id,
u32 phy_uid, u32 phy_uid_mask,
int (*run)(struct phy_device *));
Or using one of the two stubs, phy_register_fixup_for_uid() and
phy_register_fixup_for_id():
int phy_register_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask,
int (*run)(struct phy_device *));
int phy_register_fixup_for_id(const char *phy_id,
int (*run)(struct phy_device *));
The stubs set one of the two matching criteria, and set the other one to
match anything.

4
Documentation/oops-tracing.txt
View File

@ -253,6 +253,10 @@ characters, each representing a particular tainted value.
8: 'D' if the kernel has died recently, i.e. there was an OOPS or BUG.
9: 'A' if the ACPI table has been overridden.
10: 'W' if a warning has previously been issued by the kernel.
The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is

44
Documentation/powerpc/booting-without-of.txt
View File

@ -2601,6 +2601,17 @@ platforms are moved over to use the flattened-device-tree model.
differ between different families. May be
'virtex2p', 'virtex4', or 'virtex5'.
vi) Xilinx Uart 16550
Xilinx UART 16550 devices are very similar to the NS16550 but with
different register spacing and an offset from the base address.
Requred properties:
- clock-frequency : Frequency of the clock input
- reg-offset : A value of 3 is required
- reg-shift : A value of 2 is required
p) Freescale Synchronous Serial Interface
The SSI is a serial device that communicates with audio codecs. It can
@ -2825,6 +2836,39 @@ platforms are moved over to use the flattened-device-tree model.
big-endian;
};
r) Freescale Display Interface Unit
The Freescale DIU is a LCD controller, with proper hardware, it can also
drive DVI monitors.
Required properties:
- compatible : should be "fsl-diu".
- reg : should contain at least address and length of the DIU register
set.
- Interrupts : one DIU interrupt should be describe here.
Example (MPC8610HPCD)
display@2c000 {
compatible = "fsl,diu";
reg = <0x2c000 100>;
interrupts = <72 2>;
interrupt-parent = <&mpic>;
};
s) Freescale on board FPGA
This is the memory-mapped registers for on board FPGA.
Required properities:
- compatible : should be "fsl,fpga-pixis".
- reg : should contain the address and the lenght of the FPPGA register
set.
Example (MPC8610HPCD)
board-control@e8000000 {
compatible = "fsl,fpga-pixis";
reg = <0xe8000000 32>;
};
VII - Marvell Discovery mv64[345]6x System Controller chips
===========================================================

41
Documentation/powerpc/kvm_440.txt Normal file
View File

@ -0,0 +1,41 @@
Hollis Blanchard <hollisb@us.ibm.com>
15 Apr 2008
Various notes on the implementation of KVM for PowerPC 440:
To enforce isolation, host userspace, guest kernel, and guest userspace all
run at user privilege level. Only the host kernel runs in supervisor mode.
Executing privileged instructions in the guest traps into KVM (in the host
kernel), where we decode and emulate them. Through this technique, unmodified
440 Linux kernels can be run (slowly) as guests. Future performance work will
focus on reducing the overhead and frequency of these traps.
The usual code flow is started from userspace invoking an "run" ioctl, which
causes KVM to switch into guest context. We use IVPR to hijack the host
interrupt vectors while running the guest, which allows us to direct all
interrupts to kvmppc_handle_interrupt(). At this point, we could either
- handle the interrupt completely (e.g. emulate "mtspr SPRG0"), or
- let the host interrupt handler run (e.g. when the decrementer fires), or
- return to host userspace (e.g. when the guest performs device MMIO)
Address spaces: We take advantage of the fact that Linux doesn't use the AS=1
address space (in host or guest), which gives us virtual address space to use
for guest mappings. While the guest is running, the host kernel remains mapped
in AS=0, but the guest can only use AS=1 mappings.
TLB entries: The TLB entries covering the host linear mapping remain
present while running the guest. This reduces the overhead of lightweight
exits, which are handled by KVM running in the host kernel. We keep three
copies of the TLB:
- guest TLB: contents of the TLB as the guest sees it
- shadow TLB: the TLB that is actually in hardware while guest is running
- host TLB: to restore TLB state when context switching guest -> host
When a TLB miss occurs because a mapping was not present in the shadow TLB,
but was present in the guest TLB, KVM handles the fault without invoking the
guest. Large guest pages are backed by multiple 4KB shadow pages through this
mechanism.
IO: MMIO and DCR accesses are emulated by userspace. We use virtio for network
and block IO, so those drivers must be enabled in the guest. It's possible
that some qemu device emulation (e.g. e1000 or rtl8139) may also work with
little effort.

23
Documentation/powerpc/mpc52xx-device-tree-bindings.txt
View File

@ -186,6 +186,12 @@ Recommended soc5200 child nodes; populate as needed for your board
name device_type compatible Description
---- ----------- ---------- -----------
gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers
gpt@<addr> gpt fsl,mpc5200-gpt-gpio General purpose
timers in GPIO mode
gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio
controller
gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio
controller
rtc@<addr> rtc mpc5200-rtc Real time clock
mscan@<addr> mscan mpc5200-mscan CAN bus controller
pci@<addr> pci mpc5200-pci PCI bridge
@ -225,6 +231,23 @@ PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
compatible field.
7) GPIO controller nodes
Each GPIO controller node should have the empty property gpio-controller and
#gpio-cells set to 2. First cell is the GPIO number which is interpreted
according to the bit numbers in the GPIO control registers. The second cell
is for flags which is currently unsused.
8) FEC nodes
The FEC node can specify one of the following properties to configure
the MII link:
"fsl,7-wire-mode" - An empty property that specifies the link uses 7-wire
mode instead of MII
"current-speed" - Specifies that the MII should be configured for a fixed
speed. This property should contain two cells. The
first cell specifies the speed in Mbps and the second
should be '0' for half duplex and '1' for full duplex
"phy-handle" - Contains a phandle to an Ethernet PHY.
IV - Extra Notes
================

125
Documentation/s390/kvm.txt Normal file
View File

@ -0,0 +1,125 @@
*** BIG FAT WARNING ***
The kvm module is currently in EXPERIMENTAL state for s390. This means that
the interface to the module is not yet considered to remain stable. Thus, be
prepared that we keep breaking your userspace application and guest
compatibility over and over again until we feel happy with the result. Make sure
your guest kernel, your host kernel, and your userspace launcher are in a
consistent state.
This Documentation describes the unique ioctl calls to /dev/kvm, the resulting
kvm-vm file descriptors, and the kvm-vcpu file descriptors that differ from x86.
1. ioctl calls to /dev/kvm
KVM does support the following ioctls on s390 that are common with other
architectures and do behave the same:
KVM_GET_API_VERSION
KVM_CREATE_VM (*) see note
KVM_CHECK_EXTENSION
KVM_GET_VCPU_MMAP_SIZE
Notes:
* KVM_CREATE_VM may fail on s390, if the calling process has multiple
threads and has not called KVM_S390_ENABLE_SIE before.
In addition, on s390 the following architecture specific ioctls are supported:
ioctl: KVM_S390_ENABLE_SIE
args: none
see also: include/linux/kvm.h
This call causes the kernel to switch on PGSTE in the user page table. This
operation is needed in order to run a virtual machine, and it requires the
calling process to be single-threaded. Note that the first call to KVM_CREATE_VM
will implicitly try to switch on PGSTE if the user process has not called
KVM_S390_ENABLE_SIE before. User processes that want to launch multiple threads
before creating a virtual machine have to call KVM_S390_ENABLE_SIE, or will
observe an error calling KVM_CREATE_VM. Switching on PGSTE is a one-time
operation, is not reversible, and will persist over the entire lifetime of
the calling process. It does not have any user-visible effect other than a small
performance penalty.
2. ioctl calls to the kvm-vm file descriptor
KVM does support the following ioctls on s390 that are common with other
architectures and do behave the same:
KVM_CREATE_VCPU
KVM_SET_USER_MEMORY_REGION (*) see note
KVM_GET_DIRTY_LOG (**) see note
Notes:
* kvm does only allow exactly one memory slot on s390, which has to start
at guest absolute address zero and at a user address that is aligned on any
page boundary. This hardware "limitation" allows us to have a few unique
optimizations. The memory slot doesn't have to be filled
with memory actually, it may contain sparse holes. That said, with different
user memory layout this does still allow a large flexibility when
doing the guest memory setup.
** KVM_GET_DIRTY_LOG doesn't work properly yet. The user will receive an empty
log. This ioctl call is only needed for guest migration, and we intend to
implement this one in the future.
In addition, on s390 the following architecture specific ioctls for the kvm-vm
file descriptor are supported:
ioctl: KVM_S390_INTERRUPT
args: struct kvm_s390_interrupt *
see also: include/linux/kvm.h
This ioctl is used to submit a floating interrupt for a virtual machine.
Floating interrupts may be delivered to any virtual cpu in the configuration.
Only some interrupt types defined in include/linux/kvm.h make sense when
submitted as floating interrupts. The following interrupts are not considered
to be useful as floating interrupts, and a call to inject them will result in
-EINVAL error code: program interrupts and interprocessor signals. Valid
floating interrupts are:
KVM_S390_INT_VIRTIO
KVM_S390_INT_SERVICE
3. ioctl calls to the kvm-vcpu file descriptor
KVM does support the following ioctls on s390 that are common with other
architectures and do behave the same:
KVM_RUN
KVM_GET_REGS
KVM_SET_REGS
KVM_GET_SREGS
KVM_SET_SREGS
KVM_GET_FPU
KVM_SET_FPU
In addition, on s390 the following architecture specific ioctls for the
kvm-vcpu file descriptor are supported:
ioctl: KVM_S390_INTERRUPT
args: struct kvm_s390_interrupt *
see also: include/linux/kvm.h
This ioctl is used to submit an interrupt for a specific virtual cpu.
Only some interrupt types defined in include/linux/kvm.h make sense when
submitted for a specific cpu. The following interrupts are not considered
to be useful, and a call to inject them will result in -EINVAL error code:
service processor calls and virtio interrupts. Valid interrupt types are:
KVM_S390_PROGRAM_INT
KVM_S390_SIGP_STOP
KVM_S390_RESTART
KVM_S390_SIGP_SET_PREFIX
KVM_S390_INT_EMERGENCY
ioctl: KVM_S390_STORE_STATUS
args: unsigned long
see also: include/linux/kvm.h
This ioctl stores the state of the cpu at the guest real address given as
argument, unless one of the following values defined in include/linux/kvm.h
is given as arguement:
KVM_S390_STORE_STATUS_NOADDR - the CPU stores its status to the save area in
absolute lowcore as defined by the principles of operation
KVM_S390_STORE_STATUS_PREFIXED - the CPU stores its status to the save area in
its prefix page just like the dump tool that comes with zipl. This is useful
to create a system dump for use with lkcdutils or crash.
ioctl: KVM_S390_SET_INITIAL_PSW
args: struct kvm_s390_psw *
see also: include/linux/kvm.h
This ioctl can be used to set the processor status word (psw) of a stopped cpu
prior to running it with KVM_RUN. Note that this call is not required to modify
the psw during sie intercepts that fall back to userspace because struct kvm_run
does contain the psw, and this value is evaluated during reentry of KVM_RUN
after the intercept exit was recognized.
ioctl: KVM_S390_INITIAL_RESET
args: none
see also: include/linux/kvm.h
This ioctl can be used to perform an initial cpu reset as defined by the
principles of operation. The target cpu has to be in stopped state.

165
Documentation/scheduler/sched-design.txt
View File

@ -1,165 +0,0 @@
Goals, Design and Implementation of the
new ultra-scalable O(1) scheduler
This is an edited version of an email Ingo Molnar sent to
lkml on 4 Jan 2002. It describes the goals, design, and
implementation of Ingo's new ultra-scalable O(1) scheduler.
Last Updated: 18 April 2002.
Goal
====
The main goal of the new scheduler is to keep all the good things we know
and love about the current Linux scheduler:
- good interactive performance even during high load: if the user
types or clicks then the system must react instantly and must execute
the user tasks smoothly, even during considerable background load.
- good scheduling/wakeup performance with 1-2 runnable processes.
- fairness: no process should stay without any timeslice for any
unreasonable amount of time. No process should get an unjustly high
amount of CPU time.
- priorities: less important tasks can be started with lower priority,
more important tasks with higher priority.
- SMP efficiency: no CPU should stay idle if there is work to do.
- SMP affinity: processes which run on one CPU should stay affine to
that CPU. Processes should not bounce between CPUs too frequently.
- plus additional scheduler features: RT scheduling, CPU binding.
and the goal is also to add a few new things:
- fully O(1) scheduling. Are you tired of the recalculation loop
blowing the L1 cache away every now and then? Do you think the goodness
loop is taking a bit too long to finish if there are lots of runnable
processes? This new scheduler takes no prisoners: wakeup(), schedule(),
the timer interrupt are all O(1) algorithms. There is no recalculation
loop. There is no goodness loop either.
- 'perfect' SMP scalability. With the new scheduler there is no 'big'
runqueue_lock anymore - it's all per-CPU runqueues and locks - two
tasks on two separate CPUs can wake up, schedule and context-switch
completely in parallel, without any interlocking. All
scheduling-relevant data is structured for maximum scalability.
- better SMP affinity. The old scheduler has a particular weakness that
causes the random bouncing of tasks between CPUs if/when higher
priority/interactive tasks, this was observed and reported by many
people. The reason is that the timeslice recalculation loop first needs
every currently running task to consume its timeslice. But when this
happens on eg. an 8-way system, then this property starves an
increasing number of CPUs from executing any process. Once the last
task that has a timeslice left has finished using up that timeslice,
the recalculation loop is triggered and other CPUs can start executing
tasks again - after having idled around for a number of timer ticks.
The more CPUs, the worse this effect.
Furthermore, this same effect causes the bouncing effect as well:
whenever there is such a 'timeslice squeeze' of the global runqueue,
idle processors start executing tasks which are not affine to that CPU.
(because the affine tasks have finished off their timeslices already.)
The new scheduler solves this problem by distributing timeslices on a
per-CPU basis, without having any global synchronization or
recalculation.
- batch scheduling. A significant proportion of computing-intensive tasks
benefit from batch-scheduling, where timeslices are long and processes
are roundrobin scheduled. The new scheduler does such batch-scheduling
of the lowest priority tasks - so nice +19 jobs will get
'batch-scheduled' automatically. With this scheduler, nice +19 jobs are
in essence SCHED_IDLE, from an interactiveness point of view.
- handle extreme loads more smoothly, without breakdown and scheduling
storms.
- O(1) RT scheduling. For those RT folks who are paranoid about the
O(nr_running) property of the goodness loop and the recalculation loop.
- run fork()ed children before the parent. Andrea has pointed out the
advantages of this a few months ago, but patches for this feature
do not work with the old scheduler as well as they should,
because idle processes often steal the new child before the fork()ing
CPU gets to execute it.
Design
======
The core of the new scheduler contains the following mechanisms:
- *two* priority-ordered 'priority arrays' per CPU. There is an 'active'
array and an 'expired' array. The active array contains all tasks that
are affine to this CPU and have timeslices left. The expired array
contains all tasks which have used up their timeslices - but this array
is kept sorted as well. The active and expired array is not accessed
directly, it's accessed through two pointers in the per-CPU runqueue
structure. If all active tasks are used up then we 'switch' the two
pointers and from now on the ready-to-go (former-) expired array is the
active array - and the empty active array serves as the new collector
for expired tasks.
- there is a 64-bit bitmap cache for array indices. Finding the highest
priority task is thus a matter of two x86 BSFL bit-search instructions.
the split-array solution enables us to have an arbitrary number of active
and expired tasks, and the recalculation of timeslices can be done
immediately when the timeslice expires. Because the arrays are always
access through the pointers in the runqueue, switching the two arrays can
be done very quickly.
this is a hybride priority-list approach coupled with roundrobin
scheduling and the array-switch method of distributing timeslices.
- there is a per-task 'load estimator'.
one of the toughest things to get right is good interactive feel during
heavy system load. While playing with various scheduler variants i found
that the best interactive feel is achieved not by 'boosting' interactive
tasks, but by 'punishing' tasks that want to use more CPU time than there
is available. This method is also much easier to do in an O(1) fashion.
to establish the actual 'load' the task contributes to the system, a
complex-looking but pretty accurate method is used: there is a 4-entry
'history' ringbuffer of the task's activities during the last 4 seconds.
This ringbuffer is operated without much overhead. The entries tell the
scheduler a pretty accurate load-history of the task: has it used up more
CPU time or less during the past N seconds. [the size '4' and the interval
of 4x 1 seconds was found by lots of experimentation - this part is
flexible and can be changed in both directions.]
the penalty a task gets for generating more load than the CPU can handle
is a priority decrease - there is a maximum amount to this penalty
relative to their static priority, so even fully CPU-bound tasks will
observe each other's priorities, and will share the CPU accordingly.
the SMP load-balancer can be extended/switched with additional parallel
computing and cache hierarchy concepts: NUMA scheduling, multi-core CPUs
can be supported easily by changing the load-balancer. Right now it's
tuned for my SMP systems.
i skipped the prev->mm == next->mm advantage - no workload i know of shows
any sensitivity to this. It can be added back by sacrificing O(1)
schedule() [the current and one-lower priority list can be searched for a
that->mm == current->mm condition], but costs a fair number of cycles
during a number of important workloads, so i wanted to avoid this as much
as possible.
- the SMP idle-task startup code was still racy and the new scheduler
triggered this. So i streamlined the idle-setup code a bit. We do not call
into schedule() before all processors have started up fully and all idle
threads are in place.
- the patch also cleans up a number of aspects of sched.c - moves code
into other areas of the kernel where it's appropriate, and simplifies
certain code paths and data constructs. As a result, the new scheduler's
code is smaller than the old one.
Ingo

22
Documentation/scsi/ChangeLog.megaraid_sas
View File

@ -1,3 +1,25 @@
1 Release Date : Mon. March 10 11:02:31 PDT 2008 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.20-RC1
3 Older Version : 00.00.03.16
1. Rollback the sense info implementation
Sense buffer ptr data type in the ioctl path is reverted back
to u32 * as in previous versions of driver.
2. Fixed the driver frame count.
When Driver sent wrong frame count to firmware. As this
particular command is sent to drive, FW is seeing continuous
chip resets and so the command will timeout.
3. Add the new controller(1078DE) support to the driver
and Increase the max_wait to 60 from 10 in the controller
operational status. With this max_wait increase, driver will
make sure the FW will finish the pending cmd for KDUMP case.
1 Release Date : Thur. Nov. 07 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro

98
Documentation/smart-config.txt
View File

@ -1,98 +0,0 @@
Smart CONFIG_* Dependencies
1 August 1999
Michael Chastain <mec@shout.net>
Werner Almesberger <almesber@lrc.di.epfl.ch>
Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de>
Here is the problem:
Suppose that drivers/net/foo.c has the following lines:
#include <linux/config.h>
...
#ifdef CONFIG_FOO_AUTOFROB
/* Code for auto-frobbing */
#else
/* Manual frobbing only */
#endif
...
#ifdef CONFIG_FOO_MODEL_TWO
/* Code for model two */
#endif
Now suppose the user (the person building kernels) reconfigures the
kernel to change some unrelated setting. This will regenerate the
file include/linux/autoconf.h, which will cause include/linux/config.h
to be out of date, which will cause drivers/net/foo.c to be recompiled.
Most kernel sources, perhaps 80% of them, have at least one CONFIG_*
dependency somewhere. So changing _any_ CONFIG_* setting requires
almost _all_ of the kernel to be recompiled.
Here is the solution:
We've made the dependency generator, mkdep.c, smarter. Instead of
generating this dependency:
drivers/net/foo.c: include/linux/config.h
It now generates these dependencies:
drivers/net/foo.c: \
include/config/foo/autofrob.h \
include/config/foo/model/two.h
So drivers/net/foo.c depends only on the CONFIG_* lines that
it actually uses.
A new program, split-include.c, runs at the beginning of
compilation (make bzImage or make zImage). split-include reads
include/linux/autoconf.h and updates the include/config/ tree,
writing one file per option. It updates only the files for options
that have changed.
Flag Dependencies
Martin Von Loewis contributed another feature to this patch:
'flag dependencies'. The idea is that a .o file depends on
the compilation flags used to build it. The file foo.o has
its flags stored in .flags.foo.o.
Suppose the user changes the foo driver from resident to modular.
'make' will notice that the current foo.o was not compiled with
-DMODULE and will recompile foo.c.
All .o files made from C source have flag dependencies. So do .o
files made with ld, and .a files made with ar. However, .o files
made from assembly source do not have flag dependencies (nobody
needs this yet, but it would be good to fix).
Per-source-file Flags
Flag dependencies also work with per-source-file flags.
You can specify compilation flags for individual source files
like this:
CFLAGS_foo.o = -DSPECIAL_FOO_DEFINE
This helps clean up drivers/net/Makefile, drivers/scsi/Makefile,
and several other Makefiles.
Credit
Werner Almesberger had the original idea and wrote the first
version of this patch.
Michael Chastain picked it up and continued development. He is
now the principal author and maintainer. Please report any bugs
to him.
Martin von Loewis wrote flag dependencies, with some modifications
by Michael Chastain.
Thanks to all of the beta testers.

48
Documentation/sound/alsa/ALSA-Configuration.txt
View File

@ -284,6 +284,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
control correctly. If you have problems regarding this, try
another ALSA compliant mixer (alsamixer works).
Module snd-aw2
--------------
Module for Audiowerk2 sound card
This module supports multiple cards.
Module snd-azt2320
------------------
@ -788,6 +795,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
lg-lw LG LW20/LW25 laptop
tcl TCL S700
clevo Clevo laptops (m520G, m665n)
medion Medion Rim 2150
test for testing/debugging purpose, almost all controls can be
adjusted. Appearing only when compiled with
$CONFIG_SND_DEBUG=y
@ -818,19 +826,25 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
hippo_1 Hippo (Benq) with jack detection
sony-assamd Sony ASSAMD
ultra Samsung Q1 Ultra Vista model
lenovo-3000 Lenovo 3000 y410
basic fixed pin assignment w/o SPDIF
auto auto-config reading BIOS (default)
ALC268
ALC267/268
quanta-il1 Quanta IL1 mini-notebook
3stack 3-stack model
toshiba Toshiba A205
acer Acer laptops
dell Dell OEM laptops (Vostro 1200)
zepto Zepto laptops
test for testing/debugging purpose, almost all controls can
adjusted. Appearing only when compiled with
$CONFIG_SND_DEBUG=y
auto auto-config reading BIOS (default)
ALC269
basic Basic preset
ALC662
3stack-dig 3-stack (2-channel) with SPDIF
3stack-6ch 3-stack (6-channel)
@ -871,10 +885,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
lenovo-nb0763 Lenovo NB0763
lenovo-ms7195-dig Lenovo MS7195
haier-w66 Haier W66
6stack-hp HP machines with 6stack (Nettle boards)
3stack-hp HP machines with 3stack (Lucknow, Samba boards)
6stack-dell Dell machines with 6stack (Inspiron 530)
mitac Mitac 8252D
clevo-m720 Clevo M720 laptop series
fujitsu-pi2515 Fujitsu AMILO Pi2515
auto auto-config reading BIOS (default)
ALC861/660
@ -911,6 +926,12 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
3stack 3-stack mode (default)
6stack 6-stack mode
AD1884A / AD1883 / AD1984A / AD1984B
desktop 3-stack desktop (default)
laptop laptop with HP jack sensing
mobile mobile devices with HP jack sensing
thinkpad Lenovo Thinkpad X300
AD1884
N/A
@ -936,7 +957,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
laptop-automute 2-channel with EAPD and HP-automute (Lenovo N100)
ultra 2-channel with EAPD (Samsung Ultra tablet PC)
AD1988
AD1988/AD1988B/AD1989A/AD1989B
6stack 6-jack
6stack-dig ditto with SPDIF
3stack 3-jack
@ -979,6 +1000,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
dell-m26 Dell Inspiron 1501
dell-m27 Dell Inspiron E1705/9400
gateway Gateway laptops with EAPD control
panasonic Panasonic CF-74
STAC9205/9254
ref Reference board
@ -1017,6 +1039,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
3stack D965 3stack
5stack D965 5stack + SPDIF
dell-3stack Dell Dimension E520
dell-bios Fixes with Dell BIOS setup
STAC92HD71B*
ref Reference board
dell-m4-1 Dell desktops
dell-m4-2 Dell desktops
STAC92HD73*
ref Reference board
dell-m6 Dell desktops
STAC9872
vaio Setup for VAIO FE550G/SZ110
@ -1590,6 +1622,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
Power management is _not_ supported.
Module snd-pcsp
-----------------
Module for internal PC-Speaker.
nforce_wa - enable NForce chipset workaround. Expect bad sound.
This module supports system beeps, some kind of PCM playback and
even a few mixer controls.
Module snd-pcxhr
----------------

168
Documentation/spi/spidev
View File

@ -126,8 +126,8 @@ NOTES:
FULL DUPLEX CHARACTER DEVICE API
================================
See the sample program below for one example showing the use of the full
duplex programming interface. (Although it doesn't perform a full duplex
See the spidev_fdx.c sample program for one example showing the use of the
full duplex programming interface. (Although it doesn't perform a full duplex
transfer.) The model is the same as that used in the kernel spi_sync()
request; the individual transfers offer the same capabilities as are
available to kernel drivers (except that it's not asynchronous).
@ -141,167 +141,3 @@ and bitrate for each transfer segment.)
To make a full duplex request, provide both rx_buf and tx_buf for the
same transfer. It's even OK if those are the same buffer.
SAMPLE PROGRAM
==============
-------------------------------- CUT HERE
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <linux/types.h>
#include <linux/spi/spidev.h>
static int verbose;
static void do_read(int fd, int len)
{
unsigned char buf[32], *bp;
int status;
/* read at least 2 bytes, no more than 32 */
if (len < 2)
len = 2;
else if (len > sizeof(buf))
len = sizeof(buf);
memset(buf, 0, sizeof buf);
status = read(fd, buf, len);
if (status < 0) {
perror("read");
return;
}
if (status != len) {
fprintf(stderr, "short read\n");
return;
}
printf("read(%2d, %2d): %02x %02x,", len, status,
buf[0], buf[1]);
status -= 2;
bp = buf + 2;
while (status-- > 0)
printf(" %02x", *bp++);
printf("\n");
}
static void do_msg(int fd, int len)
{
struct spi_ioc_transfer xfer[2];
unsigned char buf[32], *bp;
int status;
memset(xfer, 0, sizeof xfer);
memset(buf, 0, sizeof buf);
if (len > sizeof buf)
len = sizeof buf;
buf[0] = 0xaa;
xfer[0].tx_buf = (__u64) buf;
xfer[0].len = 1;
xfer[1].rx_buf = (__u64) buf;
xfer[1].len = len;
status = ioctl(fd, SPI_IOC_MESSAGE(2), xfer);
if (status < 0) {
perror("SPI_IOC_MESSAGE");
return;
}
printf("response(%2d, %2d): ", len, status);
for (bp = buf; len; len--)
printf(" %02x", *bp++);
printf("\n");
}
static void dumpstat(const char *name, int fd)
{
__u8 mode, lsb, bits;
__u32 speed;
if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) {
perror("SPI rd_mode");
return;
}
if (ioctl(fd, SPI_IOC_RD_LSB_FIRST, &lsb) < 0) {
perror("SPI rd_lsb_fist");
return;
}
if (ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits) < 0) {
perror("SPI bits_per_word");
return;
}
if (ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed) < 0) {
perror("SPI max_speed_hz");
return;
}
printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n",
name, mode, bits, lsb ? "(lsb first) " : "", speed);
}
int main(int argc, char **argv)
{
int c;
int readcount = 0;
int msglen = 0;
int fd;
const char *name;
while ((c = getopt(argc, argv, "hm:r:v")) != EOF) {
switch (c) {
case 'm':
msglen = atoi(optarg);
if (msglen < 0)
goto usage;
continue;
case 'r':
readcount = atoi(optarg);
if (readcount < 0)
goto usage;
continue;
case 'v':
verbose++;
continue;
case 'h':
case '?':
usage:
fprintf(stderr,
"usage: %s [-h] [-m N] [-r N] /dev/spidevB.D\n",
argv[0]);
return 1;
}
}
if ((optind + 1) != argc)
goto usage;
name = argv[optind];
fd = open(name, O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
dumpstat(name, fd);
if (msglen)
do_msg(fd, msglen);
if (readcount)
do_read(fd, readcount);
close(fd);
return 0;
}

158
Documentation/spi/spidev_fdx.c Normal file
View File

@ -0,0 +1,158 @@
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <linux/types.h>
#include <linux/spi/spidev.h>
static int verbose;
static void do_read(int fd, int len)
{
unsigned char buf[32], *bp;
int status;
/* read at least 2 bytes, no more than 32 */
if (len < 2)
len = 2;
else if (len > sizeof(buf))
len = sizeof(buf);
memset(buf, 0, sizeof buf);
status = read(fd, buf, len);
if (status < 0) {
perror("read");
return;
}
if (status != len) {
fprintf(stderr, "short read\n");
return;
}
printf("read(%2d, %2d): %02x %02x,", len, status,
buf[0], buf[1]);
status -= 2;
bp = buf + 2;
while (status-- > 0)
printf(" %02x", *bp++);
printf("\n");
}
static void do_msg(int fd, int len)
{
struct spi_ioc_transfer xfer[2];
unsigned char buf[32], *bp;
int status;
memset(xfer, 0, sizeof xfer);
memset(buf, 0, sizeof buf);
if (len > sizeof buf)
len = sizeof buf;
buf[0] = 0xaa;
xfer[0].tx_buf = (__u64) buf;
xfer[0].len = 1;
xfer[1].rx_buf = (__u64) buf;
xfer[1].len = len;
status = ioctl(fd, SPI_IOC_MESSAGE(2), xfer);
if (status < 0) {
perror("SPI_IOC_MESSAGE");
return;
}
printf("response(%2d, %2d): ", len, status);
for (bp = buf; len; len--)
printf(" %02x", *bp++);
printf("\n");
}
static void dumpstat(const char *name, int fd)
{
__u8 mode, lsb, bits;
__u32 speed;
if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) {
perror("SPI rd_mode");
return;
}
if (ioctl(fd, SPI_IOC_RD_LSB_FIRST, &lsb) < 0) {
perror("SPI rd_lsb_fist");
return;
}
if (ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits) < 0) {
perror("SPI bits_per_word");
return;
}
if (ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed) < 0) {
perror("SPI max_speed_hz");
return;
}
printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n",
name, mode, bits, lsb ? "(lsb first) " : "", speed);
}
int main(int argc, char **argv)
{
int c;
int readcount = 0;
int msglen = 0;
int fd;
const char *name;
while ((c = getopt(argc, argv, "hm:r:v")) != EOF) {
switch (c) {
case 'm':
msglen = atoi(optarg);
if (msglen < 0)
goto usage;
continue;
case 'r':
readcount = atoi(optarg);
if (readcount < 0)
goto usage;
continue;
case 'v':
verbose++;
continue;
case 'h':
case '?':
usage:
fprintf(stderr,
"usage: %s [-h] [-m N] [-r N] /dev/spidevB.D\n",
argv[0]);
return 1;
}
}
if ((optind + 1) != argc)
goto usage;
name = argv[optind];
fd = open(name, O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
dumpstat(name, fd);
if (msglen)
do_msg(fd, msglen);
if (readcount)
do_read(fd, readcount);
close(fd);
return 0;
}

2
Documentation/sysrq.txt
View File

@ -85,6 +85,8 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
'k' - Secure Access Key (SAK) Kills all programs on the current virtual
console. NOTE: See important comments below in SAK section.
'l' - Shows a stack backtrace for all active CPUs.
'm' - Will dump current memory info to your console.
'n' - Used to make RT tasks nice-able

33
Documentation/thermal/sysfs-api.txt
View File

@ -108,10 +108,12 @@ and throttle appropriate devices.
RO read only value
RW read/write value
All thermal sysfs attributes will be represented under /sys/class/thermal
Thermal sysfs attributes will be represented under /sys/class/thermal.
Hwmon sysfs I/F extension is also available under /sys/class/hwmon
if hwmon is compiled in or built as a module.
Thermal zone device sys I/F, created once it's registered:
|thermal_zone[0-*]:
/sys/class/thermal/thermal_zone[0-*]:
|-----type: Type of the thermal zone
|-----temp: Current temperature
|-----mode: Working mode of the thermal zone
@ -119,7 +121,7 @@ Thermal zone device sys I/F, created once it's registered:
|-----trip_point_[0-*]_type: Trip point type
Thermal cooling device sys I/F, created once it's registered:
|cooling_device[0-*]:
/sys/class/thermal/cooling_device[0-*]:
|-----type : Type of the cooling device(processor/fan/...)
|-----max_state: Maximum cooling state of the cooling device
|-----cur_state: Current cooling state of the cooling device
@ -130,10 +132,19 @@ They represent the relationship between a thermal zone and its associated coolin
They are created/removed for each
thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful execution.
|thermal_zone[0-*]
/sys/class/thermal/thermal_zone[0-*]
|-----cdev[0-*]: The [0-*]th cooling device in the current thermal zone
|-----cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with
Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
the generic thermal driver also creates a hwmon sysfs I/F for each _type_ of
thermal zone device. E.g. the generic thermal driver registers one hwmon class device
and build the associated hwmon sysfs I/F for all the registered ACPI thermal zones.
/sys/class/hwmon/hwmon[0-*]:
|-----name: The type of the thermal zone devices.
|-----temp[1-*]_input: The current temperature of thermal zone [1-*].
|-----temp[1-*]_critical: The critical trip point of thermal zone [1-*].
Please read Documentation/hwmon/sysfs-interface for additional information.
***************************
* Thermal zone attributes *
@ -141,7 +152,10 @@ thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful e
type Strings which represent the thermal zone type.
This is given by thermal zone driver as part of registration.
Eg: "ACPI thermal zone" indicates it's a ACPI thermal device
Eg: "acpitz" indicates it's an ACPI thermal device.
In order to keep it consistent with hwmon sys attribute,
this should be a short, lowercase string,
not containing spaces nor dashes.
RO
Required
@ -218,7 +232,7 @@ the sys I/F structure will be built like this:
/sys/class/thermal:
|thermal_zone1:
|-----type: ACPI thermal zone
|-----type: acpitz
|-----temp: 37000
|-----mode: kernel
|-----trip_point_0_temp: 100000
@ -243,3 +257,10 @@ the sys I/F structure will be built like this:
|-----type: Fan
|-----max_state: 2
|-----cur_state: 0
/sys/class/hwmon:
|hwmon0:
|-----name: acpitz
|-----temp1_input: 37000
|-----temp1_crit: 100000

50
Documentation/usb/anchors.txt Normal file
View File

@ -0,0 +1,50 @@
What is anchor?
===============
A USB driver needs to support some callbacks requiring
a driver to cease all IO to an interface. To do so, a
driver has to keep track of the URBs it has submitted
to know they've all completed or to call usb_kill_urb
for them. The anchor is a data structure takes care of
keeping track of URBs and provides methods to deal with
multiple URBs.
Allocation and Initialisation
=============================
There's no API to allocate an anchor. It is simply declared
as struct usb_anchor. init_usb_anchor() must be called to
initialise the data structure.
Deallocation
============
Once it has no more URBs associated with it, the anchor can be
freed with normal memory management operations.
Association and disassociation of URBs with anchors
===================================================
An association of URBs to an anchor is made by an explicit
call to usb_anchor_urb(). The association is maintained until
an URB is finished by (successfull) completion. Thus disassociation
is automatic. A function is provided to forcibly finish (kill)
all URBs associated with an anchor.
Furthermore, disassociation can be made with usb_unanchor_urb()
Operations on multitudes of URBs
================================
usb_kill_anchored_urbs()
------------------------
This function kills all URBs associated with an anchor. The URBs
are called in the reverse temporal order they were submitted.
This way no data can be reordered.
usb_wait_anchor_empty_timeout()
-------------------------------
This function waits for all URBs associated with an anchor to finish
or a timeout, whichever comes first. Its return value will tell you
whether the timeout was reached.

132
Documentation/usb/callbacks.txt Normal file
View File

@ -0,0 +1,132 @@
What callbacks will usbcore do?
===============================
Usbcore will call into a driver through callbacks defined in the driver
structure and through the completion handler of URBs a driver submits.
Only the former are in the scope of this document. These two kinds of
callbacks are completely independent of each other. Information on the
completion callback can be found in Documentation/usb/URB.txt.
The callbacks defined in the driver structure are:
1. Hotplugging callbacks:
* @probe: Called to see if the driver is willing to manage a particular
* interface on a device.
* @disconnect: Called when the interface is no longer accessible, usually
* because its device has been (or is being) disconnected or the
* driver module is being unloaded.
2. Odd backdoor through usbfs:
* @ioctl: Used for drivers that want to talk to userspace through
* the "usbfs" filesystem. This lets devices provide ways to
* expose information to user space regardless of where they
* do (or don't) show up otherwise in the filesystem.
3. Power management (PM) callbacks:
* @suspend: Called when the device is going to be suspended.
* @resume: Called when the device is being resumed.
* @reset_resume: Called when the suspended device has been reset instead
* of being resumed.
4. Device level operations:
* @pre_reset: Called when the device is about to be reset.
* @post_reset: Called after the device has been reset
The ioctl interface (2) should be used only if you have a very good
reason. Sysfs is preferred these days. The PM callbacks are covered
separately in Documentation/usb/power-management.txt.
Calling conventions
===================
All callbacks are mutually exclusive. There's no need for locking
against other USB callbacks. All callbacks are called from a task
context. You may sleep. However, it is important that all sleeps have a
small fixed upper limit in time. In particular you must not call out to
user space and await results.
Hotplugging callbacks
=====================
These callbacks are intended to associate and disassociate a driver with
an interface. A driver's bond to an interface is exclusive.
The probe() callback
--------------------
int (*probe) (struct usb_interface *intf,
const struct usb_device_id *id);
Accept or decline an interface. If you accept the device return 0,
otherwise -ENODEV or -ENXIO. Other error codes should be used only if a
genuine error occurred during initialisation which prevented a driver
from accepting a device that would else have been accepted.
You are strongly encouraged to use usbcore'sfacility,
usb_set_intfdata(), to associate a data structure with an interface, so
that you know which internal state and identity you associate with a
particular interface. The device will not be suspended and you may do IO
to the interface you are called for and endpoint 0 of the device. Device
initialisation that doesn't take too long is a good idea here.
The disconnect() callback
-------------------------
void (*disconnect) (struct usb_interface *intf);
This callback is a signal to break any connection with an interface.
You are not allowed any IO to a device after returning from this
callback. You also may not do any other operation that may interfere
with another driver bound the interface, eg. a power management
operation.
If you are called due to a physical disconnection, all your URBs will be
killed by usbcore. Note that in this case disconnect will be called some
time after the physical disconnection. Thus your driver must be prepared
to deal with failing IO even prior to the callback.
Device level callbacks
======================
pre_reset
---------
int (*pre_reset)(struct usb_interface *intf);
Another driver or user space is triggering a reset on the device which
contains the interface passed as an argument. Cease IO and save any
device state you need to restore.
If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
are in atomic context.
post_reset
----------
int (*post_reset)(struct usb_interface *intf);
The reset has completed. Restore any saved device state and begin
using the device again.
If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
are in atomic context.
Call sequences
==============
No callbacks other than probe will be invoked for an interface
that isn't bound to your driver.
Probe will never be called for an interface bound to a driver.
Hence following a successful probe, disconnect will be called
before there is another probe for the same interface.
Once your driver is bound to an interface, disconnect can be
called at any time except in between pre_reset and post_reset.
pre_reset is always followed by post_reset, even if the reset
failed or the device has been unplugged.
suspend is always followed by one of: resume, reset_resume, or
disconnect.

43
Documentation/usb/persist.txt
View File

@ -2,7 +2,7 @@
Alan Stern <stern@rowland.harvard.edu>
September 2, 2006 (Updated May 29, 2007)
September 2, 2006 (Updated February 25, 2008)
What is the problem?
@ -65,9 +65,10 @@ much better.)
What is the solution?
Setting CONFIG_USB_PERSIST will cause the kernel to work around these
issues. It enables a mode in which the core USB device data
structures are allowed to persist across a power-session disruption.
The kernel includes a feature called USB-persist. It tries to work
around these issues by allowing the core USB device data structures to
persist across a power-session disruption.
It works like this. If the kernel sees that a USB host controller is
not in the expected state during resume (i.e., if the controller was
reset or otherwise had lost power) then it applies a persistence check
@ -80,28 +81,30 @@ re-enumeration shows that the device now attached to that port has the
same descriptors as before, including the Vendor and Product IDs, then
the kernel continues to use the same device structure. In effect, the
kernel treats the device as though it had merely been reset instead of
unplugged.
unplugged. The same thing happens if the host controller is in the
expected state but a USB device was unplugged and then replugged.
If no device is now attached to the port, or if the descriptors are
different from what the kernel remembers, then the treatment is what
you would expect. The kernel destroys the old device structure and
behaves as though the old device had been unplugged and a new device
plugged in, just as it would without the CONFIG_USB_PERSIST option.
plugged in.
The end result is that the USB device remains available and usable.
Filesystem mounts and memory mappings are unaffected, and the world is
now a good and happy place.
Note that even when CONFIG_USB_PERSIST is set, the "persist" feature
will be applied only to those devices for which it is enabled. You
can enable the feature by doing (as root):
Note that the "USB-persist" feature will be applied only to those
devices for which it is enabled. You can enable the feature by doing
(as root):
echo 1 >/sys/bus/usb/devices/.../power/persist
where the "..." should be filled in the with the device's ID. Disable
the feature by writing 0 instead of 1. For hubs the feature is
automatically and permanently enabled, so you only have to worry about
setting it for devices where it really matters.
automatically and permanently enabled and the power/persist file
doesn't even exist, so you only have to worry about setting it for
devices where it really matters.
Is this the best solution?
@ -112,19 +115,19 @@ centralized Logical Volume Manager. Such a solution would allow you
to plug in a USB flash device, create a persistent volume associated
with it, unplug the flash device, plug it back in later, and still
have the same persistent volume associated with the device. As such
it would be more far-reaching than CONFIG_USB_PERSIST.
it would be more far-reaching than USB-persist.
On the other hand, writing a persistent volume manager would be a big
job and using it would require significant input from the user. This
solution is much quicker and easier -- and it exists now, a giant
point in its favor!
Furthermore, the USB_PERSIST option applies to _all_ USB devices, not
Furthermore, the USB-persist feature applies to _all_ USB devices, not
just mass-storage devices. It might turn out to be equally useful for
other device types, such as network interfaces.
WARNING: Using CONFIG_USB_PERSIST can be dangerous!!
WARNING: USB-persist can be dangerous!!
When recovering an interrupted power session the kernel does its best
to make sure the USB device hasn't been changed; that is, the same
@ -133,10 +136,10 @@ aren't guaranteed to be 100% accurate.
If you replace one USB device with another of the same type (same
manufacturer, same IDs, and so on) there's an excellent chance the
kernel won't detect the change. Serial numbers and other strings are
not compared. In many cases it wouldn't help if they were, because
manufacturers frequently omit serial numbers entirely in their
devices.
kernel won't detect the change. The serial number string and other
descriptors are compared with the kernel's stored values, but this
might not help since manufacturers frequently omit serial numbers
entirely in their devices.
Furthermore it's quite possible to leave a USB device exactly the same
while changing its media. If you replace the flash memory card in a
@ -152,5 +155,5 @@ but yourself.
YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK!
That having been said, most of the time there shouldn't be any trouble
at all. The "persist" feature can be extremely useful. Make the most
of it.
at all. The USB-persist feature can be extremely useful. Make the
most of it.

7
Documentation/usb/usb-serial.txt
View File

@ -192,12 +192,9 @@ Keyspan USA-series Serial Adapters
FTDI Single Port Serial Driver
This is a single port DB-25 serial adapter. More information about this
device and the Linux driver can be found at:
http://reality.sgi.com/bryder_wellington/ftdi_sio/
This is a single port DB-25 serial adapter.
For any questions or problems with this driver, please contact Bill Ryder
at bryder@sgi.com
For any questions or problems with this driver, please contact Bill Ryder.
ZyXEL omni.net lcd plus ISDN TA

4
Documentation/video4linux/CARDLIST.au0828 Normal file
View File

@ -0,0 +1,4 @@
0 -> Unknown board (au0828)
1 -> Hauppauge HVR950Q (au0828) [2040:7200]
2 -> Hauppauge HVR850 (au0828) [2040:7240]
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]

2
Documentation/video4linux/CARDLIST.bttv
View File

@ -148,3 +148,5 @@
147 -> VoodooTV 200 (USA) [121a:3000]
148 -> DViCO FusionHDTV 2 [dbc0:d200]
149 -> Typhoon TV-Tuner PCI (50684)
150 -> Geovision GV-600 [008a:763c]
151 -> Kozumi KTV-01C

3
Documentation/video4linux/CARDLIST.cx23885
View File

@ -5,3 +5,6 @@
4 -> DViCO FusionHDTV5 Express [18ac:d500]
5 -> Hauppauge WinTV-HVR1500Q [0070:7790,0070:7797]
6 -> Hauppauge WinTV-HVR1500 [0070:7710,0070:7717]
7 -> Hauppauge WinTV-HVR1200 [0070:71d1]
8 -> Hauppauge WinTV-HVR1700 [0070:8101]
9 -> Hauppauge WinTV-HVR1400 [0070:8010]

9
Documentation/video4linux/CARDLIST.cx88
View File

@ -57,3 +57,12 @@
56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602]
57 -> ADS Tech Instant Video PCI [1421:0390]
58 -> Pinnacle PCTV HD 800i [11bd:0051]
59 -> DViCO FusionHDTV 5 PCI nano [18ac:d530]
60 -> Pinnacle Hybrid PCTV [12ab:1788]
61 -> Winfast TV2000 XP Global [107d:6f18]
62 -> PowerColor Real Angel 330 [14f1:ea3d]
63 -> Geniatech X8000-MT DVBT [14f1:8852]
64 -> DViCO FusionHDTV DVB-T PRO [18ac:db30]
65 -> DViCO FusionHDTV 7 Gold [18ac:d610]
66 -> Prolink Pixelview MPEG 8000GT [1554:4935]
67 -> Kworld PlusTV HD PCI 120 (ATSC 120) [17de:08c1]

16
Documentation/video4linux/CARDLIST.saa7134
View File

@ -25,8 +25,8 @@
24 -> KNC One TV-Station DVR [1894:a006]
25 -> ASUS TV-FM 7133 [1043:4843]
26 -> Pinnacle PCTV Stereo (saa7134) [11bd:002b]
27 -> Manli MuchTV M-TV002/Behold TV 403 FM
28 -> Manli MuchTV M-TV001/Behold TV 401
27 -> Manli MuchTV M-TV002
28 -> Manli MuchTV M-TV001
29 -> Nagase Sangyo TransGear 3000TV [1461:050c]
30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM) [1019:4cb4]
31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5]
@ -128,6 +128,16 @@
127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090]
128 -> Beholder BeholdTV Columbus TVFM [0000:5201]
129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093]
130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193]
130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193,5ace:6191]
131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
132 -> Genius TVGO AM11MCE
133 -> NXP Snake DVB-S reference design
134 -> Medion/Creatix CTX953 Hybrid [16be:0010]
135 -> MSI TV@nywhere A/D v1.1 [1462:8625]
136 -> AVerMedia Cardbus TV/Radio (E506R) [1461:f436]
137 -> AVerMedia Hybrid TV/Radio (A16D) [1461:f936]
138 -> Avermedia M115 [1461:a836]
139 -> Compro VideoMate T750 [185b:c900]
140 -> Avermedia DVB-S Pro A700 [1461:a7a1]
141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2]
142 -> Beholder BeholdTV H6 [5ace:6290]

34
Documentation/video4linux/cx18.txt Normal file
View File

@ -0,0 +1,34 @@
Some notes regarding the cx18 driver for the Conexant CX23418 MPEG
encoder chip:
1) The only hardware currently supported is the Hauppauge HVR-1600.
2) Some people have problems getting the i2c bus to work. Cause unknown.
The symptom is that the eeprom cannot be read and the card is
unusable.
3) The audio from the analog tuner is mono only. Probably caused by
incorrect audio register information in the datasheet. We are
waiting for updated information from Conexant.
4) VBI (raw or sliced) has not yet been implemented.
5) MPEG indexing is not yet implemented.
6) The driver is still a bit rough around the edges, this should
improve over time.
Firmware:
The firmware needs to be extracted from the Windows Hauppauge HVR-1600
driver, available here:
http://hauppauge.lightpath.net/software/install_cd/hauppauge_cd_3.4d1.zip
Unzip, then copy the following files to the firmware directory
and rename them as follows:
Drivers/Driver18/hcw18apu.rom -> v4l-cx23418-apu.fw
Drivers/Driver18/hcw18enc.rom -> v4l-cx23418-cpu.fw
Drivers/Driver18/hcw18mlC.rom -> v4l-cx23418-dig.fw

46
Documentation/video4linux/extract_xc3028.pl
View File

@ -686,11 +686,11 @@ sub main_firmware($$$$)
write_hunk(812664, 192);
#
# Firmware 58, type: SCODE FW HAS IF (0x60000000), IF = 4.50 MHz id: NTSC/M Jp (0000000000002000), size: 192
# Firmware 58, type: SCODE FW MTS LCD NOGD MONO IF HAS IF (0x6002b004), IF = 4.50 MHz id: NTSC PAL/M PAL/N (000000000000b700), size: 192
#
write_le32(0x60000000); # Type
write_le64(0x00000000, 0x00002000); # ID
write_le32(0x6002b004); # Type
write_le64(0x00000000, 0x0000b700); # ID
write_le16(4500); # IF
write_le32(192); # Size
write_hunk(807672, 192);
@ -706,10 +706,10 @@ sub main_firmware($$$$)
write_hunk(807864, 192);
#
# Firmware 60, type: SCODE FW DTV78 ZARLINK456 HAS IF (0x62000100), IF = 4.76 MHz id: (0000000000000000), size: 192
# Firmware 60, type: SCODE FW DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 HAS IF (0x620003e0), IF = 4.76 MHz id: (0000000000000000), size: 192
#
write_le32(0x62000100); # Type
write_le32(0x620003e0); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(4760); # IF
write_le32(192); # Size
@ -726,30 +726,30 @@ sub main_firmware($$$$)
write_hunk(811512, 192);
#
# Firmware 62, type: SCODE FW DTV7 ZARLINK456 HAS IF (0x62000080), IF = 5.26 MHz id: (0000000000000000), size: 192
# Firmware 62, type: SCODE FW HAS IF (0x60000000), IF = 5.26 MHz id: (0000000000000000), size: 192
#
write_le32(0x62000080); # Type
write_le32(0x60000000); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(5260); # IF
write_le32(192); # Size
write_hunk(810552, 192);
#
# Firmware 63, type: SCODE FW MONO HAS IF (0x60008000), IF = 5.32 MHz id: PAL/BG NICAM/B (0000000800000007), size: 192
# Firmware 63, type: SCODE FW MONO HAS IF (0x60008000), IF = 5.32 MHz id: PAL/BG A2 NICAM (0000000f00000007), size: 192
#
write_le32(0x60008000); # Type
write_le64(0x00000008, 0x00000007); # ID
write_le64(0x0000000f, 0x00000007); # ID
write_le16(5320); # IF
write_le32(192); # Size
write_hunk(810744, 192);
#
# Firmware 64, type: SCODE FW DTV8 CHINA HAS IF (0x64000200), IF = 5.40 MHz id: (0000000000000000), size: 192
# Firmware 64, type: SCODE FW DTV7 DTV78 DTV8 DIBCOM52 CHINA HAS IF (0x65000380), IF = 5.40 MHz id: (0000000000000000), size: 192
#
write_le32(0x64000200); # Type
write_le32(0x65000380); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(5400); # IF
write_le32(192); # Size
@ -766,50 +766,50 @@ sub main_firmware($$$$)
write_hunk(809592, 192);
#
# Firmware 66, type: SCODE FW HAS IF (0x60000000), IF = 5.64 MHz id: PAL/BG A2/B (0000000200000007), size: 192
# Firmware 66, type: SCODE FW HAS IF (0x60000000), IF = 5.64 MHz id: PAL/BG A2 (0000000300000007), size: 192
#
write_le32(0x60000000); # Type
write_le64(0x00000002, 0x00000007); # ID
write_le64(0x00000003, 0x00000007); # ID
write_le16(5640); # IF
write_le32(192); # Size
write_hunk(808440, 192);
#
# Firmware 67, type: SCODE FW HAS IF (0x60000000), IF = 5.74 MHz id: PAL/BG NICAM/B (0000000800000007), size: 192
# Firmware 67, type: SCODE FW HAS IF (0x60000000), IF = 5.74 MHz id: PAL/BG NICAM (0000000c00000007), size: 192
#
write_le32(0x60000000); # Type
write_le64(0x00000008, 0x00000007); # ID
write_le64(0x0000000c, 0x00000007); # ID
write_le16(5740); # IF
write_le32(192); # Size
write_hunk(808632, 192);
#
# Firmware 68, type: SCODE FW DTV7 DIBCOM52 HAS IF (0x61000080), IF = 5.90 MHz id: (0000000000000000), size: 192
# Firmware 68, type: SCODE FW HAS IF (0x60000000), IF = 5.90 MHz id: (0000000000000000), size: 192
#
write_le32(0x61000080); # Type
write_le32(0x60000000); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(5900); # IF
write_le32(192); # Size
write_hunk(810360, 192);
#
# Firmware 69, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.00 MHz id: PAL/I (0000000000000010), size: 192
# Firmware 69, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.00 MHz id: PAL/DK PAL/I SECAM/K3 SECAM/L SECAM/Lc NICAM (0000000c04c000f0), size: 192
#
write_le32(0x60008000); # Type
write_le64(0x00000000, 0x00000010); # ID
write_le64(0x0000000c, 0x04c000f0); # ID
write_le16(6000); # IF
write_le32(192); # Size
write_hunk(808824, 192);
#
# Firmware 70, type: SCODE FW DTV6 QAM F6MHZ HAS IF (0x68000060), IF = 6.20 MHz id: (0000000000000000), size: 192
# Firmware 70, type: SCODE FW DTV6 QAM ATSC LG60 F6MHZ HAS IF (0x68050060), IF = 6.20 MHz id: (0000000000000000), size: 192
#
write_le32(0x68000060); # Type
write_le32(0x68050060); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(6200); # IF
write_le32(192); # Size
@ -846,11 +846,11 @@ sub main_firmware($$$$)
write_hunk(809208, 192);
#
# Firmware 74, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.50 MHz id: SECAM/K3 (0000000004000000), size: 192
# Firmware 74, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.50 MHz id: PAL/DK SECAM/K3 SECAM/L NICAM (0000000c044000e0), size: 192
#
write_le32(0x60008000); # Type
write_le64(0x00000000, 0x04000000); # ID
write_le64(0x0000000c, 0x044000e0); # ID
write_le16(6500); # IF
write_le32(192); # Size
write_hunk(811128, 192);

279
Documentation/vm/numa_memory_policy.txt
View File

@ -135,77 +135,58 @@ most general to most specific:
Components of Memory Policies
A Linux memory policy is a tuple consisting of a "mode" and an optional set
of nodes. The mode determine the behavior of the policy, while the
optional set of nodes can be viewed as the arguments to the behavior.
A Linux memory policy consists of a "mode", optional mode flags, and an
optional set of nodes. The mode determines the behavior of the policy,
the optional mode flags determine the behavior of the mode, and the
optional set of nodes can be viewed as the arguments to the policy
behavior.
Internally, memory policies are implemented by a reference counted
structure, struct mempolicy. Details of this structure will be discussed
in context, below, as required to explain the behavior.
Note: in some functions AND in the struct mempolicy itself, the mode
is called "policy". However, to avoid confusion with the policy tuple,
this document will continue to use the term "mode".
Linux memory policy supports the following 4 behavioral modes:
Default Mode--MPOL_DEFAULT: The behavior specified by this mode is
context or scope dependent.
Default Mode--MPOL_DEFAULT: This mode is only used in the memory
policy APIs. Internally, MPOL_DEFAULT is converted to the NULL
memory policy in all policy scopes. Any existing non-default policy
will simply be removed when MPOL_DEFAULT is specified. As a result,
MPOL_DEFAULT means "fall back to the next most specific policy scope."
As mentioned in the Policy Scope section above, during normal
system operation, the System Default Policy is hard coded to
contain the Default mode.
For example, a NULL or default task policy will fall back to the
system default policy. A NULL or default vma policy will fall
back to the task policy.
In this context, default mode means "local" allocation--that is
attempt to allocate the page from the node associated with the cpu
where the fault occurs. If the "local" node has no memory, or the
node's memory can be exhausted [no free pages available], local
allocation will "fallback to"--attempt to allocate pages from--
"nearby" nodes, in order of increasing "distance".
When specified in one of the memory policy APIs, the Default mode
does not use the optional set of nodes.
Implementation detail -- subject to change: "Fallback" uses
a per node list of sibling nodes--called zonelists--built at
boot time, or when nodes or memory are added or removed from
the system [memory hotplug]. These per node zonelist are
constructed with nodes in order of increasing distance based
on information provided by the platform firmware.
When a task/process policy or a shared policy contains the Default
mode, this also means "local allocation", as described above.
In the context of a VMA, Default mode means "fall back to task
policy"--which may or may not specify Default mode. Thus, Default
mode can not be counted on to mean local allocation when used
on a non-shared region of the address space. However, see
MPOL_PREFERRED below.
The Default mode does not use the optional set of nodes.
It is an error for the set of nodes specified for this policy to
be non-empty.
MPOL_BIND: This mode specifies that memory must come from the
set of nodes specified by the policy.
The memory policy APIs do not specify an order in which the nodes
will be searched. However, unlike "local allocation", the Bind
policy does not consider the distance between the nodes. Rather,
allocations will fallback to the nodes specified by the policy in
order of numeric node id. Like everything in Linux, this is subject
to change.
set of nodes specified by the policy. Memory will be allocated from
the node in the set with sufficient free memory that is closest to
the node where the allocation takes place.
MPOL_PREFERRED: This mode specifies that the allocation should be
attempted from the single node specified in the policy. If that
allocation fails, the kernel will search other nodes, exactly as
it would for a local allocation that started at the preferred node
in increasing distance from the preferred node. "Local" allocation
policy can be viewed as a Preferred policy that starts at the node
allocation fails, the kernel will search other nodes, in order of
increasing distance from the preferred node based on information
provided by the platform firmware.
containing the cpu where the allocation takes place.
Internally, the Preferred policy uses a single node--the
preferred_node member of struct mempolicy. A "distinguished
value of this preferred_node, currently '-1', is interpreted
as "the node containing the cpu where the allocation takes
place"--local allocation. This is the way to specify
local allocation for a specific range of addresses--i.e. for
VMA policies.
preferred_node member of struct mempolicy. When the internal
mode flag MPOL_F_LOCAL is set, the preferred_node is ignored and
the policy is interpreted as local allocation. "Local" allocation
policy can be viewed as a Preferred policy that starts at the node
containing the cpu where the allocation takes place.
It is possible for the user to specify that local allocation is
always preferred by passing an empty nodemask with this mode.
If an empty nodemask is passed, the policy cannot use the
MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES flags described
below.
MPOL_INTERLEAVED: This mode specifies that page allocations be
interleaved, on a page granularity, across the nodes specified in
@ -231,6 +212,154 @@ Components of Memory Policies
the temporary interleaved system default policy works in this
mode.
Linux memory policy supports the following optional mode flags:
MPOL_F_STATIC_NODES: This flag specifies that the nodemask passed by
the user should not be remapped if the task or VMA's set of allowed
nodes changes after the memory policy has been defined.
Without this flag, anytime a mempolicy is rebound because of a
change in the set of allowed nodes, the node (Preferred) or
nodemask (Bind, Interleave) is remapped to the new set of
allowed nodes. This may result in nodes being used that were
previously undesired.
With this flag, if the user-specified nodes overlap with the
nodes allowed by the task's cpuset, then the memory policy is
applied to their intersection. If the two sets of nodes do not
overlap, the Default policy is used.
For example, consider a task that is attached to a cpuset with
mems 1-3 that sets an Interleave policy over the same set. If
the cpuset's mems change to 3-5, the Interleave will now occur
over nodes 3, 4, and 5. With this flag, however, since only node
3 is allowed from the user's nodemask, the "interleave" only
occurs over that node. If no nodes from the user's nodemask are
now allowed, the Default behavior is used.
MPOL_F_STATIC_NODES cannot be combined with the
MPOL_F_RELATIVE_NODES flag. It also cannot be used for
MPOL_PREFERRED policies that were created with an empty nodemask
(local allocation).
MPOL_F_RELATIVE_NODES: This flag specifies that the nodemask passed
by the user will be mapped relative to the set of the task or VMA's
set of allowed nodes. The kernel stores the user-passed nodemask,
and if the allowed nodes changes, then that original nodemask will
be remapped relative to the new set of allowed nodes.
Without this flag (and without MPOL_F_STATIC_NODES), anytime a
mempolicy is rebound because of a change in the set of allowed
nodes, the node (Preferred) or nodemask (Bind, Interleave) is
remapped to the new set of allowed nodes. That remap may not
preserve the relative nature of the user's passed nodemask to its
set of allowed nodes upon successive rebinds: a nodemask of
1,3,5 may be remapped to 7-9 and then to 1-3 if the set of
allowed nodes is restored to its original state.
With this flag, the remap is done so that the node numbers from
the user's passed nodemask are relative to the set of allowed
nodes. In other words, if nodes 0, 2, and 4 are set in the user's
nodemask, the policy will be effected over the first (and in the
Bind or Interleave case, the third and fifth) nodes in the set of
allowed nodes. The nodemask passed by the user represents nodes
relative to task or VMA's set of allowed nodes.
If the user's nodemask includes nodes that are outside the range
of the new set of allowed nodes (for example, node 5 is set in
the user's nodemask when the set of allowed nodes is only 0-3),
then the remap wraps around to the beginning of the nodemask and,
if not already set, sets the node in the mempolicy nodemask.
For example, consider a task that is attached to a cpuset with
mems 2-5 that sets an Interleave policy over the same set with
MPOL_F_RELATIVE_NODES. If the cpuset's mems change to 3-7, the
interleave now occurs over nodes 3,5-6. If the cpuset's mems
then change to 0,2-3,5, then the interleave occurs over nodes
0,3,5.
Thanks to the consistent remapping, applications preparing
nodemasks to specify memory policies using this flag should
disregard their current, actual cpuset imposed memory placement
and prepare the nodemask as if they were always located on
memory nodes 0 to N-1, where N is the number of memory nodes the
policy is intended to manage. Let the kernel then remap to the
set of memory nodes allowed by the task's cpuset, as that may
change over time.
MPOL_F_RELATIVE_NODES cannot be combined with the
MPOL_F_STATIC_NODES flag. It also cannot be used for
MPOL_PREFERRED policies that were created with an empty nodemask
(local allocation).
MEMORY POLICY REFERENCE COUNTING
To resolve use/free races, struct mempolicy contains an atomic reference
count field. Internal interfaces, mpol_get()/mpol_put() increment and
decrement this reference count, respectively. mpol_put() will only free
the structure back to the mempolicy kmem cache when the reference count
goes to zero.
When a new memory policy is allocated, it's reference count is initialized
to '1', representing the reference held by the task that is installing the
new policy. When a pointer to a memory policy structure is stored in another
structure, another reference is added, as the task's reference will be dropped
on completion of the policy installation.
During run-time "usage" of the policy, we attempt to minimize atomic operations
on the reference count, as this can lead to cache lines bouncing between cpus
and NUMA nodes. "Usage" here means one of the following:
1) querying of the policy, either by the task itself [using the get_mempolicy()
API discussed below] or by another task using the /proc/<pid>/numa_maps
interface.
2) examination of the policy to determine the policy mode and associated node
or node lists, if any, for page allocation. This is considered a "hot
path". Note that for MPOL_BIND, the "usage" extends across the entire
allocation process, which may sleep during page reclaimation, because the
BIND policy nodemask is used, by reference, to filter ineligible nodes.
We can avoid taking an extra reference during the usages listed above as
follows:
1) we never need to get/free the system default policy as this is never
changed nor freed, once the system is up and running.
2) for querying the policy, we do not need to take an extra reference on the
target task's task policy nor vma policies because we always acquire the
task's mm's mmap_sem for read during the query. The set_mempolicy() and
mbind() APIs [see below] always acquire the mmap_sem for write when
installing or replacing task or vma policies. Thus, there is no possibility
of a task or thread freeing a policy while another task or thread is
querying it.
3) Page allocation usage of task or vma policy occurs in the fault path where
we hold them mmap_sem for read. Again, because replacing the task or vma
policy requires that the mmap_sem be held for write, the policy can't be
freed out from under us while we're using it for page allocation.
4) Shared policies require special consideration. One task can replace a
shared memory policy while another task, with a distinct mmap_sem, is
querying or allocating a page based on the policy. To resolve this
potential race, the shared policy infrastructure adds an extra reference
to the shared policy during lookup while holding a spin lock on the shared
policy management structure. This requires that we drop this extra
reference when we're finished "using" the policy. We must drop the
extra reference on shared policies in the same query/allocation paths
used for non-shared policies. For this reason, shared policies are marked
as such, and the extra reference is dropped "conditionally"--i.e., only
for shared policies.
Because of this extra reference counting, and because we must lookup
shared policies in a tree structure under spinlock, shared policies are
more expensive to use in the page allocation path. This is expecially
true for shared policies on shared memory regions shared by tasks running
on different NUMA nodes. This extra overhead can be avoided by always
falling back to task or system default policy for shared memory regions,
or by prefaulting the entire shared memory region into memory and locking
it down. However, this might not be appropriate for all applications.
MEMORY POLICY APIs
Linux supports 3 system calls for controlling memory policy. These APIS
@ -251,7 +380,9 @@ Set [Task] Memory Policy:
Set's the calling task's "task/process memory policy" to mode
specified by the 'mode' argument and the set of nodes defined
by 'nmask'. 'nmask' points to a bit mask of node ids containing
at least 'maxnode' ids.
at least 'maxnode' ids. Optional mode flags may be passed by
combining the 'mode' argument with the flag (for example:
MPOL_INTERLEAVE | MPOL_F_STATIC_NODES).
See the set_mempolicy(2) man page for more details
@ -303,29 +434,19 @@ MEMORY POLICIES AND CPUSETS
Memory policies work within cpusets as described above. For memory policies
that require a node or set of nodes, the nodes are restricted to the set of
nodes whose memories are allowed by the cpuset constraints. If the nodemask
specified for the policy contains nodes that are not allowed by the cpuset, or
the intersection of the set of nodes specified for the policy and the set of
nodes with memory is the empty set, the policy is considered invalid
and cannot be installed.
specified for the policy contains nodes that are not allowed by the cpuset and
MPOL_F_RELATIVE_NODES is not used, the intersection of the set of nodes
specified for the policy and the set of nodes with memory is used. If the
result is the empty set, the policy is considered invalid and cannot be
installed. If MPOL_F_RELATIVE_NODES is used, the policy's nodes are mapped
onto and folded into the task's set of allowed nodes as previously described.
The interaction of memory policies and cpusets can be problematic for a
couple of reasons:
1) the memory policy APIs take physical node id's as arguments. As mentioned
above, it is illegal to specify nodes that are not allowed in the cpuset.
The application must query the allowed nodes using the get_mempolicy()
API with the MPOL_F_MEMS_ALLOWED flag to determine the allowed nodes and
restrict itself to those nodes. However, the resources available to a
cpuset can be changed by the system administrator, or a workload manager
application, at any time. So, a task may still get errors attempting to
specify policy nodes, and must query the allowed memories again.
2) when tasks in two cpusets share access to a memory region, such as shared
memory segments created by shmget() of mmap() with the MAP_ANONYMOUS and
MAP_SHARED flags, and any of the tasks install shared policy on the region,
only nodes whose memories are allowed in both cpusets may be used in the
policies. Obtaining this information requires "stepping outside" the
memory policy APIs to use the cpuset information and requires that one
know in what cpusets other task might be attaching to the shared region.
Furthermore, if the cpusets' allowed memory sets are disjoint, "local"
allocation is the only valid policy.
The interaction of memory policies and cpusets can be problematic when tasks
in two cpusets share access to a memory region, such as shared memory segments
created by shmget() of mmap() with the MAP_ANONYMOUS and MAP_SHARED flags, and
any of the tasks install shared policy on the region, only nodes whose
memories are allowed in both cpusets may be used in the policies. Obtaining
this information requires "stepping outside" the memory policy APIs to use the
cpuset information and requires that one know in what cpusets other task might
be attaching to the shared region. Furthermore, if the cpusets' allowed
memory sets are disjoint, "local" allocation is the only valid policy.

37
Documentation/vm/slabinfo.c
View File

@ -31,14 +31,14 @@ struct slabinfo {
int hwcache_align, object_size, objs_per_slab;
int sanity_checks, slab_size, store_user, trace;
int order, poison, reclaim_account, red_zone;
unsigned long partial, objects, slabs;
unsigned long partial, objects, slabs, objects_partial, objects_total;
unsigned long alloc_fastpath, alloc_slowpath;
unsigned long free_fastpath, free_slowpath;
unsigned long free_frozen, free_add_partial, free_remove_partial;
unsigned long alloc_from_partial, alloc_slab, free_slab, alloc_refill;
unsigned long cpuslab_flush, deactivate_full, deactivate_empty;
unsigned long deactivate_to_head, deactivate_to_tail;
unsigned long deactivate_remote_frees;
unsigned long deactivate_remote_frees, order_fallback;
int numa[MAX_NODES];
int numa_partial[MAX_NODES];
} slabinfo[MAX_SLABS];
@ -293,7 +293,7 @@ int line = 0;
void first_line(void)
{
if (show_activity)
printf("Name Objects Alloc Free %%Fast\n");
printf("Name Objects Alloc Free %%Fast Fallb O\n");
else
printf("Name Objects Objsize Space "
"Slabs/Part/Cpu O/S O %%Fr %%Ef Flg\n");
@ -540,7 +540,8 @@ void slabcache(struct slabinfo *s)
return;
store_size(size_str, slab_size(s));
snprintf(dist_str, 40, "%lu/%lu/%d", s->slabs, s->partial, s->cpu_slabs);
snprintf(dist_str, 40, "%lu/%lu/%d", s->slabs - s->cpu_slabs,
s->partial, s->cpu_slabs);
if (!line++)
first_line();
@ -572,11 +573,12 @@ void slabcache(struct slabinfo *s)
total_alloc = s->alloc_fastpath + s->alloc_slowpath;
total_free = s->free_fastpath + s->free_slowpath;
printf("%-21s %8ld %8ld %8ld %3ld %3ld \n",
printf("%-21s %8ld %10ld %10ld %3ld %3ld %5ld %1d\n",
s->name, s->objects,
total_alloc, total_free,
total_alloc ? (s->alloc_fastpath * 100 / total_alloc) : 0,
total_free ? (s->free_fastpath * 100 / total_free) : 0);
total_free ? (s->free_fastpath * 100 / total_free) : 0,
s->order_fallback, s->order);
}
else
printf("%-21s %8ld %7d %8s %14s %4d %1d %3ld %3ld %s\n",
@ -776,7 +778,6 @@ void totals(void)
unsigned long used;
unsigned long long wasted;
unsigned long long objwaste;
long long objects_in_partial_slabs;
unsigned long percentage_partial_slabs;
unsigned long percentage_partial_objs;
@ -790,18 +791,11 @@ void totals(void)
wasted = size - used;
objwaste = s->slab_size - s->object_size;
objects_in_partial_slabs = s->objects -
(s->slabs - s->partial - s ->cpu_slabs) *
s->objs_per_slab;
if (objects_in_partial_slabs < 0)
objects_in_partial_slabs = 0;
percentage_partial_slabs = s->partial * 100 / s->slabs;
if (percentage_partial_slabs > 100)
percentage_partial_slabs = 100;
percentage_partial_objs = objects_in_partial_slabs * 100
percentage_partial_objs = s->objects_partial * 100
/ s->objects;
if (percentage_partial_objs > 100)
@ -823,8 +817,8 @@ void totals(void)
min_objects = s->objects;
if (used < min_used)
min_used = used;
if (objects_in_partial_slabs < min_partobj)
min_partobj = objects_in_partial_slabs;
if (s->objects_partial < min_partobj)
min_partobj = s->objects_partial;
if (percentage_partial_slabs < min_ppart)
min_ppart = percentage_partial_slabs;
if (percentage_partial_objs < min_ppartobj)
@ -848,8 +842,8 @@ void totals(void)
max_objects = s->objects;
if (used > max_used)
max_used = used;
if (objects_in_partial_slabs > max_partobj)
max_partobj = objects_in_partial_slabs;
if (s->objects_partial > max_partobj)
max_partobj = s->objects_partial;
if (percentage_partial_slabs > max_ppart)
max_ppart = percentage_partial_slabs;
if (percentage_partial_objs > max_ppartobj)
@ -864,7 +858,7 @@ void totals(void)
total_objects += s->objects;
total_used += used;
total_partobj += objects_in_partial_slabs;
total_partobj += s->objects_partial;
total_ppart += percentage_partial_slabs;
total_ppartobj += percentage_partial_objs;
@ -1160,6 +1154,8 @@ void read_slab_dir(void)
slab->hwcache_align = get_obj("hwcache_align");
slab->object_size = get_obj("object_size");
slab->objects = get_obj("objects");
slab->objects_partial = get_obj("objects_partial");
slab->objects_total = get_obj("objects_total");
slab->objs_per_slab = get_obj("objs_per_slab");
slab->order = get_obj("order");
slab->partial = get_obj("partial");
@ -1193,6 +1189,7 @@ void read_slab_dir(void)
slab->deactivate_to_head = get_obj("deactivate_to_head");
slab->deactivate_to_tail = get_obj("deactivate_to_tail");
slab->deactivate_remote_frees = get_obj("deactivate_remote_frees");
slab->order_fallback = get_obj("order_fallback");
chdir("..");
if (slab->name[0] == ':')
alias_targets++;

62
Kbuild
View File

@ -1,26 +1,61 @@
#
# Kbuild for top-level directory of the kernel
# This file takes care of the following:
# 1) Generate asm-offsets.h
# 2) Check for missing system calls
# 1) Generate bounds.h
# 2) Generate asm-offsets.h (may need bounds.h)
# 3) Check for missing system calls
#####
# 1) Generate asm-offsets.h
# 1) Generate bounds.h
bounds-file := include/linux/bounds.h
always := $(bounds-file)
targets := $(bounds-file) kernel/bounds.s
quiet_cmd_bounds = GEN $@
define cmd_bounds
(set -e; \
echo "#ifndef __LINUX_BOUNDS_H__"; \
echo "#define __LINUX_BOUNDS_H__"; \
echo "/*"; \
echo " * DO NOT MODIFY."; \
echo " *"; \
echo " * This file was generated by Kbuild"; \
echo " *"; \
echo " */"; \
echo ""; \
sed -ne $(sed-y) $<; \
echo ""; \
echo "#endif" ) > $@
endef
# We use internal kbuild rules to avoid the "is up to date" message from make
kernel/bounds.s: kernel/bounds.c FORCE
$(Q)mkdir -p $(dir $@)
$(call if_changed_dep,cc_s_c)
$(obj)/$(bounds-file): kernel/bounds.s Kbuild
$(Q)mkdir -p $(dir $@)
$(call cmd,bounds)
#####
# 2) Generate asm-offsets.h
#
offsets-file := include/asm-$(SRCARCH)/asm-offsets.h
always := $(offsets-file)
targets := $(offsets-file)
always += $(offsets-file)
targets += $(offsets-file)
targets += arch/$(SRCARCH)/kernel/asm-offsets.s
clean-files := $(addprefix $(objtree)/,$(targets))
# Default sed regexp - multiline due to syntax constraints
define sed-y
"/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; p;}"
"/^->/{s:->#\(.*\):/* \1 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}"
endef
# Override default regexp for specific architectures
sed-$(CONFIG_MIPS) := "/^@@@/{s/^@@@//; s/ \#.*\$$//; p;}"
quiet_cmd_offsets = GEN $@
define cmd_offsets
@ -40,7 +75,8 @@ define cmd_offsets
endef
# We use internal kbuild rules to avoid the "is up to date" message from make
arch/$(SRCARCH)/kernel/asm-offsets.s: arch/$(SRCARCH)/kernel/asm-offsets.c FORCE
arch/$(SRCARCH)/kernel/asm-offsets.s: arch/$(SRCARCH)/kernel/asm-offsets.c \
$(obj)/$(bounds-file) FORCE
$(Q)mkdir -p $(dir $@)
$(call if_changed_dep,cc_s_c)
@ -49,7 +85,7 @@ $(obj)/$(offsets-file): arch/$(SRCARCH)/kernel/asm-offsets.s Kbuild
$(call cmd,offsets)
#####
# 2) Check for missing system calls
# 3) Check for missing system calls
#
quiet_cmd_syscalls = CALL $<
@ -58,3 +94,7 @@ quiet_cmd_syscalls = CALL $<
PHONY += missing-syscalls
missing-syscalls: scripts/checksyscalls.sh FORCE
$(call cmd,syscalls)
# Delete all targets during make clean
clean-files := $(addprefix $(objtree)/,$(targets))

227
MAINTAINERS
View File

@ -752,11 +752,13 @@ W: http://atmelwlandriver.sourceforge.net/
S: Maintained
AUDIT SUBSYSTEM
P: David Woodhouse
M: dwmw2@infradead.org
P: Al Viro
M: viro@zeniv.linux.org.uk
P: Eric Paris
M: eparis@redhat.com
L: linux-audit@redhat.com (subscribers-only)
W: http://people.redhat.com/sgrubb/audit/
T: git kernel.org:/pub/scm/linux/kernel/git/dwmw2/audit-2.6.git
T: git git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git
S: Maintained
AUXILIARY DISPLAY DRIVERS
@ -1037,7 +1039,7 @@ P: Urs Thuermann
M: urs.thuermann@volkswagen.de
P: Oliver Hartkopp
M: oliver.hartkopp@volkswagen.de
L: socketcan-core@lists.berlios.de
L: socketcan-core@lists.berlios.de (subscribers-only)
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
@ -1106,6 +1108,12 @@ M: kernel@wantstofly.org
L: linux-usb@vger.kernel.org
S: Maintained
CIRRUS LOGIC CS4270 SOUND DRIVER
P: Timur Tabi
M: timur@freescale.com
L: alsa-devel@alsa-project.org
S: Supported
CIRRUS LOGIC CS4280/CS461x SOUNDDRIVER
P: Cirrus Logic Corporation (kernel 2.2 driver)
M: Cirrus Logic Corporation, Thomas Woller <twoller@crystal.cirrus.com>
@ -1188,9 +1196,9 @@ S: Maintained
CPUSETS
P: Paul Jackson
P: Simon Derr
P: Paul Menage
M: pj@sgi.com
M: simon.derr@bull.net
M: menage@google.com
L: linux-kernel@vger.kernel.org
W: http://www.bullopensource.org/cpuset/
S: Supported
@ -1525,6 +1533,13 @@ L: bluesmoke-devel@lists.sourceforge.net
W: bluesmoke.sourceforge.net
S: Maintained
EEEPC LAPTOP EXTRAS DRIVER
P: Corentin Chary
M: corentincj@iksaif.net
L: acpi4asus-user@lists.sourceforge.net
W: http://sourceforge.net/projects/acpi4asus
S: Maintained
EEPRO100 NETWORK DRIVER
P: Andrey V. Savochkin
M: saw@saw.sw.com.sg
@ -1542,6 +1557,14 @@ M: raisch@de.ibm.com
L: general@lists.openfabrics.org
S: Supported
EMBEDDED LINUX
P: Paul Gortmaker
M: paul.gortmaker@windriver.com
P David Woodhouse
M: dwmw2@infradead.org
L: linux-embedded@vger.kernel.org
S: Maintained
EMULEX LPFC FC SCSI DRIVER
P: James Smart
M: james.smart@emulex.com
@ -1628,6 +1651,12 @@ L: linuxppc-dev@ozlabs.org
L: netdev@vger.kernel.org
S: Maintained
FREESCALE QUICC ENGINE LIBRARY
P: Timur Tabi
M: timur@freescale.com
L: linuxppc-dev@ozlabs.org
S: Supported
FREESCALE HIGHSPEED USB DEVICE DRIVER
P: Li Yang
M: leoli@freescale.com
@ -1642,6 +1671,19 @@ L: netdev@vger.kernel.org
L: linuxppc-dev@ozlabs.org
S: Maintained
FREESCALE QUICC ENGINE UCC UART DRIVER
P: Timur Tabi
M: timur@freescale.com
L: linuxppc-dev@ozlabs.org
S: Supported
FREESCALE SOC SOUND DRIVERS
P: Timur Tabi
M: timur@freescale.com
L: alsa-devel@alsa-project.org
L: linuxppc-dev@ozlabs.org
S: Supported
FILE LOCKING (flock() and fcntl()/lockf())
P: Matthew Wilcox
M: matthew@wil.cx
@ -2304,6 +2346,13 @@ L: kvm-devel@lists.sourceforge.net
W: kvm.sourceforge.net
S: Supported
KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC
P: Hollis Blanchard
M: hollisb@us.ibm.com
L: kvm-ppc-devel@lists.sourceforge.net
W: kvm.sourceforge.net
S: Supported
KERNEL VIRTUAL MACHINE For Itanium(KVM/IA64)
P: Anthony Xu
M: anthony.xu@intel.com
@ -2313,6 +2362,16 @@ L: kvm-ia64-devel@lists.sourceforge.net
W: kvm.sourceforge.net
S: Supported
KERNEL VIRTUAL MACHINE for s390 (KVM/s390)
P: Carsten Otte
M: cotte@de.ibm.com
P: Christian Borntraeger
M: borntraeger@de.ibm.com
M: linux390@de.ibm.com
L: linux-s390@vger.kernel.org
W: http://www.ibm.com/developerworks/linux/linux390/
S: Supported
KEXEC
P: Eric Biederman
M: ebiederm@xmission.com
@ -2558,12 +2617,10 @@ W: http://www.tazenda.demon.co.uk/phil/linux-hp
S: Maintained
MAC80211
P: Michael Wu
M: flamingice@sourmilk.net
P: Johannes Berg
M: johannes@sipsolutions.net
P: Jiri Benc
M: jbenc@suse.cz
P: Michael Wu
M: flamingice@sourmilk.net
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
T: git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
@ -2654,7 +2711,7 @@ P: David Howells
M: dhowells@redhat.com
P: Koichi Yasutake
M: yasutake.koichi@jp.panasonic.com
L: linux-am33-list@redhat.com
L: linux-am33-list@redhat.com (moderated for non-subscribers)
W: ftp://ftp.redhat.com/pub/redhat/gnupro/AM33/
S: Maintained
@ -2717,7 +2774,7 @@ M: rubini@ipvvis.unipv.it
L: linux-kernel@vger.kernel.org
S: Maintained
MOXA SMARTIO/INDUSTIO SERIAL CARD (MXSER 2.0)
MOXA SMARTIO/INDUSTIO/INTELLIO SERIAL CARD
P: Jiri Slaby
M: jirislaby@gmail.com
L: linux-kernel@vger.kernel.org
@ -3073,7 +3130,8 @@ PCI SUBSYSTEM
P: Jesse Barnes
M: jbarnes@virtuousgeek.org
L: linux-kernel@vger.kernel.org
L: linux-pci@atrey.karlin.mff.cuni.cz
L: linux-pci@vger.kernel.org
T: git kernel.org:/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git
S: Supported
PCI HOTPLUG CORE
@ -3534,6 +3592,13 @@ M: pfg@sgi.com
L: linux-ia64@vger.kernel.org
S: Supported
SFC NETWORK DRIVER
P: Steve Hodgson
P: Ben Hutchings
P: Robert Stonehouse
M: linux-net-drivers@solarflare.com
S: Supported
SGI VISUAL WORKSTATION 320 AND 540
P: Andrey Panin
M: pazke@donpac.ru
@ -3700,42 +3765,6 @@ M: chrisw@sous-sol.org
L: stable@kernel.org
S: Maintained
TPM DEVICE DRIVER
P: Kylene Hall
M: tpmdd-devel@lists.sourceforge.net
W: http://tpmdd.sourceforge.net
P: Marcel Selhorst
M: tpm@selhorst.net
W: http://www.prosec.rub.de/tpm/
L: tpmdd-devel@lists.sourceforge.net
S: Maintained
Telecom Clock Driver for MCPL0010
P: Mark Gross
M: mark.gross@intel.com
S: Supported
TENSILICA XTENSA PORT (xtensa):
P: Chris Zankel
M: chris@zankel.net
S: Maintained
THINKPAD ACPI EXTRAS DRIVER
P: Henrique de Moraes Holschuh
M: ibm-acpi@hmh.eng.br
L: ibm-acpi-devel@lists.sourceforge.net
W: http://ibm-acpi.sourceforge.net
W: http://thinkwiki.org/wiki/Ibm-acpi
T: git repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
S: Maintained
UltraSPARC (sparc64):
P: David S. Miller
M: davem@davemloft.net
L: sparclinux@vger.kernel.org
T: git kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git
S: Maintained
SHARP LH SUPPORT (LH7952X & LH7A40X)
P: Marc Singer
M: elf@buici.com
@ -3832,6 +3861,12 @@ P: Christoph Hellwig
M: hch@infradead.org
S: Maintained
TASKSTATS STATISTICS INTERFACE
P: Shailabh Nagar
M: nagar@watson.ibm.com
L: linux-kernel@vger.kernel.org
S: Maintained
TC CLASSIFIER
P: Jamal Hadi Salim
M: hadi@cyberus.ca
@ -3854,6 +3889,25 @@ M: andy@greyhouse.net
L: netdev@vger.kernel.org
S: Supported
Telecom Clock Driver for MCPL0010
P: Mark Gross
M: mark.gross@intel.com
S: Supported
TENSILICA XTENSA PORT (xtensa):
P: Chris Zankel
M: chris@zankel.net
S: Maintained
THINKPAD ACPI EXTRAS DRIVER
P: Henrique de Moraes Holschuh
M: ibm-acpi@hmh.eng.br
L: ibm-acpi-devel@lists.sourceforge.net
W: http://ibm-acpi.sourceforge.net
W: http://thinkwiki.org/wiki/Ibm-acpi
T: git repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
S: Maintained
TI FLASH MEDIA INTERFACE DRIVER
P: Alex Dubov
M: oakad@yahoo.com
@ -3871,12 +3925,6 @@ P: Deepak Saxena
M: dsaxena@plexity.net
S: Maintained
TASKSTATS STATISTICS INTERFACE
P: Shailabh Nagar
M: nagar@watson.ibm.com
L: linux-kernel@vger.kernel.org
S: Maintained
TIPC NETWORK LAYER
P: Per Liden
M: per.liden@ericsson.com
@ -3910,6 +3958,16 @@ L: tlinux-users@tce.toshiba-dme.co.jp
W: http://www.buzzard.org.uk/toshiba/
S: Maintained
TPM DEVICE DRIVER
P: Kylene Hall
M: tpmdd-devel@lists.sourceforge.net
W: http://tpmdd.sourceforge.net
P: Marcel Selhorst
M: tpm@selhorst.net
W: http://www.prosec.rub.de/tpm/
L: tpmdd-devel@lists.sourceforge.net
S: Maintained
TRIDENT 4DWAVE/SIS 7018 PCI AUDIO CORE
P: Muli Ben-Yehuda
M: mulix@mulix.org
@ -3922,6 +3980,12 @@ M: trivial@kernel.org
L: linux-kernel@vger.kernel.org
S: Maintained
TTY LAYER
P: Alan Cox
M: alan@lxorguk.ukuu.org.uk
L: linux-kernel@vger.kernel.org
S: Maintained
TULIP NETWORK DRIVERS
P: Grant Grundler
M: grundler@parisc-linux.org
@ -3987,6 +4051,12 @@ L: linux-usb@vger.kernel.org
S: Maintained
W: http://www.kroah.com/linux-usb/
USB CYPRESS C67X00 DRIVER
P: Peter Korsgaard
M: jacmet@sunsite.dk
L: linux-usb@vger.kernel.org
S: Maintained
USB DAVICOM DM9601 DRIVER
P: Peter Korsgaard
M: jacmet@sunsite.dk
@ -4090,6 +4160,20 @@ L: linux-usb@vger.kernel.org
W: http://www.chello.nl/~j.vreeken/se401/
S: Maintained
USB SERIAL BELKIN F5U103 DRIVER
P: William Greathouse
M: wgreathouse@smva.com
L: linux-usb@vger.kernel.org
S: Maintained
USB SERIAL CYPRESS M8 DRIVER
P: Lonnie Mendez
M: dignome@gmail.com
L: linux-usb@vger.kernel.org
S: Maintained
W: http://geocities.com/i0xox0i
W: http://firstlight.net/cvs
USB SERIAL CYBERJACK DRIVER
P: Matthias Bruestle and Harald Welte
M: support@reiner-sct.com
@ -4109,20 +4193,6 @@ M: gregkh@suse.de
L: linux-usb@vger.kernel.org
S: Supported
USB SERIAL BELKIN F5U103 DRIVER
P: William Greathouse
M: wgreathouse@smva.com
L: linux-usb@vger.kernel.org
S: Maintained
USB SERIAL CYPRESS M8 DRIVER
P: Lonnie Mendez
M: dignome@gmail.com
L: linux-usb@vger.kernel.org
S: Maintained
W: http://geocities.com/i0xox0i
W: http://firstlight.net/cvs
USB SERIAL EMPEG EMPEG-CAR MARK I/II DRIVER
P: Gary Brubaker
M: xavyer@ix.netcom.com
@ -4225,7 +4295,7 @@ M: gregkh@suse.de
L: linux-kernel@vger.kernel.org
S: Maintained
FAT/VFAT/MSDOS FILESYSTEM:
VFAT/FAT/MSDOS FILESYSTEM:
P: OGAWA Hirofumi
M: hirofumi@mail.parknet.co.jp
L: linux-kernel@vger.kernel.org
@ -4270,6 +4340,13 @@ M: dushistov@mail.ru
L: linux-kernel@vger.kernel.org
S: Maintained
UltraSPARC (sparc64):
P: David S. Miller
M: davem@davemloft.net
L: sparclinux@vger.kernel.org
T: git kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git
S: Maintained
USB DIAMOND RIO500 DRIVER
P: Cesar Miquel
M: miquel@df.uba.ar
@ -4358,6 +4435,16 @@ L: linux-wireless@vger.kernel.org
W: http://oops.ghostprotocols.net:81/blog
S: Maintained
WM97XX TOUCHSCREEN DRIVERS
P: Mark Brown
M: broonie@opensource.wolfsonmicro.com
P: Liam Girdwood
M: liam.girdwood@wolfsonmicro.com
L: linux-input@vger.kernel.org
T: git git://opensource.wolfsonmicro.com/linux-2.6-touch
W: http://opensource.wolfsonmicro.com/node/7
S: Supported
X.25 NETWORK LAYER
P: Henner Eisen
M: eis@baty.hanse.de

46
Makefile
View File

@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 25
EXTRAVERSION =
SUBLEVEL = 26
EXTRAVERSION = -rc1
NAME = Funky Weasel is Jiggy wit it
# *DOCUMENTATION*
@ -507,6 +507,10 @@ else
KBUILD_CFLAGS += -O2
endif
ifneq (CONFIG_FRAME_WARN,0)
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
endif
# Force gcc to behave correct even for buggy distributions
# Arch Makefiles may override this setting
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
@ -790,7 +794,7 @@ endif # ifdef CONFIG_KALLSYMS
quiet_cmd_vmlinux-modpost = LD $@
cmd_vmlinux-modpost = $(LD) $(LDFLAGS) -r -o $@ \
$(vmlinux-init) --start-group $(vmlinux-main) --end-group \
$(filter-out $(vmlinux-init) $(vmlinux-main) $(vmlinux-lds) FORCE ,$^)
$(filter-out $(vmlinux-init) $(vmlinux-main) FORCE ,$^)
define rule_vmlinux-modpost
:
+$(call cmd,vmlinux-modpost)
@ -814,7 +818,9 @@ endif
ifdef CONFIG_KALLSYMS
.tmp_vmlinux1: vmlinux.o
endif
vmlinux.o: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE
modpost-init := $(filter-out init/built-in.o, $(vmlinux-init))
vmlinux.o: $(modpost-init) $(vmlinux-main) FORCE
$(call if_changed_rule,vmlinux-modpost)
# The actual objects are generated when descending,
@ -1170,8 +1176,10 @@ rpm: include/config/kernel.release FORCE
# Brief documentation of the typical targets used
# ---------------------------------------------------------------------------
boards := $(wildcard $(srctree)/arch/$(ARCH)/configs/*_defconfig)
boards := $(wildcard $(srctree)/arch/$(SRCARCH)/configs/*_defconfig)
boards := $(notdir $(boards))
board-dirs := $(dir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/*/*_defconfig))
board-dirs := $(sort $(notdir $(board-dirs:/=)))
help:
@echo 'Cleaning targets:'
@ -1217,14 +1225,19 @@ help:
@echo 'Documentation targets:'
@$(MAKE) -f $(srctree)/Documentation/DocBook/Makefile dochelp
@echo ''
@echo 'Architecture specific targets ($(ARCH)):'
@echo 'Architecture specific targets ($(SRCARCH)):'
@$(if $(archhelp),$(archhelp),\
echo ' No architecture specific help defined for $(ARCH)')
echo ' No architecture specific help defined for $(SRCARCH)')
@echo ''
@$(if $(boards), \
$(foreach b, $(boards), \
printf " %-24s - Build for %s\\n" $(b) $(subst _defconfig,,$(b));) \
echo '')
@$(if $(board-dirs), \
$(foreach b, $(board-dirs), \
printf " %-16s - Show %s-specific targets\\n" help-$(b) $(b);) \
printf " %-16s - Show all of the above\\n" help-boards; \
echo '')
@echo ' make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build'
@echo ' make V=2 [targets] 2 => give reason for rebuild of target'
@ -1236,6 +1249,20 @@ help:
@echo 'For further info see the ./README file'
help-board-dirs := $(addprefix help-,$(board-dirs))
help-boards: $(help-board-dirs)
boards-per-dir = $(notdir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/$*/*_defconfig))
$(help-board-dirs): help-%:
@echo 'Architecture specific targets ($(SRCARCH) $*):'
@$(if $(boards-per-dir), \
$(foreach b, $(boards-per-dir), \
printf " %-24s - Build for %s\\n" $*/$(b) $(subst _defconfig,,$(b));) \
echo '')
# Documentation targets
# ---------------------------------------------------------------------------
%docs: scripts_basic FORCE
@ -1396,7 +1423,7 @@ define xtags
$(all-kconfigs) | xargs $1 -a \
--langdef=kconfig \
--language-force=kconfig \
--regex-kconfig='/^[[:blank:]]*config[[:blank:]]+([[:alnum:]_]+)/\1/'; \
--regex-kconfig='/^[[:blank:]]*(menu|)config[[:blank:]]+([[:alnum:]_]+)/\2/'; \
$(all-defconfigs) | xargs -r $1 -a \
--langdef=dotconfig \
--language-force=dotconfig \
@ -1404,7 +1431,7 @@ define xtags
elif $1 --version 2>&1 | grep -iq emacs; then \
$(all-sources) | xargs $1 -a; \
$(all-kconfigs) | xargs $1 -a \
--regex='/^[ \t]*config[ \t]+\([a-zA-Z0-9_]+\)/\1/'; \
--regex='/^[ \t]*(menu|)config[ \t]+\([a-zA-Z0-9_]+\)/\2/'; \
$(all-defconfigs) | xargs -r $1 -a \
--regex='/^#?[ \t]?\(CONFIG_[a-zA-Z0-9_]+\)/\1/'; \
else \
@ -1539,7 +1566,6 @@ quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN $(wildcard $(rm-files))
cmd_rmfiles = rm -f $(rm-files)
# Run depmod only if we have System.map and depmod is executable
# and we build for the host arch
quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
cmd_depmod = \
if [ -r System.map -a -x $(DEPMOD) ]; then \

3
arch/Kconfig
View File

@ -36,3 +36,6 @@ config HAVE_KPROBES
config HAVE_KRETPROBES
def_bool n
config HAVE_DMA_ATTRS
def_bool n

6
arch/alpha/kernel/asm-offsets.c
View File

@ -8,13 +8,9 @@
#include <linux/stddef.h>
#include <linux/sched.h>
#include <linux/ptrace.h>
#include <linux/kbuild.h>
#include <asm/io.h>
#define DEFINE(sym, val) \
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
#define BLANK() asm volatile("\n->" : : )
void foo(void)
{
DEFINE(TI_TASK, offsetof(struct thread_info, task));

6
arch/alpha/kernel/core_marvel.c
View File

@ -994,7 +994,7 @@ marvel_agp_configure(alpha_agp_info *agp)
* rate, but warn the user.
*/
printk("%s: unknown PLL setting RNGB=%lx (PLL6_CTL=%016lx)\n",
__FUNCTION__, IO7_PLL_RNGB(agp_pll), agp_pll);
__func__, IO7_PLL_RNGB(agp_pll), agp_pll);
break;
}
@ -1044,13 +1044,13 @@ marvel_agp_translate(alpha_agp_info *agp, dma_addr_t addr)
if (addr < agp->aperture.bus_base ||
addr >= agp->aperture.bus_base + agp->aperture.size) {
printk("%s: addr out of range\n", __FUNCTION__);
printk("%s: addr out of range\n", __func__);
return -EINVAL;
}
pte = aper->arena->ptes[baddr >> PAGE_SHIFT];
if (!(pte & 1)) {
printk("%s: pte not valid\n", __FUNCTION__);
printk("%s: pte not valid\n", __func__);
return -EINVAL;
}
return (pte >> 1) << PAGE_SHIFT;

24
arch/alpha/kernel/core_t2.c
View File

@ -336,10 +336,7 @@ t2_direct_map_window1(unsigned long base, unsigned long length)
#if DEBUG_PRINT_FINAL_SETTINGS
printk("%s: setting WBASE1=0x%lx WMASK1=0x%lx TBASE1=0x%lx\n",
__FUNCTION__,
*(vulp)T2_WBASE1,
*(vulp)T2_WMASK1,
*(vulp)T2_TBASE1);
__func__, *(vulp)T2_WBASE1, *(vulp)T2_WMASK1, *(vulp)T2_TBASE1);
#endif
}
@ -366,10 +363,7 @@ t2_sg_map_window2(struct pci_controller *hose,
#if DEBUG_PRINT_FINAL_SETTINGS
printk("%s: setting WBASE2=0x%lx WMASK2=0x%lx TBASE2=0x%lx\n",
__FUNCTION__,
*(vulp)T2_WBASE2,
*(vulp)T2_WMASK2,
*(vulp)T2_TBASE2);
__func__, *(vulp)T2_WBASE2, *(vulp)T2_WMASK2, *(vulp)T2_TBASE2);
#endif
}
@ -377,15 +371,15 @@ static void __init
t2_save_configuration(void)
{
#if DEBUG_PRINT_INITIAL_SETTINGS
printk("%s: HAE_1 was 0x%lx\n", __FUNCTION__, srm_hae); /* HW is 0 */
printk("%s: HAE_2 was 0x%lx\n", __FUNCTION__, *(vulp)T2_HAE_2);
printk("%s: HAE_3 was 0x%lx\n", __FUNCTION__, *(vulp)T2_HAE_3);
printk("%s: HAE_4 was 0x%lx\n", __FUNCTION__, *(vulp)T2_HAE_4);
printk("%s: HBASE was 0x%lx\n", __FUNCTION__, *(vulp)T2_HBASE);
printk("%s: HAE_1 was 0x%lx\n", __func__, srm_hae); /* HW is 0 */
printk("%s: HAE_2 was 0x%lx\n", __func__, *(vulp)T2_HAE_2);
printk("%s: HAE_3 was 0x%lx\n", __func__, *(vulp)T2_HAE_3);
printk("%s: HAE_4 was 0x%lx\n", __func__, *(vulp)T2_HAE_4);
printk("%s: HBASE was 0x%lx\n", __func__, *(vulp)T2_HBASE);
printk("%s: WBASE1=0x%lx WMASK1=0x%lx TBASE1=0x%lx\n", __FUNCTION__,
printk("%s: WBASE1=0x%lx WMASK1=0x%lx TBASE1=0x%lx\n", __func__,
*(vulp)T2_WBASE1, *(vulp)T2_WMASK1, *(vulp)T2_TBASE1);
printk("%s: WBASE2=0x%lx WMASK2=0x%lx TBASE2=0x%lx\n", __FUNCTION__,
printk("%s: WBASE2=0x%lx WMASK2=0x%lx TBASE2=0x%lx\n", __func__,
*(vulp)T2_WBASE2, *(vulp)T2_WMASK2, *(vulp)T2_TBASE2);
#endif

32
arch/alpha/kernel/core_titan.c
View File

@ -365,21 +365,21 @@ void __init
titan_init_arch(void)
{
#if 0
printk("%s: titan_init_arch()\n", __FUNCTION__);
printk("%s: CChip registers:\n", __FUNCTION__);
printk("%s: CSR_CSC 0x%lx\n", __FUNCTION__, TITAN_cchip->csc.csr);
printk("%s: CSR_MTR 0x%lx\n", __FUNCTION__, TITAN_cchip->mtr.csr);
printk("%s: CSR_MISC 0x%lx\n", __FUNCTION__, TITAN_cchip->misc.csr);
printk("%s: CSR_DIM0 0x%lx\n", __FUNCTION__, TITAN_cchip->dim0.csr);
printk("%s: CSR_DIM1 0x%lx\n", __FUNCTION__, TITAN_cchip->dim1.csr);
printk("%s: CSR_DIR0 0x%lx\n", __FUNCTION__, TITAN_cchip->dir0.csr);
printk("%s: CSR_DIR1 0x%lx\n", __FUNCTION__, TITAN_cchip->dir1.csr);
printk("%s: CSR_DRIR 0x%lx\n", __FUNCTION__, TITAN_cchip->drir.csr);
printk("%s: titan_init_arch()\n", __func__);
printk("%s: CChip registers:\n", __func__);
printk("%s: CSR_CSC 0x%lx\n", __func__, TITAN_cchip->csc.csr);
printk("%s: CSR_MTR 0x%lx\n", __func__, TITAN_cchip->mtr.csr);
printk("%s: CSR_MISC 0x%lx\n", __func__, TITAN_cchip->misc.csr);
printk("%s: CSR_DIM0 0x%lx\n", __func__, TITAN_cchip->dim0.csr);
printk("%s: CSR_DIM1 0x%lx\n", __func__, TITAN_cchip->dim1.csr);
printk("%s: CSR_DIR0 0x%lx\n", __func__, TITAN_cchip->dir0.csr);
printk("%s: CSR_DIR1 0x%lx\n", __func__, TITAN_cchip->dir1.csr);
printk("%s: CSR_DRIR 0x%lx\n", __func__, TITAN_cchip->drir.csr);
printk("%s: DChip registers:\n", __FUNCTION__);
printk("%s: CSR_DSC 0x%lx\n", __FUNCTION__, TITAN_dchip->dsc.csr);
printk("%s: CSR_STR 0x%lx\n", __FUNCTION__, TITAN_dchip->str.csr);
printk("%s: CSR_DREV 0x%lx\n", __FUNCTION__, TITAN_dchip->drev.csr);
printk("%s: DChip registers:\n", __func__);
printk("%s: CSR_DSC 0x%lx\n", __func__, TITAN_dchip->dsc.csr);
printk("%s: CSR_STR 0x%lx\n", __func__, TITAN_dchip->str.csr);
printk("%s: CSR_DREV 0x%lx\n", __func__, TITAN_dchip->drev.csr);
#endif
boot_cpuid = __hard_smp_processor_id();
@ -700,13 +700,13 @@ titan_agp_translate(alpha_agp_info *agp, dma_addr_t addr)
if (addr < agp->aperture.bus_base ||
addr >= agp->aperture.bus_base + agp->aperture.size) {
printk("%s: addr out of range\n", __FUNCTION__);
printk("%s: addr out of range\n", __func__);
return -EINVAL;
}
pte = aper->arena->ptes[baddr >> PAGE_SHIFT];
if (!(pte & 1)) {
printk("%s: pte not valid\n", __FUNCTION__);
printk("%s: pte not valid\n", __func__);
return -EINVAL;
}

28
arch/alpha/kernel/core_tsunami.c
View File

@ -241,8 +241,6 @@ tsunami_probe_write(volatile unsigned long *vaddr)
#define tsunami_probe_read(ADDR) 1
#endif /* NXM_MACHINE_CHECKS_ON_TSUNAMI */
#define FN __FUNCTION__
static void __init
tsunami_init_one_pchip(tsunami_pchip *pchip, int index)
{
@ -383,27 +381,27 @@ tsunami_init_arch(void)
/* NXMs just don't matter to Tsunami--unless they make it
choke completely. */
tmp = (unsigned long)(TSUNAMI_cchip - 1);
printk("%s: probing bogus address: 0x%016lx\n", FN, bogus_addr);
printk("%s: probing bogus address: 0x%016lx\n", __func__, bogus_addr);
printk("\tprobe %s\n",
tsunami_probe_write((unsigned long *)bogus_addr)
? "succeeded" : "failed");
#endif /* NXM_MACHINE_CHECKS_ON_TSUNAMI */
#if 0
printk("%s: CChip registers:\n", FN);
printk("%s: CSR_CSC 0x%lx\n", FN, TSUNAMI_cchip->csc.csr);
printk("%s: CSR_MTR 0x%lx\n", FN, TSUNAMI_cchip.mtr.csr);
printk("%s: CSR_MISC 0x%lx\n", FN, TSUNAMI_cchip->misc.csr);
printk("%s: CSR_DIM0 0x%lx\n", FN, TSUNAMI_cchip->dim0.csr);
printk("%s: CSR_DIM1 0x%lx\n", FN, TSUNAMI_cchip->dim1.csr);
printk("%s: CSR_DIR0 0x%lx\n", FN, TSUNAMI_cchip->dir0.csr);
printk("%s: CSR_DIR1 0x%lx\n", FN, TSUNAMI_cchip->dir1.csr);
printk("%s: CSR_DRIR 0x%lx\n", FN, TSUNAMI_cchip->drir.csr);
printk("%s: CChip registers:\n", __func__);
printk("%s: CSR_CSC 0x%lx\n", __func__, TSUNAMI_cchip->csc.csr);
printk("%s: CSR_MTR 0x%lx\n", __func__, TSUNAMI_cchip.mtr.csr);
printk("%s: CSR_MISC 0x%lx\n", __func__, TSUNAMI_cchip->misc.csr);
printk("%s: CSR_DIM0 0x%lx\n", __func__, TSUNAMI_cchip->dim0.csr);
printk("%s: CSR_DIM1 0x%lx\n", __func__, TSUNAMI_cchip->dim1.csr);
printk("%s: CSR_DIR0 0x%lx\n", __func__, TSUNAMI_cchip->dir0.csr);
printk("%s: CSR_DIR1 0x%lx\n", __func__, TSUNAMI_cchip->dir1.csr);
printk("%s: CSR_DRIR 0x%lx\n", __func__, TSUNAMI_cchip->drir.csr);
printk("%s: DChip registers:\n");
printk("%s: CSR_DSC 0x%lx\n", FN, TSUNAMI_dchip->dsc.csr);
printk("%s: CSR_STR 0x%lx\n", FN, TSUNAMI_dchip->str.csr);
printk("%s: CSR_DREV 0x%lx\n", FN, TSUNAMI_dchip->drev.csr);
printk("%s: CSR_DSC 0x%lx\n", __func__, TSUNAMI_dchip->dsc.csr);
printk("%s: CSR_STR 0x%lx\n", __func__, TSUNAMI_dchip->str.csr);
printk("%s: CSR_DREV 0x%lx\n", __func__, TSUNAMI_dchip->drev.csr);
#endif
/* With multiple PCI busses, we play with I/O as physical addrs. */
ioport_resource.end = ~0UL;

6
arch/alpha/kernel/module.c
View File

@ -120,6 +120,12 @@ module_frob_arch_sections(Elf64_Ehdr *hdr, Elf64_Shdr *sechdrs,
nsyms = symtab->sh_size / sizeof(Elf64_Sym);
chains = kcalloc(nsyms, sizeof(struct got_entry), GFP_KERNEL);
if (!chains) {
printk(KERN_ERR
"module %s: no memory for symbol chain buffer\n",
me->name);
return -ENOMEM;
}
got->sh_size = 0;
got->sh_addralign = 8;

70
arch/alpha/kernel/osf_sys.c
View File

@ -75,6 +75,7 @@ osf_set_program_attributes(unsigned long text_start, unsigned long text_len,
lock_kernel();
mm = current->mm;
mm->end_code = bss_start + bss_len;
mm->start_brk = bss_start + bss_len;
mm->brk = bss_start + bss_len;
#if 0
printk("set_program_attributes(%lx %lx %lx %lx)\n",
@ -980,27 +981,18 @@ asmlinkage int
osf_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user *exp,
struct timeval32 __user *tvp)
{
fd_set_bits fds;
char *bits;
size_t size;
long timeout;
int ret = -EINVAL;
struct fdtable *fdt;
int max_fds;
timeout = MAX_SCHEDULE_TIMEOUT;
s64 timeout = MAX_SCHEDULE_TIMEOUT;
if (tvp) {
time_t sec, usec;
if (!access_ok(VERIFY_READ, tvp, sizeof(*tvp))
|| __get_user(sec, &tvp->tv_sec)
|| __get_user(usec, &tvp->tv_usec)) {
ret = -EFAULT;
goto out_nofds;
return -EFAULT;
}
if (sec < 0 || usec < 0)
goto out_nofds;
return -EINVAL;
if ((unsigned long) sec < MAX_SELECT_SECONDS) {
timeout = (usec + 1000000/HZ - 1) / (1000000/HZ);
@ -1008,60 +1000,8 @@ osf_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user *exp,
}
}
rcu_read_lock();
fdt = files_fdtable(current->files);
max_fds = fdt->max_fds;
rcu_read_unlock();
if (n < 0 || n > max_fds)
goto out_nofds;
/*
* We need 6 bitmaps (in/out/ex for both incoming and outgoing),
* since we used fdset we need to allocate memory in units of
* long-words.
*/
ret = -ENOMEM;
size = FDS_BYTES(n);
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
goto out_nofds;
fds.in = (unsigned long *) bits;
fds.out = (unsigned long *) (bits + size);
fds.ex = (unsigned long *) (bits + 2*size);
fds.res_in = (unsigned long *) (bits + 3*size);
fds.res_out = (unsigned long *) (bits + 4*size);
fds.res_ex = (unsigned long *) (bits + 5*size);
if ((ret = get_fd_set(n, inp->fds_bits, fds.in)) ||
(ret = get_fd_set(n, outp->fds_bits, fds.out)) ||
(ret = get_fd_set(n, exp->fds_bits, fds.ex)))
goto out;
zero_fd_set(n, fds.res_in);
zero_fd_set(n, fds.res_out);
zero_fd_set(n, fds.res_ex);
ret = do_select(n, &fds, &timeout);
/* OSF does not copy back the remaining time. */
if (ret < 0)
goto out;
if (!ret) {
ret = -ERESTARTNOHAND;
if (signal_pending(current))
goto out;
ret = 0;
}
if (set_fd_set(n, inp->fds_bits, fds.res_in) ||
set_fd_set(n, outp->fds_bits, fds.res_out) ||
set_fd_set(n, exp->fds_bits, fds.res_ex))
ret = -EFAULT;
out:
kfree(bits);
out_nofds:
return ret;
return core_sys_select(n, inp, outp, exp, &timeout);
}
struct rusage32 {

28
arch/alpha/kernel/pci.c
View File

@ -71,25 +71,13 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82378, quirk_i
static void __init
quirk_cypress(struct pci_dev *dev)
{
/* The Notorious Cy82C693 chip. */
/* The Cypress IDE controller doesn't support native mode, but it
has programmable addresses of IDE command/control registers.
This violates PCI specifications, confuses the IDE subsystem and
causes resource conflicts between the primary HD_CMD register and
the floppy controller. Ugh. Fix that. */
if (dev->class >> 8 == PCI_CLASS_STORAGE_IDE) {
dev->resource[0].flags = 0;
dev->resource[1].flags = 0;
}
/* The Cypress bridge responds on the PCI bus in the address range
0xffff0000-0xffffffff (conventional x86 BIOS ROM). There is no
way to turn this off. The bridge also supports several extended
BIOS ranges (disabled after power-up), and some consoles do turn
them on. So if we use a large direct-map window, or a large SG
window, we must avoid the entire 0xfff00000-0xffffffff region. */
else if (dev->class >> 8 == PCI_CLASS_BRIDGE_ISA) {
if (dev->class >> 8 == PCI_CLASS_BRIDGE_ISA) {
if (__direct_map_base + __direct_map_size >= 0xfff00000UL)
__direct_map_size = 0xfff00000UL - __direct_map_base;
else {
@ -220,7 +208,7 @@ pdev_save_srm_config(struct pci_dev *dev)
tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
if (!tmp) {
printk(KERN_ERR "%s: kmalloc() failed!\n", __FUNCTION__);
printk(KERN_ERR "%s: kmalloc() failed!\n", __func__);
return;
}
tmp->next = srm_saved_configs;
@ -391,7 +379,7 @@ pcibios_set_master(struct pci_dev *dev)
pci_write_config_byte(dev, PCI_LATENCY_TIMER, 64);
}
static void __init
void __init
pcibios_claim_one_bus(struct pci_bus *b)
{
struct pci_dev *dev;
@ -405,7 +393,8 @@ pcibios_claim_one_bus(struct pci_bus *b)
if (r->parent || !r->start || !r->flags)
continue;
pci_claim_resource(dev, i);
if (pci_probe_only || (r->flags & IORESOURCE_PCI_FIXED))
pci_claim_resource(dev, i);
}
}
@ -444,8 +433,7 @@ common_init_pci(void)
}
}
if (pci_probe_only)
pcibios_claim_console_setup();
pcibios_claim_console_setup();
pci_assign_unassigned_resources();
pci_fixup_irqs(alpha_mv.pci_swizzle, alpha_mv.pci_map_irq);
@ -526,8 +514,8 @@ sys_pciconfig_iobase(long which, unsigned long bus, unsigned long dfn)
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
unsigned long start = pci_resource_start(dev, bar);
unsigned long len = pci_resource_len(dev, bar);
resource_size_t start = pci_resource_start(dev, bar);
resource_size_t len = pci_resource_len(dev, bar);
unsigned long flags = pci_resource_flags(dev, bar);
if (!len || !start)

32
arch/alpha/kernel/pci_iommu.c
View File

@ -79,25 +79,21 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
#ifdef CONFIG_DISCONTIGMEM
if (!NODE_DATA(nid) ||
(NULL == (arena = alloc_bootmem_node(NODE_DATA(nid),
sizeof(*arena))))) {
printk("%s: couldn't allocate arena from node %d\n"
" falling back to system-wide allocation\n",
__FUNCTION__, nid);
arena = alloc_bootmem(sizeof(*arena));
}
arena = alloc_bootmem_node(NODE_DATA(nid), sizeof(*arena));
if (!NODE_DATA(nid) || !arena) {
printk("%s: couldn't allocate arena from node %d\n"
" falling back to system-wide allocation\n",
__func__, nid);
arena = alloc_bootmem(sizeof(*arena));
}
if (!NODE_DATA(nid) ||
(NULL == (arena->ptes = __alloc_bootmem_node(NODE_DATA(nid),
mem_size,
align,
0)))) {
printk("%s: couldn't allocate arena ptes from node %d\n"
" falling back to system-wide allocation\n",
__FUNCTION__, nid);
arena->ptes = __alloc_bootmem(mem_size, align, 0);
}
arena->ptes = __alloc_bootmem_node(NODE_DATA(nid), mem_size, align, 0);
if (!NODE_DATA(nid) || !arena->ptes) {
printk("%s: couldn't allocate arena ptes from node %d\n"
" falling back to system-wide allocation\n",
__func__, nid);
arena->ptes = __alloc_bootmem(mem_size, align, 0);
}
#else /* CONFIG_DISCONTIGMEM */

4
arch/alpha/kernel/smp.c
View File

@ -755,7 +755,7 @@ smp_call_function_on_cpu (void (*func) (void *info), void *info, int retry,
if (atomic_read(&data.unstarted_count) > 0) {
long start_time = jiffies;
printk(KERN_ERR "%s: initial timeout -- trying long wait\n",
__FUNCTION__);
__func__);
timeout = jiffies + 30 * HZ;
while (atomic_read(&data.unstarted_count) > 0
&& time_before(jiffies, timeout))
@ -764,7 +764,7 @@ smp_call_function_on_cpu (void (*func) (void *info), void *info, int retry,
long delta = jiffies - start_time;
printk(KERN_ERR
"%s: response %ld.%ld seconds into long wait\n",
__FUNCTION__, delta / HZ,
__func__, delta / HZ,
(100 * (delta - ((delta / HZ) * HZ))) / HZ);
}
}

2
arch/alpha/kernel/srm_env.c
View File

@ -199,7 +199,7 @@ srm_env_init(void)
printk(KERN_INFO "%s: This Alpha system doesn't "
"know about SRM (or you've booted "
"SRM->MILO->Linux, which gets "
"misdetected)...\n", __FUNCTION__);
"misdetected)...\n", __func__);
return -ENODEV;
}

2
arch/alpha/kernel/sys_alcor.c
View File

@ -259,7 +259,7 @@ alcor_init_pci(void)
if (dev && dev->devfn == PCI_DEVFN(6,0)) {
alpha_mv.sys.cia.gru_int_req_bits = XLT_GRU_INT_REQ_BITS;
printk(KERN_INFO "%s: Detected AS500 or XLT motherboard.\n",
__FUNCTION__);
__func__);
}
pci_dev_put(dev);
}

Some files were not shown because too many files have changed in this diff Show More