Kernel/linux-stable
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2025-01-09 14:43:16 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'osd-devel' into nfs-for-next

Browse Source
This commit is contained in:
Trond Myklebust 2011-11-02 23:56:40 -04:00
commit 31cbecb4ab
7798 changed files with 500875 additions and 331564 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/ABI/removed/o2cb
View File

@ -1,6 +1,6 @@
What: /sys/o2cb symlink
Date: May 2011
KernelVersion: 2.6.40
KernelVersion: 3.0
Contact: ocfs2-devel@oss.oracle.com
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
removed when new versions of ocfs2-tools which know to look

2
Documentation/ABI/removed/raw1394
View File

@ -5,7 +5,7 @@ Description:
/dev/raw1394 was a character device file that allowed low-level
access to FireWire buses. Its major drawbacks were its inability
to implement sensible device security policies, and its low level
of abstraction that required userspace clients do duplicate much
of abstraction that required userspace clients to duplicate much
of the kernel's ieee1394 core functionality.
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
firewire-core.

19
Documentation/ABI/testing/debugfs-ideapad Normal file
View File

@ -0,0 +1,19 @@
What: /sys/kernel/debug/ideapad/cfg
Date: Sep 2011
KernelVersion: 3.2
Contact: Ike Panhc <ike.pan@canonical.com>
Description:
cfg shows the return value of _CFG method in VPC2004 device. It tells machine
capability and what graphic component within the machine.
What: /sys/kernel/debug/ideapad/status
Date: Sep 2011
KernelVersion: 3.2
Contact: Ike Panhc <ike.pan@canonical.com>
Description:
status shows infos we can read and tells its meaning and value.

23
Documentation/ABI/testing/evm Normal file
View File

@ -0,0 +1,23 @@
What: security/evm
Date: March 2011
Contact: Mimi Zohar <zohar@us.ibm.com>
Description:
EVM protects a file's security extended attributes(xattrs)
against integrity attacks. The initial method maintains an
HMAC-sha1 value across the extended attributes, storing the
value as the extended attribute 'security.evm'.
EVM depends on the Kernel Key Retention System to provide it
with a trusted/encrypted key for the HMAC-sha1 operation.
The key is loaded onto the root's keyring using keyctl. Until
EVM receives notification that the key has been successfully
loaded onto the keyring (echo 1 > <securityfs>/evm), EVM
can not create or validate the 'security.evm' xattr, but
returns INTEGRITY_UNKNOWN. Loading the key and signaling EVM
should be done as early as possible. Normally this is done
in the initramfs, which has already been measured as part
of the trusted boot. For more information on creating and
loading existing trusted/encrypted keys, refer to:
Documentation/keys-trusted-encrypted.txt. (A sample dracut
patch, which loads the trusted/encrypted key and enables
EVM, is available from http://linux-ima.sourceforge.net/#EVM.)

13
Documentation/ABI/testing/sysfs-block
View File

@ -206,3 +206,16 @@ Description:
when a discarded area is read the discard_zeroes_data
parameter will be set to one. Otherwise it will be 0 and
the result of reading a discarded area is undefined.
What: /sys/block/<disk>/alias
Date: Aug 2011
Contact: Nao Nishijima <nao.nishijima.xt@hitachi.com>
Description:
A raw device name of a disk does not always point a same disk
each boot-up time. Therefore, users have to use persistent
device names, which udev creates when the kernel finds a disk,
instead of raw device name. However, kernel doesn't show those
persistent names on its messages (e.g. dmesg).
This file can store an alias of the disk and it would be
appeared in kernel messages if it is set. A disk can have an
alias which length is up to 255bytes. Users can use alphabets,
numbers, "-" and "_" in alias name. This file is writeonce.

8
Documentation/ABI/testing/sysfs-bus-bcma
View File

@ -1,6 +1,6 @@
What: /sys/bus/bcma/devices/.../manuf
Date: May 2011
KernelVersion: 2.6.40
KernelVersion: 3.0
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
Each BCMA core has it's manufacturer id. See
@ -8,7 +8,7 @@ Description:
What: /sys/bus/bcma/devices/.../id
Date: May 2011
KernelVersion: 2.6.40
KernelVersion: 3.0
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
There are a few types of BCMA cores, they can be identified by
@ -16,7 +16,7 @@ Description:
What: /sys/bus/bcma/devices/.../rev
Date: May 2011
KernelVersion: 2.6.40
KernelVersion: 3.0
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
BCMA cores of the same type can still slightly differ depending
@ -24,7 +24,7 @@ Description:
What: /sys/bus/bcma/devices/.../class
Date: May 2011
KernelVersion: 2.6.40
KernelVersion: 3.0
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
Each BCMA core is identified by few fields, including class it

46
Documentation/ABI/testing/sysfs-bus-pci-drivers-ehci_hcd Normal file
View File

@ -0,0 +1,46 @@
What: /sys/bus/pci/drivers/ehci_hcd/.../companion
/sys/bus/usb/devices/usbN/../companion
Date: January 2007
KernelVersion: 2.6.21
Contact: Alan Stern <stern@rowland.harvard.edu>
Description:
PCI-based EHCI USB controllers (i.e., high-speed USB-2.0
controllers) are often implemented along with a set of
"companion" full/low-speed USB-1.1 controllers. When a
high-speed device is plugged in, the connection is routed
to the EHCI controller; when a full- or low-speed device
is plugged in, the connection is routed to the companion
controller.
Sometimes you want to force a high-speed device to connect
at full speed, which can be accomplished by forcing the
connection to be routed to the companion controller.
That's what this file does. Writing a port number to the
file causes connections on that port to be routed to the
companion controller, and writing the negative of a port
number returns the port to normal operation.
For example: To force the high-speed device attached to
port 4 on bus 2 to run at full speed:
echo 4 >/sys/bus/usb/devices/usb2/../companion
To return the port to high-speed operation:
echo -4 >/sys/bus/usb/devices/usb2/../companion
Reading the file gives the list of ports currently forced
to the companion controller.
Note: Some EHCI controllers do not have companions; they
may contain an internal "transaction translator" or they
may be attached directly to a "rate-matching hub". This
mechanism will not work with such controllers. Also, it
cannot be used to force a port on a high-speed hub to
connect at full speed.
Note: When this file was first added, it appeared in a
different sysfs directory. The location given above is
correct for 2.6.35 (and probably several earlier kernel
versions as well).

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

@ -142,3 +142,18 @@ Description:
such devices.
Users:
usb_modeswitch
What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
Date: September 2011
Contact: Andiry Xu <andiry.xu@amd.com>
Description:
If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
is plugged in to a xHCI host which support link PM, it will
perform a LPM test; if the test is passed and host supports
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
be enabled for the device and the USB device directory will
contain a file named power/usb2_hardware_lpm. The file holds
a string value (enable or disable) indicating whether or not
USB2 hardware LPM is enabled for the device. Developer can
write y/Y/1 or n/N/0 to the file to enable/disable the
feature.

16
Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870
View File

@ -4,8 +4,8 @@ What: /sys/class/backlight/<backlight>/l2_bright_max
What: /sys/class/backlight/<backlight>/l3_office_max
What: /sys/class/backlight/<backlight>/l4_indoor_max
What: /sys/class/backlight/<backlight>/l5_dark_max
Date: Mai 2011
KernelVersion: 2.6.40
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the maximum brightness for <ambient light zone>
@ -18,8 +18,8 @@ What: /sys/class/backlight/<backlight>/l2_bright_dim
What: /sys/class/backlight/<backlight>/l3_office_dim
What: /sys/class/backlight/<backlight>/l4_indoor_dim
What: /sys/class/backlight/<backlight>/l5_dark_dim
Date: Mai 2011
KernelVersion: 2.6.40
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the dim brightness for <ambient light zone>
@ -29,8 +29,8 @@ Description:
this <ambient light zone>.
What: /sys/class/backlight/<backlight>/ambient_light_level
Date: Mai 2011
KernelVersion: 2.6.40
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Get conversion value of the light sensor.
@ -39,8 +39,8 @@ Description:
8000 (max ambient brightness)
What: /sys/class/backlight/<backlight>/ambient_light_zone
Date: Mai 2011
KernelVersion: 2.6.40
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Get/Set current ambient light zone. Reading returns

52
Documentation/ABI/testing/sysfs-class-devfreq Normal file
View File

@ -0,0 +1,52 @@
What: /sys/class/devfreq/.../
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
Provide a place in sysfs for the devfreq objects.
This allows accessing various devfreq specific variables.
The name of devfreq object denoted as ... is same as the
name of device using devfreq.
What: /sys/class/devfreq/.../governor
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../governor shows the name of the
governor used by the corresponding devfreq object.
What: /sys/class/devfreq/.../cur_freq
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../cur_freq shows the current
frequency of the corresponding devfreq object.
What: /sys/class/devfreq/.../central_polling
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../central_polling shows whether
the devfreq ojbect is using devfreq-provided central
polling mechanism or not.
What: /sys/class/devfreq/.../polling_interval
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../polling_interval shows and sets
the requested polling interval of the corresponding devfreq
object. The values are represented in ms. If the value is
less than 1 jiffy, it is considered to be 0, which means
no polling. This value is meaningless if the governor is
not polling; thus. If the governor is not using
devfreq-provided central polling
(/sys/class/devfreq/.../central_polling is 0), this value
may be useless.
What: /sys/class/devfreq/.../userspace/set_freq
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../userspace/set_freq shows and
sets the requested frequency for the devfreq object if
userspace governor is in effect.

8
Documentation/ABI/testing/sysfs-class-net-mesh
View File

@ -22,6 +22,14 @@ Description:
mesh will be fragmented or silently discarded if the
packet size exceeds the outgoing interface MTU.
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <ordex@autistici.org>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
silently dropped.
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>

7
Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff Normal file
View File

@ -0,0 +1,7 @@
What: /sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
Date: July 2011
KernelVersion: 3.2
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.

72
Documentation/ABI/testing/sysfs-driver-wacom Normal file
View File

@ -0,0 +1,72 @@
What: /sys/class/hidraw/hidraw*/device/speed
Date: April 2010
Kernel Version: 2.6.35
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/speed file controls
reporting speed of Wacom bluetooth tablet. Reading from
this file returns 1 if tablet reports in high speed mode
or 0 otherwise. Writing to this file one of these values
switches reporting speed.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
Date: August 2011
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.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the status LED luminance (1..127)
when the stylus does not touch the tablet surface, and no
button is pressed on the stylus. This luminance level is
normally lower than the level when a button is pressed.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the status LED luminance (1..127)
when the stylus touches the tablet surface, or any button is
pressed on the stylus.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
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.
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.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the overall luminance level (0..15)
of all eight button OLED displays.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
When writing a 1024 byte raw image in Wacom Intuos 4
interleaving format to the file, the image shows up on Button N
of the device. The image is a 64x32 pixel 4-bit gray image. The
1024 byte binary is split up into 16x 64 byte chunks. Each 64
byte chunk encodes the image data for two consecutive lines on
the display. The low nibble of each byte contains the first
line, and the high nibble contains the second line.

15
Documentation/ABI/testing/sysfs-platform-ideapad-laptop
View File

@ -5,19 +5,4 @@ Contact: "Ike Panhc <ike.pan@canonical.com>"
Description:
Control the power of camera module. 1 means on, 0 means off.
What: /sys/devices/platform/ideapad/cfg
Date: Jun 2011
KernelVersion: 3.1
Contact: "Ike Panhc <ike.pan@canonical.com>"
Description:
Ideapad capability bits.
Bit 8-10: 1 - Intel graphic only
2 - ATI graphic only
3 - Nvidia graphic only
4 - Intel and ATI graphic
5 - Intel and Nvidia graphic
Bit 16: Bluetooth exist (1 for exist)
Bit 17: 3G exist (1 for exist)
Bit 18: Wifi exist (1 for exist)
Bit 19: Camera exist (1 for exist)

10
Documentation/ABI/testing/sysfs-wacom
View File

@ -1,10 +0,0 @@
What: /sys/class/hidraw/hidraw*/device/speed
Date: April 2010
Kernel Version: 2.6.35
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/speed file controls
reporting speed of wacom bluetooth tablet. Reading from
this file returns 1 if tablet reports in high speed mode
or 0 otherwise. Writing to this file one of these values
switches reporting speed.

11
Documentation/DocBook/80211.tmpl
View File

@ -433,8 +433,18 @@
Insert notes about VLAN interfaces with hw crypto here or
in the hw crypto chapter.
</para>
<section id="ps-client">
<title>support for powersaving clients</title>
!Pinclude/net/mac80211.h AP support for powersaving clients
</section>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
!Finclude/net/mac80211.h ieee80211_sta_eosp_irqsafe
!Finclude/net/mac80211.h ieee80211_frame_release_type
!Finclude/net/mac80211.h ieee80211_sta_ps_transition
!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni
!Finclude/net/mac80211.h ieee80211_sta_set_buffered
!Finclude/net/mac80211.h ieee80211_sta_block_awake
</chapter>
<chapter id="multi-iface">
@ -460,7 +470,6 @@
!Finclude/net/mac80211.h sta_notify_cmd
!Finclude/net/mac80211.h ieee80211_find_sta
!Finclude/net/mac80211.h ieee80211_find_sta_by_ifaddr
!Finclude/net/mac80211.h ieee80211_sta_block_awake
</chapter>
<chapter id="hardware-scan-offload">

24
Documentation/DocBook/media/dvb/dvbproperty.xml
View File

@ -352,6 +352,7 @@ typedef enum fe_delivery_system {
SYS_CMMB,
SYS_DAB,
SYS_DVBT2,
SYS_TURBO,
} fe_delivery_system_t;
</programlisting>
</section>
@ -809,6 +810,8 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
</itemizedlist>
<para>Future implementations might add those two missing parameters:</para>
<itemizedlist mark='opencircle'>
@ -818,25 +821,18 @@ typedef enum fe_hierarchy {
</section>
<section id="dvbs2-params">
<title>DVB-S2 delivery system</title>
<para>The following parameters are valid for DVB-S2:</para>
<para>In addition to all parameters valid for DVB-S, DVB-S2 supports the following parameters:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-DELIVERY-SYSTEM"><constant>DTV_DELIVERY_SYSTEM</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-PILOT"><constant>DTV_PILOT</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
</itemizedlist>
<para>Future implementations might add those two missing parameters:</para>
</section>
<section id="turbo-params">
<title>Turbo code delivery system</title>
<para>In addition to all parameters valid for DVB-S, turbo code supports the following parameters:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
<listitem><para><link linkend="DTV-DISEQC-SLAVE-REPLY"><constant>DTV_DISEQC_SLAVE_REPLY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
</itemizedlist>
</section>
<section id="isdbs-params">

2
Documentation/DocBook/media/dvb/intro.xml
View File

@ -205,7 +205,7 @@ a partial path like:</para>
additional include file <emphasis
role="tt">linux/dvb/version.h</emphasis> exists, which defines the
constant <emphasis role="tt">DVB_API_VERSION</emphasis>. This document
describes <emphasis role="tt">DVB_API_VERSION&#x00A0;3</emphasis>.
describes <emphasis role="tt">DVB_API_VERSION 5.4</emphasis>.
</para>
</section>

8
Documentation/DocBook/media/v4l/compat.xml
View File

@ -2370,6 +2370,14 @@ that used it. It was originally scheduled for removal in 2.6.35.
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.2</title>
<orderedlist>
<listitem>
<para>V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls to userspace.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

2
Documentation/DocBook/media/v4l/dev-subdev.xml
View File

@ -266,7 +266,7 @@
<para>When satisfied with the try results, applications can set the active
formats by setting the <structfield>which</structfield> argument to
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. Active formats are changed
<constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. Active formats are changed
exactly as try formats by drivers. To avoid modifying the hardware state
during format negotiation, applications should negotiate try formats first
and then modify the active settings using the try formats returned during

9
Documentation/DocBook/media/v4l/v4l2.xml
View File

@ -127,6 +127,13 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.2</revnumber>
<date>2011-08-26</date>
<authorinitials>hv</authorinitials>
<revremark>Added V4L2_CTRL_FLAG_VOLATILE.</revremark>
</revision>
<revision>
<revnumber>3.1</revnumber>
<date>2011-06-27</date>
@ -410,7 +417,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.1</subtitle>
<subtitle>Revision 3.2</subtitle>
<chapter id="common">
&sub-common;

129
Documentation/DocBook/media/v4l/vidioc-dqevent.xml
View File

@ -86,6 +86,12 @@
<entry>Event data for event V4L2_EVENT_CTRL.
</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-event-frame-sync;</entry>
<entry><structfield>frame</structfield></entry>
<entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
</row>
<row>
<entry></entry>
<entry>__u8</entry>
@ -135,6 +141,129 @@
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-event-vsync">
<title>struct <structname>v4l2_event_vsync</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u8</entry>
<entry><structfield>field</structfield></entry>
<entry>The upcoming field. See &v4l2-field;.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-event-ctrl">
<title>struct <structname>v4l2_event_ctrl</structname></title>
<tgroup cols="4">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>changes</structfield></entry>
<entry></entry>
<entry>A bitmask that tells what has changed. See <xref linkend="changes-flags" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry></entry>
<entry>The type of the control. See &v4l2-ctrl-type;.</entry>
</row>
<row>
<entry>union (anonymous)</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry>__s32</entry>
<entry><structfield>value</structfield></entry>
<entry>The 32-bit value of the control for 32-bit control types.
This is 0 for string controls since the value of a string
cannot be passed using &VIDIOC-DQEVENT;.</entry>
</row>
<row>
<entry></entry>
<entry>__s64</entry>
<entry><structfield>value64</structfield></entry>
<entry>The 64-bit value of the control for 64-bit control types.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry>The control flags. See <xref linkend="control-flags" />.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>minimum</structfield></entry>
<entry></entry>
<entry>The minimum value of the control. See &v4l2-queryctrl;.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>maximum</structfield></entry>
<entry></entry>
<entry>The maximum value of the control. See &v4l2-queryctrl;.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>step</structfield></entry>
<entry></entry>
<entry>The step value of the control. See &v4l2-queryctrl;.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>default_value</structfield></entry>
<entry></entry>
<entry>The default value value of the control. See &v4l2-queryctrl;.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-event-frame-sync">
<title>struct <structname>v4l2_event_frame_sync</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>frame_sequence</structfield></entry>
<entry>
The sequence number of the frame being received.
</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="changes-flags">
<title>Changes</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_VALUE</constant></entry>
<entry>0x0001</entry>
<entry>This control event was triggered because the value of the control
changed. Special case: if a button control is pressed, then this
event is sent as well, even though there is not explicit value
associated with a button control.</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_FLAGS</constant></entry>
<entry>0x0002</entry>
<entry>This control event was triggered because the control flags
changed.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;

9
Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
View File

@ -406,6 +406,15 @@ flag is typically present for relative controls or action controls where
writing a value will cause the device to carry out a given action
(&eg; motor control) but no meaningful value can be returned.</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_FLAG_VOLATILE</constant></entry>
<entry>0x0080</entry>
<entry>This control is volatile, which means that the value of the control
changes continuously. A typical example would be the current gain value if the device
is in auto-gain mode. In such a case the hardware calculates the gain value based on
the lighting conditions which can change over time. Note that setting a new value for
a volatile control will have no effect. The new value will just be ignored.</entry>
</row>
</tbody>
</tgroup>
</table>

123
Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
View File

@ -138,6 +138,22 @@
field of the oldest event.</para>
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
<entry>4</entry>
<entry>
<para>Triggered immediately when the reception of a
frame has begun. This event has a
&v4l2-event-frame-sync; associated with it.</para>
<para>If the hardware needs to be stopped in the case of a
buffer underrun it might not be able to generate this event.
In such cases the <structfield>frame_sequence</structfield>
field in &v4l2-event-frame-sync; will not be incremented. This
causes two consecutive frame sequence numbers to have n times
frame interval in between them.</para>
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
<entry>0x08000000</entry>
@ -183,113 +199,6 @@
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-event-vsync">
<title>struct <structname>v4l2_event_vsync</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u8</entry>
<entry><structfield>field</structfield></entry>
<entry>The upcoming field. See &v4l2-field;.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-event-ctrl">
<title>struct <structname>v4l2_event_ctrl</structname></title>
<tgroup cols="4">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>changes</structfield></entry>
<entry></entry>
<entry>A bitmask that tells what has changed. See <xref linkend="changes-flags" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry></entry>
<entry>The type of the control. See &v4l2-ctrl-type;.</entry>
</row>
<row>
<entry>union (anonymous)</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry>__s32</entry>
<entry><structfield>value</structfield></entry>
<entry>The 32-bit value of the control for 32-bit control types.
This is 0 for string controls since the value of a string
cannot be passed using &VIDIOC-DQEVENT;.</entry>
</row>
<row>
<entry></entry>
<entry>__s64</entry>
<entry><structfield>value64</structfield></entry>
<entry>The 64-bit value of the control for 64-bit control types.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry>The control flags. See <xref linkend="control-flags" />.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>minimum</structfield></entry>
<entry></entry>
<entry>The minimum value of the control. See &v4l2-queryctrl;.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>maximum</structfield></entry>
<entry></entry>
<entry>The maximum value of the control. See &v4l2-queryctrl;.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>step</structfield></entry>
<entry></entry>
<entry>The step value of the control. See &v4l2-queryctrl;.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>default_value</structfield></entry>
<entry></entry>
<entry>The default value value of the control. See &v4l2-queryctrl;.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="changes-flags">
<title>Changes</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_VALUE</constant></entry>
<entry>0x0001</entry>
<entry>This control event was triggered because the value of the control
changed. Special case: if a button control is pressed, then this
event is sent as well, even though there is not explicit value
associated with a button control.</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_FLAGS</constant></entry>
<entry>0x0002</entry>
<entry>This control event was triggered because the control flags
changed.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;

2
Documentation/DocBook/uio-howto.tmpl
View File

@ -529,7 +529,7 @@ memory (e.g. allocated with <function>kmalloc()</function>). There's also
</para></listitem>
<listitem><para>
<varname>unsigned long addr</varname>: Required if the mapping is used.
<varname>phys_addr_t addr</varname>: Required if the mapping is used.
Fill in the address of your memory block. This address is the one that
appears in sysfs.
</para></listitem>

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

@ -4288,7 +4288,7 @@ struct _snd_pcm_runtime {
<![CDATA[
struct snd_rawmidi *rmidi;
snd_mpu401_uart_new(card, 0, MPU401_HW_MPU401, port, info_flags,
irq, irq_flags, &rmidi);
irq, &rmidi);
]]>
</programlisting>
</informalexample>
@ -4343,6 +4343,13 @@ struct _snd_pcm_runtime {
by itself to start processing the output stream in the irq handler.
</para>
<para>
If the MPU-401 interface shares its interrupt with the other logical
devices on the card, set <constant>MPU401_INFO_IRQ_HOOK</constant>
(see <link linkend="midi-interface-interrupt-handler"><citetitle>
below</citetitle></link>).
</para>
<para>
Usually, the port address corresponds to the command port and
port + 1 corresponds to the data port. If not, you may change
@ -4375,14 +4382,12 @@ struct _snd_pcm_runtime {
</para>
<para>
The 6th argument specifies the irq number for UART. If the irq
is already allocated, pass 0 to the 7th argument
(<parameter>irq_flags</parameter>). Otherwise, pass the flags
for irq allocation
(<constant>SA_XXX</constant> bits) to it, and the irq will be
reserved by the mpu401-uart layer. If the card doesn't generate
UART interrupts, pass -1 as the irq number. Then a timer
interrupt will be invoked for polling.
The 6th argument specifies the ISA irq number that will be
allocated. If no interrupt is to be allocated (because your
code is already allocating a shared interrupt, or because the
device does not use interrupts), pass -1 instead.
For a MPU-401 device without an interrupt, a polling timer
will be used instead.
</para>
</section>
@ -4390,12 +4395,13 @@ struct _snd_pcm_runtime {
<title>Interrupt Handler</title>
<para>
When the interrupt is allocated in
<function>snd_mpu401_uart_new()</function>, the private
interrupt handler is used, hence you don't have anything else to do
than creating the mpu401 stuff. Otherwise, you have to call
<function>snd_mpu401_uart_interrupt()</function> explicitly when
a UART interrupt is invoked and checked in your own interrupt
handler.
<function>snd_mpu401_uart_new()</function>, an exclusive ISA
interrupt handler is automatically used, hence you don't have
anything else to do than creating the mpu401 stuff. Otherwise, you
have to set <constant>MPU401_INFO_IRQ_HOOK</constant>, and call
<function>snd_mpu401_uart_interrupt()</function> explicitly from your
own interrupt handler when it has determined that a UART interrupt
has occurred.
</para>
<para>

2
Documentation/PCI/pci.txt
View File

@ -314,7 +314,7 @@ from the PCI device config space. Use the values in the pci_dev structure
as the PCI "bus address" might have been remapped to a "host physical"
address by the arch/chip-set specific kernel support.
See Documentation/IO-mapping.txt for how to access device registers
See Documentation/io-mapping.txt for how to access device registers
or device memory.
The device driver needs to call pci_request_region() to verify

2
Documentation/RCU/NMI-RCU.txt
View File

@ -95,7 +95,7 @@ not to return until all ongoing NMI handlers exit. It is therefore safe
to free up the handler's data as soon as synchronize_sched() returns.
Important note: for this to work, the architecture in question must
invoke irq_enter() and irq_exit() on NMI entry and exit, respectively.
invoke nmi_enter() and nmi_exit() on NMI entry and exit, respectively.
Answer to Quick Quiz

110
Documentation/RCU/lockdep-splat.txt Normal file
View File

@ -0,0 +1,110 @@
Lockdep-RCU was added to the Linux kernel in early 2010
(http://lwn.net/Articles/371986/). This facility checks for some common
misuses of the RCU API, most notably using one of the rcu_dereference()
family to access an RCU-protected pointer without the proper protection.
When such misuse is detected, an lockdep-RCU splat is emitted.
The usual cause of a lockdep-RCU slat is someone accessing an
RCU-protected data structure without either (1) being in the right kind of
RCU read-side critical section or (2) holding the right update-side lock.
This problem can therefore be serious: it might result in random memory
overwriting or worse. There can of course be false positives, this
being the real world and all that.
So let's look at an example RCU lockdep splat from 3.0-rc5, one that
has long since been fixed:
===============================
[ INFO: suspicious RCU usage. ]
-------------------------------
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
3 locks held by scsi_scan_6/1552:
#0: (&shost->scan_mutex){+.+.+.}, at: [<ffffffff8145efca>]
scsi_scan_host_selected+0x5a/0x150
#1: (&eq->sysfs_lock){+.+...}, at: [<ffffffff812a5032>]
elevator_exit+0x22/0x60
#2: (&(&q->__queue_lock)->rlock){-.-...}, at: [<ffffffff812b6233>]
cfq_exit_queue+0x43/0x190
stack backtrace:
Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
Call Trace:
[<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
[<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
[<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
[<ffffffff812a5046>] elevator_exit+0x36/0x60
[<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
[<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
[<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
[<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
[<ffffffff817da069>] ? error_exit+0x29/0xb0
[<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
[<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
[<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[<ffffffff817da069>] ? error_exit+0x29/0xb0
[<ffffffff812bcc60>] ? kobject_del+0x40/0x40
[<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
[<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
[<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
[<ffffffff8145f170>] do_scan_async+0x20/0x160
[<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
[<ffffffff810975b6>] kthread+0xa6/0xb0
[<ffffffff817db154>] kernel_thread_helper+0x4/0x10
[<ffffffff81066430>] ? finish_task_switch+0x80/0x110
[<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
[<ffffffff81097510>] ? __init_kthread_worker+0x70/0x70
[<ffffffff817db150>] ? gs_change+0xb/0xb
Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:
if (rcu_dereference(ioc->ioc_data) == cic) {
This form says that it must be in a plain vanilla RCU read-side critical
section, but the "other info" list above shows that this is not the
case. Instead, we hold three locks, one of which might be RCU related.
And maybe that lock really does protect this reference. If so, the fix
is to inform RCU, perhaps by changing __cfq_exit_single_io_context() to
take the struct request_queue "q" from cfq_exit_queue() as an argument,
which would permit us to invoke rcu_dereference_protected as follows:
if (rcu_dereference_protected(ioc->ioc_data,
lockdep_is_held(&q->queue_lock)) == cic) {
With this change, there would be no lockdep-RCU splat emitted if this
code was invoked either from within an RCU read-side critical section
or with the ->queue_lock held. In particular, this would have suppressed
the above lockdep-RCU splat because ->queue_lock is held (see #2 in the
list above).
On the other hand, perhaps we really do need an RCU read-side critical
section. In this case, the critical section must span the use of the
return value from rcu_dereference(), or at least until there is some
reference count incremented or some such. One way to handle this is to
add rcu_read_lock() and rcu_read_unlock() as follows:
rcu_read_lock();
if (rcu_dereference(ioc->ioc_data) == cic) {
spin_lock(&ioc->lock);
rcu_assign_pointer(ioc->ioc_data, NULL);
spin_unlock(&ioc->lock);
}
rcu_read_unlock();
With this change, the rcu_dereference() is always within an RCU
read-side critical section, which again would have suppressed the
above lockdep-RCU splat.
But in this particular case, we don't actually deference the pointer
returned from rcu_dereference(). Instead, that pointer is just compared
to the cic pointer, which means that the rcu_dereference() can be replaced
by rcu_access_pointer() as follows:
if (rcu_access_pointer(ioc->ioc_data) == cic) {
Because it is legal to invoke rcu_access_pointer() without protection,
this change would also suppress the above lockdep-RCU splat.

34
Documentation/RCU/lockdep.txt
View File

@ -32,9 +32,27 @@ checking of rcu_dereference() primitives:
srcu_dereference(p, sp):
Check for SRCU read-side critical section.
rcu_dereference_check(p, c):
Use explicit check expression "c". This is useful in
code that is invoked by both readers and updaters.
rcu_dereference_raw(p)
Use explicit check expression "c" along with
rcu_read_lock_held(). This is useful in code that is
invoked by both RCU readers and updaters.
rcu_dereference_bh_check(p, c):
Use explicit check expression "c" along with
rcu_read_lock_bh_held(). This is useful in code that
is invoked by both RCU-bh readers and updaters.
rcu_dereference_sched_check(p, c):
Use explicit check expression "c" along with
rcu_read_lock_sched_held(). This is useful in code that
is invoked by both RCU-sched readers and updaters.
srcu_dereference_check(p, c):
Use explicit check expression "c" along with
srcu_read_lock_held()(). This is useful in code that
is invoked by both SRCU readers and updaters.
rcu_dereference_index_check(p, c):
Use explicit check expression "c", but the caller
must supply one of the rcu_read_lock_held() functions.
This is useful in code that uses RCU-protected arrays
that is invoked by both RCU readers and updaters.
rcu_dereference_raw(p):
Don't check. (Use sparingly, if at all.)
rcu_dereference_protected(p, c):
Use explicit check expression "c", and omit all barriers
@ -48,13 +66,11 @@ checking of rcu_dereference() primitives:
value of the pointer itself, for example, against NULL.
The rcu_dereference_check() check expression can be any boolean
expression, but would normally include one of the rcu_read_lock_held()
family of functions and a lockdep expression. However, any boolean
expression can be used. For a moderately ornate example, consider
the following:
expression, but would normally include a lockdep expression. However,
any boolean expression can be used. For a moderately ornate example,
consider the following:
file = rcu_dereference_check(fdt->fd[fd],
rcu_read_lock_held() ||
lockdep_is_held(&files->file_lock) ||
atomic_read(&files->count) == 1);
@ -62,7 +78,7 @@ This expression picks up the pointer "fdt->fd[fd]" in an RCU-safe manner,
and, if CONFIG_PROVE_RCU is configured, verifies that this expression
is used in:
1. An RCU read-side critical section, or
1. An RCU read-side critical section (implicit), or
2. with files->file_lock held, or
3. on an unshared files_struct.

137
Documentation/RCU/torture.txt
View File

@ -42,7 +42,7 @@ fqs_holdoff Holdoff time (in microseconds) between consecutive calls
fqs_stutter Wait time (in seconds) between consecutive bursts
of calls to force_quiescent_state().
irqreaders Says to invoke RCU readers from irq level. This is currently
irqreader Says to invoke RCU readers from irq level. This is currently
done via timers. Defaults to "1" for variants of RCU that
permit this. (Or, more accurately, variants of RCU that do
-not- permit this know to ignore this variable.)
@ -79,19 +79,68 @@ stutter The length of time to run the test before pausing for this
Specifying "stutter=0" causes the test to run continuously
without pausing, which is the old default behavior.
test_boost Whether or not to test the ability of RCU to do priority
boosting. Defaults to "test_boost=1", which performs
RCU priority-inversion testing only if the selected
RCU implementation supports priority boosting. Specifying
"test_boost=0" never performs RCU priority-inversion
testing. Specifying "test_boost=2" performs RCU
priority-inversion testing even if the selected RCU
implementation does not support RCU priority boosting,
which can be used to test rcutorture's ability to
carry out RCU priority-inversion testing.
test_boost_interval
The number of seconds in an RCU priority-inversion test
cycle. Defaults to "test_boost_interval=7". It is
usually wise for this value to be relatively prime to
the value selected for "stutter".
test_boost_duration
The number of seconds to do RCU priority-inversion testing
within any given "test_boost_interval". Defaults to
"test_boost_duration=4".
test_no_idle_hz Whether or not to test the ability of RCU to operate in
a kernel that disables the scheduling-clock interrupt to
idle CPUs. Boolean parameter, "1" to test, "0" otherwise.
Defaults to omitting this test.
torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API,
"rcu_sync" for rcu_read_lock() with synchronous reclamation,
"rcu_bh" for the rcu_read_lock_bh() API, "rcu_bh_sync" for
rcu_read_lock_bh() with synchronous reclamation, "srcu" for
the "srcu_read_lock()" API, "sched" for the use of
preempt_disable() together with synchronize_sched(),
and "sched_expedited" for the use of preempt_disable()
with synchronize_sched_expedited().
torture_type The type of RCU to test, with string values as follows:
"rcu": rcu_read_lock(), rcu_read_unlock() and call_rcu().
"rcu_sync": rcu_read_lock(), rcu_read_unlock(), and
synchronize_rcu().
"rcu_expedited": rcu_read_lock(), rcu_read_unlock(), and
synchronize_rcu_expedited().
"rcu_bh": rcu_read_lock_bh(), rcu_read_unlock_bh(), and
call_rcu_bh().
"rcu_bh_sync": rcu_read_lock_bh(), rcu_read_unlock_bh(),
and synchronize_rcu_bh().
"rcu_bh_expedited": rcu_read_lock_bh(), rcu_read_unlock_bh(),
and synchronize_rcu_bh_expedited().
"srcu": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu().
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu_expedited().
"sched": preempt_disable(), preempt_enable(), and
call_rcu_sched().
"sched_sync": preempt_disable(), preempt_enable(), and
synchronize_sched().
"sched_expedited": preempt_disable(), preempt_enable(), and
synchronize_sched_expedited().
Defaults to "rcu".
verbose Enable debug printk()s. Default is disabled.
@ -100,12 +149,12 @@ OUTPUT
The statistics output is as follows:
rcu-torture: --- Start of test: nreaders=16 stat_interval=0 verbose=0
rcu-torture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915
rcu-torture: Reader Pipe: 1466408 9747 0 0 0 0 0 0 0 0 0
rcu-torture: Reader Batch: 1464477 11678 0 0 0 0 0 0 0 0
rcu-torture: Free-Block Circulation: 1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0
rcu-torture: --- End of test
rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767
rcu-torture: Reader Pipe: 727860534 34213 0 0 0 0 0 0 0 0 0
rcu-torture: Reader Batch: 727877838 17003 0 0 0 0 0 0 0 0 0
rcu-torture: Free-Block Circulation: 155440 155440 155440 155440 155440 155440 155440 155440 155440 155440 0
rcu-torture:--- End of test: SUCCESS: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
The command "dmesg | grep torture:" will extract this information on
most systems. On more esoteric configurations, it may be necessary to
@ -113,26 +162,55 @@ use other commands to access the output of the printk()s used by
the RCU torture test. The printk()s use KERN_ALERT, so they should
be evident. ;-)
The first and last lines show the rcutorture module parameters, and the
last line shows either "SUCCESS" or "FAILURE", based on rcutorture's
automatic determination as to whether RCU operated correctly.
The entries are as follows:
o "rtc": The hexadecimal address of the structure currently visible
to readers.
o "ver": The number of times since boot that the rcutw writer task
o "ver": The number of times since boot that the RCU writer task
has changed the structure visible to readers.
o "tfle": If non-zero, indicates that the "torture freelist"
containing structure to be placed into the "rtc" area is empty.
containing structures to be placed into the "rtc" area is empty.
This condition is important, since it can fool you into thinking
that RCU is working when it is not. :-/
o "rta": Number of structures allocated from the torture freelist.
o "rtaf": Number of allocations from the torture freelist that have
failed due to the list being empty.
failed due to the list being empty. It is not unusual for this
to be non-zero, but it is bad for it to be a large fraction of
the value indicated by "rta".
o "rtf": Number of frees into the torture freelist.
o "rtmbe": A non-zero value indicates that rcutorture believes that
rcu_assign_pointer() and rcu_dereference() are not working
correctly. This value should be zero.
o "rtbke": rcutorture was unable to create the real-time kthreads
used to force RCU priority inversion. This value should be zero.
o "rtbre": Although rcutorture successfully created the kthreads
used to force RCU priority inversion, it was unable to set them
to the real-time priority level of 1. This value should be zero.
o "rtbf": The number of times that RCU priority boosting failed
to resolve RCU priority inversion.
o "rtb": The number of times that rcutorture attempted to force
an RCU priority inversion condition. If you are testing RCU
priority boosting via the "test_boost" module parameter, this
value should be non-zero.
o "nt": The number of times rcutorture ran RCU read-side code from
within a timer handler. This value should be non-zero only
if you specified the "irqreader" module parameter.
o "Reader Pipe": Histogram of "ages" of structures seen by readers.
If any entries past the first two are non-zero, RCU is broken.
And rcutorture prints the error flag string "!!!" to make sure
@ -162,26 +240,15 @@ o "Free-Block Circulation": Shows the number of torture structures
somehow gets incremented farther than it should.
Different implementations of RCU can provide implementation-specific
additional information. For example, SRCU provides the following:
additional information. For example, SRCU provides the following
additional line:
srcu-torture: rtc: f8cf46a8 ver: 355 tfle: 0 rta: 356 rtaf: 0 rtf: 346 rtmbe: 0
srcu-torture: Reader Pipe: 559738 939 0 0 0 0 0 0 0 0 0
srcu-torture: Reader Batch: 560434 243 0 0 0 0 0 0 0 0
srcu-torture: Free-Block Circulation: 355 354 353 352 351 350 349 348 347 346 0
srcu-torture: per-CPU(idx=1): 0(0,1) 1(0,1) 2(0,0) 3(0,1)
The first four lines are similar to those for RCU. The last line shows
the per-CPU counter state. The numbers in parentheses are the values
of the "old" and "current" counters for the corresponding CPU. The
"idx" value maps the "old" and "current" values to the underlying array,
and is useful for debugging.
Similarly, sched_expedited RCU provides the following:
sched_expedited-torture: rtc: d0000000016c1880 ver: 1090796 tfle: 0 rta: 1090796 rtaf: 0 rtf: 1090787 rtmbe: 0 nt: 27713319
sched_expedited-torture: Reader Pipe: 12660320201 95875 0 0 0 0 0 0 0 0 0
sched_expedited-torture: Reader Batch: 12660424885 0 0 0 0 0 0 0 0 0 0
sched_expedited-torture: Free-Block Circulation: 1090795 1090795 1090794 1090793 1090792 1090791 1090790 1090789 1090788 1090787 0
This line shows the per-CPU counter state. The numbers in parentheses are
the values of the "old" and "current" counters for the corresponding CPU.
The "idx" value maps the "old" and "current" values to the underlying
array, and is useful for debugging.
USAGE

38
Documentation/RCU/trace.txt
View File

@ -33,23 +33,23 @@ rcu/rcuboost:
The output of "cat rcu/rcudata" looks as follows:
rcu_sched:
0 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
1 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
2 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
3 c=20942 g=20943 pq=1 pqc=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
4 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
5 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
6 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
7 c=20897 g=20897 pq=1 pqc=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
rcu_bh:
0 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
1 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
2 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
3 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
4 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
5 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
6 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
7 c=1474 g=1474 pq=1 pqc=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
The first section lists the rcu_data structures for rcu_sched, the second
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
@ -84,7 +84,7 @@ o "pq" indicates that this CPU has passed through a quiescent state
CPU has not yet reported that fact, (2) some other CPU has not
yet reported for this grace period, or (3) both.
o "pqc" indicates which grace period the last-observed quiescent
o "pgp" indicates which grace period the last-observed quiescent
state for this CPU corresponds to. This is important for handling
the race between CPU 0 reporting an extended dynticks-idle
quiescent state for CPU 1 and CPU 1 suddenly waking up and
@ -184,10 +184,14 @@ o "kt" is the per-CPU kernel-thread state. The digit preceding
The number after the final slash is the CPU that the kthread
is actually running on.
This field is displayed only for CONFIG_RCU_BOOST kernels.
o "ktl" is the low-order 16 bits (in hexadecimal) of the count of
the number of times that this CPU's per-CPU kthread has gone
through its loop servicing invoke_rcu_cpu_kthread() requests.
This field is displayed only for CONFIG_RCU_BOOST kernels.
o "b" is the batch limit for this CPU. If more than this number
of RCU callbacks is ready to invoke, then the remainder will
be deferred.

2
Documentation/blackfin/bfin-gpio-notes.txt
View File

@ -1,5 +1,5 @@
/*
* File: Documentation/blackfin/bfin-gpio-note.txt
* File: Documentation/blackfin/bfin-gpio-notes.txt
* Based on:
* Author:
*

2
Documentation/block/biodoc.txt
View File

@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
do not have a corresponding kernel virtual address space mapping) and
low-memory pages.
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
Note: Please refer to Documentation/DMA-API-HOWTO.txt for a discussion
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
for 64 bit PCI.

2
Documentation/bus-virt-phys-mapping.txt
View File

@ -1,6 +1,6 @@
[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
superseded by the functionality provided by the PCI DMA interface
(see Documentation/PCI/PCI-DMA-mapping.txt). They continue
(see Documentation/DMA-API-HOWTO.txt). They continue
to be documented below for historical purposes, but new code
must not use them. --davidm 00/12/12 ]

2
Documentation/cdrom/packet-writing.txt
View File

@ -109,7 +109,7 @@ this interface. (see http://tom.ist-im-web.de/download/pktcdvd )
For a description of the sysfs interface look into the file:
Documentation/ABI/testing/sysfs-block-pktcdvd
Documentation/ABI/testing/sysfs-class-pktcdvd
Using the pktcdvd debugfs interface

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

@ -132,7 +132,7 @@ The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or no_hz=off boot parameter is used, the
If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)

2
Documentation/development-process/4.Coding
View File

@ -278,7 +278,7 @@ enabled, a configurable percentage of memory allocations will be made to
fail; these failures can be restricted to a specific range of code.
Running with fault injection enabled allows the programmer to see how the
code responds when things go badly. See
Documentation/fault-injection/fault-injection.text for more information on
Documentation/fault-injection/fault-injection.txt for more information on
how to use this facility.
Other kinds of errors can be found with the "sparse" static analysis tool.

8
Documentation/devicetree/bindings/arm/calxeda.txt Normal file
View File

@ -0,0 +1,8 @@
Calxeda Highbank Platforms Device Tree Bindings
-----------------------------------------------
Boards with Calxeda Cortex-A9 based Highbank SOC shall have the following
properties.
Required root node properties:
- compatible = "calxeda,highbank";

26
Documentation/devicetree/bindings/arm/fsl.txt Normal file
View File

@ -0,0 +1,26 @@
Freescale i.MX Platforms Device Tree Bindings
-----------------------------------------------
i.MX51 Babbage Board
Required root node properties:
- compatible = "fsl,imx51-babbage", "fsl,imx51";
i.MX53 Automotive Reference Design Board
Required root node properties:
- compatible = "fsl,imx53-ard", "fsl,imx53";
i.MX53 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx53-evk", "fsl,imx53";
i.MX53 Quick Start Board
Required root node properties:
- compatible = "fsl,imx53-qsb", "fsl,imx53";
i.MX53 Smart Mobile Reference Design Board
Required root node properties:
- compatible = "fsl,imx53-smd", "fsl,imx53";
i.MX6 Quad SABRE Automotive Board
Required root node properties:
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";

55
Documentation/devicetree/bindings/arm/gic.txt Normal file
View File

@ -0,0 +1,55 @@
* ARM Generic Interrupt Controller
ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.
Main node required properties:
- compatible : should be one of:
"arm,cortex-a9-gic"
"arm,arm11mp-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
- reg : Specifies base physical address(s) and size of the GIC registers. The
first region is the GIC distributor register base and size. The 2nd region is
the GIC cpu interface register base and size.
Optional
- interrupts : Interrupt source of the parent interrupt controller. Only
present on secondary GICs.
Example:
intc: interrupt-controller@fff11000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
};

44
Documentation/devicetree/bindings/arm/l2cc.txt Normal file
View File

@ -0,0 +1,44 @@
* ARM L2 Cache Controller
ARM cores often have a separate level 2 cache controller. There are various
implementations of the L2 cache controller with compatible programming models.
The ARM L2 cache representation in the device tree should be done as follows:
Required properties:
- compatible : should be one of:
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped
registers.
Optional properties:
- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
read, write and setup latencies. Minimum valid values are 1. Controllers
without setup latency control should use a value of 0.
- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
read, write and setup latencies. Controllers without setup latency control
should use 0. Controllers without separate read and write Tag RAM latency
values should only use the first cell.
- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
- arm,filter-ranges : <start length> Starting address and length of window to
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
- interrupts : 1 combined interrupt.
Example:
L2: cache-controller {
compatible = "arm,pl310-cache";
reg = <0xfff12000 0x1000>;
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
arm,filter-latency = <0x80000000 0x8000000>;
cache-unified;
cache-level = <2>;
interrupts = <45>;
};

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

@ -0,0 +1,14 @@
* TI - DSP (Digital Signal Processor)
TI DSP included in OMAP SoC
Required properties:
- compatible : Should be "ti,omap3-c64" for OMAP3 & 4
- ti,hwmods: "dsp"
Examples:
dsp {
compatible = "ti,omap3-c64";
ti,hwmods = "dsp";
};

19
Documentation/devicetree/bindings/arm/omap/iva.txt Normal file
View File

@ -0,0 +1,19 @@
* TI - IVA (Imaging and Video Accelerator) subsystem
The IVA contain various audio, video or imaging HW accelerator
depending of the version.
Required properties:
- compatible : Should be:
- "ti,ivahd" for OMAP4
- "ti,iva2.2" for OMAP3
- "ti,iva2.1" for OMAP2430
- "ti,iva1" for OMAP2420
- ti,hwmods: "iva"
Examples:
iva {
compatible = "ti,ivahd", "ti,iva";
ti,hwmods = "iva";
};

19
Documentation/devicetree/bindings/arm/omap/l3-noc.txt Normal file
View File

@ -0,0 +1,19 @@
* TI - L3 Network On Chip (NoC)
This version is an implementation of the generic NoC IP
provided by Arteris.
Required properties:
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
Should be "ti,omap4-l3-noc" for OMAP4 family
- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
Examples:
ocp {
compatible = "ti,omap4-l3-noc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
};

27
Documentation/devicetree/bindings/arm/omap/mpu.txt Normal file
View File

@ -0,0 +1,27 @@
* TI - MPU (Main Processor Unit) subsystem
The MPU subsystem contain one or several ARM cores
depending of the version.
The MPU contain CPUs, GIC, L2 cache and a local PRCM.
Required properties:
- compatible : Should be "ti,omap3-mpu" for OMAP3
Should be "ti,omap4-mpu" for OMAP4
- ti,hwmods: "mpu"
Examples:
- For an OMAP4 SMP system:
mpu {
compatible = "ti,omap4-mpu";
ti,hwmods = "mpu";
};
- For an OMAP3 monocore system:
mpu {
compatible = "ti,omap3-mpu";
ti,hwmods = "mpu";
};

43
Documentation/devicetree/bindings/arm/omap/omap.txt Normal file
View File

@ -0,0 +1,43 @@
* Texas Instruments OMAP
OMAP is currently using a static file per SoC family to describe the
IPs present in the SoC.
On top of that an omap_device is created to extend the platform_device
capabilities and to allow binding with one or several hwmods.
The hwmods will contain all the information to build the device:
adresse range, irq lines, dma lines, interconnect, PRCM register,
clock domain, input clocks.
For the moment just point to the existing hwmod, the next step will be
to move data from hwmod to device-tree representation.
Required properties:
- compatible: Every devices present in OMAP SoC should be in the
form: "ti,XXX"
- ti,hwmods: list of hwmod names (ascii strings), that comes from the OMAP
HW documentation, attached to a device. Must contain at least
one hwmod.
Optional properties:
- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
Example:
spinlock@1 {
compatible = "ti,omap4-spinlock";
ti,hwmods = "spinlock";
};
Boards:
- OMAP3 BeagleBoard : Low cost community board
compatible = "ti,omap3-beagle", "ti,omap3"
- OMAP4 SDP : Software Developement Board
compatible = "ti,omap4-sdp", "ti,omap4430"
- OMAP4 PandaBoard : Low cost community board
compatible = "ti,omap4-panda", "ti,omap4430"

24
Documentation/devicetree/bindings/arm/picoxcell.txt Normal file
View File

@ -0,0 +1,24 @@
Picochip picoXcell device tree bindings.
========================================
Required root node properties:
- compatible:
- "picochip,pc7302-pc3x3" : PC7302 development board with PC3X3 device.
- "picochip,pc7302-pc3x2" : PC7302 development board with PC3X2 device.
- "picochip,pc3x3" : picoXcell PC3X3 device based board.
- "picochip,pc3x2" : picoXcell PC3X2 device based board.
Timers required properties:
- compatible = "picochip,pc3x2-timer"
- interrupts : The single IRQ line for the timer.
- clock-freq : The frequency in HZ of the timer.
- reg : The register bank for the timer.
Note: two timers are required - one for the scheduler clock and one for the
event tick/NOHZ.
VIC required properties:
- compatible = "arm,pl192-vic".
- interrupt-controller.
- reg : The register bank for the device.
- #interrupt-cells : Must be 1.

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

@ -6,7 +6,9 @@ driver matching.
Required properties:
- compatible : should be a specific value for peripheral and "arm,primecell"
- compatible : should be a specific name for the peripheral and
"arm,primecell". The specific name will match the ARM
engineering name for the logic block in the form: "arm,pl???"
Optional properties:

23
Documentation/devicetree/bindings/crypto/picochip-spacc.txt Normal file
View File

@ -0,0 +1,23 @@
Picochip picoXcell SPAcc (Security Protocol Accelerator) bindings
Picochip picoXcell devices contain crypto offload engines that may be used for
IPSEC and femtocell layer 2 ciphering.
Required properties:
- compatible : "picochip,spacc-ipsec" for the IPSEC offload engine
"picochip,spacc-l2" for the femtocell layer 2 ciphering engine.
- reg : Offset and length of the register set for this device
- interrupt-parent : The interrupt controller that controls the SPAcc
interrupt.
- interrupts : The interrupt line from the SPAcc.
- ref-clock : The input clock that drives the SPAcc.
Example SPAcc node:
spacc@10000 {
compatible = "picochip,spacc-ipsec";
reg = <0x100000 0x10000>;
interrupt-parent = <&vic0>;
interrupts = <24>;
ref-clock = <&ipsec_clk>, "ref";
};

2
Documentation/devicetree/bindings/gpio/led.txt
View File

@ -8,7 +8,7 @@ node's name represents the name of the corresponding LED.
LED sub-node properties:
- gpios : Should specify the LED's GPIO, see "Specifying GPIO information
for devices" in Documentation/powerpc/booting-without-of.txt. Active
for devices" in Documentation/devicetree/booting-without-of.txt. Active
low LEDs should be indicated using flags in the GPIO specifier.
- label : (optional) The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).

10
Documentation/devicetree/bindings/gpio/pl061-gpio.txt Normal file
View File

@ -0,0 +1,10 @@
ARM PL061 GPIO controller
Required properties:
- compatible : "arm,pl061", "arm,primecell"
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.
- interrupts : Interrupt mapping for GPIO IRQ.

25
Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt Normal file
View File

@ -0,0 +1,25 @@
* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
Required properties:
- compatible : Should be "fsl,<chip>-i2c"
- reg : Should contain I2C/HS-I2C registers location and length
- interrupts : Should contain I2C/HS-I2C interrupt
Optional properties:
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
The absence of the propoerty indicates the default frequency 100 kHz.
Examples:
i2c@83fc4000 { /* I2C2 on i.MX51 */
compatible = "fsl,imx51-i2c", "fsl,imx1-i2c";
reg = <0x83fc4000 0x4000>;
interrupts = <63>;
};
i2c@70038000 { /* HS-I2C on i.MX51 */
compatible = "fsl,imx51-i2c", "fsl,imx1-i2c";
reg = <0x70038000 0x4000>;
interrupts = <64>;
clock-frequency = <400000>;
};

39
Documentation/devicetree/bindings/i2c/samsung-i2c.txt Normal file
View File

@ -0,0 +1,39 @@
* Samsung's I2C controller
The Samsung's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: value should be either of the following.
(a) "samsung, s3c2410-i2c", for i2c compatible with s3c2410 i2c.
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
- samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges.
- gpios: The order of the gpios should be the following: <SDA, SCL>.
The gpio specifier depends on the gpio controller.
Optional properties:
- samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
specified, default value is 0.
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
specified, the default value in Hz is 100000.
Example:
i2c@13870000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x13870000 0x100>;
interrupts = <345>;
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <100000>;
gpios = <&gpd1 2 0 /* SDA */
&gpd1 3 0 /* SCL */>;
#address-cells = <1>;
#size-cells = <0>;
wm8994@1a {
compatible = "wlf,wm8994";
reg = <0x1a>;
};
};

27
Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt Normal file
View File

@ -0,0 +1,27 @@
* NVIDIA Tegra Secure Digital Host Controller
This controller on Tegra family SoCs provides an interface for MMC, SD,
and SDIO types of memory cards.
Required properties:
- compatible : Should be "nvidia,<chip>-sdhci"
- reg : Should contain SD/MMC registers location and length
- interrupts : Should contain SD/MMC interrupt
Optional properties:
- cd-gpios : Specify GPIOs for card detection
- wp-gpios : Specify GPIOs for write protection
- power-gpios : Specify GPIOs for power control
- support-8bit : Boolean, indicates if 8-bit mode should be used.
Example:
sdhci@c8000200 {
compatible = "nvidia,tegra20-sdhci";
reg = <0xc8000200 0x200>;
interrupts = <47>;
cd-gpios = <&gpio 69 0>; /* gpio PI5 */
wp-gpios = <&gpio 57 0>; /* gpio PH1 */
power-gpios = <&gpio 155 0>; /* gpio PT3 */
support-8bit;
};

63
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
View File

@ -1,61 +1,24 @@
CAN Device Tree Bindings
------------------------
2011 Freescale Semiconductor, Inc.
Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
fsl,flexcan-v1.0 nodes
-----------------------
In addition to the required compatible-, reg- and interrupt-properties, you can
also specify which clock source shall be used for the controller.
Required properties:
CPI Clock- Can Protocol Interface Clock
This CLK_SRC bit of CTRL(control register) selects the clock source to
the CAN Protocol Interface(CPI) to be either the peripheral clock
(driven by the PLL) or the crystal oscillator clock. The selected clock
is the one fed to the prescaler to generate the Serial Clock (Sclock).
The PRESDIV field of CTRL(control register) controls a prescaler that
generates the Serial Clock (Sclock), whose period defines the
time quantum used to compose the CAN waveform.
- compatible : Should be "fsl,<processor>-flexcan"
Can Engine Clock Source
There are two sources for CAN clock
- Platform Clock It represents the bus clock
- Oscillator Clock
An implementation should also claim any of the following compatibles
that it is fully backwards compatible with:
Peripheral Clock (PLL)
--------------
|
--------- -------------
| |CPI Clock | Prescaler | Sclock
| |---------------->| (1.. 256) |------------>
--------- -------------
| |
-------------- ---------------------CLK_SRC
Oscillator Clock
- fsl,p1010-flexcan
- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
the peripheral clock. PLL clock is fed to the
prescaler to generate the Serial Clock (Sclock).
Valid values are "oscillator" and "platform"
"oscillator": CAN engine clock source is oscillator clock.
"platform" The CAN engine clock source is the bus clock
(platform clock).
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
- clock-frequency : The oscillator frequency driving the flexcan device
- fsl,flexcan-clock-divider : for the reference and system clock, an additional
clock divider can be specified.
- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
Example:
Note:
- v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
- P1010 does not have oscillator as the Clock Source.So the default
Clock Source is platform clock.
Examples:
can0@1c000 {
compatible = "fsl,flexcan-v1.0";
can@1c000 {
compatible = "fsl,p1010-flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
fsl,flexcan-clock-source = "platform";
fsl,flexcan-clock-divider = <2>;
clock-frequency = <fixed by u-boot>;
clock-frequency = <200000000>; // filled in by bootloader
};

38
Documentation/devicetree/bindings/net/smsc911x.txt Normal file
View File

@ -0,0 +1,38 @@
* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
Required properties:
- compatible : Should be "smsc,lan<model>", "smsc,lan9115"
- reg : Address and length of the io space for SMSC LAN
- interrupts : Should contain SMSC LAN interrupt line
- interrupt-parent : Should be the phandle for the interrupt controller
that services interrupts for this device
- phy-mode : String, operation mode of the PHY interface.
Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
"rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
Optional properties:
- reg-shift : Specify the quantity to shift the register offsets by
- reg-io-width : Specify the size (in bytes) of the IO accesses that
should be performed on the device. Valid value for SMSC LAN is
2 or 4. If it's omitted or invalid, the size would be 2.
- smsc,irq-active-high : Indicates the IRQ polarity is active-high
- smsc,irq-push-pull : Indicates the IRQ type is push-pull
- smsc,force-internal-phy : Forces SMSC LAN controller to use
internal PHY
- smsc,force-external-phy : Forces SMSC LAN controller to use
external PHY
- smsc,save-mac-address : Indicates that mac address needs to be saved
before resetting the controller
- local-mac-address : 6 bytes, mac address
Examples:
lan9220@f4000000 {
compatible = "smsc,lan9220", "smsc,lan9115";
reg = <0xf4000000 0x2000000>;
phy-mode = "mii";
interrupt-parent = <&gpio1>;
interrupts = <31>;
reg-io-width = <4>;
smsc,irq-push-pull;
};

5
Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt Normal file
View File

@ -0,0 +1,5 @@
NVIDIA Tegra 2 pinmux controller
Required properties:
- compatible : "nvidia,tegra20-pinmux"

31
Documentation/devicetree/bindings/serial/rs485.txt Normal file
View File

@ -0,0 +1,31 @@
* RS485 serial communications
The RTS signal is capable of automatically controlling line direction for
the built-in half-duplex mode.
The properties described hereafter shall be given to a half-duplex capable
UART node.
Required properties:
- rs485-rts-delay: prop-encoded-array <a b> where:
* a is the delay beteween rts signal and beginning of data sent in milliseconds.
it corresponds to the delay before sending data.
* b is the delay between end of data sent and rts signal in milliseconds
it corresponds to the delay after sending data and actual release of the line.
Optional properties:
- linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485
feature at boot time. It can be disabled later with proper ioctl.
- rs485-rx-during-tx: empty property that enables the receiving of data even
whilst sending data.
RS485 example for Atmel USART:
usart0: serial@fff8c000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfff8c000 0x4000>;
interrupts = <7>;
atmel,use-dma-rx;
atmel,use-dma-tx;
linux,rs485-enabled-at-boot-time;
rs485-rts-delay = <0 200>; // in milliseconds
};

11
Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt Normal file
View File

@ -0,0 +1,11 @@
* Freescale SGTL5000 Stereo Codec
Required properties:
- compatible : "fsl,sgtl5000".
Example:
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
};

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

@ -0,0 +1,18 @@
WM8510 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8510"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8510@1a {
compatible = "wlf,wm8510";
reg = <0x1a>;
};

16
Documentation/devicetree/bindings/sound/wm8523.txt Normal file
View File

@ -0,0 +1,16 @@
WM8523 audio CODEC
This device supports I2C only.
Required properties:
- compatible : "wlf,wm8523"
- reg : the I2C address of the device.
Example:
codec: wm8523@1a {
compatible = "wlf,wm8523";
reg = <0x1a>;
};

16
Documentation/devicetree/bindings/sound/wm8580.txt Normal file
View File

@ -0,0 +1,16 @@
WM8580 audio CODEC
This device supports I2C only.
Required properties:
- compatible : "wlf,wm8580"
- reg : the I2C address of the device.
Example:
codec: wm8580@1a {
compatible = "wlf,wm8580";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8711 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8711"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8711@1a {
compatible = "wlf,wm8711";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8728 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8728"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8728@1a {
compatible = "wlf,wm8728";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8731 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8731"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8731@1a {
compatible = "wlf,wm8731";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8737 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8737"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8737@1a {
compatible = "wlf,wm8737";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8741 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8741"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8741@1a {
compatible = "wlf,wm8741";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8750 and WM8987 audio CODECs
These devices support both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8750" or "wlf,wm8987"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8750@1a {
compatible = "wlf,wm8750";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8753 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8753"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8737@1a {
compatible = "wlf,wm8753";
reg = <0x1a>;
};

16
Documentation/devicetree/bindings/sound/wm8770.txt Normal file
View File

@ -0,0 +1,16 @@
WM8770 audio CODEC
This device supports SPI.
Required properties:
- compatible : "wlf,wm8770"
- reg : the chip select number.
Example:
codec: wm8770@1 {
compatible = "wlf,wm8770";
reg = <1>;
};

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

@ -0,0 +1,18 @@
WM8776 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8776"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8776@1a {
compatible = "wlf,wm8776";
reg = <0x1a>;
};

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

@ -0,0 +1,18 @@
WM8804 audio CODEC
This device supports both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm8804"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8804@1a {
compatible = "wlf,wm8804";
reg = <0x1a>;
};

12
Documentation/devicetree/bindings/spi/spi_pl022.txt Normal file
View File

@ -0,0 +1,12 @@
ARM PL022 SPI controller
Required properties:
- compatible : "arm,pl022", "arm,primecell"
- reg : Offset and length of the register set for the device
- interrupts : Should contain SPI controller interrupt
Optional properties:
- cs-gpios : should specify GPIOs used for chipselects.
The gpios will be referred to as reg = <index> in the SPI child nodes.
If unspecified, a single SPI device without a chip select can be used.

27
Documentation/devicetree/bindings/tty/serial/atmel-usart.txt Normal file
View File

@ -0,0 +1,27 @@
* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
Required properties:
- compatible: Should be "atmel,<chip>-usart"
The compatible <chip> indicated will be the first SoC to support an
additional mode or an USART new feature.
- reg: Should contain registers location and length
- interrupts: Should contain interrupt
Optional properties:
- atmel,use-dma-rx: use of PDC or DMA for receiving data
- atmel,use-dma-tx: use of PDC or DMA for transmitting data
<chip> compatible description:
- at91rm9200: legacy USART support
- at91sam9260: generic USART implementation for SAM9 SoCs
Example:
usart0: serial@fff8c000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xfff8c000 0x4000>;
interrupts = <7>;
atmel,use-dma-rx;
atmel,use-dma-tx;
};

27
Documentation/devicetree/bindings/tty/serial/msm_serial.txt Normal file
View File

@ -0,0 +1,27 @@
* Qualcomm MSM UART
Required properties:
- compatible :
- "qcom,msm-uart", and one of "qcom,msm-hsuart" or
"qcom,msm-lsuart".
- reg : offset and length of the register set for the device
for the hsuart operating in compatible mode, there should be a
second pair describing the gsbi registers.
- interrupts : should contain the uart interrupt.
There are two different UART blocks used in MSM devices,
"qcom,msm-hsuart" and "qcom,msm-lsuart". The msm-serial driver is
able to handle both of these, and matches against the "qcom,msm-uart"
as the compatibility.
The registers for the "qcom,msm-hsuart" device need to specify both
register blocks, even for the common driver.
Example:
uart@19c400000 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x19c40000 0x1000>,
<0x19c00000 0x1000>;
interrupts = <195>;
};

25
Documentation/devicetree/bindings/tty/serial/snps-dw-apb-uart.txt Normal file
View File

@ -0,0 +1,25 @@
* Synopsys DesignWare ABP UART
Required properties:
- compatible : "snps,dw-apb-uart"
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
- clock-frequency : the input clock frequency for the UART.
Optional properties:
- reg-shift : quantity to shift the register offsets by. If this property is
not present then the register offsets are not shifted.
- reg-io-width : the size (in bytes) of the IO accesses that should be
performed on the device. If this property is not present then single byte
accesses are used.
Example:
uart@80230000 {
compatible = "snps,dw-apb-uart";
reg = <0x80230000 0x100>;
clock-frequency = <3686400>;
interrupts = <10>;
reg-shift = <2>;
reg-io-width = <4>;
};

40
Documentation/devicetree/bindings/vendor-prefixes.txt Normal file
View File

@ -0,0 +1,40 @@
Device tree binding vendor prefix registry. Keep list in alphabetical order.
This isn't an exhaustive list, but you should add new prefixes to it before
using them to avoid name-space collisions.
adi Analog Devices, Inc.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)
arm ARM Ltd.
atmel Atmel Corporation
chrp Common Hardware Reference Platform
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
denx Denx Software Engineering
epson Seiko Epson Corp.
est ESTeem Wireless Modems
fsl Freescale Semiconductor
GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc.
gef GE Fanuc Intelligent Platforms Embedded Systems, Inc.
hp Hewlett Packard
ibm International Business Machines (IBM)
idt Integrated Device Technologies, Inc.
intercontrol Inter Control Group
linux Linux-specific binding
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
mosaixtech Mosaix Technologies, Inc.
national National Semiconductor
nintendo Nintendo
nvidia NVIDIA
nxp NXP Semiconductors
powervr Imagination Technologies
qcom Qualcomm, Inc.
ramtron Ramtron International
samsung Samsung Semiconductor
schindler Schindler
simtek
sirf SiRF Technology, Inc.
stericsson ST-Ericsson
ti Texas Instruments
xlnx Xilinx

4
Documentation/driver-model/binding.txt
View File

@ -48,10 +48,6 @@ devclass_add_device is called to enumerate the device within the class
and actually register it with the class, which happens with the
class's register_dev callback.
NOTE: The device class structures and core routines to manipulate them
are not in the mainline kernel, so the discussion is still a bit
speculative.
Driver
~~~~~~

65
Documentation/driver-model/device.txt
View File

@ -45,33 +45,52 @@ struct device_attribute {
const char *buf, size_t count);
};
Attributes of devices can be exported via drivers using a simple
procfs-like interface.
Attributes of devices can be exported by a device driver through sysfs.
Please see Documentation/filesystems/sysfs.txt for more information
on how sysfs works.
As explained in Documentation/kobject.txt, device attributes must be be
created before the KOBJ_ADD uevent is generated. The only way to realize
that is by defining an attribute group.
Attributes are declared using a macro called DEVICE_ATTR:
#define DEVICE_ATTR(name,mode,show,store)
Example:
DEVICE_ATTR(power,0644,show_power,store_power);
static DEVICE_ATTR(type, 0444, show_type, NULL);
static DEVICE_ATTR(power, 0644, show_power, store_power);
This declares a structure of type struct device_attribute named
'dev_attr_power'. This can then be added and removed to the device's
directory using:
This declares two structures of type struct device_attribute with respective
names 'dev_attr_type' and 'dev_attr_power'. These two attributes can be
organized as follows into a group:
int device_create_file(struct device *device, struct device_attribute * entry);
void device_remove_file(struct device * dev, struct device_attribute * attr);
static struct attribute *dev_attrs[] = {
&dev_attr_type.attr,
&dev_attr_power.attr,
NULL,
};
Example:
static struct attribute_group dev_attr_group = {
.attrs = dev_attrs,
};
device_create_file(dev,&dev_attr_power);
device_remove_file(dev,&dev_attr_power);
static const struct attribute_group *dev_attr_groups[] = {
&dev_attr_group,
NULL,
};
The file name will be 'power' with a mode of 0644 (-rw-r--r--).
This array of groups can then be associated with a device by setting the
group pointer in struct device before device_register() is invoked:
dev->groups = dev_attr_groups;
device_register(dev);
The device_register() function will use the 'groups' pointer to create the
device attributes and the device_unregister() function will use this pointer
to remove the device attributes.
Word of warning: While the kernel allows device_create_file() and
device_remove_file() to be called on a device at any time, userspace has
@ -84,24 +103,4 @@ not know about the new attributes.
This is important for device driver that need to publish additional
attributes for a device at driver probe time. If the device driver simply
calls device_create_file() on the device structure passed to it, then
userspace will never be notified of the new attributes. Instead, it should
probably use class_create() and class->dev_attrs to set up a list of
desired attributes in the modules_init function, and then in the .probe()
hook, and then use device_create() to create a new device as a child
of the probed device. The new device will generate a new uevent and
properly advertise the new attributes to userspace.
For example, if a driver wanted to add the following attributes:
struct device_attribute mydriver_attribs[] = {
__ATTR(port_count, 0444, port_count_show),
__ATTR(serial_number, 0444, serial_number_show),
NULL
};
Then in the module init function is would do:
mydriver_class = class_create(THIS_MODULE, "my_attrs");
mydriver_class.dev_attr = mydriver_attribs;
And assuming 'dev' is the struct device passed into the probe hook, the driver
probe function would do something like:
device_create(&mydriver_class, dev, chrdev, &private_data, "my_name");
userspace will never be notified of the new attributes.

51
Documentation/dvb/get_dvb_firmware
View File

@ -27,7 +27,8 @@ use IO::Handle;
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
"lme2510c_s7395_old", "drxk", "drxk_terratec_h5");
"lme2510c_s7395_old", "drxk", "drxk_terratec_h5", "tda10071",
"it9135" );
# Check args
syntax() if (scalar(@ARGV) != 1);
@ -575,19 +576,10 @@ sub ngene {
}
sub az6027{
my $file = "AZ6027_Linux_Driver.tar.gz";
my $url = "http://linux.terratec.de/files/$file";
my $firmware = "dvb-usb-az6027-03.fw";
my $url = "http://linux.terratec.de/files/TERRATEC_S7/$firmware";
wgetfile($file, $url);
#untar
if( system("tar xzvf $file $firmware")){
die "failed to untar firmware";
}
if( system("rm $file")){
die ("unable to remove unnecessary files");
}
wgetfile($firmware, $url);
$firmware;
}
@ -665,6 +657,41 @@ sub drxk_terratec_h5 {
"$fwfile"
}
sub it9135 {
my $url = "http://kworld.server261.com/kworld/CD/ITE_TiVme/V1.00/";
my $zipfile = "Driver_V10.323.1.0412.100412.zip";
my $hash = "79b597dc648698ed6820845c0c9d0d37";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
my $drvfile = "Driver_V10.323.1.0412.100412/Data/x86/IT9135BDA.sys";
my $fwfile = "dvb-usb-it9137-01.fw";
checkstandard();
wgetfile($zipfile, $url . $zipfile);
verify($zipfile, $hash);
unzip($zipfile, $tmpdir);
extract("$tmpdir/$drvfile", 69632, 5731, "$fwfile");
"$fwfile"
}
sub tda10071 {
my $sourcefile = "PCTV_460e_reference.zip";
my $url = "ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%20330e%20800e/";
my $hash = "4403de903bf2593464c8d74bbc200a57";
my $fwfile = "dvb-fe-tda10071.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
checkstandard();
wgetfile($sourcefile, $url . $sourcefile);
verify($sourcefile, $hash);
unzip($sourcefile, $tmpdir);
extract("$tmpdir/PCTV\ 70e\ 80e\ 100e\ 320e\ 330e\ 800e/32\ bit/emOEM.sys", 0x67d38, 40504, $fwfile);
"$fwfile";
}
# ---------------------------------------------------------------
# Utilities

9
Documentation/dvb/it9137.txt Normal file
View File

@ -0,0 +1,9 @@
To extract firmware for Kworld UB499-2T (id 1b80:e409) you need to copy the
following file(s) to this directory.
IT9135BDA.sys Dated Mon 22 Mar 2010 02:20:08 GMT
extract using dd
dd if=IT9135BDA.sys ibs=1 skip=69632 count=5731 of=dvb-usb-it9137-01.fw
copy to default firmware location.

8
Documentation/fault-injection/fault-injection.txt
View File

@ -21,6 +21,11 @@ o fail_make_request
/sys/block/<device>/make-it-fail or
/sys/block/<device>/<partition>/make-it-fail. (generic_make_request())
o fail_mmc_request
injects MMC data errors on devices permitted by setting
debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
Configure fault-injection capabilities behavior
-----------------------------------------------
@ -115,7 +120,8 @@ use the boot option:
failslab=
fail_page_alloc=
fail_make_request=<interval>,<probability>,<space>,<times>
fail_make_request=
mmc_core.fail_request=<interval>,<probability>,<space>,<times>
How to add new fault injection capability
-----------------------------------------

37
Documentation/fb/udlfb.txt
View File

@ -87,23 +87,38 @@ Special configuration for udlfb is usually unnecessary. There are a few
options, however.
From the command line, pass options to modprobe
modprobe udlfb defio=1 console=1
modprobe udlfb fb_defio=0 console=1 shadow=1
Or for permanent option, create file like /etc/modprobe.d/options with text
options udlfb defio=1 console=1
Or modify options on the fly at /sys/module/udlfb/parameters directory via
sudo nano fb_defio
change the parameter in place, and save the file.
Accepted options:
Unplug/replug USB device to apply with new settings
Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text
options udlfb fb_defio=0 console=1 shadow=1
Accepted boolean options:
fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
module to track changed areas of the framebuffer by page faults.
Standard fbdev applications that use mmap but that do not
report damage, may be able to work with this enabled.
Disabled by default because of overhead and other issues.
Standard fbdev applications that use mmap but that do not
report damage, should be able to work with this enabled.
Disable when running with X server that supports reporting
changed regions via ioctl, as this method is simpler,
more stable, and higher performance.
default: fb_defio=1
console Allow fbcon to attach to udlfb provided framebuffers. This
is disabled by default because fbcon will aggressively consume
the first framebuffer it finds, which isn't usually what the
user wants in the case of USB displays.
console Allow fbcon to attach to udlfb provided framebuffers.
Can be disabled if fbcon and other clients
(e.g. X with --shared-vt) are in conflict.
default: console=1
shadow Allocate a 2nd framebuffer to shadow what's currently across
the USB bus in device memory. If any pixels are unchanged,
do not transmit. Spends host memory to save USB transfers.
Enabled by default. Only disable on very low memory systems.
default: shadow=1
Sysfs Attributes
================

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

@ -495,29 +495,6 @@ Who: Jean Delvare <khali@linux-fr.org>
----------------------------
What: Support for UVCIOC_CTRL_ADD in the uvcvideo driver
When: 3.2
Why: The information passed to the driver by this ioctl is now queried
dynamically from the device.
Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
----------------------------
What: Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver
When: 3.2
Why: Used only by applications compiled against older driver versions.
Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls.
Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
----------------------------
What: Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver
When: 3.2
Why: Superseded by the UVCIOC_CTRL_QUERY ioctl.
Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
----------------------------
What: Support for driver specific ioctls in the pwc driver (everything
defined in media/pwc-ioctl.h)
When: 3.3
@ -594,9 +571,18 @@ Why: In 3.0, we can now autodetect internal 3G device and already have
Who: Lee, Chun-Yi <jlee@novell.com>
----------------------------
What: The XFS nodelaylog mount option
When: 3.3
Why: The delaylog mode that has been the default since 2.6.39 has proven
stable, and the old code is in the way of additional improvements in
the log code.
Who: Christoph Hellwig <hch@lst.de>
----------------------------
What: iwlagn alias support
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>

2
Documentation/filesystems/9p.txt
View File

@ -92,7 +92,7 @@ OPTIONS
wfdno=n the file descriptor for writing with trans=fd
maxdata=n the number of bytes to use for 9p packet payload (msize)
msize=n the number of bytes to use for 9p packet payload
port=n port to connect to on the remote server

6
Documentation/filesystems/caching/object.txt
View File

@ -127,9 +127,9 @@ fscache_enqueue_object()).
PROVISION OF CPU TIME
---------------------
The work to be done by the various states is given CPU time by the threads of
the slow work facility (see Documentation/slow-work.txt). This is used in
preference to the workqueue facility because:
The work to be done by the various states was given CPU time by the threads of
the slow work facility. This was used in preference to the workqueue facility
because:
(1) Threads may be completely occupied for very long periods of time by a
particular work item. These state actions may be doing sequences of

11
Documentation/filesystems/locks.txt
View File

@ -53,11 +53,12 @@ fcntl(), with all the problems that implies.
1.3 Mandatory Locking As A Mount Option
---------------------------------------
Mandatory locking, as described in 'Documentation/filesystems/mandatory.txt'
was prior to this release a general configuration option that was valid for
all mounted filesystems. This had a number of inherent dangers, not the
least of which was the ability to freeze an NFS server by asking it to read
a file for which a mandatory lock existed.
Mandatory locking, as described in
'Documentation/filesystems/mandatory-locking.txt' was prior to this release a
general configuration option that was valid for all mounted filesystems. This
had a number of inherent dangers, not the least of which was the ability to
freeze an NFS server by asking it to read a file for which a mandatory lock
existed.
From this release of the kernel, mandatory locking can be turned on and off
on a per-filesystem basis, using the mount options 'mand' and 'nomand'.

2
Documentation/filesystems/nfs/idmapper.txt
View File

@ -47,7 +47,7 @@ request-key will find the first matching line and corresponding program. In
this case, /some/other/program will handle all uid lookups and
/usr/sbin/nfs.idmap will handle gid, user, and group lookups.
See <file:Documentation/security/keys-request-keys.txt> for more information
See <file:Documentation/security/keys-request-key.txt> for more information
about the request-key function.

5
Documentation/filesystems/pohmelfs/design_notes.txt
View File

@ -58,8 +58,9 @@ data transfers.
POHMELFS clients operate with a working set of servers and are capable of balancing read-only
operations (like lookups or directory listings) between them according to IO priorities.
Administrators can add or remove servers from the set at run-time via special commands (described
in Documentation/pohmelfs/info.txt file). Writes are replicated to all servers, which are connected
with write permission turned on. IO priority and permissions can be changed in run-time.
in Documentation/filesystems/pohmelfs/info.txt file). Writes are replicated to all servers, which
are connected with write permission turned on. IO priority and permissions can be changed in
run-time.
POHMELFS is capable of full data channel encryption and/or strong crypto hashing.
One can select any kernel supported cipher, encryption mode, hash type and operation mode

2
Documentation/filesystems/proc.txt
View File

@ -1263,7 +1263,7 @@ review the kernel documentation in the directory /usr/src/linux/Documentation.
This chapter is heavily based on the documentation included in the pre 2.2
kernels, and became part of it in version 2.2.1 of the Linux kernel.
Please see: Documentation/sysctls/ directory for descriptions of these
Please see: Documentation/sysctl/ directory for descriptions of these
entries.
------------------------------------------------------------------------------

10
Documentation/filesystems/sysfs.txt
View File

@ -4,7 +4,7 @@ sysfs - _The_ filesystem for exporting kernel objects.
Patrick Mochel <mochel@osdl.org>
Mike Murphy <mamurph@cs.clemson.edu>
Revised: 15 July 2010
Revised: 16 August 2011
Original: 10 January 2003
@ -370,3 +370,11 @@ int driver_create_file(struct device_driver *, const struct driver_attribute *);
void driver_remove_file(struct device_driver *, const struct driver_attribute *);
Documentation
~~~~~~~~~~~~~
The sysfs directory structure and the attributes in each directory define an
ABI between the kernel and user space. As for any ABI, it is important that
this ABI is stable and properly documented. All new sysfs attributes must be
documented in Documentation/ABI. See also Documentation/ABI/README for more
information.

3
Documentation/filesystems/vfs.txt
View File

@ -1053,9 +1053,6 @@ manipulate dentries:
and the dentry is returned. The caller must use dput()
to free the dentry when it finishes using it.
For further information on dentry locking, please refer to the document
Documentation/filesystems/dentry-locking.txt.
Mount Options
=============

6
Documentation/frv/booting.txt
View File

@ -180,9 +180,3 @@ separated by spaces:
This tells the kernel what program to run initially. By default this is
/sbin/init, but /sbin/sash or /bin/sh are common alternatives.
(*) vdc=...
This option configures the MB93493 companion chip visual display
driver. Please see Documentation/frv/mb93493/vdc.txt for more
information.

25
Documentation/hwmon/ad7314 Normal file
View File

@ -0,0 +1,25 @@
Kernel driver ad7314
====================
Supported chips:
* Analog Devices AD7314
Prefix: 'ad7314'
Datasheet: Publicly available at Analog Devices website.
* Analog Devices ADT7301
Prefix: 'adt7301'
Datasheet: Publicly available at Analog Devices website.
* Analog Devices ADT7302
Prefix: 'adt7302'
Datasheet: Publicly available at Analog Devices website.
Description
-----------
Driver supports the above parts. The ad7314 has a 10 bit
sensor with 1lsb = 0.25 degrees centigrade. The adt7301 and
adt7302 have 14 bit sensors with 1lsb = 0.03125 degrees centigrade.
Notes
-----
Currently power down mode is not supported.

40
Documentation/hwmon/adm1275
View File

@ -6,6 +6,10 @@ Supported chips:
Prefix: 'adm1275'
Addresses scanned: -
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1275.pdf
* Analog Devices ADM1276
Prefix: 'adm1276'
Addresses scanned: -
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
@ -13,13 +17,13 @@ Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
This driver supports hardware montoring for Analog Devices ADM1275 Hot-Swap
Controller and Digital Power Monitor.
This driver supports hardware montoring for Analog Devices ADM1275 and ADM1276
Hot-Swap Controller and Digital Power Monitor.
The ADM1275 is a hot-swap controller that allows a circuit board to be removed
from or inserted into a live backplane. It also features current and voltage
readback via an integrated 12-bit analog-to-digital converter (ADC), accessed
using a PMBus. interface.
ADM1275 and ADM1276 are hot-swap controllers that allow a circuit board to be
removed from or inserted into a live backplane. They also feature current and
voltage readback via an integrated 12-bit analog-to-digital converter (ADC),
accessed using a PMBus interface.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
@ -48,17 +52,25 @@ attributes are write-only, all other attributes are read-only.
in1_label "vin1" or "vout1" depending on chip variant and
configuration.
in1_input Measured voltage. From READ_VOUT register.
in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
in1_input Measured voltage.
in1_min Minumum Voltage.
in1_max Maximum voltage.
in1_min_alarm Voltage low alarm.
in1_max_alarm Voltage high alarm.
in1_highest Historical maximum voltage.
in1_reset_history Write any value to reset history.
curr1_label "iout1"
curr1_input Measured current. From READ_IOUT register.
curr1_max Maximum current. From IOUT_OC_WARN_LIMIT register.
curr1_max_alarm Current high alarm. From IOUT_OC_WARN_LIMIT register.
curr1_input Measured current.
curr1_max Maximum current.
curr1_max_alarm Current high alarm.
curr1_lcrit Critical minimum current. Depending on the chip
configuration, either curr1_lcrit or curr1_crit is
supported, but not both.
curr1_lcrit_alarm Critical current low alarm.
curr1_crit Critical maximum current. Depending on the chip
configuration, either curr1_lcrit or curr1_crit is
supported, but not both.
curr1_crit_alarm Critical current high alarm.
curr1_highest Historical maximum current.
curr1_reset_history Write any value to reset history.

81
Documentation/hwmon/exynos4_tmu Normal file
View File

@ -0,0 +1,81 @@
Kernel driver exynos4_tmu
=================
Supported chips:
* ARM SAMSUNG EXYNOS4 series of SoC
Prefix: 'exynos4-tmu'
Datasheet: Not publicly available
Authors: Donggeun Kim <dg77.kim@samsung.com>
Description
-----------
This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC.
The chip only exposes the measured 8-bit temperature code value
through a register.
Temperature can be taken from the temperature code.
There are three equations converting from temperature to temperature code.
The three equations are:
1. Two point trimming
Tc = (T - 25) * (TI2 - TI1) / (85 - 25) + TI1
2. One point trimming
Tc = T + TI1 - 25
3. No trimming
Tc = T + 50
Tc: Temperature code, T: Temperature,
TI1: Trimming info for 25 degree Celsius (stored at TRIMINFO register)
Temperature code measured at 25 degree Celsius which is unchanged
TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register)
Temperature code measured at 85 degree Celsius which is unchanged
TMU(Thermal Management Unit) in EXYNOS4 generates interrupt
when temperature exceeds pre-defined levels.
The maximum number of configurable threshold is four.
The threshold levels are defined as follows:
Level_0: current temperature > trigger_level_0 + threshold
Level_1: current temperature > trigger_level_1 + threshold
Level_2: current temperature > trigger_level_2 + threshold
Level_3: current temperature > trigger_level_3 + threshold
The threshold and each trigger_level are set
through the corresponding registers.
When an interrupt occurs, this driver notify user space of
one of four threshold levels for the interrupt
through kobject_uevent_env and sysfs_notify functions.
Although an interrupt condition for level_0 can be set,
it is not notified to user space through sysfs_notify function.
Sysfs Interface
---------------
name name of the temperature sensor
RO
temp1_input temperature
RO
temp1_max temperature for level_1 interrupt
RO
temp1_crit temperature for level_2 interrupt
RO
temp1_emergency temperature for level_3 interrupt
RO
temp1_max_alarm alarm for level_1 interrupt
RO
temp1_crit_alarm
alarm for level_2 interrupt
RO
temp1_emergency_alarm
alarm for level_3 interrupt
RO

61
Documentation/hwmon/lm75
View File

@ -12,26 +12,46 @@ Supported chips:
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
* Dallas Semiconductor DS75
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.maxim-ic.com/
* Dallas Semiconductor DS1775
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
* Dallas Semiconductor DS75, DS1775
Prefixes: 'ds75', 'ds1775'
Addresses scanned: none
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.maxim-ic.com/
* Maxim MAX6625, MAX6626
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4b
Prefixes: 'max6625', 'max6626'
Addresses scanned: none
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/
* Microchip (TelCom) TCN75
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Addresses scanned: none
Datasheet: Publicly available at the Microchip website
http://www.microchip.com/
* Microchip MCP9800, MCP9801, MCP9802, MCP9803
Prefix: 'mcp980x'
Addresses scanned: none
Datasheet: Publicly available at the Microchip website
http://www.microchip.com/
* Analog Devices ADT75
Prefix: 'adt75'
Addresses scanned: none
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/adt75
* ST Microelectronics STDS75
Prefix: 'stds75'
Addresses scanned: none
Datasheet: Publicly available at the ST website
http://www.st.com/internet/analog/product/121769.jsp
* Texas Instruments TMP100, TMP101, TMP105, TMP75, TMP175, TMP275
Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp175', 'tmp75', 'tmp275'
Addresses scanned: none
Datasheet: Publicly available at the Texas Instruments website
http://www.ti.com/product/tmp100
http://www.ti.com/product/tmp101
http://www.ti.com/product/tmp105
http://www.ti.com/product/tmp75
http://www.ti.com/product/tmp175
http://www.ti.com/product/tmp275
Author: Frodo Looijaard <frodol@dds.nl>
@ -50,21 +70,16 @@ range of -55 to +125 degrees.
The LM75 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
The LM75 is usually used in combination with LM78-like chips, to measure
the temperature of the processor(s).
The DS75, DS1775, MAX6625, and MAX6626 are supported as well.
They are not distinguished from an LM75. While most of these chips
have three additional bits of accuracy (12 vs. 9 for the LM75),
the additional bits are not supported. Not only that, but these chips will
not be detected if not in 9-bit precision mode (use the force parameter if
needed).
The TCN75 is supported as well, and is not distinguished from an LM75.
The original LM75 was typically used in combination with LM78-like chips
on PC motherboards, to measure the temperature of the processor(s). Clones
are now used in various embedded designs.
The LM75 is essentially an industry standard; there may be other
LM75 clones not listed here, with or without various enhancements,
that are supported.
that are supported. The clones are not detected by the driver, unless
they reproduce the exact register tricks of the original LM75, and must
therefore be instantiated explicitly. The specific enhancements (such as
higher resolution) are not currently supported by the driver.
The LM77 is not supported, contrary to what we pretended for a long time.
Both chips are simply not compatible, value encoding differs.

103
Documentation/hwmon/ltc2978 Normal file
View File

@ -0,0 +1,103 @@
Kernel driver ltc2978
=====================
Supported chips:
* Linear Technology LTC2978
Prefix: 'ltc2978'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
* Linear Technology LTC3880
Prefix: 'ltc3880'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/3880f.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
The LTC2978 is an octal power supply monitor, supervisor, sequencer and
margin controller. The LTC3880 is a dual, PolyPhase DC/DC synchronous
step-down switching regulator controller.
Usage Notes
-----------
This driver does not probe for PMBus devices. You will have to instantiate
devices explicitly.
Example: the following commands will load the driver for an LTC2978 at address
0x60 on I2C bus #1:
# modprobe ltc2978
# echo ltc2978 0x60 > /sys/bus/i2c/devices/i2c-1/new_device
Sysfs attributes
----------------
in1_label "vin"
in1_input Measured input voltage.
in1_min Minimum input voltage.
in1_max Maximum input voltage.
in1_lcrit Critical minimum input voltage.
in1_crit Critical maximum input voltage.
in1_min_alarm Input voltage low alarm.
in1_max_alarm Input voltage high alarm.
in1_lcrit_alarm Input voltage critical low alarm.
in1_crit_alarm Input voltage critical high alarm.
in1_lowest Lowest input voltage. LTC2978 only.
in1_highest Highest input voltage.
in1_reset_history Reset history. Writing into this attribute will reset
history for all attributes.
in[2-9]_label "vout[1-8]". Channels 3 to 9 on LTC2978 only.
in[2-9]_input Measured output voltage.
in[2-9]_min Minimum output voltage.
in[2-9]_max Maximum output voltage.
in[2-9]_lcrit Critical minimum output voltage.
in[2-9]_crit Critical maximum output voltage.
in[2-9]_min_alarm Output voltage low alarm.
in[2-9]_max_alarm Output voltage high alarm.
in[2-9]_lcrit_alarm Output voltage critical low alarm.
in[2-9]_crit_alarm Output voltage critical high alarm.
in[2-9]_lowest Lowest output voltage. LTC2978 only.
in[2-9]_highest Lowest output voltage.
in[2-9]_reset_history Reset history. Writing into this attribute will reset
history for all attributes.
temp[1-3]_input Measured temperature.
On LTC2978, only one temperature measurement is
supported and reflects the internal temperature.
On LTC3880, temp1 and temp2 report external
temperatures, and temp3 reports the internal
temperature.
temp[1-3]_min Mimimum temperature.
temp[1-3]_max Maximum temperature.
temp[1-3]_lcrit Critical low temperature.
temp[1-3]_crit Critical high temperature.
temp[1-3]_min_alarm Chip temperature low alarm.
temp[1-3]_max_alarm Chip temperature high alarm.
temp[1-3]_lcrit_alarm Chip temperature critical low alarm.
temp[1-3]_crit_alarm Chip temperature critical high alarm.
temp[1-3]_lowest Lowest measured temperature. LTC2978 only.
temp[1-3]_highest Highest measured temperature.
temp[1-3]_reset_history Reset history. Writing into this attribute will reset
history for all attributes.
power[1-2]_label "pout[1-2]". LTC3880 only.
power[1-2]_input Measured power.
curr1_label "iin". LTC3880 only.
curr1_input Measured input current.
curr1_max Maximum input current.
curr1_max_alarm Input current high alarm.
curr[2-3]_label "iout[1-2]". LTC3880 only.
curr[2-3]_input Measured input current.
curr[2-3]_max Maximum input current.
curr[2-3]_crit Critical input current.
curr[2-3]_max_alarm Input current high alarm.
curr[2-3]_crit_alarm Input current critical high alarm.

13
Documentation/hwmon/pmbus
View File

@ -8,11 +8,6 @@ Supported chips:
Addresses scanned: -
Datasheet:
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395
* Linear Technology LTC2978
Octal PMBus Power Supply Monitor and Controller
Prefix: 'ltc2978'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
* ON Semiconductor ADP4000, NCP4200, NCP4208
Prefixes: 'adp4000', 'ncp4200', 'ncp4208'
Addresses scanned: -
@ -20,6 +15,14 @@ Supported chips:
http://www.onsemi.com/pub_link/Collateral/ADP4000-D.PDF
http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF
http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF
* Lineage Power
Prefixes: 'pdt003', 'pdt006', 'pdt012', 'udt020'
Addresses scanned: -
Datasheets:
http://www.lineagepower.com/oem/pdf/PDT003A0X.pdf
http://www.lineagepower.com/oem/pdf/PDT006A0X.pdf
http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf
http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf
* Generic PMBus devices
Prefix: 'pmbus'
Addresses scanned: -

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