renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-11-16 22:54:39 +08:00
Code

Merge commit '8700c95adb03' into timers/nohz

Browse Source 
The full dynticks tree needs the latest RCU and sched
upstream updates in order to fix some dependencies.

Merge a common upstream merge point that has these
updates.

Conflicts:
	include/linux/perf_event.h
	kernel/rcutree.h
	kernel/rcutree_plugin.h

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
This commit is contained in:
Frederic Weisbecker 2013-05-02 17:37:49 +02:00
commit c032862fba
3692 changed files with 150969 additions and 120861 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
CREDITS
View File

@ -761,6 +761,10 @@ S: Northampton
S: NN1 3QT
S: United Kingdom
N: Massimo Dal Zotto
E: dz@debian.org
D: i8k Dell laptop SMM driver
N: Uwe Dannowski
E: Uwe.Dannowski@ira.uka.de
W: http://i30www.ira.uka.de/~dannowsk/
@ -953,11 +957,11 @@ S: Blacksburg, Virginia 24061
S: USA
N: Randy Dunlap
E: rdunlap@xenotime.net
W: http://www.xenotime.net/linux/linux.html
W: http://www.linux-usb.org
E: rdunlap@infradead.org
W: http://www.infradead.org/~rdunlap/
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
D: x86 SMP, ACPI, bootflag hacking
D: documentation, builds
S: (ask for current address)
S: USA
@ -1510,6 +1514,14 @@ D: Natsemi ethernet
D: Cobalt Networks (x86) support
D: This-and-That
N: Mark M. Hoffman
E: mhoffman@lightlink.com
D: asb100, lm93 and smsc47b397 hardware monitoring drivers
D: hwmon subsystem core
D: hwmon subsystem maintainer
D: i2c-sis96x and i2c-stub SMBus drivers
S: USA
N: Dirk Hohndel
E: hohndel@suse.de
D: The XFree86[tm] Project

7
Documentation/ABI/testing/sysfs-bus-mei Normal file
View File

@ -0,0 +1,7 @@
What: /sys/bus/mei/devices/.../modalias
Date: March 2013
KernelVersion: 3.10
Contact: Samuel Ortiz <sameo@linux.intel.com>
linux-mei@linux.intel.com
Description: Stores the same MODALIAS value emitted by uevent
Format: mei:<mei device name>

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

@ -32,7 +32,7 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been connected to the machine. This
file is read-only.
@ -45,7 +45,7 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been active, i.e. not in a suspended
state. This file is read-only.
@ -187,7 +187,7 @@ What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
Date: September 2011
Contact: Andiry Xu <andiry.xu@amd.com>
Description:
If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
is plugged in to a xHCI host which support link PM, it will
perform a LPM test; if the test is passed and host supports
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will

12
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -173,3 +173,15 @@ Description: Processor frequency boosting control
Boosting allows the CPU and the firmware to run at a frequency
beyound it's nominal limit.
More details can be found in Documentation/cpu-freq/boost.txt
What: /sys/devices/system/cpu/cpu#/crash_notes
/sys/devices/system/cpu/cpu#/crash_notes_size
Date: April 2013
Contact: kexec@lists.infradead.org
Description: address and size of the percpu note.
crash_notes: the physical address of the memory that holds the
note of cpu#.
crash_notes_size: size of the note of cpu#.

2
Documentation/DocBook/device-drivers.tmpl
View File

@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
<chapter id="uart16x50">
<title>16x50 UART Driver</title>
!Edrivers/tty/serial/serial_core.c
!Edrivers/tty/serial/8250/8250.c
!Edrivers/tty/serial/8250/8250_core.c
</chapter>
<chapter id="fbdev">

26
Documentation/RCU/checklist.txt
View File

@ -217,9 +217,14 @@ over a rather long period of time, but improvements are always welcome!
whether the increased speed is worth it.
8. Although synchronize_rcu() is slower than is call_rcu(), it
usually results in simpler code. So, unless update performance
is critically important or the updaters cannot block,
synchronize_rcu() should be used in preference to call_rcu().
usually results in simpler code. So, unless update performance is
critically important, the updaters cannot block, or the latency of
synchronize_rcu() is visible from userspace, synchronize_rcu()
should be used in preference to call_rcu(). Furthermore,
kfree_rcu() usually results in even simpler code than does
synchronize_rcu() without synchronize_rcu()'s multi-millisecond
latency. So please take advantage of kfree_rcu()'s "fire and
forget" memory-freeing capabilities where it applies.
An especially important property of the synchronize_rcu()
primitive is that it automatically self-limits: if grace periods
@ -268,7 +273,8 @@ over a rather long period of time, but improvements are always welcome!
e. Periodically invoke synchronize_rcu(), permitting a limited
number of updates per grace period.
The same cautions apply to call_rcu_bh() and call_rcu_sched().
The same cautions apply to call_rcu_bh(), call_rcu_sched(),
call_srcu(), and kfree_rcu().
9. All RCU list-traversal primitives, which include
rcu_dereference(), list_for_each_entry_rcu(), and
@ -296,9 +302,9 @@ over a rather long period of time, but improvements are always welcome!
all currently executing rcu_read_lock()-protected RCU read-side
critical sections complete. It does -not- necessarily guarantee
that all currently running interrupts, NMIs, preempt_disable()
code, or idle loops will complete. Therefore, if you do not have
rcu_read_lock()-protected read-side critical sections, do -not-
use synchronize_rcu().
code, or idle loops will complete. Therefore, if your
read-side critical sections are protected by something other
than rcu_read_lock(), do -not- use synchronize_rcu().
Similarly, disabling preemption is not an acceptable substitute
for rcu_read_lock(). Code that attempts to use preemption
@ -401,9 +407,9 @@ over a rather long period of time, but improvements are always welcome!
read-side critical sections. It is the responsibility of the
RCU update-side primitives to deal with this.
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
the __rcu sparse checks to validate your RCU code. These
can help find problems as follows:
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the
__rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
validate your RCU code. These can help find problems as follows:
CONFIG_PROVE_RCU: check that accesses to RCU-protected data
structures are carried out under the proper RCU

5
Documentation/RCU/lockdep.txt
View File

@ -64,6 +64,11 @@ checking of rcu_dereference() primitives:
but retain the compiler constraints that prevent duplicating
or coalescsing. This is useful when when testing the
value of the pointer itself, for example, against NULL.
rcu_access_index(idx):
Return the value of the index and omit all barriers, but
retain the compiler constraints that prevent duplicating
or coalescsing. This is useful when when testing the
value of the index itself, for example, against -1.
The rcu_dereference_check() check expression can be any boolean
expression, but would normally include a lockdep expression. However,

15
Documentation/RCU/rcubarrier.txt
View File

@ -79,7 +79,20 @@ complete. Pseudo-code using rcu_barrier() is as follows:
2. Execute rcu_barrier().
3. Allow the module to be unloaded.
The rcutorture module makes use of rcu_barrier in its exit function
There are also rcu_barrier_bh(), rcu_barrier_sched(), and srcu_barrier()
functions for the other flavors of RCU, and you of course must match
the flavor of rcu_barrier() with that of call_rcu(). If your module
uses multiple flavors of call_rcu(), then it must also use multiple
flavors of rcu_barrier() when unloading that module. For example, if
it uses call_rcu_bh(), call_srcu() on srcu_struct_1, and call_srcu() on
srcu_struct_2(), then the following three lines of code will be required
when unloading:
1 rcu_barrier_bh();
2 srcu_barrier(&srcu_struct_1);
3 srcu_barrier(&srcu_struct_2);
The rcutorture module makes use of rcu_barrier() in its exit function
as follows:
1 static void

33
Documentation/RCU/stallwarn.txt
View File

@ -92,14 +92,14 @@ If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
more information is printed with the stall-warning message, for example:
INFO: rcu_preempt detected stall on CPU
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
(t=65000 jiffies)
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
printed:
INFO: rcu_preempt detected stall on CPU
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
(t=65000 jiffies)
The "(64628 ticks this GP)" indicates that this CPU has taken more
@ -116,13 +116,28 @@ number between the two "/"s is the value of the nesting, which will
be a small positive number if in the idle loop and a very large positive
number (as shown above) otherwise.
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
not in the process of trying to force itself into dyntick-idle state, the
"." indicates that the CPU has not given up forcing RCU into dyntick-idle
mode (it would be "H" otherwise), and the "timer not pending" indicates
that the CPU has not recently forced RCU into dyntick-idle mode (it
would otherwise indicate the number of microseconds remaining in this
forced state).
The "softirq=" portion of the message tracks the number of RCU softirq
handlers that the stalled CPU has executed. The number before the "/"
is the number that had executed since boot at the time that this CPU
last noted the beginning of a grace period, which might be the current
(stalled) grace period, or it might be some earlier grace period (for
example, if the CPU might have been in dyntick-idle mode for an extended
time period. The number after the "/" is the number that have executed
since boot until the current time. If this latter number stays constant
across repeated stall-warning messages, it is possible that RCU's softirq
handlers are no longer able to execute on this CPU. This can happen if
the stalled CPU is spinning with interrupts are disabled, or, in -rt
kernels, if a high-priority process is starving RCU's softirq handler.
For CONFIG_RCU_FAST_NO_HZ kernels, the "last_accelerate:" prints the
low-order 16 bits (in hex) of the jiffies counter when this CPU last
invoked rcu_try_advance_all_cbs() from rcu_needs_cpu() or last invoked
rcu_accelerate_cbs() from rcu_prepare_for_idle(). The "nonlazy_posted:"
prints the number of non-lazy callbacks posted since the last call to
rcu_needs_cpu(). Finally, an "L" indicates that there are currently
no non-lazy callbacks ("." is printed otherwise, as shown above) and
"D" indicates that dyntick-idle processing is enabled ("." is printed
otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
Multiple Warnings From One Stall

4
Documentation/RCU/whatisRCU.txt
View File

@ -265,9 +265,9 @@ rcu_dereference()
rcu_read_lock();
p = rcu_dereference(head.next);
rcu_read_unlock();
x = p->address;
x = p->address; /* BUG!!! */
rcu_read_lock();
y = p->data;
y = p->data; /* BUG!!! */
rcu_read_unlock();
Holding a reference from one RCU read-side critical section

12
Documentation/SubmittingPatches
View File

@ -60,8 +60,7 @@ own source tree. For example:
"dontdiff" is a list of files which are generated by the kernel during
the build process, and should be ignored in any diff(1)-generated
patch. The "dontdiff" file is included in the kernel tree in
2.6.12 and later. For earlier kernel versions, you can get it
from <http://www.xenotime.net/linux/doc/dontdiff>.
2.6.12 and later.
Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
@ -421,7 +420,7 @@ person it names. This tag documents that potentially interested parties
have been included in the discussion
14) Using Reported-by:, Tested-by: and Reviewed-by:
14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution. Please
@ -469,6 +468,13 @@ done on the patch. Reviewed-by: tags, when supplied by reviewers known to
understand the subject area and to perform thorough reviews, will normally
increase the likelihood of your patch getting into the kernel.
A Suggested-by: tag indicates that the patch idea is suggested by the person
named and ensures credit to the person for the idea. Please note that this
tag should not be added without the reporter's permission, especially if the
idea was not posted in a public forum. That said, if we diligently credit our
idea reporters, they will, hopefully, be inspired to help us again in the
future.
15) The canonical patch format

56
Documentation/arm/sunxi/clocks.txt Normal file
View File

@ -0,0 +1,56 @@
Frequently asked questions about the sunxi clock system
=======================================================
This document contains useful bits of information that people tend to ask
about the sunxi clock system, as well as accompanying ASCII art when adequate.
Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
system?
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
carelessly the system would stop functioning, but with the right
steps, one can gate it and keep the system running. Consider this
simplified suspend example:
While the system is operational, you would see something like
24MHz 32kHz
|
PLL1
\
\_ CPU Mux
|
[CPU]
When you are about to suspend, you switch the CPU Mux to the 32kHz
oscillator:
24Mhz 32kHz
| |
PLL1 |
/
CPU Mux _/
|
[CPU]
Finally you can gate the main oscillator
32kHz
|
|
/
CPU Mux _/
|
[CPU]
Q: Were can I learn more about the sunxi clocks?
A: The linux-sunxi wiki contains a page documenting the clock registers,
you can find it at
http://linux-sunxi.org/A10/CCM
The authoritative source for information at this time is the ccmu driver
released by Allwinner, you can find it at
https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu

7
Documentation/backlight/lp855x-driver.txt
View File

@ -32,14 +32,10 @@ Platform data for lp855x
For supporting platform specific data, the lp855x platform data can be used.
* name : Backlight driver name. If it is not defined, default name is set.
* mode : Brightness control mode. PWM or register based.
* device_control : Value of DEVICE CONTROL register.
* initial_brightness : Initial value of backlight brightness.
* period_ns : Platform specific PWM period value. unit is nano.
Only valid when brightness is pwm input mode.
* load_new_rom_data :
0 : use default configuration data
1 : update values of eeprom or eprom registers on loading driver
* size_program : Total size of lp855x_rom_data.
* rom_data : List of new eeprom/eprom registers.
@ -54,10 +50,8 @@ static struct lp855x_rom_data lp8552_eeprom_arr[] = {
static struct lp855x_platform_data lp8552_pdata = {
.name = "lcd-bl",
.mode = REGISTER_BASED,
.device_control = I2C_CONFIG(LP8552),
.initial_brightness = INITIAL_BRT,
.load_new_rom_data = 1,
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
.rom_data = lp8552_eeprom_arr,
};
@ -65,7 +59,6 @@ static struct lp855x_platform_data lp8552_pdata = {
example 2) lp8556 platform data : pwm input mode with default rom data
static struct lp855x_platform_data lp8556_pdata = {
.mode = PWM_BASED,
.device_control = PWM_CONFIG(LP8556),
.initial_brightness = INITIAL_BRT,
.period_ns = 1000000,

3
Documentation/cgroups/cgroups.txt
View File

@ -442,7 +442,7 @@ You can attach the current shell task by echoing 0:
You can use the cgroup.procs file instead of the tasks file to move all
threads in a threadgroup at once. Echoing the PID of any task in a
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
in the writing task's threadgroup.
Note: Since every task is always a member of exactly one cgroup in each
@ -580,6 +580,7 @@ propagation along the hierarchy. See the comment on
cgroup_for_each_descendant_pre() for details.
void css_offline(struct cgroup *cgrp);
(cgroup_mutex held by caller)
This is the counterpart of css_online() and called iff css_online()
has succeeded on @cgrp. This signifies the beginning of the end of

70
Documentation/cgroups/devices.txt
View File

@ -13,9 +13,7 @@ either an integer or * for all. Access is a composition of r
The root device cgroup starts with rwm to 'all'. A child device
cgroup gets a copy of the parent. Administrators can then remove
devices from the whitelist or add new entries. A child cgroup can
never receive a device access which is denied by its parent. However
when a device access is removed from a parent it will not also be
removed from the child(ren).
never receive a device access which is denied by its parent.
2. User Interface
@ -50,3 +48,69 @@ task to a new cgroup. (Again we'll probably want to change that).
A cgroup may not be granted more permissions than the cgroup's
parent has.
4. Hierarchy
device cgroups maintain hierarchy by making sure a cgroup never has more
access permissions than its parent. Every time an entry is written to
a cgroup's devices.deny file, all its children will have that entry removed
from their whitelist and all the locally set whitelist entries will be
re-evaluated. In case one of the locally set whitelist entries would provide
more access than the cgroup's parent, it'll be removed from the whitelist.
Example:
A
/ \
B
group behavior exceptions
A allow "b 8:* rwm", "c 116:1 rw"
B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
If a device is denied in group A:
# echo "c 116:* r" > A/devices.deny
it'll propagate down and after revalidating B's entries, the whitelist entry
"c 116:2 rwm" will be removed:
group whitelist entries denied devices
A all "b 8:* rwm", "c 116:* rw"
B "c 1:3 rwm", "b 3:* rwm" all the rest
In case parent's exceptions change and local exceptions are not allowed
anymore, they'll be deleted.
Notice that new whitelist entries will not be propagated:
A
/ \
B
group whitelist entries denied devices
A "c 1:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
when adding "c *:3 rwm":
# echo "c *:3 rwm" >A/devices.allow
the result:
group whitelist entries denied devices
A "c *:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
but now it'll be possible to add new entries to B:
# echo "c 2:3 rwm" >B/devices.allow
# echo "c 50:3 r" >B/devices.allow
or even
# echo "c *:3 rwm" >B/devices.allow
Allowing or denying all by writing 'a' to devices.allow or devices.deny will
not be possible once the device cgroups has children.
4.1 Hierarchy (internal implementation)
device cgroups is implemented internally using a behavior (ALLOW, DENY) and a
list of exceptions. The internal state is controlled using the same user
interface to preserve compatibility with the previous whitelist-only
implementation. Removal or addition of exceptions that will reduce the access
to devices will be propagated down the hierarchy.
For every propagated exception, the effective rules will be re-evaluated based
on current parent's access rules.

70
Documentation/cgroups/memory.txt
View File

@ -40,6 +40,7 @@ Features:
- soft limit
- moving (recharging) account at moving a task is selectable.
- usage threshold notifier
- memory pressure notifier
- oom-killer disable knob and oom-notifier
- Root cgroup has no limit controls.
@ -65,6 +66,7 @@ Brief summary of control files.
memory.stat # show various statistics
memory.use_hierarchy # set/show hierarchical account enabled
memory.force_empty # trigger forced move charge to parent
memory.pressure_level # set memory pressure notifications
memory.swappiness # set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
memory.move_charge_at_immigrate # set/show controls of moving charges
@ -762,7 +764,73 @@ At reading, current status of OOM is shown.
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
11. TODO
11. Memory Pressure
The pressure level notifications can be used to monitor the memory
allocation cost; based on the pressure, applications can implement
different strategies of managing their memory resources. The pressure
levels are defined as following:
The "low" level means that the system is reclaiming memory for new
allocations. Monitoring this reclaiming activity might be useful for
maintaining cache level. Upon notification, the program (typically
"Activity Manager") might analyze vmstat and act in advance (i.e.
prematurely shutdown unimportant services).
The "medium" level means that the system is experiencing medium memory
pressure, the system might be making swap, paging out active file caches,
etc. Upon this event applications may decide to further analyze
vmstat/zoneinfo/memcg or internal memory usage statistics and free any
resources that can be easily reconstructed or re-read from a disk.
The "critical" level means that the system is actively thrashing, it is
about to out of memory (OOM) or even the in-kernel OOM killer is on its
way to trigger. Applications should do whatever they can to help the
system. It might be too late to consult with vmstat or any other
statistics, so it's advisable to take an immediate action.
The events are propagated upward until the event is handled, i.e. the
events are not pass-through. Here is what this means: for example you have
three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
and C, and suppose group C experiences some pressure. In this situation,
only group C will receive the notification, i.e. groups A and B will not
receive it. This is done to avoid excessive "broadcasting" of messages,
which disturbs the system and which is especially bad if we are low on
memory or thrashing. So, organize the cgroups wisely, or propagate the
events manually (or, ask us to implement the pass-through events,
explaining why would you need them.)
The file memory.pressure_level is only used to setup an eventfd. To
register a notification, an application must:
- create an eventfd using eventfd(2);
- open memory.pressure_level;
- write string like "<event_fd> <fd of memory.pressure_level> <level>"
to cgroup.event_control.
Application will be notified through eventfd when memory pressure is at
the specific level (or higher). Read/write operations to
memory.pressure_level are no implemented.
Test:
Here is a small script example that makes a new cgroup, sets up a
memory limit, sets up a notification in the cgroup and then makes child
cgroup experience a critical pressure:
# cd /sys/fs/cgroup/memory/
# mkdir foo
# cd foo
# cgroup_event_listener memory.pressure_level low &
# echo 8000000 > memory.limit_in_bytes
# echo 8000000 > memory.memsw.limit_in_bytes
# echo $$ > tasks
# dd if=/dev/zero | read x
(Expect a bunch of notifications, and eventually, the oom-killer will
trigger.)
12. TODO
1. Add support for accounting huge pages (as a separate controller)
2. Make per-cgroup scanner reclaim not-shared pages first

15
Documentation/clk.txt
View File

@ -174,9 +174,9 @@ int clk_foo_enable(struct clk_hw *hw)
};
Below is a matrix detailing which clk_ops are mandatory based upon the
hardware capbilities of that clock. A cell marked as "y" means
hardware capabilities of that clock. A cell marked as "y" means
mandatory, a cell marked as "n" implies that either including that
callback is invalid or otherwise uneccesary. Empty cells are either
callback is invalid or otherwise unnecessary. Empty cells are either
optional or must be evaluated on a case-by-case basis.
clock hardware characteristics
@ -231,3 +231,14 @@ To better enforce this policy, always follow this simple rule: any
statically initialized clock data MUST be defined in a separate file
from the logic that implements its ops. Basically separate the logic
from the data and all is well.
Part 6 - Disabling clock gating of unused clocks
Sometimes during development it can be useful to be able to bypass the
default disabling of unused clocks. For example, if drivers aren't enabling
clocks properly but rely on them being on from the bootloader, bypassing
the disabling means that the driver will remain functional while the issues
are sorted out.
To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
kernel.

44
Documentation/device-mapper/dm-raid.txt
View File

@ -30,6 +30,7 @@ The target is named "raid" and it accepts the following parameters:
raid10 Various RAID10 inspired algorithms chosen by additional params
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
- RAID1E: Integrated Adjacent Stripe Mirroring
- RAID1E: Integrated Offset Stripe Mirroring
- and other similar RAID10 variants
Reference: Chapter 4 of
@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters:
synchronisation state for each region.
[raid10_copies <# copies>]
[raid10_format near]
[raid10_format <near|far|offset>]
These two options are used to alter the default layout of
a RAID10 configuration. The number of copies is can be
specified, but the default is 2. There are other variations
to how the copies are laid down - the default and only current
option is "near". Near copies are what most people think of
with respect to mirroring. If these options are left
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
are given, then the layouts for 2, 3 and 4 devices are:
specified, but the default is 2. There are also three
variations to how the copies are laid down - the default
is "near". Near copies are what most people think of with
respect to mirroring. If these options are left unspecified,
or 'raid10_copies 2' and/or 'raid10_format near' are given,
then the layouts for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- ---------- --------------
A1 A1 A1 A1 A2 A1 A1 A2 A2
@ -85,6 +86,33 @@ The target is named "raid" and it accepts the following parameters:
3-device layout is what might be called a 'RAID1E - Integrated
Adjacent Stripe Mirroring'.
If 'raid10_copies 2' and 'raid10_format far', then the layouts
for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- -------------- --------------------
A1 A2 A1 A2 A3 A1 A2 A3 A4
A3 A4 A4 A5 A6 A5 A6 A7 A8
A5 A6 A7 A8 A9 A9 A10 A11 A12
.. .. .. .. .. .. .. .. ..
A2 A1 A3 A1 A2 A2 A1 A4 A3
A4 A3 A6 A4 A5 A6 A5 A8 A7
A6 A5 A9 A7 A8 A10 A9 A12 A11
.. .. .. .. .. .. .. .. ..
If 'raid10_copies 2' and 'raid10_format offset', then the
layouts for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- ------------ -----------------
A1 A2 A1 A2 A3 A1 A2 A3 A4
A2 A1 A3 A1 A2 A2 A1 A4 A3
A3 A4 A4 A5 A6 A5 A6 A7 A8
A4 A3 A6 A4 A5 A6 A5 A8 A7
A5 A6 A7 A8 A9 A9 A10 A11 A12
A6 A5 A9 A7 A8 A10 A9 A12 A11
.. .. .. .. .. .. .. .. ..
Here we see layouts closely akin to 'RAID1E - Integrated
Offset Stripe Mirroring'.
<#raid_devs>: The number of devices composing the array.
Each device consists of two entries. The first is the device
containing the metadata (if any); the second is the one containing the
@ -142,3 +170,5 @@ Version History
1.3.0 Added support for RAID 10
1.3.1 Allow device replacement/rebuild for RAID 10
1.3.2 Fix/improve redundancy checking for RAID10
1.4.0 Non-functional change. Removes arg from mapping function.
1.4.1 Add RAID10 "far" and "offset" algorithm support.

13
Documentation/devicetree/bindings/arm/atmel-adc.txt
View File

@ -14,9 +14,19 @@ Required properties:
- atmel,adc-status-register: Offset of the Interrupt Status Register
- atmel,adc-trigger-register: Offset of the Trigger Register
- atmel,adc-vref: Reference voltage in millivolts for the conversions
- atmel,adc-res: List of resolution in bits supported by the ADC. List size
must be two at least.
- atmel,adc-res-names: Contains one identifier string for each resolution
in atmel,adc-res property. "lowres" and "highres"
identifiers are required.
Optional properties:
- atmel,adc-use-external: Boolean to enable of external triggers
- atmel,adc-use-res: String corresponding to an identifier from
atmel,adc-res-names property. If not specified, the highest
resolution will be used.
- atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
- atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
Optional trigger Nodes:
- Required properties:
@ -40,6 +50,9 @@ adc0: adc@fffb0000 {
atmel,adc-trigger-register = <0x08>;
atmel,adc-use-external;
atmel,adc-vref = <3300>;
atmel,adc-res = <8 10>;
atmel,adc-res-names = "lowres", "highres";
atmel,adc-use-res = "lowres";
trigger@0 {
trigger-name = "external-rising";

18
Documentation/devicetree/bindings/arm/msm/ssbi.txt Normal file
View File

@ -0,0 +1,18 @@
* Qualcomm SSBI
Some Qualcomm MSM devices contain a point-to-point serial bus used to
communicate with a limited range of devices (mostly power management
chips).
These require the following properties:
- compatible: "qcom,ssbi"
- qcom,controller-type
indicates the SSBI bus variant the controller should use to talk
with the slave device. This should be one of "ssbi", "ssbi2", or
"pmic-arbiter". The type chosen is determined by the attached
slave.
The slave device should be the single child node of the ssbi device
with a compatible field.

60
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt Normal file
View File

@ -0,0 +1,60 @@
Samsung Exynos Analog to Digital Converter bindings
The devicetree bindings are for the new ADC driver written for
Exynos4 and upward SoCs from Samsung.
New driver handles the following
1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
and future SoCs from Samsung
2. Add ADC driver under iio/adc framework
3. Also adds the Documentation for device tree bindings
Required properties:
- compatible: Must be "samsung,exynos-adc-v1"
for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
- #io-channel-cells = <1>; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
- clock-names From common clock binding: Shall be "adc".
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
Example: adding device info in dtsi file
adc: adc@12D10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>, <0x10040718 0x4>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
io-channel-ranges;
clocks = <&clock 303>;
clock-names = "adc";
vdd-supply = <&buck5_reg>;
};
Example: Adding child nodes in dts file
adc@12D10000 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
pullup-uV = <1800000>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 4>;
};
};
Note: Does not apply to ADC driver under arch/arm/plat-samsung/
Note: The child node can be added under the adc node or separately.

22
Documentation/devicetree/bindings/clock/axi-clkgen.txt Normal file
View File

@ -0,0 +1,22 @@
Binding for the axi-clkgen clock generator
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "adi,axi-clkgen".
- #clock-cells : from common clock binding; Should always be set to 0.
- reg : Address and length of the axi-clkgen register set.
- clocks : Phandle and clock specifier for the parent clock.
Optional properties:
- clock-output-names : From common clock binding.
Example:
clock@0xff000000 {
compatible = "adi,axi-clkgen";
#clock-cells = <0>;
reg = <0xff000000 0x1000>;
clocks = <&osc 1>;
};

24
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt Normal file
View File

@ -0,0 +1,24 @@
Binding for simple fixed factor rate clock sources.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-factor-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clock-div: fixed divider.
- clock-mult: fixed multiplier.
- clocks: parent clock.
Optional properties:
- clock-output-names : From common clock binding.
Example:
clock {
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
div = <2>;
mult = <1>;
};

114
Documentation/devicetree/bindings/clock/silabs,si5351.txt Normal file
View File

@ -0,0 +1,114 @@
Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
Reference
[1] Si5351A/B/C Data Sheet
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
The Si5351a/b/c are programmable i2c clock generators with upto 8 output
clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
3 output clocks are accessible. The internal structure of the clock
generators can be found in [1].
==I2C device node==
Required properties:
- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
- reg: i2c device address, shall be 0x60 or 0x61.
- #clock-cells: from common clock binding; shall be set to 1.
- clocks: from common clock binding; list of parent clock
handles, shall be xtal reference clock or xtal and clkin for
si5351c only.
- #address-cells: shall be set to 1.
- #size-cells: shall be set to 0.
Optional properties:
- silabs,pll-source: pair of (number, source) for each pll. Allows
to overwrite clock source of pll A (number=0) or B (number=1).
==Child nodes==
Each of the clock outputs can be overwritten individually by
using a child node to the I2C device node. If a child node for a clock
output is not set, the eeprom configuration is not overwritten.
Required child node properties:
- reg: number of clock output.
Optional child node properties:
- silabs,clock-source: source clock of the output divider stage N, shall be
0 = multisynth N
1 = multisynth 0 for output clocks 0-3, else multisynth4
2 = xtal
3 = clkin (si5351c only)
- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
divider.
- silabs,pll-master: boolean, multisynth can change pll frequency.
==Example==
/* 25MHz reference crystal */
ref25: ref25M {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
};
i2c-master-node {
/* Si5351a msop10 i2c clock generator */
si5351a: clock-generator@60 {
compatible = "silabs,si5351a-msop";
reg = <0x60>;
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <1>;
/* connect xtal input to 25MHz reference */
clocks = <&ref25>;
/* connect xtal input as source of pll0 and pll1 */
silabs,pll-source = <0 0>, <1 0>;
/*
* overwrite clkout0 configuration with:
* - 8mA output drive strength
* - pll0 as clock source of multisynth0
* - multisynth0 as clock source of output divider
* - multisynth0 can change pll0
* - set initial clock frequency of 74.25MHz
*/
clkout0 {
reg = <0>;
silabs,drive-strength = <8>;
silabs,multisynth-source = <0>;
silabs,clock-source = <0>;
silabs,pll-master;
clock-frequency = <74250000>;
};
/*
* overwrite clkout1 configuration with:
* - 4mA output drive strength
* - pll1 as clock source of multisynth1
* - multisynth1 as clock source of output divider
* - multisynth1 can change pll1
*/
clkout1 {
reg = <1>;
silabs,drive-strength = <4>;
silabs,multisynth-source = <1>;
silabs,clock-source = <0>;
pll-master;
};
/*
* overwrite clkout2 configuration with:
* - xtal as clock source of output divider
*/
clkout2 {
reg = <2>;
silabs,clock-source = <2>;
};
};
};

151
Documentation/devicetree/bindings/clock/sunxi.txt Normal file
View File

@ -0,0 +1,151 @@
Device Tree Clock bindings for arch-sunxi
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"allwinner,sun4i-osc-clk" - for a gatable oscillator
"allwinner,sun4i-pll1-clk" - for the main PLL clock
"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-axi-clk" - for the AXI clock
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-ahb-clk" - for the AHB clock
"allwinner,sun4i-ahb-gates-clk" - for the AHB gates
"allwinner,sun4i-apb0-clk" - for the APB0 clock
"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
"allwinner,sun4i-apb1-clk" - for the APB1 clock
"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
Required properties for all clocks:
- reg : shall be the control register address for the clock.
- clocks : shall be the input parent clock(s) phandle for the clock
- #clock-cells : from common clock binding; shall be set to 0 except for
"allwinner,sun4i-*-gates-clk" where it shall be set to 1
Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
- clock-output-names : the corresponding gate names that the clock controls
For example:
osc24M: osc24M@01c20050 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-osc-clk";
reg = <0x01c20050 0x4>;
clocks = <&osc24M_fixed>;
};
pll1: pll1@01c20000 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-pll1-clk";
reg = <0x01c20000 0x4>;
clocks = <&osc24M>;
};
cpu: cpu@01c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-cpu-clk";
reg = <0x01c20054 0x4>;
clocks = <&osc32k>, <&osc24M>, <&pll1>;
};
Gate clock outputs
The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
their corresponding offsets as present on sun4i are listed below. Note that
some of these gates are not present on sun5i.
* AXI gates ("allwinner,sun4i-axi-gates-clk")
DRAM 0
* AHB gates ("allwinner,sun4i-ahb-gates-clk")
USB0 0
EHCI0 1
OHCI0 2*
EHCI1 3
OHCI1 4*
SS 5
DMA 6
BIST 7
MMC0 8
MMC1 9
MMC2 10
MMC3 11
MS 12**
NAND 13
SDRAM 14
ACE 16
EMAC 17
TS 18
SPI0 20
SPI1 21
SPI2 22
SPI3 23
PATA 24
SATA 25**
GPS 26*
VE 32
TVD 33
TVE0 34
TVE1 35
LCD0 36
LCD1 37
CSI0 40
CSI1 41
HDMI 43
DE_BE0 44
DE_BE1 45
DE_FE0 46
DE_FE1 47
MP 50
MALI400 52
* APB0 gates ("allwinner,sun4i-apb0-gates-clk")
CODEC 0
SPDIF 1*
AC97 2
IIS 3
PIO 5
IR0 6
IR1 7
KEYPAD 10
* APB1 gates ("allwinner,sun4i-apb1-gates-clk")
I2C0 0
I2C1 1
I2C2 2
CAN 4
SCR 5
PS20 6
PS21 7
UART0 16
UART1 17
UART2 18
UART3 19
UART4 20
UART5 21
UART6 22
UART7 23
Notation:
[*]: The datasheet didn't mention these, but they are present on AW code
[**]: The datasheet had this marked as "NC" but they are used on AW code

6
Documentation/devicetree/bindings/gpio/gpio.txt
View File

@ -98,7 +98,7 @@ announce the pinrange to the pin ctrl subsystem. For example,
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
}
@ -107,8 +107,8 @@ where,
Next values specify the base pin and number of pins for the range
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
by this gpio controller.
pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
pinctrl2 with gpio offset 10 is handled by this gpio controller.
The pinctrl node must have "#gpio-range-cells" property to show number of
arguments to pass with phandle from gpio controllers node.

29
Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt Normal file
View File

@ -0,0 +1,29 @@
NTC Thermistor hwmon sensors
-------------------------------
Requires node properties:
- "compatible" value : one of
"ntc,ncp15wb473"
"ntc,ncp18wb473"
"ntc,ncp21wb473"
"ntc,ncp03wb473"
"ntc,ncp15wl333"
- "pullup-uv" Pull up voltage in micro volts
- "pullup-ohm" Pull up resistor value in ohms
- "pulldown-ohm" Pull down resistor value in ohms
- "connected-positive" Always ON, If not specified.
Status change is possible.
- "io-channels" Channel node of ADC to be used for
conversion.
Read more about iio bindings at
Documentation/devicetree/bindings/iio/iio-bindings.txt
Example:
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
pullup-uv = <1800000>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 3>;
};

97
Documentation/devicetree/bindings/iio/iio-bindings.txt Normal file
View File

@ -0,0 +1,97 @@
This binding is derived from clock bindings, and based on suggestions
from Lars-Peter Clausen [1].
Sources of IIO channels can be represented by any node in the device
tree. Those nodes are designated as IIO providers. IIO consumer
nodes use a phandle and IIO specifier pair to connect IIO provider
outputs to IIO inputs. Similar to the gpio specifiers, an IIO
specifier is an array of one or more cells identifying the IIO
output on a device. The length of an IIO specifier is defined by the
value of a #io-channel-cells property in the IIO provider node.
[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
==IIO providers==
Required properties:
#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
with a single IIO output and 1 for nodes with multiple
IIO outputs.
Example for a simple configuration with no trigger:
adc: voltage-sensor@35 {
compatible = "maxim,max1139";
reg = <0x35>;
#io-channel-cells = <1>;
};
Example for a configuration with trigger:
adc@35 {
compatible = "some-vendor,some-adc";
reg = <0x35>;
adc1: iio-device@0 {
#io-channel-cells = <1>;
/* other properties */
};
adc2: iio-device@1 {
#io-channel-cells = <1>;
/* other properties */
};
};
==IIO consumers==
Required properties:
io-channels: List of phandle and IIO specifier pairs, one pair
for each IIO input to the device. Note: if the
IIO provider specifies '0' for #io-channel-cells,
then only the phandle portion of the pair will appear.
Optional properties:
io-channel-names:
List of IIO input name strings sorted in the same
order as the io-channels property. Consumers drivers
will use io-channel-names to match IIO input names
with IIO specifiers.
io-channel-ranges:
Empty property indicating that child nodes can inherit named
IIO channels from this node. Useful for bus nodes to provide
and IIO channel to their children.
For example:
device {
io-channels = <&adc 1>, <&ref 0>;
io-channel-names = "vcc", "vdd";
};
This represents a device with two IIO inputs, named "vcc" and "vdd".
The vcc channel is connected to output 1 of the &adc device, and the
vdd channel is connected to output 0 of the &ref device.
==Example==
adc: max1139@35 {
compatible = "maxim,max1139";
reg = <0x35>;
#io-channel-cells = <1>;
};
...
iio_hwmon {
compatible = "iio-hwmon";
io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
<&adc 3>, <&adc 4>, <&adc 5>,
<&adc 6>, <&adc 7>, <&adc 8>,
<&adc 9>;
};
some_consumer {
compatible = "some-consumer";
io-channels = <&adc 10>, <&adc 11>;
io-channel-names = "adc1", "adc2";
};

30
Documentation/devicetree/bindings/media/coda.txt Normal file
View File

@ -0,0 +1,30 @@
Chips&Media Coda multi-standard codec IP
========================================
Coda codec IPs are present in i.MX SoCs in various versions,
called VPU (Video Processing Unit).
Required properties:
- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
(a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
(b) "fsl,imx53-vpu" for CODA7541 present in i.MX53
(c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
- reg: should be register base and length as documented in the
SoC reference manual
- interrupts : Should contain the VPU interrupt. For CODA960,
a second interrupt is needed for the MJPEG unit.
- clocks : Should contain the ahb and per clocks, in the order
determined by the clock-names property.
- clock-names : Should be "ahb", "per"
- iram : phandle pointing to the SRAM device node
Example:
vpu: vpu@63ff4000 {
compatible = "fsl,imx53-vpu";
reg = <0x63ff4000 0x1000>;
interrupts = <9>;
clocks = <&clks 63>, <&clks 63>;
clock-names = "ahb", "per";
iram = <&ocram>;
};

6
Documentation/devicetree/bindings/mfd/ab8500.txt
View File

@ -13,9 +13,6 @@ Required parent device properties:
4 = active high level-sensitive
8 = active low level-sensitive
Optional parent device properties:
- reg : contains the PRCMU mailbox address for the AB8500 i2c port
The AB8500 consists of a large and varied group of sub-devices:
Device IRQ Names Supply Names Description
@ -86,9 +83,8 @@ Non-standard child device properties:
- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic
- stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
ab8500@5 {
ab8500 {
compatible = "stericsson,ab8500";
reg = <5>; /* mailbox 5 is i2c */
interrupts = <0 40 0x4>;
interrupt-controller;
#interrupt-cells = <2>;

36
Documentation/devicetree/bindings/mfd/mc13xxx.txt
View File

@ -10,10 +10,40 @@ Optional properties:
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
Sub-nodes:
- regulators : Contain the regulator nodes. The MC13892 regulators are
bound using their names as listed below with their registers and bits
for enabling.
- regulators : Contain the regulator nodes. The regulators are bound using
their names as listed below with their registers and bits for enabling.
MC13783 regulators:
sw1a : regulator SW1A (register 24, bit 0)
sw1b : regulator SW1B (register 25, bit 0)
sw2a : regulator SW2A (register 26, bit 0)
sw2b : regulator SW2B (register 27, bit 0)
sw3 : regulator SW3 (register 29, bit 20)
vaudio : regulator VAUDIO (register 32, bit 0)
viohi : regulator VIOHI (register 32, bit 3)
violo : regulator VIOLO (register 32, bit 6)
vdig : regulator VDIG (register 32, bit 9)
vgen : regulator VGEN (register 32, bit 12)
vrfdig : regulator VRFDIG (register 32, bit 15)
vrfref : regulator VRFREF (register 32, bit 18)
vrfcp : regulator VRFCP (register 32, bit 21)
vsim : regulator VSIM (register 33, bit 0)
vesim : regulator VESIM (register 33, bit 3)
vcam : regulator VCAM (register 33, bit 6)
vrfbg : regulator VRFBG (register 33, bit 9)
vvib : regulator VVIB (register 33, bit 11)
vrf1 : regulator VRF1 (register 33, bit 12)
vrf2 : regulator VRF2 (register 33, bit 15)
vmmc1 : regulator VMMC1 (register 33, bit 18)
vmmc2 : regulator VMMC2 (register 33, bit 21)
gpo1 : regulator GPO1 (register 34, bit 6)
gpo2 : regulator GPO2 (register 34, bit 8)
gpo3 : regulator GPO3 (register 34, bit 10)
gpo4 : regulator GPO4 (register 34, bit 12)
pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
MC13892 regulators:
vcoincell : regulator VCOINCELL (register 13, bit 23)
sw1 : regulator SW1 (register 24, bit 0)
sw2 : regulator SW2 (register 25, bit 0)

16
Documentation/devicetree/bindings/misc/sram.txt Normal file
View File

@ -0,0 +1,16 @@
Generic on-chip SRAM
Simple IO memory regions to be managed by the genalloc API.
Required properties:
- compatible : mmio-sram
- reg : SRAM iomem address range
Example:
sram: sram@5c000000 {
compatible = "mmio-sram";
reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
};

109
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
View File

@ -1,7 +1,9 @@
One-register-per-pin type device tree based pinctrl driver
Required properties:
- compatible : "pinctrl-single"
- compatible : "pinctrl-single" or "pinconf-single".
"pinctrl-single" means that pinconf isn't supported.
"pinconf-single" means that generic pinconf is supported.
- reg : offset and length of the register set for the mux registers
@ -14,9 +16,61 @@ Optional properties:
- pinctrl-single,function-off : function off mode for disabled state if
available and same for all registers; if not specified, disabling of
pin functions is ignored
- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
more than one pin
- pinctrl-single,drive-strength : array of value that are used to configure
drive strength in the pinmux register. They're value of drive strength
current and drive strength mask.
/* drive strength current, mask */
pinctrl-single,power-source = <0x30 0xf0>;
- pinctrl-single,bias-pullup : array of value that are used to configure the
input bias pullup in the pinmux register.
/* input, enabled pullup bits, disabled pullup bits, mask */
pinctrl-single,bias-pullup = <0 1 0 1>;
- pinctrl-single,bias-pulldown : array of value that are used to configure the
input bias pulldown in the pinmux register.
/* input, enabled pulldown bits, disabled pulldown bits, mask */
pinctrl-single,bias-pulldown = <2 2 0 2>;
* Two bits to control input bias pullup and pulldown: User should use
pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means
pullup, and the other one bit means pulldown.
* Three bits to control input bias enable, pullup and pulldown. User should
use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias
enable bit should be included in pullup or pulldown bits.
* Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as
pinctrl-single,bias-disable. Because pinctrl single driver could implement
it by calling pulldown, pullup disabled.
- pinctrl-single,input-schmitt : array of value that are used to configure
input schmitt in the pinmux register. In some silicons, there're two input
schmitt value (rising-edge & falling-edge) in the pinmux register.
/* input schmitt value, mask */
pinctrl-single,input-schmitt = <0x30 0x70>;
- pinctrl-single,input-schmitt-enable : array of value that are used to
configure input schmitt enable or disable in the pinmux register.
/* input, enable bits, disable bits, mask */
pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
range. They're value of subnode phandle, pin base in pinctrl device, pin
number in this range, GPIO function value of this GPIO range.
The number of parameters is depend on #pinctrl-single,gpio-range-cells
property.
/* pin base, nr pins & gpio function */
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
This driver assumes that there is only one register for each pin (unless the
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
specified in the pinctrl-bindings.txt document in this directory.
@ -42,6 +96,20 @@ Where 0xdc is the offset from the pinctrl register base address for the
device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
be used when applying this change to the register.
Optional sub-node: In case some pins could be configured as GPIO in the pinmux
register, those pins could be defined as a GPIO range. This sub-node is required
by pinctrl-single,gpio-range property.
Required properties in sub-node:
- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
pinctrl-single,gpio-range property.
range: gpio-range {
#pinctrl-single,gpio-range-cells = <3>;
};
Example:
/* SoC common file */
@ -58,7 +126,7 @@ pmx_core: pinmux@4a100040 {
/* second controller instance for pins in wkup domain */
pmx_wkup: pinmux@4a31e040 {
compatible = "pinctrl-single;
compatible = "pinctrl-single";
reg = <0x4a31e040 0x0038>;
#address-cells = <1>;
#size-cells = <0>;
@ -76,6 +144,29 @@ control_devconf0: pinmux@48002274 {
pinctrl-single,function-mask = <0x5F>;
};
/* third controller instance for pins in gpio domain */
pmx_gpio: pinmux@d401e000 {
compatible = "pinconf-single";
reg = <0xd401e000 0x0330>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <7>;
/* sparse GPIO range could be supported */
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
&range 12 1 0 &range 13 29 1
&range 43 1 0 &range 44 49 1
&range 94 1 1 &range 96 2 1>;
range: gpio-range {
#pinctrl-single,gpio-range-cells = <3>;
};
};
/* board specific .dts file */
&pmx_core {
@ -96,6 +187,15 @@ control_devconf0: pinmux@48002274 {
>;
};
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
0x208 0 /* UART0_RXD (IOCFG138) */
0x20c 0 /* UART0_TXD (IOCFG139) */
>;
pinctrl-single,bias-pulldown = <0 2 2>;
pinctrl-single,bias-pullup = <0 1 1>;
};
/* map uart2 pins */
uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
@ -122,6 +222,11 @@ control_devconf0: pinmux@48002274 {
};
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins>;
};
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;

3
Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
View File

@ -7,6 +7,7 @@ on-chip controllers onto these pads.
Required Properties:
- compatible: should be one of the following.
- "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
- "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
- "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
- "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
@ -105,6 +106,8 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
- compatible: identifies the type of the external wakeup interrupt controller
The possible values are:
- samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
found on Samsung S3C64xx SoCs,
- samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
found on Samsung Exynos4210 SoC.
- interrupt-parent: phandle of the interrupt parent to which the external

52
Documentation/devicetree/bindings/regulator/max8952.txt Normal file
View File

@ -0,0 +1,52 @@
Maxim MAX8952 voltage regulator
Required properties:
- compatible: must be equal to "maxim,max8952"
- reg: I2C slave address, usually 0x60
- max8952,dvs-mode-microvolt: array of 4 integer values defining DVS voltages
in microvolts. All values must be from range <770000, 1400000>
- any required generic properties defined in regulator.txt
Optional properties:
- max8952,vid-gpios: array of two GPIO pins used for DVS voltage selection
- max8952,en-gpio: GPIO used to control enable status of regulator
- max8952,default-mode: index of default DVS voltage, from <0, 3> range
- max8952,sync-freq: sync frequency, must be one of following values:
- 0: 26 MHz
- 1: 13 MHz
- 2: 19.2 MHz
Defaults to 26 MHz if not specified.
- max8952,ramp-speed: voltage ramp speed, must be one of following values:
- 0: 32mV/us
- 1: 16mV/us
- 2: 8mV/us
- 3: 4mV/us
- 4: 2mV/us
- 5: 1mV/us
- 6: 0.5mV/us
- 7: 0.25mV/us
Defaults to 32mV/us if not specified.
- any available generic properties defined in regulator.txt
Example:
vdd_arm_reg: pmic@60 {
compatible = "maxim,max8952";
reg = <0x60>;
/* max8952-specific properties */
max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
max8952,en-gpio = <&gpx0 1 0>;
max8952,default-mode = <0>;
max8952,dvs-mode-microvolt = <1250000>, <1200000>,
<1050000>, <950000>;
max8952,sync-freq = <0>;
max8952,ramp-speed = <0>;
/* generic regulator properties */
regulator-name = "vdd_arm";
regulator-min-microvolt = <770000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
};

15
Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt Normal file
View File

@ -0,0 +1,15 @@
Atmel AT91RM9200 Real Time Clock
Required properties:
- compatible: should be: "atmel,at91rm9200-rtc"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: rtc alarm/event interrupt
Example:
rtc@fffffe00 {
compatible = "atmel,at91rm9200-rtc";
reg = <0xfffffe00 0x100>;
interrupts = <1 4 7>;
};

22
Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt Normal file
View File

@ -0,0 +1,22 @@
Broadcom BCM2835 SPI0 controller
The BCM2835 contains two forms of SPI master controller, one known simply as
SPI0, and the other known as the "Universal SPI Master"; part of the
auxilliary block. This binding applies to the SPI0 controller.
Required properties:
- compatible: Should be "brcm,bcm2835-spi".
- reg: Should contain register location and length.
- interrupts: Should contain interrupt.
- clocks: The clock feeding the SPI controller.
Example:
spi@20204000 {
compatible = "brcm,bcm2835-spi";
reg = <0x7e204000 0x1000>;
interrupts = <2 22>;
clocks = <&clk_spi>;
#address-cells = <1>;
#size-cells = <0>;
};

3
Documentation/devicetree/bindings/spi/fsl-spi.txt
View File

@ -4,7 +4,7 @@ Required properties:
- cell-index : QE SPI subblock index.
0: QE subblock SPI1
1: QE subblock SPI2
- compatible : should be "fsl,spi".
- compatible : should be "fsl,spi" or "aeroflexgaisler,spictrl".
- mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
- reg : Offset and length of the register set for the device
- interrupts : <a b> where a is the interrupt number and b is a
@ -14,6 +14,7 @@ Required properties:
controller you have.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- clock-frequency : input clock frequency to non FSL_SOC cores
Optional properties:
- gpios : specifies the gpio pins to be used for chipselects.

26
Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt Normal file
View File

@ -0,0 +1,26 @@
NVIDIA Tegra114 SPI controller.
Required properties:
- compatible : should be "nvidia,tegra114-spi".
- reg: Should contain SPI registers location and length.
- interrupts: Should contain SPI interrupts.
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
request selector for this SPI controller.
- This is also require clock named "spi" as per binding document
Documentation/devicetree/bindings/clock/clock-bindings.txt
Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
Example:
spi@7000d600 {
compatible = "nvidia,tegra114-spi";
reg = <0x7000d600 0x200>;
interrupts = <0 82 0x04>;
nvidia,dma-request-selector = <&apbdma 16>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
};

8
Documentation/devicetree/bindings/spi/spi-samsung.txt
View File

@ -31,9 +31,6 @@ 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:
@ -86,9 +83,8 @@ Example:
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>;
pinctrl-names = "default";
pinctrl-0 = <&spi0_bus>;
w25q80bw@0 {
#address-cells = <1>;

15
Documentation/devicetree/bindings/staging/dwc2.txt Normal file
View File

@ -0,0 +1,15 @@
Platform DesignWare HS OTG USB 2.0 controller
-----------------------------------------------------
Required properties:
- compatible : "snps,dwc2"
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
Example:
usb@101c0000 {
compatible = "ralink,rt3050-usb, snps,dwc2";
reg = <0x101c0000 40000>;
interrupts = <18>;
};

2
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
View File

@ -26,7 +26,7 @@ Required properties:
- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
crtc. Currently supported types: "rgb24", "rgb565"
crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel

7
Documentation/devicetree/bindings/tty/serial/of-serial.txt
View File

@ -11,6 +11,9 @@ Required properties:
- "nvidia,tegra20-uart"
- "nxp,lpc3220-uart"
- "ibm,qpace-nwp-serial"
- "altr,16550-FIFO32"
- "altr,16550-FIFO64"
- "altr,16550-FIFO128"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
@ -30,6 +33,10 @@ Optional properties:
RTAS and should not be registered.
- no-loopback-test: set to indicate that the port does not implements loopback
test mode
- fifo-size: the fifo size of the UART.
- auto-flow-control: one way to enable automatic flow control support. The
driver is allowed to detect support for the capability even without this
property.
Example:

2
Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
View File

@ -11,6 +11,7 @@ Optional properties:
that indicate usb controller index
- vbus-supply: regulator for vbus
- disable-over-current: disable over current detect
- external-vbus-divider: enables off-chip resistor divider for Vbus
Examples:
usb@02184000 { /* USB OTG */
@ -20,4 +21,5 @@ usb@02184000 { /* USB OTG */
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
disable-over-current;
external-vbus-divider;
};

32
Documentation/devicetree/bindings/usb/ehci-omap.txt Normal file
View File

@ -0,0 +1,32 @@
OMAP HS USB EHCI controller
This device is usually the child of the omap-usb-host
Documentation/devicetree/bindings/mfd/omap-usb-host.txt
Required properties:
- compatible: should be "ti,ehci-omap"
- reg: should contain one register range i.e. start and length
- interrupts: description of the interrupt line
Optional properties:
- phys: list of phandles to PHY nodes.
This property is required if at least one of the ports are in
PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
To specify the port mode, see
Documentation/devicetree/bindings/mfd/omap-usb-host.txt
Example for OMAP4:
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap", "usb-ehci";
reg = <0x4a064c00 0x400>;
interrupts = <0 77 0x4>;
};
&usbhsehci {
phys = <&hsusb1_phy 0 &hsusb3_phy>;
};

15
Documentation/devicetree/bindings/usb/ohci-omap3.txt Normal file
View File

@ -0,0 +1,15 @@
OMAP HS USB OHCI controller (OMAP3 and later)
Required properties:
- compatible: should be "ti,ohci-omap3"
- reg: should contain one register range i.e. start and length
- interrupts: description of the interrupt line
Example for OMAP4:
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
reg = <0x4a064800 0x400>;
interrupts = <0 76 0x4>;
};

40
Documentation/devicetree/bindings/usb/omap-usb.txt
View File

@ -8,10 +8,10 @@ OMAP MUSB GLUE
and disconnect.
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num_eps : Specifies the number of endpoints. This is also a
- num-eps : Specifies the number of endpoints. This is also a
MUSB configuration-specific setting. Should be set to "16"
- ram_bits : Specifies the ram address size. Should be set to "12"
- interface_type : This is a board specific setting to describe the type of
- ram-bits : Specifies the ram address size. Should be set to "12"
- interface-type : This is a board specific setting to describe the type of
interface between the controller and the phy. It should be "0" or "1"
specifying ULPI and UTMI respectively.
- mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
@ -29,18 +29,46 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
ti,hwmods = "usb_otg_hs";
ti,has-mailbox;
multipoint = <1>;
num_eps = <16>;
ram_bits = <12>;
num-eps = <16>;
ram-bits = <12>;
ctrl-module = <&omap_control_usb>;
};
Board specific device node entry
&usb_otg_hs {
interface_type = <1>;
interface-type = <1>;
mode = <3>;
power = <50>;
};
OMAP DWC3 GLUE
- compatible : Should be "ti,dwc3"
- ti,hwmods : Should be "usb_otg_ss"
- reg : Address and length of the register set for the device.
- interrupts : The irq number of this device that is used to interrupt the
MPU
- #address-cells, #size-cells : Must be present if the device has sub-nodes
- utmi-mode : controls the source of UTMI/PIPE status for VBUS and OTG ID.
It should be set to "1" for HW mode and "2" for SW mode.
- ranges: the child address space are mapped 1:1 onto the parent address space
Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
The binding details of dwc3 can be found in:
Documentation/devicetree/bindings/usb/dwc3.txt
omap_dwc3 {
compatible = "ti,dwc3";
ti,hwmods = "usb_otg_ss";
reg = <0x4a020000 0x1ff>;
interrupts = <0 93 4>;
#address-cells = <1>;
#size-cells = <1>;
utmi-mode = <2>;
ranges;
};
OMAP CONTROL USB
Required properties:

76
Documentation/devicetree/bindings/usb/samsung-usbphy.txt
View File

@ -1,20 +1,25 @@
* Samsung's usb phy transceiver
SAMSUNG USB-PHY controllers
The Samsung's phy transceiver is used for controlling usb phy for
s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers
across Samsung SOCs.
** Samsung's usb 2.0 phy transceiver
The Samsung's usb 2.0 phy transceiver is used for controlling
usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
usb controllers across Samsung SOCs.
TODO: Adding the PHY binding with controller(s) according to the under
developement generic PHY driver.
Required properties:
Exynos4210:
- compatible : should be "samsung,exynos4210-usbphy"
- compatible : should be "samsung,exynos4210-usb2phy"
- reg : base physical address of the phy registers and length of memory mapped
region.
- clocks: Clock IDs array as required by the controller.
- clock-names: names of clock correseponding IDs clock property as requested
by the controller driver.
Exynos5250:
- compatible : should be "samsung,exynos5250-usbphy"
- compatible : should be "samsung,exynos5250-usb2phy"
- reg : base physical address of the phy registers and length of memory mapped
region.
@ -44,12 +49,69 @@ Example:
usbphy@125B0000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "samsung,exynos4210-usbphy";
compatible = "samsung,exynos4210-usb2phy";
reg = <0x125B0000 0x100>;
ranges;
clocks = <&clock 2>, <&clock 305>;
clock-names = "xusbxti", "otg";
usbphy-sys {
/* USB device and host PHY_CONTROL registers */
reg = <0x10020704 0x8>;
};
};
** Samsung's usb 3.0 phy transceiver
Starting exynso5250, Samsung's SoC have usb 3.0 phy transceiver
which is used for controlling usb 3.0 phy for dwc3-exynos usb 3.0
controllers across Samsung SOCs.
Required properties:
Exynos5250:
- compatible : should be "samsung,exynos5250-usb3phy"
- reg : base physical address of the phy registers and length of memory mapped
region.
- clocks: Clock IDs array as required by the controller.
- clock-names: names of clocks correseponding to IDs in the clock property
as requested by the controller driver.
Optional properties:
- #address-cells: should be '1' when usbphy node has a child node with 'reg'
property.
- #size-cells: should be '1' when usbphy node has a child node with 'reg'
property.
- ranges: allows valid translation between child's address space and parent's
address space.
- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
interface for usb-phy. It should provide the following information required by
usb-phy controller to control phy.
- reg : base physical address of PHY_CONTROL registers.
The size of this register is the total sum of size of all PHY_CONTROL
registers that the SoC has. For example, the size will be
'0x4' in case we have only one PHY_CONTROL register (e.g.
OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
and, '0x8' in case we have two PHY_CONTROL registers (e.g.
USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
and so on.
Example:
usbphy@12100000 {
compatible = "samsung,exynos5250-usb3phy";
reg = <0x12100000 0x100>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
clocks = <&clock 1>, <&clock 286>;
clock-names = "ext_xtal", "usbdrd30";
usbphy-sys {
/* USB device and host PHY_CONTROL registers */
reg = <0x10040704 0x8>;
};
};

34
Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt Normal file
View File

@ -0,0 +1,34 @@
USB NOP PHY
Required properties:
- compatible: should be usb-nop-xceiv
Optional properties:
- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
/bindings/clock/clock-bindings.txt
This property is required if clock-frequency is specified.
- clock-names: Should be "main_clk"
- clock-frequency: the clock frequency (in Hz) that the PHY clock must
be configured to.
- vcc-supply: phandle to the regulator that provides RESET to the PHY.
- reset-supply: phandle to the regulator that provides power to the PHY.
Example:
hsusb1_phy {
compatible = "usb-nop-xceiv";
clock-frequency = <19200000>;
clocks = <&osc 0>;
clock-names = "main_clk";
vcc-supply = <&hsusb1_vcc_regulator>;
reset-supply = <&hsusb1_reset_regulator>;
};
hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
controls RESET.

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

@ -5,6 +5,7 @@ using them to avoid name-space collisions.
ad Avionic Design GmbH
adi Analog Devices, Inc.
aeroflexgaisler Aeroflex Gaisler AB
ak Asahi Kasei Corp.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)
@ -48,6 +49,7 @@ samsung Samsung Semiconductor
sbs Smart Battery System
schindler Schindler
sil Silicon Image
silabs Silicon Laboratories
simtek
sirf SiRF Technology, Inc.
snps Synopsys, Inc.

41
Documentation/devicetree/bindings/video/backlight/lp855x.txt Normal file
View File

@ -0,0 +1,41 @@
lp855x bindings
Required properties:
- compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
"ti,lp8556", "ti,lp8557"
- reg: I2C slave address (u8)
- dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
Optional properties:
- bl-name: Backlight device name (string)
- init-brt: Initial value of backlight brightness (u8)
- pwm-period: PWM period value. Set only PWM input mode used (u32)
- rom-addr: Register address of ROM area to be updated (u8)
- rom-val: Register value to be updated (u8)
Example:
/* LP8556 */
backlight@2c {
compatible = "ti,lp8556";
reg = <0x2c>;
bl-name = "lcd-bl";
dev-ctrl = /bits/ 8 <0x85>;
init-brt = /bits/ 8 <0x10>;
};
/* LP8557 */
backlight@2c {
compatible = "ti,lp8557";
reg = <0x2c>;
dev-ctrl = /bits/ 8 <0x41>;
init-brt = /bits/ 8 <0x0a>;
/* 4V OV, 4 output LED string enabled */
rom_14h {
rom-addr = /bits/ 8 <0x14>;
rom-val = /bits/ 8 <0xcf>;
};
};

27
Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt Normal file
View File

@ -0,0 +1,27 @@
TPS65217 family of regulators
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights.
Required properties:
- compatible: "ti,tps65217"
- reg: I2C slave address
- backlight: node for specifying WLED1 and WLED2 lines in TPS65217
- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level)
- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000
- default-brightness: valid values: 0-100
Each regulator is defined using the standard binding for regulators.
Example:
tps: tps@24 {
reg = <0x24>;
compatible = "ti,tps65217";
backlight {
isel = <1>; /* 1 - ISET1, 2 ISET2 */
fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
default-brightness = <50>;
};
};

48
Documentation/devicetree/bindings/video/via,vt8500-fb.txt
View File

@ -5,58 +5,32 @@ Required properties:
- compatible : "via,vt8500-fb"
- reg : Should contain 1 register ranges(address and length)
- interrupts : framebuffer controller interrupt
- display: a phandle pointing to the display node
- bits-per-pixel : bit depth of framebuffer (16 or 32)
Required nodes:
- display: a display node is required to initialize the lcd panel
This should be in the board dts.
- default-mode: a videomode within the display with timing parameters
as specified below.
Required subnodes:
- display-timings: see display-timing.txt for information
Example:
fb@d800e400 {
fb@d8050800 {
compatible = "via,vt8500-fb";
reg = <0xd800e400 0x400>;
interrupts = <12>;
display = <&display>;
default-mode = <&mode0>;
};
bits-per-pixel = <16>;
VIA VT8500 Display
-----------------------------------------------------
Required properties (as per of_videomode_helper):
- hactive, vactive: Display resolution
- hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
in pixels
vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
lines
- clock: displayclock in Hz
- bpp: lcd panel bit-depth.
<16> for RGB565, <32> for RGB888
Optional properties (as per of_videomode_helper):
- width-mm, height-mm: Display dimensions in mm
- hsync-active-high (bool): Hsync pulse is active high
- vsync-active-high (bool): Vsync pulse is active high
- interlaced (bool): This is an interlaced mode
- doublescan (bool): This is a doublescan mode
Example:
display: display@0 {
modes {
mode0: mode@0 {
display-timings {
native-mode = <&timing0>;
timing0: 800x480 {
clock-frequency = <0>; /* unused but required */
hactive = <800>;
vactive = <480>;
hback-porch = <88>;
hfront-porch = <40>;
hback-porch = <88>;
hsync-len = <0>;
vback-porch = <32>;
vfront-porch = <11>;
vsync-len = <1>;
clock = <0>; /* unused but required */
bpp = <16>; /* non-standard but required */
};
};
};

32
Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
View File

@ -4,20 +4,30 @@ Wondermedia WM8505 Framebuffer
Required properties:
- compatible : "wm,wm8505-fb"
- reg : Should contain 1 register ranges(address and length)
- via,display: a phandle pointing to the display node
- bits-per-pixel : bit depth of framebuffer (16 or 32)
Required nodes:
- display: a display node is required to initialize the lcd panel
This should be in the board dts. See definition in
Documentation/devicetree/bindings/video/via,vt8500-fb.txt
- default-mode: a videomode node as specified in
Documentation/devicetree/bindings/video/via,vt8500-fb.txt
Required subnodes:
- display-timings: see display-timing.txt for information
Example:
fb@d8050800 {
fb@d8051700 {
compatible = "wm,wm8505-fb";
reg = <0xd8050800 0x200>;
display = <&display>;
default-mode = <&mode0>;
reg = <0xd8051700 0x200>;
bits-per-pixel = <16>;
display-timings {
native-mode = <&timing0>;
timing0: 800x480 {
clock-frequency = <0>; /* unused but required */
hactive = <800>;
vactive = <480>;
hfront-porch = <40>;
hback-porch = <88>;
hsync-len = <0>;
vback-porch = <32>;
vfront-porch = <11>;
vsync-len = <1>;
};
};
};

26
Documentation/filesystems/vfat.txt
View File

@ -150,12 +150,28 @@ discard -- If set, issues discard/TRIM commands to the block
device when blocks are freed. This is useful for SSD devices
and sparse/thinly-provisoned LUNs.
nfs -- This option maintains an index (cache) of directory
inodes by i_logstart which is used by the nfs-related code to
improve look-ups.
nfs=stale_rw|nostale_ro
Enable this only if you want to export the FAT filesystem
over NFS.
stale_rw: This option maintains an index (cache) of directory
inodes by i_logstart which is used by the nfs-related code to
improve look-ups. Full file operations (read/write) over NFS is
supported but with cache eviction at NFS server, this could
result in ESTALE issues.
nostale_ro: This option bases the inode number and filehandle
on the on-disk location of a file in the MS-DOS directory entry.
This ensures that ESTALE will not be returned after a file is
evicted from the inode cache. However, it means that operations
such as rename, create and unlink could cause filehandles that
previously pointed at one file to point at a different file,
potentially causing data corruption. For this reason, this
option also mounts the filesystem readonly.
To maintain backward compatibility, '-o nfs' is also accepted,
defaulting to stale_rw
Enable this only if you want to export the FAT filesystem
over NFS
<bool>: 0,1,yes,no,true,false

2
Documentation/hwmon/adm1275
View File

@ -15,7 +15,7 @@ Supported chips:
Addresses scanned: -
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

50
Documentation/hwmon/adt7410
View File

@ -4,28 +4,50 @@ Kernel driver adt7410
Supported chips:
* Analog Devices ADT7410
Prefix: 'adt7410'
Addresses scanned: I2C 0x48 - 0x4B
Addresses scanned: None
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf
* Analog Devices ADT7420
Prefix: 'adt7420'
Addresses scanned: None
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf
* Analog Devices ADT7310
Prefix: 'adt7310'
Addresses scanned: None
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf
* Analog Devices ADT7320
Prefix: 'adt7320'
Addresses scanned: None
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf
Author: Hartmut Knaack <knaack.h@gmx.de>
Description
-----------
The ADT7410 is a temperature sensor with rated temperature range of -55°C to
+150°C. It has a high accuracy of +/-0.5°C and can be operated at a resolution
of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an INT pin to
indicate that a minimum or maximum temperature set point has been exceeded, as
well as a critical temperature (CT) pin to indicate that the critical
temperature set point has been exceeded. Both pins can be set up with a common
hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events. Both
pins can individually set to be active-low or active-high, while the whole
device can either run in comparator mode or interrupt mode. The ADT7410
supports continous temperature sampling, as well as sampling one temperature
value per second or even justget one sample on demand for power saving.
Besides, it can completely power down its ADC, if power management is
required.
The ADT7310/ADT7410 is a temperature sensor with rated temperature range of
-55°C to +150°C. It has a high accuracy of +/-0.5°C and can be operated at a
resolution of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an
INT pin to indicate that a minimum or maximum temperature set point has been
exceeded, as well as a critical temperature (CT) pin to indicate that the
critical temperature set point has been exceeded. Both pins can be set up with a
common hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events.
Both pins can individually set to be active-low or active-high, while the whole
device can either run in comparator mode or interrupt mode. The ADT7410 supports
continuous temperature sampling, as well as sampling one temperature value per
second or even just get one sample on demand for power saving. Besides, it can
completely power down its ADC, if power management is required.
The ADT7320/ADT7420 is register compatible, the only differences being the
package, a slightly narrower operating temperature range (-40°C to +150°C), and
a better accuracy (0.25°C instead of 0.50°C.)
The difference between the ADT7310/ADT7320 and ADT7410/ADT7420 is the control
interface, the ADT7310 and ADT7320 use SPI while the ADT7410 and ADT7420 use
I2C.
Configuration Notes
-------------------

2
Documentation/hwmon/jc42
View File

@ -49,7 +49,7 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1f
Author:
Guenter Roeck <guenter.roeck@ericsson.com>
Guenter Roeck <linux@roeck-us.net>
Description

2
Documentation/hwmon/lineage-pem
View File

@ -8,7 +8,7 @@ Supported devices:
Documentation:
http://www.lineagepower.com/oem/pdf/CPLI2C.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

34
Documentation/hwmon/lm25066
View File

@ -1,7 +1,13 @@
Kernel driver max8688
Kernel driver lm25066
=====================
Supported chips:
* TI LM25056
Prefix: 'lm25056'
Addresses scanned: -
Datasheets:
http://www.ti.com/lit/gpn/lm25056
http://www.ti.com/lit/gpn/lm25056a
* National Semiconductor LM25066
Prefix: 'lm25066'
Addresses scanned: -
@ -19,14 +25,15 @@ Supported chips:
Datasheet:
http://www.national.com/pf/LM/LM5066.html
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
This driver supports hardware montoring for National Semiconductor LM25066,
LM5064, and LM5064 Power Management, Monitoring, Control, and Protection ICs.
This driver supports hardware montoring for National Semiconductor / TI LM25056,
LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and
Protection ICs.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
@ -60,14 +67,19 @@ in1_max Maximum input voltage.
in1_min_alarm Input voltage low alarm.
in1_max_alarm Input voltage high alarm.
in2_label "vout1"
in2_input Measured output voltage.
in2_average Average measured output voltage.
in2_min Minimum output voltage.
in2_min_alarm Output voltage low alarm.
in2_label "vmon"
in2_input Measured voltage on VAUX pin
in2_min Minimum VAUX voltage (LM25056 only).
in2_max Maximum VAUX voltage (LM25056 only).
in2_min_alarm VAUX voltage low alarm (LM25056 only).
in2_max_alarm VAUX voltage high alarm (LM25056 only).
in3_label "vout2"
in3_input Measured voltage on vaux pin
in3_label "vout1"
Not supported on LM25056.
in3_input Measured output voltage.
in3_average Average measured output voltage.
in3_min Minimum output voltage.
in3_min_alarm Output voltage low alarm.
curr1_label "iin"
curr1_input Measured input current.

2
Documentation/hwmon/lm75
View File

@ -23,7 +23,7 @@ Supported chips:
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/
* Microchip (TelCom) TCN75
Prefix: 'lm75'
Prefix: 'tcn75'
Addresses scanned: none
Datasheet: Publicly available at the Microchip website
http://www.microchip.com/

36
Documentation/hwmon/lm95234 Normal file
View File

@ -0,0 +1,36 @@
Kernel driver lm95234
=====================
Supported chips:
* National Semiconductor / Texas Instruments LM95234
Addresses scanned: I2C 0x18, 0x4d, 0x4e
Datasheet: Publicly available at the Texas Instruments website
http://www.ti.com/product/lm95234
Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
LM95234 is an 11-bit digital temperature sensor with a 2-wire System Management
Bus (SMBus) interface and TrueTherm technology that can very accurately monitor
the temperature of four remote diodes as well as its own temperature.
The four remote diodes can be external devices such as microprocessors,
graphics processors or diode-connected 2N3904s. The LM95234's TruTherm
beta compensation technology allows sensing of 90 nm or 65 nm process
thermal diodes accurately.
All temperature values are given in millidegrees Celsius. Temperature
is provided within a range of -127 to +255 degrees (+127.875 degrees for
the internal sensor). Resolution depends on temperature input and range.
Each sensor has its own maximum limit, but the hysteresis is common to all
channels. The hysteresis is configurable with the tem1_max_hyst attribute and
affects the hysteresis on all channels. The first two external sensors also
have a critical limit.
The lm95234 driver can change its update interval to a fixed set of values.
It will round up to the next selectable interval. See the datasheet for exact
values. Reading sensor values more often will do no harm, but will return
'old' values.

139
Documentation/hwmon/ltc2978
View File

@ -2,24 +2,32 @@ Kernel driver ltc2978
=====================
Supported chips:
* Linear Technology LTC2974
Prefix: 'ltc2974'
Addresses scanned: -
Datasheet: http://www.linear.com/product/ltc2974
* Linear Technology LTC2978
Prefix: 'ltc2978'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
Datasheet: http://www.linear.com/product/ltc2978
* Linear Technology LTC3880
Prefix: 'ltc3880'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/3880f.pdf
Datasheet: http://www.linear.com/product/ltc3880
* Linear Technology LTC3883
Prefix: 'ltc3883'
Addresses scanned: -
Datasheet: http://www.linear.com/product/ltc3883
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
The LTC2978 is an octal power supply monitor, supervisor, sequencer and
margin controller. The LTC3880 is a dual, PolyPhase DC/DC synchronous
step-down switching regulator controller.
LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883
is a single phase step-down DC/DC controller.
Usage Notes
@ -41,63 +49,90 @@ Sysfs attributes
in1_label "vin"
in1_input Measured input voltage.
in1_min Minimum input voltage.
in1_max Maximum input voltage.
in1_lcrit Critical minimum input voltage.
in1_max Maximum input voltage. LTC2974 and LTC2978 only.
in1_lcrit Critical minimum input voltage. LTC2974 and LTC2978
only.
in1_crit Critical maximum input voltage.
in1_min_alarm Input voltage low alarm.
in1_max_alarm Input voltage high alarm.
in1_lcrit_alarm Input voltage critical low alarm.
in1_max_alarm Input voltage high alarm. LTC2974 and LTC2978 only.
in1_lcrit_alarm Input voltage critical low alarm. LTC2974 and LTC2978
only.
in1_crit_alarm Input voltage critical high alarm.
in1_lowest Lowest input voltage. LTC2978 only.
in1_lowest Lowest input voltage. LTC2974 and LTC2978 only.
in1_highest Highest input voltage.
in1_reset_history Reset history. Writing into this attribute will reset
history for all attributes.
in1_reset_history Reset input voltage history.
in[2-9]_label "vout[1-8]". Channels 3 to 9 on LTC2978 only.
in[2-9]_input Measured output voltage.
in[2-9]_min Minimum output voltage.
in[2-9]_max Maximum output voltage.
in[2-9]_lcrit Critical minimum output voltage.
in[2-9]_crit Critical maximum output voltage.
in[2-9]_min_alarm Output voltage low alarm.
in[2-9]_max_alarm Output voltage high alarm.
in[2-9]_lcrit_alarm Output voltage critical low alarm.
in[2-9]_crit_alarm Output voltage critical high alarm.
in[2-9]_lowest Lowest output voltage. LTC2978 only.
in[2-9]_highest Lowest output voltage.
in[2-9]_reset_history Reset history. Writing into this attribute will reset
history for all attributes.
in[N]_label "vout[1-8]".
LTC2974: N=2-5
LTC2978: N=2-9
LTC3880: N=2-3
LTC3883: N=2
in[N]_input Measured output voltage.
in[N]_min Minimum output voltage.
in[N]_max Maximum output voltage.
in[N]_lcrit Critical minimum output voltage.
in[N]_crit Critical maximum output voltage.
in[N]_min_alarm Output voltage low alarm.
in[N]_max_alarm Output voltage high alarm.
in[N]_lcrit_alarm Output voltage critical low alarm.
in[N]_crit_alarm Output voltage critical high alarm.
in[N]_lowest Lowest output voltage. LTC2974 and LTC2978 only.
in[N]_highest Highest output voltage.
in[N]_reset_history Reset output voltage history.
temp[1-3]_input Measured temperature.
temp[N]_input Measured temperature.
On LTC2974, temp[1-4] report external temperatures,
and temp5 reports the chip temperature.
On LTC2978, only one temperature measurement is
supported and reflects the internal temperature.
supported and reports the chip temperature.
On LTC3880, temp1 and temp2 report external
temperatures, and temp3 reports the internal
temperature.
temp[1-3]_min Mimimum temperature.
temp[1-3]_max Maximum temperature.
temp[1-3]_lcrit Critical low temperature.
temp[1-3]_crit Critical high temperature.
temp[1-3]_min_alarm Chip temperature low alarm.
temp[1-3]_max_alarm Chip temperature high alarm.
temp[1-3]_lcrit_alarm Chip temperature critical low alarm.
temp[1-3]_crit_alarm Chip temperature critical high alarm.
temp[1-3]_lowest Lowest measured temperature. LTC2978 only.
temp[1-3]_highest Highest measured temperature.
temp[1-3]_reset_history Reset history. Writing into this attribute will reset
history for all attributes.
temperatures, and temp3 reports the chip temperature.
On LTC3883, temp1 reports an external temperature,
and temp2 reports the chip temperature.
temp[N]_min Mimimum temperature. LTC2974 and LTC2978 only.
temp[N]_max Maximum temperature.
temp[N]_lcrit Critical low temperature.
temp[N]_crit Critical high temperature.
temp[N]_min_alarm Temperature low alarm. LTC2974 and LTC2978 only.
temp[N]_max_alarm Temperature high alarm.
temp[N]_lcrit_alarm Temperature critical low alarm.
temp[N]_crit_alarm Temperature critical high alarm.
temp[N]_lowest Lowest measured temperature. LTC2974 and LTC2978 only.
Not supported for chip temperature sensor on LTC2974.
temp[N]_highest Highest measured temperature. Not supported for chip
temperature sensor on LTC2974.
temp[N]_reset_history Reset temperature history. Not supported for chip
temperature sensor on LTC2974.
power[1-2]_label "pout[1-2]". LTC3880 only.
power[1-2]_input Measured power.
power1_label "pin". LTC3883 only.
power1_input Measured input power.
curr1_label "iin". LTC3880 only.
power[N]_label "pout[1-4]".
LTC2974: N=1-4
LTC2978: Not supported
LTC3880: N=1-2
LTC3883: N=2
power[N]_input Measured output power.
curr1_label "iin". LTC3880 and LTC3883 only.
curr1_input Measured input current.
curr1_max Maximum input current.
curr1_max_alarm Input current high alarm.
curr1_highest Highest input current. LTC3883 only.
curr1_reset_history Reset input current history. LTC3883 only.
curr[2-3]_label "iout[1-2]". LTC3880 only.
curr[2-3]_input Measured input current.
curr[2-3]_max Maximum input current.
curr[2-3]_crit Critical input current.
curr[2-3]_max_alarm Input current high alarm.
curr[2-3]_crit_alarm Input current critical high alarm.
curr[N]_label "iout[1-4]".
LTC2974: N=1-4
LTC2978: not supported
LTC3880: N=2-3
LTC3883: N=2
curr[N]_input Measured output current.
curr[N]_max Maximum output current.
curr[N]_crit Critical high output current.
curr[N]_lcrit Critical low output current. LTC2974 only.
curr[N]_max_alarm Output current high alarm.
curr[N]_crit_alarm Output current critical high alarm.
curr[N]_lcrit_alarm Output current critical low alarm. LTC2974 only.
curr[N]_lowest Lowest output current. LTC2974 only.
curr[N]_highest Highest output current.
curr[N]_reset_history Reset output current history.

2
Documentation/hwmon/ltc4261
View File

@ -8,7 +8,7 @@ Supported chips:
Datasheet:
http://cds.linear.com/docs/Datasheet/42612fb.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

2
Documentation/hwmon/max16064
View File

@ -7,7 +7,7 @@ Supported chips:
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

2
Documentation/hwmon/max16065
View File

@ -24,7 +24,7 @@ Supported chips:
http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

2
Documentation/hwmon/max34440
View File

@ -27,7 +27,7 @@ Supported chips:
Addresses scanned: -
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

2
Documentation/hwmon/max8688
View File

@ -7,7 +7,7 @@ Supported chips:
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

188
Documentation/hwmon/nct6775 Normal file
View File

@ -0,0 +1,188 @@
Note
====
This driver supersedes the NCT6775F and NCT6776F support in the W83627EHF
driver.
Kernel driver NCT6775
=====================
Supported chips:
* Nuvoton NCT5572D/NCT6771F/NCT6772F/NCT6775F/W83677HG-I
Prefix: 'nct6775'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
* Nuvoton NCT5577D/NCT6776D/NCT6776F
Prefix: 'nct6776'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
* Nuvoton NCT5532D/NCT6779D
Prefix: 'nct6779'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
Authors:
Guenter Roeck <linux@roeck-us.net>
Description
-----------
This driver implements support for the Nuvoton NCT6775F, NCT6776F, and NCT6779D
and compatible super I/O chips.
The chips support up to 25 temperature monitoring sources. Up to 6 of those are
direct temperature sensor inputs, the others are special sources such as PECI,
PCH, and SMBUS. Depending on the chip type, 2 to 6 of the temperature sources
can be monitored and compared against minimum, maximum, and critical
temperatures. The driver reports up to 10 of the temperatures to the user.
There are 4 to 5 fan rotation speed sensors, 8 to 15 analog voltage sensors,
one VID, alarms with beep warnings (control unimplemented), and some automatic
fan regulation strategies (plus manual fan control mode).
The temperature sensor sources on all chips are configurable. The configured
source for each of the temperature sensors is provided in tempX_label.
Temperatures are measured in degrees Celsius and measurement resolution is
either 1 degC or 0.5 degC, depending on the temperature source and
configuration. An alarm is triggered when the temperature gets higher than
the high limit; it stays on until the temperature falls below the hysteresis
value. Alarms are only supported for temp1 to temp6, depending on the chip type.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. On
NCT6775F, fan readings can be divided by a programmable divider (1, 2, 4, 8,
16, 32, 64 or 128) to give the readings more range or accuracy; the other chips
do not have a fan speed divider. The driver sets the most suitable fan divisor
itself; specifically, it increases the divider value each time a fan speed
reading returns an invalid value, and it reduces it if the fan speed reading
is lower than optimal. Some fans might not be present because they share pins
with other functions.
Voltage sensors (also known as IN sensors) report their values in millivolts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit.
The driver supports automatic fan control mode known as Thermal Cruise.
In this mode, the chip attempts to keep the measured temperature in a
predefined temperature range. If the temperature goes out of range, fan
is driven slower/faster to reach the predefined range again.
The mode works for fan1-fan5.
sysfs attributes
----------------
pwm[1-5] - this file stores PWM duty cycle or DC value (fan speed) in range:
0 (lowest speed) to 255 (full)
pwm[1-5]_enable - this file controls mode of fan/temperature control:
* 0 Fan control disabled (fans set to maximum speed)
* 1 Manual mode, write to pwm[0-5] any value 0-255
* 2 "Thermal Cruise" mode
* 3 "Fan Speed Cruise" mode
* 4 "Smart Fan III" mode (NCT6775F only)
* 5 "Smart Fan IV" mode
pwm[1-5]_mode - controls if output is PWM or DC level
* 0 DC output
* 1 PWM output
Common fan control attributes
-----------------------------
pwm[1-5]_temp_sel Temperature source. Value is temperature sensor index.
For example, select '1' for temp1_input.
pwm[1-5]_weight_temp_sel
Secondary temperature source. Value is temperature
sensor index. For example, select '1' for temp1_input.
Set to 0 to disable secondary temperature control.
If secondary temperature functionality is enabled, it is controlled with the
following attributes.
pwm[1-5]_weight_duty_step
Duty step size.
pwm[1-5]_weight_temp_step
Temperature step size. With each step over
temp_step_base, the value of weight_duty_step is added
to the current pwm value.
pwm[1-5]_weight_temp_step_base
Temperature at which secondary temperature control kicks
in.
pwm[1-5]_weight_temp_step_tol
Temperature step tolerance.
Thermal Cruise mode (2)
-----------------------
If the temperature is in the range defined by:
pwm[1-5]_target_temp Target temperature, unit millidegree Celsius
(range 0 - 127000)
pwm[1-5]_temp_tolerance
Target temperature tolerance, unit millidegree Celsius
there are no changes to fan speed. Once the temperature leaves the interval, fan
speed increases (if temperature is higher that desired) or decreases (if
temperature is lower than desired), using the following limits and time
intervals.
pwm[1-5]_start fan pwm start value (range 1 - 255), to start fan
when the temperature is above defined range.
pwm[1-5]_floor lowest fan pwm (range 0 - 255) if temperature is below
the defined range. If set to 0, the fan is expected to
stop if the temperature is below the defined range.
pwm[1-5]_step_up_time milliseconds before fan speed is increased
pwm[1-5]_step_down_time milliseconds before fan speed is decreased
pwm[1-5]_stop_time how many milliseconds must elapse to switch
corresponding fan off (when the temperature was below
defined range).
Speed Cruise mode (3)
---------------------
This modes tries to keep the fan speed constant.
fan[1-5]_target Target fan speed
fan[1-5]_tolerance
Target speed tolerance
Untested; use at your own risk.
Smart Fan IV mode (5)
---------------------
This mode offers multiple slopes to control the fan speed. The slopes can be
controlled by setting the pwm and temperature attributes. When the temperature
rises, the chip will calculate the DC/PWM output based on the current slope.
There are up to seven data points depending on the chip type. Subsequent data
points should be set to higher temperatures and higher pwm values to achieve
higher fan speeds with increasing temperature. The last data point reflects
critical temperature mode, in which the fans should run at full speed.
pwm[1-5]_auto_point[1-7]_pwm
pwm value to be set if temperature reaches matching
temperature range.
pwm[1-5]_auto_point[1-7]_temp
Temperature over which the matching pwm is enabled.
pwm[1-5]_temp_tolerance
Temperature tolerance, unit millidegree Celsius
pwm[1-5]_crit_temp_tolerance
Temperature tolerance for critical temperature,
unit millidegree Celsius
pwm[1-5]_step_up_time milliseconds before fan speed is increased
pwm[1-5]_step_down_time milliseconds before fan speed is decreased
Usage Notes
-----------
On various ASUS boards with NCT6776F, it appears that CPUTIN is not really
connected to anything and floats, or that it is connected to some non-standard
temperature measurement device. As a result, the temperature reported on CPUTIN
will not reflect a usable value. It often reports unreasonably high
temperatures, and in some cases the reported temperature declines if the actual
temperature increases (similar to the raw PECI temperature value - see PECI
specification for details). CPUTIN should therefore be be ignored on ASUS
boards. The CPU temperature on ASUS boards is reported from PECI 0.

2
Documentation/hwmon/pmbus
View File

@ -34,7 +34,7 @@ Supported chips:
Addresses scanned: -
Datasheet: n.a.
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

2
Documentation/hwmon/sht15
View File

@ -40,7 +40,7 @@ bits for humidity, or 12 bits for temperature and 8 bits for humidity.
The humidity calibration coefficients are programmed into an OTP memory on the
chip. These coefficients are used to internally calibrate the signals from the
sensors. Disabling the reload of those coefficients allows saving 10ms for each
measurement and decrease power consumption, while loosing on precision.
measurement and decrease power consumption, while losing on precision.
Some options may be set directly in the sht15_platform_data structure
or via sysfs attributes.

2
Documentation/hwmon/smm665
View File

@ -29,7 +29,7 @@ Supported chips:
http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf
http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Module Parameters

25
Documentation/hwmon/tmp401
View File

@ -8,8 +8,16 @@ Supported chips:
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html
* Texas Instruments TMP411
Prefix: 'tmp411'
Addresses scanned: I2C 0x4c
Addresses scanned: I2C 0x4c, 0x4d, 0x4e
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html
* Texas Instruments TMP431
Prefix: 'tmp431'
Addresses scanned: I2C 0x4c, 0x4d
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp431.html
* Texas Instruments TMP432
Prefix: 'tmp432'
Addresses scanned: I2C 0x4c, 0x4d
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp432.html
Authors:
Hans de Goede <hdegoede@redhat.com>
@ -18,19 +26,19 @@ Authors:
Description
-----------
This driver implements support for Texas Instruments TMP401 and
TMP411 chips. These chips implements one remote and one local
temperature sensor. Temperature is measured in degrees
This driver implements support for Texas Instruments TMP401, TMP411,
TMP431, and TMP432 chips. These chips implement one or two remote and
one local temperature sensors. Temperature is measured in degrees
Celsius. Resolution of the remote sensor is 0.0625 degree. Local
sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
supported by the driver so far, so using the default resolution of 0.5
degree).
The driver provides the common sysfs-interface for temperatures (see
/Documentation/hwmon/sysfs-interface under Temperatures).
Documentation/hwmon/sysfs-interface under Temperatures).
The TMP411 chip is compatible with TMP401. It provides some additional
features.
The TMP411 and TMP431 chips are compatible with TMP401. TMP411 provides
some additional features.
* Minimum and Maximum temperature measured since power-on, chip-reset
@ -40,3 +48,6 @@ features.
Exported via sysfs attribute temp_reset_history. Writing 1 to this
file triggers a reset.
TMP432 is compatible with TMP401 and TMP431. It supports two external
temperature sensors.

2
Documentation/hwmon/ucd9000
View File

@ -11,7 +11,7 @@ Supported chips:
http://focus.ti.com/lit/ds/symlink/ucd9090.pdf
http://focus.ti.com/lit/ds/symlink/ucd90910.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

2
Documentation/hwmon/ucd9200
View File

@ -15,7 +15,7 @@ Supported chips:
http://focus.ti.com/lit/ds/symlink/ucd9246.pdf
http://focus.ti.com/lit/ds/symlink/ucd9248.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description

4
Documentation/hwmon/zl6100
View File

@ -54,7 +54,7 @@ http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description
@ -125,7 +125,7 @@ in2_label "vmon"
in2_input Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
ZL9117M) pin. Reported voltage is 16x the voltage on the
pin (adjusted internally by the chip).
in2_lcrit Critical minumum VMON/VDRV Voltage.
in2_lcrit Critical minimum VMON/VDRV Voltage.
in2_crit Critical maximum VMON/VDRV voltage.
in2_lcrit_alarm VMON/VDRV voltage critical low alarm.
in2_crit_alarm VMON/VDRV voltage critical high alarm.

2
Documentation/i2c/busses/i2c-diolan-u2c
View File

@ -5,7 +5,7 @@ Supported adapters:
Documentation:
http://www.diolan.com/i2c/u2c12.html
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------

2
Documentation/ia64/err_inject.txt
View File

@ -882,7 +882,7 @@ int err_inj()
cpu=parameters[i].cpu;
k = cpu%64;
j = cpu/64;
mask[j]=1<<k;
mask[j] = 1UL << k;
if (sched_setaffinity(0, MASK_SIZE*8, mask)==-1) {
perror("Error sched_setaffinity:");

65
Documentation/input/alps.txt
View File

@ -3,10 +3,26 @@ ALPS Touchpad Protocol
Introduction
------------
Currently the ALPS touchpad driver supports five protocol versions in use by
ALPS touchpads, called versions 1, 2, 3, 4 and 5.
Currently the ALPS touchpad driver supports four protocol versions in use by
ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
protocol versions is contained in the following sections.
Since roughly mid-2010 several new ALPS touchpads have been released and
integrated into a variety of laptops and netbooks. These new touchpads
have enough behavior differences that the alps_model_data definition
table, describing the properties of the different versions, is no longer
adequate. The design choices were to re-define the alps_model_data
table, with the risk of regression testing existing devices, or isolate
the new devices outside of the alps_model_data table. The latter design
choice was made. The new touchpad signatures are named: "Rushmore",
"Pinnacle", and "Dolphin", which you will see in the alps.c code.
For the purposes of this document, this group of ALPS touchpads will
generically be called "new ALPS touchpads".
We experimented with probing the ACPI interface _HID (Hardware ID)/_CID
(Compatibility ID) definition as a way to uniquely identify the
different ALPS variants but there did not appear to be a 1:1 mapping.
In fact, it appeared to be an m:n mapping between the _HID and actual
hardware type.
Detection
---------
@ -20,9 +36,13 @@ If the E6 report is successful, the touchpad model is identified using the "E7
report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
matched against known models in the alps_model_data_array.
With protocol versions 3 and 4, the E7 report model signature is always
73-02-64. To differentiate between these versions, the response from the
"Enter Command Mode" sequence must be inspected as described below.
For older touchpads supporting protocol versions 3 and 4, the E7 report
model signature is always 73-02-64. To differentiate between these
versions, the response from the "Enter Command Mode" sequence must be
inspected as described below.
The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but
seem to be better differentiated by the EC Command Mode response.
Command Mode
------------
@ -47,6 +67,14 @@ address of the register being read, and the third contains the value of the
register. Registers are written by writing the value one nibble at a time
using the same encoding used for addresses.
For the new ALPS touchpads, the EC command is used to enter command
mode. The response in the new ALPS touchpads is significantly different,
and more important in determining the behavior. This code has been
separated from the original alps_model_data table and put in the
alps_identify function. For example, there seem to be two hardware init
sequences for the "Dolphin" touchpads as determined by the second byte
of the EC response.
Packet Format
-------------
@ -187,3 +215,28 @@ There are several things worth noting here.
well.
So far no v4 devices with tracksticks have been encountered.
ALPS Absolute Mode - Protocol Version 5
---------------------------------------
This is basically Protocol Version 3 but with different logic for packet
decode. It uses the same alps_process_touchpad_packet_v3 call with a
specialized decode_fields function pointer to correctly interpret the
packets. This appears to only be used by the Dolphin devices.
For single-touch, the 6-byte packet format is:
byte 0: 1 1 0 0 1 0 0 0
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
byte 2: 0 y6 y5 y4 y3 y2 y1 y0
byte 3: 0 M R L 1 m r l
byte 4: y10 y9 y8 y7 x10 x9 x8 x7
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
For mt, the format is:
byte 0: 1 1 1 n3 1 n2 n1 x24
byte 1: 1 y7 y6 y5 y4 y3 y2 y1
byte 2: ? x2 x1 y12 y11 y10 y9 y8
byte 3: 0 x23 x22 x21 x20 x19 x18 x17
byte 4: 0 x9 x8 x7 x6 x5 x4 x3
byte 5: 0 x16 x15 x14 x13 x12 x11 x10

1
Documentation/ioctl/ioctl-number.txt
View File

@ -131,6 +131,7 @@ Code Seq#(hex) Include File Comments
'H' 40-4F sound/hdspm.h conflict!
'H' 40-4F sound/hdsp.h conflict!
'H' 90 sound/usb/usx2y/usb_stream.h
'H' A0 uapi/linux/usb/cdc-wdm.h
'H' C0-F0 net/bluetooth/hci.h conflict!
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!

1
Documentation/kdump/kdump.txt
View File

@ -297,6 +297,7 @@ Boot into System Kernel
On ia64, 256M@256M is a generous value that typically works.
The region may be automatically placed on ia64, see the
dump-capture kernel config option notes above.
If use sparse memory, the size should be rounded to GRANULE boundaries.
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not

88
Documentation/kernel-parameters.txt
View File

@ -44,6 +44,7 @@ parameter is applicable:
AVR32 AVR32 architecture is enabled.
AX25 Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled.
CLK Common clock infrastructure is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@ -320,6 +321,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
on: enable for both 32- and 64-bit processes
off: disable for both 32- and 64-bit processes
alloc_snapshot [FTRACE]
Allocate the ftrace snapshot buffer on boot up when the
main buffer is allocated. This is handy if debugging
and you need to use tracing_snapshot() on boot up, and
do not want to use tracing_snapshot_alloc() as it needs
to be done where GFP_KERNEL allocations are allowed.
amd_iommu= [HW,X86-64]
Pass parameters to the AMD IOMMU driver in the system.
Possible values are:
@ -465,6 +473,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
cio_ignore= [S390]
See Documentation/s390/CommonIO for details.
clk_ignore_unused
[CLK]
Keep all clocks already enabled by bootloader on,
even if no driver has claimed them. This is useful
for debug and development, but should not be
needed on a platform with proper driver support.
For more information, see Documentation/clk.txt.
clock= [BUGS=X86-32, HW] gettimeofday clocksource override.
[Deprecated]
@ -596,9 +611,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
is selected automatically. Check
Documentation/kdump/kdump.txt for further details.
crashkernel_low=size[KMG]
[KNL, x86] parts under 4G.
crashkernel=range1:size1[,range2:size2,...][@offset]
[KNL] Same as above, but depends on the memory
in the running system. The syntax of range is
@ -606,6 +618,26 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
a memory unit (amount[KMG]). See also
Documentation/kdump/kdump.txt for an example.
crashkernel=size[KMG],high
[KNL, x86_64] range could be above 4G. Allow kernel
to allocate physical memory region from top, so could
be above 4G if system have more than 4G ram installed.
Otherwise memory region will be allocated below 4G, if
available.
It will be ignored if crashkernel=X is specified.
crashkernel=size[KMG],low
[KNL, x86_64] range under 4G. When crashkernel=X,high
is passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
requires at least 64M+32K low memory. Kernel would
try to allocate 72M below 4G automatically.
This one let user to specify own low range under 4G
for second kernel instead.
0: to disable low allocation.
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
cs89x0_dma= [HW,NET]
Format: <dma>
@ -788,6 +820,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
edd= [EDD]
Format: {"off" | "on" | "skip[mbr]"}
efi_no_storage_paranoia [EFI; X86]
Using this parameter you can use more than 50% of
your efi variable storage. Use this parameter only if
you are really sure that your UEFI does sane gc and
fulfills the spec otherwise your board may brick.
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
@ -2469,9 +2507,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
the specified list of CPUs to be no-callback CPUs.
Invocation of these CPUs' RCU callbacks will
be offloaded to "rcuoN" kthreads created for
that purpose. This reduces OS jitter on the
be offloaded to "rcuox/N" kthreads created for
that purpose, where "x" is "b" for RCU-bh, "p"
for RCU-preempt, and "s" for RCU-sched, and "N"
is the CPU number. This reduces OS jitter on the
offloaded CPUs, which can be useful for HPC and
real-time workloads. It can also improve energy
efficiency for asymmetric multiprocessors.
@ -2495,6 +2536,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
leaf rcu_node structure. Useful for very large
systems.
rcutree.jiffies_till_first_fqs= [KNL,BOOT]
Set delay from grace-period initialization to
first attempt to force quiescent states.
Units are jiffies, minimum value is zero,
and maximum value is HZ.
rcutree.jiffies_till_next_fqs= [KNL,BOOT]
Set delay between subsequent attempts to force
quiescent states. Units are jiffies, minimum
value is one, and maximum value is HZ.
rcutree.qhimark= [KNL,BOOT]
Set threshold of queued
RCU callbacks over which batch limiting is disabled.
@ -2509,16 +2561,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
Set timeout for RCU CPU stall warning messages.
rcutree.jiffies_till_first_fqs= [KNL,BOOT]
Set delay from grace-period initialization to
first attempt to force quiescent states.
Units are jiffies, minimum value is zero,
and maximum value is HZ.
rcutree.rcu_idle_gp_delay= [KNL,BOOT]
Set wakeup interval for idle CPUs that have
RCU callbacks (RCU_FAST_NO_HZ=y).
rcutree.jiffies_till_next_fqs= [KNL,BOOT]
Set delay between subsequent attempts to force
quiescent states. Units are jiffies, minimum
value is one, and maximum value is HZ.
rcutree.rcu_idle_lazy_gp_delay= [KNL,BOOT]
Set wakeup interval for idle CPUs that have
only "lazy" RCU callbacks (RCU_FAST_NO_HZ=y).
Lazy RCU callbacks are those which RCU can
prove do nothing more than free memory.
rcutorture.fqs_duration= [KNL,BOOT]
Set duration of force_quiescent_state bursts.
@ -3230,6 +3281,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
or other driver-specific files in the
Documentation/watchdog/ directory.
workqueue.disable_numa
By default, all work items queued to unbound
workqueues are affine to the NUMA nodes they're
issued on, which results in better behavior in
general. If NUMA affinity needs to be disabled for
whatever reason, this option can be used. Note
that this also can be controlled per-workqueue for
workqueues visible under /sys/bus/workqueue/.
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
default x2apic cluster mode on platforms
supporting x2apic.

138
Documentation/misc-devices/mei/mei-client-bus.txt Normal file
View File

@ -0,0 +1,138 @@
Intel(R) Management Engine (ME) Client bus API
===============================================
Rationale
=========
MEI misc character device is useful for dedicated applications to send and receive
data to the many FW appliance found in Intel's ME from the user space.
However for some of the ME functionalities it make sense to leverage existing software
stack and expose them through existing kernel subsystems.
In order to plug seamlessly into the kernel device driver model we add kernel virtual
bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers
for the various MEI features as a stand alone entities found in their respective subsystem.
Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to
the existing code.
MEI CL bus API
===========
A driver implementation for an MEI Client is very similar to existing bus
based device drivers. The driver registers itself as an MEI CL bus driver through
the mei_cl_driver structure:
struct mei_cl_driver {
struct device_driver driver;
const char *name;
const struct mei_cl_device_id *id_table;
int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
int (*remove)(struct mei_cl_device *dev);
};
struct mei_cl_id {
char name[MEI_NAME_SIZE];
kernel_ulong_t driver_info;
};
The mei_cl_id structure allows the driver to bind itself against a device name.
To actually register a driver on the ME Client bus one must call the mei_cl_add_driver()
API. This is typically called at module init time.
Once registered on the ME Client bus, a driver will typically try to do some I/O on
this bus and this should be done through the mei_cl_send() and mei_cl_recv()
routines. The latter is synchronous (blocks and sleeps until data shows up).
In order for drivers to be notified of pending events waiting for them (e.g.
an Rx event) they can register an event handler through the
mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event
will trigger an event handler call and the driver implementation is supposed
to call mei_recv() from the event handler in order to fetch the pending
received buffers.
Example
=======
As a theoretical example let's pretend the ME comes with a "contact" NFC IP.
The driver init and exit routines for this device would look like:
#define CONTACT_DRIVER_NAME "contact"
static struct mei_cl_device_id contact_mei_cl_tbl[] = {
{ CONTACT_DRIVER_NAME, },
/* required last entry */
{ }
};
MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
static struct mei_cl_driver contact_driver = {
.id_table = contact_mei_tbl,
.name = CONTACT_DRIVER_NAME,
.probe = contact_probe,
.remove = contact_remove,
};
static int contact_init(void)
{
int r;
r = mei_cl_driver_register(&contact_driver);
if (r) {
pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
return r;
}
return 0;
}
static void __exit contact_exit(void)
{
mei_cl_driver_unregister(&contact_driver);
}
module_init(contact_init);
module_exit(contact_exit);
And the driver's simplified probe routine would look like that:
int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
{
struct contact_driver *contact;
[...]
mei_cl_enable_device(dev);
mei_cl_register_event_cb(dev, contact_event_cb, contact);
return 0;
}
In the probe routine the driver first enable the MEI device and then registers
an ME bus event handler which is as close as it can get to registering a
threaded IRQ handler.
The handler implementation will typically call some I/O routine depending on
the pending events:
#define MAX_NFC_PAYLOAD 128
static void contact_event_cb(struct mei_cl_device *dev, u32 events,
void *context)
{
struct contact_driver *contact = context;
if (events & BIT(MEI_EVENT_RX)) {
u8 payload[MAX_NFC_PAYLOAD];
int payload_size;
payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
if (payload_size <= 0)
return;
/* Hook to the NFC subsystem */
nfc_hci_recv_frame(contact->hdev, payload, payload_size);
}
}

7
Documentation/networking/ipvs-sysctl.txt
View File

@ -15,6 +15,13 @@ amemthresh - INTEGER
enabled and the variable is automatically set to 2, otherwise
the strategy is disabled and the variable is set to 1.
backup_only - BOOLEAN
0 - disabled (default)
not 0 - enabled
If set, disable the director function while the server is
in backup mode to avoid packet loops for DR/TUN methods.
conntrack - BOOLEAN
0 - disabled (default)
not 0 - enabled

77
Documentation/networking/tuntap.txt
View File

@ -105,6 +105,83 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
Proto [2 bytes]
Raw protocol(IP, IPv6, etc) frame.
3.3 Multiqueue tuntap interface:
From version 3.8, Linux supports multiqueue tuntap which can uses multiple
file descriptors (queues) to parallelize packets sending or receiving. The
device allocation is the same as before, and if user wants to create multiple
queues, TUNSETIFF with the same device name must be called many times with
IFF_MULTI_QUEUE flag.
char *dev should be the name of the device, queues is the number of queues to
be created, fds is used to store and return the file descriptors (queues)
created to the caller. Each file descriptor were served as the interface of a
queue which could be accessed by userspace.
#include <linux/if.h>
#include <linux/if_tun.h>
int tun_alloc_mq(char *dev, int queues, int *fds)
{
struct ifreq ifr;
int fd, err, i;
if (!dev)
return -1;
memset(&ifr, 0, sizeof(ifr));
/* Flags: IFF_TUN - TUN device (no Ethernet headers)
* IFF_TAP - TAP device
*
* IFF_NO_PI - Do not provide packet information
* IFF_MULTI_QUEUE - Create a queue of multiqueue device
*/
ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE;
strcpy(ifr.ifr_name, dev);
for (i = 0; i < queues; i++) {
if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
goto err;
err = ioctl(fd, TUNSETIFF, (void *)&ifr);
if (err) {
close(fd);
goto err;
}
fds[i] = fd;
}
return 0;
err:
for (--i; i >= 0; i--)
close(fds[i]);
return err;
}
A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When
calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when
calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were
enabled by default after it was created through TUNSETIFF.
fd is the file descriptor (queue) that we want to enable or disable, when
enable is true we enable it, otherwise we disable it
#include <linux/if.h>
#include <linux/if_tun.h>
int tun_set_queue(int fd, int enable)
{
struct ifreq ifr;
memset(&ifr, 0, sizeof(ifr));
if (enable)
ifr.ifr_flags = IFF_ATTACH_QUEUE;
else
ifr.ifr_flags = IFF_DETACH_QUEUE;
return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
}
Universal TUN/TAP device driver Frequently Asked Question.
1. What platforms are supported by TUN/TAP driver ?

112
Documentation/pinctrl.txt
View File

@ -736,6 +736,13 @@ All the above functions are mandatory to implement for a pinmux driver.
Pin control interaction with the GPIO subsystem
===============================================
Note that the following implies that the use case is to use a certain pin
from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
and similar functions. There are cases where you may be using something
that your datasheet calls "GPIO mode" but actually is just an electrical
configuration for a certain device. See the section below named
"GPIO mode pitfalls" for more details on this scenario.
The public pinmux API contains two functions named pinctrl_request_gpio()
and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
gpiolib-based drivers as part of their gpio_request() and
@ -774,6 +781,111 @@ obtain the function "gpioN" where "N" is the global GPIO pin number if no
special GPIO-handler is registered.
GPIO mode pitfalls
==================
Sometime the developer may be confused by a datasheet talking about a pin
being possible to set into "GPIO mode". It appears that what hardware
engineers mean with "GPIO mode" is not necessarily the use case that is
implied in the kernel interface <linux/gpio.h>: a pin that you grab from
kernel code and then either listen for input or drive high/low to
assert/deassert some external line.
Rather hardware engineers think that "GPIO mode" means that you can
software-control a few electrical properties of the pin that you would
not be able to control if the pin was in some other mode, such as muxed in
for a device.
Example: a pin is usually muxed in to be used as a UART TX line. But during
system sleep, we need to put this pin into "GPIO mode" and ground it.
If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
to think that you need to come up with something real complex, that the
pin shall be used for UART TX and GPIO at the same time, that you will grab
a pin control handle and set it to a certain state to enable UART TX to be
muxed in, then twist it over to GPIO mode and use gpio_direction_output()
to drive it low during sleep, then mux it over to UART TX again when you
wake up and maybe even gpio_request/gpio_free as part of this cycle. This
all gets very complicated.
The solution is to not think that what the datasheet calls "GPIO mode"
has to be handled by the <linux/gpio.h> interface. Instead view this as
a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
and you find this in the documentation:
PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
1 to indicate high level, argument 0 to indicate low level.
So it is perfectly possible to push a pin into "GPIO mode" and drive the
line low as part of the usual pin control map. So for example your UART
driver may look like this:
#include <linux/pinctrl/consumer.h>
struct pinctrl *pinctrl;
struct pinctrl_state *pins_default;
struct pinctrl_state *pins_sleep;
pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
/* Normal mode */
retval = pinctrl_select_state(pinctrl, pins_default);
/* Sleep mode */
retval = pinctrl_select_state(pinctrl, pins_sleep);
And your machine configuration may look like this:
--------------------------------------------------
static unsigned long uart_default_mode[] = {
PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
};
static unsigned long uart_sleep_mode[] = {
PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
};
static struct pinctrl_map __initdata pinmap[] = {
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
"u0_group", "u0"),
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
"UART_TX_PIN", uart_default_mode),
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
"u0_group", "gpio-mode"),
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
"UART_TX_PIN", uart_sleep_mode),
};
foo_init(void) {
pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
}
Here the pins we want to control are in the "u0_group" and there is some
function called "u0" that can be enabled on this group of pins, and then
everything is UART business as usual. But there is also some function
named "gpio-mode" that can be mapped onto the same pins to move them into
GPIO mode.
This will give the desired effect without any bogus interaction with the
GPIO subsystem. It is just an electrical configuration used by that device
when going to sleep, it might imply that the pin is set into something the
datasheet calls "GPIO mode" but that is not the point: it is still used
by that UART device to control the pins that pertain to that very UART
driver, putting them into modes needed by the UART. GPIO in the Linux
kernel sense are just some 1-bit line, and is a different use case.
How the registers are poked to attain the push/pull and output low
configuration and the muxing of the "u0" or "gpio-mode" group onto these
pins is a question for the driver.
Some datasheets will be more helpful and refer to the "GPIO mode" as
"low power mode" rather than anything to do with GPIO. This often means
the same thing electrically speaking, but in this latter case the
software engineers will usually quickly identify that this is some
specific muxing/configuration rather than anything related to the GPIO
API.
Board/machine configuration
==================================

25
Documentation/power/opp.txt
View File

@ -1,6 +1,5 @@
*=============*
* OPP Library *
*=============*
Operating Performance Points (OPP) Library
==========================================
(C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
@ -16,15 +15,31 @@ Contents
1. Introduction
===============
1.1 What is an Operating Performance Point (OPP)?
Complex SoCs of today consists of a multiple sub-modules working in conjunction.
In an operational system executing varied use cases, not all modules in the SoC
need to function at their highest performing frequency all the time. To
facilitate this, sub-modules in a SoC are grouped into domains, allowing some
domains to run at lower voltage and frequency while other domains are loaded
more. The set of discrete tuples consisting of frequency and voltage pairs that
domains to run at lower voltage and frequency while other domains run at
voltage/frequency pairs that are higher.
The set of discrete tuples consisting of frequency and voltage pairs that
the device will support per domain are called Operating Performance Points or
OPPs.
As an example:
Let us consider an MPU device which supports the following:
{300MHz at minimum voltage of 1V}, {800MHz at minimum voltage of 1.2V},
{1GHz at minimum voltage of 1.3V}
We can represent these as three OPPs as the following {Hz, uV} tuples:
{300000000, 1000000}
{800000000, 1200000}
{1000000000, 1300000}
1.2 Operating Performance Points Library
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/base/power/opp.c and the header
is located in include/linux/opp.h. OPP library can be enabled by enabling

2
Documentation/printk-formats.txt
View File

@ -170,5 +170,5 @@ Reminder: sizeof() result is of type size_t.
Thank you for your cooperation and attention.
By Randy Dunlap <rdunlap@xenotime.net> and
By Randy Dunlap <rdunlap@infradead.org> and
Andrew Murray <amurray@mpc-data.co.uk>

3
Documentation/s390/s390dbf.txt
View File

@ -143,7 +143,8 @@ Parameter: id: handle for debug log
Return Value: none
Description: frees memory for a debug log
Description: frees memory for a debug log and removes all registered debug
views.
Must not be called within an interrupt handler
---------------------------------------------------------------------------

2
Documentation/scsi/LICENSE.qla2xxx
View File

@ -1,4 +1,4 @@
Copyright (c) 2003-2012 QLogic Corporation
Copyright (c) 2003-2013 QLogic Corporation
QLogic Linux FC-FCoE Driver
This program includes a device driver for Linux 3.x.

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

@ -890,9 +890,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
power_save - Automatic power-saving timeout (in second, 0 =
disable)
power_save_controller - Support runtime D3 of HD-audio controller
(-1 = on for supported chip (default), false = off,
true = force to on even for unsupported hardware)
power_save_controller - Reset HD-audio controller in power-saving mode
(default = on)
align_buffer_size - Force rounding of buffer/period sizes to multiples
of 128 bytes. This is more efficient in terms of memory
access but isn't required by the HDA spec and prevents
@ -912,7 +911,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
models depending on the codec chip. The list of available models
is found in HD-Audio-Models.txt
The model name "genric" is treated as a special case. When this
The model name "generic" is treated as a special case. When this
model is given, the driver uses the generic codec parser without
"codec-patch". It's sometimes good for testing and debugging.

2
Documentation/sound/alsa/seq_oss.html
View File

@ -285,7 +285,7 @@ sample data.
<H4>
7.2.4 Close Callback</H4>
The <TT>close</TT> callback is called when this device is closed by the
applicaion. If any private data was allocated in open callback, it must
application. If any private data was allocated in open callback, it must
be released in the close callback. The deletion of ALSA port should be
done here, too. This callback must not be NULL.
<H4>

50
Documentation/sysctl/vm.txt
View File

@ -18,6 +18,7 @@ files can be found in mm/swap.c.
Currently, these files are in /proc/sys/vm:
- admin_reserve_kbytes
- block_dump
- compact_memory
- dirty_background_bytes
@ -53,11 +54,41 @@ Currently, these files are in /proc/sys/vm:
- percpu_pagelist_fraction
- stat_interval
- swappiness
- user_reserve_kbytes
- vfs_cache_pressure
- zone_reclaim_mode
==============================================================
admin_reserve_kbytes
The amount of free memory in the system that should be reserved for users
with the capability cap_sys_admin.
admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
That should provide enough for the admin to log in and kill a process,
if necessary, under the default overcommit 'guess' mode.
Systems running under overcommit 'never' should increase this to account
for the full Virtual Memory Size of programs used to recover. Otherwise,
root may not be able to log in to recover the system.
How do you calculate a minimum useful reserve?
sshd or login + bash (or some other shell) + top (or ps, kill, etc.)
For overcommit 'guess', we can sum resident set sizes (RSS).
On x86_64 this is about 8MB.
For overcommit 'never', we can take the max of their virtual sizes (VSZ)
and add the sum of their RSS.
On x86_64 this is about 128MB.
Changing this takes effect whenever an application requests memory.
==============================================================
block_dump
block_dump enables block I/O debugging when set to a nonzero value. More
@ -542,6 +573,7 @@ memory until it actually runs out.
When this flag is 2, the kernel uses a "never overcommit"
policy that attempts to prevent any overcommit of memory.
Note that user_reserve_kbytes affects this policy.
This feature can be very useful because there are a lot of
programs that malloc() huge amounts of memory "just-in-case"
@ -645,6 +677,24 @@ The default value is 60.
==============================================================
- user_reserve_kbytes
When overcommit_memory is set to 2, "never overommit" mode, reserve
min(3% of current process size, user_reserve_kbytes) of free memory.
This is intended to prevent a user from starting a single memory hogging
process, such that they cannot recover (kill the hog).
user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
If this is reduced to zero, then the user will be allowed to allocate
all free memory with a single process, minus admin_reserve_kbytes.
Any subsequent attempts to execute a command will result in
"fork: Cannot allocate memory".
Changing this takes effect whenever an application requests memory.
==============================================================
vfs_cache_pressure
------------------

205
Documentation/this_cpu_ops.txt Normal file
View File

@ -0,0 +1,205 @@
this_cpu operations
-------------------
this_cpu operations are a way of optimizing access to per cpu
variables associated with the *currently* executing processor through
the use of segment registers (or a dedicated register where the cpu
permanently stored the beginning of the per cpu area for a specific
processor).
The this_cpu operations add a per cpu variable offset to the processor
specific percpu base and encode that operation in the instruction
operating on the per cpu variable.
This means there are no atomicity issues between the calculation of
the offset and the operation on the data. Therefore it is not
necessary to disable preempt or interrupts to ensure that the
processor is not changed between the calculation of the address and
the operation on the data.
Read-modify-write operations are of particular interest. Frequently
processors have special lower latency instructions that can operate
without the typical synchronization overhead but still provide some
sort of relaxed atomicity guarantee. The x86 for example can execute
RMV (Read Modify Write) instructions like inc/dec/cmpxchg without the
lock prefix and the associated latency penalty.
Access to the variable without the lock prefix is not synchronized but
synchronization is not necessary since we are dealing with per cpu
data specific to the currently executing processor. Only the current
processor should be accessing that variable and therefore there are no
concurrency issues with other processors in the system.
On x86 the fs: or the gs: segment registers contain the base of the
per cpu area. It is then possible to simply use the segment override
to relocate a per cpu relative address to the proper per cpu area for
the processor. So the relocation to the per cpu base is encoded in the
instruction via a segment register prefix.
For example:
DEFINE_PER_CPU(int, x);
int z;
z = this_cpu_read(x);
results in a single instruction
mov ax, gs:[x]
instead of a sequence of calculation of the address and then a fetch
from that address which occurs with the percpu operations. Before
this_cpu_ops such sequence also required preempt disable/enable to
prevent the kernel from moving the thread to a different processor
while the calculation is performed.
The main use of the this_cpu operations has been to optimize counter
operations.
this_cpu_inc(x)
results in the following single instruction (no lock prefix!)
inc gs:[x]
instead of the following operations required if there is no segment
register.
int *y;
int cpu;
cpu = get_cpu();
y = per_cpu_ptr(&x, cpu);
(*y)++;
put_cpu();
Note that these operations can only be used on percpu data that is
reserved for a specific processor. Without disabling preemption in the
surrounding code this_cpu_inc() will only guarantee that one of the
percpu counters is correctly incremented. However, there is no
guarantee that the OS will not move the process directly before or
after the this_cpu instruction is executed. In general this means that
the value of the individual counters for each processor are
meaningless. The sum of all the per cpu counters is the only value
that is of interest.
Per cpu variables are used for performance reasons. Bouncing cache
lines can be avoided if multiple processors concurrently go through
the same code paths. Since each processor has its own per cpu
variables no concurrent cacheline updates take place. The price that
has to be paid for this optimization is the need to add up the per cpu
counters when the value of the counter is needed.
Special operations:
-------------------
y = this_cpu_ptr(&x)
Takes the offset of a per cpu variable (&x !) and returns the address
of the per cpu variable that belongs to the currently executing
processor. this_cpu_ptr avoids multiple steps that the common
get_cpu/put_cpu sequence requires. No processor number is
available. Instead the offset of the local per cpu area is simply
added to the percpu offset.
Per cpu variables and offsets
-----------------------------
Per cpu variables have *offsets* to the beginning of the percpu
area. They do not have addresses although they look like that in the
code. Offsets cannot be directly dereferenced. The offset must be
added to a base pointer of a percpu area of a processor in order to
form a valid address.
Therefore the use of x or &x outside of the context of per cpu
operations is invalid and will generally be treated like a NULL
pointer dereference.
In the context of per cpu operations
x is a per cpu variable. Most this_cpu operations take a cpu
variable.
&x is the *offset* a per cpu variable. this_cpu_ptr() takes
the offset of a per cpu variable which makes this look a bit
strange.
Operations on a field of a per cpu structure
--------------------------------------------
Let's say we have a percpu structure
struct s {
int n,m;
};
DEFINE_PER_CPU(struct s, p);
Operations on these fields are straightforward
this_cpu_inc(p.m)
z = this_cpu_cmpxchg(p.m, 0, 1);
If we have an offset to struct s:
struct s __percpu *ps = &p;
z = this_cpu_dec(ps->m);
z = this_cpu_inc_return(ps->n);
The calculation of the pointer may require the use of this_cpu_ptr()
if we do not make use of this_cpu ops later to manipulate fields:
struct s *pp;
pp = this_cpu_ptr(&p);
pp->m--;
z = pp->n++;
Variants of this_cpu ops
-------------------------
this_cpu ops are interrupt safe. Some architecture do not support
these per cpu local operations. In that case the operation must be
replaced by code that disables interrupts, then does the operations
that are guaranteed to be atomic and then reenable interrupts. Doing
so is expensive. If there are other reasons why the scheduler cannot
change the processor we are executing on then there is no reason to
disable interrupts. For that purpose the __this_cpu operations are
provided. For example.
__this_cpu_inc(x);
Will increment x and will not fallback to code that disables
interrupts on platforms that cannot accomplish atomicity through
address relocation and a Read-Modify-Write operation in the same
instruction.
&this_cpu_ptr(pp)->n vs this_cpu_ptr(&pp->n)
--------------------------------------------
The first operation takes the offset and forms an address and then
adds the offset of the n field.
The second one first adds the two offsets and then does the
relocation. IMHO the second form looks cleaner and has an easier time
with (). The second form also is consistent with the way
this_cpu_read() and friends are used.
Christoph Lameter, April 3rd, 2013

2085
Documentation/trace/ftrace.txt
View File

File diff suppressed because it is too large Load Diff

112
Documentation/trace/uprobetracer.txt
View File

@ -1,6 +1,8 @@
Uprobe-tracer: Uprobe-based Event Tracing
=========================================
Documentation written by Srikar Dronamraju
Uprobe-tracer: Uprobe-based Event Tracing
=========================================
Documentation written by Srikar Dronamraju
Overview
--------
@ -13,78 +15,94 @@ current_tracer. Instead of that, add probe points via
/sys/kernel/debug/tracing/events/uprobes/<EVENT>/enabled.
However unlike kprobe-event tracer, the uprobe event interface expects the
user to calculate the offset of the probepoint in the object
user to calculate the offset of the probepoint in the object.
Synopsis of uprobe_tracer
-------------------------
p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a probe
p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe
r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe)
-:[GRP/]EVENT : Clear uprobe or uretprobe event
GRP : Group name. If omitted, use "uprobes" for it.
EVENT : Event name. If omitted, the event name is generated
based on SYMBOL+offs.
PATH : path to an executable or a library.
SYMBOL[+offs] : Symbol+offset where the probe is inserted.
GRP : Group name. If omitted, "uprobes" is the default value.
EVENT : Event name. If omitted, the event name is generated based
on SYMBOL+offs.
PATH : Path to an executable or a library.
SYMBOL[+offs] : Symbol+offset where the probe is inserted.
FETCHARGS : Arguments. Each probe can have up to 128 args.
%REG : Fetch register REG
FETCHARGS : Arguments. Each probe can have up to 128 args.
%REG : Fetch register REG
Event Profiling
---------------
You can check the total number of probe hits and probe miss-hits via
You can check the total number of probe hits and probe miss-hits via
/sys/kernel/debug/tracing/uprobe_profile.
The first column is event name, the second is the number of probe hits,
The first column is event name, the second is the number of probe hits,
the third is the number of probe miss-hits.
Usage examples
--------------
To add a probe as a new event, write a new definition to uprobe_events
as below.
* Add a probe as a new uprobe event, write a new definition to uprobe_events
as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash)
echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash
* Add a probe as a new uretprobe event:
echo > /sys/kernel/debug/tracing/uprobe_events
echo 'r: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
This clears all probe points.
* Unset registered event:
The following example shows how to dump the instruction pointer and %ax
a register at the probed text address. Here we are trying to probe
function zfree in /bin/zsh
echo '-:bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events
* Print out the events that are registered:
cat /sys/kernel/debug/tracing/uprobe_events
* Clear all events:
echo > /sys/kernel/debug/tracing/uprobe_events
Following example shows how to dump the instruction pointer and %ax register
at the probed text address. Probe zfree function in /bin/zsh:
# cd /sys/kernel/debug/tracing/
# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp
# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp
00400000-0048a000 r-xp 00000000 08:03 130904 /bin/zsh
# objdump -T /bin/zsh | grep -w zfree
0000000000446420 g DF .text 0000000000000012 Base zfree
0x46420 is the offset of zfree in object /bin/zsh that is loaded at
0x00400000. Hence the command to probe would be :
0x46420 is the offset of zfree in object /bin/zsh that is loaded at
0x00400000. Hence the command to uprobe would be:
# echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events
# echo 'p:zfree_entry /bin/zsh:0x46420 %ip %ax' > uprobe_events
Please note: User has to explicitly calculate the offset of the probepoint
And the same for the uretprobe would be:
# echo 'r:zfree_exit /bin/zsh:0x46420 %ip %ax' >> uprobe_events
Please note: User has to explicitly calculate the offset of the probe-point
in the object. We can see the events that are registered by looking at the
uprobe_events file.
# cat uprobe_events
p:uprobes/p_zsh_0x46420 /bin/zsh:0x00046420 arg1=%ip arg2=%ax
p:uprobes/zfree_entry /bin/zsh:0x00046420 arg1=%ip arg2=%ax
r:uprobes/zfree_exit /bin/zsh:0x00046420 arg1=%ip arg2=%ax
The format of events can be seen by viewing the file events/uprobes/p_zsh_0x46420/format
Format of events can be seen by viewing the file events/uprobes/zfree_entry/format
# cat events/uprobes/p_zsh_0x46420/format
name: p_zsh_0x46420
# cat events/uprobes/zfree_entry/format
name: zfree_entry
ID: 922
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:int common_padding; offset:8; size:4; signed:1;
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:int common_padding; offset:8; size:4; signed:1;
field:unsigned long __probe_ip; offset:12; size:4; signed:0;
field:u32 arg1; offset:16; size:4; signed:0;
field:u32 arg2; offset:20; size:4; signed:0;
field:unsigned long __probe_ip; offset:12; size:4; signed:0;
field:u32 arg1; offset:16; size:4; signed:0;
field:u32 arg2; offset:20; size:4; signed:0;
print fmt: "(%lx) arg1=%lx arg2=%lx", REC->__probe_ip, REC->arg1, REC->arg2
@ -94,6 +112,7 @@ events, you need to enable it by:
# echo 1 > events/uprobes/enable
Lets disable the event after sleeping for some time.
# sleep 20
# echo 0 > events/uprobes/enable
@ -104,10 +123,11 @@ And you can see the traced information via /sys/kernel/debug/tracing/trace.
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
zsh-24842 [006] 258544.995456: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
zsh-24842 [007] 258545.000270: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
zsh-24842 [002] 258545.043929: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
zsh-24842 [004] 258547.046129: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
zsh-24842 [006] 258544.995456: zfree_entry: (0x446420) arg1=446420 arg2=79
zsh-24842 [007] 258545.000270: zfree_exit: (0x446540 <- 0x446420) arg1=446540 arg2=0
zsh-24842 [002] 258545.043929: zfree_entry: (0x446420) arg1=446420 arg2=79
zsh-24842 [004] 258547.046129: zfree_exit: (0x446540 <- 0x446420) arg1=446540 arg2=0
Each line shows us probes were triggered for a pid 24842 with ip being
0x446421 and contents of ax register being 79.
Output shows us uprobe was triggered for a pid 24842 with ip being 0x446420
and contents of ax register being 79. And uretprobe was triggered with ip at
0x446540 with counterpart function entry at 0x446420.

10
Documentation/usb/power-management.txt
View File

@ -33,6 +33,10 @@ built with CONFIG_USB_SUSPEND enabled (which depends on
CONFIG_PM_RUNTIME). System PM support is present only if the kernel
was built with CONFIG_SUSPEND or CONFIG_HIBERNATION enabled.
(Starting with the 3.10 kernel release, dynamic PM support for USB is
present whenever the kernel was built with CONFIG_PM_RUNTIME enabled.
The CONFIG_USB_SUSPEND option has been eliminated.)
What is Remote Wakeup?
----------------------
@ -206,10 +210,8 @@ initialized to 5. (The idle-delay values for already existing devices
will not be affected.)
Setting the initial default idle-delay to -1 will prevent any
autosuspend of any USB device. This is a simple alternative to
disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the
added benefit of allowing you to enable autosuspend for selected
devices.
autosuspend of any USB device. This has the benefit of allowing you
then to enable autosuspend for selected devices.
Warnings

8
Documentation/vm/overcommit-accounting
View File

@ -8,7 +8,9 @@ The Linux kernel supports the following overcommit handling modes
default.
1 - Always overcommit. Appropriate for some scientific
applications.
applications. Classic example is code using sparse arrays
and just relying on the virtual memory consisting almost
entirely of zero pages.
2 - Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
@ -18,6 +20,10 @@ The Linux kernel supports the following overcommit handling modes
pages but will receive errors on memory allocation as
appropriate.
Useful for applications that want to guarantee their
memory allocations will be available in the future
without having to initialize every page.
The overcommit policy is set via the sysctl `vm.overcommit_memory'.
The overcommit percentage is set via `vm.overcommit_ratio'.

185
MAINTAINERS
View File

@ -90,6 +90,9 @@ Descriptions of section entries:
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
One pattern per line. Multiple F: lines acceptable.
N: Files and directories with regex patterns.
N: [^a-z]tegra all files whose path contains the word tegra
One pattern per line. Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
@ -97,13 +100,12 @@ Descriptions of section entries:
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
K: Keyword perl extended regex pattern to match content in a
patch or file, or an affected filename. For instance:
patch or file. For instance:
K: of_get_profile
matches patch or file content, or filenames, that contain
"of_get_profile"
matches patches or files that contain "of_get_profile"
K: \b(printk|pr_(info|err))\b
matches patch or file content, or filenames, that contain one or
more of the words printk, pr_info or pr_err
matches patches or files that contain one or more of the words
printk, pr_info or pr_err
One regex pattern per line. Multiple K: lines acceptable.
Note: For the hard of thinking, this list is meant to remain in alphabetical
@ -114,12 +116,6 @@ Maintainers List (try to look for most precise areas first)
-----------------------------------
3C505 NETWORK DRIVER
M: Philip Blundell <philb@gnu.org>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/i825xx/3c505*
3C59X NETWORK DRIVER
M: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
L: netdev@vger.kernel.org
@ -1037,6 +1033,7 @@ F: drivers/mmc/host/msm_sdcc.h
F: drivers/tty/serial/msm_serial.h
F: drivers/tty/serial/msm_serial.c
F: drivers/*/pm8???-*
F: drivers/ssbi/
F: include/linux/mfd/pm8xxx/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git
S: Maintained
@ -1344,12 +1341,6 @@ S: Maintained
F: drivers/platform/x86/asus*.c
F: drivers/platform/x86/eeepc*.c
ASUS ASB100 HARDWARE MONITOR DRIVER
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
L: lm-sensors@lm-sensors.org
S: Maintained
F: drivers/hwmon/asb100.c
ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API
M: Dan Williams <djbw@fb.com>
W: http://sourceforge.net/projects/xscaleiop
@ -1473,6 +1464,12 @@ F: drivers/dma/at_hdmac.c
F: drivers/dma/at_hdmac_regs.h
F: include/linux/platform_data/dma-atmel.h
ATMEL I2C DRIVER
M: Ludovic Desroches <ludovic.desroches@atmel.com>
L: linux-i2c@vger.kernel.org
S: Supported
F: drivers/i2c/busses/i2c-at91.c
ATMEL ISI DRIVER
M: Josh Wu <josh.wu@atmel.com>
L: linux-media@vger.kernel.org
@ -2361,12 +2358,6 @@ W: http://www.arm.linux.org.uk/
S: Maintained
F: drivers/video/cyber2000fb.*
CYCLADES 2X SYNC CARD DRIVER
M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
W: http://oops.ghostprotocols.net:81/blog
S: Maintained
F: drivers/net/wan/cycx*
CYCLADES ASYNC MUX DRIVER
W: http://www.cyclades.com/
S: Orphan
@ -2453,9 +2444,7 @@ S: Maintained
F: drivers/platform/x86/dell-laptop.c
DELL LAPTOP SMM DRIVER
M: Massimo Dal Zotto <dz@debian.org>
W: http://www.debian.org/~dz/i8k/
S: Maintained
S: Orphan
F: drivers/char/i8k.c
F: include/uapi/linux/i8k.h
@ -2470,6 +2459,12 @@ M: Matthew Garrett <mjg59@srcf.ucam.org>
S: Maintained
F: drivers/platform/x86/dell-wmi.c
DESIGNWARE USB2 DRD IP DRIVER
M: Paul Zimmerman <paulz@synopsys.com>
L: linux-usb@vger.kernel.org
S: Maintained
F: drivers/staging/dwc2/
DESIGNWARE USB3 DRD IP DRIVER
M: Felipe Balbi <balbi@ti.com>
L: linux-usb@vger.kernel.org
@ -2641,7 +2636,7 @@ F: include/uapi/drm/
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
M: Daniel Vetter <daniel.vetter@ffwll.ch>
L: intel-gfx@lists.freedesktop.org (subscribers-only)
L: intel-gfx@lists.freedesktop.org
L: dri-devel@lists.freedesktop.org
T: git git://people.freedesktop.org/~danvet/drm-intel
S: Supported
@ -3067,12 +3062,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
F: drivers/video/s1d13xxxfb.c
F: include/video/s1d13xxxfb.h
ETHEREXPRESS-16 NETWORK DRIVER
M: Philip Blundell <philb@gnu.org>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/i825xx/eexpress.*
ETHERNET BRIDGE
M: Stephen Hemminger <stephen@networkplumber.org>
L: bridge@lists.linux-foundation.org
@ -3260,6 +3249,12 @@ F: Documentation/firmware_class/
F: drivers/base/firmware*.c
F: include/linux/firmware.h
FLASHSYSTEM DRIVER (IBM FlashSystem 70/80 PCI SSD Flash Card)
M: Joshua Morris <josh.h.morris@us.ibm.com>
M: Philip Kelleher <pjk1939@linux.vnet.ibm.com>
S: Maintained
F: drivers/block/rsxx/
FLOPPY DRIVER
M: Jiri Kosina <jkosina@suse.cz>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/floppy.git
@ -3520,7 +3515,7 @@ F: drivers/isdn/gigaset/
F: include/uapi/linux/gigaset_dev.h
GPIO SUBSYSTEM
M: Grant Likely <grant.likely@secretlab.ca>
M: Grant Likely <grant.likely@linaro.org>
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
T: git git://git.secretlab.ca/git/linux-2.6.git
@ -3869,7 +3864,7 @@ F: drivers/i2c/busses/i2c-ismt.c
F: Documentation/i2c/busses/i2c-ismt
I2C/SMBUS STUB DRIVER
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
M: Jean Delvare <khali@linux-fr.org>
L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/i2c/i2c-stub.c
@ -4023,6 +4018,22 @@ M: Stanislaw Gruszka <stf_xl@wp.pl>
S: Maintained
F: drivers/usb/atm/ueagle-atm.c
INA209 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/ina209
F: Documentation/devicetree/bindings/i2c/ina209.txt
F: drivers/hwmon/ina209.c
INA2XX HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/ina2xx
F: drivers/hwmon/ina2xx.c
F: include/linux/platform_data/ina2xx.h
INDUSTRY PACK SUBSYSTEM (IPACK)
M: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
M: Jens Taprogge <jens.taprogge@taprogge.org>
@ -4337,7 +4348,7 @@ F: drivers/irqchip/
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
M: Grant Likely <grant.likely@secretlab.ca>
M: Grant Likely <grant.likely@linaro.org>
T: git git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
S: Maintained
F: Documentation/IRQ-domain.txt
@ -4824,11 +4835,8 @@ F: arch/powerpc/platforms/40x/
F: arch/powerpc/platforms/44x/
LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
M: Grant Likely <grant.likely@secretlab.ca>
W: http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
L: linuxppc-dev@lists.ozlabs.org
T: git git://git.secretlab.ca/git/linux-2.6.git
S: Maintained
S: Unmaintained
F: arch/powerpc/*/*virtex*
F: arch/powerpc/*/*/*virtex*
@ -4937,6 +4945,12 @@ W: logfs.org
S: Maintained
F: fs/logfs/
LPC32XX MACHINE SUPPORT
M: Roland Stigge <stigge@antcom.de>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-lpc32xx/
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
M: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
@ -5061,9 +5075,8 @@ S: Maintained
F: drivers/net/ethernet/marvell/sk*
MARVELL LIBERTAS WIRELESS DRIVER
M: Dan Williams <dcbw@redhat.com>
L: libertas-dev@lists.infradead.org
S: Maintained
S: Orphan
F: drivers/net/wireless/libertas/
MARVELL MV643XX ETHERNET DRIVER
@ -5116,6 +5129,15 @@ S: Maintained
F: Documentation/hwmon/max6650
F: drivers/hwmon/max6650.c
MAX6697 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/max6697
F: Documentation/devicetree/bindings/i2c/max6697.txt
F: drivers/hwmon/max6697.c
F: include/linux/platform_data/max6697.h
MAXIRADIO FM RADIO RECEIVER DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
L: linux-media@vger.kernel.org
@ -5394,6 +5416,13 @@ L: linux-scsi@vger.kernel.org
S: Maintained
F: drivers/scsi/NCR_D700.*
NCT6775 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/nct6775
F: drivers/hwmon/nct6775.c
NETEFFECT IWARP RNIC DRIVER (IW_NES)
M: Faisal Latif <faisal.latif@intel.com>
L: linux-rdma@vger.kernel.org
@ -5556,6 +5585,7 @@ F: include/uapi/linux/if_*
F: include/uapi/linux/netdevice.h
NETXEN (1/10) GbE SUPPORT
M: Manish Chopra <manish.chopra@qlogic.com>
M: Sony Chacko <sony.chacko@qlogic.com>
M: Rajesh Borundia <rajesh.borundia@qlogic.com>
L: netdev@vger.kernel.org
@ -5640,6 +5670,14 @@ S: Maintained
F: drivers/video/riva/
F: drivers/video/nvidia/
NVM EXPRESS DRIVER
M: Matthew Wilcox <willy@linux.intel.com>
L: linux-nvme@lists.infradead.org
T: git git://git.infradead.org/users/willy/linux-nvme.git
S: Supported
F: drivers/block/nvme.c
F: include/linux/nvme.h
OMAP SUPPORT
M: Tony Lindgren <tony@atomide.com>
L: linux-omap@vger.kernel.org
@ -5668,7 +5706,7 @@ S: Maintained
F: arch/arm/*omap*/*clock*
OMAP POWER MANAGEMENT SUPPORT
M: Kevin Hilman <khilman@ti.com>
M: Kevin Hilman <khilman@deeprootsystems.com>
L: linux-omap@vger.kernel.org
S: Maintained
F: arch/arm/*omap*/*pm*
@ -5762,7 +5800,7 @@ F: arch/arm/*omap*/usb*
OMAP GPIO DRIVER
M: Santosh Shilimkar <santosh.shilimkar@ti.com>
M: Kevin Hilman <khilman@ti.com>
M: Kevin Hilman <khilman@deeprootsystems.com>
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/gpio/gpio-omap.c
@ -5816,7 +5854,7 @@ F: Documentation/i2c/busses/i2c-ocores
F: drivers/i2c/busses/i2c-ocores.c
OPEN FIRMWARE AND FLATTENED DEVICE TREE
M: Grant Likely <grant.likely@secretlab.ca>
M: Grant Likely <grant.likely@linaro.org>
M: Rob Herring <rob.herring@calxeda.com>
L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
W: http://fdt.secretlab.ca
@ -6194,7 +6232,7 @@ F: include/linux/power_supply.h
F: drivers/power/
PNP SUPPORT
M: Adam Belay <abelay@mit.edu>
M: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
M: Bjorn Helgaas <bhelgaas@google.com>
S: Maintained
F: drivers/pnp/
@ -6430,6 +6468,8 @@ F: Documentation/networking/LICENSE.qla3xxx
F: drivers/net/ethernet/qlogic/qla3xxx.*
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
M: Rajesh Borundia <rajesh.borundia@qlogic.com>
M: Shahed Shaikh <shahed.shaikh@qlogic.com>
M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
M: Sony Chacko <sony.chacko@qlogic.com>
M: linux-driver@qlogic.com
@ -6534,12 +6574,6 @@ S: Maintained
F: Documentation/blockdev/ramdisk.txt
F: drivers/block/brd.c
RAMSAM DRIVER (IBM RamSan 70/80 PCI SSD Flash Card)
M: Joshua Morris <josh.h.morris@us.ibm.com>
M: Philip Kelleher <pjk1939@linux.vnet.ibm.com>
S: Maintained
F: drivers/block/rsxx/
RANDOM NUMBER DRIVER
M: Theodore Ts'o" <tytso@mit.edu>
S: Maintained
@ -6608,7 +6642,7 @@ S: Supported
F: fs/reiserfs/
REGISTER MAP ABSTRACTION
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
M: Mark Brown <broonie@kernel.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
S: Supported
F: drivers/base/regmap/
@ -6934,7 +6968,6 @@ F: drivers/scsi/st*
SCTP PROTOCOL
M: Vlad Yasevich <vyasevich@gmail.com>
M: Sridhar Samudrala <sri@us.ibm.com>
M: Neil Horman <nhorman@tuxdriver.com>
L: linux-sctp@vger.kernel.org
W: http://lksctp.sourceforge.net
@ -7156,7 +7189,7 @@ F: arch/arm/mach-s3c2410/bast-irq.c
TI DAVINCI MACHINE SUPPORT
M: Sekhar Nori <nsekhar@ti.com>
M: Kevin Hilman <khilman@ti.com>
M: Kevin Hilman <khilman@deeprootsystems.com>
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
T: git git://gitorious.org/linux-davinci/linux-davinci.git
Q: http://patchwork.kernel.org/project/linux-davinci/list/
@ -7189,13 +7222,6 @@ L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/sis/sis900.*
SIS 96X I2C/SMBUS DRIVER
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
L: linux-i2c@vger.kernel.org
S: Maintained
F: Documentation/i2c/busses/i2c-sis96x
F: drivers/i2c/busses/i2c-sis96x.c
SIS FRAMEBUFFER DRIVER
M: Thomas Winischhofer <thomas@winischhofer.net>
W: http://www.winischhofer.net/linuxsisvga.shtml
@ -7273,7 +7299,7 @@ F: Documentation/hwmon/sch5627
F: drivers/hwmon/sch5627.c
SMSC47B397 HARDWARE MONITOR DRIVER
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
M: Jean Delvare <khali@linux-fr.org>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/smsc47b397
@ -7364,7 +7390,7 @@ F: sound/
SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC)
M: Liam Girdwood <lgirdwood@gmail.com>
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
M: Mark Brown <broonie@kernel.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
W: http://alsa-project.org/main/index.php/ASoC
@ -7452,11 +7478,11 @@ S: Maintained
F: drivers/clk/spear/
SPI SUBSYSTEM
M: Grant Likely <grant.likely@secretlab.ca>
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
M: Mark Brown <broonie@kernel.org>
M: Grant Likely <grant.likely@linaro.org>
L: spi-devel-general@lists.sourceforge.net
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
T: git git://git.secretlab.ca/git/linux-2.6.git
S: Maintained
F: Documentation/spi/
F: drivers/spi/
@ -7696,9 +7722,10 @@ F: include/linux/swiotlb.h
SYNOPSYS ARC ARCHITECTURE
M: Vineet Gupta <vgupta@synopsys.com>
L: linux-snps-arc@vger.kernel.org
S: Supported
F: arch/arc/
F: Documentation/devicetree/bindings/arc/
F: drivers/tty/serial/arc-uart.c
SYSV FILESYSTEM
M: Christoph Hellwig <hch@infradead.org>
@ -7866,7 +7893,7 @@ L: linux-tegra@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
K: (?i)[^a-z]tegra
N: [^a-z]tegra
TEHUTI ETHERNET DRIVER
M: Andy Gospodarek <andy@greyhouse.net>
@ -7909,6 +7936,12 @@ T: git git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
S: Maintained
F: drivers/platform/x86/thinkpad_acpi.c
TI BANDGAP AND THERMAL DRIVER
M: Eduardo Valentin <eduardo.valentin@ti.com>
L: linux-pm@vger.kernel.org
S: Maintained
F: drivers/staging/omap-thermal/
TI FLASH MEDIA INTERFACE DRIVER
M: Alex Dubov <oakad@yahoo.com>
S: Maintained
@ -8346,9 +8379,10 @@ S: Maintained
F: drivers/usb/serial/option.c
USB PEGASUS DRIVER
M: Petko Manolov <petkan@users.sourceforge.net>
M: Petko Manolov <petkan@nucleusys.com>
L: linux-usb@vger.kernel.org
L: netdev@vger.kernel.org
T: git git://git.code.sf.net/p/pegasus2/git
W: http://pegasus2.sourceforge.net/
S: Maintained
F: drivers/net/usb/pegasus.*
@ -8368,9 +8402,10 @@ S: Supported
F: drivers/usb/class/usblp.c
USB RTL8150 DRIVER
M: Petko Manolov <petkan@users.sourceforge.net>
M: Petko Manolov <petkan@nucleusys.com>
L: linux-usb@vger.kernel.org
L: netdev@vger.kernel.org
T: git git://git.code.sf.net/p/pegasus2/git
W: http://pegasus2.sourceforge.net/
S: Maintained
F: drivers/net/usb/rtl8150.c
@ -8696,8 +8731,8 @@ F: drivers/scsi/vmw_pvscsi.c
F: drivers/scsi/vmw_pvscsi.h
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
M: Liam Girdwood <lrg@ti.com>
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
M: Liam Girdwood <lgirdwood@gmail.com>
M: Mark Brown <broonie@kernel.org>
W: http://opensource.wolfsonmicro.com/node/15
W: http://www.slimlogic.co.uk/?p=48
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lrg/regulator.git
@ -8960,9 +8995,7 @@ S: Maintained
F: drivers/net/ethernet/xilinx/xilinx_axienet*
XILINX SYSTEMACE DRIVER
M: Grant Likely <grant.likely@secretlab.ca>
W: http://www.secretlab.ca/
S: Maintained
S: Unmaintained
F: drivers/block/xsysace.c
XILINX UARTLITE SERIAL DRIVER

9
Makefile
View File

@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 9
SUBLEVEL = 0
EXTRAVERSION = -rc1
EXTRAVERSION =
NAME = Unicycling Gorilla
# *DOCUMENTATION*
@ -513,7 +513,8 @@ ifeq ($(KBUILD_EXTMOD),)
# Carefully list dependencies so we do not try to build scripts twice
# in parallel
PHONY += scripts
scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
asm-generic
$(Q)$(MAKE) $(build)=$(@)
# Objects we will link into vmlinux / subdirs we need to visit
@ -1331,11 +1332,11 @@ kernelversion:
# Clear a bunch of variables before executing the submake
tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(objtree) subdir=tools -C $(src)/tools/
tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/ $*
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(objtree) subdir=tools -C $(src)/tools/ $*
# Single targets
# ---------------------------------------------------------------------------

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