mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-05-09 00:43:08 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge tag 'v3.3-rc1' into staging/for_v3.3

Browse Source 
* tag 'v3.3-rc1': (8187 commits)
  Linux 3.3-rc1
  x86, syscall: Need __ARCH_WANT_SYS_IPC for 32 bits
  qnx4: don't leak ->BitMap on late failure exits
  qnx4: reduce the insane nesting in qnx4_checkroot()
  qnx4: di_fname is an array, for crying out loud...
  KEYS: Permit key_serial() to be called with a const key pointer
  keys: fix user_defined key sparse messages
  ima: fix cred sparse warning
  uml: fix compile for x86-64
  MPILIB: Add a missing ENOMEM check
  tpm: fix (ACPI S3) suspend regression
  nvme: fix merge error due to change of 'make_request_fn' fn type
  xen: using EXPORT_SYMBOL requires including export.h
  gpio: tps65910: Use correct offset for gpio initialization
  acpi/apei/einj: Add extensions to EINJ from rev 5.0 of acpi spec
  intel_idle: Split up and provide per CPU initialization func
  ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init V2
  tg3: Fix single-vector MSI-X code
  openvswitch: Fix multipart datapath dumps.
  ipv6: fix per device IP snmp counters
  ...
This commit is contained in:
Mauro Carvalho Chehab
2012-01-21 23:23:15 -02:00
parent 9e5e3097a3 dcd6c92267
commit 19c22c34dc
9364 changed files with 445595 additions and 253652 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
CREDITS
View File

@@ -514,6 +514,11 @@ S: Bessemerstraat 21
S: Amsterdam
S: The Netherlands
N: NeilBrown
E: neil@brown.name
P: 4096R/566281B9 1BC6 29EB D390 D870 7B5F 497A 39EC 9EDD 5662 81B9
D: NFSD Maintainer 2000-2007
N: Zach Brown
E: zab@zabbo.net
D: maestro pci sound

75
Documentation/ABI/stable/sysfs-bus-xen-backend Normal file
View File

@@ -0,0 +1,75 @@
What: /sys/bus/xen-backend/devices/*/devtype
Date: Feb 2009
KernelVersion: 2.6.38
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The type of the device. e.g., one of: 'vbd' (block),
'vif' (network), or 'vfb' (framebuffer).
What: /sys/bus/xen-backend/devices/*/nodename
Date: Feb 2009
KernelVersion: 2.6.38
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
XenStore node (under /local/domain/NNN/) for this
backend device.
What: /sys/bus/xen-backend/devices/vbd-*/physical_device
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The major:minor number (in hexidecimal) of the
physical device providing the storage for this backend
block device.
What: /sys/bus/xen-backend/devices/vbd-*/mode
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Whether the block device is read-only ('r') or
read-write ('w').
What: /sys/bus/xen-backend/devices/vbd-*/statistics/f_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of flush requests from the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/oo_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of requests delayed because the backend was too
busy processing previous requests.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of read requests from the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_sect
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of sectors read by the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of write requests from the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_sect
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of sectors written by the frontend.

77
Documentation/ABI/stable/sysfs-devices-system-xen_memory Normal file
View File

@@ -0,0 +1,77 @@
What: /sys/devices/system/xen_memory/xen_memory0/max_retry_count
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The maximum number of times the balloon driver will
attempt to increase the balloon before giving up. See
also 'retry_count' below.
A value of zero means retry forever and is the default one.
What: /sys/devices/system/xen_memory/xen_memory0/max_schedule_delay
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The limit that 'schedule_delay' (see below) will be
increased to. The default value is 32 seconds.
What: /sys/devices/system/xen_memory/xen_memory0/retry_count
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The current number of times that the balloon driver
has attempted to increase the size of the balloon.
The default value is one. With max_retry_count being
zero (unlimited), this means that the driver will attempt
to retry with a 'schedule_delay' delay.
What: /sys/devices/system/xen_memory/xen_memory0/schedule_delay
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The time (in seconds) to wait between attempts to
increase the balloon. Each time the balloon cannot be
increased, 'schedule_delay' is increased (until
'max_schedule_delay' is reached at which point it
will use the max value).
What: /sys/devices/system/xen_memory/xen_memory0/target
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The target number of pages to adjust this domain's
memory reservation to.
What: /sys/devices/system/xen_memory/xen_memory0/target_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
As target above, except the value is in KiB.
What: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Current size (in KiB) of this domain's memory
reservation.
What: /sys/devices/system/xen_memory/xen_memory0/info/high_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Amount (in KiB) of high memory in the balloon.
What: /sys/devices/system/xen_memory/xen_memory0/info/low_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Amount (in KiB) of low (or normal) memory in the
balloon.

18
Documentation/ABI/testing/sysfs-bus-pci
View File

@@ -66,6 +66,24 @@ Description:
re-discover previously removed devices.
Depends on CONFIG_HOTPLUG.
What: /sys/bus/pci/devices/.../msi_irqs/
Date: September, 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
The /sys/devices/.../msi_irqs directory contains a variable set
of sub-directories, with each sub-directory being named after a
corresponding msi irq vector allocated to that device. Each
numbered sub-directory N contains attributes of that irq.
Note that this directory is not created for device drivers which
do not support msi irqs
What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode
Date: September 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
This attribute indicates the mode that the irq vector named by
the parent directory is in (msi vs. msix)
What: /sys/bus/pci/devices/.../remove
Date: January 2009
Contact: Linux PCI developers <linux-pci@vger.kernel.org>

25
Documentation/ABI/testing/sysfs-bus-usb
View File

@@ -119,6 +119,31 @@ Description:
Write a 1 to force the device to disconnect
(equivalent to unplugging a wired USB device).
What: /sys/bus/usb/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
Description:
Writing a device ID to this file will attempt to
dynamically add a new device ID to a USB device driver.
This may allow the driver to support more hardware than
was included in the driver's static device ID support
table at compile time. The format for the device ID is:
idVendor idProduct bInterfaceClass.
The vendor ID and device ID fields are required, the
interface class is optional.
Upon successfully adding an ID, the driver will probe
for the device and attempt to bind to it. For example:
# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
What: /sys/bus/usb-serial/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
Description:
For serial USB drivers, this attribute appears under the
extra bus folder "usb-serial" in sysfs; apart from that
difference, all descriptions from the entry
"/sys/bus/usb/drivers/.../new_id" apply.
What: /sys/bus/usb/drivers/.../remove_id
Date: November 2009
Contact: CHENG Renquan <rqcheng@smu.edu.sg>

12
Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration Normal file
View File

@@ -0,0 +1,12 @@
What: Attribute for calibrating ST-Ericsson AB8500 Real Time Clock
Date: Oct 2011
KernelVersion: 3.0
Contact: Mark Godfrey <mark.godfrey@stericsson.com>
Description: The rtc_calibration attribute allows the userspace to
calibrate the AB8500.s 32KHz Real Time Clock.
Every 60 seconds the AB8500 will correct the RTC's value
by adding to it the value of this attribute.
The range of the attribute is -127 to +127 in units of
30.5 micro-seconds (half-parts-per-million of the 32KHz clock)
Users: The /vendor/st-ericsson/base_utilities/core/rtc_calibration
daemon uses this interface.

34
Documentation/ABI/testing/sysfs-devices-platform-docg3 Normal file
View File

@@ -0,0 +1,34 @@
What: /sys/devices/platform/docg3/f[0-3]_dps[01]_is_keylocked
Date: November 2011
KernelVersion: 3.3
Contact: Robert Jarzmik <robert.jarzmik@free.fr>
Description:
Show whether the floor (0 to 4), protection area (0 or 1) is
keylocked. Each docg3 chip (or floor) has 2 protection areas,
which can cover any part of it, block aligned, called DPS.
The protection has information embedded whether it blocks reads,
writes or both.
The result is:
0 -> the DPS is not keylocked
1 -> the DPS is keylocked
Users: None identified so far.
What: /sys/devices/platform/docg3/f[0-3]_dps[01]_protection_key
Date: November 2011
KernelVersion: 3.3
Contact: Robert Jarzmik <robert.jarzmik@free.fr>
Description:
Enter the protection key for the floor (0 to 4), protection area
(0 or 1). Each docg3 chip (or floor) has 2 protection areas,
which can cover any part of it, block aligned, called DPS.
The protection has information embedded whether it blocks reads,
writes or both.
The protection key is a string of 8 bytes (value 0-255).
Entering the correct value toggle the lock, and can be observed
through f[0-3]_dps[01]_is_keylocked.
Possible values are:
- 8 bytes
Typical values are:
- "00000000"
- "12345678"
Users: None identified so far.

2
Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff
View File

@@ -1,7 +1,7 @@
What: /sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
Date: July 2011
KernelVersion: 3.2
Contact: Michal Mal<EFBFBD> <madcatxster@gmail.com>
Contact: Michal Malý <madcatxster@gmail.com>
Description: Display minimum, maximum and current range of the steering
wheel. Writing a value within min and max boundaries sets the
range of the wheel.

9
Documentation/ABI/testing/sysfs-driver-hid-multitouch Normal file
View File

@@ -0,0 +1,9 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/quirks
Date: November 2011
Contact: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Description: The integer value of this attribute corresponds to the
quirks actually in place to handle the device's protocol.
When read, this attribute returns the current settings (see
MT_QUIRKS_* in hid-multitouch.c).
When written this attribute change on the fly the quirks, then
the protocol to handle the device.

135
Documentation/ABI/testing/sysfs-driver-hid-roccat-isku Normal file
View File

@@ -0,0 +1,135 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/actual_profile
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the actual
profile. This value is persistent, so its equivalent to the
profile that's active when the device is powered on next time.
When written, this file sets the number of the startup profile
and the device activates this profile immediately.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/info
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns general data like firmware version.
The data is 6 bytes long.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/key_mask
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one deactivate certain keys like
windows and application keys, to prevent accidental presses.
Profile number for which this settings occur is included in
written data. The data has to be 6 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_capslock
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
capslock key for a specific profile. Profile number is included
in written data. The data has to be 6 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_easyzone
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
easyzone keys for a specific profile. Profile number is included
in written data. The data has to be 65 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_function
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
function keys for a specific profile. Profile number is included
in written data. The data has to be 41 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_macro
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the macro
keys for a specific profile. Profile number is included in
written data. The data has to be 35 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_media
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the media
keys for a specific profile. Profile number is included in
written data. The data has to be 29 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_thumbster
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
thumbster keys for a specific profile. Profile number is included
in written data. The data has to be 23 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/last_set
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the time in secs since
epoch in which the last configuration took place.
The data has to be 20 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/light
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the backlight intensity for
a specific profile. Profile number is included in written data.
The data has to be 10 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/macro
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one store macros with max 500
keystrokes for a specific button for a specific profile.
Button and profile numbers are included in written data.
The data has to be 2083 bytes long.
Before reading this file, control has to be written to select
which profile and key to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/control
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one select which data from which
profile will be read next. The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talk
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one trigger easyshift functionality
from the host.
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net

12
Documentation/ABI/testing/sysfs-driver-hid-wiimote
View File

@@ -8,3 +8,15 @@ Contact: David Herrmann <dh.herrmann@googlemail.com>
Description: Make it possible to set/get current led state. Reading from it
returns 0 if led is off and 1 if it is on. Writing 0 to it
disables the led, writing 1 enables it.
What: /sys/bus/hid/drivers/wiimote/<dev>/extension
Date: August 2011
KernelVersion: 3.2
Contact: David Herrmann <dh.herrmann@googlemail.com>
Description: This file contains the currently connected and initialized
extensions. It can be one of: none, motionp, nunchuck, classic,
motionp+nunchuck, motionp+classic
motionp is the official Nintendo Motion+ extension, nunchuck is
the official Nintendo Nunchuck extension and classic is the
Nintendo Classic Controller extension. The motionp extension can
be combined with the other two.

17
Documentation/ABI/testing/sysfs-driver-wacom
View File

@@ -15,9 +15,9 @@ Contact: linux-input@vger.kernel.org
Description:
Attribute group for control of the status LEDs and the OLEDs.
This attribute group is only available for Intuos 4 M, L,
and XL (with LEDs and OLEDs) and Cintiq 21UX2 (LEDs only).
Therefore its presence implicitly signifies the presence of
said LEDs and OLEDs on the tablet device.
and XL (with LEDs and OLEDs) and Cintiq 21UX2 and Cintiq 24HD
(LEDs only). Therefore its presence implicitly signifies the
presence of said LEDs and OLEDs on the tablet device.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
Date: August 2011
@@ -41,16 +41,17 @@ Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the four (for Intuos 4)
or of the right four (for Cintiq 21UX2) status LEDs is active (0..3).
The other three LEDs on the same side are always inactive.
or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status
LEDs is active (0..3). The other three LEDs on the same side are
always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
Date: September 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the left four (for Cintiq 21UX2)
status LEDs is active (0..3). The other three LEDs on the left are always
inactive.
Writing to this file sets which one of the left four (for Cintiq 21UX2
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
the left are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
Date: August 2011

4
Documentation/ABI/testing/sysfs-kernel-slab
View File

@@ -346,6 +346,10 @@ Description:
number of objects per slab. If a slab cannot be allocated
because of fragmentation, SLUB will retry with the minimum order
possible depending on its characteristics.
When debug_guardpage_minorder=N (N > 0) parameter is specified
(see Documentation/kernel-parameters.txt), the minimum possible
order is used and this sysfs entry can not be used to change
the order at run time.
What: /sys/kernel/slab/cache/order_fallback
Date: April 2008

16
Documentation/ABI/testing/sysfs-module
View File

@@ -33,3 +33,19 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
Beware, non-standard modes are usually not thoroughly tested by
hardware designers, and the hardware can malfunction when this
setting differ from default 100.
What: /sys/module/*/{coresize,initsize}
Date: Jan 2012
KernelVersion:»·3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module size in bytes.
What: /sys/module/*/taint
Date: Jan 2012
KernelVersion:»·3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module taint flags:
P - proprietary module
O - out-of-tree module
F - force-loaded module
C - staging driver module

50
Documentation/DocBook/debugobjects.tmpl
View File

@@ -96,6 +96,7 @@
<listitem><para>debug_object_deactivate</para></listitem>
<listitem><para>debug_object_destroy</para></listitem>
<listitem><para>debug_object_free</para></listitem>
<listitem><para>debug_object_assert_init</para></listitem>
</itemizedlist>
Each of these functions takes the address of the real object and
a pointer to the object type specific debug description
@@ -273,6 +274,26 @@
debug checks.
</para>
</sect1>
<sect1 id="debug_object_assert_init">
<title>debug_object_assert_init</title>
<para>
This function is called to assert that an object has been
initialized.
</para>
<para>
When the real object is not tracked by debugobjects, it calls
fixup_assert_init of the object type description structure
provided by the caller, with the hardcoded object state
ODEBUG_NOT_AVAILABLE. The fixup function can correct the problem
by calling debug_object_init and other specific initializing
functions.
</para>
<para>
When the real object is already tracked by debugobjects it is
ignored.
</para>
</sect1>
</chapter>
<chapter id="fixupfunctions">
<title>Fixup functions</title>
@@ -381,6 +402,35 @@
statistics.
</para>
</sect1>
<sect1 id="fixup_assert_init">
<title>fixup_assert_init</title>
<para>
This function is called from the debug code whenever a problem
in debug_object_assert_init is detected.
</para>
<para>
Called from debug_object_assert_init() with a hardcoded state
ODEBUG_STATE_NOTAVAILABLE when the object is not found in the
debug bucket.
</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, this function should make sure debug_object_init() is
called before returning.
</para>
<para>
The handling of statically initialized objects is a special
case. The fixup function should check if this is a legitimate
case of a statically initialized object or not. In this case only
debug_object_init() should be called to make the object known to
the tracker. Then the function should return 0 because this is not
a real fixup.
</para>
</sect1>
</chapter>
<chapter id="bugs">
<title>Known Bugs And Assumptions</title>

121
Documentation/DocBook/media/v4l/pixfmt-nv24.xml Normal file
View File

@@ -0,0 +1,121 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 ('NV42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-NV24"><constant>V4L2_PIX_FMT_NV24</constant></refname>
<refname id="V4L2-PIX-FMT-NV42"><constant>V4L2_PIX_FMT_NV42</constant></refname>
<refpurpose>Formats with full horizontal and vertical
chroma resolutions, also known as YUV 4:4:4. One luminance and one
chrominance plane with alternating chroma samples as opposed to
<constant>V4L2_PIX_FMT_YVU420</constant></refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>These are two-plane versions of the YUV 4:4:4 format. The three
components are separated into two sub-images or planes. The Y plane is
first, with each Y sample stored in one byte per pixel. For
<constant>V4L2_PIX_FMT_NV24</constant>, a combined CbCr plane
immediately follows the Y plane in memory. The CbCr plane has the same
width and height, in pixels, as the Y plane (and the image). Each line
contains one CbCr pair per pixel, with each Cb and Cr sample stored in
one byte. <constant>V4L2_PIX_FMT_NV42</constant> is the same except that
the Cb and Cr samples are swapped, the CrCb plane starts with a Cr
sample.</para>
<para>If the Y plane has pad bytes after each row, then the CbCr plane
has twice as many pad bytes after its rows.</para>
<example>
<title><constant>V4L2_PIX_FMT_NV24</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
<entry>Cb<subscript>03</subscript></entry>
<entry>Cr<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
<entry>Cb<subscript>13</subscript></entry>
<entry>Cr<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;32:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
<entry>Cb<subscript>23</subscript></entry>
<entry>Cr<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;40:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
<entry>Cb<subscript>33</subscript></entry>
<entry>Cr<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

1
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@@ -714,6 +714,7 @@ information.</para>
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
&sub-nv24;
&sub-m420;
</section>

2
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@@ -404,7 +404,7 @@
/* SNDRV_CARDS: maximum number of cards supported by this module */
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
/* definition of the chip-specific record */
struct mychip {

4
Documentation/HOWTO
View File

@@ -275,8 +275,8 @@ versions.
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 as needs dictate. The normal release period is approximately
2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
are 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.

6
Documentation/RCU/checklist.txt
View File

@@ -328,6 +328,12 @@ over a rather long period of time, but improvements are always welcome!
RCU rather than SRCU, because RCU is almost always faster and
easier to use than is SRCU.
If you need to enter your read-side critical section in a
hardirq or exception handler, and then exit that same read-side
critical section in the task that was interrupted, then you need
to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid
the lockdep checking that would otherwise this practice illegal.
Also unlike other forms of RCU, explicit initialization
and cleanup is required via init_srcu_struct() and
cleanup_srcu_struct(). These are passed a "struct srcu_struct"

10
Documentation/RCU/rcu.txt
View File

@@ -38,11 +38,11 @@ o How can the updater tell when a grace period has completed
Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the
same effect, but require that the readers manipulate CPU-local
counters. These counters allow limited types of blocking
within RCU read-side critical sections. SRCU also uses
CPU-local counters, and permits general blocking within
RCU read-side critical sections. These two variants of
RCU detect grace periods by sampling these counters.
counters. These counters allow limited types of blocking within
RCU read-side critical sections. SRCU also uses CPU-local
counters, and permits general blocking within RCU read-side
critical sections. These variants of RCU detect grace periods
by sampling these counters.
o If I am running on a uniprocessor kernel, which can only do one
thing at a time, why should I wait for a grace period?

16
Documentation/RCU/stallwarn.txt
View File

@@ -101,6 +101,11 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
messages.
o A hardware or software issue shuts off the scheduler-clock
interrupt on a CPU that is not in dyntick-idle mode. This
problem really has happened, and seems to be most likely to
result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.
o A bug in the RCU implementation.
o A hardware failure. This is quite unlikely, but has occurred
@@ -109,12 +114,11 @@ o A hardware failure. This is quite unlikely, but has occurred
This resulted in a series of RCU CPU stall warnings, eventually
leading the realization that the CPU had failed.
The RCU, RCU-sched, and RCU-bh implementations have CPU stall
warning. SRCU does not have its own CPU stall warnings, but its
calls to synchronize_sched() will result in RCU-sched detecting
RCU-sched-related CPU stalls. Please note that RCU only detects
CPU stalls when there is a grace period in progress. No grace period,
no CPU stall warnings.
The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
SRCU does not have its own CPU stall warnings, but its calls to
synchronize_sched() will result in RCU-sched detecting RCU-sched-related
CPU stalls. Please note that RCU only detects CPU stalls when there is
a grace period in progress. No grace period, no CPU stall warnings.
To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.

13
Documentation/RCU/torture.txt
View File

@@ -61,11 +61,24 @@ nreaders This is the number of RCU reading threads supported.
To properly exercise RCU implementations with preemptible
read-side critical sections.
onoff_interval
The number of seconds between each attempt to execute a
randomly selected CPU-hotplug operation. Defaults to
zero, which disables CPU hotplugging. In HOTPLUG_CPU=n
kernels, rcutorture will silently refuse to do any
CPU-hotplug operations regardless of what value is
specified for onoff_interval.
shuffle_interval
The number of seconds to keep the test threads affinitied
to a particular subset of the CPUs, defaults to 3 seconds.
Used in conjunction with test_no_idle_hz.
shutdown_secs The number of seconds to run the test before terminating
the test and powering off the system. The default is
zero, which disables test termination and system shutdown.
This capability is useful for automated testing.
stat_interval The number of seconds between output of torture
statistics (via printk()). Regardless of the interval,
statistics are printed when the module is unloaded.

4
Documentation/RCU/trace.txt
View File

@@ -105,14 +105,10 @@ o "dt" is the current value of the dyntick counter that is incremented
or one greater than the interrupt-nesting depth otherwise.
The number after the second "/" is the NMI nesting depth.
This field is displayed only for CONFIG_NO_HZ kernels.
o "df" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being in
dynticks-idle state.
This field is displayed only for CONFIG_NO_HZ kernels.
o "of" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being
offline. In a perfect world, this might never happen, but it

19
Documentation/RCU/whatisRCU.txt
View File

@@ -4,6 +4,7 @@ to start learning about RCU:
1. What is RCU, Fundamentally? http://lwn.net/Articles/262464/
2. What is RCU? Part 2: Usage http://lwn.net/Articles/263130/
3. RCU part 3: the RCU API http://lwn.net/Articles/264090/
4. The RCU API, 2010 Edition http://lwn.net/Articles/418853/
What is RCU?
@@ -834,6 +835,8 @@ SRCU: Critical sections Grace period Barrier
srcu_read_lock synchronize_srcu N/A
srcu_read_unlock synchronize_srcu_expedited
srcu_read_lock_raw
srcu_read_unlock_raw
srcu_dereference
SRCU: Initialization/cleanup
@@ -855,27 +858,33 @@ list can be helpful:
a. Will readers need to block? If so, you need SRCU.
b. What about the -rt patchset? If readers would need to block
b. Is it necessary to start a read-side critical section in a
hardirq handler or exception handler, and then to complete
this read-side critical section in the task that was
interrupted? If so, you need SRCU's srcu_read_lock_raw() and
srcu_read_unlock_raw() primitives.
c. What about the -rt patchset? If readers would need to block
in an non-rt kernel, you need SRCU. If readers would block
in a -rt kernel, but not in a non-rt kernel, SRCU is not
necessary.
c. Do you need to treat NMI handlers, hardirq handlers,
d. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
If so, you need RCU-sched.
d. Do you need RCU grace periods to complete even in the face
e. Do you need RCU grace periods to complete even in the face
of softirq monopolization of one or more of the CPUs? For
example, is your code subject to network-based denial-of-service
attacks? If so, you need RCU-bh.
e. Is your workload too update-intensive for normal use of
f. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
f. Otherwise, use RCU.
g. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.

55
Documentation/acpi/apei/einj.txt
View File

@@ -47,20 +47,53 @@ directory apei/einj. The following files are provided.
- param1
This file is used to set the first error parameter value. Effect of
parameter depends on error_type specified. For memory error, this is
physical memory address. Only available if param_extension module
parameter is specified.
parameter depends on error_type specified.
- param2
This file is used to set the second error parameter value. Effect of
parameter depends on error_type specified. For memory error, this is
physical memory address mask. Only available if param_extension
module parameter is specified.
parameter depends on error_type specified.
BIOS versions based in the ACPI 4.0 specification have limited options
to control where the errors are injected. Your BIOS may support an
extension (enabled with the param_extension=1 module parameter, or
boot command line einj.param_extension=1). This allows the address
and mask for memory injections to be specified by the param1 and
param2 files in apei/einj.
BIOS versions using the ACPI 5.0 specification have more control over
the target of the injection. For processor related errors (type 0x1,
0x2 and 0x4) the APICID of the target should be provided using the
param1 file in apei/einj. For memory errors (type 0x8, 0x10 and 0x20)
the address is set using param1 with a mask in param2 (0x0 is equivalent
to all ones). For PCI express errors (type 0x40, 0x80 and 0x100) the
segment, bus, device and function are specified using param1:
31 24 23 16 15 11 10 8 7 0
+-------------------------------------------------+
| segment | bus | device | function | reserved |
+-------------------------------------------------+
An ACPI 5.0 BIOS may also allow vendor specific errors to be injected.
In this case a file named vendor will contain identifying information
from the BIOS that hopefully will allow an application wishing to use
the vendor specific extension to tell that they are running on a BIOS
that supports it. All vendor extensions have the 0x80000000 bit set in
error_type. A file vendor_flags controls the interpretation of param1
and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor
documentation for details (and expect changes to this API if vendors
creativity in using this feature expands beyond our expectations).
Example:
# cd /sys/kernel/debug/apei/einj
# cat available_error_type # See which errors can be injected
0x00000002 Processor Uncorrectable non-fatal
0x00000008 Memory Correctable
0x00000010 Memory Uncorrectable non-fatal
# echo 0x12345000 > param1 # Set memory address for injection
# echo 0xfffffffffffff000 > param2 # Mask - anywhere in this page
# echo 0x8 > error_type # Choose correctable memory error
# echo 1 > error_inject # Inject now
Injecting parameter support is a BIOS version specific extension, that
is, it only works on some BIOS version. If you want to use it, please
make sure your BIOS version has the proper support and specify
"param_extension=y" in module parameter.
For more information about EINJ, please refer to ACPI specification
version 4.0, section 17.5.
version 4.0, section 17.5 and ACPI 5.0, section 18.6.

11
Documentation/arm/memory.txt
View File

@@ -51,15 +51,14 @@ ffc00000 ffefffff DMA memory mapping region. Memory returned
ff000000 ffbfffff Reserved for future expansion of DMA
mapping region.
VMALLOC_END feffffff Free for platform use, recommended.
VMALLOC_END must be aligned to a 2MB
boundary.
VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
Memory returned by vmalloc/ioremap will
be dynamically placed in this region.
VMALLOC_START may be based upon the value
of the high_memory variable.
Machine specific static mappings are also
located here through iotable_init().
VMALLOC_START is based upon the value
of the high_memory variable, and VMALLOC_END
is equal to 0xff000000.
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically

87
Documentation/atomic_ops.txt
View File

@@ -84,6 +84,93 @@ compiler optimizes the section accessing atomic_t variables.
*** YOU HAVE BEEN WARNED! ***
Properly aligned pointers, longs, ints, and chars (and unsigned
equivalents) may be atomically loaded from and stored to in the same
sense as described for atomic_read() and atomic_set(). The ACCESS_ONCE()
macro should be used to prevent the compiler from using optimizations
that might otherwise optimize accesses out of existence on the one hand,
or that might create unsolicited accesses on the other.
For example consider the following code:
while (a > 0)
do_something();
If the compiler can prove that do_something() does not store to the
variable a, then the compiler is within its rights transforming this to
the following:
tmp = a;
if (a > 0)
for (;;)
do_something();
If you don't want the compiler to do this (and you probably don't), then
you should use something like the following:
while (ACCESS_ONCE(a) < 0)
do_something();
Alternatively, you could place a barrier() call in the loop.
For another example, consider the following code:
tmp_a = a;
do_something_with(tmp_a);
do_something_else_with(tmp_a);
If the compiler can prove that do_something_with() does not store to the
variable a, then the compiler is within its rights to manufacture an
additional load as follows:
tmp_a = a;
do_something_with(tmp_a);
tmp_a = a;
do_something_else_with(tmp_a);
This could fatally confuse your code if it expected the same value
to be passed to do_something_with() and do_something_else_with().
The compiler would be likely to manufacture this additional load if
do_something_with() was an inline function that made very heavy use
of registers: reloading from variable a could save a flush to the
stack and later reload. To prevent the compiler from attacking your
code in this manner, write the following:
tmp_a = ACCESS_ONCE(a);
do_something_with(tmp_a);
do_something_else_with(tmp_a);
For a final example, consider the following code, assuming that the
variable a is set at boot time before the second CPU is brought online
and never changed later, so that memory barriers are not needed:
if (a)
b = 9;
else
b = 42;
The compiler is within its rights to manufacture an additional store
by transforming the above code into the following:
b = 42;
if (a)
b = 9;
This could come as a fatal surprise to other code running concurrently
that expected b to never have the value 42 if a was zero. To prevent
the compiler from doing this, write something like:
if (a)
ACCESS_ONCE(b) = 9;
else
ACCESS_ONCE(b) = 42;
Don't even -think- about doing this without proper use of memory barriers,
locks, or atomic operations if variable a can change at runtime!
*** WARNING: ACCESS_ONCE() DOES NOT IMPLY A BARRIER! ***
Now, we move onto the atomic operation interfaces typically implemented with
the help of assembly code.

51
Documentation/cgroups/cgroups.txt
View File

@@ -594,53 +594,44 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
called multiple times against a cgroup.
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task)
struct cgroup_taskset *tset)
(cgroup_mutex held by caller)
Called prior to moving a task into a cgroup; if the subsystem
returns an error, this will abort the attach operation. If a NULL
task is passed, then a successful result indicates that *any*
unspecified task can be moved into the cgroup. Note that this isn't
called on a fork. If this method returns 0 (success) then this should
remain valid while the caller holds cgroup_mutex and it is ensured that either
Called prior to moving one or more tasks into a cgroup; if the
subsystem returns an error, this will abort the attach operation.
@tset contains the tasks to be attached and is guaranteed to have at
least one task in it.
If there are multiple tasks in the taskset, then:
- it's guaranteed that all are from the same thread group
- @tset contains all tasks from the thread group whether or not
they're switching cgroups
- the first task is the leader
Each @tset entry also contains the task's old cgroup and tasks which
aren't switching cgroup can be skipped easily using the
cgroup_taskset_for_each() iterator. Note that this isn't called on a
fork. If this method returns 0 (success) then this should remain valid
while the caller holds cgroup_mutex and it is ensured that either
attach() or cancel_attach() will be called in future.
int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As can_attach, but for operations that must be run once per task to be
attached (possibly many when using cgroup_attach_proc). Called after
can_attach.
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task, bool threadgroup)
struct cgroup_taskset *tset)
(cgroup_mutex held by caller)
Called when a task attach operation has failed after can_attach() has succeeded.
A subsystem whose can_attach() has some side-effects should provide this
function, so that the subsystem can implement a rollback. If not, not necessary.
This will be called only about subsystems whose can_attach() operation have
succeeded.
void pre_attach(struct cgroup *cgrp);
(cgroup_mutex held by caller)
For any non-per-thread attachment work that needs to happen before
attach_task. Needed by cpuset.
succeeded. The parameters are identical to can_attach().
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct cgroup *old_cgrp, struct task_struct *task)
struct cgroup_taskset *tset)
(cgroup_mutex held by caller)
Called after the task has been attached to the cgroup, to allow any
post-attachment activity that requires memory allocations or blocking.
void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As attach, but for operations that must be run once per task to be attached,
like can_attach_task. Called before attach. Currently does not support any
subsystem that might need the old_cgrp for every thread in the group.
The parameters are identical to can_attach().
void fork(struct cgroup_subsy *ss, struct task_struct *task)

37
Documentation/cgroups/memory.txt
View File

@@ -44,8 +44,8 @@ Features:
- oom-killer disable knob and oom-notifier
- Root cgroup has no limit controls.
Kernel memory and Hugepages are not under control yet. We just manage
pages on LRU. To add more controls, we have to take care of performance.
Kernel memory support is work in progress, and the current version provides
basically functionality. (See Section 2.7)
Brief summary of control files.
@@ -61,7 +61,7 @@ Brief summary of control files.
memory.failcnt # show the number of memory usage hits limits
memory.memsw.failcnt # show the number of memory+Swap hits limits
memory.max_usage_in_bytes # show max memory usage recorded
memory.memsw.usage_in_bytes # show max memory+Swap usage recorded
memory.memsw.max_usage_in_bytes # show max memory+Swap usage recorded
memory.soft_limit_in_bytes # set/show soft limit of memory usage
memory.stat # show various statistics
memory.use_hierarchy # set/show hierarchical account enabled
@@ -72,6 +72,9 @@ Brief summary of control files.
memory.oom_control # set/show oom controls.
memory.numa_stat # show the number of memory usage per numa node
memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
1. History
The memory controller has a long history. A request for comments for the memory
@@ -255,6 +258,27 @@ When oom event notifier is registered, event will be delivered.
per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
zone->lru_lock, it has no lock of its own.
2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
With the Kernel memory extension, the Memory Controller is able to limit
the amount of kernel memory used by the system. Kernel memory is fundamentally
different than user memory, since it can't be swapped out, which makes it
possible to DoS the system by consuming too much of this precious resource.
Kernel memory limits are not imposed for the root cgroup. Usage for the root
cgroup may or may not be accounted.
Currently no soft limit is implemented for kernel memory. It is future work
to trigger slab reclaim when those limits are reached.
2.7.1 Current Kernel Memory resources accounted
* sockets memory pressure: some sockets protocols have memory pressure
thresholds. The Memory Controller allows them to be controlled individually
per cgroup, instead of globally.
* tcp memory pressure: sockets memory pressure for the tcp protocol.
3. User Interface
0. Configuration
@@ -386,8 +410,11 @@ memory.stat file includes following statistics
cache - # of bytes of page cache memory.
rss - # of bytes of anonymous and swap cache memory.
mapped_file - # of bytes of mapped file (includes tmpfs/shmem)
pgpgin - # of pages paged in (equivalent to # of charging events).
pgpgout - # of pages paged out (equivalent to # of uncharging events).
pgpgin - # of charging events to the memory cgroup. The charging
event happens each time a page is accounted as either mapped
anon page(RSS) or cache page(Page Cache) to the cgroup.
pgpgout - # of uncharging events to the memory cgroup. The uncharging
event happens each time a page is unaccounted from the cgroup.
swap - # of bytes of swap usage
inactive_anon - # of bytes of anonymous memory and swap cache memory on
LRU list.

53
Documentation/cgroups/net_prio.txt Normal file
View File

@@ -0,0 +1,53 @@
Network priority cgroup
-------------------------
The Network priority cgroup provides an interface to allow an administrator to
dynamically set the priority of network traffic generated by various
applications
Nominally, an application would set the priority of its traffic via the
SO_PRIORITY socket option. This however, is not always possible because:
1) The application may not have been coded to set this value
2) The priority of application traffic is often a site-specific administrative
decision rather than an application defined one.
This cgroup allows an administrator to assign a process to a group which defines
the priority of egress traffic on a given interface. Network priority groups can
be created by first mounting the cgroup filesystem.
# mount -t cgroup -onet_prio none /sys/fs/cgroup/net_prio
With the above step, the initial group acting as the parent accounting group
becomes visible at '/sys/fs/cgroup/net_prio'. This group includes all tasks in
the system. '/sys/fs/cgroup/net_prio/tasks' lists the tasks in this cgroup.
Each net_prio cgroup contains two files that are subsystem specific
net_prio.prioidx
This file is read-only, and is simply informative. It contains a unique integer
value that the kernel uses as an internal representation of this cgroup.
net_prio.ifpriomap
This file contains a map of the priorities assigned to traffic originating from
processes in this group and egressing the system on various interfaces. It
contains a list of tuples in the form <ifname priority>. Contents of this file
can be modified by echoing a string into the file using the same tuple format.
for example:
echo "eth0 5" > /sys/fs/cgroups/net_prio/iscsi/net_prio.ifpriomap
This command would force any traffic originating from processes belonging to the
iscsi net_prio cgroup and egressing on interface eth0 to have the priority of
said traffic set to the value 5. The parent accounting group also has a
writeable 'net_prio.ifpriomap' file that can be used to set a system default
priority.
Priorities are set immediately prior to queueing a frame to the device
queueing discipline (qdisc) so priorities will be assigned prior to the hardware
queue selection being made.
One usage for the net_prio cgroup is with mqprio qdisc allowing application
traffic to be steered to hardware/driver based traffic classes. These mappings
can then be managed by administrators or other networking protocols such as
DCBX.

10
Documentation/coccinelle.txt
View File

@@ -102,9 +102,15 @@ or
make coccicheck COCCI=<my_SP.cocci> MODE=report
Using Coccinelle on (modified) files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Controlling Which Files are Processed by Coccinelle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default the entire kernel source tree is checked.
To apply Coccinelle to a specific directory, M= can be used.
For example, to check drivers/net/wireless/ one may write:
make coccicheck M=drivers/net/wireless/
To apply Coccinelle on a file basis, instead of a directory basis, the
following command may be used:

4
Documentation/cpu-freq/governors.txt
View File

@@ -127,7 +127,7 @@ in the bash (as said, 1000 is default), do:
echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
>ondemand/sampling_rate
show_sampling_rate_min:
sampling_rate_min:
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
@@ -140,8 +140,6 @@ HZ=100: min=200000us (200ms)
The highest value of kernel and HW latency restrictions is shown and
used as the minimum sampling rate.
show_sampling_rate_max: THIS INTERFACE IS DEPRECATED, DON'T USE IT.
up_threshold: defines what the average CPU usage between the samplings
of 'sampling_rate' needs to be for the kernel to make a decision on
whether it should increase the frequency. For example when it is set

8
Documentation/development-process/5.Posting
View File

@@ -271,10 +271,10 @@ copies should go to:
the linux-kernel list.
- If you are fixing a bug, think about whether the fix should go into the
next stable update. If so, stable@kernel.org should get a copy of the
patch. Also add a "Cc: stable@kernel.org" to the tags within the patch
itself; that will cause the stable team to get a notification when your
fix goes into the mainline.
next stable update. If so, stable@vger.kernel.org should get a copy of
the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
the patch itself; that will cause the stable team to get a notification
when your fix goes into the mainline.
When selecting recipients for a patch, it is good to have an idea of who
you think will eventually accept the patch and get it merged. While it

5
Documentation/devices.txt
View File

@@ -379,7 +379,7 @@ Your cooperation is appreciated.
162 = /dev/smbus System Management Bus
163 = /dev/lik Logitech Internet Keyboard
164 = /dev/ipmo Intel Intelligent Platform Management
165 = /dev/vmmon VMWare virtual machine monitor
165 = /dev/vmmon VMware virtual machine monitor
166 = /dev/i2o/ctl I2O configuration manager
167 = /dev/specialix_sxctl Specialix serial control
168 = /dev/tcldrv Technology Concepts serial control
@@ -447,6 +447,9 @@ Your cooperation is appreciated.
234 = /dev/btrfs-control Btrfs control device
235 = /dev/autofs Autofs control device
236 = /dev/mapper/control Device-Mapper control device
237 = /dev/loop-control Loopback control device
238 = /dev/vhost-net Host kernel accelerator for virtio net
240-254 Reserved for local use
255 Reserved for MISC_DYNAMIC_MINOR

8
Documentation/devicetree/bindings/arm/fsl.txt
View File

@@ -21,6 +21,10 @@ i.MX53 Smart Mobile Reference Design Board
Required root node properties:
- compatible = "fsl,imx53-smd", "fsl,imx53";
i.MX6 Quad SABRE Automotive Board
i.MX6 Quad Armadillo2 Board
Required root node properties:
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
- compatible = "fsl,imx6q-arm2", "fsl,imx6q";
i.MX6 Quad SABRE Lite Board
Required root node properties:
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";

4
Documentation/devicetree/bindings/arm/gic.txt
View File

@@ -42,6 +42,10 @@ Optional
- interrupts : Interrupt source of the parent interrupt controller. Only
present on secondary GICs.
- cpu-offset : per-cpu offset within the distributor and cpu interface
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
Example:
intc: interrupt-controller@fff11000 {

8
Documentation/devicetree/bindings/arm/insignal-boards.txt Normal file
View File

@@ -0,0 +1,8 @@
* Insignal's Exynos4210 based Origen evaluation board
Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.

8
Documentation/devicetree/bindings/arm/samsung-boards.txt Normal file
View File

@@ -0,0 +1,8 @@
* Samsung's Exynos4210 based SMDKV310 evaluation board
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.

14
Documentation/devicetree/bindings/arm/tegra.txt Normal file
View File

@@ -0,0 +1,14 @@
NVIDIA Tegra device tree bindings
-------------------------------------------
Boards with the tegra20 SoC shall have the following properties:
Required root node property:
compatible = "nvidia,tegra20";
Boards with the tegra30 SoC shall have the following properties:
Required root node property:
compatible = "nvidia,tegra30";

29
Documentation/devicetree/bindings/arm/vic.txt Normal file
View File

@@ -0,0 +1,29 @@
* ARM Vectored Interrupt Controller
One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM
system for interrupt routing. For multiple controllers they can either be
nested or have the outputs wire-OR'd together.
Required properties:
- compatible : should be one of
"arm,pl190-vic"
"arm,pl192-vic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as
the VIC has no configuration options for interrupt sources. The cell is a u32
and defines the interrupt number.
- reg : The register bank for the VIC.
Optional properties:
- interrupts : Interrupt source for parent controllers if the VIC is nested.
Example:
vic0: interrupt-controller@60000 {
compatible = "arm,pl192-vic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x60000 0x1000>;
};

40
Documentation/devicetree/bindings/c6x/clocks.txt Normal file
View File

@@ -0,0 +1,40 @@
C6X PLL Clock Controllers
-------------------------
This is a first-cut support for the SoC clock controllers. This is still
under development and will probably change as the common device tree
clock support is added to the kernel.
Required properties:
- compatible: "ti,c64x+pll"
May also have SoC-specific value to support SoC-specific initialization
in the driver. One of:
"ti,c6455-pll"
"ti,c6457-pll"
"ti,c6472-pll"
"ti,c6474-pll"
- reg: base address and size of register area
- clock-frequency: input clock frequency in hz
Optional properties:
- ti,c64x+pll-bypass-delay: CPU cycles to delay when entering bypass mode
- ti,c64x+pll-reset-delay: CPU cycles to delay after PLL reset
- ti,c64x+pll-lock-delay: CPU cycles to delay after PLL frequency change
Example:
clock-controller@29a0000 {
compatible = "ti,c6472-pll", "ti,c64x+pll";
reg = <0x029a0000 0x200>;
clock-frequency = <25000000>;
ti,c64x+pll-bypass-delay = <200>;
ti,c64x+pll-reset-delay = <12000>;
ti,c64x+pll-lock-delay = <80000>;
};

127
Documentation/devicetree/bindings/c6x/dscr.txt Normal file
View File

@@ -0,0 +1,127 @@
Device State Configuration Registers
------------------------------------
TI C6X SoCs contain a region of miscellaneous registers which provide various
function for SoC control or status. Details vary considerably among from SoC
to SoC with no two being alike.
In general, the Device State Configuraion Registers (DSCR) will provide one or
more configuration registers often protected by a lock register where one or
more key values must be written to a lock register in order to unlock the
configuration register for writes. These configuration register may be used to
enable (and disable in some cases) SoC pin drivers, select peripheral clock
sources (internal or pin), etc. In some cases, a configuration register is
write once or the individual bits are write once. In addition to device config,
the DSCR block may provide registers which which are used to reset peripherals,
provide device ID information, provide ethernet MAC addresses, as well as other
miscellaneous functions.
For device state control (enable/disable), each device control is assigned an
id which is used by individual device drivers to control the state as needed.
Required properties:
- compatible: must be "ti,c64x+dscr"
- reg: register area base and size
Optional properties:
NOTE: These are optional in that not all SoCs will have all properties. For
SoCs which do support a given property, leaving the property out of the
device tree will result in reduced functionality or possibly driver
failure.
- ti,dscr-devstat
offset of the devstat register
- ti,dscr-silicon-rev
offset, start bit, and bitsize of silicon revision field
- ti,dscr-rmii-resets
offset and bitmask of RMII reset field. May have multiple tuples if more
than one ethernet port is available.
- ti,dscr-locked-regs
possibly multiple tuples describing registers which are write protected by
a lock register. Each tuple consists of the register offset, lock register
offsset, and the key value used to unlock the register.
- ti,dscr-kick-regs
offset and key values of two "kick" registers used to write protect other
registers in DSCR. On SoCs using kick registers, the first key must be
written to the first kick register and the second key must be written to
the second register before other registers in the area are write-enabled.
- ti,dscr-mac-fuse-regs
MAC addresses are contained in two registers. Each element of a MAC address
is contained in a single byte. This property has two tuples. Each tuple has
a register offset and four cells representing bytes in the register from
most significant to least. The value of these four cells is the MAC byte
index (1-6) of the byte within the register. A value of 0 means the byte
is unused in the MAC address.
- ti,dscr-devstate-ctl-regs
This property describes the bitfields used to control the state of devices.
Each tuple describes a range of identical bitfields used to control one or
more devices (one bitfield per device). The layout of each tuple is:
start_id num_ids reg enable disable start_bit nbits
Where:
start_id is device id for the first device control in the range
num_ids is the number of device controls in the range
reg is the offset of the register holding the control bits
enable is the value to enable a device
disable is the value to disable a device (0xffffffff if cannot disable)
start_bit is the bit number of the first bit in the range
nbits is the number of bits per device control
- ti,dscr-devstate-stat-regs
This property describes the bitfields used to provide device state status
for device states controlled by the DSCR. Each tuple describes a range of
identical bitfields used to provide status for one or more devices (one
bitfield per device). The layout of each tuple is:
start_id num_ids reg enable disable start_bit nbits
Where:
start_id is device id for the first device status in the range
num_ids is the number of devices covered by the range
reg is the offset of the register holding the status bits
enable is the value indicating device is enabled
disable is the value indicating device is disabled
start_bit is the bit number of the first bit in the range
nbits is the number of bits per device status
- ti,dscr-privperm
Offset and default value for register used to set access privilege for
some SoC devices.
Example:
device-state-config-regs@2a80000 {
compatible = "ti,c64x+dscr";
reg = <0x02a80000 0x41000>;
ti,dscr-devstat = <0>;
ti,dscr-silicon-rev = <8 28 0xf>;
ti,dscr-rmii-resets = <0x40020 0x00040000>;
ti,dscr-locked-regs = <0x40008 0x40004 0x0f0a0b00>;
ti,dscr-devstate-ctl-regs =
<0 12 0x40008 1 0 0 2
12 1 0x40008 3 0 30 2
13 2 0x4002c 1 0xffffffff 0 1>;
ti,dscr-devstate-stat-regs =
<0 10 0x40014 1 0 0 3
10 2 0x40018 1 0 0 3>;
ti,dscr-mac-fuse-regs = <0x700 1 2 3 4
0x704 5 6 0 0>;
ti,dscr-privperm = <0x41c 0xaaaaaaaa>;
ti,dscr-kick-regs = <0x38 0x83E70B13
0x3c 0x95A4F1E0>;
};

62
Documentation/devicetree/bindings/c6x/emifa.txt Normal file
View File

@@ -0,0 +1,62 @@
External Memory Interface
-------------------------
The emifa node describes a simple external bus controller found on some C6X
SoCs. This interface provides external busses with a number of chip selects.
Required properties:
- compatible: must be "ti,c64x+emifa", "simple-bus"
- reg: register area base and size
- #address-cells: must be 2 (chip-select + offset)
- #size-cells: must be 1
- ranges: mapping from EMIFA space to parent space
Optional properties:
- ti,dscr-dev-enable: Device ID if EMIF is enabled/disabled from DSCR
- ti,emifa-burst-priority:
Number of memory transfers after which the EMIF will elevate the priority
of the oldest command in the command FIFO. Setting this field to 255
disables this feature, thereby allowing old commands to stay in the FIFO
indefinitely.
- ti,emifa-ce-config:
Configuration values for each of the supported chip selects.
Example:
emifa@70000000 {
compatible = "ti,c64x+emifa", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x70000000 0x100>;
ranges = <0x2 0x0 0xa0000000 0x00000008
0x3 0x0 0xb0000000 0x00400000
0x4 0x0 0xc0000000 0x10000000
0x5 0x0 0xD0000000 0x10000000>;
ti,dscr-dev-enable = <13>;
ti,emifa-burst-priority = <255>;
ti,emifa-ce-config = <0x00240120
0x00240120
0x00240122
0x00240122>;
flash@3,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x3 0x0 0x400000>;
bank-width = <1>;
device-width = <1>;
partition@0 {
reg = <0x0 0x400000>;
label = "NOR";
};
};
};
This shows a flash chip attached to chip select 3.

104
Documentation/devicetree/bindings/c6x/interrupt.txt Normal file
View File

@@ -0,0 +1,104 @@
C6X Interrupt Chips
-------------------
* C64X+ Core Interrupt Controller
The core interrupt controller provides 16 prioritized interrupts to the
C64X+ core. Priority 0 and 1 are used for reset and NMI respectively.
Priority 2 and 3 are reserved. Priority 4-15 are used for interrupt
sources coming from outside the core.
Required properties:
--------------------
- compatible: Should be "ti,c64x+core-pic";
- #interrupt-cells: <1>
Interrupt Specifier Definition
------------------------------
Single cell specifying the core interrupt priority level (4-15) where
4 is highest priority and 15 is lowest priority.
Example
-------
core_pic: interrupt-controller@0 {
interrupt-controller;
#interrupt-cells = <1>;
compatible = "ti,c64x+core-pic";
};
* C64x+ Megamodule Interrupt Controller
The megamodule PIC consists of four interrupt mupliplexers each of which
combine up to 32 interrupt inputs into a single interrupt output which
may be cascaded into the core interrupt controller. The megamodule PIC
has a total of 12 outputs cascading into the core interrupt controller.
One for each core interrupt priority level. In addition to the combined
interrupt sources, individual megamodule interrupts may be cascaded to
the core interrupt controller. When an individual interrupt is cascaded,
it is no longer handled through a megamodule interrupt combiner and is
considered to have the core interrupt controller as the parent.
Required properties:
--------------------
- compatible: "ti,c64x+megamod-pic"
- interrupt-controller
- #interrupt-cells: <1>
- reg: base address and size of register area
- interrupt-parent: must be core interrupt controller
- interrupts: This should have four cells; one for each interrupt combiner.
The cells contain the core priority interrupt to which the
corresponding combiner output is wired.
Optional properties:
--------------------
- ti,c64x+megamod-pic-mux: Array of 12 cells correspnding to the 12 core
priority interrupts. The first cell corresponds to
core priority 4 and the last cell corresponds to
core priority 15. The value of each cell is the
megamodule interrupt source which is MUXed to
the core interrupt corresponding to the cell
position. Allowed values are 4 - 127. Mapping for
interrupts 0 - 3 (combined interrupt sources) are
ignored.
Interrupt Specifier Definition
------------------------------
Single cell specifying the megamodule interrupt source (4-127). Note that
interrupts mapped directly to the core with "ti,c64x+megamod-pic-mux" will
use the core interrupt controller as their parent and the specifier will
be the core priority level, not the megamodule interrupt number.
Examples
--------
megamod_pic: interrupt-controller@1800000 {
compatible = "ti,c64x+megamod-pic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x1800000 0x1000>;
interrupt-parent = <&core_pic>;
interrupts = < 12 13 14 15 >;
};
This is a minimal example where all individual interrupts go through a
combiner. Combiner-0 is mapped to core interrupt 12, combiner-1 is mapped
to interrupt 13, etc.
megamod_pic: interrupt-controller@1800000 {
compatible = "ti,c64x+megamod-pic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x1800000 0x1000>;
interrupt-parent = <&core_pic>;
interrupts = < 12 13 14 15 >;
ti,c64x+megamod-pic-mux = < 0 0 0 0
32 0 0 0
0 0 0 0 >;
};
This the same as the first example except that megamodule interrupt 32 is
mapped directly to core priority interrupt 8. The node using this interrupt
must set the core controller as its interrupt parent and use 8 in the
interrupt specifier value.

28
Documentation/devicetree/bindings/c6x/soc.txt Normal file
View File

@@ -0,0 +1,28 @@
C6X System-on-Chip
------------------
Required properties:
- compatible: "simple-bus"
- #address-cells: must be 1
- #size-cells: must be 1
- ranges
Optional properties:
- model: specific SoC model
- nodes for IP blocks within SoC
Example:
soc {
compatible = "simple-bus";
model = "tms320c6455";
#address-cells = <1>;
#size-cells = <1>;
ranges;
...
};

26
Documentation/devicetree/bindings/c6x/timer64.txt Normal file
View File

@@ -0,0 +1,26 @@
Timer64
-------
The timer64 node describes C6X event timers.
Required properties:
- compatible: must be "ti,c64x+timer64"
- reg: base address and size of register region
- interrupt-parent: interrupt controller
- interrupts: interrupt id
Optional properties:
- ti,dscr-dev-enable: Device ID used to enable timer IP through DSCR interface.
- ti,core-mask: on multi-core SoCs, bitmask of cores allowed to use this timer.
Example:
timer0: timer@25e0000 {
compatible = "ti,c64x+timer64";
ti,core-mask = < 0x01 >;
reg = <0x25e0000 0x40>;
interrupt-parent = <&megamod_pic>;
interrupts = < 16 >;
};

30
Documentation/devicetree/bindings/dma/arm-pl330.txt Normal file
View File

@@ -0,0 +1,30 @@
* ARM PrimeCell PL330 DMA Controller
The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
between memory and peripherals or memory to memory.
Required properties:
- compatible: should include both "arm,pl330" and "arm,primecell".
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
Example:
pdma0: pdma@12680000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
mem-to-dev) should specify the DMA channel numbers using a two-value pair
as shown below.
[property name] = <[phandle of the dma controller] [dma request id]>;
where 'dma request id' is the dma request number which is connected
to the client controller. The 'property name' is recommended to be
of the form <name>-dma-channel.
Example: tx-dma-channel = <&pdma0 12>;

14
Documentation/devicetree/bindings/dma/atmel-dma.txt Normal file
View File

@@ -0,0 +1,14 @@
* Atmel Direct Memory Access Controller (DMA)
Required properties:
- compatible: Should be "atmel,<chip>-dma"
- reg: Should contain DMA registers location and length
- interrupts: Should contain DMA interrupt
Examples:
dma@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21>;
};

40
Documentation/devicetree/bindings/gpio/gpio-samsung.txt Normal file
View File

@@ -0,0 +1,40 @@
Samsung Exynos4 GPIO Controller
Required properties:
- compatible: Compatible property value should be "samsung,exynos4-gpio>".
- reg: Physical base address of the controller and length of memory mapped
region.
- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
should be the following with values derived from the SoC user manual.
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
[pull up/down]
[drive strength]>
Values for gpio specifier:
- Pin number: is a value between 0 to 7.
- Pull Up/Down: 0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
3 - Pull Up Enabled.
- Drive Strength: 0 - 1x,
1 - 3x,
2 - 2x,
3 - 4x
- gpio-controller: Specifies that the node is a gpio controller.
- #address-cells: should be 1.
- #size-cells: should be 1.
Example:
gpa0: gpio-controller@11400000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "samsung,exynos4-gpio";
reg = <0x11400000 0x20>;
#gpio-cells = <4>;
gpio-controller;
};

22
Documentation/devicetree/bindings/i2c/i2c-designware.txt Normal file
View File

@@ -0,0 +1,22 @@
* Synopsys DesignWare I2C
Required properties :
- compatible : should be "snps,designware-i2c"
- reg : Offset and length of the register set for the device
- interrupts : <IRQ> where IRQ is the interrupt number.
Recommended properties :
- clock-frequency : desired I2C bus clock frequency in Hz.
Example :
i2c@f0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "snps,designware-i2c";
reg = <0xf0000 0x1000>;
interrupts = <11>;
clock-frequency = <400000>;
};

30
Documentation/devicetree/bindings/i2c/omap-i2c.txt Normal file
View File

@@ -0,0 +1,30 @@
I2C for OMAP platforms
Required properties :
- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
- #address-cells = <1>;
- #size-cells = <0>;
Recommended properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
the default 100 kHz frequency will be used.
Optional properties:
- Child nodes conforming to i2c bus binding
Note: Current implementation will fetch base address, irq and dma
from omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Examples :
i2c1: i2c@0 {
compatible = "ti,omap3-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
clock-frequency = <400000>;
};

58
Documentation/devicetree/bindings/i2c/trivial-devices.txt Normal file
View File

@@ -0,0 +1,58 @@
This is a list of trivial i2c devices that have simple device tree
bindings, consisting only of a compatible field, an address and
possibly an interrupt line.
If a device needs more specific bindings, such as properties to
describe some aspect of it, there needs to be a specific binding
document for it just like any other devices.
Compatible Vendor / Chip
========== =============
ad,ad7414 SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin
ad,adm9240 ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems
adi,adt7461 +/-1C TDM Extended Temp Range I.C
adt7461 +/-1C TDM Extended Temp Range I.C
at,24c08 i2c serial eeprom (24cxx)
atmel,24c02 i2c serial eeprom (24cxx)
catalyst,24c32 i2c serial eeprom
dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock
dallas,ds1338 I2C RTC with 56-Byte NV RAM
dallas,ds1339 I2C Serial Real-Time Clock
dallas,ds1340 I2C RTC with Trickle Charger
dallas,ds1374 I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
dallas,ds1631 High-Precision Digital Thermometer
dallas,ds1682 Total-Elapsed-Time Recorder with Alarm
dallas,ds1775 Tiny Digital Thermometer and Thermostat
dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
dallas,ds75 Digital Thermometer and Thermostat
dialog,da9053 DA9053: flexible system level PMIC with multicore support
epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE
epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51
fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
mc,rv3029c2 Real Time Clock Module with I2C-Bus
national,lm75 I2C TEMP SENSOR
national,lm80 Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
national,lm92 ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface
nxp,pca9556 Octal SMBus and I2C registered interface
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
nxp,pcf8563 Real-time clock/calendar
ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus
pericom,pt7c4338 Real-time Clock Module
plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
ramtron,24c64 i2c serial eeprom (24cxx)
ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
st-micro,24c256 i2c serial eeprom (24cxx)
stm,m41t00 Serial Access TIMEKEEPER
stm,m41t62 Serial real-time clock (RTC) with alarm
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
ti,tsc2003 I2C Touch-Screen Controller

88
Documentation/devicetree/bindings/input/samsung-keypad.txt Normal file
View File

@@ -0,0 +1,88 @@
* Samsung's Keypad Controller device tree bindings
Samsung's Keypad controller is used to interface a SoC with a matrix-type
keypad device. The keypad controller supports multiple row and column lines.
A key can be placed at each intersection of a unique row and a unique column.
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.
Required SoC Specific Properties:
- compatible: should be one of the following
- "samsung,s3c6410-keypad": For controllers compatible with s3c6410 keypad
controller.
- "samsung,s5pv210-keypad": For controllers compatible with s5pv210 keypad
controller.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
Required Board Specific Properties:
- samsung,keypad-num-rows: Number of row lines connected to the keypad
controller.
- samsung,keypad-num-columns: Number of column lines connected to the
keypad controller.
- row-gpios: List of gpios used as row lines. The gpio specifier for
this property depends on the gpio controller to which these row lines
are connected.
- col-gpios: List of gpios used as column lines. The gpio specifier for
this property depends on the gpio controller to which these column
lines are connected.
- Keys represented as child nodes: Each key connected to the keypad
controller is represented as a child node to the keypad controller
device node and should include the following properties.
- keypad,row: the row number to which the key is connected.
- keypad,column: the column number to which the key is connected.
- linux,code: the key-code to be reported when the key is pressed
and released.
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
- linux,keypad-wakeup: use any event on keypad as wakeup event.
Example:
keypad@100A0000 {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A0000 0x100>;
interrupts = <173>;
samsung,keypad-num-rows = <2>;
samsung,keypad-num-columns = <8>;
linux,input-no-autorepeat;
linux,input-wakeup;
row-gpios = <&gpx2 0 3 3 0
&gpx2 1 3 3 0>;
col-gpios = <&gpx1 0 3 0 0
&gpx1 1 3 0 0
&gpx1 2 3 0 0
&gpx1 3 3 0 0
&gpx1 4 3 0 0
&gpx1 5 3 0 0
&gpx1 6 3 0 0
&gpx1 7 3 0 0>;
key_1 {
keypad,row = <0>;
keypad,column = <3>;
linux,code = <2>;
};
key_2 {
keypad,row = <0>;
keypad,column = <4>;
linux,code = <3>;
};
key_3 {
keypad,row = <0>;
keypad,column = <5>;
linux,code = <4>;
};
};

18
Documentation/devicetree/bindings/input/tegra-kbc.txt Normal file
View File

@@ -0,0 +1,18 @@
* Tegra keyboard controller
Required properties:
- compatible: "nvidia,tegra20-kbc"
Optional properties:
- debounce-delay: delay in milliseconds per row scan for debouncing
- repeat-delay: delay in milliseconds before repeat starts
- ghost-filter: enable ghost filtering for this device
- wakeup-source: configure keyboard as a wakeup source for suspend/resume
Example:
keyboard: keyboard {
compatible = "nvidia,tegra20-kbc";
reg = <0x7000e200 0x100>;
ghost-filter;
};

78
Documentation/devicetree/bindings/mfd/mc13xxx.txt Normal file
View File

@@ -0,0 +1,78 @@
* Freescale MC13783/MC13892 Power Management Integrated Circuit (PMIC)
Required properties:
- compatible : Should be "fsl,mc13783" or "fsl,mc13892"
Optional properties:
- fsl,mc13xxx-uses-adc : Indicate the ADC is being used
- fsl,mc13xxx-uses-codec : Indicate the Audio Codec is being used
- fsl,mc13xxx-uses-rtc : Indicate the RTC is being used
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
Sub-nodes:
- regulators : Contain the regulator nodes. The MC13892 regulators are
bound using their names as listed below with their registers and bits
for enabling.
vcoincell : regulator VCOINCELL (register 13, bit 23)
sw1 : regulator SW1 (register 24, bit 0)
sw2 : regulator SW2 (register 25, bit 0)
sw3 : regulator SW3 (register 26, bit 0)
sw4 : regulator SW4 (register 27, bit 0)
swbst : regulator SWBST (register 29, bit 20)
vgen1 : regulator VGEN1 (register 32, bit 0)
viohi : regulator VIOHI (register 32, bit 3)
vdig : regulator VDIG (register 32, bit 9)
vgen2 : regulator VGEN2 (register 32, bit 12)
vpll : regulator VPLL (register 32, bit 15)
vusb2 : regulator VUSB2 (register 32, bit 18)
vgen3 : regulator VGEN3 (register 33, bit 0)
vcam : regulator VCAM (register 33, bit 6)
vvideo : regulator VVIDEO (register 33, bit 12)
vaudio : regulator VAUDIO (register 33, bit 15)
vsd : regulator VSD (register 33, bit 18)
gpo1 : regulator GPO1 (register 34, bit 6)
gpo2 : regulator GPO2 (register 34, bit 8)
gpo3 : regulator GPO3 (register 34, bit 10)
gpo4 : regulator GPO4 (register 34, bit 12)
pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
vusb : regulator VUSB (register 50, bit 3)
The bindings details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
Examples:
ecspi@70010000 { /* ECSPI1 */
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
<&gpio3 25 0>; /* GPIO4_25 */
status = "okay";
pmic: mc13892@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mc13892";
spi-max-frequency = <6000000>;
reg = <0>;
interrupt-parent = <&gpio0>;
interrupts = <8>;
regulators {
sw1_reg: mc13892__sw1 {
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1375000>;
regulator-boot-on;
regulator-always-on;
};
sw2_reg: mc13892__sw2 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1850000>;
regulator-boot-on;
regulator-always-on;
};
};
};
};

47
Documentation/devicetree/bindings/mfd/twl-familly.txt Normal file
View File

@@ -0,0 +1,47 @@
Texas Instruments TWL family
The TWLs are Integrated Power Management Chips.
Some version might contain much more analog function like
USB transceiver or Audio amplifier.
These chips are connected to an i2c bus.
Required properties:
- compatible : Must be "ti,twl4030";
For Integrated power-management/audio CODEC device used in OMAP3
based boards
- compatible : Must be "ti,twl6030";
For Integrated power-management used in OMAP4 based boards
- interrupts : This i2c device has an IRQ line connected to the main SoC
- interrupt-controller : Since the twl support several interrupts internally,
it is considered as an interrupt controller cascaded to the SoC one.
- #interrupt-cells = <1>;
- interrupt-parent : The parent interrupt controller.
Optional node:
- Child nodes contain in the twl. The twl family is made of several variants
that support a different number of features.
The children nodes will thus depend of the capability of the variant.
Example:
/*
* Integrated Power Management Chip
* http://www.ti.com/lit/ds/symlink/twl6030.pdf
*/
twl@48 {
compatible = "ti,twl6030";
reg = <0x48>;
interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
twl_rtc {
compatible = "ti,twl_rtc";
interrupts = <11>;
reg = <0>;
};
};

44
Documentation/devicetree/bindings/mtd/gpio-control-nand.txt Normal file
View File

@@ -0,0 +1,44 @@
GPIO assisted NAND flash
The GPIO assisted NAND flash uses a memory mapped interface to
read/write the NAND commands and data and GPIO pins for the control
signals.
Required properties:
- compatible : "gpio-control-nand"
- reg : should specify localbus chip select and size used for the chip. The
resource describes the data bus connected to the NAND flash and all accesses
are made in native endianness.
- #address-cells, #size-cells : Must be present if the device has sub-nodes
representing partitions.
- gpios : specifies the gpio pins to control the NAND device. nwp is an
optional gpio and may be set to 0 if not present.
Optional properties:
- bank-width : Width (in bytes) of the device. If not present, the width
defaults to 1 byte.
- chip-delay : chip dependent delay for transferring data from array to
read registers (tR). If not present then a default of 20us is used.
- gpio-control-nand,io-sync-reg : A 64-bit physical address for a read
location used to guard against bus reordering with regards to accesses to
the GPIO's and the NAND flash data bus. If present, then after changing
GPIO state and before and after command byte writes, this register will be
read to ensure that the GPIO accesses have completed.
Examples:
gpio-nand@1,0 {
compatible = "gpio-control-nand";
reg = <1 0x0000 0x2>;
#address-cells = <1>;
#size-cells = <1>;
gpios = <&banka 1 0 /* rdy */
&banka 2 0 /* nce */
&banka 3 0 /* ale */
&banka 4 0 /* cle */
0 /* nwp */>;
partition@0 {
...
};
};

15
Documentation/devicetree/bindings/net/calxeda-xgmac.txt Normal file
View File

@@ -0,0 +1,15 @@
* Calxeda Highbank 10Gb XGMAC Ethernet
Required properties:
- compatible : Should be "calxeda,hb-xgmac"
- reg : Address and length of the register set for the device
- interrupts : Should contain 3 xgmac interrupts. The 1st is main interrupt.
The 2nd is pwr mgt interrupt. The 3rd is low power state interrupt.
Example:
ethernet@fff50000 {
compatible = "calxeda,hb-xgmac";
reg = <0xfff50000 0x1000>;
interrupts = <0 77 4 0 78 4 0 79 4>;
};

53
Documentation/devicetree/bindings/net/can/cc770.txt Normal file
View File

@@ -0,0 +1,53 @@
Memory mapped Bosch CC770 and Intel AN82527 CAN controller
Note: The CC770 is a CAN controller from Bosch, which is 100%
compatible with the old AN82527 from Intel, but with "bugs" being fixed.
Required properties:
- compatible : should be "bosch,cc770" for the CC770 and "intc,82527"
for the AN82527.
- reg : should specify the chip select, address offset and size required
to map the registers of the controller. The size is usually 0x80.
- interrupts : property with a value describing the interrupt source
(number and sensitivity) required for the controller.
Optional properties:
- bosch,external-clock-frequency : frequency of the external oscillator
clock in Hz. Note that the internal clock frequency used by the
controller is half of that value. If not specified, a default
value of 16000000 (16 MHz) is used.
- bosch,clock-out-frequency : slock frequency in Hz on the CLKOUT pin.
If not specified or if the specified value is 0, the CLKOUT pin
will be disabled.
- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
a resonable value will be calculated.
- bosch,disconnect-rx0-input : see data sheet.
- bosch,disconnect-rx1-input : see data sheet.
- bosch,disconnect-tx1-output : see data sheet.
- bosch,polarity-dominant : see data sheet.
- bosch,divide-memory-clock : see data sheet.
- bosch,iso-low-speed-mux : see data sheet.
For further information, please have a look to the CC770 or AN82527.
Examples:
can@3,100 {
compatible = "bosch,cc770";
reg = <3 0x100 0x80>;
interrupts = <2 0>;
interrupt-parent = <&mpic>;
bosch,external-clock-frequency = <16000000>;
};

25
Documentation/devicetree/bindings/net/macb.txt Normal file
View File

@@ -0,0 +1,25 @@
* Cadence MACB/GEM Ethernet controller
Required properties:
- compatible: Should be "cdns,[<chip>-]{macb|gem}"
Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
the Cadence GEM, or the generic form: "cdns,gem".
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
Optional properties:
- local-mac-address: 6 bytes, mac address
Examples:
macb0: ethernet@fffc4000 {
compatible = "cdns,at32ap7000-macb";
reg = <0xfffc4000 0x4000>;
interrupts = <21>;
phy-mode = "rmii";
local-mac-address = [3a 0e 03 04 05 06];
};

9
Documentation/devicetree/bindings/nvec/nvec_nvidia.txt Normal file
View File

@@ -0,0 +1,9 @@
NVIDIA compliant embedded controller
Required properties:
- compatible : should be "nvidia,nvec".
- reg : the iomem of the i2c slave controller
- interrupts : the interrupt line of the i2c slave controller
- clock-frequency : the frequency of the i2c bus
- gpios : the gpio used for ec request
- slave-addr: the i2c address of the slave controller

5
Documentation/devicetree/bindings/power_supply/olpc_battery.txt Normal file
View File

@@ -0,0 +1,5 @@
OLPC battery
~~~~~~~~~~~~
Required properties:
- compatible : "olpc,xo1-battery"

23
Documentation/devicetree/bindings/power_supply/sbs_sbs-battery.txt Normal file
View File

@@ -0,0 +1,23 @@
SBS sbs-battery
~~~~~~~~~~
Required properties :
- compatible : "sbs,sbs-battery"
Optional properties :
- sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
IO failure.
- sbs,poll-retry-count : The number of times to try looking for new status
after an external change notification.
- sbs,battery-detect-gpios : The gpio which signals battery detection and
a flag specifying its polarity.
Example:
bq20z75@b {
compatible = "sbs,sbs-battery";
reg = < 0xb >;
sbs,i2c-retry-count = <2>;
sbs,poll-retry-count = <10>;
sbs,battery-detect-gpios = <&gpio-controller 122 1>;
}

163
Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt Normal file
View File

@@ -0,0 +1,163 @@
Message unit node:
For SRIO controllers that implement the message unit as part of the controller
this node is required. For devices with RMAN this node should NOT exist. The
node is composed of three types of sub-nodes ("fsl-srio-msg-unit",
"fsl-srio-dbell-unit" and "fsl-srio-port-write-unit").
See srio.txt for more details about generic SRIO controller details.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio-rmu-vX.Y", "fsl,srio-rmu".
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- fsl,liodn
Usage: optional-but-recommended (for devices with PAMU)
Value type: <prop-encoded-array>
Definition: The logical I/O device number for the PAMU (IOMMU) to be
correctly configured for SRIO accesses. The property should
not exist on devices that do not support PAMU.
The LIODN value is associated with all RMU transactions
(msg-unit, doorbell, port-write).
Sub-Nodes for RMU: The RMU node is composed of multiple sub-nodes that
correspond to the actual sub-controllers in the RMU. The manual for a given
SoC will detail which and how many of these sub-controllers are implemented.
Message Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio-msg-unit-vX.Y", "fsl,srio-msg-unit".
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A pair of IRQs are specified in this property. The first
element is associated with the transmit (TX) interrupt and the
second element is associated with the receive (RX) interrupt.
Doorbell Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include:
"fsl,srio-dbell-unit-vX.Y", "fsl,srio-dbell-unit"
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A pair of IRQs are specified in this property. The first
element is associated with the transmit (TX) interrupt and the
second element is associated with the receive (RX) interrupt.
Port-Write Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include:
"fsl,srio-port-write-unit-vX.Y", "fsl,srio-port-write-unit"
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A single IRQ that handles port-write conditions is
specified by this property. (Typically shared with error).
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
Example:
rmu: rmu@d3000 {
compatible = "fsl,srio-rmu";
reg = <0xd3000 0x400>;
ranges = <0x0 0xd3000 0x400>;
fsl,liodn = <0xc8>;
message-unit@0 {
compatible = "fsl,srio-msg-unit";
reg = <0x0 0x100>;
interrupts = <
60 2 0 0 /* msg1_tx_irq */
61 2 0 0>;/* msg1_rx_irq */
};
message-unit@100 {
compatible = "fsl,srio-msg-unit";
reg = <0x100 0x100>;
interrupts = <
62 2 0 0 /* msg2_tx_irq */
63 2 0 0>;/* msg2_rx_irq */
};
doorbell-unit@400 {
compatible = "fsl,srio-dbell-unit";
reg = <0x400 0x80>;
interrupts = <
56 2 0 0 /* bell_outb_irq */
57 2 0 0>;/* bell_inb_irq */
};
port-write-unit@4e0 {
compatible = "fsl,srio-port-write-unit";
reg = <0x4e0 0x20>;
interrupts = <16 2 1 11>;
};
};

103
Documentation/devicetree/bindings/powerpc/fsl/srio.txt Normal file
View File

@@ -0,0 +1,103 @@
* Freescale Serial RapidIO (SRIO) Controller
RapidIO port node:
Properties:
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio" for IP blocks with IP Block
Revision Register (SRIO IPBRR1) Major ID equal to 0x01c0.
Optionally, a compatiable string of "fsl,srio-vX.Y" where X is Major
version in IP Block Revision Register and Y is Minor version. If this
compatiable is provided it should be ordered before "fsl,srio".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers. The size should
be set to 0x11000.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A single IRQ that handles error conditions is specified by this
property. (Typically shared with port-write).
- fsl,srio-rmu-handle:
Usage: required if rmu node is defined
Value type: <phandle>
Definition: A single <phandle> value that points to the RMU.
(See srio-rmu.txt for more details on RMU node binding)
Port Child Nodes: There should a port child node for each port that exists in
the controller. The ports are numbered starting at one (1) and should have
the following properties:
- cell-index
Usage: required
Value type: <u32>
Definition: A standard property. Matches the port id.
- ranges
Usage: required if local access windows preset
Value type: <prop-encoded-array>
Definition: A standard property. Utilized to describe the memory mapped
IO space utilized by the controller. This corresponds to the
setting of the local access windows that are targeted to this
SRIO port.
- fsl,liodn
Usage: optional-but-recommended (for devices with PAMU)
Value type: <prop-encoded-array>
Definition: The logical I/O device number for the PAMU (IOMMU) to be
correctly configured for SRIO accesses. The property should
not exist on devices that do not support PAMU.
For HW (ie, the P4080) that only supports a LIODN for both
memory and maintenance transactions then a single LIODN is
represented in the property for both transactions.
For HW (ie, the P304x/P5020, etc) that supports an LIODN for
memory transactions and a unique LIODN for maintenance
transactions then a pair of LIODNs are represented in the
property. Within the pair, the first element represents the
LIODN associated with memory transactions and the second element
represents the LIODN associated with maintenance transactions
for the port.
Note: All other standard properties (see ePAPR) are allowed but are optional.
Example:
rapidio: rapidio@ffe0c0000 {
#address-cells = <2>;
#size-cells = <2>;
reg = <0xf 0xfe0c0000 0 0x11000>;
compatible = "fsl,srio";
interrupts = <16 2 1 11>; /* err_irq */
fsl,srio-rmu-handle = <&rmu>;
ranges;
port1 {
cell-index = <1>;
#address-cells = <2>;
#size-cells = <2>;
fsl,liodn = <34>;
ranges = <0 0 0xc 0x20000000 0 0x10000000>;
};
port2 {
cell-index = <2>;
#address-cells = <2>;
#size-cells = <2>;
fsl,liodn = <48>;
ranges = <0 0 0xc 0x30000000 0 0x10000000>;
};
};

29
Documentation/devicetree/bindings/regulator/fixed-regulator.txt Normal file
View File

@@ -0,0 +1,29 @@
Fixed Voltage regulators
Required properties:
- compatible: Must be "regulator-fixed";
Optional properties:
- gpio: gpio to use for enable control
- startup-delay-us: startup time in microseconds
- enable-active-high: Polarity of GPIO is Active high
If this property is missing, the default assumed is Active low.
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
However a fixed voltage regulator is expected to have the
regulator-min-microvolt and regulator-max-microvolt
to be the same.
Example:
abc: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "fixed-supply";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
gpio = <&gpio1 16 0>;
startup-delay-us = <70000>;
enable-active-high;
regulator-boot-on
};

54
Documentation/devicetree/bindings/regulator/regulator.txt Normal file
View File

@@ -0,0 +1,54 @@
Voltage/Current Regulators
Optional properties:
- regulator-name: A string used as a descriptive name for regulator outputs
- regulator-min-microvolt: smallest voltage consumers may set
- regulator-max-microvolt: largest voltage consumers may set
- regulator-microvolt-offset: Offset applied to voltages to compensate for voltage drops
- regulator-min-microamp: smallest current consumers may set
- regulator-max-microamp: largest current consumers may set
- regulator-always-on: boolean, regulator should never be disabled
- regulator-boot-on: bootloader/firmware enabled regulator
- <name>-supply: phandle to the parent supply/regulator node
Example:
xyzreg: regulator@0 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <2500000>;
regulator-always-on;
vin-supply = <&vin>;
};
Regulator Consumers:
Consumer nodes can reference one or more of its supplies/
regulators using the below bindings.
- <name>-supply: phandle to the regulator node
These are the same bindings that a regulator in the above
example used to reference its own supply, in which case
its just seen as a special case of a regulator being a
consumer itself.
Example of a consumer device node (mmc) referencing two
regulators (twl_reg1 and twl_reg2),
twl_reg1: regulator@0 {
...
...
...
};
twl_reg2: regulator@1 {
...
...
...
};
mmc: mmc@0x0 {
...
...
vmmc-supply = <&twl_reg1>;
vmmcaux-supply = <&twl_reg2>;
};

54
Documentation/devicetree/bindings/resource-names.txt Normal file
View File

@@ -0,0 +1,54 @@
Some properties contain an ordered list of 1 or more datum which are
normally accessed by index. However, some devices will have multiple
values which are more naturally accessed by name. Device nodes can
include a supplemental property for assigning names to each of the list
items. The names property consists of a list of strings in the same
order as the data in the resource property.
The following supplemental names properties are defined.
Resource Property Supplemental Names Property
----------------- ---------------------------
reg reg-names
clocks clock-names
interrupts interrupt-names
Usage:
The -names property must be used in conjunction with the normal resource
property. If not it will be ignored.
Examples:
l4-abe {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x48000000 0x00001000>, /* MPU path */
<1 0 0x49000000 0x00001000>; /* L3 path */
mcasp {
compatible = "ti,mcasp";
reg = <0 0x10 0x10>, <0 0x20 0x10>,
<1 0x10 0x10>, <1 0x20 0x10>;
reg-names = "mpu", "dat",
"dma", "dma_dat";
interrupts = <11>, <12>;
interrupt-names = "rx", "tx";
};
timer {
compatible = "ti,timer";
reg = <0 0x40 0x10>, <1 0x40 0x10>;
reg-names = "mpu", "dma";
};
};
usb {
compatible = "ti,usb-host";
reg = <0x4a064000 0x800>, <0x4a064800 0x200>,
<0x4a064c00 0x200>;
reg-names = "config", "ohci", "ehci";
interrupts = <14>, <15>;
interrupt-names = "ohci", "ehci";
};

20
Documentation/devicetree/bindings/rtc/s3c-rtc.txt Normal file
View File

@@ -0,0 +1,20 @@
* Samsung's S3C Real Time Clock controller
Required properties:
- compatible: should be one of the following.
* "samsung,s3c2410-rtc" - for controllers compatible with s3c2410 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Two interrupt numbers to the cpu should be specified. First
interrupt number is the rtc alarm interupt and second interrupt number
is the rtc tick interrupt. The number of cells representing a interrupt
depends on the parent interrupt controller.
Example:
rtc@10070000 {
compatible = "samsung,s3c6410-rtc";
reg = <0x10070000 0x100>;
interrupts = <44 0 45 0>;
};

12
Documentation/devicetree/bindings/rtc/twl-rtc.txt Normal file
View File

@@ -0,0 +1,12 @@
* TI twl RTC
The TWL family (twl4030/6030) contains a RTC.
Required properties:
- compatible : Should be twl4030-rtc
Examples:
rtc@0 {
compatible = "ti,twl4030-rtc";
};

10
Documentation/devicetree/bindings/serial/omap_serial.txt Normal file
View File

@@ -0,0 +1,10 @@
OMAP UART controller
Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
- ti,hwmods : Must be "uart<n>", n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART

14
Documentation/devicetree/bindings/serial/samsung_uart.txt Normal file
View File

@@ -0,0 +1,14 @@
* Samsung's UART Controller
The Samsung's UART controller is used for interfacing SoC with serial communicaion
devices.
Required properties:
- compatible: should be
- "samsung,exynos4210-uart", for UART's compatible with Exynos4210 uart ports.
- reg: base physical address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu. The interrupt specifier format depends
on the interrupt controller parent.

71
Documentation/devicetree/bindings/sound/tegra-audio-wm8903.txt Normal file
View File

@@ -0,0 +1,71 @@
NVIDIA Tegra audio complex
Required properties:
- compatible : "nvidia,tegra-audio-wm8903"
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names for sources and
sinks are the WM8903's pins, and the jacks on the board:
WM8903 pins:
* IN1L
* IN1R
* IN2L
* IN2R
* IN3L
* IN3R
* DMICDAT
* HPOUTL
* HPOUTR
* LINEOUTL
* LINEOUTR
* LOP
* LON
* ROP
* RON
* MICBIAS
Board connectors:
* Headphone Jack
* Int Spk
* Mic Jack
- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
- nvidia,audio-codec : The phandle of the WM8903 audio codec
Optional properties:
- nvidia,spkr-en-gpios : The GPIO that enables the speakers
- nvidia,hp-mute-gpios : The GPIO that mutes the headphones
- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in
- nvidia,int-mic-en-gpios : The GPIO that enables the internal microphone
- nvidia,ext-mic-en-gpios : The GPIO that enables the external microphone
Example:
sound {
compatible = "nvidia,tegra-audio-wm8903-harmony",
"nvidia,tegra-audio-wm8903"
nvidia,model = "tegra-wm8903-harmony";
nvidia,audio-routing =
"Headphone Jack", "HPOUTR",
"Headphone Jack", "HPOUTL",
"Int Spk", "ROP",
"Int Spk", "RON",
"Int Spk", "LOP",
"Int Spk", "LON",
"Mic Jack", "MICBIAS",
"IN1L", "Mic Jack";
nvidia,i2s-controller = <&i2s1>;
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&codec 2 0>;
nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
};

12
Documentation/devicetree/bindings/sound/tegra20-das.txt Normal file
View File

@@ -0,0 +1,12 @@
NVIDIA Tegra 20 DAS (Digital Audio Switch) controller
Required properties:
- compatible : "nvidia,tegra20-das"
- reg : Should contain DAS registers location and length
Example:
das@70000c00 {
compatible = "nvidia,tegra20-das";
reg = <0x70000c00 0x80>;
};

17
Documentation/devicetree/bindings/sound/tegra20-i2s.txt Normal file
View File

@@ -0,0 +1,17 @@
NVIDIA Tegra 20 I2S controller
Required properties:
- compatible : "nvidia,tegra20-i2s"
- reg : Should contain I2S registers location and length
- interrupts : Should contain I2S interrupt
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
request selector for this I2S controller
Example:
i2s@70002800 {
compatible = "nvidia,tegra20-i2s";
reg = <0x70002800 0x200>;
interrupts = < 45 >;
nvidia,dma-request-selector = < &apbdma 2 >;
};

50
Documentation/devicetree/bindings/sound/wm8903.txt Normal file
View File

@@ -0,0 +1,50 @@
WM8903 audio CODEC
This device supports I2C only.
Required properties:
- compatible : "wlf,wm8903"
- reg : the I2C address of the device.
- gpio-controller : Indicates this device is a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
Optional properties:
- interrupts : The interrupt line the codec is connected to.
- micdet-cfg : Default register value for R6 (Mic Bias). If absent, the
default is 0.
- micdet-delay : The debounce delay for microphone detection in mS. If
absent, the default is 100.
- gpio-cfg : A list of GPIO configuration register values. The list must
be 5 entries long. If absent, no configuration of these registers is
performed. If any entry has the value 0xffffffff, that GPIO's
configuration will not be modified.
Example:
codec: wm8903@1a {
compatible = "wlf,wm8903";
reg = <0x1a>;
interrupts = < 347 >;
gpio-controller;
#gpio-cells = <2>;
micdet-cfg = <0>;
micdet-delay = <100>;
gpio-cfg = <
0x0600 /* DMIC_LR, output */
0x0680 /* DMIC_DAT, input */
0x0000 /* GPIO, output, low */
0x0200 /* Interrupt, output */
0x01a0 /* BCLK, input, active high */
>;
};

18
Documentation/devicetree/bindings/sound/wm8994.txt Normal file
View File

@@ -0,0 +1,18 @@
WM1811/WM8994/WM8958 audio CODEC
These devices support both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm1811", "wlf,wm8994", "wlf,wm8958"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8994@1a {
compatible = "wlf,wm8994";
reg = <0x1a>;
};

13
Documentation/devicetree/bindings/usb/tegra-usb.txt Normal file
View File

@@ -0,0 +1,13 @@
Tegra SOC USB controllers
The device node for a USB controller that is part of a Tegra
SOC is as described in the document "Open Firmware Recommended
Practice : Universal Serial Bus" with the following modifications
and additions :
Required properties :
- compatible : Should be "nvidia,tegra20-ehci" for USB controllers
used in host mode.
- phy_type : Should be one of "ulpi" or "utmi".
- nvidia,vbus-gpio : If present, specifies a gpio that needs to be
activated for the bus to be powered.

5
Documentation/devicetree/bindings/vendor-prefixes.txt
View File

@@ -8,7 +8,9 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)
arm ARM Ltd.
atmel Atmel Corporation
cavium Cavium, Inc.
chrp Common Hardware Reference Platform
cortina Cortina Systems, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
denx Denx Software Engineering
epson Seiko Epson Corp.
@@ -32,10 +34,13 @@ powervr Imagination Technologies
qcom Qualcomm, Inc.
ramtron Ramtron International
samsung Samsung Semiconductor
sbs Smart Battery System
schindler Schindler
sil Silicon Image
simtek
sirf SiRF Technology, Inc.
st STMicroelectronics
stericsson ST-Ericsson
ti Texas Instruments
wlf Wolfson Microelectronics
xlnx Xilinx

96
Documentation/digsig.txt Normal file
View File

@@ -0,0 +1,96 @@
Digital Signature Verification API
CONTENTS
1. Introduction
2. API
3. User-space utilities
1. Introduction
Digital signature verification API provides a method to verify digital signature.
Currently digital signatures are used by the IMA/EVM integrity protection subsystem.
Digital signature verification is implemented using cut-down kernel port of
GnuPG multi-precision integers (MPI) library. The kernel port provides
memory allocation errors handling, has been refactored according to kernel
coding style, and checkpatch.pl reported errors and warnings have been fixed.
Public key and signature consist of header and MPIs.
struct pubkey_hdr {
uint8_t version; /* key format version */
time_t timestamp; /* key made, always 0 for now */
uint8_t algo;
uint8_t nmpi;
char mpi[0];
} __packed;
struct signature_hdr {
uint8_t version; /* signature format version */
time_t timestamp; /* signature made */
uint8_t algo;
uint8_t hash;
uint8_t keyid[8];
uint8_t nmpi;
char mpi[0];
} __packed;
keyid equals to SHA1[12-19] over the total key content.
Signature header is used as an input to generate a signature.
Such approach insures that key or signature header could not be changed.
It protects timestamp from been changed and can be used for rollback
protection.
2. API
API currently includes only 1 function:
digsig_verify() - digital signature verification with public key
/**
* digsig_verify() - digital signature verification with public key
* @keyring: keyring to search key in
* @sig: digital signature
* @sigen: length of the signature
* @data: data
* @datalen: length of the data
* @return: 0 on success, -EINVAL otherwise
*
* Verifies data integrity against digital signature.
* Currently only RSA is supported.
* Normally hash of the content is used as a data for this function.
*
*/
int digsig_verify(struct key *keyring, const char *sig, int siglen,
const char *data, int datalen);
3. User-space utilities
The signing and key management utilities evm-utils provide functionality
to generate signatures, to load keys into the kernel keyring.
Keys can be in PEM or converted to the kernel format.
When the key is added to the kernel keyring, the keyid defines the name
of the key: 5D2B05FC633EE3E8 in the example bellow.
Here is example output of the keyctl utility.
$ keyctl show
Session Keyring
-3 --alswrv 0 0 keyring: _ses
603976250 --alswrv 0 -1 \_ keyring: _uid.0
817777377 --alswrv 0 0 \_ user: kmk
891974900 --alswrv 0 0 \_ encrypted: evm-key
170323636 --alswrv 0 0 \_ keyring: _module
548221616 --alswrv 0 0 \_ keyring: _ima
128198054 --alswrv 0 0 \_ keyring: _evm
$ keyctl list 128198054
1 key in keyring:
620789745: --alswrv 0 0 user: 5D2B05FC633EE3E8
Dmitry Kasatkin
06.10.2011

228
Documentation/dma-buf-sharing.txt Normal file
View File

@@ -0,0 +1,228 @@
DMA Buffer Sharing API Guide
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sumit Semwal
<sumit dot semwal at linaro dot org>
<sumit dot semwal at ti dot com>
This document serves as a guide to device-driver writers on what is the dma-buf
buffer sharing API, how to use it for exporting and using shared buffers.
Any device driver which wishes to be a part of DMA buffer sharing, can do so as
either the 'exporter' of buffers, or the 'user' of buffers.
Say a driver A wants to use buffers created by driver B, then we call B as the
exporter, and A as buffer-user.
The exporter
- implements and manages operations[1] for the buffer
- allows other users to share the buffer by using dma_buf sharing APIs,
- manages the details of buffer allocation,
- decides about the actual backing storage where this allocation happens,
- takes care of any migration of scatterlist - for all (shared) users of this
buffer,
The buffer-user
- is one of (many) sharing users of the buffer.
- doesn't need to worry about how the buffer is allocated, or where.
- needs a mechanism to get access to the scatterlist that makes up this buffer
in memory, mapped into its own address space, so it can access the same area
of memory.
*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
For this first version, A buffer shared using the dma_buf sharing API:
- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of
this framework.
- may be used *ONLY* by importers that do not need CPU access to the buffer.
The dma_buf buffer sharing API usage contains the following steps:
1. Exporter announces that it wishes to export a buffer
2. Userspace gets the file descriptor associated with the exported buffer, and
passes it around to potential buffer-users based on use case
3. Each buffer-user 'connects' itself to the buffer
4. When needed, buffer-user requests access to the buffer from exporter
5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
6. when buffer-user is done using this buffer completely, it 'disconnects'
itself from the buffer.
1. Exporter's announcement of buffer export
The buffer exporter announces its wish to export a buffer. In this, it
connects its own private buffer data, provides implementation for operations
that can be performed on the exported dma_buf, and flags for the file
associated with this buffer.
Interface:
struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
size_t size, int flags)
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
2. Userspace gets a handle to pass around to potential buffer-users
Userspace entity requests for a file-descriptor (fd) which is a handle to the
anonymous file associated with the buffer. It can then share the fd with other
drivers and/or processes.
Interface:
int dma_buf_fd(struct dma_buf *dmabuf)
This API installs an fd for the anonymous file associated with this buffer;
returns either 'fd', or error.
3. Each buffer-user 'connects' itself to the buffer
Each buffer-user now gets a reference to the buffer, using the fd passed to
it.
Interface:
struct dma_buf *dma_buf_get(int fd)
This API will return a reference to the dma_buf, and increment refcount for
it.
After this, the buffer-user needs to attach its device with the buffer, which
helps the exporter to know of device buffer constraints.
Interface:
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
This API returns reference to an attachment structure, which is then used
for scatterlist operations. It will optionally call the 'attach' dma_buf
operation, if provided by the exporter.
The dma-buf sharing framework does the bookkeeping bits related to managing
the list of all attachments to a buffer.
Until this stage, the buffer-exporter has the option to choose not to actually
allocate the backing storage for this buffer, but wait for the first buffer-user
to request use of buffer for allocation.
4. When needed, buffer-user requests access to the buffer
Whenever a buffer-user wants to use the buffer for any DMA, it asks for
access to the buffer using dma_buf_map_attachment API. At least one attach to
the buffer must have happened before map_dma_buf can be called.
Interface:
struct sg_table * dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
This is a wrapper to dma_buf->ops->map_dma_buf operation, which hides the
"dma_buf->ops->" indirection from the users of this interface.
In struct dma_buf_ops, map_dma_buf is defined as
struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *,
enum dma_data_direction);
It is one of the buffer operations that must be implemented by the exporter.
It should return the sg_table containing scatterlist for this buffer, mapped
into caller's address space.
If this is being called for the first time, the exporter can now choose to
scan through the list of attachments for this buffer, collate the requirements
of the attached devices, and choose an appropriate backing storage for the
buffer.
Based on enum dma_data_direction, it might be possible to have multiple users
accessing at the same time (for reading, maybe), or any other kind of sharing
that the exporter might wish to make available to buffer-users.
map_dma_buf() operation can return -EINTR if it is interrupted by a signal.
5. When finished, the buffer-user notifies end-of-DMA to exporter
Once the DMA for the current buffer-user is over, it signals 'end-of-DMA' to
the exporter using the dma_buf_unmap_attachment API.
Interface:
void dma_buf_unmap_attachment(struct dma_buf_attachment *,
struct sg_table *);
This is a wrapper to dma_buf->ops->unmap_dma_buf() operation, which hides the
"dma_buf->ops->" indirection from the users of this interface.
In struct dma_buf_ops, unmap_dma_buf is defined as
void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
map_dma_buf, this API also must be implemented by the exporter.
6. when buffer-user is done using this buffer, it 'disconnects' itself from the
buffer.
After the buffer-user has no more interest in using this buffer, it should
disconnect itself from the buffer:
- it first detaches itself from the buffer.
Interface:
void dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *dmabuf_attach);
This API removes the attachment from the list in dmabuf, and optionally calls
dma_buf->ops->detach(), if provided by exporter, for any housekeeping bits.
- Then, the buffer-user returns the buffer reference to exporter.
Interface:
void dma_buf_put(struct dma_buf *dmabuf);
This API then reduces the refcount for this buffer.
If, as a result of this call, the refcount becomes 0, the 'release' file
operation related to this fd is called. It calls the dmabuf->ops->release()
operation in turn, and frees the memory allocated for dmabuf when exported.
NOTES:
- Importance of attach-detach and {map,unmap}_dma_buf operation pairs
The attach-detach calls allow the exporter to figure out backing-storage
constraints for the currently-interested devices. This allows preferential
allocation, and/or migration of pages across different types of storage
available, if possible.
Bracketing of DMA access with {map,unmap}_dma_buf operations is essential
to allow just-in-time backing of storage, and migration mid-way through a
use-case.
- Migration of backing storage if needed
If after
- at least one map_dma_buf has happened,
- and the backing storage has been allocated for this buffer,
another new buffer-user intends to attach itself to this buffer, it might
be allowed, if possible for the exporter.
In case it is allowed by the exporter:
if the new buffer-user has stricter 'backing-storage constraints', and the
exporter can handle these constraints, the exporter can just stall on the
map_dma_buf until all outstanding access is completed (as signalled by
unmap_dma_buf).
Once all users have finished accessing and have unmapped this buffer, the
exporter could potentially move the buffer to the stricter backing-storage,
and then allow further {map,unmap}_dma_buf operations from any buffer-user
from the migrated backing-storage.
If the exporter cannot fulfil the backing-storage constraints of the new
buffer-user device as requested, dma_buf_attach() would return an error to
denote non-compatibility of the new buffer-sharing request with the current
buffer.
If the exporter chooses not to allow an attach() operation once a
map_dma_buf() API has been called, it simply returns an error.
Miscellaneous notes:
- Any exporters or users of the dma-buf buffer sharing framework must have
a 'select DMA_SHARED_BUFFER' in their respective Kconfigs.
References:
[1] struct dma_buf_ops in include/linux/dma-buf.h
[2] All interfaces mentioned above defined in include/linux/dma-buf.h

8
Documentation/dmaengine.txt
View File

@@ -75,6 +75,10 @@ The slave DMA usage consists of following steps:
slave_sg - DMA a list of scatter gather buffers from/to a peripheral
dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the
operation is explicitly stopped.
interleaved_dma - This is common to Slave as well as M2M clients. For slave
address of devices' fifo could be already known to the driver.
Various types of operations could be expressed by setting
appropriate values to the 'dma_interleaved_template' members.
A non-NULL return of this transfer API represents a "descriptor" for
the given transaction.
@@ -89,6 +93,10 @@ The slave DMA usage consists of following steps:
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_data_direction direction);
struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
struct dma_chan *chan, struct dma_interleaved_template *xt,
unsigned long flags);
The peripheral driver is expected to have mapped the scatterlist for
the DMA operation prior to calling device_prep_slave_sg, and must
keep the scatterlist mapped until the DMA operation has completed.

1
Documentation/dontdiff
View File

@@ -66,7 +66,6 @@ GRTAGS
GSYMS
GTAGS
Image
Kerntypes
Module.markers
Module.symvers
PENDING

1
Documentation/driver-model/devres.txt
View File

@@ -262,6 +262,7 @@ IOMAP
devm_ioremap()
devm_ioremap_nocache()
devm_iounmap()
devm_request_and_ioremap() : checks resource, requests region, ioremaps
pcim_iomap()
pcim_iounmap()
pcim_iomap_table() : array of mapped addresses indexed by BAR

306
Documentation/fb/api.txt Normal file
View File

@@ -0,0 +1,306 @@
The Frame Buffer Device API
---------------------------
Last revised: June 21, 2011
0. Introduction
---------------
This document describes the frame buffer API used by applications to interact
with frame buffer devices. In-kernel APIs between device drivers and the frame
buffer core are not described.
Due to a lack of documentation in the original frame buffer API, drivers
behaviours differ in subtle (and not so subtle) ways. This document describes
the recommended API implementation, but applications should be prepared to
deal with different behaviours.
1. Capabilities
---------------
Device and driver capabilities are reported in the fixed screen information
capabilities field.
struct fb_fix_screeninfo {
...
__u16 capabilities; /* see FB_CAP_* */
...
};
Application should use those capabilities to find out what features they can
expect from the device and driver.
- FB_CAP_FOURCC
The driver supports the four character code (FOURCC) based format setting API.
When supported, formats are configured using a FOURCC instead of manually
specifying color components layout.
2. Types and visuals
--------------------
Pixels are stored in memory in hardware-dependent formats. Applications need
to be aware of the pixel storage format in order to write image data to the
frame buffer memory in the format expected by the hardware.
Formats are described by frame buffer types and visuals. Some visuals require
additional information, which are stored in the variable screen information
bits_per_pixel, grayscale, red, green, blue and transp fields.
Visuals describe how color information is encoded and assembled to create
macropixels. Types describe how macropixels are stored in memory. The following
types and visuals are supported.
- FB_TYPE_PACKED_PIXELS
Macropixels are stored contiguously in a single plane. If the number of bits
per macropixel is not a multiple of 8, whether macropixels are padded to the
next multiple of 8 bits or packed together into bytes depends on the visual.
Padding at end of lines may be present and is then reported through the fixed
screen information line_length field.
- FB_TYPE_PLANES
Macropixels are split across multiple planes. The number of planes is equal to
the number of bits per macropixel, with plane i'th storing i'th bit from all
macropixels.
Planes are located contiguously in memory.
- FB_TYPE_INTERLEAVED_PLANES
Macropixels are split across multiple planes. The number of planes is equal to
the number of bits per macropixel, with plane i'th storing i'th bit from all
macropixels.
Planes are interleaved in memory. The interleave factor, defined as the
distance in bytes between the beginning of two consecutive interleaved blocks
belonging to different planes, is stored in the fixed screen information
type_aux field.
- FB_TYPE_FOURCC
Macropixels are stored in memory as described by the format FOURCC identifier
stored in the variable screen information grayscale field.
- FB_VISUAL_MONO01
Pixels are black or white and stored on a number of bits (typically one)
specified by the variable screen information bpp field.
Black pixels are represented by all bits set to 1 and white pixels by all bits
set to 0. When the number of bits per pixel is smaller than 8, several pixels
are packed together in a byte.
FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
- FB_VISUAL_MONO10
Pixels are black or white and stored on a number of bits (typically one)
specified by the variable screen information bpp field.
Black pixels are represented by all bits set to 0 and white pixels by all bits
set to 1. When the number of bits per pixel is smaller than 8, several pixels
are packed together in a byte.
FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
- FB_VISUAL_TRUECOLOR
Pixels are broken into red, green and blue components, and each component
indexes a read-only lookup table for the corresponding value. Lookup tables
are device-dependent, and provide linear or non-linear ramps.
Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields.
- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
Pixel values are encoded as indices into a colormap that stores red, green and
blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
and read-write for FB_VISUAL_PSEUDOCOLOR.
Each pixel value is stored in the number of bits reported by the variable
screen information bits_per_pixel field.
- FB_VISUAL_DIRECTCOLOR
Pixels are broken into red, green and blue components, and each component
indexes a programmable lookup table for the corresponding value.
Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields.
- FB_VISUAL_FOURCC
Pixels are encoded and interpreted as described by the format FOURCC
identifier stored in the variable screen information grayscale field.
3. Screen information
---------------------
Screen information are queried by applications using the FBIOGET_FSCREENINFO
and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
fb_fix_screeninfo and fb_var_screeninfo structure respectively.
struct fb_fix_screeninfo stores device independent unchangeable information
about the frame buffer device and the current format. Those information can't
be directly modified by applications, but can be changed by the driver when an
application modifies the format.
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
/* (physical address) */
__u32 smem_len; /* Length of frame buffer mem */
__u32 type; /* see FB_TYPE_* */
__u32 type_aux; /* Interleave for interleaved Planes */
__u32 visual; /* see FB_VISUAL_* */
__u16 xpanstep; /* zero if no hardware panning */
__u16 ypanstep; /* zero if no hardware panning */
__u16 ywrapstep; /* zero if no hardware ywrap */
__u32 line_length; /* length of a line in bytes */
unsigned long mmio_start; /* Start of Memory Mapped I/O */
/* (physical address) */
__u32 mmio_len; /* Length of Memory Mapped I/O */
__u32 accel; /* Indicate to driver which */
/* specific chip/card we have */
__u16 capabilities; /* see FB_CAP_* */
__u16 reserved[2]; /* Reserved for future compatibility */
};
struct fb_var_screeninfo stores device independent changeable information
about a frame buffer device, its current format and video mode, as well as
other miscellaneous parameters.
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* 0 = color, 1 = grayscale, */
/* >1 = FOURCC */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
__u32 activate; /* see FB_ACTIVATE_* */
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
__u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
__u32 left_margin; /* time from sync to picture */
__u32 right_margin; /* time from picture to sync */
__u32 upper_margin; /* time from sync to picture */
__u32 lower_margin;
__u32 hsync_len; /* length of horizontal sync */
__u32 vsync_len; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 rotate; /* angle we rotate counter clockwise */
__u32 colorspace; /* colorspace for FOURCC-based modes */
__u32 reserved[4]; /* Reserved for future compatibility */
};
To modify variable information, applications call the FBIOPUT_VSCREENINFO
ioctl with a pointer to a fb_var_screeninfo structure. If the call is
successful, the driver will update the fixed screen information accordingly.
Instead of filling the complete fb_var_screeninfo structure manually,
applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
fields they care about.
4. Format configuration
-----------------------
Frame buffer devices offer two ways to configure the frame buffer format: the
legacy API and the FOURCC-based API.
The legacy API has been the only frame buffer format configuration API for a
long time and is thus widely used by application. It is the recommended API
for applications when using RGB and grayscale formats, as well as legacy
non-standard formats.
To select a format, applications set the fb_var_screeninfo bits_per_pixel field
to the desired frame buffer depth. Values up to 8 will usually map to
monochrome, grayscale or pseudocolor visuals, although this is not required.
- For grayscale formats, applications set the grayscale field to one. The red,
blue, green and transp fields must be set to 0 by applications and ignored by
drivers. Drivers must fill the red, blue and green offsets to 0 and lengths
to the bits_per_pixel value.
- For pseudocolor formats, applications set the grayscale field to zero. The
red, blue, green and transp fields must be set to 0 by applications and
ignored by drivers. Drivers must fill the red, blue and green offsets to 0
and lengths to the bits_per_pixel value.
- For truecolor and directcolor formats, applications set the grayscale field
to zero, and the red, blue, green and transp fields to describe the layout of
color components in memory.
struct fb_bitfield {
__u32 offset; /* beginning of bitfield */
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Pixel values are bits_per_pixel wide and are split in non-overlapping red,
green, blue and alpha (transparency) components. Location and size of each
component in the pixel value are described by the fb_bitfield offset and
length fields. Offset are computed from the right.
Pixels are always stored in an integer number of bytes. If the number of
bits per pixel is not a multiple of 8, pixel values are padded to the next
multiple of 8 bits.
Upon successful format configuration, drivers update the fb_fix_screeninfo
type, visual and line_length fields depending on the selected format.
The FOURCC-based API replaces format descriptions by four character codes
(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
without explicitly describing it. This is the only API that supports YUV
formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
and grayscale formats.
Drivers that support the FOURCC-based API report this capability by setting
the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
FOURCC definitions are located in the linux/videodev2.h header. However, and
despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
and don't require usage of the V4L2 subsystem. FOURCC documentation is
available in Documentation/DocBook/v4l/pixfmt.xml.
To select a format, applications set the grayscale field to the desired FOURCC.
For YUV formats, they should also select the appropriate colorspace by setting
the colorspace field to one of the colorspaces listed in linux/videodev2.h and
documented in Documentation/DocBook/v4l/colorspaces.xml.
The red, green, blue and transp fields are not used with the FOURCC-based API.
For forward compatibility reasons applications must zero those fields, and
drivers must ignore them. Values other than 0 may get a meaning in future
extensions.
Upon successful format configuration, drivers update the fb_fix_screeninfo
type, visual and line_length fields depending on the selected format. The type
and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.

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

@@ -85,17 +85,6 @@ Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
---------------------------
What: Deprecated snapshot ioctls
When: 2.6.36
Why: The ioctls in kernel/power/user.c were marked as deprecated long time
ago. Now they notify users about that so that they need to replace
their userspace. After some more time, remove them completely.
Who: Jiri Slaby <jirislaby@gmail.com>
---------------------------
What: The ieee80211_regdom module parameter
When: March 2010 / desktop catchup
@@ -263,8 +252,7 @@ Who: Ravikiran Thirumalai <kiran@scalex86.org>
What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS
(in net/core/net-sysfs.c)
When: After the only user (hal) has seen a release with the patches
for enough time, probably some time in 2010.
When: 3.5
Why: Over 1K .text/.data size reduction, data is available in other
ways (ioctls)
Who: Johannes Berg <johannes@sipsolutions.net>
@@ -362,15 +350,6 @@ Who: anybody or Florian Mickler <florian@mickler.org>
----------------------------
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
on newer and older hardware. It is already not exposed to the guest,
and kept only for live migration purposes.
Who: Avi Kivity <avi@redhat.com>
----------------------------
What: iwlwifi 50XX module parameters
When: 3.0
Why: The "..50" modules parameters were used to configure 5000 series and
@@ -489,6 +468,20 @@ Why: In 3.0, we can now autodetect internal 3G device and already have
information log when acer-wmi initial.
Who: Lee, Chun-Yi <jlee@novell.com>
---------------------------
What: /sys/devices/platform/_UDC_/udc/_UDC_/is_dualspeed file and
is_dualspeed line in /sys/devices/platform/ci13xxx_*/udc/device file.
When: 3.8
Why: The is_dualspeed file is superseded by maximum_speed in the same
directory and is_dualspeed line in device file is superseded by
max_speed line in the same file.
The maximum_speed/max_speed specifies maximum speed supported by UDC.
To check if dualspeeed is supported, check if the value is >= 3.
Various possible speeds are defined in <linux/usb/ch9.h>.
Who: Michal Nazarewicz <mina86@mina86.com>
----------------------------
What: The XFS nodelaylog mount option
@@ -505,3 +498,15 @@ When: 3.5
Why: The iwlagn module has been renamed iwlwifi. The alias will be around
for backward compatibility for several cycles and then dropped.
Who: Don Fry <donald.h.fry@intel.com>
----------------------------
What: pci_scan_bus_parented()
When: 3.5
Why: The pci_scan_bus_parented() interface creates a new root bus. The
bus is created with default resources (ioport_resource and
iomem_resource) that are always wrong, so we rely on arch code to
correct them later. Callers of pci_scan_bus_parented() should
convert to using pci_scan_root_bus() so they can supply a list of
bus resources when the bus is created.
Who: Bjorn Helgaas <bhelgaas@google.com>

8
Documentation/filesystems/Locking
View File

@@ -37,15 +37,15 @@ d_manage: no no yes (ref-walk) maybe
--------------------------- inode_operations ---------------------------
prototypes:
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
int (*create) (struct inode *,struct dentry *,umode_t, struct nameidata *);
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameid
ata *);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
int (*symlink) (struct inode *,struct dentry *,const char *);
int (*mkdir) (struct inode *,struct dentry *,int);
int (*mkdir) (struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
int (*mknod) (struct inode *,struct dentry *,int,dev_t);
int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
int (*rename) (struct inode *, struct dentry *,
struct inode *, struct dentry *);
int (*readlink) (struct dentry *, char __user *,int);
@@ -117,7 +117,7 @@ prototypes:
int (*statfs) (struct dentry *, struct kstatfs *);
int (*remount_fs) (struct super_block *, int *, char *);
void (*umount_begin) (struct super_block *);
int (*show_options)(struct seq_file *, struct vfsmount *);
int (*show_options)(struct seq_file *, struct dentry *);
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);

18
Documentation/filesystems/ceph.txt
View File

@@ -119,12 +119,20 @@ Mount Options
must rely on TCP's error correction to detect data corruption
in the data payload.
noasyncreaddir
Disable client's use its local cache to satisfy readdir
requests. (This does not change correctness; the client uses
cached metadata only when a lease or capability ensures it is
valid.)
dcache
Use the dcache contents to perform negative lookups and
readdir when the client has the entire directory contents in
its cache. (This does not change correctness; the client uses
cached metadata only when a lease or capability ensures it is
valid.)
nodcache
Do not use the dcache as above. This avoids a significant amount of
complex code, sacrificing performance without affecting correctness,
and is useful for tracking down bugs.
noasyncreaddir
Do not use the dcache as above for readdir.
More Information
================

2
Documentation/filesystems/configfs/configfs.txt
View File

@@ -192,7 +192,7 @@ attribute value uses the store_attribute() method.
struct configfs_attribute {
char *ca_name;
struct module *ca_owner;
mode_t ca_mode;
umode_t ca_mode;
};
When a config_item wants an attribute to appear as a file in the item's

56
Documentation/filesystems/debugfs.txt
View File

@@ -35,7 +35,7 @@ described below will work.
The most general way to create a file within a debugfs directory is with:
struct dentry *debugfs_create_file(const char *name, mode_t mode,
struct dentry *debugfs_create_file(const char *name, umode_t mode,
struct dentry *parent, void *data,
const struct file_operations *fops);
@@ -53,13 +53,13 @@ actually necessary; the debugfs code provides a number of helper functions
for simple situations. Files containing a single integer value can be
created with any of:
struct dentry *debugfs_create_u8(const char *name, mode_t mode,
struct dentry *debugfs_create_u8(const char *name, umode_t mode,
struct dentry *parent, u8 *value);
struct dentry *debugfs_create_u16(const char *name, mode_t mode,
struct dentry *debugfs_create_u16(const char *name, umode_t mode,
struct dentry *parent, u16 *value);
struct dentry *debugfs_create_u32(const char *name, mode_t mode,
struct dentry *debugfs_create_u32(const char *name, umode_t mode,
struct dentry *parent, u32 *value);
struct dentry *debugfs_create_u64(const char *name, mode_t mode,
struct dentry *debugfs_create_u64(const char *name, umode_t mode,
struct dentry *parent, u64 *value);
These files support both reading and writing the given value; if a specific
@@ -67,13 +67,13 @@ file should not be written to, simply set the mode bits accordingly. The
values in these files are in decimal; if hexadecimal is more appropriate,
the following functions can be used instead:
struct dentry *debugfs_create_x8(const char *name, mode_t mode,
struct dentry *debugfs_create_x8(const char *name, umode_t mode,
struct dentry *parent, u8 *value);
struct dentry *debugfs_create_x16(const char *name, mode_t mode,
struct dentry *debugfs_create_x16(const char *name, umode_t mode,
struct dentry *parent, u16 *value);
struct dentry *debugfs_create_x32(const char *name, mode_t mode,
struct dentry *debugfs_create_x32(const char *name, umode_t mode,
struct dentry *parent, u32 *value);
struct dentry *debugfs_create_x64(const char *name, mode_t mode,
struct dentry *debugfs_create_x64(const char *name, umode_t mode,
struct dentry *parent, u64 *value);
These functions are useful as long as the developer knows the size of the
@@ -81,7 +81,7 @@ value to be exported. Some types can have different widths on different
architectures, though, complicating the situation somewhat. There is a
function meant to help out in one special case:
struct dentry *debugfs_create_size_t(const char *name, mode_t mode,
struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
struct dentry *parent,
size_t *value);
@@ -90,21 +90,22 @@ a variable of type size_t.
Boolean values can be placed in debugfs with:
struct dentry *debugfs_create_bool(const char *name, mode_t mode,
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
struct dentry *parent, u32 *value);
A read on the resulting file will yield either Y (for non-zero values) or
N, followed by a newline. If written to, it will accept either upper- or
lower-case values, or 1 or 0. Any other input will be silently ignored.
Finally, a block of arbitrary binary data can be exported with:
Another option is exporting a block of arbitrary binary data, with
this structure and function:
struct debugfs_blob_wrapper {
void *data;
unsigned long size;
};
struct dentry *debugfs_create_blob(const char *name, mode_t mode,
struct dentry *debugfs_create_blob(const char *name, umode_t mode,
struct dentry *parent,
struct debugfs_blob_wrapper *blob);
@@ -115,6 +116,35 @@ can be used to export binary information, but there does not appear to be
any code which does so in the mainline. Note that all files created with
debugfs_create_blob() are read-only.
If you want to dump a block of registers (something that happens quite
often during development, even if little such code reaches mainline.
Debugfs offers two functions: one to make a registers-only file, and
another to insert a register block in the middle of another sequential
file.
struct debugfs_reg32 {
char *name;
unsigned long offset;
};
struct debugfs_regset32 {
struct debugfs_reg32 *regs;
int nregs;
void __iomem *base;
};
struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
struct dentry *parent,
struct debugfs_regset32 *regset);
int debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs,
int nregs, void __iomem *base, char *prefix);
The "base" argument may be 0, but you may want to build the reg32 array
using __stringify, and a number of register names (macros) are actually
byte offsets over a base for the register block.
There are a couple of other directory-oriented helper functions:
struct dentry *debugfs_rename(struct dentry *old_dir,

7
Documentation/filesystems/ext4.txt
View File

@@ -581,6 +581,13 @@ Table of Ext4 specific ioctls
behaviour may change in the future as it is
not necessary and has been done this way only
for sake of simplicity.
EXT4_IOC_RESIZE_FS Resize the filesystem to a new size. The number
of blocks of resized filesystem is passed in via
64 bit integer argument. The kernel allocates
bitmaps and inode table, the userspace tool thus
just passes the new number of blocks.
..............................................................................
References

2
Documentation/filesystems/nfs/00-INDEX
View File

@@ -2,6 +2,8 @@
- this file (nfs-related documentation).
Exporting
- explanation of how to make filesystems exportable.
fault_injection.txt
- information for using fault injection on the server
knfsd-stats.txt
- statistics which the NFS server makes available to user space.
nfs.txt

69
Documentation/filesystems/nfs/fault_injection.txt Normal file
View File

@@ -0,0 +1,69 @@
Fault Injection
===============
Fault injection is a method for forcing errors that may not normally occur, or
may be difficult to reproduce. Forcing these errors in a controlled environment
can help the developer find and fix bugs before their code is shipped in a
production system. Injecting an error on the Linux NFS server will allow us to
observe how the client reacts and if it manages to recover its state correctly.
NFSD_FAULT_INJECTION must be selected when configuring the kernel to use this
feature.
Using Fault Injection
=====================
On the client, mount the fault injection server through NFS v4.0+ and do some
work over NFS (open files, take locks, ...).
On the server, mount the debugfs filesystem to <debug_dir> and ls
<debug_dir>/nfsd. This will show a list of files that will be used for
injecting faults on the NFS server. As root, write a number n to the file
corresponding to the action you want the server to take. The server will then
process the first n items it finds. So if you want to forget 5 locks, echo '5'
to <debug_dir>/nfsd/forget_locks. A value of 0 will tell the server to forget
all corresponding items. A log message will be created containing the number
of items forgotten (check dmesg).
Go back to work on the client and check if the client recovered from the error
correctly.
Available Faults
================
forget_clients:
The NFS server keeps a list of clients that have placed a mount call. If
this list is cleared, the server will have no knowledge of who the client
is, forcing the client to reauthenticate with the server.
forget_openowners:
The NFS server keeps a list of what files are currently opened and who
they were opened by. Clearing this list will force the client to reopen
its files.
forget_locks:
The NFS server keeps a list of what files are currently locked in the VFS.
Clearing this list will force the client to reclaim its locks (files are
unlocked through the VFS as they are cleared from this list).
forget_delegations:
A delegation is used to assure the client that a file, or part of a file,
has not changed since the delegation was awarded. Clearing this list will
force the client to reaquire its delegation before accessing the file
again.
recall_delegations:
Delegations can be recalled by the server when another client attempts to
access a file. This test will notify the client that its delegation has
been revoked, forcing the client to reaquire the delegation before using
the file again.
tools/nfs/inject_faults.sh script
=================================
This script has been created to ease the fault injection process. This script
will detect the mounted debugfs directory and write to the files located there
based on the arguments passed by the user. For example, running
`inject_faults.sh forget_locks 1` as root will instruct the server to forget
one lock. Running `inject_faults forget_locks` will instruct the server to
forgetall locks.

42
Documentation/filesystems/proc.txt
View File

@@ -41,6 +41,8 @@ Table of Contents
3.5 /proc/<pid>/mountinfo - Information about mounts
3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm
4 Configuring procfs
4.1 Mount options
------------------------------------------------------------------------------
Preface
@@ -305,6 +307,9 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
blkio_ticks time spent waiting for block IO
gtime guest time of the task in jiffies
cgtime guest time of the task children in jiffies
start_data address above which program data+bss is placed
end_data address below which program data+bss is placed
start_brk address above which program heap can be expanded with brk()
..............................................................................
The /proc/PID/maps file containing the currently mapped memory regions and
@@ -1542,3 +1547,40 @@ a task to set its own or one of its thread siblings comm value. The comm value
is limited in size compared to the cmdline value, so writing anything longer
then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
comm value.
------------------------------------------------------------------------------
Configuring procfs
------------------------------------------------------------------------------
4.1 Mount options
---------------------
The following mount options are supported:
hidepid= Set /proc/<pid>/ access mode.
gid= Set the group authorized to learn processes information.
hidepid=0 means classic mode - everybody may access all /proc/<pid>/ directories
(default).
hidepid=1 means users may not access any /proc/<pid>/ directories but their
own. Sensitive files like cmdline, sched*, status are now protected against
other users. This makes it impossible to learn whether any user runs
specific program (given the program doesn't reveal itself by its behaviour).
As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
poorly written programs passing sensitive information via program arguments are
now protected against local eavesdroppers.
hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
users. It doesn't mean that it hides a fact whether a process with a specific
pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
but it hides process' uid and gid, which may be learned by stat()'ing
/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
information about running processes, whether some daemon runs with elevated
privileges, whether other user runs some sensitive program, whether other users
run any program at all, etc.
gid= defines a group authorized to learn processes information otherwise
prohibited by hidepid=. If you use some daemon like identd which needs to learn
information about processes information, just add identd to this group.

6
Documentation/filesystems/squashfs.txt
View File

@@ -93,8 +93,8 @@ byte alignment:
Compressed data blocks are written to the filesystem as files are read from
the source directory, and checked for duplicates. Once all file data has been
written the completed inode, directory, fragment, export and uid/gid lookup
tables are written.
written the completed inode, directory, fragment, export, uid/gid lookup and
xattr tables are written.
3.1 Compression options
-----------------------
@@ -151,7 +151,7 @@ in each metadata block. Directories are sorted in alphabetical order,
and at lookup the index is scanned linearly looking for the first filename
alphabetically larger than the filename being looked up. At this point the
location of the metadata block the filename is in has been found.
The general idea of the index is ensure only one metadata block needs to be
The general idea of the index is to ensure only one metadata block needs to be
decompressed to do a lookup irrespective of the length of the directory.
This scheme has the advantage that it doesn't require extra memory overhead
and doesn't require much extra storage on disk.

2
Documentation/filesystems/sysfs.txt
View File

@@ -70,7 +70,7 @@ An attribute definition is simply:
struct attribute {
char * name;
struct module *owner;
mode_t mode;
umode_t mode;
};

8
Documentation/filesystems/vfs.txt
View File

@@ -225,7 +225,7 @@ struct super_operations {
void (*clear_inode) (struct inode *);
void (*umount_begin) (struct super_block *);
int (*show_options)(struct seq_file *, struct vfsmount *);
int (*show_options)(struct seq_file *, struct dentry *);
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
@@ -341,14 +341,14 @@ This describes how the VFS can manipulate an inode in your
filesystem. As of kernel 2.6.22, the following members are defined:
struct inode_operations {
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
int (*create) (struct inode *,struct dentry *, umode_t, struct nameidata *);
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
int (*symlink) (struct inode *,struct dentry *,const char *);
int (*mkdir) (struct inode *,struct dentry *,int);
int (*mkdir) (struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
int (*mknod) (struct inode *,struct dentry *,int,dev_t);
int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
int (*rename) (struct inode *, struct dentry *,
struct inode *, struct dentry *);
int (*readlink) (struct dentry *, char __user *,int);

13
Documentation/hwmon/it87
View File

@@ -26,6 +26,10 @@ Supported chips:
Prefix: 'it8721'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* IT8728F
Prefix: 'it8728'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* SiS950 [clone of IT8705F]
Prefix: 'it87'
Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -71,7 +75,7 @@ Description
-----------
This driver implements support for the IT8705F, IT8712F, IT8716F,
IT8718F, IT8720F, IT8721F, IT8726F, IT8758E and SiS950 chips.
IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -105,6 +109,9 @@ The IT8726F is just bit enhanced IT8716F with additional hardware
for AMD power sequencing. Therefore the chip will appear as IT8716F
to userspace applications.
The IT8728F is considered compatible with the IT8721F, until a datasheet
becomes available (hopefully.)
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.
@@ -121,8 +128,8 @@ alarm is triggered if the voltage has crossed a programmable minimum or
maximum limit. Note that minimum in this case always means 'closest to
zero'; this is important for negative voltage measurements. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
0.016 volt (except IT8721F/IT8758E: 0.012 volt.) The battery voltage in8 does
not have limit registers.
0.016 volt (except IT8721F/IT8758E and IT8728F: 0.012 volt.) The battery
voltage in8 does not have limit registers.
On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside
the chip (in7, in8 and optionally in3). The driver handles this transparently

21
Documentation/hwmon/lm63
View File

@@ -12,6 +12,11 @@ Supported chips:
Addresses scanned: I2C 0x18 and 0x4e
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM64.html
* National Semiconductor LM96163
Prefix: 'lm96163'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM96163.html
Author: Jean Delvare <khali@linux-fr.org>
@@ -49,16 +54,24 @@ value for measuring the speed of the fan. It can measure fan speeds down to
Note that the pin used for fan monitoring is shared with an alert out
function. Depending on how the board designer wanted to use the chip, fan
speed monitoring will or will not be possible. The proper chip configuration
is left to the BIOS, and the driver will blindly trust it.
is left to the BIOS, and the driver will blindly trust it. Only the original
LM63 suffers from this limitation, the LM64 and LM96163 have separate pins
for fan monitoring and alert out. On the LM64, monitoring is always enabled;
on the LM96163 it can be disabled.
A PWM output can be used to control the speed of the fan. The LM63 has two
PWM modes: manual and automatic. Automatic mode is not fully implemented yet
(you cannot define your custom PWM/temperature curve), and mode change isn't
supported either.
The lm63 driver will not update its values more frequently than every
second; reading them more often will do no harm, but will return 'old'
values.
The lm63 driver will not update its values more frequently than configured with
the update_interval sysfs attribute; reading them more often will do no harm,
but will return 'old' values. Values in the automatic fan control lookup table
(attributes pwm1_auto_*) have their own independent lifetime of 5 seconds.
The LM64 is effectively an LM63 with GPIO lines. The driver does not
support these GPIO lines at present.
The LM96163 is an enhanced version of LM63 with improved temperature accuracy
and better PWM resolution. For LM96163, the external temperature sensor type is
configurable as CPU embedded diode(1) or 3904 transistor(2).

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