asgardius/android_kernel_motorola_sm6225
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge remote-tracking branch 'wireless/master' into mac80211

Browse source
This commit is contained in:
Johannes Berg 2012-07-30 09:13:03 +02:00
commit fcb06702f0
4412 changed files with 147028 additions and 96298 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.mailmap
View file

@ -111,6 +111,7 @@ Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <ukl@pengutronix.de>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Viresh Kumar <viresh.linux@gmail.com> <viresh.kumar@st.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Yusuke Goda <goda.yusuke@renesas.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>

21
Documentation/ABI/testing/sysfs-block-rssd
View file

@ -1,26 +1,5 @@
What: /sys/block/rssd*/registers
Date: March 2012
KernelVersion: 3.3
Contact: Asai Thambi S P <asamymuthupa@micron.com>
Description: This is a read-only file. Dumps below driver information and
hardware registers.
- S ACTive
- Command Issue
- Completed
- PORT IRQ STAT
- HOST IRQ STAT
- Allocated
- Commands in Q
What: /sys/block/rssd*/status
Date: April 2012
KernelVersion: 3.4
Contact: Asai Thambi S P <asamymuthupa@micron.com>
Description: This is a read-only file. Indicates the status of the device.
What: /sys/block/rssd*/flags
Date: May 2012
KernelVersion: 3.5
Contact: Asai Thambi S P <asamymuthupa@micron.com>
Description: This is a read-only file. Dumps the flags in port and driver
data structure

31
Documentation/ABI/testing/sysfs-bus-iio
View file

@ -219,6 +219,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
@ -273,6 +274,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
What: /sys/.../iio:deviceX/in_voltageX_scale_available
What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
What: /sys/.../iio:deviceX/out_voltageX_scale_available
What: /sys/.../iio:deviceX/out_altvoltageX_scale_available
What: /sys/.../iio:deviceX/in_capacitance_scale_available
KernelVersion: 2.635
Contact: linux-iio@vger.kernel.org
@ -298,14 +300,19 @@ Description:
gives the 3dB frequency of the filter in Hz.
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_raw
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled, no bias etc.) output voltage for
channel Y. The number must always be specified and
unique if the output corresponds to a single channel.
While DAC like devices typically use out_voltage,
a continuous frequency generating device, such as
a DDS or PLL should use out_altvoltage.
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY&Z_raw
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY&Z_raw
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@ -316,6 +323,8 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown_mode
What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown_mode
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown_mode
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown_mode
KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
@ -330,6 +339,8 @@ Description:
What: /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
What: /sys/.../iio:deviceX/out_voltage_powerdown_mode_available
What: /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
What: /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
@ -338,6 +349,8 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown
What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown
KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
@ -346,6 +359,24 @@ Description:
normal operation. Y may be suppressed if all outputs are
controlled together.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Output frequency for channel Y in Hz. The number must always be
specified and unique if the output corresponds to a single
channel.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Phase in radians of one frequency/clock output Y
(out_altvoltageY) relative to another frequency/clock output
(out_altvoltageZ) of the device X. The number must always be
specified and unique if the output corresponds to a single
channel.
What: /sys/bus/iio/devices/iio:deviceX/events
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org

17
Documentation/ABI/testing/sysfs-class-mtd
View file

@ -142,13 +142,14 @@ KernelVersion: 3.4
Contact: linux-mtd@lists.infradead.org
Description:
This allows the user to examine and adjust the criteria by which
mtd returns -EUCLEAN from mtd_read(). If the maximum number of
bit errors that were corrected on any single region comprising
an ecc step (as reported by the driver) equals or exceeds this
value, -EUCLEAN is returned. Otherwise, absent an error, 0 is
returned. Higher layers (e.g., UBI) use this return code as an
indication that an erase block may be degrading and should be
scrutinized as a candidate for being marked as bad.
mtd returns -EUCLEAN from mtd_read() and mtd_read_oob(). If the
maximum number of bit errors that were corrected on any single
region comprising an ecc step (as reported by the driver) equals
or exceeds this value, -EUCLEAN is returned. Otherwise, absent
an error, 0 is returned. Higher layers (e.g., UBI) use this
return code as an indication that an erase block may be
degrading and should be scrutinized as a candidate for being
marked as bad.
The initial value may be specified by the flash device driver.
If not, then the default value is ecc_strength.
@ -167,7 +168,7 @@ Description:
block degradation, but high enough to avoid the consequences of
a persistent return value of -EUCLEAN on devices where sticky
bitflips occur. Note that if bitflip_threshold exceeds
ecc_strength, -EUCLEAN is never returned by mtd_read().
ecc_strength, -EUCLEAN is never returned by the read operations.
Conversely, if bitflip_threshold is zero, -EUCLEAN is always
returned, absent a hard error.

13
Documentation/ABI/testing/sysfs-power
View file

@ -231,3 +231,16 @@ Description:
Reads from this file return a string consisting of the names of
wakeup sources created with the help of /sys/power/wake_lock
that are inactive at the moment, separated with spaces.
What: /sys/power/pm_print_times
Date: May 2012
Contact: Sameer Nanda <snanda@chromium.org>
Description:
The /sys/power/pm_print_times file allows user space to
control whether the time taken by devices to suspend and
resume is printed. These prints are useful for hunting down
devices that take too long to suspend or resume.
Writing a "1" enables this printing while writing a "0"
disables it. The default value is "0". Reading from this file
will display the current value.

1
Documentation/DocBook/80211.tmpl
View file

@ -404,7 +404,6 @@
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv
!Finclude/net/mac80211.h ieee80211_get_tkip_p2k
!Finclude/net/mac80211.h ieee80211_key_removed
</chapter>
<chapter id="powersave">

2
Documentation/DocBook/media/v4l/controls.xml
View file

@ -3988,7 +3988,7 @@ interface and may change in the future.</para>
from RGB to Y'CbCr color space.
</entry>
</row>
<row id = "v4l2-jpeg-chroma-subsampling">
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>

4
Documentation/DocBook/media/v4l/pixfmt.xml
View file

@ -986,13 +986,13 @@ http://www.thedirks.org/winnov/</ulink></para></entry>
<row id="V4L2-PIX-FMT-Y4">
<entry><constant>V4L2_PIX_FMT_Y4</constant></entry>
<entry>'Y04 '</entry>
<entry>Old 4-bit greyscale format. Only the least significant 4 bits of each byte are used,
<entry>Old 4-bit greyscale format. Only the most significant 4 bits of each byte are used,
the other bits are set to 0.</entry>
</row>
<row id="V4L2-PIX-FMT-Y6">
<entry><constant>V4L2_PIX_FMT_Y6</constant></entry>
<entry>'Y06 '</entry>
<entry>Old 6-bit greyscale format. Only the least significant 6 bits of each byte are used,
<entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used,
the other bits are set to 0.</entry>
</row>
</tbody>

2
Documentation/DocBook/media/v4l/v4l2.xml
View file

@ -560,6 +560,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-g-tuner;
&sub-log-status;
&sub-overlay;
&sub-prepare-buf;
&sub-qbuf;
&sub-querybuf;
&sub-querycap;
@ -567,7 +568,6 @@ and discussions on the V4L mailing list.</revremark>
&sub-query-dv-preset;
&sub-query-dv-timings;
&sub-querystd;
&sub-prepare-buf;
&sub-reqbufs;
&sub-s-hw-freq-seek;
&sub-streamon;

5
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
View file

@ -108,10 +108,9 @@ information.</para>
/></entry>
</row>
<row>
<entry>__u32</entry>
<entry>struct&nbsp;v4l2_format</entry>
<entry><structfield>format</structfield></entry>
<entry>Filled in by the application, preserved by the driver.
See <xref linkend="v4l2-format" />.</entry>
<entry>Filled in by the application, preserved by the driver.</entry>
</row>
<row>
<entry>__u32</entry>

2
Documentation/DocBook/media/v4l/vidioc-dqevent.xml
View file

@ -89,7 +89,7 @@
<row>
<entry></entry>
<entry>&v4l2-event-frame-sync;</entry>
<entry><structfield>frame</structfield></entry>
<entry><structfield>frame_sync</structfield></entry>
<entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
</row>
<row>

7
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View file

@ -284,13 +284,6 @@ These controls are described in <xref
processing controls. These controls are described in <xref
linkend="image-process-controls" />.</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_CLASS_JPEG</constant></entry>
<entry>0x9d0000</entry>
<entry>The class containing JPEG compression controls.
These controls are described in <xref
linkend="jpeg-controls" />.</entry>
</row>
</tbody>
</tgroup>
</table>

39
Documentation/RCU/checklist.txt
View file

@ -162,9 +162,9 @@ over a rather long period of time, but improvements are always welcome!
when publicizing a pointer to a structure that can
be traversed by an RCU read-side critical section.
5. If call_rcu(), or a related primitive such as call_rcu_bh() or
call_rcu_sched(), is used, the callback function must be
written to be called from softirq context. In particular,
5. If call_rcu(), or a related primitive such as call_rcu_bh(),
call_rcu_sched(), or call_srcu() is used, the callback function
must be written to be called from softirq context. In particular,
it cannot block.
6. Since synchronize_rcu() can block, it cannot be called from
@ -202,11 +202,12 @@ over a rather long period of time, but improvements are always welcome!
updater uses call_rcu_sched() or synchronize_sched(), then
the corresponding readers must disable preemption, possibly
by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
If the updater uses synchronize_srcu(), the the corresponding
readers must use srcu_read_lock() and srcu_read_unlock(),
and with the same srcu_struct. The rules for the expedited
primitives are the same as for their non-expedited counterparts.
Mixing things up will result in confusion and broken kernels.
If the updater uses synchronize_srcu() or call_srcu(),
the the corresponding readers must use srcu_read_lock() and
srcu_read_unlock(), and with the same srcu_struct. The rules for
the expedited primitives are the same as for their non-expedited
counterparts. Mixing things up will result in confusion and
broken kernels.
One exception to this rule: rcu_read_lock() and rcu_read_unlock()
may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()
@ -333,14 +334,14 @@ over a rather long period of time, but improvements are always welcome!
victim CPU from ever going offline.)
14. SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(),
synchronize_srcu(), and synchronize_srcu_expedited()) may only
be invoked from process context. Unlike other forms of RCU, it
-is- permissible to block in an SRCU read-side critical section
(demarked by srcu_read_lock() and srcu_read_unlock()), hence the
"SRCU": "sleepable RCU". Please note that if you don't need
to sleep in read-side critical sections, you should be using
RCU rather than SRCU, because RCU is almost always faster and
easier to use than is SRCU.
synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu())
may only be invoked from process context. Unlike other forms of
RCU, it -is- permissible to block in an SRCU read-side critical
section (demarked by srcu_read_lock() and srcu_read_unlock()),
hence the "SRCU": "sleepable RCU". Please note that if you
don't need to sleep in read-side critical sections, you should be
using RCU rather than SRCU, because RCU is almost always faster
and easier to use than is SRCU.
If you need to enter your read-side critical section in a
hardirq or exception handler, and then exit that same read-side
@ -353,8 +354,8 @@ over a rather long period of time, but improvements are always welcome!
cleanup_srcu_struct(). These are passed a "struct srcu_struct"
that defines the scope of a given SRCU domain. Once initialized,
the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()
synchronize_srcu(), and synchronize_srcu_expedited(). A given
synchronize_srcu() waits only for SRCU read-side critical
synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu().
A given synchronize_srcu() waits only for SRCU read-side critical
sections governed by srcu_read_lock() and srcu_read_unlock()
calls that have been passed the same srcu_struct. This property
is what makes sleeping read-side critical sections tolerable --
@ -374,7 +375,7 @@ over a rather long period of time, but improvements are always welcome!
requiring SRCU's read-side deadlock immunity or low read-side
realtime latency.
Note that, rcu_assign_pointer() relates to SRCU just as they do
Note that, rcu_assign_pointer() relates to SRCU just as it does
to other forms of RCU.
15. The whole point of call_rcu(), synchronize_rcu(), and friends

15
Documentation/RCU/rcubarrier.txt
View file

@ -79,8 +79,6 @@ complete. Pseudo-code using rcu_barrier() is as follows:
2. Execute rcu_barrier().
3. Allow the module to be unloaded.
Quick Quiz #1: Why is there no srcu_barrier()?
The rcutorture module makes use of rcu_barrier in its exit function
as follows:
@ -162,7 +160,7 @@ for any pre-existing callbacks to complete.
Then lines 55-62 print status and do operation-specific cleanup, and
then return, permitting the module-unload operation to be completed.
Quick Quiz #2: Is there any other situation where rcu_barrier() might
Quick Quiz #1: Is there any other situation where rcu_barrier() might
be required?
Your module might have additional complications. For example, if your
@ -242,7 +240,7 @@ reaches zero, as follows:
4 complete(&rcu_barrier_completion);
5 }
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in
@ -259,12 +257,7 @@ so that your module may be safely unloaded.
Answers to Quick Quizzes
Quick Quiz #1: Why is there no srcu_barrier()?
Answer: Since there is no call_srcu(), there can be no outstanding SRCU
callbacks. Therefore, there is no need to wait for them.
Quick Quiz #2: Is there any other situation where rcu_barrier() might
Quick Quiz #1: Is there any other situation where rcu_barrier() might
be required?
Answer: Interestingly enough, rcu_barrier() was not originally
@ -278,7 +271,7 @@ Answer: Interestingly enough, rcu_barrier() was not originally
implementing rcutorture, and found that rcu_barrier() solves
this problem as well.
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in

9
Documentation/RCU/torture.txt
View file

@ -174,11 +174,20 @@ torture_type The type of RCU to test, with string values as follows:
and synchronize_rcu_bh_expedited().
"srcu": srcu_read_lock(), srcu_read_unlock() and
call_srcu().
"srcu_sync": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu().
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu_expedited().
"srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
and call_srcu().
"srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
and synchronize_srcu().
"sched": preempt_disable(), preempt_enable(), and
call_rcu_sched().

6
Documentation/RCU/whatisRCU.txt
View file

@ -833,9 +833,9 @@ sched: Critical sections Grace period Barrier
SRCU: Critical sections Grace period Barrier
srcu_read_lock synchronize_srcu N/A
srcu_read_unlock synchronize_srcu_expedited
srcu_read_lock_raw
srcu_read_lock synchronize_srcu srcu_barrier
srcu_read_unlock call_srcu
srcu_read_lock_raw synchronize_srcu_expedited
srcu_read_unlock_raw
srcu_dereference

2
Documentation/arm/SPEAr/overview.txt
View file

@ -60,4 +60,4 @@ Introduction
Document Author
---------------
Viresh Kumar <viresh.kumar@st.com>, (c) 2010-2012 ST Microelectronics
Viresh Kumar <viresh.linux@gmail.com>, (c) 2010-2012 ST Microelectronics

13
Documentation/connector/cn_test.c
View file

@ -69,9 +69,13 @@ static int cn_test_want_notify(void)
return -ENOMEM;
}
nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh));
nlh = nlmsg_put(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh), 0);
if (!nlh) {
kfree_skb(skb);
return -EMSGSIZE;
}
msg = (struct cn_msg *)NLMSG_DATA(nlh);
msg = nlmsg_data(nlh);
memset(msg, 0, size0);
@ -117,11 +121,6 @@ static int cn_test_want_notify(void)
pr_info("request was sent: group=0x%x\n", ctl->group);
return 0;
nlmsg_failure:
pr_err("failed to send %u.%u\n", msg->seq, msg->ack);
kfree_skb(skb);
return -EINVAL;
}
#endif

129
Documentation/device-mapper/verity.txt
View file

@ -7,39 +7,39 @@ This target is read-only.
Construction Parameters
=======================
<version> <dev> <hash_dev> <hash_start>
<version> <dev> <hash_dev>
<data_block_size> <hash_block_size>
<num_data_blocks> <hash_start_block>
<algorithm> <digest> <salt>
<version>
This is the version number of the on-disk format.
This is the type of the on-disk hash format.
0 is the original format used in the Chromium OS.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeros.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeros.
1 is the current format that should be used for new devices.
The salt is prepended when hashing and each digest is
padded with zeros to the power of two.
The salt is prepended when hashing and each digest is
padded with zeros to the power of two.
<dev>
This is the device containing the data the integrity of which needs to be
This is the device containing data, the integrity of which needs to be
checked. It may be specified as a path, like /dev/sdaX, or a device number,
<major>:<minor>.
<hash_dev>
This is the device that that supplies the hash tree data. It may be
This is the device that supplies the hash tree data. It may be
specified similarly to the device path and may be the same device. If the
same device is used, the hash_start should be outside of the dm-verity
configured device size.
same device is used, the hash_start should be outside the configured
dm-verity device.
<data_block_size>
The block size on a data device. Each block corresponds to one digest on
the hash device.
The block size on a data device in bytes.
Each block corresponds to one digest on the hash device.
<hash_block_size>
The size of a hash block.
The size of a hash block in bytes.
<num_data_blocks>
The number of data blocks on the data device. Additional blocks are
@ -65,7 +65,7 @@ Construction Parameters
Theory of operation
===================
dm-verity is meant to be setup as part of a verified boot path. This
dm-verity is meant to be set up as part of a verified boot path. This
may be anything ranging from a boot using tboot or trustedgrub to just
booting from a known-good device (like a USB drive or CD).
@ -73,20 +73,20 @@ When a dm-verity device is configured, it is expected that the caller
has been authenticated in some way (cryptographic signatures, etc).
After instantiation, all hashes will be verified on-demand during
disk access. If they cannot be verified up to the root node of the
tree, the root hash, then the I/O will fail. This should identify
tree, the root hash, then the I/O will fail. This should detect
tampering with any data on the device and the hash data.
Cryptographic hashes are used to assert the integrity of the device on a
per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly-aligned to the nearest
block the size of a page.
per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly, aligned to the nearest
block size.
Hash Tree
---------
Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
is of some block data on disk. If it is an intermediary node, then the hash is
of a number of child nodes.
of some data block on disk is calculated. If it is an intermediary node,
the hash of a number of child nodes is calculated.
Each entry in the tree is a collection of neighboring nodes that fit in one
block. The number is determined based on block_size and the size of the
@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_size = 4096
On-disk format
==============
Below is the recommended on-disk format. The verity kernel code does not
read the on-disk header. It only reads the hash blocks which directly
follow the header. It is expected that a user-space tool will verify the
integrity of the verity_header and then call dmsetup with the correct
parameters. Alternatively, the header can be omitted and the dmsetup
parameters can be passed via the kernel command-line in a rooted chain
of trust where the command-line is verified.
The verity kernel code does not read the verity metadata on-disk header.
It only reads the hash blocks which directly follow the header.
It is expected that a user-space tool will verify the integrity of the
verity header.
The on-disk format is especially useful in cases where the hash blocks
are on a separate partition. The magic number allows easy identification
of the partition contents. Alternatively, the hash blocks can be stored
in the same partition as the data to be verified. In such a configuration
the filesystem on the partition would be sized a little smaller than
the full-partition, leaving room for the hash blocks.
struct superblock {
uint8_t signature[8]
"verity\0\0";
uint8_t version;
1 - current format
uint8_t data_block_bits;
log2(data block size)
uint8_t hash_block_bits;
log2(hash block size)
uint8_t pad1[1];
zero padding
uint16_t salt_size;
big-endian salt size
uint8_t pad2[2];
zero padding
uint32_t data_blocks_hi;
big-endian high 32 bits of the 64-bit number of data blocks
uint32_t data_blocks_lo;
big-endian low 32 bits of the 64-bit number of data blocks
uint8_t algorithm[16];
cryptographic algorithm
uint8_t salt[384];
salt (the salt size is specified above)
uint8_t pad3[88];
zero padding to 512-byte boundary
}
Alternatively, the header can be omitted and the dmsetup parameters can
be passed via the kernel command-line in a rooted chain of trust where
the command-line is verified.
Directly following the header (and with sector number padded to the next hash
block boundary) are the hash blocks which are stored a depth at a time
(starting from the root), sorted in order of increasing index.
The full specification of kernel parameters and on-disk metadata format
is available at the cryptsetup project's wiki page
http://code.google.com/p/cryptsetup/wiki/DMVerity
Status
======
V (for Valid) is returned if every check performed so far was valid.
@ -174,21 +134,22 @@ If any check failed, C (for Corruption) is returned.
Example
=======
Setup a device:
dmsetup create vroot --table \
"0 2097152 "\
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
Set up a device:
# dmsetup create vroot --readonly --table \
"0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
"1234000000000000000000000000000000000000000000000000000000000000"
A command line tool veritysetup is available to compute or verify
the hash tree or activate the kernel driver. This is available from
the LVM2 upstream repository and may be supplied as a package called
device-mapper-verity-tools:
git://sources.redhat.com/git/lvm2
http://sourceware.org/git/?p=lvm2.git
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
the hash tree or activate the kernel device. This is available from
the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
(as a libcryptsetup extension).
veritysetup -a vroot /dev/sda1 /dev/sda2 \
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
Create hash on the device:
# veritysetup format /dev/sda1 /dev/sda2
...
Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
Activate the device:
# veritysetup create vroot /dev/sda1 /dev/sda2 \
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076

23
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt Normal file
View file

@ -0,0 +1,23 @@
Marvell Armada 370 and Armada XP Interrupt Controller
-----------------------------------------------------
Required properties:
- compatible: Should be "marvell,mpic"
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
The cell is the IRQ number
- reg: Should contain PMIC registers location and length. First pair
for the main interrupt registers, second pair for the per-CPU
interrupt registers
Example:
mpic: interrupt-controller@d0020000 {
compatible = "marvell,mpic";
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
reg = <0xd0020000 0x1000>,
<0xd0021000 0x1000>;
};

11
Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt Normal file
View file

@ -0,0 +1,11 @@
Marvell Armada 370 and Armada XP Global Timers
----------------------------------------------
Required properties:
- compatible: Should be "marvell,armada-370-xp-timer"
- interrupts: Should contain the list of Global Timer interrupts
- reg: Should contain the base address of the Global Timer registers
Optional properties:
- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
Mhz fixed mode (available on Armada XP and not on Armada 370)

24
Documentation/devicetree/bindings/arm/armada-370-xp.txt Normal file
View file

@ -0,0 +1,24 @@
Marvell Armada 370 and Armada XP Platforms Device Tree Bindings
---------------------------------------------------------------
Boards with a SoC of the Marvell Armada 370 and Armada XP families
shall have the following property:
Required root node property:
compatible: must contain "marvell,armada-370-xp"
In addition, boards using the Marvell Armada 370 SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armada370"
In addition, boards using the Marvell Armada XP SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armadaxp"

9
Documentation/devicetree/bindings/arm/atmel-aic.txt
View file

@ -4,7 +4,7 @@ Required properties:
- compatible: Should be "atmel,<chip>-aic"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: For single AIC system, it is an empty property.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 2.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@ -14,7 +14,10 @@ Required properties:
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
Default flag for internal sources should be set to 4 (active high).
The third cell is used to specify the irq priority from 0 (lowest) to 7
(highest).
- reg: Should contain AIC registers location and length
- atmel,external-irqs: u32 array of external irqs.
Examples:
/*
@ -24,7 +27,7 @@ Examples:
compatible = "atmel,at91rm9200-aic";
interrupt-controller;
interrupt-parent;
#interrupt-cells = <2>;
#interrupt-cells = <3>;
reg = <0xfffff000 0x200>;
};
@ -34,5 +37,5 @@ Examples:
dma: dma-controller@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21 4>;
interrupts = <21 4 5>;
};

27
Documentation/devicetree/bindings/arm/davinci/cp-intc.txt Normal file
View file

@ -0,0 +1,27 @@
* TI Common Platform Interrupt Controller
Common Platform Interrupt Controller (cp_intc) is used on
OMAP-L1x SoCs and can support several configurable number
of interrupts.
Main node required properties:
- compatible : should be:
"ti,cp-intc"
- 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 1.
The cell contains the interrupt number in the range [0-128].
- ti,intc-size: Number of interrupts handled by the interrupt controller.
- reg: physical base address and size of the intc registers map.
Example:
intc: interrupt-controller@1 {
compatible = "ti,cp-intc";
interrupt-controller;
#interrupt-cells = <1>;
ti,intc-size = <101>;
reg = <0xfffee000 0x2000>;
};

17
Documentation/devicetree/bindings/arm/mvebu-system-controller.txt Normal file
View file

@ -0,0 +1,17 @@
MVEBU System Controller
-----------------------
MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x)
Required properties:
- compatible: one of:
- "marvell,orion-system-controller"
- "marvell,armada-370-xp-system-controller"
- reg: Should contain system controller registers location and length.
Example:
system-controller@d0018200 {
compatible = "marvell,armada-370-xp-system-controller";
reg = <0xd0018200 0x500>;
};

6
Documentation/devicetree/bindings/arm/olimex.txt Normal file
View file

@ -0,0 +1,6 @@
Olimex i.MX Platforms Device Tree Bindings
------------------------------------------
i.MX23 Olinuxino Low Cost Board
Required root node properties:
- compatible = "olimex,imx23-olinuxino", "fsl,imx23";

6
Documentation/devicetree/bindings/arm/omap/omap.txt
View file

@ -47,3 +47,9 @@ Boards:
- AM335X EVM : Software Developement Board for AM335x
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"

2
Documentation/devicetree/bindings/arm/tegra/emc.txt → Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt
View file

@ -15,7 +15,7 @@ Child device nodes describe the memory settings for different configurations and
Example:
emc@7000f400 {
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
compatible = "nvidia,tegra20-emc";

2
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt
View file

@ -8,7 +8,7 @@ Required properties:
- interrupts : Should contain MC General interrupt.
Example:
mc {
memory-controller@0x7000f000 {
compatible = "nvidia,tegra20-mc";
reg = <0x7000f000 0x024
0x7000f03c 0x3c4>;

2
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt
View file

@ -8,7 +8,7 @@ Required properties:
- interrupts : Should contain MC General interrupt.
Example:
mc {
memory-controller {
compatible = "nvidia,tegra30-mc";
reg = <0x7000f000 0x010
0x7000f03c 0x1b4

19
Documentation/devicetree/bindings/fb/mxsfb.txt Normal file
View file

@ -0,0 +1,19 @@
* Freescale MXS LCD Interface (LCDIF)
Required properties:
- compatible: Should be "fsl,<chip>-lcdif". Supported chips include
imx23 and imx28.
- reg: Address and length of the register set for lcdif
- interrupts: Should contain lcdif interrupts
Optional properties:
- panel-enable-gpios : Should specify the gpio for panel enable
Examples:
lcdif@80030000 {
compatible = "fsl,imx28-lcdif";
reg = <0x80030000 2000>;
interrupts = <38 86>;
panel-enable-gpios = <&gpio3 30 0>;
};

14
Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt
View file

@ -8,8 +8,16 @@ Required properties:
by low 16 pins and the second one is for high 16 pins.
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify optional parameters (currently
unused).
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
The second cell bits[3:0] is used to specify 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.
Example:
@ -19,4 +27,6 @@ gpio0: gpio@73f84000 {
interrupts = <50 51>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

5
Documentation/devicetree/bindings/gpio/gpio-mxs.txt
View file

@ -13,8 +13,9 @@ Required properties for GPIO node:
- interrupts : Should be the port interrupt shared by all 32 pins.
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify optional parameters (currently
unused).
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
The second cell bits[3:0] is used to specify trigger type and level flags:

2
Documentation/devicetree/bindings/gpio/gpio-nmk.txt
View file

@ -26,6 +26,6 @@ Example:
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
supports-sleepmode;
st,supports-sleepmode;
gpio-bank = <1>;
};

0
Documentation/devicetree/bindings/gpio/gpio_nvidia.txt → Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt
View file

93
Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt Normal file
View file

@ -0,0 +1,93 @@
Pinctrl-based I2C Bus Mux
This binding describes an I2C bus multiplexer that uses pin multiplexing to
route the I2C signals, and represents the pin multiplexing configuration
using the pinctrl device tree bindings.
+-----+ +-----+
| dev | | dev |
+------------------------+ +-----+ +-----+
| SoC | | |
| /----|------+--------+
| +---+ +------+ | child bus A, on first set of pins
| |I2C|---|Pinmux| |
| +---+ +------+ | child bus B, on second set of pins
| \----|------+--------+--------+
| | | | |
+------------------------+ +-----+ +-----+ +-----+
| dev | | dev | | dev |
+-----+ +-----+ +-----+
Required properties:
- compatible: i2c-mux-pinctrl
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
Also required are:
* Standard pinctrl properties that specify the pin mux state for each child
bus. See ../pinctrl/pinctrl-bindings.txt.
* Standard I2C mux properties. See mux.txt in this directory.
* I2C child bus nodes. See mux.txt in this directory.
For each named state defined in the pinctrl-names property, an I2C child bus
will be created. I2C child bus numbers are assigned based on the index into
the pinctrl-names property.
The only exception is that no bus will be created for a state named "idle". If
such a state is defined, it must be the last entry in pinctrl-names. For
example:
pinctrl-names = "ddc", "pta", "idle" -> ddc = bus 0, pta = bus 1
pinctrl-names = "ddc", "idle", "pta" -> Invalid ("idle" not last)
pinctrl-names = "idle", "ddc", "pta" -> Invalid ("idle" not last)
Whenever an access is made to a device on a child bus, the relevant pinctrl
state will be programmed into hardware.
If an idle state is defined, whenever an access is not being made to a device
on a child bus, the idle pinctrl state will be programmed into hardware.
If an idle state is not defined, the most recently used pinctrl state will be
left programmed into hardware whenever no access is being made of a device on
a child bus.
Example:
i2cmux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c1>;
pinctrl-names = "ddc", "pta", "idle";
pinctrl-0 = <&state_i2cmux_ddc>;
pinctrl-1 = <&state_i2cmux_pta>;
pinctrl-2 = <&state_i2cmux_idle>;
i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
eeprom {
compatible = "eeprom";
reg = <0x50>;
};
};
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
eeprom {
compatible = "eeprom";
reg = <0x50>;
};
};
};

1
Documentation/devicetree/bindings/input/fsl-mma8450.txt
View file

@ -2,6 +2,7 @@
Required properties:
- compatible : "fsl,mma8450".
- reg: the I2C address of MMA8450
Example:

0
Documentation/devicetree/bindings/input/tegra-kbc.txt → Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
View file

4
Documentation/devicetree/bindings/mfd/mc13xxx.txt
View file

@ -46,8 +46,8 @@ Examples:
ecspi@70010000 { /* ECSPI1 */
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
<&gpio3 25 0>; /* GPIO4_25 */
cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */
<&gpio4 25 0>; /* GPIO4_25 */
status = "okay";
pmic: mc13892@0 {

90
Documentation/devicetree/bindings/mfd/tps65910.txt
View file

@ -17,18 +17,46 @@ Required properties:
device need to be present. The definition for each of these nodes is defined
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
The regulator is matched with the regulator-compatible.
The valid names for regulators are:
The valid regulator-compatible values are:
tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1,
vaux2, vaux33, vmmc
tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
ldo6, ldo7, ldo8
- xxx-supply: Input voltage supply regulator.
These entries are require if regulators are enabled for a device. Missing of these
properties can cause the regulator registration fails.
If some of input supply is powered through battery or always-on supply then
also it is require to have these parameters with proper node handle of always
on power supply.
tps65910:
vcc1-supply: VDD1 input.
vcc2-supply: VDD2 input.
vcc3-supply: VAUX33 and VMMC input.
vcc4-supply: VAUX1 and VAUX2 input.
vcc5-supply: VPLL and VDAC input.
vcc6-supply: VDIG1 and VDIG2 input.
vcc7-supply: VRTC input.
vccio-supply: VIO input.
tps65911:
vcc1-supply: VDD1 input.
vcc2-supply: VDD2 input.
vcc3-supply: LDO6, LDO7 and LDO8 input.
vcc4-supply: LDO5 input.
vcc5-supply: LDO3 and LDO4 input.
vcc6-supply: LDO1 and LDO2 input.
vcc7-supply: VRTC input.
vccio-supply: VIO input.
Optional properties:
- ti,vmbch-threshold: (tps65911) main battery charged threshold
comparator. (see VMBCH_VSEL in TPS65910 datasheet)
- ti,vmbch2-threshold: (tps65911) main battery discharged threshold
comparator. (see VMBCH_VSEL in TPS65910 datasheet)
- ti,en-ck32k-xtal: enable external 32-kHz crystal oscillator (see CK32K_CTRL
in TPS6591X datasheet)
- ti,en-gpio-sleep: enable sleep control for gpios
There should be 9 entries here, one for each gpio.
@ -56,74 +84,110 @@ Example:
ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>;
vcc1-supply = <&reg_parent>;
vcc2-supply = <&some_reg>;
vcc3-supply = <...>;
vcc4-supply = <...>;
vcc5-supply = <...>;
vcc6-supply = <...>;
vcc7-supply = <...>;
vccio-supply = <...>;
regulators {
vdd1_reg: vdd1 {
#address-cells = <1>;
#size-cells = <0>;
vdd1_reg: regulator@0 {
regulator-compatible = "vdd1";
reg = <0>;
regulator-min-microvolt = < 600000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
regulator-boot-on;
ti,regulator-ext-sleep-control = <0>;
};
vdd2_reg: vdd2 {
vdd2_reg: regulator@1 {
regulator-compatible = "vdd2";
reg = <1>;
regulator-min-microvolt = < 600000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
regulator-boot-on;
ti,regulator-ext-sleep-control = <4>;
};
vddctrl_reg: vddctrl {
vddctrl_reg: regulator@2 {
regulator-compatible = "vddctrl";
reg = <2>;
regulator-min-microvolt = < 600000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
ti,regulator-ext-sleep-control = <0>;
};
vio_reg: vio {
vio_reg: regulator@3 {
regulator-compatible = "vio";
reg = <3>;
regulator-min-microvolt = <1500000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-boot-on;
ti,regulator-ext-sleep-control = <1>;
};
ldo1_reg: ldo1 {
ldo1_reg: regulator@4 {
regulator-compatible = "ldo1";
reg = <4>;
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3300000>;
ti,regulator-ext-sleep-control = <0>;
};
ldo2_reg: ldo2 {
ldo2_reg: regulator@5 {
regulator-compatible = "ldo2";
reg = <5>;
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1050000>;
ti,regulator-ext-sleep-control = <0>;
};
ldo3_reg: ldo3 {
ldo3_reg: regulator@6 {
regulator-compatible = "ldo3";
reg = <6>;
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3300000>;
ti,regulator-ext-sleep-control = <0>;
};
ldo4_reg: ldo4 {
ldo4_reg: regulator@7 {
regulator-compatible = "ldo4";
reg = <7>;
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
ti,regulator-ext-sleep-control = <0>;
};
ldo5_reg: ldo5 {
ldo5_reg: regulator@8 {
regulator-compatible = "ldo5";
reg = <8>;
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3300000>;
ti,regulator-ext-sleep-control = <0>;
};
ldo6_reg: ldo6 {
ldo6_reg: regulator@9 {
regulator-compatible = "ldo6";
reg = <9>;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
ti,regulator-ext-sleep-control = <0>;
};
ldo7_reg: ldo7 {
ldo7_reg: regulator@10 {
regulator-compatible = "ldo7";
reg = <10>;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-boot-on;
ti,regulator-ext-sleep-control = <1>;
};
ldo8_reg: ldo8 {
ldo8_reg: regulator@11 {
regulator-compatible = "ldo8";
reg = <11>;
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;

25
Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
View file

@ -3,21 +3,22 @@
The Enhanced Secure Digital Host Controller provides an interface
for MMC, SD, and SDIO types of memory cards.
This file documents differences between the core properties described
by mmc.txt and the properties used by the sdhci-esdhc driver.
Required properties:
- compatible : should be
"fsl,<chip>-esdhc", "fsl,esdhc"
- reg : should contain eSDHC registers location and length.
- interrupts : should contain eSDHC interrupt.
- interrupt-parent : interrupt source phandle.
- clock-frequency : specifies eSDHC base clock frequency.
- sdhci,wp-inverted : (optional) specifies that eSDHC controller
reports inverted write-protect state; New devices should use
the generic "wp-inverted" property.
- sdhci,1-bit-only : (optional) specifies that a controller can
only handle 1-bit data transfers. New devices should use the
generic "bus-width = <1>" property.
- sdhci,auto-cmd12: (optional) specifies that a controller can
only handle auto CMD12.
Optional properties:
- sdhci,wp-inverted : specifies that eSDHC controller reports
inverted write-protect state; New devices should use the generic
"wp-inverted" property.
- sdhci,1-bit-only : specifies that a controller can only handle
1-bit data transfers. New devices should use the generic
"bus-width = <1>" property.
- sdhci,auto-cmd12: specifies that a controller can only handle auto
CMD12.
Example:

12
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
View file

@ -3,17 +3,15 @@
The Enhanced Secure Digital Host Controller on Freescale i.MX family
provides an interface for MMC, SD, and SDIO types of memory cards.
This file documents differences between the core properties described
by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
Required properties:
- compatible : Should be "fsl,<chip>-esdhc"
- reg : Should contain eSDHC registers location and length
- interrupts : Should contain eSDHC interrupt
Optional properties:
- non-removable : Indicate the card is wired to host permanently
- fsl,cd-internal : Indicate to use controller internal card detection
- fsl,wp-internal : Indicate to use controller internal write protection
- cd-gpios : Specify GPIOs for card detection
- wp-gpios : Specify GPIOs for write protection
Examples:
@ -29,6 +27,6 @@ esdhc@70008000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70008000 0x4000>;
interrupts = <2>;
cd-gpios = <&gpio0 6 0>; /* GPIO1_6 */
wp-gpios = <&gpio0 5 0>; /* GPIO1_5 */
cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
};

8
Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
View file

@ -1,8 +1,9 @@
MMC/SD/SDIO slot directly connected to a SPI bus
This file documents differences between the core properties described
by mmc.txt and the properties used by the mmc_spi driver.
Required properties:
- compatible : should be "mmc-spi-slot".
- reg : should specify SPI address (chip-select number).
- spi-max-frequency : maximum frequency for this device (Hz).
- voltage-ranges : two cells are required, first cell specifies minimum
slot voltage (mV), second cell specifies maximum slot voltage (mV).
@ -11,8 +12,7 @@ Required properties:
Optional properties:
- gpios : may specify GPIOs in this order: Card-Detect GPIO,
Write-Protect GPIO. Note that this does not follow the
binding from mmc.txt, for historic reasons.
- interrupts : the interrupt of a card detect interrupt.
binding from mmc.txt, for historical reasons.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.

10
Documentation/devicetree/bindings/mmc/mmc.txt
View file

@ -2,13 +2,17 @@ These properties are common to multiple MMC host controllers. Any host
that requires the respective functionality should implement them using
these definitions.
Interpreted by the OF core:
- reg: Registers location and length.
- interrupts: Interrupts used by the MMC controller.
Required properties:
- bus-width: Number of data lines, can be <1>, <4>, or <8>
Optional properties:
- cd-gpios : Specify GPIOs for card detection, see gpio binding
- wp-gpios : Specify GPIOs for write protection, see gpio binding
- cd-inverted: when present, polarity on the wp gpio line is inverted
- cd-gpios: Specify GPIOs for card detection, see gpio binding
- wp-gpios: Specify GPIOs for write protection, see gpio binding
- cd-inverted: when present, polarity on the cd gpio line is inverted
- wp-inverted: when present, polarity on the wp gpio line is inverted
- non-removable: non-removable slot (like eMMC)
- max-frequency: maximum operating clock frequency

12
Documentation/devicetree/bindings/mmc/mmci.txt
View file

@ -1,19 +1,15 @@
* ARM PrimeCell MultiMedia Card Interface (MMCI) PL180/1
The ARM PrimeCell MMCI PL180 and PL181 provides and interface for
The ARM PrimeCell MMCI PL180 and PL181 provides an interface for
reading and writing to MultiMedia and SD cards alike.
This file documents differences between the core properties described
by mmc.txt and the properties used by the mmci driver.
Required properties:
- compatible : contains "arm,pl18x", "arm,primecell".
- reg : contains pl18x registers and length.
- interrupts : contains the device IRQ(s).
- arm,primecell-periphid : contains the PrimeCell Peripheral ID.
Optional properties:
- wp-gpios : contains any write protect (ro) gpios
- cd-gpios : contains any card detection gpios
- cd-inverted : indicates whether the cd gpio is inverted
- max-frequency : contains the maximum operating frequency
- bus-width : number of data lines, can be <1>, <4>, or <8>
- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable
- mmc-cap-sd-highspeed : indicates whether SD is high speed capable

8
Documentation/devicetree/bindings/mmc/mxs-mmc.txt
View file

@ -3,16 +3,14 @@
The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
to support MMC, SD, and SDIO types of memory cards.
This file documents differences between the core properties in mmc.txt
and the properties used by the mxsmmc driver.
Required properties:
- compatible: Should be "fsl,<chip>-mmc". The supported chips include
imx23 and imx28.
- reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
- fsl,ssp-dma-channel: APBH DMA channel for the SSP
- bus-width: Number of data lines, can be <1>, <4>, or <8>
Optional properties:
- wp-gpios: Specify GPIOs for write protection
Examples:

8
Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt → Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
View file

@ -3,15 +3,13 @@
This controller on Tegra family SoCs provides an interface for MMC, SD,
and SDIO types of memory cards.
This file documents differences between the core properties described
by mmc.txt and the properties used by the sdhci-tegra driver.
Required properties:
- compatible : Should be "nvidia,<chip>-sdhci"
- reg : Should contain SD/MMC registers location and length
- interrupts : Should contain SD/MMC interrupt
- bus-width : Number of data lines, can be <1>, <4>, or <8>
Optional properties:
- cd-gpios : Specify GPIOs for card detection
- wp-gpios : Specify GPIOs for write protection
- power-gpios : Specify GPIOs for power control
Example:

21
Documentation/devicetree/bindings/mmc/sdhci-pxa.txt Normal file
View file

@ -0,0 +1,21 @@
* Marvell sdhci-pxa v2/v3 controller
This file documents differences between the core properties in mmc.txt
and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers.
Required properties:
- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc".
Optional properties:
- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
Example:
sdhci@d4280800 {
compatible = "mrvl,pxav3-mmc";
reg = <0xd4280800 0x800>;
bus-width = <8>;
interrupts = <27>;
non-removable;
mrvl,clk-delay-cycles = <31>;
};

7
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
View file

@ -3,21 +3,20 @@
The Highspeed MMC Host Controller on TI OMAP family
provides an interface for MMC, SD, and SDIO types of memory cards.
This file documents differences between the core properties described
by mmc.txt and the properties used by the omap_hsmmc driver.
Required properties:
- compatible:
Should be "ti,omap2-hsmmc", for OMAP2 controllers
Should be "ti,omap3-hsmmc", for OMAP3 controllers
Should be "ti,omap4-hsmmc", for OMAP4 controllers
- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
- reg : should contain hsmmc registers location and length
Optional properties:
ti,dual-volt: boolean, supports dual voltage cards
<supply-name>-supply: phandle to the regulator device tree node
"supply-name" examples are "vmmc", "vmmc_aux" etc
bus-width: Number of data lines, default assumed is 1 if the property is missing.
cd-gpios: GPIOs for card detection
wp-gpios: GPIOs for write protection
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence

29
Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt Normal file
View file

@ -0,0 +1,29 @@
The Broadcom BCM87XX devices are a family of 10G Ethernet PHYs. They
have these bindings in addition to the standard PHY bindings.
Compatible: Should contain "broadcom,bcm8706" or "broadcom,bcm8727" and
"ethernet-phy-ieee802.3-c45"
Optional Properties:
- broadcom,c45-reg-init : one of more sets of 4 cells. The first cell
is the MDIO Manageable Device (MMD) address, the second a register
address within the MMD, the third cell contains a mask to be ANDed
with the existing register value, and the fourth cell is ORed with
he result to yield the new register value. If the third cell has a
value of zero, no read of the existing value is performed.
Example:
ethernet-phy@5 {
reg = <5>;
compatible = "broadcom,bcm8706", "ethernet-phy-ieee802.3-c45";
interrupt-parent = <&gpio>;
interrupts = <12 8>; /* Pin 12, active low */
/*
* Set PMD Digital Control Register for
* GPIO[1] Tx/Rx
* GPIO[0] R64 Sync Acquired
*/
broadcom,c45-reg-init = <1 0xc808 0xff8f 0x70>;
};

3
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
View file

@ -11,6 +11,9 @@ Required properties:
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
Optional properties:
- clock-frequency : The oscillator frequency driving the flexcan device
Example:

41
Documentation/devicetree/bindings/net/davinci_emac.txt Normal file
View file

@ -0,0 +1,41 @@
* Texas Instruments Davinci EMAC
This file provides information, what the device node
for the davinci_emac interface contains.
Required properties:
- compatible: "ti,davinci-dm6467-emac";
- reg: Offset and length of the register set for the device
- ti,davinci-ctrl-reg-offset: offset to control register
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
- ti,davinci-rmii-en: use RMII
- ti,davinci-no-bd-ram: has the emac controller BD RAM
- phy-handle: Contains a phandle to an Ethernet PHY.
if not, davinci_emac driver defaults to 100/FULL
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
Receive Interrupt
Transmit Interrupt
Miscellaneous Interrupt>
Optional properties:
- local-mac-address : 6 bytes, mac address
Example (enbw_cmc board):
eth0: emac@1e20000 {
compatible = "ti,davinci-dm6467-emac";
reg = <0x220000 0x4000>;
ti,davinci-ctrl-reg-offset = <0x3000>;
ti,davinci-ctrl-mod-reg-offset = <0x2000>;
ti,davinci-ctrl-ram-offset = <0>;
ti,davinci-ctrl-ram-size = <0x2000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <33
34
35
36
>;
interrupt-parent = <&intc>;
};

8
Documentation/devicetree/bindings/net/fsl-fec.txt
View file

@ -7,10 +7,14 @@ Required properties:
- 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".
- phy-reset-gpios : Should specify the gpio for phy reset
Optional properties:
- local-mac-address : 6 bytes, mac address
- phy-reset-gpios : Should specify the gpio for phy reset
- phy-reset-duration : Reset duration in milliseconds. Should present
only if property "phy-reset-gpios" is available. Missing the property
will have the duration be 1 millisecond. Numbers greater than 1000 are
invalid and 1 millisecond will be used instead.
Example:
@ -19,6 +23,6 @@ ethernet@83fec000 {
reg = <0x83fec000 0x4000>;
interrupts = <87>;
phy-mode = "mii";
phy-reset-gpios = <&gpio1 14 0>; /* GPIO2_14 */
phy-reset-gpios = <&gpio2 14 0>; /* GPIO2_14 */
local-mac-address = [00 04 9F 01 1B B9];
};

12
Documentation/devicetree/bindings/net/phy.txt
View file

@ -14,10 +14,20 @@ Required properties:
- linux,phandle : phandle for this node; likely referenced by an
ethernet controller node.
Optional Properties:
- compatible: Compatible list, may contain
"ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
specifications. If neither of these are specified, the default is to
assume clause 22. The compatible list may also contain other
elements.
Example:
ethernet-phy@0 {
linux,phandle = <2452000>
compatible = "ethernet-phy-ieee802.3-c22";
linux,phandle = <2452000>;
interrupt-parent = <40000>;
interrupts = <35 1>;
reg = <0>;

3
Documentation/devicetree/bindings/net/stmmac.txt
View file

@ -1,7 +1,8 @@
* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
Required properties:
- compatible: Should be "st,spear600-gmac"
- compatible: Should be "snps,dwmac-<ip_version>" "snps,dwmac"
For backwards compatibility: "st,spear600-gmac" is also supported.
- reg: Address and length of the register set for the device
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device

0
Documentation/devicetree/bindings/nvec/nvec_nvidia.txt → Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
View file

2
Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
View file

@ -1626,3 +1626,5 @@ MX6Q_PAD_SD2_DAT3__PCIE_CTRL_MUX_11 1587
MX6Q_PAD_SD2_DAT3__GPIO_1_12 1588
MX6Q_PAD_SD2_DAT3__SJC_DONE 1589
MX6Q_PAD_SD2_DAT3__ANATOP_TESTO_3 1590
MX6Q_PAD_ENET_RX_ER__ANATOP_USBOTG_ID 1591
MX6Q_PAD_GPIO_1__ANATOP_USBOTG_ID 1592

2
Documentation/devicetree/bindings/regulator/fixed-regulator.txt
View file

@ -10,6 +10,7 @@ Optional properties:
If this property is missing, the default assumed is Active low.
- gpio-open-drain: GPIO is open drain type.
If this property is missing then default assumption is false.
-vin-supply: Input supply name.
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
@ -29,4 +30,5 @@ Example:
enable-active-high;
regulator-boot-on;
gpio-open-drain;
vin-supply = <&parent_reg>;
};

5
Documentation/devicetree/bindings/regulator/regulator.txt
View file

@ -10,6 +10,11 @@ Optional properties:
- regulator-always-on: boolean, regulator should never be disabled
- regulator-boot-on: bootloader/firmware enabled regulator
- <name>-supply: phandle to the parent supply/regulator node
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
- regulator-compatible: If a regulator chip contains multiple
regulators, and if the chip's binding contains a child node that
describes each regulator, then this property indicates which regulator
this child node is intended to configure.
Example:

91
Documentation/devicetree/bindings/regulator/tps65217.txt Normal file
View file

@ -0,0 +1,91 @@
TPS65217 family of regulators
Required properties:
- compatible: "ti,tps65217"
- reg: I2C slave address
- regulators: list of regulators provided by this controller, must be named
after their hardware counterparts: dcdc[1-3] and ldo[1-4]
- regulators: This is the list of child nodes that specify the regulator
initialization data for defined regulators. Not all regulators for the given
device need to be present. The definition for each of these nodes is defined
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
Each regulator is defined using the standard binding for regulators.
Example:
tps: tps@24 {
compatible = "ti,tps65217";
regulators {
#address-cells = <1>;
#size-cells = <0>;
dcdc1_reg: regulator@0 {
reg = <0>;
regulator-compatible = "dcdc1";
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1800000>;
regulator-boot-on;
regulator-always-on;
};
dcdc2_reg: regulator@1 {
reg = <1>;
regulator-compatible = "dcdc2";
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
dcdc3_reg: regulator@2 {
reg = <2>;
regulator-compatible = "dcdc3";
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
regulator-always-on;
};
ldo1_reg: regulator@3 {
reg = <3>;
regulator-compatible = "ldo1";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
ldo2_reg: regulator@4 {
reg = <4>;
regulator-compatible = "ldo2";
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
ldo3_reg: regulator@5 {
reg = <5>;
regulator-compatible = "ldo3";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
ldo4_reg: regulator@6 {
reg = <6>;
regulator-compatible = "ldo4";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
};
};

77
Documentation/devicetree/bindings/regulator/tps6586x.txt
View file

@ -6,8 +6,17 @@ Required properties:
- interrupts: the interrupt outputs of the controller
- #gpio-cells: number of cells to describe a GPIO
- gpio-controller: mark the device as a GPIO controller
- regulators: list of regulators provided by this controller, must be named
after their hardware counterparts: sm[0-2], ldo[0-9] and ldo_rtc
- regulators: list of regulators provided by this controller, must have
property "regulator-compatible" to match their hardware counterparts:
sm[0-2], ldo[0-9] and ldo_rtc
- sm0-supply: The input supply for the SM0.
- sm1-supply: The input supply for the SM1.
- sm2-supply: The input supply for the SM2.
- vinldo01-supply: The input supply for the LDO1 and LDO2
- vinldo23-supply: The input supply for the LDO2 and LDO3
- vinldo4-supply: The input supply for the LDO4
- vinldo678-supply: The input supply for the LDO6, LDO7 and LDO8
- vinldo9-supply: The input supply for the LDO9
Each regulator is defined using the standard binding for regulators.
@ -21,75 +30,113 @@ Example:
#gpio-cells = <2>;
gpio-controller;
sm0-supply = <&some_reg>;
sm1-supply = <&some_reg>;
sm2-supply = <&some_reg>;
vinldo01-supply = <...>;
vinldo23-supply = <...>;
vinldo4-supply = <...>;
vinldo678-supply = <...>;
vinldo9-supply = <...>;
regulators {
sm0_reg: sm0 {
#address-cells = <1>;
#size-cells = <0>;
sm0_reg: regulator@0 {
reg = <0>;
regulator-compatible = "sm0";
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
regulator-always-on;
};
sm1_reg: sm1 {
sm1_reg: regulator@1 {
reg = <1>;
regulator-compatible = "sm1";
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
regulator-always-on;
};
sm2_reg: sm2 {
sm2_reg: regulator@2 {
reg = <2>;
regulator-compatible = "sm2";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <4550000>;
regulator-boot-on;
regulator-always-on;
};
ldo0_reg: ldo0 {
ldo0_reg: regulator@3 {
reg = <3>;
regulator-compatible = "ldo0";
regulator-name = "PCIE CLK";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
ldo1_reg: ldo1 {
ldo1_reg: regulator@4 {
reg = <4>;
regulator-compatible = "ldo1";
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
};
ldo2_reg: ldo2 {
ldo2_reg: regulator@5 {
reg = <5>;
regulator-compatible = "ldo2";
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
};
ldo3_reg: ldo3 {
ldo3_reg: regulator@6 {
reg = <6>;
regulator-compatible = "ldo3";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo4_reg: ldo4 {
ldo4_reg: regulator@7 {
reg = <7>;
regulator-compatible = "ldo4";
regulator-min-microvolt = <1700000>;
regulator-max-microvolt = <2475000>;
};
ldo5_reg: ldo5 {
ldo5_reg: regulator@8 {
reg = <8>;
regulator-compatible = "ldo5";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo6_reg: ldo6 {
ldo6_reg: regulator@9 {
reg = <9>;
regulator-compatible = "ldo6";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo7_reg: ldo7 {
ldo7_reg: regulator@10 {
reg = <10>;
regulator-compatible = "ldo7";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo8_reg: ldo8 {
ldo8_reg: regulator@11 {
reg = <11>;
regulator-compatible = "ldo8";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo9_reg: ldo9 {
ldo9_reg: regulator@12 {
reg = <12>;
regulator-compatible = "ldo9";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};

1
Documentation/devicetree/bindings/regulator/twl-regulator.txt
View file

@ -15,7 +15,6 @@ For twl6030 regulators/LDOs
- "ti,twl6030-vusb" for VUSB LDO
- "ti,twl6030-v1v8" for V1V8 LDO
- "ti,twl6030-v2v1" for V2V1 LDO
- "ti,twl6030-clk32kg" for CLK32KG RESOURCE
- "ti,twl6030-vdd1" for VDD1 SMPS
- "ti,twl6030-vdd2" for VDD2 SMPS
- "ti,twl6030-vdd3" for VDD3 SMPS

25
Documentation/devicetree/bindings/rtc/dw-apb.txt Normal file
View file

@ -0,0 +1,25 @@
* Designware APB timer
Required properties:
- compatible: "snps,dw-apb-timer-sp" or "snps,dw-apb-timer-osc"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: IRQ line for the timer.
- clock-frequency: The frequency in HZ of the timer.
- clock-freq: For backwards compatibility with picoxcell
Example:
timer1: timer@ffc09000 {
compatible = "snps,dw-apb-timer-sp";
interrupts = <0 168 4>;
clock-frequency = <200000000>;
reg = <0xffc09000 0x1000>;
};
timer2: timer@ffd00000 {
compatible = "snps,dw-apb-timer-osc";
interrupts = <0 169 4>;
clock-frequency = <200000000>;
reg = <0xffd00000 0x1000>;
};

16
Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt Normal file
View file

@ -0,0 +1,16 @@
* STMP3xxx/i.MX28 Time Clock controller
Required properties:
- compatible: should be one of the following.
* "fsl,stmp3xxx-rtc"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: rtc alarm interrupt
Example:
rtc@80056000 {
compatible = "fsl,imx28-rtc", "fsl,stmp3xxx-rtc";
reg = <0x80056000 2000>;
interrupts = <29>;
};

0
Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt → Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
View file

0
Documentation/devicetree/bindings/sound/tegra-audio-trimslice.txt → Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
View file

0
Documentation/devicetree/bindings/sound/tegra-audio-wm8753.txt → Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
View file

0
Documentation/devicetree/bindings/sound/tegra-audio-wm8903.txt → Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
View file

0
Documentation/devicetree/bindings/sound/tegra20-das.txt → Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt
View file

0
Documentation/devicetree/bindings/sound/tegra20-i2s.txt → Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
View file

4
Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
View file

@ -17,6 +17,6 @@ ecspi@70010000 {
reg = <0x70010000 0x4000>;
interrupts = <36>;
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
<&gpio3 25 0>; /* GPIO4_25 */
cs-gpios = <&gpio3 24 0>, /* GPIO3_24 */
<&gpio3 25 0>; /* GPIO3_25 */
};

0
Documentation/devicetree/bindings/spi/spi_nvidia.txt → Documentation/devicetree/bindings/spi/nvidia,tegra20-spi.txt
View file

116
Documentation/devicetree/bindings/spi/spi-samsung.txt Normal file
View file

@ -0,0 +1,116 @@
* Samsung SPI Controller
The Samsung SPI controller is used to interface with various devices such as flash
and display controllers using the SPI communication interface.
Required SoC Specific Properties:
- compatible: should be one of the following.
- samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms
- samsung,s3c6410-spi: for s3c6410 platforms
- samsung,s5p6440-spi: for s5p6440 and s5p6450 platforms
- samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms
- samsung,exynos4210-spi: for exynos4 and exynos5 platforms
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu. The interrupt specifier format
depends on the interrupt controller.
[PRELIMINARY: the dma channel allocation will change once there are
official DMA bindings]
- tx-dma-channel: The dma channel specifier for tx operations. The format of
the dma specifier depends on the dma controller.
- rx-dma-channel: The dma channel specifier for rx operations. The format of
the dma specifier depends on the dma controller.
Required Board Specific Properties:
- #address-cells: should be 1.
- #size-cells: should be 0.
- gpios: The gpio specifier for clock, mosi and miso interface lines (in the
order specified). The format of the gpio specifier depends on the gpio
controller.
Optional Board Specific Properties:
- samsung,spi-src-clk: If the spi controller includes a internal clock mux to
select the clock source for the spi bus clock, this property can be used to
indicate the clock to be used for driving the spi bus clock. If not specified,
the clock number 0 is used as default.
- num-cs: Specifies the number of chip select lines supported. If
not specified, the default number of chip select lines is set to 1.
SPI Controller specific data in SPI slave nodes:
- The spi slave nodes should provide the following information which is required
by the spi controller.
- cs-gpio: A gpio specifier that specifies the gpio line used as
the slave select line by the spi controller. The format of the gpio
specifier depends on the gpio controller.
- samsung,spi-feedback-delay: The sampling phase shift to be applied on the
miso line (to account for any lag in the miso line). The following are the
valid values.
- 0: No phase shift.
- 1: 90 degree phase shift sampling.
- 2: 180 degree phase shift sampling.
- 3: 270 degree phase shift sampling.
Aliases:
- All the SPI controller nodes should be represented in the aliases node using
the following format 'spi{n}' where n is a unique number for the alias.
Example:
- SoC Specific Portion:
spi_0: spi@12d20000 {
compatible = "samsung,exynos4210-spi";
reg = <0x12d20000 0x100>;
interrupts = <0 66 0>;
tx-dma-channel = <&pdma0 5>;
rx-dma-channel = <&pdma0 4>;
};
- Board Specific Portion:
spi_0: spi@12d20000 {
#address-cells = <1>;
#size-cells = <0>;
gpios = <&gpa2 4 2 3 0>,
<&gpa2 6 2 3 0>,
<&gpa2 7 2 3 0>;
w25q80bw@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "w25x80";
reg = <0>;
spi-max-frequency = <10000>;
controller-data {
cs-gpio = <&gpa2 5 1 0 3>;
samsung,spi-feedback-delay = <0>;
};
partition@0 {
label = "U-Boot";
reg = <0x0 0x40000>;
read-only;
};
partition@40000 {
label = "Kernel";
reg = <0x40000 0xc0000>;
};
};
};

27
Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt Normal file
View file

@ -0,0 +1,27 @@
* Freescale MXS Application UART (AUART)
Required properties:
- compatible : Should be "fsl,<soc>-auart". The supported SoCs include
imx23 and imx28.
- reg : Address and length of the register set for the device
- interrupts : Should contain the auart interrupt numbers
Example:
auart0: serial@8006a000 {
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112 70 71>;
};
Note: Each auart port should have an alias correctly numbered in "aliases"
node.
Example:
aliases {
serial0 = &auart0;
serial1 = &auart1;
serial2 = &auart2;
serial3 = &auart3;
serial4 = &auart4;
};

0
Documentation/devicetree/bindings/usb/tegra-usb.txt → Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
View file

1
Documentation/devicetree/bindings/vendor-prefixes.txt
View file

@ -3,6 +3,7 @@ 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.
ad Avionic Design GmbH
adi Analog Devices, Inc.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)

14
Documentation/devicetree/bindings/watchdog/omap-wdt.txt Normal file
View file

@ -0,0 +1,14 @@
TI Watchdog Timer (WDT) Controller for OMAP
Required properties:
compatible:
- "ti,omap3-wdt" for OMAP3
- "ti,omap4-wdt" for OMAP4
- ti,hwmods: Name of the hwmod associated to the WDT
Examples:
wdt2: wdt@4a314000 {
compatible = "ti,omap4-wdt", "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
};

44
Documentation/feature-removal-schedule.txt
View file

@ -249,15 +249,6 @@ Who: Ravikiran Thirumalai <kiran@scalex86.org>
---------------------------
What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS
(in net/core/net-sysfs.c)
When: 3.5
Why: Over 1K .text/.data size reduction, data is available in other
ways (ioctls)
Who: Johannes Berg <johannes@sipsolutions.net>
---------------------------
What: sysfs ui for changing p4-clockmod parameters
When: September 2009
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
@ -414,21 +405,6 @@ Who: Jean Delvare <khali@linux-fr.org>
----------------------------
What: xt_connlimit rev 0
When: 2012
Who: Jan Engelhardt <jengelh@medozas.de>
Files: net/netfilter/xt_connlimit.c
----------------------------
What: ipt_addrtype match include file
When: 2012
Why: superseded by xt_addrtype
Who: Florian Westphal <fw@strlen.de>
Files: include/linux/netfilter_ipv4/ipt_addrtype.h
----------------------------
What: i2c_driver.attach_adapter
i2c_driver.detach_adapter
When: September 2011
@ -449,6 +425,19 @@ Who: Hans Verkuil <hans.verkuil@cisco.com>
----------------------------
What: CONFIG_CFG80211_WEXT
When: as soon as distributions ship new wireless tools, ie. wpa_supplicant 1.0
and NetworkManager/connman/etc. that are able to use nl80211
Why: Wireless extensions are deprecated, and userland tools are moving to
using nl80211. New drivers are no longer using wireless extensions,
and while there might still be old drivers, both new drivers and new
userland no longer needs them and they can't be used for an feature
developed in the past couple of years. As such, compatibility with
wireless extensions in new drivers will be removed.
Who: Johannes Berg <johannes@sipsolutions.net>
----------------------------
What: g_file_storage driver
When: 3.8
Why: This driver has been superseded by g_mass_storage.
@ -589,6 +578,13 @@ Why: Remount currently allows changing bound subsystems and
----------------------------
What: xt_recent rev 0
When: 2013
Who: Pablo Neira Ayuso <pablo@netfilter.org>
Files: net/netfilter/xt_recent.c
----------------------------
What: KVM debugfs statistics
When: 2013
Why: KVM tracepoints provide mostly equivalent information in a much more

11
Documentation/filesystems/Locking
View file

@ -9,7 +9,7 @@ be able to use diff(1).
--------------------------- dentry_operations --------------------------
prototypes:
int (*d_revalidate)(struct dentry *, struct nameidata *);
int (*d_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, const struct inode *,
struct qstr *);
int (*d_compare)(const struct dentry *, const struct inode *,
@ -37,9 +37,8 @@ d_manage: no no yes (ref-walk) maybe
--------------------------- inode_operations ---------------------------
prototypes:
int (*create) (struct inode *,struct dentry *,umode_t, struct nameidata *);
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameid
ata *);
int (*create) (struct inode *,struct dentry *,umode_t, bool);
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
int (*symlink) (struct inode *,struct dentry *,const char *);
@ -62,6 +61,9 @@ ata *);
int (*removexattr) (struct dentry *, const char *);
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *,
struct file *, unsigned open_flag,
umode_t create_mode, int *opened);
locking rules:
all may block
@ -89,6 +91,7 @@ listxattr: no
removexattr: yes
fiemap: no
update_time: no
atomic_open: yes
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
victim.

21
Documentation/filesystems/porting
View file

@ -355,12 +355,10 @@ protects *all* the dcache state of a given dentry.
via rcu-walk path walk (basically, if the file can have had a path name in the
vfs namespace).
i_dentry and i_rcu share storage in a union, and the vfs expects
i_dentry to be reinitialized before it is freed, so an:
INIT_LIST_HEAD(&inode->i_dentry);
must be done in the RCU callback.
Even though i_dentry and i_rcu share storage in a union, we will
initialize the former in inode_init_always(), so just leave it alone in
the callback. It used to be necessary to clean it there, but not anymore
(starting at 3.2).
--
[recommended]
@ -433,3 +431,14 @@ release it yourself.
d_alloc_root() is gone, along with a lot of bugs caused by code
misusing it. Replacement: d_make_root(inode). The difference is,
d_make_root() drops the reference to inode if dentry allocation fails.
--
[mandatory]
The witch is dead! Well, 2/3 of it, anyway. ->d_revalidate() and
->lookup() do *not* take struct nameidata anymore; just the flags.
--
[mandatory]
->create() doesn't take struct nameidata *; unlike the previous
two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that
local filesystems can ignore tha argument - they are guaranteed that the
object doesn't exist. It's remote/distributed ones that might care...

23
Documentation/filesystems/vfs.txt
View file

@ -341,8 +341,8 @@ This describes how the VFS can manipulate an inode in your
filesystem. As of kernel 2.6.22, the following members are defined:
struct inode_operations {
int (*create) (struct inode *,struct dentry *, umode_t, struct nameidata *);
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
int (*create) (struct inode *,struct dentry *, umode_t, bool);
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
int (*symlink) (struct inode *,struct dentry *,const char *);
@ -364,6 +364,9 @@ struct inode_operations {
ssize_t (*listxattr) (struct dentry *, char *, size_t);
int (*removexattr) (struct dentry *, const char *);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *,
struct file *, unsigned open_flag,
umode_t create_mode, int *opened);
};
Again, all methods are called without any locks being held, unless
@ -476,6 +479,14 @@ otherwise noted.
an inode. If this is not defined the VFS will update the inode itself
and call mark_inode_dirty_sync.
atomic_open: called on the last component of an open. Using this optional
method the filesystem can look up, possibly create and open the file in
one atomic operation. If it cannot perform this (e.g. the file type
turned out to be wrong) it may signal this by returning 1 instead of
usual 0 or -ve . This method is only called if the last
component is negative or needs lookup. Cached positive dentries are
still handled by f_op->open().
The Address Space Object
========================
@ -891,7 +902,7 @@ the VFS uses a default. As of kernel 2.6.22, the following members are
defined:
struct dentry_operations {
int (*d_revalidate)(struct dentry *, struct nameidata *);
int (*d_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, const struct inode *,
struct qstr *);
int (*d_compare)(const struct dentry *, const struct inode *,
@ -910,11 +921,11 @@ struct dentry_operations {
dcache. Most filesystems leave this as NULL, because all their
dentries in the dcache are valid
d_revalidate may be called in rcu-walk mode (nd->flags & LOOKUP_RCU).
d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU).
If in rcu-walk mode, the filesystem must revalidate the dentry without
blocking or storing to the dentry, d_parent and d_inode should not be
used without care (because they can go NULL), instead nd->inode should
be used.
used without care (because they can change and, in d_inode case, even
become NULL under us).
If a situation is encountered that rcu-walk cannot handle, return
-ECHILD and it will be called again in ref-walk mode.

22
Documentation/hwmon/coretemp
View file

@ -6,7 +6,9 @@ Supported chips:
Prefix: 'coretemp'
CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom),
0x36 (Cedar Trail Atom)
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide
http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
@ -52,6 +54,17 @@ Some information comes from ark.intel.com
Process Processor TjMax(C)
22nm Core i5/i7 Processors
i7 3920XM, 3820QM, 3720QM, 3667U, 3520M 105
i5 3427U, 3360M/3320M 105
i7 3770/3770K 105
i5 3570/3570K, 3550, 3470/3450 105
i7 3770S 103
i5 3570S/3550S, 3475S/3470S/3450S 103
i7 3770T 94
i5 3570T 94
i5 3470T 91
32nm Core i3/i5/i7 Processors
i7 660UM/640/620, 640LM/620, 620M, 610E 105
i5 540UM/520/430, 540M/520/450/430 105
@ -65,6 +78,11 @@ Process Processor TjMax(C)
U3400 105
P4505/P4500 90
32nm Atom Processors
Z2460 90
D2700/2550/2500 100
N2850/2800/2650/2600 100
45nm Xeon Processors 5400 Quad-Core
X5492, X5482, X5472, X5470, X5460, X5450 85
E5472, E5462, E5450/40/30/20/10/05 85
@ -85,6 +103,8 @@ Process Processor TjMax(C)
N475/470/455/450 100
N280/270 90
330/230 125
E680/660/640/620 90
E680T/660T/640T/620T 110
45nm Core2 Processors
Solo ULV SU3500/3300 100

2
Documentation/kdump/kdump.txt
View file

@ -86,7 +86,7 @@ There is also a gitweb interface available at
http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git
More information about kexec-tools can be found at
http://www.kernel.org/pub/linux/utils/kernel/kexec/README.html
http://horms.net/projects/kexec/
3) Unpack the tarball with the tar command, as follows:

14
Documentation/kernel-parameters.txt
View file

@ -2367,6 +2367,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Set maximum number of finished RCU callbacks to process
in one batch.
rcutree.fanout_leaf= [KNL,BOOT]
Increase the number of CPUs assigned to each
leaf rcu_node structure. Useful for very large
systems.
rcutree.qhimark= [KNL,BOOT]
Set threshold of queued
RCU callbacks over which batch limiting is disabled.
@ -2543,6 +2548,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
sched_debug [KNL] Enables verbose scheduler debug messages.
skew_tick= [KNL] Offset the periodic timer tick per cpu to mitigate
xtime_lock contention on larger systems, and/or RCU lock
contention on all systems with CONFIG_MAXSMP set.
Format: { "0" | "1" }
0 -- disable. (may be 1 via CONFIG_CMDLINE="skew_tick=1"
1 -- enable.
Note: increases power consumption, thus should only be
enabled if running jitter sensitive (HPC/RT) workloads.
security= [SECURITY] Choose a security module to enable at boot.
If this boot parameter is not specified, only the first
security module asking for security registration will be

5
Documentation/networking/batman-adv.txt
View file

@ -211,6 +211,11 @@ The debug output can be changed at runtime using the file
will enable debug messages for when routes change.
Counters for different types of packets entering and leaving the
batman-adv module are available through ethtool:
# ethtool --statistics bat0
BATCTL
------

6
Documentation/networking/bonding.txt
View file

@ -1210,7 +1210,7 @@ options, you may wish to use the "max_bonds" module parameter,
documented above.
To create multiple bonding devices with differing options, it is
preferrable to use bonding parameters exported by sysfs, documented in the
preferable to use bonding parameters exported by sysfs, documented in the
section below.
For versions of bonding without sysfs support, the only means to
@ -1950,7 +1950,7 @@ access to fail over to. Additionally, the bonding load balance modes
support link monitoring of their members, so if individual links fail,
the load will be rebalanced across the remaining devices.
See Section 13, "Configuring Bonding for Maximum Throughput"
See Section 12, "Configuring Bonding for Maximum Throughput"
for information on configuring bonding with one peer device.
11.2 High Availability in a Multiple Switch Topology
@ -2620,7 +2620,7 @@ be found at:
https://lists.sourceforge.net/lists/listinfo/bonding-devel
Discussions regarding the developpement of the bonding driver take place
Discussions regarding the development of the bonding driver take place
on the main Linux network mailing list, hosted at vger.kernel.org. The list
address is:

13
Documentation/networking/bridge.txt
View file

@ -1,7 +1,14 @@
In order to use the Ethernet bridging functionality, you'll need the
userspace tools. These programs and documentation are available
at http://www.linuxfoundation.org/en/Net:Bridge. The download page is
http://prdownloads.sourceforge.net/bridge.
userspace tools.
Documentation for Linux bridging is on:
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
The bridge-utilities are maintained at:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
Additionally, the iproute2 utilities can be used to configure
bridge devices.
If you still have questions, don't hesitate to post to the mailing list
(more info https://lists.linux-foundation.org/mailman/listinfo/bridge).

89
Documentation/networking/caif/Linux-CAIF.txt
View file

@ -19,60 +19,36 @@ and host. Currently, UART and Loopback are available for Linux.
Architecture:
------------
The implementation of CAIF is divided into:
* CAIF Socket Layer, Kernel API, and Net Device.
* CAIF Socket Layer and GPRS IP Interface.
* CAIF Core Protocol Implementation
* CAIF Link Layer, implemented as NET devices.
RTNL
!
! +------+ +------+ +------+
! +------+! +------+! +------+!
! ! Sock !! !Kernel!! ! Net !!
! ! API !+ ! API !+ ! Dev !+ <- CAIF Client APIs
! +------+ +------! +------+
! ! ! !
! +----------!----------+
! +------+ <- CAIF Protocol Implementation
+-------> ! CAIF !
! Core !
+------+
+--------!--------+
! !
+------+ +-----+
! ! ! TTY ! <- Link Layer (Net Devices)
+------+ +-----+
! +------+ +------+
! +------+! +------+!
! ! IP !! !Socket!!
+-------> !interf!+ ! API !+ <- CAIF Client APIs
! +------+ +------!
! ! !
! +-----------+
! !
! +------+ <- CAIF Core Protocol
! ! CAIF !
! ! Core !
! +------+
! +----------!---------+
! ! ! !
! +------+ +-----+ +------+
+--> ! HSI ! ! TTY ! ! USB ! <- Link Layer (Net Devices)
+------+ +-----+ +------+
Using the Kernel API
----------------------
The Kernel API is used for accessing CAIF channels from the
kernel.
The user of the API has to implement two callbacks for receive
and control.
The receive callback gives a CAIF packet as a SKB. The control
callback will
notify of channel initialization complete, and flow-on/flow-
off.
struct caif_device caif_dev = {
.caif_config = {
.name = "MYDEV"
.type = CAIF_CHTY_AT
}
.receive_cb = my_receive,
.control_cb = my_control,
};
caif_add_device(&caif_dev);
caif_transmit(&caif_dev, skb);
See the caif_kernel.h for details about the CAIF kernel API.
I M P L E M E N T A T I O N
===========================
===========================
CAIF Core Protocol Layer
=========================================
@ -88,17 +64,13 @@ The Core CAIF implementation contains:
- Simple implementation of CAIF.
- Layered architecture (a la Streams), each layer in the CAIF
specification is implemented in a separate c-file.
- Clients must implement PHY layer to access physical HW
with receive and transmit functions.
- Clients must call configuration function to add PHY layer.
- Clients must implement CAIF layer to consume/produce
CAIF payload with receive and transmit functions.
- Clients must call configuration function to add and connect the
Client layer.
- When receiving / transmitting CAIF Packets (cfpkt), ownership is passed
to the called function (except for framing layers' receive functions
or if a transmit function returns an error, in which case the caller
must free the packet).
to the called function (except for framing layers' receive function)
Layered Architecture
--------------------
@ -109,11 +81,6 @@ Implementation. The support functions include:
CAIF Packet has functions for creating, destroying and adding content
and for adding/extracting header and trailers to protocol packets.
- CFLST CAIF list implementation.
- CFGLUE CAIF Glue. Contains OS Specifics, such as memory
allocation, endianness, etc.
The CAIF Protocol implementation contains:
- CFCNFG CAIF Configuration layer. Configures the CAIF Protocol
@ -128,7 +95,7 @@ The CAIF Protocol implementation contains:
control and remote shutdown requests.
- CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual
External Interface). This layer encodes/decodes VEI frames.
External Interface). This layer encodes/decodes VEI frames.
- CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP
traffic), encodes/decodes Datagram frames.
@ -170,7 +137,7 @@ The CAIF Protocol implementation contains:
+---------+ +---------+
! !
+---------+ +---------+
| | | Serial |
| | | Serial |
| | | CFSERL |
+---------+ +---------+
@ -186,24 +153,20 @@ In this layered approach the following "rules" apply.
layer->dn->transmit(layer->dn, packet);
Linux Driver Implementation
CAIF Socket and IP interface
===========================
Linux GPRS Net Device and CAIF socket are implemented on top of the
CAIF Core protocol. The Net device and CAIF socket have an instance of
The IP interface and CAIF socket API are implemented on top of the
CAIF Core protocol. The IP Interface and CAIF socket have an instance of
'struct cflayer', just like the CAIF Core protocol stack.
Net device and Socket implement the 'receive()' function defined by
'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and
receive of packets is handled as by the rest of the layers: the 'dn->transmit()'
function is called in order to transmit data.
The layer on top of the CAIF Core implementation is
sometimes referred to as the "Client layer".
Configuration of Link Layer
---------------------------
The Link Layer is implemented as Linux net devices (struct net_device).
The Link Layer is implemented as Linux network devices (struct net_device).
Payload handling and registration is done using standard Linux mechanisms.
The CAIF Protocol relies on a loss-less link layer without implementing

186
Documentation/networking/can.txt
View file

@ -22,7 +22,8 @@ This file contains
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
4.1.3 RAW socket option CAN_RAW_LOOPBACK
4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
4.1.5 RAW socket returned message flags
4.1.5 RAW socket option CAN_RAW_FD_FRAMES
4.1.6 RAW socket returned message flags
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM)
@ -41,7 +42,8 @@ This file contains
6.5.1 Netlink interface to set/get devices properties
6.5.2 Setting the CAN bit-timing
6.5.3 Starting and stopping the CAN network device
6.6 supported CAN hardware
6.6 CAN FD (flexible data rate) driver support
6.7 supported CAN hardware
7 Socket CAN resources
@ -232,16 +234,16 @@ solution for a couple of reasons:
arbitration problems and error frames caused by the different
ECUs. The occurrence of detected errors are important for diagnosis
and have to be logged together with the exact timestamp. For this
reason the CAN interface driver can generate so called Error Frames
that can optionally be passed to the user application in the same
way as other CAN frames. Whenever an error on the physical layer
reason the CAN interface driver can generate so called Error Message
Frames that can optionally be passed to the user application in the
same way as other CAN frames. Whenever an error on the physical layer
or the MAC layer is detected (e.g. by the CAN controller) the driver
creates an appropriate error frame. Error frames can be requested by
the user application using the common CAN filter mechanisms. Inside
this filter definition the (interested) type of errors may be
selected. The reception of error frames is disabled by default.
The format of the CAN error frame is briefly described in the Linux
header file "include/linux/can/error.h".
creates an appropriate error message frame. Error messages frames can
be requested by the user application using the common CAN filter
mechanisms. Inside this filter definition the (interested) type of
errors may be selected. The reception of error messages is disabled
by default. The format of the CAN error message frame is briefly
described in the Linux header file "include/linux/can/error.h".
4. How to use Socket CAN
------------------------
@ -273,7 +275,7 @@ solution for a couple of reasons:
struct can_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 can_dlc; /* data length code: 0 .. 8 */
__u8 can_dlc; /* frame payload length in byte (0 .. 8) */
__u8 data[8] __attribute__((aligned(8)));
};
@ -375,6 +377,51 @@ solution for a couple of reasons:
nbytes = sendto(s, &frame, sizeof(struct can_frame),
0, (struct sockaddr*)&addr, sizeof(addr));
Remark about CAN FD (flexible data rate) support:
Generally the handling of CAN FD is very similar to the formerly described
examples. The new CAN FD capable CAN controllers support two different
bitrates for the arbitration phase and the payload phase of the CAN FD frame
and up to 64 bytes of payload. This extended payload length breaks all the
kernel interfaces (ABI) which heavily rely on the CAN frame with fixed eight
bytes of payload (struct can_frame) like the CAN_RAW socket. Therefore e.g.
the CAN_RAW socket supports a new socket option CAN_RAW_FD_FRAMES that
switches the socket into a mode that allows the handling of CAN FD frames
and (legacy) CAN frames simultaneously (see section 4.1.5).
The struct canfd_frame is defined in include/linux/can.h:
struct canfd_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 len; /* frame payload length in byte (0 .. 64) */
__u8 flags; /* additional flags for CAN FD */
__u8 __res0; /* reserved / padding */
__u8 __res1; /* reserved / padding */
__u8 data[64] __attribute__((aligned(8)));
};
The struct canfd_frame and the existing struct can_frame have the can_id,
the payload length and the payload data at the same offset inside their
structures. This allows to handle the different structures very similar.
When the content of a struct can_frame is copied into a struct canfd_frame
all structure elements can be used as-is - only the data[] becomes extended.
When introducing the struct canfd_frame it turned out that the data length
code (DLC) of the struct can_frame was used as a length information as the
length and the DLC has a 1:1 mapping in the range of 0 .. 8. To preserve
the easy handling of the length information the canfd_frame.len element
contains a plain length value from 0 .. 64. So both canfd_frame.len and
can_frame.can_dlc are equal and contain a length information and no DLC.
For details about the distinction of CAN and CAN FD capable devices and
the mapping to the bus-relevant data length code (DLC), see chapter 6.6.
The length of the two CAN(FD) frame structures define the maximum transfer
unit (MTU) of the CAN(FD) network interface and skbuff data length. Two
definitions are specified for CAN specific MTUs in include/linux/can.h :
#define CAN_MTU (sizeof(struct can_frame)) == 16 => 'legacy' CAN frame
#define CANFD_MTU (sizeof(struct canfd_frame)) == 72 => CAN FD frame
4.1 RAW protocol sockets with can_filters (SOCK_RAW)
Using CAN_RAW sockets is extensively comparable to the commonly
@ -383,7 +430,7 @@ solution for a couple of reasons:
defaults are set at RAW socket binding time:
- The filters are set to exactly one filter receiving everything
- The socket only receives valid data frames (=> no error frames)
- The socket only receives valid data frames (=> no error message frames)
- The loopback of sent CAN frames is enabled (see chapter 3.2)
- The socket does not receive its own sent frames (in loopback mode)
@ -434,7 +481,7 @@ solution for a couple of reasons:
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
As described in chapter 3.4 the CAN interface driver can generate so
called Error Frames that can optionally be passed to the user
called Error Message Frames that can optionally be passed to the user
application in the same way as other CAN frames. The possible
errors are divided into different error classes that may be filtered
using the appropriate error mask. To register for every possible
@ -472,7 +519,69 @@ solution for a couple of reasons:
setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
&recv_own_msgs, sizeof(recv_own_msgs));
4.1.5 RAW socket returned message flags
4.1.5 RAW socket option CAN_RAW_FD_FRAMES
CAN FD support in CAN_RAW sockets can be enabled with a new socket option
CAN_RAW_FD_FRAMES which is off by default. When the new socket option is
not supported by the CAN_RAW socket (e.g. on older kernels), switching the
CAN_RAW_FD_FRAMES option returns the error -ENOPROTOOPT.
Once CAN_RAW_FD_FRAMES is enabled the application can send both CAN frames
and CAN FD frames. OTOH the application has to handle CAN and CAN FD frames
when reading from the socket.
CAN_RAW_FD_FRAMES enabled: CAN_MTU and CANFD_MTU are allowed
CAN_RAW_FD_FRAMES disabled: only CAN_MTU is allowed (default)
Example:
[ remember: CANFD_MTU == sizeof(struct canfd_frame) ]
struct canfd_frame cfd;
nbytes = read(s, &cfd, CANFD_MTU);
if (nbytes == CANFD_MTU) {
printf("got CAN FD frame with length %d\n", cfd.len);
/* cfd.flags contains valid data */
} else if (nbytes == CAN_MTU) {
printf("got legacy CAN frame with length %d\n", cfd.len);
/* cfd.flags is undefined */
} else {
fprintf(stderr, "read: invalid CAN(FD) frame\n");
return 1;
}
/* the content can be handled independently from the received MTU size */
printf("can_id: %X data length: %d data: ", cfd.can_id, cfd.len);
for (i = 0; i < cfd.len; i++)
printf("%02X ", cfd.data[i]);
When reading with size CANFD_MTU only returns CAN_MTU bytes that have
been received from the socket a legacy CAN frame has been read into the
provided CAN FD structure. Note that the canfd_frame.flags data field is
not specified in the struct can_frame and therefore it is only valid in
CANFD_MTU sized CAN FD frames.
As long as the payload length is <=8 the received CAN frames from CAN FD
capable CAN devices can be received and read by legacy sockets too. When
user-generated CAN FD frames have a payload length <=8 these can be send
by legacy CAN network interfaces too. Sending CAN FD frames with payload
length > 8 to a legacy CAN network interface returns an -EMSGSIZE error.
Implementation hint for new CAN applications:
To build a CAN FD aware application use struct canfd_frame as basic CAN
data structure for CAN_RAW based applications. When the application is
executed on an older Linux kernel and switching the CAN_RAW_FD_FRAMES
socket option returns an error: No problem. You'll get legacy CAN frames
or CAN FD frames and can process them the same way.
When sending to CAN devices make sure that the device is capable to handle
CAN FD frames by checking if the device maximum transfer unit is CANFD_MTU.
The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
4.1.6 RAW socket returned message flags
When using recvmsg() call, the msg->msg_flags may contain following flags:
@ -527,7 +636,7 @@ solution for a couple of reasons:
rcvlist_all - list for unfiltered entries (no filter operations)
rcvlist_eff - list for single extended frame (EFF) entries
rcvlist_err - list for error frames masks
rcvlist_err - list for error message frames masks
rcvlist_fil - list for mask/value filters
rcvlist_inv - list for mask/value filters (inverse semantic)
rcvlist_sff - list for single standard frame (SFF) entries
@ -573,10 +682,13 @@ solution for a couple of reasons:
dev->type = ARPHRD_CAN; /* the netdevice hardware type */
dev->flags = IFF_NOARP; /* CAN has no arp */
dev->mtu = sizeof(struct can_frame);
dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */
The struct can_frame is the payload of each socket buffer in the
protocol family PF_CAN.
or alternative, when the controller supports CAN with flexible data rate:
dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */
The struct can_frame or struct canfd_frame is the payload of each socket
buffer (skbuff) in the protocol family PF_CAN.
6.2 local loopback of sent frames
@ -784,15 +896,41 @@ solution for a couple of reasons:
$ ip link set canX type can restart-ms 100
Alternatively, the application may realize the "bus-off" condition
by monitoring CAN error frames and do a restart when appropriate with
the command:
by monitoring CAN error message frames and do a restart when
appropriate with the command:
$ ip link set canX type can restart
Note that a restart will also create a CAN error frame (see also
chapter 3.4).
Note that a restart will also create a CAN error message frame (see
also chapter 3.4).
6.6 Supported CAN hardware
6.6 CAN FD (flexible data rate) driver support
CAN FD capable CAN controllers support two different bitrates for the
arbitration phase and the payload phase of the CAN FD frame. Therefore a
second bittiming has to be specified in order to enable the CAN FD bitrate.
Additionally CAN FD capable CAN controllers support up to 64 bytes of
payload. The representation of this length in can_frame.can_dlc and
canfd_frame.len for userspace applications and inside the Linux network
layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
The data length code was a 1:1 mapping to the payload length in the legacy
CAN frames anyway. The payload length to the bus-relevant DLC mapping is
only performed inside the CAN drivers, preferably with the helper
functions can_dlc2len() and can_len2dlc().
The CAN netdevice driver capabilities can be distinguished by the network
devices maximum transfer unit (MTU):
MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => 'legacy' CAN device
MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device
The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
N.B. CAN FD capable devices can also handle and send legacy CAN frames.
FIXME: Add details about the CAN FD controller configuration when available.
6.7 Supported CAN hardware
Please check the "Kconfig" file in "drivers/net/can" to get an actual
list of the support CAN hardware. On the Socket CAN project website

62
Documentation/networking/ip-sysctl.txt
View file

@ -468,6 +468,19 @@ tcp_syncookies - BOOLEAN
SYN flood warnings in logs not being really flooded, your server
is seriously misconfigured.
tcp_fastopen - INTEGER
Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data
in the opening SYN packet. To use this feature, the client application
must not use connect(). Instead, it should use sendmsg() or sendto()
with MSG_FASTOPEN flag which performs a TCP handshake automatically.
The values (bitmap) are:
1: Enables sending data in the opening SYN on the client
5: Enables sending data in the opening SYN on the client regardless
of cookie availability.
Default: 0
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
@ -551,6 +564,25 @@ tcp_thin_dupack - BOOLEAN
Documentation/networking/tcp-thin.txt
Default: 0
tcp_limit_output_bytes - INTEGER
Controls TCP Small Queue limit per tcp socket.
TCP bulk sender tends to increase packets in flight until it
gets losses notifications. With SNDBUF autotuning, this can
result in a large amount of packets queued in qdisc/device
on the local machine, hurting latency of other flows, for
typical pfifo_fast qdiscs.
tcp_limit_output_bytes limits the number of bytes on qdisc
or device to reduce artificial RTT/cwnd and reduce bufferbloat.
Note: For GSO/TSO enabled flows, we try to have at least two
packets in flight. Reducing tcp_limit_output_bytes might also
reduce the size of individual GSO packet (64KB being the max)
Default: 131072
tcp_challenge_ack_limit - INTEGER
Limits number of Challenge ACK sent per second, as recommended
in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks)
Default: 100
UDP variables:
udp_mem - vector of 3 INTEGERs: min, pressure, max
@ -857,9 +889,19 @@ accept_source_route - BOOLEAN
FALSE (host)
accept_local - BOOLEAN
Accept packets with local source addresses. In combination with
suitable routing, this can be used to direct packets between two
local interfaces over the wire and have them accepted properly.
Accept packets with local source addresses. In combination
with suitable routing, this can be used to direct packets
between two local interfaces over the wire and have them
accepted properly.
rp_filter must be set to a non-zero value in order for
accept_local to have an effect.
default FALSE
route_localnet - BOOLEAN
Do not consider loopback addresses as martian source or destination
while routing. This enables the use of 127/8 for local routing purposes.
default FALSE
rp_filter - INTEGER
@ -1398,6 +1440,20 @@ path_max_retrans - INTEGER
Default: 5
pf_retrans - INTEGER
The number of retransmissions that will be attempted on a given path
before traffic is redirected to an alternate transport (should one
exist). Note this is distinct from path_max_retrans, as a path that
passes the pf_retrans threshold can still be used. Its only
deprioritized when a transmission path is selected by the stack. This
setting is primarily used to enable fast failover mechanisms without
having to reduce path_max_retrans to a very low value. See:
http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-05.txt
for details. Note also that a value of pf_retrans > path_max_retrans
disables this feature
Default: 0
rto_initial - INTEGER
The initial round trip timeout value in milliseconds that will be used
in calculating round trip times. This is the initial time interval

2
Documentation/networking/openvswitch.txt
View file

@ -118,7 +118,7 @@ essentially like this, ignoring metadata:
Naively, to add VLAN support, it makes sense to add a new "vlan" flow
key attribute to contain the VLAN tag, then continue to decode the
encapsulated headers beyond the VLAN tag using the existing field
definitions. With this change, an TCP packet in VLAN 10 would have a
definitions. With this change, a TCP packet in VLAN 10 would have a
flow key much like this:
eth(...), vlan(vid=10, pcp=0), eth_type(0x0800), ip(proto=6, ...), tcp(...)

14
Documentation/networking/s2io.txt
View file

@ -136,16 +136,6 @@ For more information, please review the AMD8131 errata at
http://vip.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
26310_AMD-8131_HyperTransport_PCI-X_Tunnel_Revision_Guide_rev_3_18.pdf
6. Available Downloads
Neterion "s2io" driver in Red Hat and Suse 2.6-based distributions is kept up
to date, also the latest "s2io" code (including support for 2.4 kernels) is
available via "Support" link on the Neterion site: http://www.neterion.com.
For Xframe User Guide (Programming manual), visit ftp site ns1.s2io.com,
user: linuxdocs password: HALdocs
7. Support
6. Support
For further support please contact either your 10GbE Xframe NIC vendor (IBM,
HP, SGI etc.) or click on the "Support" link on the Neterion site:
http://www.neterion.com.
HP, SGI etc.)

80
Documentation/networking/stmmac.txt
View file

@ -10,8 +10,8 @@ Currently this network device driver is for all STM embedded MAC/GMAC
(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
FF1152AMT0221 D1215994A VIRTEX FPGA board.
DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether MAC 10/100
Universal version 4.0 have been used for developing this driver.
DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
MAC 10/100 Universal version 4.0 have been used for developing this driver.
This driver supports both the platform bus and PCI.
@ -54,27 +54,27 @@ net_device structure enabling the scatter/gather feature.
When one or more packets are received, an interrupt happens. The interrupts
are not queued so the driver has to scan all the descriptors in the ring during
the receive process.
This is based on NAPI so the interrupt handler signals only if there is work to be
done, and it exits.
This is based on NAPI so the interrupt handler signals only if there is work
to be done, and it exits.
Then the poll method will be scheduled at some future point.
The incoming packets are stored, by the DMA, in a list of pre-allocated socket
buffers in order to avoid the memcpy (Zero-copy).
4.3) Timer-Driver Interrupt
Instead of having the device that asynchronously notifies the frame receptions, the
driver configures a timer to generate an interrupt at regular intervals.
Based on the granularity of the timer, the frames that are received by the device
will experience different levels of latency. Some NICs have dedicated timer
device to perform this task. STMMAC can use either the RTC device or the TMU
channel 2 on STLinux platforms.
Instead of having the device that asynchronously notifies the frame receptions,
the driver configures a timer to generate an interrupt at regular intervals.
Based on the granularity of the timer, the frames that are received by the
device will experience different levels of latency. Some NICs have dedicated
timer device to perform this task. STMMAC can use either the RTC device or the
TMU channel 2 on STLinux platforms.
The timers frequency can be passed to the driver as parameter; when change it,
take care of both hardware capability and network stability/performance impact.
Several performance tests on STM platforms showed this optimisation allows to spare
the CPU while having the maximum throughput.
Several performance tests on STM platforms showed this optimisation allows to
spare the CPU while having the maximum throughput.
4.4) WOL
Wake up on Lan feature through Magic and Unicast frames are supported for the GMAC
core.
Wake up on Lan feature through Magic and Unicast frames are supported for the
GMAC core.
4.5) DMA descriptors
Driver handles both normal and enhanced descriptors. The latter has been only
@ -106,7 +106,8 @@ Several driver's information can be passed through the platform
These are included in the include/linux/stmmac.h header file
and detailed below as well:
struct plat_stmmacenet_data {
struct plat_stmmacenet_data {
char *phy_bus_name;
int bus_id;
int phy_addr;
int interface;
@ -124,19 +125,24 @@ and detailed below as well:
void (*bus_setup)(void __iomem *ioaddr);
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
void *custom_cfg;
void *custom_data;
void *bsp_priv;
};
Where:
o phy_bus_name: phy bus name to attach to the stmmac.
o bus_id: bus identifier.
o phy_addr: the physical address can be passed from the platform.
If it is set to -1 the driver will automatically
detect it at run-time by probing all the 32 addresses.
o interface: PHY device's interface.
o mdio_bus_data: specific platform fields for the MDIO bus.
o pbl: the Programmable Burst Length is maximum number of beats to
o dma_cfg: internal DMA parameters
o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
GMAC also enables the 4xPBL by default.
o fixed_burst/mixed_burst/burst_len
o clk_csr: fixed CSR Clock range selection.
o has_gmac: uses the GMAC core.
o enh_desc: if sets the MAC will use the enhanced descriptor structure.
@ -160,8 +166,9 @@ Where:
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
registers.
o custom_cfg: this is a custom configuration that can be passed while
initialising the resources.
o custom_cfg/custom_data: this is a custom configuration that can be passed
while initialising the resources.
o bsp_priv: another private poiter.
For MDIO bus The we have:
@ -180,7 +187,6 @@ Where:
o irqs: list of IRQs, one per PHY.
o probed_phy_irq: if irqs is NULL, use this for probed PHY.
For DMA engine we have the following internal fields that should be
tuned according to the HW capabilities.
@ -251,9 +257,11 @@ reset procedure etc).
o Makefile
o stmmac_main.c: main network device driver;
o stmmac_mdio.c: mdio functions;
o stmmac_pci: PCI driver;
o stmmac_platform.c: platform driver
o stmmac_ethtool.c: ethtool support;
o stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts
Only tested on ST40 platforms based.
(only tested on ST40 platforms based);
o stmmac.h: private driver structure;
o common.h: common definitions and VFTs;
o descs.h: descriptor structure definitions;
@ -263,9 +271,11 @@ reset procedure etc).
o dwmac100_core: MAC 100 core and dma code;
o dwmac100_dma.c: dma funtions for the MAC chip;
o dwmac1000.h: specific header file for the MAC;
o dwmac_lib.c: generic DMA functions shared among chips
o enh_desc.c: functions for handling enhanced descriptors
o norm_desc.c: functions for handling normal descriptors
o dwmac_lib.c: generic DMA functions shared among chips;
o enh_desc.c: functions for handling enhanced descriptors;
o norm_desc.c: functions for handling normal descriptors;
o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes;
o mmc_core.c/mmc.h: Management MAC Counters;
5) Debug Information
@ -298,7 +308,27 @@ All these are only useful during the developing stage
and should never enabled inside the code for general usage.
In fact, these can generate an huge amount of debug messages.
6) TODO:
6) Energy Efficient Ethernet
Energy Efficient Ethernet(EEE) enables IEEE 802.3 MAC sublayer along
with a family of Physical layer to operate in the Low power Idle(LPI)
mode. The EEE mode supports the IEEE 802.3 MAC operation at 100Mbps,
1000Mbps & 10Gbps.
The LPI mode allows power saving by switching off parts of the
communication device functionality when there is no data to be
transmitted & received. The system on both the side of the link can
disable some functionalities & save power during the period of low-link
utilization. The MAC controls whether the system should enter or exit
the LPI mode & communicate this to PHY.
As soon as the interface is opened, the driver verifies if the EEE can
be supported. This is done by looking at both the DMA HW capability
register and the PHY devices MCD registers.
To enter in Tx LPI mode the driver needs to have a software timer
that enable and disable the LPI mode when there is nothing to be
transmitted.
7) TODO:
o XGMAC is not supported.
o Add the EEE - Energy Efficient Ethernet
o Add the PTP - precision time protocol

7
Documentation/networking/vxge.txt
View file

@ -91,10 +91,3 @@ v) addr_learn_en
virtualization environment.
Valid range: 0,1 (disabled, enabled respectively)
Default: 0
4) Troubleshooting:
-------------------
To resolve an issue with the source code or X3100 series adapter, please collect
the statistics, register dumps using ethool, relevant logs and email them to
support@neterion.com.

33
Documentation/nfc/nfc-hci.txt
View file

@ -178,3 +178,36 @@ ANY_GET_PARAMETER to the reader A gate to get information on the target
that was discovered).
Typically, such an event will be propagated to NFC Core from MSGRXWQ context.
Error management
----------------
Errors that occur synchronously with the execution of an NFC Core request are
simply returned as the execution result of the request. These are easy.
Errors that occur asynchronously (e.g. in a background protocol handling thread)
must be reported such that upper layers don't stay ignorant that something
went wrong below and know that expected events will probably never happen.
Handling of these errors is done as follows:
- driver (pn544) fails to deliver an incoming frame: it stores the error such
that any subsequent call to the driver will result in this error. Then it calls
the standard nfc_shdlc_recv_frame() with a NULL argument to report the problem
above. shdlc stores a EREMOTEIO sticky status, which will trigger SMW to
report above in turn.
- SMW is basically a background thread to handle incoming and outgoing shdlc
frames. This thread will also check the shdlc sticky status and report to HCI
when it discovers it is not able to run anymore because of an unrecoverable
error that happened within shdlc or below. If the problem occurs during shdlc
connection, the error is reported through the connect completion.
- HCI: if an internal HCI error happens (frame is lost), or HCI is reported an
error from a lower layer, HCI will either complete the currently executing
command with that error, or notify NFC Core directly if no command is executing.
- NFC Core: when NFC Core is notified of an error from below and polling is
active, it will send a tag discovered event with an empty tag list to the user
space to let it know that the poll operation will never be able to detect a tag.
If polling is not active and the error was sticky, lower levels will return it
at next invocation.

9
Documentation/power/devices.txt
View file

@ -583,9 +583,10 @@ for the given device during all power transitions, instead of the respective
subsystem-level callbacks. Specifically, if a device's pm_domain pointer is
not NULL, the ->suspend() callback from the object pointed to by it will be
executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and
anlogously for all of the remaining callbacks. In other words, power management
domain callbacks, if defined for the given device, always take precedence over
the callbacks provided by the device's subsystem (e.g. bus type).
analogously for all of the remaining callbacks. In other words, power
management domain callbacks, if defined for the given device, always take
precedence over the callbacks provided by the device's subsystem (e.g. bus
type).
The support for device power management domains is only relevant to platforms
needing to use the same device driver power management callbacks in many
@ -598,7 +599,7 @@ it into account in any way.
Device Low Power (suspend) States
---------------------------------
Device low-power states aren't standard. One device might only handle
"on" and "off, while another might support a dozen different versions of
"on" and "off", while another might support a dozen different versions of
"on" (how many engines are active?), plus a state that gets back to "on"
faster than from a full "off".

5
Documentation/power/swsusp.txt
View file

@ -33,6 +33,11 @@ echo shutdown > /sys/power/disk; echo disk > /sys/power/state
echo platform > /sys/power/disk; echo disk > /sys/power/state
. If you would like to write hibernation image to swap and then suspend
to RAM (provided your platform supports it), you can try
echo suspend > /sys/power/disk; echo disk > /sys/power/state
. If you have SATA disks, you'll need recent kernels with SATA suspend
support. For suspend and resume to work, make sure your disk drivers
are built into kernel -- not modules. [There's way to make

57
Documentation/prctl/no_new_privs.txt Normal file
View file

@ -0,0 +1,57 @@
The execve system call can grant a newly-started program privileges that
its parent did not have. The most obvious examples are setuid/setgid
programs and file capabilities. To prevent the parent program from
gaining these privileges as well, the kernel and user code must be
careful to prevent the parent from doing anything that could subvert the
child. For example:
- The dynamic loader handles LD_* environment variables differently if
a program is setuid.
- chroot is disallowed to unprivileged processes, since it would allow
/etc/passwd to be replaced from the point of view of a process that
inherited chroot.
- The exec code has special handling for ptrace.
These are all ad-hoc fixes. The no_new_privs bit (since Linux 3.5) is a
new, generic mechanism to make it safe for a process to modify its
execution environment in a manner that persists across execve. Any task
can set no_new_privs. Once the bit is set, it is inherited across fork,
clone, and execve and cannot be unset. With no_new_privs set, execve
promises not to grant the privilege to do anything that could not have
been done without the execve call. For example, the setuid and setgid
bits will no longer change the uid or gid; file capabilities will not
add to the permitted set, and LSMs will not relax constraints after
execve.
To set no_new_privs, use prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0).
Be careful, though: LSMs might also not tighten constraints on exec
in no_new_privs mode. (This means that setting up a general-purpose
service launcher to set no_new_privs before execing daemons may
interfere with LSM-based sandboxing.)
Note that no_new_privs does not prevent privilege changes that do not
involve execve. An appropriately privileged task can still call
setuid(2) and receive SCM_RIGHTS datagrams.
There are two main use cases for no_new_privs so far:
- Filters installed for the seccomp mode 2 sandbox persist across
execve and can change the behavior of newly-executed programs.
Unprivileged users are therefore only allowed to install such filters
if no_new_privs is set.
- By itself, no_new_privs can be used to reduce the attack surface
available to an unprivileged user. If everything running with a
given uid has no_new_privs set, then that uid will be unable to
escalate its privileges by directly attacking setuid, setgid, and
fcap-using binaries; it will need to compromise something without the
no_new_privs bit set first.
In the future, other potentially dangerous kernel features could become
available to unprivileged tasks if no_new_privs is set. In principle,
several options to unshare(2) and clone(2) would be safe when
no_new_privs is set, and no_new_privs + chroot is considerable less
dangerous than chroot by itself.

6
Documentation/stable_kernel_rules.txt
View file

@ -12,6 +12,12 @@ Rules on what kind of patches are accepted, and which ones are not, into the
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
- Serious issues as reported by a user of a distribution kernel may also
be considered if they fix a notable performance or interactivity issue.
As these fixes are not as obvious and have a higher risk of a subtle
regression they should only be submitted by a distribution kernel
maintainer and include an addendum linking to a bugzilla entry if it
exists and additional information on the user-visible impact.
- New device IDs and quirks are also accepted.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.

17
Documentation/virtual/kvm/api.txt
View file

@ -1930,6 +1930,23 @@ The "pte_enc" field provides a value that can OR'ed into the hash
PTE's RPN field (ie, it needs to be shifted left by 12 to OR it
into the hash PTE second double word).
4.75 KVM_IRQFD
Capability: KVM_CAP_IRQFD
Architectures: x86
Type: vm ioctl
Parameters: struct kvm_irqfd (in)
Returns: 0 on success, -1 on error
Allows setting an eventfd to directly trigger a guest interrupt.
kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
kvm_irqfd.gsi specifies the irqchip pin toggled by this event. When
an event is tiggered on the eventfd, an interrupt is injected into
the guest using the specified gsi pin. The irqfd is removed using
the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
and kvm_irqfd.gsi.
5. The kvm_run structure
------------------------

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