iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'x86/vt-d' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu into x86/apic-picks

Browse Source 
Required to apply Jiangs x86 irq handling rework without creating a
nightmare of conflicts.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This commit is contained in:
Thomas Gleixner 2014-12-16 12:25:38 +01:00
commit 8ab7913675
2709 changed files with 87519 additions and 64571 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Documentation/ABI/stable/sysfs-driver-ib_srp
View File

@ -55,12 +55,12 @@ Description: Interface for making ib_srp connect to a new target.
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
* comp_vector, a number in the range 0..n-1 specifying the
MSI-X completion vector. Some HCA's allocate multiple (n)
MSI-X vectors per HCA port. If the IRQ affinity masks of
these interrupts have been configured such that each MSI-X
interrupt is handled by a different CPU then the comp_vector
parameter can be used to spread the SRP completion workload
over multiple CPU's.
MSI-X completion vector of the first RDMA channel. Some
HCA's allocate multiple (n) MSI-X vectors per HCA port. If
the IRQ affinity masks of these interrupts have been
configured such that each MSI-X interrupt is handled by a
different CPU then the comp_vector parameter can be used to
spread the SRP completion workload over multiple CPU's.
* tl_retry_count, a number in the range 2..7 specifying the
IB RC retry count.
* queue_size, the maximum number of commands that the
@ -88,6 +88,13 @@ Description: Whether ib_srp is allowed to include a partial memory
descriptor list in an SRP_CMD when communicating with an SRP
target.
What: /sys/class/scsi_host/host<n>/ch_count
Date: April 1, 2015
KernelVersion: 3.19
Contact: linux-rdma@vger.kernel.org
Description: Number of RDMA channels used for communication with the SRP
target.
What: /sys/class/scsi_host/host<n>/cmd_sg_entries
Date: May 19, 2011
KernelVersion: 2.6.39
@ -95,6 +102,12 @@ Contact: linux-rdma@vger.kernel.org
Description: Maximum number of data buffer descriptors that may be sent to
the target in a single SRP_CMD request.
What: /sys/class/scsi_host/host<n>/comp_vector
Date: September 2, 2013
KernelVersion: 3.11
Contact: linux-rdma@vger.kernel.org
Description: Completion vector used for the first RDMA channel.
What: /sys/class/scsi_host/host<n>/dgid
Date: June 17, 2006
KernelVersion: 2.6.17

71
Documentation/IRQ-domain.txt
View File

@ -151,3 +151,74 @@ used and no descriptor gets allocated it is very important to make sure
that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
==== Hierarchy IRQ domain ====
On some architectures, there may be multiple interrupt controllers
involved in delivering an interrupt from the device to the target CPU.
Let's look at a typical interrupt delivering path on x86 platforms:
Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU
There are three interrupt controllers involved:
1) IOAPIC controller
2) Interrupt remapping controller
3) Local APIC controller
To support such a hardware topology and make software architecture match
hardware architecture, an irq_domain data structure is built for each
interrupt controller and those irq_domains are organized into hierarchy.
When building irq_domain hierarchy, the irq_domain near to the device is
child and the irq_domain near to CPU is parent. So a hierarchy structure
as below will be built for the example above.
CPU Vector irq_domain (root irq_domain to manage CPU vectors)
^
|
Interrupt Remapping irq_domain (manage irq_remapping entries)
^
|
IOAPIC irq_domain (manage IOAPIC delivery entries/pins)
There are four major interfaces to use hierarchy irq_domain:
1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt
controller related resources to deliver these interrupts.
2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller
related resources associated with these interrupts.
3) irq_domain_activate_irq(): activate interrupt controller hardware to
deliver the interrupt.
3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
to stop delivering the interrupt.
Following changes are needed to support hierarchy irq_domain.
1) a new field 'parent' is added to struct irq_domain; it's used to
maintain irq_domain hierarchy information.
2) a new field 'parent_data' is added to struct irq_data; it's used to
build hierarchy irq_data to match hierarchy irq_domains. The irq_data
is used to store irq_domain pointer and hardware irq number.
3) new callbacks are added to struct irq_domain_ops to support hierarchy
irq_domain operations.
With support of hierarchy irq_domain and hierarchy irq_data ready, an
irq_domain structure is built for each interrupt controller, and an
irq_data structure is allocated for each irq_domain associated with an
IRQ. Now we could go one step further to support stacked(hierarchy)
irq_chip. That is, an irq_chip is associated with each irq_data along
the hierarchy. A child irq_chip may implement a required action by
itself or by cooperating with its parent irq_chip.
With stacked irq_chip, interrupt controller driver only needs to deal
with the hardware managed by itself and may ask for services from its
parent irq_chip when needed. So we could achieve a much cleaner
software architecture.
For an interrupt controller driver to support hierarchy irq_domain, it
needs to:
1) Implement irq_domain_ops.alloc and irq_domain_ops.free
2) Optionally implement irq_domain_ops.activate and
irq_domain_ops.deactivate.
3) Optionally implement an irq_chip to manage the interrupt controller
hardware.
4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,
they are unused with hierarchy irq_domain.
Hierarchy irq_domain may also be used to support other architectures,
such as ARM, ARM64 etc.

4
Documentation/RCU/rcu.txt
View File

@ -36,7 +36,7 @@ o How can the updater tell when a grace period has completed
executed in user mode, or executed in the idle loop, we can
safely free up that item.
Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the
Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the
same effect, but require that the readers manipulate CPU-local
counters. These counters allow limited types of blocking within
RCU read-side critical sections. SRCU also uses CPU-local
@ -81,7 +81,7 @@ o I hear that RCU is patented? What is with that?
o I hear that RCU needs work in order to support realtime kernels?
This work is largely completed. Realtime-friendly RCU can be
enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration
enabled via the CONFIG_PREEMPT_RCU kernel configuration
parameter. However, work is in progress for enabling priority
boosting of preempted RCU read-side critical sections. This is
needed if you have CPU-bound realtime threads.

14
Documentation/RCU/stallwarn.txt
View File

@ -26,12 +26,6 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
Stall-warning messages may be enabled and disabled completely via
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
CONFIG_RCU_CPU_STALL_VERBOSE
This kernel configuration parameter causes the stall warning to
also dump the stacks of any tasks that are blocking the current
RCU-preempt grace period.
CONFIG_RCU_CPU_STALL_INFO
This kernel configuration parameter causes the stall warning to
@ -77,7 +71,7 @@ This message indicates that CPU 5 detected that it was causing a stall,
and that the stall was affecting RCU-sched. This message will normally be
followed by a stack dump of the offending CPU. On TREE_RCU kernel builds,
RCU and RCU-sched are implemented by the same underlying mechanism,
while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented
while on PREEMPT_RCU kernel builds, RCU is instead implemented
by rcu_preempt_state.
On the other hand, if the offending CPU fails to print out a stall-warning
@ -89,7 +83,7 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 j
This message indicates that CPU 2 detected that CPUs 3 and 5 were both
causing stalls, and that the stall was affecting RCU-bh. This message
will normally be followed by stack dumps for each CPU. Please note that
TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
and that the tasks will be indicated by PID, for example, "P3421".
It is even possible for a rcu_preempt_state stall to be caused by both
CPUs -and- tasks, in which case the offending CPUs and tasks will all
@ -205,10 +199,10 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
is running at a higher priority than the RCU softirq threads.
This will prevent RCU callbacks from ever being invoked,
and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent
and in a CONFIG_PREEMPT_RCU kernel will further prevent
RCU grace periods from ever completing. Either way, the
system will eventually run out of memory and hang. In the
CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
CONFIG_PREEMPT_RCU case, you might see stall-warning
messages.
o A hardware or software issue shuts off the scheduler-clock

4
Documentation/RCU/trace.txt
View File

@ -8,7 +8,7 @@ The following sections describe the debugfs files and formats, first
for rcutree and next for rcutiny.
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
CONFIG_TREE_RCU and CONFIG_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provide several debugfs directories under the
top-level directory "rcu":
@ -18,7 +18,7 @@ rcu/rcu_preempt
rcu/rcu_sched
Each directory contains files for the corresponding flavor of RCU.
Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.
Note that rcu/rcu_preempt is only present for CONFIG_PREEMPT_RCU.
For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,
so that activity for both appears in rcu/rcu_sched.

2
Documentation/RCU/whatisRCU.txt
View File

@ -137,7 +137,7 @@ rcu_read_lock()
Used by a reader to inform the reclaimer that the reader is
entering an RCU read-side critical section. It is illegal
to block while in an RCU read-side critical section, though
kernels built with CONFIG_TREE_PREEMPT_RCU can preempt RCU
kernels built with CONFIG_PREEMPT_RCU can preempt RCU
read-side critical sections. Any RCU-protected data structure
accessed during an RCU read-side critical section is guaranteed to
remain unreclaimed for the full duration of that critical section.

28
Documentation/arm/firmware.txt
View File

@ -7,32 +7,14 @@ world, which changes the way some things have to be initialized. This makes
a need to provide an interface for such platforms to specify available firmware
operations and call them when needed.
Firmware operations can be specified using struct firmware_ops
struct firmware_ops {
/*
* Enters CPU idle mode
*/
int (*do_idle)(void);
/*
* Sets boot address of specified physical CPU
*/
int (*set_cpu_boot_addr)(int cpu, unsigned long boot_addr);
/*
* Boots specified physical CPU
*/
int (*cpu_boot)(int cpu);
/*
* Initializes L2 cache
*/
int (*l2x0_init)(void);
};
and then registered with register_firmware_ops function
Firmware operations can be specified by filling in a struct firmware_ops
with appropriate callbacks and then registering it with register_firmware_ops()
function.
void register_firmware_ops(const struct firmware_ops *ops)
the ops pointer must be non-NULL.
The ops pointer must be non-NULL. More information about struct firmware_ops
and its members can be found in arch/arm/include/asm/firmware.h header.
There is a default, empty set of operations provided, so there is no need to
set anything if platform does not require firmware operations.

16
Documentation/arm/sunxi/README
View File

@ -37,16 +37,26 @@ SunXi family
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
- Allwinner A23
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A23/A23%20Datasheet%20V1.0%2020130830.pdf
+ User Manual
http://dl.linux-sunxi.org/A23/A23%20User%20Manual%20V1.0%2020130830.pdf
* Quad ARM Cortex-A7 based SoCs
- Allwinner A31 (sun6i)
+ Datasheet
http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20datasheet%20V1.3%2020131106.pdf
+ User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
- Allwinner A31s (sun6i)
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
+ User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20User%20Manual%20%20V1.0%2020130322.pdf
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A80/A80_Datasheet_Revision_1.0_0404.pdf

45
Documentation/arm64/legacy_instructions.txt Normal file
View File

@ -0,0 +1,45 @@
The arm64 port of the Linux kernel provides infrastructure to support
emulation of instructions which have been deprecated, or obsoleted in
the architecture. The infrastructure code uses undefined instruction
hooks to support emulation. Where available it also allows turning on
the instruction execution in hardware.
The emulation mode can be controlled by writing to sysctl nodes
(/proc/sys/abi). The following explains the different execution
behaviours and the corresponding values of the sysctl nodes -
* Undef
Value: 0
Generates undefined instruction abort. Default for instructions that
have been obsoleted in the architecture, e.g., SWP
* Emulate
Value: 1
Uses software emulation. To aid migration of software, in this mode
usage of emulated instruction is traced as well as rate limited
warnings are issued. This is the default for deprecated
instructions, .e.g., CP15 barriers
* Hardware Execution
Value: 2
Although marked as deprecated, some implementations may support the
enabling/disabling of hardware support for the execution of these
instructions. Using hardware execution generally provides better
performance, but at the loss of ability to gather runtime statistics
about the use of the deprecated instructions.
The default mode depends on the status of the instruction in the
architecture. Deprecated instructions should default to emulation
while obsolete instructions must be undefined by default.
Supported legacy instructions
-----------------------------
* SWP{B}
Node: /proc/sys/abi/swp
Status: Obsolete
Default: Undef (0)
* CP15 Barriers
Node: /proc/sys/abi/cp15_barrier
Status: Deprecated
Default: Emulate (1)

12
Documentation/atomic_ops.txt
View File

@ -7,12 +7,13 @@
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
The atomic_t type should be defined as a signed integer.
Also, it should be made opaque such that any kind of cast to a normal
C integer type will fail. Something like the following should
suffice:
The atomic_t type should be defined as a signed integer and
the atomic_long_t type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
will fail. Something like the following should suffice:
typedef struct { int counter; } atomic_t;
typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
See Documentation/volatile-considered-harmful.txt for the complete rationale.
@ -37,6 +38,9 @@ initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
value with atomic_read from another thread.
As with all of the atomic_ interfaces, replace the leading "atomic_"
with "atomic_long_" to operate on atomic_long_t.
The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };

4
Documentation/block/biodoc.txt
View File

@ -827,10 +827,6 @@ but in the event of any barrier requests in the tag queue we need to ensure
that requests are restarted in the order they were queue. This may happen
if the driver needs to use blk_queue_invalidate_tags().
Tagging also defines a new request flag, REQ_QUEUED. This is set whenever
a request is currently tagged. You should not use this flag directly,
blk_rq_tagged(rq) is the portable way to do so.
3.3 I/O Submission
The routine submit_bio() is used to submit a single io. Higher level i/o

22
Documentation/device-mapper/cache-policies.txt
View File

@ -47,20 +47,26 @@ Message and constructor argument pairs are:
'discard_promote_adjustment <value>'
The sequential threshold indicates the number of contiguous I/Os
required before a stream is treated as sequential. The random threshold
required before a stream is treated as sequential. Once a stream is
considered sequential it will bypass the cache. The random threshold
is the number of intervening non-contiguous I/Os that must be seen
before the stream is treated as random again.
The sequential and random thresholds default to 512 and 4 respectively.
Large, sequential ios are probably better left on the origin device
since spindles tend to have good bandwidth. The io_tracker counts
contiguous I/Os to try to spot when the io is in one of these sequential
modes.
Large, sequential I/Os are probably better left on the origin device
since spindles tend to have good sequential I/O bandwidth. The
io_tracker counts contiguous I/Os to try to spot when the I/O is in one
of these sequential modes. But there are use-cases for wanting to
promote sequential blocks to the cache (e.g. fast application startup).
If sequential threshold is set to 0 the sequential I/O detection is
disabled and sequential I/O will no longer implicitly bypass the cache.
Setting the random threshold to 0 does _not_ disable the random I/O
stream detection.
Internally the mq policy maintains a promotion threshold variable. If
the hit count of a block not in the cache goes above this threshold it
gets promoted to the cache. The read, write and discard promote adjustment
Internally the mq policy determines a promotion threshold. If the hit
count of a block not in the cache goes above this threshold it gets
promoted to the cache. The read, write and discard promote adjustment
tunables allow you to tweak the promotion threshold by adding a small
value based on the io type. They default to 4, 8 and 1 respectively.
If you're trying to quickly warm a new cache device you may wish to

6
Documentation/devicetree/bindings/arm/amlogic.txt
View File

@ -2,7 +2,9 @@ Amlogic MesonX device tree bindings
-------------------------------------------
Boards with the Amlogic Meson6 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson6"
compatible = "amlogic,meson6";
Boards with the Amlogic Meson8 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8";

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

@ -22,6 +22,14 @@ to deliver its interrupts via SPIs.
- always-on : a boolean property. If present, the timer is powered through an
always-on power domain, therefore it never loses context.
** Optional properties:
- arm,cpu-registers-not-fw-configured : Firmware does not initialize
any of the generic timer CPU registers, which contain their
architecturally-defined reset values. Only supported for 32-bit
systems which follow the ARMv7 architected reset values.
Example:
timer {

65
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -92,3 +92,68 @@ Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
the ARM11 and Cortex A-8 and Cortex A-9 processors.
Required properties (in root node):
/* RealView Emulation Baseboard */
compatible = "arm,realview-eb";
/* RealView Platform Baseboard for ARM1176JZF-S */
compatible = "arm,realview-pb1176";
/* RealView Platform Baseboard for ARM11 MPCore */
compatible = "arm,realview-pb11mp";
/* RealView Platform Baseboard for Cortex A-8 */
compatible = "arm,realview-pba8";
/* RealView Platform Baseboard Explore for Cortex A-9 */
compatible = "arm,realview-pbx";
Required nodes:
- soc: some node of the RealView platforms must be the SoC
node that contain the SoC-specific devices, withe the compatible
string set to one of these tuples:
"arm,realview-eb-soc", "simple-bus"
"arm,realview-pb1176-soc", "simple-bus"
"arm,realview-pb11mp-soc", "simple-bus"
"arm,realview-pba8-soc", "simple-bus"
"arm,realview-pbx-soc", "simple-bus"
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these tuples:
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"
"arm,realview-pba8-syscon", "syscon"
"arm,realview-pbx-syscon", "syscon"
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x1000 bytes.
Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
#include "skeleton.dtsi"
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "arm,realview-pb1176-soc", "simple-bus";
ranges;
syscon: syscon@10000000 {
compatible = "arm,realview-syscon", "syscon";
reg = <0x10000000 0x1000>;
};
};
};

31
Documentation/devicetree/bindings/arm/bcm/cygnus.txt Normal file
View File

@ -0,0 +1,31 @@
Broadcom Cygnus device tree bindings
------------------------------------
Boards with Cygnus SoCs shall have the following properties:
Required root node property:
BCM11300
compatible = "brcm,bcm11300", "brcm,cygnus";
BCM11320
compatible = "brcm,bcm11320", "brcm,cygnus";
BCM11350
compatible = "brcm,bcm11350", "brcm,cygnus";
BCM11360
compatible = "brcm,bcm11360", "brcm,cygnus";
BCM58300
compatible = "brcm,bcm58300", "brcm,cygnus";
BCM58302
compatible = "brcm,bcm58302", "brcm,cygnus";
BCM58303
compatible = "brcm,bcm58303", "brcm,cygnus";
BCM58305
compatible = "brcm,bcm58305", "brcm,cygnus";

9
Documentation/devicetree/bindings/arm/cpus.txt
View File

@ -227,6 +227,15 @@ nodes to be present and contain the properties described below.
# List of phandles to idle state nodes supported
by this cpu [3].
- rockchip,pmu
Usage: optional for systems that have an "enable-method"
property value of "rockchip,rk3066-smp"
While optional, it is the preferred way to get access to
the cpu-core power-domains.
Value type: <phandle>
Definition: Specifies the syscon node controlling the cpu core
power domains.
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {

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

@ -74,3 +74,41 @@ Required root node properties:
i.MX6q generic board
Required root node properties:
- compatible = "fsl,imx6q";
Freescale LS1021A Platform Device Tree Bindings
------------------------------------------------
Required root node compatible properties:
- compatible = "fsl,ls1021a";
Freescale LS1021A SoC-specific Device Tree Bindings
-------------------------------------------
Freescale SCFG
SCFG is the supplemental configuration unit, that provides SoC specific
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- compatible: should be "fsl,ls1021a-scfg"
- reg: should contain base address and length of SCFG memory-mapped registers
Example:
scfg: scfg@1570000 {
compatible = "fsl,ls1021a-scfg";
reg = <0x0 0x1570000 0x0 0x10000>;
};
Freescale DCFG
DCFG is the device configuration unit, that provides general purpose
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- compatible: should be "fsl,ls1021a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1021a-dcfg";
reg = <0x0 0x1ee0000 0x0 0x10000>;
};

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

@ -17,6 +17,7 @@ Main node required properties:
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
"brcm,brahma-b15-gic"
"arm,arm1176jzf-devchip-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.

10
Documentation/devicetree/bindings/arm/marvell,berlin.txt
View File

@ -106,11 +106,21 @@ Required subnode-properties:
- groups: a list of strings describing the group names.
- function: a string describing the function used to mux the groups.
* Reset controller binding
A reset controller is part of the chip control registers set. The chip control
node also provides the reset. The register set is not at the same offset between
Berlin SoCs.
Required property:
- #reset-cells: must be set to 2
Example:
chip: chip-control@ea0000 {
compatible = "marvell,berlin2-chip-ctrl";
#clock-cells = <1>;
#reset-cells = <2>;
reg = <0xea0000 0x400>;
clocks = <&refclk>, <&externaldev 0>;
clock-names = "refclk", "video_ext0";

19
Documentation/devicetree/bindings/arm/mediatek.txt
View File

@ -1,10 +1,14 @@
Mediatek MT6589 Platforms Device Tree Bindings
MediaTek mt65xx & mt81xx Platforms Device Tree Bindings
Boards with a SoC of the Mediatek MT6589 shall have the following property:
Boards with a MediaTek mt65xx/mt81xx SoC shall have the following property:
Required root node property:
compatible: must contain "mediatek,mt6589"
compatible: Must contain one of
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt8127"
"mediatek,mt8135"
Supported boards:
@ -12,3 +16,12 @@ Supported boards:
- bq Aquaris5 smart phone:
Required root node properties:
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
- Evaluation board for MT6592:
Required root node properties:
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
- MTK mt8127 tablet moose EVB:
Required root node properties:
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
- MTK mt8135 tablet EVB:
Required root node properties:
- compatible = "mediatek,mt8135-evbp1", "mediatek,mt8135";

3
Documentation/devicetree/bindings/arm/omap/omap.txt
View File

@ -132,6 +132,9 @@ Boards:
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
- AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx"
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"

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

@ -1,6 +1,10 @@
Rockchip platforms device tree bindings
---------------------------------------
- MarsBoard RK3066 board:
Required root node properties:
- compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a";
- bq Curie 2 tablet:
Required root node properties:
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";

19
Documentation/devicetree/bindings/arm/samsung-boards.txt
View File

@ -1,11 +1,20 @@
* Samsung's Exynos4210 based SMDKV310 evaluation board
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
* Samsung's Exynos SoC based boards
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
Optional:
- firmware node, specifying presence and type of secure firmware:

6
Documentation/devicetree/bindings/arm/ste-nomadik.txt
View File

@ -10,6 +10,12 @@ Required root node property: src
Boards with the Nomadik SoC include:
Nomadik NHK-15 board manufactured by ST Microelectronics:
Required root node property:
compatible="st,nomadik-nhk-15";
S8815 "MiniKit" manufactured by Calao Systems:
Required root node property:

12
Documentation/devicetree/bindings/arm/sunxi.txt Normal file
View File

@ -0,0 +1,12 @@
Allwinner sunXi Platforms Device Tree Bindings
Each device tree must specify which Allwinner SoC it uses,
using one of the following compatible strings:
allwinner,sun4i-a10
allwinner,sun5i-a10s
allwinner,sun5i-a13
allwinner,sun6i-a31
allwinner,sun7i-a20
allwinner,sun8i-a23
allwinner,sun9i-a80

35
Documentation/devicetree/bindings/arm/ux500/power_domain.txt Normal file
View File

@ -0,0 +1,35 @@
* ST-Ericsson UX500 PM Domains
UX500 supports multiple PM domains which are used to gate power to one or
more peripherals on the SOC.
The implementation of PM domains for UX500 are based upon the generic PM domain
and use the corresponding DT bindings.
==PM domain providers==
Required properties:
- compatible: Must be "stericsson,ux500-pm-domains".
- #power-domain-cells : Number of cells in a power domain specifier, must be 1.
Example:
pm_domains: pm_domains0 {
compatible = "stericsson,ux500-pm-domains";
#power-domain-cells = <1>;
};
==PM domain consumers==
Required properties:
- power-domains: A phandle and PM domain specifier. Below are the list of
valid specifiers:
Index Specifier
----- ---------
0 DOMAIN_VAPE
Example:
sdi0_per1@80126000 {
compatible = "arm,pl18x", "arm,primecell";
power-domains = <&pm_domains DOMAIN_VAPE>
};

6
Documentation/devicetree/bindings/ata/sata_rcar.txt
View File

@ -3,8 +3,10 @@
Required properties:
- compatible : should contain one of the following:
- "renesas,sata-r8a7779" for R-Car H1
- "renesas,sata-r8a7790" for R-Car H2
- "renesas,sata-r8a7791" for R-Car M2
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
- "renesas,sata-r8a7791" for R-Car M2-W
- "renesas,sata-r8a7793" for R-Car M2-N
- reg : address and length of the SATA registers;
- interrupts : must consist of one interrupt specifier.

6
Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
View File

@ -2,7 +2,11 @@ Broadcom GISB bus Arbiter controller
Required properties:
- compatible: should be "brcm,gisb-arb"
- compatible:
"brcm,gisb-arb" or "brcm,bcm7445-gisb-arb" for 28nm chips
"brcm,bcm7435-gisb-arb" for newer 40nm chips
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
"brcm,bcm7038-gisb-arb" for 130nm chips
- reg: specifies the base physical address and size of the registers
- interrupt-parent: specifies the phandle to the parent interrupt controller
this arbiter gets interrupt line from

17
Documentation/devicetree/bindings/bus/mvebu-mbus.txt
View File

@ -48,9 +48,12 @@ Required properties:
- compatible: Should be set to "marvell,mbus-controller".
- reg: Device's register space.
Two entries are expected (see the examples below):
the first one controls the devices decoding window and
the second one controls the SDRAM decoding window.
Two or three entries are expected (see the examples below):
the first one controls the devices decoding window,
the second one controls the SDRAM decoding window and
the third controls the MBus bridge (only with the
marvell,armada370-mbus and marvell,armadaxp-mbus
compatible strings)
Example:
@ -67,7 +70,7 @@ Example:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@ -126,7 +129,7 @@ are skipped.
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@ -170,7 +173,7 @@ Using this macro, the above example would be:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* other children */
@ -266,7 +269,7 @@ See the example below, where a more complete device tree is shown:
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
interrupt-controller@20000 {

34
Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt Normal file
View File

@ -0,0 +1,34 @@
Broadcom Cygnus Clocks
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
Currently various "fixed" clocks are declared for peripheral drivers that use
the common clock framework to reference their core clocks. Proper support of
these clocks will be added later
Device tree example:
clocks {
#address-cells = <1>;
#size-cells = <1>;
ranges;
osc: oscillator {
compatible = "fixed-clock";
#clock-cells = <1>;
clock-frequency = <25000000>;
};
apb_clk: apb_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000000000>;
};
periph_clk: periph_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <500000000>;
};
};

15
Documentation/devicetree/bindings/clock/vf610-clock.txt
View File

@ -5,6 +5,19 @@ Required properties:
- reg: Address and length of the register set
- #clock-cells: Should be <1>
Optional properties:
- clocks: list of clock identifiers which are external input clocks to the
given clock controller. Please refer the next section to find
the input clocks for a given controller.
- clock-names: list of names of clocks which are exteral input clocks to the
given clock controller.
Input clocks for top clock controller:
- sxosc (external crystal oscillator 32KHz, recommended)
- fxosc (external crystal oscillator 24MHz, recommended)
- audio_ext
- enet_ext
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
for the full list of VF610 clock IDs.
@ -15,6 +28,8 @@ clks: ccm@4006b000 {
compatible = "fsl,vf610-ccm";
reg = <0x4006b000 0x1000>;
#clock-cells = <1>;
clocks = <&sxosc>, <&fxosc>;
clock-names = "sxosc", "fxosc";
};
uart1: serial@40028000 {

2
Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
View File

@ -25,7 +25,7 @@ Required child node properties:
- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or
"xlnx,axi-vdma-s2mm-channel".
- interrupts: Should contain per channel VDMA interrupts.
- xlnx,data-width: Should contain the stream data width, take values
- xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
Optional child node properties:

39
Documentation/devicetree/bindings/hwmon/ltc2978.txt Normal file
View File

@ -0,0 +1,39 @@
ltc2978
Required properties:
- compatible: should contain one of:
* "lltc,ltc2974"
* "lltc,ltc2977"
* "lltc,ltc2978"
* "lltc,ltc3880"
* "lltc,ltc3883"
* "lltc,ltm4676"
- reg: I2C slave address
Optional properties:
- regulators: A node that houses a sub-node for each regulator controlled by
the device. Each sub-node is identified using the node's name, with valid
values listed below. The content of each sub-node is defined by the
standard binding for regulators; see regulator.txt.
Valid names of regulators depend on number of supplies supported per device:
* ltc2974 : vout0 - vout3
* ltc2977 : vout0 - vout7
* ltc2978 : vout0 - vout7
* ltc3880 : vout0 - vout1
* ltc3883 : vout0
* ltm4676 : vout0 - vout1
Example:
ltc2978@5e {
compatible = "lltc,ltc2978";
reg = <0x5e>;
regulators {
vout0 {
regulator-name = "FPGA-2.5V";
};
vout2 {
regulator-name = "FPGA-1.5V";
};
};
};

1
Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
View File

@ -32,6 +32,7 @@ Optional properties:
specified, default value is 0.
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
specified, the default value in Hz is 100000.
- samsung,sysreg-phandle - handle to syscon used to control the system registers
Example:

2
Documentation/devicetree/bindings/i2c/trivial-devices.txt
View File

@ -56,6 +56,8 @@ gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire In
infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
isl,isl12057 Intersil ISL12057 I2C RTC Chip
isil,isl29028 (deprecated, use isl)
isl,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface

26
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
View File

@ -13,7 +13,12 @@ Such an interrupt controller has the following hardware design:
or if they will output an interrupt signal at this 2nd level interrupt
controller, in particular for UARTs
- not all 32-bits within the interrupt controller actually map to an interrupt
- typically has one 32-bit enable word and one 32-bit status word, but on
some hardware may have more than one enable/status pair
- no atomic set/clear operations
- not all bits within the interrupt controller actually map to an interrupt
The typical hardware layout for this controller is represented below:
@ -48,7 +53,9 @@ The typical hardware layout for this controller is represented below:
Required properties:
- compatible: should be "brcm,bcm7120-l2-intc"
- reg: specifies the base physical address and size of the registers
- reg: specifies the base physical address and size of the registers;
multiple pairs may be specified, with the first pair handling IRQ offsets
0..31 and the second pair handling 32..63
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
source, should be 1.
@ -59,18 +66,21 @@ Required properties:
- brcm,int-map-mask: 32-bits bit mask describing how many and which interrupts
are wired to this 2nd level interrupt controller, and how they match their
respective interrupt parents. Should match exactly the number of interrupts
specified in the 'interrupts' property.
specified in the 'interrupts' property, multiplied by the number of
enable/status register pairs implemented by this controller. For
multiple parent IRQs with multiple enable/status words, this looks like:
<irq0_w0 irq0_w1 irq1_w0 irq1_w1 ...>
Optional properties:
- brcm,irq-can-wake: if present, this means the L2 controller can be used as a
wakeup source for system suspend/resume.
- brcm,int-fwd-mask: if present, a 32-bits bit mask to configure for the
interrupts which have a mux gate, typically UARTs. Setting these bits will
make their respective interrupts outputs bypass this 2nd level interrupt
controller completely, it completely transparent for the interrupt controller
parent
- brcm,int-fwd-mask: if present, a bit mask to configure the interrupts which
have a mux gate, typically UARTs. Setting these bits will make their
respective interrupt outputs bypass this 2nd level interrupt controller
completely; it is completely transparent for the interrupt controller
parent. This should have one 32-bit word per enable/status pair.
Example:

4
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
View File

@ -30,10 +30,6 @@ should only be used when a device has multiple interrupt parents.
Example:
interrupts-extended = <&intc1 5 1>, <&intc2 1 0>;
A device node may contain either "interrupts" or "interrupts-extended", but not
both. If both properties are present, then the operating system should log an
error and use only the data in "interrupts".
2) Interrupt controller nodes
-----------------------------

21
Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt Normal file
View File

@ -0,0 +1,21 @@
Device Tree bindings for MVEBU SDRAM controllers
The Marvell EBU SoCs all have a SDRAM controller. The SDRAM controller
differs from one SoC variant to another, but they also share a number
of commonalities.
For now, this Device Tree binding documentation only documents the
Armada XP SDRAM controller.
Required properties:
- compatible: for Armada XP, "marvell,armada-xp-sdram-controller"
- reg: a resource specifier for the register space, which should
include all SDRAM controller registers as per the datasheet.
Example:
sdramc@1400 {
compatible = "marvell,armada-xp-sdram-controller";
reg = <0x1400 0x500>;
};

36
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra-mc.txt Normal file
View File

@ -0,0 +1,36 @@
NVIDIA Tegra Memory Controller device tree bindings
===================================================
Required properties:
- compatible: Should be "nvidia,tegra<chip>-mc"
- reg: Physical base address and length of the controller's registers.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- mc: the module's clock input
- interrupts: The interrupt outputs from the controller.
- #iommu-cells: Should be 1. The single cell of the IOMMU specifier defines
the SWGROUP of the master.
This device implements an IOMMU that complies with the generic IOMMU binding.
See ../iommu/iommu.txt for details.
Example:
--------
mc: memory-controller@0,70019000 {
compatible = "nvidia,tegra124-mc";
reg = <0x0 0x70019000 0x0 0x1000>;
clocks = <&tegra_car TEGRA124_CLK_MC>;
clock-names = "mc";
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
#iommu-cells = <1>;
};
sdhci@0,700b0000 {
compatible = "nvidia,tegra124-sdhci";
...
iommus = <&mc TEGRA_SWGROUP_SDMMC1A>;
};

51
Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt Normal file
View File

@ -0,0 +1,51 @@
Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
Required properties:
- compatible: value should be one of the following:
"atmel,sama5d3-hlcdc"
- reg: base address and size of the HLCDC device registers.
- clock-names: the name of the 3 clocks requested by the HLCDC device.
Should contain "periph_clk", "sys_clk" and "slow_clk".
- clocks: should contain the 3 clocks requested by the HLCDC device.
- interrupts: should contain the description of the HLCDC interrupt line
The HLCDC IP exposes two subdevices:
- a PWM chip: see ../pwm/atmel-hlcdc-pwm.txt
- a Display Controller: see ../drm/atmel-hlcdc-dc.txt
Example:
hlcdc: hlcdc@f0030000 {
compatible = "atmel,sama5d3-hlcdc";
reg = <0xf0030000 0x2000>;
clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
clock-names = "periph_clk","sys_clk", "slow_clk";
interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
status = "disabled";
hlcdc-display-controller {
compatible = "atmel,hlcdc-display-controller";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
hlcdc_panel_output: endpoint@0 {
reg = <0>;
remote-endpoint = <&panel_input>;
};
};
};
hlcdc_pwm: hlcdc-pwm {
compatible = "atmel,hlcdc-pwm";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd_pwm>;
#pwm-cells = <3>;
};
};

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

@ -34,6 +34,12 @@ to get matched with their hardware counterparts as follow:
-BUCKn : for BUCKs, where n can lie in range 1 to 9.
example: BUCK1, BUCK5, BUCK9.
Regulators which can be turned off during system suspend:
-LDOn : 2, 6-8, 10-12, 14-16,
-BUCKn : 1-4.
Use standard regulator bindings for it ('regulator-off-in-suspend').
Example:
max77686@09 {

21
Documentation/devicetree/bindings/mfd/max77693.txt
View File

@ -27,6 +27,20 @@ Optional properties:
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
- haptic : The MAX77693 haptic device utilises a PWM controlled motor to provide
users with tactile feedback. PWM period and duty-cycle are varied in
order to provide the approprite level of feedback.
Required properties:
- compatible : Must be "maxim,max77693-hpatic"
- haptic-supply : power supply for the haptic motor
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
PWM properties should be named "pwms". And number of cell is different
for each pwm device.
To get more informations, please refer to documentaion.
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
Example:
max77693@66 {
compatible = "maxim,max77693";
@ -52,4 +66,11 @@ Example:
regulator-boot-on;
};
};
haptic {
compatible = "maxim,max77693-haptic";
haptic-supply = <&haptic_supply>;
pwms = <&pwm 0 40000 0>;
pwm-names = "haptic";
};
};

22
Documentation/devicetree/bindings/mfd/s2mps11.txt
View File

@ -1,5 +1,5 @@
* Samsung S2MPS11, S2MPS14 and S2MPU02 Voltage and Current Regulator
* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
The Samsung S2MPS11 is a multi-function device which includes voltage and
current regulators, RTC, charger controller and other sub-blocks. It is
@ -7,8 +7,8 @@ interfaced to the host controller using an I2C interface. Each sub-block is
addressed by the host system using different I2C slave addresses.
Required properties:
- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic"
or "samsung,s2mpu02-pmic".
- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
- reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
Optional properties:
@ -17,8 +17,8 @@ Optional properties:
- interrupts: Interrupt specifiers for interrupt sources.
Optional nodes:
- clocks: s2mps11 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz
outputs, so to register these as clocks with common clock framework
- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768
KHz outputs, so to register these as clocks with common clock framework
instantiate a sub-node named "clocks". It uses the common clock binding
documented in :
[Documentation/devicetree/bindings/clock/clock-bindings.txt]
@ -30,12 +30,12 @@ Optional nodes:
the clock which they consume.
Clock ID Devices
----------------------------------------------------------
32KhzAP 0 S2MPS11, S2MPS14, S5M8767
32KhzCP 1 S2MPS11, S5M8767
32KhzBT 2 S2MPS11, S2MPS14, S5M8767
32KhzAP 0 S2MPS11, S2MPS13, S2MPS14, S5M8767
32KhzCP 1 S2MPS11, S2MPS13, S5M8767
32KhzBT 2 S2MPS11, S2MPS13, S2MPS14, S5M8767
- compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps14-clk",
"samsung,s5m8767-clk"
- compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk",
"samsung,s2mps14-clk", "samsung,s5m8767-clk"
- regulators: The regulators of s2mps11 that have to be instantiated should be
included in a sub-node named 'regulators'. Regulator nodes included in this
@ -81,12 +81,14 @@ as per the datasheet of s2mps11.
- LDOn
- valid values for n are:
- S2MPS11: 1 to 38
- S2MPS13: 1 to 40
- S2MPS14: 1 to 25
- S2MPU02: 1 to 28
- Example: LDO1, LDO2, LDO28
- BUCKn
- valid values for n are:
- S2MPS11: 1 to 10
- S2MPS13: 1 to 10
- S2MPS14: 1 to 5
- S2MPU02: 1 to 7
- Example: BUCK1, BUCK2, BUCK9

4
Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
View File

@ -18,6 +18,10 @@ Required Properties:
specific extensions.
- "samsung,exynos5420-dw-mshc": for controllers with Samsung Exynos5420
specific extensions.
- "samsung,exynos7-dw-mshc": for controllers with Samsung Exynos7
specific extensions.
- "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
specific extensions having an SMU.
* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
unit (ciu) clock. This property is applicable only for Exynos5 SoC's and

29
Documentation/devicetree/bindings/mmc/img-dw-mshc.txt Normal file
View File

@ -0,0 +1,29 @@
* Imagination specific extensions to the Synopsys Designware Mobile Storage
Host Controller
The Synopsys designware mobile storage host controller is used to interface
a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
differences between the core Synopsys dw mshc controller properties described
by synopsys-dw-mshc.txt and the properties used by the Imagination specific
extensions to the Synopsys Designware Mobile Storage Host Controller.
Required Properties:
* compatible: should be
- "img,pistachio-dw-mshc": for Pistachio SoCs
Example:
mmc@18142000 {
compatible = "img,pistachio-dw-mshc";
reg = <0x18142000 0x400>;
interrupts = <GIC_SHARED 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&system_clk>, <&sdhost_clk>;
clock-names = "biu", "ciu";
fifo-depth = <0x20>;
bus-width = <4>;
num-slots = <1>;
disable-wp;
};

7
Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
View File

@ -12,6 +12,10 @@ Required properties:
* for "marvell,armada-380-sdhci", two register areas. The first one
for the SDHCI registers themselves, and the second one for the
AXI/Mbus bridge registers of the SDHCI unit.
- clocks: Array of clocks required for SDHCI; requires at least one for
I/O clock.
- clock-names: Array of names corresponding to clocks property; shall be
"io" for I/O clock and "core" for optional core clock.
Optional properties:
- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
@ -23,6 +27,8 @@ sdhci@d4280800 {
reg = <0xd4280800 0x800>;
bus-width = <8>;
interrupts = <27>;
clocks = <&chip CLKID_SDIO1XIN>, <&chip CLKID_SDIO1>;
clock-names = "io", "core";
non-removable;
mrvl,clk-delay-cycles = <31>;
};
@ -32,5 +38,6 @@ sdhci@d8000 {
reg = <0xd8000 0x1000>, <0xdc000 0x100>;
interrupts = <0 25 0x4>;
clocks = <&gateclk 17>;
clock-names = "io";
mrvl,clk-delay-cycles = <0x1F>;
};

62
Documentation/devicetree/bindings/nios2/nios2.txt Normal file
View File

@ -0,0 +1,62 @@
* Nios II Processor Binding
This binding specifies what properties available in the device tree
representation of a Nios II Processor Core.
Users can use sopc2dts tool for generating device tree sources (dts) from a
Qsys system. See more detail in: http://www.alterawiki.com/wiki/Sopc2dts
Required properties:
- compatible: Compatible property value should be "altr,nios2-1.0".
- reg: Contains CPU index.
- interrupt-controller: Specifies that the node is an interrupt controller
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source, should be 1.
- clock-frequency: Contains the clock frequency for CPU, in Hz.
- dcache-line-size: Contains data cache line size.
- icache-line-size: Contains instruction line size.
- dcache-size: Contains data cache size.
- icache-size: Contains instruction cache size.
- altr,pid-num-bits: Specifies the number of bits to use to represent the process
identifier (PID).
- altr,tlb-num-ways: Specifies the number of set-associativity ways in the TLB.
- altr,tlb-num-entries: Specifies the number of entries in the TLB.
- altr,tlb-ptr-sz: Specifies size of TLB pointer.
- altr,has-mul: Specifies CPU hardware multipy support, should be 1.
- altr,has-mmu: Specifies CPU support MMU support, should be 1.
- altr,has-initda: Specifies CPU support initda instruction, should be 1.
- altr,reset-addr: Specifies CPU reset address
- altr,fast-tlb-miss-addr: Specifies CPU fast TLB miss exception address
- altr,exception-addr: Specifies CPU exception address
Optional properties:
- altr,has-div: Specifies CPU hardware divide support
- altr,implementation: Nios II core implementation, this should be "fast";
Example:
cpu@0x0 {
device_type = "cpu";
compatible = "altr,nios2-1.0";
reg = <0>;
interrupt-controller;
#interrupt-cells = <1>;
clock-frequency = <125000000>;
dcache-line-size = <32>;
icache-line-size = <32>;
dcache-size = <32768>;
icache-size = <32768>;
altr,implementation = "fast";
altr,pid-num-bits = <8>;
altr,tlb-num-ways = <16>;
altr,tlb-num-entries = <128>;
altr,tlb-ptr-sz = <7>;
altr,has-div = <1>;
altr,has-mul = <1>;
altr,reset-addr = <0xc2800000>;
altr,fast-tlb-miss-addr = <0xc7fff400>;
altr,exception-addr = <0xd0000020>;
altr,has-initda = <1>;
altr,has-mmu = <1>;
};

19
Documentation/devicetree/bindings/nios2/timer.txt Normal file
View File

@ -0,0 +1,19 @@
Altera Timer
Required properties:
- compatible : should be "altr,timer-1.0"
- reg : Specifies base physical address and size of the registers.
- interrupt-parent: phandle of the interrupt controller
- interrupts : Should contain the timer interrupt number
- clock-frequency : The frequency of the clock that drives the counter, in Hz.
Example:
timer {
compatible = "altr,timer-1.0";
reg = <0x00400000 0x00000020>;
interrupt-parent = <&cpu>;
interrupts = <11>;
clock-frequency = <125000000>;
};

11
Documentation/devicetree/bindings/pci/pci.txt
View File

@ -7,3 +7,14 @@ And for the interrupt mapping part:
Open Firmware Recommended Practice: Interrupt Mapping
http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
Additionally to the properties specified in the above standards a host bridge
driver implementation may support the following properties:
- linux,pci-domain:
If present this property assigns a fixed PCI domain number to a host bridge,
otherwise an unstable (across boots) unique number will be assigned.
It is required to either not set this property at all or set it for all
host bridges in the system, otherwise potentially conflicting domain numbers
may be assigned to root buses behind different host bridges. The domain
number for each host bridge in the system must be unique.

2
Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt
View File

@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
TZ1090-PDC's pin configuration nodes act as a container for an abitrary number
TZ1090-PDC's pin configuration nodes act as a container for an arbitrary number
of subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

2
Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt
View File

@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
TZ1090's pin configuration nodes act as a container for an abitrary number of
TZ1090's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

2
Documentation/devicetree/bindings/pinctrl/lantiq,falcon-pinumx.txt
View File

@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
Lantiq's pin configuration nodes act as a container for an abitrary number of
Lantiq's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those group(s), and two pin configuration parameters:

2
Documentation/devicetree/bindings/pinctrl/lantiq,xway-pinumx.txt
View File

@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
Lantiq's pin configuration nodes act as a container for an abitrary number of
Lantiq's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those group(s), and two pin configuration parameters:

2
Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt
View File

@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
Tegra's pin configuration nodes act as a container for an abitrary number of
Tegra's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

2
Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt
View File

@ -13,7 +13,7 @@ Optional properties:
Please refer to pinctrl-bindings.txt in this directory for details of the common
pinctrl bindings used by client devices.
SiRFprimaII's pinmux nodes act as a container for an abitrary number of subnodes.
SiRFprimaII's pinmux nodes act as a container for an arbitrary number of subnodes.
Each of these subnodes represents some desired configuration for a group of pins.
Required subnode-properties:

2
Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt
View File

@ -32,7 +32,7 @@ Required properties:
Please refer to pinctrl-bindings.txt in this directory for details of the common
pinctrl bindings used by client devices.
SPEAr's pinmux nodes act as a container for an abitrary number of subnodes. Each
SPEAr's pinmux nodes act as a container for an arbitrary number of subnodes. Each
of these subnodes represents muxing for a pin, a group, or a list of pins or
groups.

2
Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
View File

@ -18,7 +18,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
Qualcomm's pin configuration nodes act as a container for an abitrary number of
Qualcomm's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

2
Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
View File

@ -47,7 +47,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
The pin configuration nodes act as a container for an abitrary number of
The pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

2
Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
View File

@ -18,7 +18,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
Qualcomm's pin configuration nodes act as a container for an abitrary number of
Qualcomm's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

2
Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
View File

@ -47,7 +47,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
The pin configuration nodes act as a container for an abitrary number of
The pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

2
Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
View File

@ -18,7 +18,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
Qualcomm's pin configuration nodes act as a container for an abitrary number of
Qualcomm's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration

18
Documentation/devicetree/bindings/power/power-controller.txt Normal file
View File

@ -0,0 +1,18 @@
* Generic system power control capability
Power-management integrated circuits or miscellaneous hardware components are
sometimes able to control the system power. The device driver associated with these
components might need to define this capability, which tells the kernel that
it can be used to switch off the system. The corresponding device must have the
standard property "system-power-controller" in its device node. This property
marks the device as able to control the system power. In order to test if this
property is found programmatically, use the helper function
"of_device_is_system_power_controller" from of.h .
Example:
act8846: act8846@5 {
compatible = "active-semi,act8846";
status = "okay";
system-power-controller;
}

23
Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt Normal file
View File

@ -0,0 +1,23 @@
i.mx6 Poweroff Driver
SNVS_LPCR in SNVS module can power off the whole system by pull
PMIC_ON_REQ low if PMIC_ON_REQ is connected with external PMIC.
If you don't want to use PMIC_ON_REQ as power on/off control,
please set status='disabled' to disable this driver.
Required Properties:
-compatible: "fsl,sec-v4.0-poweroff"
-reg: Specifies the physical address of the SNVS_LPCR register
Example:
snvs@020cc000 {
compatible = "fsl,sec-v4.0-mon", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x020cc000 0x4000>;
.....
snvs_poweroff: snvs-poweroff@38 {
compatible = "fsl,sec-v4.0-poweroff";
reg = <0x38 0x4>;
};
}

4
Documentation/devicetree/bindings/regulator/act8865-regulator.txt
View File

@ -5,6 +5,10 @@ Required properties:
- compatible: "active-semi,act8846" or "active-semi,act8865"
- reg: I2C slave address
Optional properties:
- system-power-controller: Telling whether or not this pmic is controlling
the system power. See Documentation/devicetree/bindings/power/power-controller.txt .
Any standard regulator properties can be used to configure the single regulator.
The valid names for regulators are:

35
Documentation/devicetree/bindings/regulator/max77802.txt
View File

@ -25,6 +25,29 @@ with their hardware counterparts as follow. The valid names are:
example: LDO1, LDO2, LDO35.
-BUCKn : for BUCKs, where n can lie in range 1 to 10.
example: BUCK1, BUCK5, BUCK10.
The max77802 regulator supports two different operating modes: Normal and Low
Power Mode. Some regulators support the modes to be changed at startup or by
the consumers during normal operation while others only support to change the
mode during system suspend. The standard regulator suspend states binding can
be used to configure the regulator operating mode.
The regulators that support the standard "regulator-initial-mode" property,
changing their mode during normal operation are: LDOs 1, 3, 20 and 21.
The possible values for "regulator-initial-mode" and "regulator-mode" are:
1: Normal regulator voltage output mode.
3: Low Power which reduces the quiescent current down to only 1uA
The list of valid modes are defined in the dt-bindings/clock/maxim,max77802.h
header and can be included by device tree source files.
The standard "regulator-mode" property can only be used for regulators that
support changing their mode to Low Power Mode during suspend. These regulators
are: BUCKs 2-4 and LDOs 1-35. Also, it only takes effect if the regulator has
been enabled for the given suspend state using "regulator-on-in-suspend" and
has not been disabled for that state using "regulator-off-in-suspend".
Example:
max77802@09 {
@ -36,11 +59,23 @@ Example:
#size-cells = <0>;
regulators {
ldo1_reg: LDO1 {
regulator-name = "vdd_1v0";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <MAX77802_OPMODE_LP>;
};
ldo11_reg: LDO11 {
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <1900000>;
regulator-max-microvolt = <1900000>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <MAX77802_OPMODE_LP>;
};
};
buck1_reg: BUCK1 {

22
Documentation/devicetree/bindings/regulator/regulator.txt
View File

@ -19,6 +19,24 @@ Optional properties:
design requires. This property describes the total system ramp time
required due to the combination of internal ramping of the regulator itself,
and board design issues such as trace capacitance and load on the supply.
- regulator-state-mem sub-root node for Suspend-to-RAM mode
: suspend to memory, the device goes to sleep, but all data stored in memory,
only some external interrupt can wake the device.
- regulator-state-disk sub-root node for Suspend-to-DISK mode
: suspend to disk, this state operates similarly to Suspend-to-RAM,
but includes a final step of writing memory contents to disk.
- regulator-state-[mem/disk] node has following common properties:
- regulator-on-in-suspend: regulator should be on in suspend state.
- regulator-off-in-suspend: regulator should be off in suspend state.
- regulator-suspend-microvolt: regulator should be set to this voltage
in suspend.
- regulator-mode: operating mode in the given suspend state.
The set of possible operating modes depends on the capabilities of
every hardware so the valid modes are documented on each regulator
device tree binding document.
- regulator-initial-mode: initial operating mode. The set of possible operating
modes depends on the capabilities of every hardware so each device binding
documentation explains which values the regulator supports.
Deprecated properties:
- regulator-compatible: If a regulator chip contains multiple
@ -34,6 +52,10 @@ Example:
regulator-max-microvolt = <2500000>;
regulator-always-on;
vin-supply = <&vin>;
regulator-state-mem {
regulator-on-in-suspend;
};
};
Regulator Consumers:

6
Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
View File

@ -1,6 +1,7 @@
SKY81452 voltage regulator
Required properties:
- regulator node named lout.
- any required generic properties defined in regulator.txt
Optional properties:
@ -9,8 +10,9 @@ Optional properties:
Example:
regulator {
/* generic regulator properties */
regulator-name = "touch_en";
lout {
regulator-name = "sky81452-lout";
regulator-min-microvolt = <4500000>;
regulator-max-microvolt = <8000000>;
};
};

42
Documentation/devicetree/bindings/reset/st,sti-picophyreset.txt Normal file
View File

@ -0,0 +1,42 @@
STMicroelectronics STi family Sysconfig Picophy SoftReset Controller
=============================================================================
This binding describes a reset controller device that is used to enable and
disable on-chip PicoPHY USB2 phy(s) using "softreset" control bits found in
the STi family SoC system configuration registers.
The actual action taken when softreset is asserted is hardware dependent.
However, when asserted it may not be possible to access the hardware's
registers and after an assert/deassert sequence the hardware's previous state
may no longer be valid.
Please refer to Documentation/devicetree/bindings/reset/reset.txt
for common reset controller binding usage.
Required properties:
- compatible: Should be "st,stih407-picophyreset"
- #reset-cells: 1, see below
Example:
picophyreset: picophyreset-controller {
compatible = "st,stih407-picophyreset";
#reset-cells = <1>;
};
Specifying picophyreset control of devices
=======================================
Device nodes should specify the reset channel required in their "resets"
property, containing a phandle to the picophyreset device node and an
index specifying which channel to use, as described in
Documentation/devicetree/bindings/reset/reset.txt.
Example:
usb2_picophy0: usbpicophy@0 {
resets = <&picophyreset STIH407_PICOPHY0_RESET>;
};
Macro definitions for the supported reset channels can be found in:
include/dt-bindings/reset-controller/stih407-resets.h

23
Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt Normal file
View File

@ -0,0 +1,23 @@
Atmel AT91SAM9260 Real Time Timer
Required properties:
- compatible: should be: "atmel,at91sam9260-rtt"
- reg: should encode the memory region of the RTT controller
- interrupts: rtt alarm/event interrupt
- clocks: should contain the 32 KHz slow clk that will drive the RTT block.
- atmel,rtt-rtc-time-reg: should encode the GPBR register used to store
the time base when the RTT is used as an RTC.
The first cell should point to the GPBR node and the second one
encode the offset within the GPBR block (or in other words, the
GPBR register used to store the time base).
Example:
rtt@fffffd20 {
compatible = "atmel,at91sam9260-rtt";
reg = <0xfffffd20 0x10>;
interrupts = <1 4 7>;
clocks = <&clk32k>;
atmel,rtt-rtc-time-reg = <&gpbr 0x0>;
};

5
Documentation/devicetree/bindings/thermal/rcar-thermal.txt
View File

@ -7,7 +7,10 @@ Required properties:
- "renesas,thermal-r8a73a4" (R-Mobile AP6)
- "renesas,thermal-r8a7779" (R-Car H1)
- "renesas,thermal-r8a7790" (R-Car H2)
- "renesas,thermal-r8a7791" (R-Car M2)
- "renesas,thermal-r8a7791" (R-Car M2-W)
- "renesas,thermal-r8a7792" (R-Car V2H)
- "renesas,thermal-r8a7793" (R-Car M2-N)
- "renesas,thermal-r8a7794" (R-Car E2)
- reg : Address range of the thermal registers.
The 1st reg will be recognized as common register
if it has "interrupts".

9
Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
View File

@ -2,8 +2,10 @@ Marvell Armada 370 and Armada XP Timers
---------------------------------------
Required properties:
- compatible: Should be either "marvell,armada-370-timer" or
"marvell,armada-xp-timer" as appropriate.
- compatible: Should be one of the following
"marvell,armada-370-timer",
"marvell,armada-375-timer",
"marvell,armada-xp-timer".
- interrupts: Should contain the list of Global Timer interrupts and
then local timer interrupts
- reg: Should contain location and length for timers register. First
@ -13,7 +15,8 @@ Required properties:
Clocks required for compatible = "marvell,armada-370-timer":
- clocks : Must contain a single entry describing the clock input
Clocks required for compatible = "marvell,armada-xp-timer":
Clocks required for compatibles = "marvell,armada-xp-timer",
"marvell,armada-375-timer":
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"nbclk" (L2/coherency fabric clock),

2
Documentation/devicetree/bindings/timer/renesas,mtu2.txt
View File

@ -1,4 +1,4 @@
* Renesas R-Car Multi-Function Timer Pulse Unit 2 (MTU2)
* Renesas Multi-Function Timer Pulse Unit 2 (MTU2)
The MTU2 is a multi-purpose, multi-channel timer/counter with configurable
clock inputs and programmable compare match.

4
Documentation/devicetree/bindings/timer/renesas,tmu.txt
View File

@ -1,4 +1,4 @@
* Renesas R-Car Timer Unit (TMU)
* Renesas R-Mobile/R-Car Timer Unit (TMU)
The TMU is a 32-bit timer/counter with configurable clock inputs and
programmable compare match.
@ -9,6 +9,8 @@ are independent. The TMU hardware supports up to three channels.
Required Properties:
- compatible: must contain one or more of the following:
- "renesas,tmu-r8a7740" for the r8a7740 TMU
- "renesas,tmu-r8a7778" for the r8a7778 TMU
- "renesas,tmu-r8a7779" for the r8a7779 TMU
- "renesas,tmu" for any TMU.
This is a fallback for the above renesas,tmu-* entries

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

@ -34,12 +34,14 @@ chipidea Chipidea, Inc
chrp Common Hardware Reference Platform
chunghwa Chunghwa Picture Tubes Ltd.
cirrus Cirrus Logic, Inc.
cnm Chips&Media, Inc.
cortina Cortina Systems, Inc.
crystalfontz Crystalfontz America, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
denx Denx Software Engineering
digi Digi International Inc.
digilent Diglent, Inc.
dlg Dialog Semiconductor
dlink D-Link Corporation
dmo Data Modul AG
@ -77,6 +79,7 @@ innolux Innolux Corporation
intel Intel Corporation
intercontrol Inter Control Group
isee ISEE 2007 S.L.
isil Intersil (deprecated, use isl)
isl Intersil
karo Ka-Ro electronics GmbH
keymile Keymile GmbH
@ -90,8 +93,10 @@ lltc Linear Technology Corporation
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
mediatek MediaTek Inc.
merrii Merrii Technology Co., Ltd.
micrel Micrel Inc.
microchip Microchip Technology Inc.
micron Micron Technology Inc.
mitsubishi Mitsubishi Electric Corporation
mosaixtech Mosaix Technologies, Inc.
moxa Moxa
@ -127,6 +132,7 @@ renesas Renesas Electronics Corporation
ricoh Ricoh Co. Ltd.
rockchip Fuzhou Rockchip Electronics Co., Ltd
samsung Samsung Semiconductor
sandisk Sandisk Corporation
sbs Smart Battery System
schindler Schindler
seagate Seagate Technology PLC
@ -146,6 +152,7 @@ st STMicroelectronics
ste ST-Ericsson
stericsson ST-Ericsson
synology Synology, Inc.
tbs TBS Technologies
thine THine Electronics, Inc.
ti Texas Instruments
tlm Trusted Logic Mobility

17
Documentation/devicetree/bindings/w1/omap-hdq.txt Normal file
View File

@ -0,0 +1,17 @@
* OMAP HDQ One wire bus master controller
Required properties:
- compatible : should be "ti,omap3-1w"
- reg : Address and length of the register set for the device
- interrupts : interrupt line.
- ti,hwmods : "hdq1w"
Example:
- From omap3.dtsi
hdqw1w: 1w@480b2000 {
compatible = "ti,omap3-1w";
reg = <0x480b2000 0x1000>;
interrupts = <58>;
ti,hwmods = "hdq1w";
};

13
Documentation/devicetree/bindings/watchdog/marvel.txt
View File

@ -17,6 +17,18 @@ For "marvell,armada-375-wdt" and "marvell,armada-380-wdt":
- reg : A third entry is mandatory and should contain the
shared mask/unmask RSTOUT address.
Clocks required for compatibles = "marvell,orion-wdt",
"marvell,armada-370-wdt":
- clocks : Must contain a single entry describing the clock input
Clocks required for compatibles = "marvell,armada-xp-wdt"
"marvell,armada-375-wdt"
"marvell,armada-380-wdt":
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"nbclk" (L2/coherency fabric clock),
"fixed" (Reference 25 MHz fixed-clock).
Optional properties:
- interrupts : Contains the IRQ for watchdog expiration
@ -30,4 +42,5 @@ Example:
interrupts = <3>;
timeout-sec = <10>;
status = "okay";
clocks = <&gate_clk 7>;
};

2
Documentation/filesystems/overlayfs.txt
View File

@ -64,7 +64,7 @@ is formed.
At mount time, the two directories given as mount options "lowerdir" and
"upperdir" are combined into a merged directory:
mount -t overlayfs overlayfs -olowerdir=/lower,upperdir=/upper,\
mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
workdir=/work /merged
The "workdir" needs to be an empty directory on the same filesystem

5
Documentation/hwmon/lm75
View File

@ -53,6 +53,11 @@ Supported chips:
http://www.ti.com/product/tmp75
http://www.ti.com/product/tmp175
http://www.ti.com/product/tmp275
* NXP LM75B
Prefix: 'lm75b'
Addresses scanned: none
Datasheet: Publicly available at the NXP website
http://www.nxp.com/documents/data_sheet/LM75B.pdf
Author: Frodo Looijaard <frodol@dds.nl>

15
Documentation/hwmon/lm95234
View File

@ -2,6 +2,10 @@ Kernel driver lm95234
=====================
Supported chips:
* National Semiconductor / Texas Instruments LM95233
Addresses scanned: I2C 0x18, 0x2a, 0x2b
Datasheet: Publicly available at the Texas Instruments website
http://www.ti.com/product/lm95233
* National Semiconductor / Texas Instruments LM95234
Addresses scanned: I2C 0x18, 0x4d, 0x4e
Datasheet: Publicly available at the Texas Instruments website
@ -13,11 +17,12 @@ 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
LM95233 and LM95234 are 11-bit digital temperature sensors with a 2-wire
System Management Bus (SMBus) interface and TrueTherm technology
that can very accurately monitor the temperature of two (LM95233)
or four (LM95234) remote diodes as well as its own temperature.
The remote diodes can be external devices such as microprocessors,
graphics processors or diode-connected 2N3904s. The chip's TruTherm
beta compensation technology allows sensing of 90 nm or 65 nm process
thermal diodes accurately.

14
Documentation/hwmon/lm95245
View File

@ -2,10 +2,14 @@ Kernel driver lm95245
==================
Supported chips:
* National Semiconductor LM95245
* TI LM95235
Addresses scanned: I2C 0x18, 0x29, 0x4c
Datasheet: Publicly available at the TI website
http://www.ti.com/lit/ds/symlink/lm95235.pdf
* TI / National Semiconductor LM95245
Addresses scanned: I2C 0x18, 0x19, 0x29, 0x4c, 0x4d
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/mpf/LM/LM95245.html
Datasheet: Publicly available at the TI website
http://www.ti.com/lit/ds/symlink/lm95245.pdf
Author: Alexander Stein <alexander.stein@systec-electronic.com>
@ -13,10 +17,10 @@ Author: Alexander Stein <alexander.stein@systec-electronic.com>
Description
-----------
The LM95245 is an 11-bit digital temperature sensor with a 2-wire System
LM95235 and LM95245 are 11-bit digital temperature sensors with a 2-wire System
Management Bus (SMBus) interface and TruTherm technology that can monitor
the temperature of a remote diode as well as its own temperature.
The LM95245 can be used to very accurately monitor the temperature of
The chips can be used to very accurately monitor the temperature of
external devices such as microprocessors.
All temperature values are given in millidegrees Celsius. Local temperature

14
Documentation/hwmon/nct6775
View File

@ -8,11 +8,15 @@ Kernel driver NCT6775
=====================
Supported chips:
* Nuvoton NCT6102D/NCT6104D/NCT6106D
Prefix: 'nct6106'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from the Nuvoton web site
* 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
* Nuvoton NCT5573D/NCT5577D/NCT6776D/NCT6776F
Prefix: 'nct6776'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
@ -20,6 +24,14 @@ Supported chips:
Prefix: 'nct6779'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
* Nuvoton NCT6791D
Prefix: 'nct6791'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
* Nuvoton NCT6792D
Prefix: 'nct6792'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
Authors:
Guenter Roeck <linux@roeck-us.net>

32
Documentation/hwmon/nct7802 Normal file
View File

@ -0,0 +1,32 @@
Kernel driver nct7802
=====================
Supported chips:
* Nuvoton NCT7802Y
Prefix: 'nct7802'
Addresses scanned: I2C 0x28..0x2f
Datasheet: Available from Nuvoton web site
Authors:
Guenter Roeck <linux@roeck-us.net>
Description
-----------
This driver implements support for the Nuvoton NCT7802Y hardware monitoring
chip. NCT7802Y supports 6 temperature sensors, 5 voltage sensors, and 3 fan
speed sensors.
The chip also supports intelligent fan speed control. This functionality is
not currently supported by the driver.
Tested Boards and BIOS Versions
-------------------------------
The driver has been reported to work with the following boards and
BIOS versions.
Board BIOS version
---------------------------------------------------------------
Kontron COMe-bSC2 CHR2E934.001.GGO
Kontron COMe-bIP2 CCR2E212

8
Documentation/hwmon/tmp401
View File

@ -18,6 +18,10 @@ Supported chips:
Prefix: 'tmp432'
Addresses scanned: I2C 0x4c, 0x4d
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp432.html
* Texas Instruments TMP435
Prefix: 'tmp435'
Addresses scanned: I2C 0x37, 0x48 - 0x4f
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html
Authors:
Hans de Goede <hdegoede@redhat.com>
@ -27,8 +31,8 @@ Description
-----------
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
TMP431, TMP432 and TMP435 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

81
Documentation/input/elantech.txt
View File

@ -38,22 +38,38 @@ Contents
7.2.1 Status packet
7.2.2 Head packet
7.2.3 Motion packet
8. Trackpoint (for Hardware version 3 and 4)
8.1 Registers
8.2 Native relative mode 6 byte packet format
8.2.1 Status Packet
1. Introduction
~~~~~~~~~~~~
Currently the Linux Elantech touchpad driver is aware of two different
hardware versions unimaginatively called version 1 and version 2. Version 1
is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to
be introduced with the EeePC and uses 6 bytes per packet, and provides
additional features such as position of two fingers, and width of the touch.
Currently the Linux Elantech touchpad driver is aware of four different
hardware versions unimaginatively called version 1,version 2, version 3
and version 4. Version 1 is found in "older" laptops and uses 4 bytes per
packet. Version 2 seems to be introduced with the EeePC and uses 6 bytes
per packet, and provides additional features such as position of two fingers,
and width of the touch. Hardware version 3 uses 6 bytes per packet (and
for 2 fingers the concatenation of two 6 bytes packets) and allows tracking
of up to 3 fingers. Hardware version 4 uses 6 bytes per packet, and can
combine a status packet with multiple head or motion packets. Hardware version
4 allows tracking up to 5 fingers.
Some Hardware version 3 and version 4 also have a trackpoint which uses a
separate packet format. It is also 6 bytes per packet.
The driver tries to support both hardware versions and should be compatible
with the Xorg Synaptics touchpad driver and its graphical configuration
utilities.
Note that a mouse button is also associated with either the touchpad or the
trackpoint when a trackpoint is available. Disabling the Touchpad in xorg
(TouchPadOff=0) will also disable the buttons associated with the touchpad.
Additionally the operation of the touchpad can be altered by adjusting the
contents of some of its internal registers. These registers are represented
by the driver as sysfs entries under /sys/bus/serio/drivers/psmouse/serio?
@ -78,7 +94,7 @@ completeness sake.
2. Extra knobs
~~~~~~~~~~~
Currently the Linux Elantech touchpad driver provides two extra knobs under
Currently the Linux Elantech touchpad driver provides three extra knobs under
/sys/bus/serio/drivers/psmouse/serio? for the user.
* debug
@ -112,6 +128,20 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under
data consistency checking can be done. For now checking is disabled by
default. Currently even turning it on will do nothing.
* crc_enabled
Sets crc_enabled to 0/1. The name "crc_enabled" is the official name of
this integrity check, even though it is not an actual cyclic redundancy
check.
Depending on the state of crc_enabled, certain basic data integrity
verification is done by the driver on hardware version 3 and 4. The
driver will reject any packet that appears corrupted. Using this knob,
The state of crc_enabled can be altered with this knob.
Reading the crc_enabled value will show the active value. Echoing
"0" or "1" to this file will set the state to "0" or "1".
/////////////////////////////////////////////////////////////////////////////
3. Differentiating hardware versions
@ -746,3 +776,42 @@ byte 5:
byte 0 ~ 2 for one finger
byte 3 ~ 5 for another
8. Trackpoint (for Hardware version 3 and 4)
=========================================
8.1 Registers
~~~~~~~~~
No special registers have been identified.
8.2 Native relative mode 6 byte packet format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8.2.1 Status Packet
~~~~~~~~~~~~~
byte 0:
bit 7 6 5 4 3 2 1 0
0 0 sx sy 0 M R L
byte 1:
bit 7 6 5 4 3 2 1 0
~sx 0 0 0 0 0 0 0
byte 2:
bit 7 6 5 4 3 2 1 0
~sy 0 0 0 0 0 0 0
byte 3:
bit 7 6 5 4 3 2 1 0
0 0 ~sy ~sx 0 1 1 0
byte 4:
bit 7 6 5 4 3 2 1 0
x7 x6 x5 x4 x3 x2 x1 x0
byte 5:
bit 7 6 5 4 3 2 1 0
y7 y6 y5 y4 y3 y2 y1 y0
x and y are written in two's complement spread
over 9 bits with sx/sy the relative top bit and
x7..x0 and y7..y0 the lower bits.
~sx is the inverse of sx, ~sy is the inverse of sy.
The sign of y is opposite to what the input driver
expects for a relative movement

18
Documentation/kernel-parameters.txt
View File

@ -2940,6 +2940,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
quiescent states. Units are jiffies, minimum
value is one, and maximum value is HZ.
rcutree.kthread_prio= [KNL,BOOT]
Set the SCHED_FIFO priority of the RCU
per-CPU kthreads (rcuc/N). This value is also
used for the priority of the RCU boost threads
(rcub/N). Valid values are 1-99 and the default
is 1 (the least-favored priority).
rcutree.rcu_nocb_leader_stride= [KNL]
Set the number of NOCB kthread groups, which
defaults to the square root of the number of
@ -3089,6 +3096,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
messages. Disable with a value less than or equal
to zero.
rcupdate.rcu_self_test= [KNL]
Run the RCU early boot self tests
rcupdate.rcu_self_test_bh= [KNL]
Run the RCU bh early boot self tests
rcupdate.rcu_self_test_sched= [KNL]
Run the RCU sched early boot self tests
rdinit= [KNL]
Format: <full_path>
Run specified binary instead of /init from the ramdisk,
@ -3621,7 +3637,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
usb-storage.delay_use=
[UMS] The delay in seconds before a new device is
scanned for Logical Units (default 5).
scanned for Logical Units (default 1).
usb-storage.quirks=
[UMS] A list of quirks entries to supplement or

166
Documentation/locking/lglock.txt Normal file
View File

@ -0,0 +1,166 @@
lglock - local/global locks for mostly local access patterns
------------------------------------------------------------
Origin: Nick Piggin's VFS scalability series introduced during
2.6.35++ [1] [2]
Location: kernel/locking/lglock.c
include/linux/lglock.h
Users: currently only the VFS and stop_machine related code
Design Goal:
------------
Improve scalability of globally used large data sets that are
distributed over all CPUs as per_cpu elements.
To manage global data structures that are partitioned over all CPUs
as per_cpu elements but can be mostly handled by CPU local actions
lglock will be used where the majority of accesses are cpu local
reading and occasional cpu local writing with very infrequent
global write access.
* deal with things locally whenever possible
- very fast access to the local per_cpu data
- reasonably fast access to specific per_cpu data on a different
CPU
* while making global action possible when needed
- by expensive access to all CPUs locks - effectively
resulting in a globally visible critical section.
Design:
-------
Basically it is an array of per_cpu spinlocks with the
lg_local_lock/unlock accessing the local CPUs lock object and the
lg_local_lock_cpu/unlock_cpu accessing a remote CPUs lock object
the lg_local_lock has to disable preemption as migration protection so
that the reference to the local CPUs lock does not go out of scope.
Due to the lg_local_lock/unlock only touching cpu-local resources it
is fast. Taking the local lock on a different CPU will be more
expensive but still relatively cheap.
One can relax the migration constraints by acquiring the current
CPUs lock with lg_local_lock_cpu, remember the cpu, and release that
lock at the end of the critical section even if migrated. This should
give most of the performance benefits without inhibiting migration
though needs careful considerations for nesting of lglocks and
consideration of deadlocks with lg_global_lock.
The lg_global_lock/unlock locks all underlying spinlocks of all
possible CPUs (including those off-line). The preemption disable/enable
are needed in the non-RT kernels to prevent deadlocks like:
on cpu 1
task A task B
lg_global_lock
got cpu 0 lock
<<<< preempt <<<<
lg_local_lock_cpu for cpu 0
spin on cpu 0 lock
On -RT this deadlock scenario is resolved by the arch_spin_locks in the
lglocks being replaced by rt_mutexes which resolve the above deadlock
by boosting the lock-holder.
Implementation:
---------------
The initial lglock implementation from Nick Piggin used some complex
macros to generate the lglock/brlock in lglock.h - they were later
turned into a set of functions by Andi Kleen [7]. The change to functions
was motivated by the presence of multiple lock users and also by them
being easier to maintain than the generating macros. This change to
functions is also the basis to eliminated the restriction of not
being initializeable in kernel modules (the remaining problem is that
locks are not explicitly initialized - see lockdep-design.txt)
Declaration and initialization:
-------------------------------
#include <linux/lglock.h>
DEFINE_LGLOCK(name)
or:
DEFINE_STATIC_LGLOCK(name);
lg_lock_init(&name, "lockdep_name_string");
on UP this is mapped to DEFINE_SPINLOCK(name) in both cases, note
also that as of 3.18-rc6 all declaration in use are of the _STATIC_
variant (and it seems that the non-static was never in use).
lg_lock_init is initializing the lockdep map only.
Usage:
------
From the locking semantics it is a spinlock. It could be called a
locality aware spinlock. lg_local_* behaves like a per_cpu
spinlock and lg_global_* like a global spinlock.
No surprises in the API.
lg_local_lock(*lglock);
access to protected per_cpu object on this CPU
lg_local_unlock(*lglock);
lg_local_lock_cpu(*lglock, cpu);
access to protected per_cpu object on other CPU cpu
lg_local_unlock_cpu(*lglock, cpu);
lg_global_lock(*lglock);
access all protected per_cpu objects on all CPUs
lg_global_unlock(*lglock);
There are no _trylock variants of the lglocks.
Note that the lg_global_lock/unlock has to iterate over all possible
CPUs rather than the actually present CPUs or a CPU could go off-line
with a held lock [4] and that makes it very expensive. A discussion on
these issues can be found at [5]
Constraints:
------------
* currently the declaration of lglocks in kernel modules is not
possible, though this should be doable with little change.
* lglocks are not recursive.
* suitable for code that can do most operations on the CPU local
data and will very rarely need the global lock
* lg_global_lock/unlock is *very* expensive and does not scale
* on UP systems all lg_* primitives are simply spinlocks
* in PREEMPT_RT the spinlock becomes an rt-mutex and can sleep but
does not change the tasks state while sleeping [6].
* in PREEMPT_RT the preempt_disable/enable in lg_local_lock/unlock
is downgraded to a migrate_disable/enable, the other
preempt_disable/enable are downgraded to barriers [6].
The deadlock noted for non-RT above is resolved due to rt_mutexes
boosting the lock-holder in this case which arch_spin_locks do
not do.
lglocks were designed for very specific problems in the VFS and probably
only are the right answer in these corner cases. Any new user that looks
at lglocks probably wants to look at the seqlock and RCU alternatives as
her first choice. There are also efforts to resolve the RCU issues that
currently prevent using RCU in place of view remaining lglocks.
Note on brlock history:
-----------------------
The 'Big Reader' read-write spinlocks were originally introduced by
Ingo Molnar in 2000 (2.4/2.5 kernel series) and removed in 2003. They
later were introduced by the VFS scalability patch set in 2.6 series
again as the "big reader lock" brlock [2] variant of lglock which has
been replaced by seqlock primitives or by RCU based primitives in the
3.13 kernel series as was suggested in [3] in 2003. The brlock was
entirely removed in the 3.13 kernel series.
Link: 1 http://lkml.org/lkml/2010/8/2/81
Link: 2 http://lwn.net/Articles/401738/
Link: 3 http://lkml.org/lkml/2003/3/9/205
Link: 4 https://lkml.org/lkml/2011/8/24/185
Link: 5 http://lkml.org/lkml/2011/12/18/189
Link: 6 https://www.kernel.org/pub/linux/kernel/projects/rt/
patch series - lglocks-rt.patch.patch
Link: 7 http://lkml.org/lkml/2012/3/5/26

51
Documentation/memory-barriers.txt
View File

@ -121,22 +121,22 @@ For example, consider the following sequence of events:
The set of accesses as seen by the memory system in the middle can be arranged
in 24 different combinations:
STORE A=3, STORE B=4, x=LOAD A->3, y=LOAD B->4
STORE A=3, STORE B=4, y=LOAD B->4, x=LOAD A->3
STORE A=3, x=LOAD A->3, STORE B=4, y=LOAD B->4
STORE A=3, x=LOAD A->3, y=LOAD B->2, STORE B=4
STORE A=3, y=LOAD B->2, STORE B=4, x=LOAD A->3
STORE A=3, y=LOAD B->2, x=LOAD A->3, STORE B=4
STORE B=4, STORE A=3, x=LOAD A->3, y=LOAD B->4
STORE A=3, STORE B=4, y=LOAD A->3, x=LOAD B->4
STORE A=3, STORE B=4, x=LOAD B->4, y=LOAD A->3
STORE A=3, y=LOAD A->3, STORE B=4, x=LOAD B->4
STORE A=3, y=LOAD A->3, x=LOAD B->2, STORE B=4
STORE A=3, x=LOAD B->2, STORE B=4, y=LOAD A->3
STORE A=3, x=LOAD B->2, y=LOAD A->3, STORE B=4
STORE B=4, STORE A=3, y=LOAD A->3, x=LOAD B->4
STORE B=4, ...
...
and can thus result in four different combinations of values:
x == 1, y == 2
x == 1, y == 4
x == 3, y == 2
x == 3, y == 4
x == 2, y == 1
x == 2, y == 3
x == 4, y == 1
x == 4, y == 3
Furthermore, the stores committed by a CPU to the memory system may not be
@ -694,6 +694,24 @@ Please note once again that the stores to 'b' differ. If they were
identical, as noted earlier, the compiler could pull this store outside
of the 'if' statement.
You must also be careful not to rely too much on boolean short-circuit
evaluation. Consider this example:
q = ACCESS_ONCE(a);
if (a || 1 > 0)
ACCESS_ONCE(b) = 1;
Because the second condition is always true, the compiler can transform
this example as following, defeating control dependency:
q = ACCESS_ONCE(a);
ACCESS_ONCE(b) = 1;
This example underscores the need to ensure that the compiler cannot
out-guess your code. More generally, although ACCESS_ONCE() does force
the compiler to actually emit code for a given load, it does not force
the compiler to use the results.
Finally, control dependencies do -not- provide transitivity. This is
demonstrated by two related examples, with the initial values of
x and y both being zero:
@ -2465,10 +2483,15 @@ functions:
Please refer to the PCI specification for more information on interactions
between PCI transactions.
(*) readX_relaxed()
(*) readX_relaxed(), writeX_relaxed()
These are similar to readX(), but are not guaranteed to be ordered in any
way. Be aware that there is no I/O read barrier available.
These are similar to readX() and writeX(), but provide weaker memory
ordering guarantees. Specifically, they do not guarantee ordering with
respect to normal memory accesses (e.g. DMA buffers) nor do they guarantee
ordering with respect to LOCK or UNLOCK operations. If the latter is
required, an mmiowb() barrier can be used. Note that relaxed accesses to
the same peripheral are guaranteed to be ordered with respect to each
other.
(*) ioreadX(), iowriteX()

14
Documentation/networking/ip-sysctl.txt
View File

@ -56,6 +56,13 @@ ip_forward_use_pmtu - BOOLEAN
0 - disabled
1 - enabled
fwmark_reflect - BOOLEAN
Controls the fwmark of kernel-generated IPv4 reply packets that are not
associated with a socket for example, TCP RSTs or ICMP echo replies).
If unset, these packets have a fwmark of zero. If set, they have the
fwmark of the packet they are replying to.
Default: 0
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
@ -1201,6 +1208,13 @@ conf/all/forwarding - BOOLEAN
proxy_ndp - BOOLEAN
Do proxy ndp.
fwmark_reflect - BOOLEAN
Controls the fwmark of kernel-generated IPv6 reply packets that are not
associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
If unset, these packets have a fwmark of zero. If set, they have the
fwmark of the packet they are replying to.
Default: 0
conf/interface/*:
Change special settings per interface.

2
Documentation/networking/timestamping.txt
View File

@ -136,7 +136,7 @@ SOF_TIMESTAMPING_OPT_ID:
This option is implemented only for transmit timestamps. There, the
timestamp is always looped along with a struct sock_extended_err.
The option modifies field ee_info to pass an id that is unique
The option modifies field ee_data to pass an id that is unique
among all possibly concurrently outstanding timestamp requests for
that socket. In practice, it is a monotonically increasing u32
(that wraps).

23
Documentation/nios2/README Normal file
View File

@ -0,0 +1,23 @@
Linux on the Nios II architecture
=================================
This is a port of Linux to Nios II (nios2) processor.
In order to compile for Nios II, you need a version of GCC with support for the generic
system call ABI. Please see this link for more information on how compiling and booting
software for the Nios II platform:
http://www.rocketboards.org/foswiki/Documentation/NiosIILinuxUserManual
For reference, please see the following link:
http://www.altera.com/literature/lit-nio2.jsp
What is Nios II?
================
Nios II is a 32-bit embedded-processor architecture designed specifically for the
Altera family of FPGAs. In order to support Linux, Nios II needs to be configured
with MMU and hardware multiplier enabled.
Nios II ABI
===========
Please refer to chapter "Application Binary Interface" in Nios II Processor Reference
Handbook.

82
Documentation/scsi/libsas.txt
View File

@ -226,9 +226,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha)
my_ha->sas_ha.lldd_dev_found = my_dev_found;
my_ha->sas_ha.lldd_dev_gone = my_dev_gone;
my_ha->sas_ha.lldd_max_execute_num = lldd_max_execute_num; (1)
my_ha->sas_ha.lldd_queue_size = ha_can_queue;
my_ha->sas_ha.lldd_execute_task = my_execute_task;
my_ha->sas_ha.lldd_abort_task = my_abort_task;
@ -247,28 +244,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha)
return sas_register_ha(&my_ha->sas_ha);
}
(1) This is normally a LLDD parameter, something of the
lines of a task collector. What it tells the SAS Layer is
whether the SAS layer should run in Direct Mode (default:
value 0 or 1) or Task Collector Mode (value greater than 1).
In Direct Mode, the SAS Layer calls Execute Task as soon as
it has a command to send to the SDS, _and_ this is a single
command, i.e. not linked.
Some hardware (e.g. aic94xx) has the capability to DMA more
than one task at a time (interrupt) from host memory. Task
Collector Mode is an optional feature for HAs which support
this in their hardware. (Again, it is completely optional
even if your hardware supports it.)
In Task Collector Mode, the SAS Layer would do _natural_
coalescing of tasks and at the appropriate moment it would
call your driver to DMA more than one task in a single HA
interrupt. DMBS may want to use this by insmod/modprobe
setting the lldd_max_execute_num to something greater than
1.
(2) SAS 1.1 does not define I_T Nexus Reset TMF.
Events
@ -325,71 +300,22 @@ PHYE_SPINUP_HOLD -- SATA is present, COMWAKE not sent.
The Execute Command SCSI RPC:
int (*lldd_execute_task)(struct sas_task *, int num,
unsigned long gfp_flags);
int (*lldd_execute_task)(struct sas_task *, gfp_t gfp_flags);
Used to queue a task to the SAS LLDD. @task is the tasks to
be executed. @num should be the number of tasks being
queued at this function call (they are linked listed via
task::list), @gfp_mask should be the gfp_mask defining the
context of the caller.
Used to queue a task to the SAS LLDD. @task is the task to be executed.
@gfp_mask is the gfp_mask defining the context of the caller.
This function should implement the Execute Command SCSI RPC,
or if you're sending a SCSI Task as linked commands, you
should also use this function.
That is, when lldd_execute_task() is called, the command(s)
That is, when lldd_execute_task() is called, the command
go out on the transport *immediately*. There is *no*
queuing of any sort and at any level in a SAS LLDD.
The use of task::list is two-fold, one for linked commands,
the other discussed below.
It is possible to queue up more than one task at a time, by
initializing the list element of struct sas_task, and
passing the number of tasks enlisted in this manner in num.
Returns: -SAS_QUEUE_FULL, -ENOMEM, nothing was queued;
0, the task(s) were queued.
If you want to pass num > 1, then either
A) you're the only caller of this function and keep track
of what you've queued to the LLDD, or
B) you know what you're doing and have a strategy of
retrying.
As opposed to queuing one task at a time (function call),
batch queuing of tasks, by having num > 1, greatly
simplifies LLDD code, sequencer code, and _hardware design_,
and has some performance advantages in certain situations
(DBMS).
The LLDD advertises if it can take more than one command at
a time at lldd_execute_task(), by setting the
lldd_max_execute_num parameter (controlled by "collector"
module parameter in aic94xx SAS LLDD).
You should leave this to the default 1, unless you know what
you're doing.
This is a function of the LLDD, to which the SAS layer can
cater to.
int lldd_queue_size
The host adapter's queue size. This is the maximum
number of commands the lldd can have pending to domain
devices on behalf of all upper layers submitting through
lldd_execute_task().
You really want to set this to something (much) larger than
1.
This _really_ has absolutely nothing to do with queuing.
There is no queuing in SAS LLDDs.
struct sas_task {
dev -- the device this task is destined to
list -- must be initialized (INIT_LIST_HEAD)
task_proto -- _one_ of enum sas_proto
scatter -- pointer to scatter gather list array
num_scatter -- number of elements in scatter

66
Documentation/scsi/scsi_mid_low_api.txt
View File

@ -149,7 +149,7 @@ scsi_add_host() ---->
scsi_scan_host() -------+
|
slave_alloc()
slave_configure() --> scsi_adjust_queue_depth()
slave_configure() --> scsi_change_queue_depth()
|
slave_alloc()
slave_configure()
@ -159,7 +159,7 @@ scsi_scan_host() -------+
------------------------------------------------------------
If the LLD wants to adjust the default queue settings, it can invoke
scsi_adjust_queue_depth() in its slave_configure() routine.
scsi_change_queue_depth() in its slave_configure() routine.
*** For scsi devices that the mid level tries to scan but do not
respond, a slave_alloc(), slave_destroy() pair is called.
@ -203,7 +203,7 @@ LLD mid level LLD
scsi_add_device() ------+
|
slave_alloc()
slave_configure() [--> scsi_adjust_queue_depth()]
slave_configure() [--> scsi_change_queue_depth()]
------------------------------------------------------------
In a similar fashion, an LLD may become aware that a SCSI device has been
@ -261,7 +261,7 @@ init_this_scsi_driver() ----+
| scsi_register()
|
slave_alloc()
slave_configure() --> scsi_adjust_queue_depth()
slave_configure() --> scsi_change_queue_depth()
slave_alloc() ***
slave_destroy() ***
|
@ -271,9 +271,9 @@ init_this_scsi_driver() ----+
slave_destroy() ***
------------------------------------------------------------
The mid level invokes scsi_adjust_queue_depth() with tagged queuing off and
"cmd_per_lun" for that host as the queue length. These settings can be
overridden by a slave_configure() supplied by the LLD.
The mid level invokes scsi_change_queue_depth() with "cmd_per_lun" for that
host as the queue length. These settings can be overridden by a
slave_configure() supplied by the LLD.
*** For scsi devices that the mid level tries to scan but do not
respond, a slave_alloc(), slave_destroy() pair is called.
@ -366,13 +366,11 @@ is initialized. The functions below are listed alphabetically and their
names all start with "scsi_".
Summary:
scsi_activate_tcq - turn on tag command queueing
scsi_add_device - creates new scsi device (lu) instance
scsi_add_host - perform sysfs registration and set up transport class
scsi_adjust_queue_depth - change the queue depth on a SCSI device
scsi_change_queue_depth - change the queue depth on a SCSI device
scsi_bios_ptable - return copy of block device's partition table
scsi_block_requests - prevent further commands being queued to given host
scsi_deactivate_tcq - turn off tag command queueing
scsi_host_alloc - return a new scsi_host instance whose refcount==1
scsi_host_get - increments Scsi_Host instance's refcount
scsi_host_put - decrements Scsi_Host instance's refcount (free if 0)
@ -389,24 +387,6 @@ Summary:
Details:
/**
* scsi_activate_tcq - turn on tag command queueing ("ordered" task attribute)
* @sdev: device to turn on TCQ for
* @depth: queue depth
*
* Returns nothing
*
* Might block: no
*
* Notes: Eventually, it is hoped depth would be the maximum depth
* the device could cope with and the real queue depth
* would be adjustable from 0 to depth.
*
* Defined (inline) in: include/scsi/scsi_tcq.h
**/
void scsi_activate_tcq(struct scsi_device *sdev, int depth)
/**
* scsi_add_device - creates new scsi device (lu) instance
* @shost: pointer to scsi host instance
@ -456,11 +436,8 @@ int scsi_add_host(struct Scsi_Host *shost, struct device * dev)
/**
* scsi_adjust_queue_depth - allow LLD to change queue depth on a SCSI device
* scsi_change_queue_depth - allow LLD to change queue depth on a SCSI device
* @sdev: pointer to SCSI device to change queue depth on
* @tagged: 0 - no tagged queuing
* MSG_SIMPLE_TAG - simple tagged queuing
* MSG_ORDERED_TAG - ordered tagged queuing
* @tags Number of tags allowed if tagged queuing enabled,
* or number of commands the LLD can queue up
* in non-tagged mode (as per cmd_per_lun).
@ -471,15 +448,12 @@ int scsi_add_host(struct Scsi_Host *shost, struct device * dev)
*
* Notes: Can be invoked any time on a SCSI device controlled by this
* LLD. [Specifically during and after slave_configure() and prior to
* slave_destroy().] Can safely be invoked from interrupt code. Actual
* queue depth change may be delayed until the next command is being
* processed. See also scsi_activate_tcq() and scsi_deactivate_tcq().
* slave_destroy().] Can safely be invoked from interrupt code.
*
* Defined in: drivers/scsi/scsi.c [see source code for more notes]
*
**/
void scsi_adjust_queue_depth(struct scsi_device * sdev, int tagged,
int tags)
int scsi_change_queue_depth(struct scsi_device *sdev, int tags)
/**
@ -514,20 +488,6 @@ unsigned char *scsi_bios_ptable(struct block_device *dev)
void scsi_block_requests(struct Scsi_Host * shost)
/**
* scsi_deactivate_tcq - turn off tag command queueing
* @sdev: device to turn off TCQ for
* @depth: queue depth (stored in sdev)
*
* Returns nothing
*
* Might block: no
*
* Defined (inline) in: include/scsi/scsi_tcq.h
**/
void scsi_deactivate_tcq(struct scsi_device *sdev, int depth)
/**
* scsi_host_alloc - create a scsi host adapter instance and perform basic
* initialization.
@ -1254,7 +1214,7 @@ of interest:
for disk firmware uploads.
cmd_per_lun - maximum number of commands that can be queued on devices
controlled by the host. Overridden by LLD calls to
scsi_adjust_queue_depth().
scsi_change_queue_depth().
unchecked_isa_dma - 1=>only use bottom 16 MB of ram (ISA DMA addressing
restriction), 0=>can use full 32 bit (or better) DMA
address space
@ -1294,7 +1254,7 @@ struct scsi_cmnd
Instances of this structure convey SCSI commands to the LLD and responses
back to the mid level. The SCSI mid level will ensure that no more SCSI
commands become queued against the LLD than are indicated by
scsi_adjust_queue_depth() (or struct Scsi_Host::cmd_per_lun). There will
scsi_change_queue_depth() (or struct Scsi_Host::cmd_per_lun). There will
be at least one instance of struct scsi_cmnd available for each SCSI device.
Members of interest:
cmnd - array containing SCSI command

8
Documentation/scsi/st.txt
View File

@ -506,9 +506,11 @@ user does not request data that far.)
DEBUGGING HINTS
To enable debugging messages, edit st.c and #define DEBUG 1. As seen
above, debugging can be switched off with an ioctl if debugging is
compiled into the driver. The debugging output is not voluminous.
Debugging code is now compiled in by default but debugging is turned off
with the kernel module parameter debug_flag defaulting to 0. Debugging
can still be switched on and off with an ioctl. To enable debug at
module load time add debug_flag=1 to the module load options, the
debugging output is not voluminous.
If the tape seems to hang, I would be very interested to hear where
the driver is waiting. With the command 'ps -l' you can see the state

21
Documentation/scsi/wd719x.txt Normal file
View File

@ -0,0 +1,21 @@
Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards
---------------------------------------------------------------
The card requires firmware that can be cut out of the Windows NT driver that
can be downloaded from WD at:
http://support.wdc.com/product/download.asp?groupid=801&sid=27&lang=en
There is no license anywhere in the file or on the page - so the firmware
probably cannot be added to linux-firmware.
This script downloads and extracts the firmware, creating wd719x-risc.bin and
d719x-wcs.bin files. Put them in /lib/firmware/.
#!/bin/sh
wget http://support.wdc.com/download/archive/pciscsi.exe
lha xi pciscsi.exe pci-scsi.exe
lha xi pci-scsi.exe nt/wd7296a.sys
rm pci-scsi.exe
dd if=wd7296a.sys of=wd719x-risc.bin bs=1 skip=5760 count=14336
dd if=wd7296a.sys of=wd719x-wcs.bin bs=1 skip=20096 count=514
rm wd7296a.sys

12
Documentation/video4linux/vivid.txt
View File

@ -221,12 +221,11 @@ ccs_out_mode: specify the allowed video output crop/compose/scaling combination
key, not quality.
multiplanar: select whether each device instance supports multi-planar formats,
and thus the V4L2 multi-planar API. By default the first device instance
is single-planar, the second multi-planar, and it keeps alternating.
and thus the V4L2 multi-planar API. By default device instances are
single-planar.
This module option can override that for each instance. Values are:
0: use alternating single and multi-planar devices.
1: this is a single-planar instance.
2: this is a multi-planar instance.
@ -975,9 +974,8 @@ is set, then the alpha component is only used for the color red and set to
0 otherwise.
The driver has to be configured to support the multiplanar formats. By default
the first driver instance is single-planar, the second is multi-planar, and it
keeps alternating. This can be changed by setting the multiplanar module option,
see section 1 for more details on that option.
the driver instances are single-planar. This can be changed by setting the
multiplanar module option, see section 1 for more details on that option.
If the driver instance is using the multiplanar formats/API, then the first
single planar format (YUYV) and the multiplanar NV16M and NV61M formats the
@ -1021,7 +1019,7 @@ the output overlay for the video output, turn on video looping and capture
to see the blended framebuffer overlay that's being written to by the second
instance. This setup would require the following commands:
$ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1 multiplanar=1,1
$ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1
$ v4l2-ctl -d1 --find-fb
/dev/fb1 is the framebuffer associated with base address 0x12800000
$ sudo v4l2-ctl -d2 --set-fbuf fb=1

234
Documentation/x86/intel_mpx.txt Normal file
View File

@ -0,0 +1,234 @@
1. Intel(R) MPX Overview
========================
Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new capability
introduced into Intel Architecture. Intel MPX provides hardware features
that can be used in conjunction with compiler changes to check memory
references, for those references whose compile-time normal intentions are
usurped at runtime due to buffer overflow or underflow.
For more information, please refer to Intel(R) Architecture Instruction
Set Extensions Programming Reference, Chapter 9: Intel(R) Memory Protection
Extensions.
Note: Currently no hardware with MPX ISA is available but it is always
possible to use SDE (Intel(R) Software Development Emulator) instead, which
can be downloaded from
http://software.intel.com/en-us/articles/intel-software-development-emulator
2. How to get the advantage of MPX
==================================
For MPX to work, changes are required in the kernel, binutils and compiler.
No source changes are required for applications, just a recompile.
There are a lot of moving parts of this to all work right. The following
is how we expect the compiler, application and kernel to work together.
1) Application developer compiles with -fmpx. The compiler will add the
instrumentation as well as some setup code called early after the app
starts. New instruction prefixes are noops for old CPUs.
2) That setup code allocates (virtual) space for the "bounds directory",
points the "bndcfgu" register to the directory and notifies the kernel
(via the new prctl(PR_MPX_ENABLE_MANAGEMENT)) that the app will be using
MPX.
3) The kernel detects that the CPU has MPX, allows the new prctl() to
succeed, and notes the location of the bounds directory. Userspace is
expected to keep the bounds directory at that locationWe note it
instead of reading it each time because the 'xsave' operation needed
to access the bounds directory register is an expensive operation.
4) If the application needs to spill bounds out of the 4 registers, it
issues a bndstx instruction. Since the bounds directory is empty at
this point, a bounds fault (#BR) is raised, the kernel allocates a
bounds table (in the user address space) and makes the relevant entry
in the bounds directory point to the new table.
5) If the application violates the bounds specified in the bounds registers,
a separate kind of #BR is raised which will deliver a signal with
information about the violation in the 'struct siginfo'.
6) Whenever memory is freed, we know that it can no longer contain valid
pointers, and we attempt to free the associated space in the bounds
tables. If an entire table becomes unused, we will attempt to free
the table and remove the entry in the directory.
To summarize, there are essentially three things interacting here:
GCC with -fmpx:
* enables annotation of code with MPX instructions and prefixes
* inserts code early in the application to call in to the "gcc runtime"
GCC MPX Runtime:
* Checks for hardware MPX support in cpuid leaf
* allocates virtual space for the bounds directory (malloc() essentially)
* points the hardware BNDCFGU register at the directory
* calls a new prctl(PR_MPX_ENABLE_MANAGEMENT) to notify the kernel to
start managing the bounds directories
Kernel MPX Code:
* Checks for hardware MPX support in cpuid leaf
* Handles #BR exceptions and sends SIGSEGV to the app when it violates
bounds, like during a buffer overflow.
* When bounds are spilled in to an unallocated bounds table, the kernel
notices in the #BR exception, allocates the virtual space, then
updates the bounds directory to point to the new table. It keeps
special track of the memory with a VM_MPX flag.
* Frees unused bounds tables at the time that the memory they described
is unmapped.
3. How does MPX kernel code work
================================
Handling #BR faults caused by MPX
---------------------------------
When MPX is enabled, there are 2 new situations that can generate
#BR faults.
* new bounds tables (BT) need to be allocated to save bounds.
* bounds violation caused by MPX instructions.
We hook #BR handler to handle these two new situations.
On-demand kernel allocation of bounds tables
--------------------------------------------
MPX only has 4 hardware registers for storing bounds information. If
MPX-enabled code needs more than these 4 registers, it needs to spill
them somewhere. It has two special instructions for this which allow
the bounds to be moved between the bounds registers and some new "bounds
tables".
#BR exceptions are a new class of exceptions just for MPX. They are
similar conceptually to a page fault and will be raised by the MPX
hardware during both bounds violations or when the tables are not
present. The kernel handles those #BR exceptions for not-present tables
by carving the space out of the normal processes address space and then
pointing the bounds-directory over to it.
The tables need to be accessed and controlled by userspace because
the instructions for moving bounds in and out of them are extremely
frequent. They potentially happen every time a register points to
memory. Any direct kernel involvement (like a syscall) to access the
tables would obviously destroy performance.
Why not do this in userspace? MPX does not strictly require anything in
the kernel. It can theoretically be done completely from userspace. Here
are a few ways this could be done. We don't think any of them are practical
in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so that we
never have to allocate them?
A: MPX-enabled application will possibly create a lot of bounds tables in
process address space to save bounds information. These tables can take
up huge swaths of memory (as much as 80% of the memory on the system)
even if we clean them up aggressively. In the worst-case scenario, the
tables can be 4x the size of the data structure being tracked. IOW, a
1-page structure can require 4 bounds-table pages. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds directory.
If we were to preallocate them for the 128TB of user virtual address
space, we would need to reserve 512TB+2GB, which is larger than the
entire virtual address space today. This means they can not be reserved
ahead of time. Also, a single process's pre-popualated bounds directory
consumes 2GB of virtual *AND* physical memory. IOW, it's completely
infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory is
allocated which might contain pointers that might eventually need
bounds tables?
A: This would work if we could hook the site of each and every memory
allocation syscall. This can be done for small, constrained applications.
But, it isn't practical at a larger scale since a given app has no
way of controlling how all the parts of the app might allocate memory
(think libraries). The kernel is really the only place to intercept
these calls.
Q: Could a bounds fault be handed to userspace and the tables allocated
there in a signal handler intead of in the kernel?
A: mmap() is not on the list of safe async handler functions and even
if mmap() would work it still requires locking or nasty tricks to
keep track of the allocation state there.
Having ruled out all of the userspace-only approaches for managing
bounds tables that we could think of, we create them on demand in
the kernel.
Decoding MPX instructions
-------------------------
If a #BR is generated due to a bounds violation caused by MPX.
We need to decode MPX instructions to get violation address and
set this address into extended struct siginfo.
The _sigfault feild of struct siginfo is extended as follow:
87 /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
88 struct {
89 void __user *_addr; /* faulting insn/memory ref. */
90 #ifdef __ARCH_SI_TRAPNO
91 int _trapno; /* TRAP # which caused the signal */
92 #endif
93 short _addr_lsb; /* LSB of the reported address */
94 struct {
95 void __user *_lower;
96 void __user *_upper;
97 } _addr_bnd;
98 } _sigfault;
The '_addr' field refers to violation address, and new '_addr_and'
field refers to the upper/lower bounds when a #BR is caused.
Glibc will be also updated to support this new siginfo. So user
can get violation address and bounds when bounds violations occur.
Cleanup unused bounds tables
----------------------------
When a BNDSTX instruction attempts to save bounds to a bounds directory
entry marked as invalid, a #BR is generated. This is an indication that
no bounds table exists for this entry. In this case the fault handler
will allocate a new bounds table on demand.
Since the kernel allocated those tables on-demand without userspace
knowledge, it is also responsible for freeing them when the associated
mappings go away.
Here, the solution for this issue is to hook do_munmap() to check
whether one process is MPX enabled. If yes, those bounds tables covered
in the virtual address region which is being unmapped will be freed also.
Adding new prctl commands
-------------------------
Two new prctl commands are added to enable and disable MPX bounds tables
management in kernel.
155 #define PR_MPX_ENABLE_MANAGEMENT 43
156 #define PR_MPX_DISABLE_MANAGEMENT 44
Runtime library in userspace is responsible for allocation of bounds
directory. So kernel have to use XSAVE instruction to get the base
of bounds directory from BNDCFG register.
But XSAVE is expected to be very expensive. In order to do performance
optimization, we have to get the base of bounds directory and save it
into struct mm_struct to be used in future during PR_MPX_ENABLE_MANAGEMENT
command execution.
4. Special rules
================
1) If userspace is requesting help from the kernel to do the management
of bounds tables, it may not create or modify entries in the bounds directory.
Certainly users can allocate bounds tables and forcibly point the bounds
directory at them through XSAVE instruction, and then set valid bit
of bounds entry to have this entry valid. But, the kernel will decline
to assist in managing these tables.
2) Userspace may not take multiple bounds directory entries and point
them at the same bounds table.
This is allowed architecturally. See more information "Intel(R) Architecture
Instruction Set Extensions Programming Reference" (9.3.4).
However, if users did this, the kernel might be fooled in to unmaping an
in-use bounds table since it does not recognize sharing.

174
MAINTAINERS
View File

@ -861,6 +861,7 @@ W: http://maxim.org.za/at91_26.html
W: http://www.linux4sam.org
S: Supported
F: arch/arm/mach-at91/
F: include/soc/at91/
F: arch/arm/boot/dts/at91*.dts
F: arch/arm/boot/dts/at91*.dtsi
F: arch/arm/boot/dts/sama*.dts
@ -1308,30 +1309,22 @@ F: drivers/*/*rockchip*
F: drivers/*/*/*rockchip*
F: sound/soc/rockchip/
ARM/SAMSUNG ARM ARCHITECTURES
M: Ben Dooks <ben-linux@fluff.org>
M: Kukjin Kim <kgene.kim@samsung.com>
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
M: Kukjin Kim <kgene@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
W: http://www.fluff.org/ben/linux/
S: Maintained
F: arch/arm/boot/dts/s3c*
F: arch/arm/boot/dts/exynos*
F: arch/arm/plat-samsung/
F: arch/arm/mach-s3c24*/
F: arch/arm/mach-s3c64xx/
F: arch/arm/mach-s5p*/
F: arch/arm/mach-exynos*/
F: drivers/*/*s3c2410*
F: drivers/*/*/*s3c2410*
F: drivers/spi/spi-s3c*
F: sound/soc/samsung/*
ARM/S5P EXYNOS ARM ARCHITECTURES
M: Kukjin Kim <kgene.kim@samsung.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-s5p*/
F: arch/arm/mach-exynos*/
N: exynos
ARM/SAMSUNG MOBILE MACHINE SUPPORT
@ -1381,12 +1374,12 @@ F: arch/arm/boot/dts/sh*
F: arch/arm/configs/ape6evm_defconfig
F: arch/arm/configs/armadillo800eva_defconfig
F: arch/arm/configs/bockw_defconfig
F: arch/arm/configs/koelsch_defconfig
F: arch/arm/configs/kzm9g_defconfig
F: arch/arm/configs/lager_defconfig
F: arch/arm/configs/mackerel_defconfig
F: arch/arm/configs/marzen_defconfig
F: arch/arm/configs/shmobile_defconfig
F: arch/arm/include/debug/renesas-scif.S
F: arch/arm/mach-shmobile/
F: drivers/sh/
@ -1430,6 +1423,7 @@ F: drivers/tty/serial/st-asc.c
F: drivers/usb/dwc3/dwc3-st.c
F: drivers/usb/host/ehci-st.c
F: drivers/usb/host/ohci-st.c
F: drivers/ata/ahci_st.c
ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
M: Lennert Buytenhek <kernel@wantstofly.org>
@ -1503,6 +1497,19 @@ S: Maintained
F: drivers/clk/ux500/
F: include/linux/platform_data/clk-ux500.h
ARM/VERSATILE EXPRESS PLATFORM
M: Liviu Dudau <liviu.dudau@arm.com>
M: Sudeep Holla <sudeep.holla@arm.com>
M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/vexpress*
F: arch/arm/mach-vexpress/
F: */*/vexpress*
F: */*/*/vexpress*
F: drivers/clk/versatile/clk-vexpress-osc.c
F: drivers/clocksource/versatile.c
ARM/VFP SUPPORT
M: Russell King <linux@arm.linux.org.uk>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@ -1543,6 +1550,7 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
R: Sören Brinkmann <soren.brinkmann@xilinx.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
W: http://wiki.xilinx.com
T: git git://git.xilinx.com/linux-xlnx.git
@ -1827,7 +1835,7 @@ F: include/net/ax25.h
F: net/ax25/
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -2071,8 +2079,9 @@ F: drivers/clocksource/bcm_kona_timer.c
BROADCOM BCM2835 ARM ARCHITECTURE
M: Stephen Warren <swarren@wwwdotorg.org>
M: Lee Jones <lee@kernel.org>
L: linux-rpi-kernel@lists.infradead.org (moderated for non-subscribers)
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
S: Maintained
N: bcm2835
@ -2095,10 +2104,13 @@ F: arch/arm/include/debug/bcm63xx.S
BROADCOM BCM7XXX ARM ARCHITECTURE
M: Marc Carino <marc.ceeeee@gmail.com>
M: Brian Norris <computersforpeace@gmail.com>
M: Gregory Fong <gregory.0xf0@gmail.com>
M: Florian Fainelli <f.fainelli@gmail.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-bcm/*brcmstb*
F: arch/arm/boot/dts/bcm7*.dts*
F: drivers/bus/brcmstb_gisb.c
BROADCOM TG3 GIGABIT ETHERNET DRIVER
M: Prashant Sreedharan <prashant@broadcom.com>
@ -2129,6 +2141,20 @@ L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/bnx2i/
BROADCOM CYGNUS/IPROC ARM ARCHITECTURE
M: Ray Jui <rjui@broadcom.com>
M: Scott Branden <sbranden@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: bcm-kernel-feedback-list@broadcom.com
T: git git://git.github.com/brcm/linux.git
S: Maintained
N: iproc
N: cygnus
N: bcm9113*
N: bcm9583*
N: bcm583*
N: bcm113*
BROADCOM KONA GPIO DRIVER
M: Ray Jui <rjui@broadcom.com>
L: bcm-kernel-feedback-list@broadcom.com
@ -2196,7 +2222,7 @@ F: Documentation/filesystems/btrfs.txt
F: fs/btrfs/
BTTV VIDEO4LINUX DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -2717,7 +2743,7 @@ F: drivers/media/common/cx2341x*
F: include/media/cx2341x*
CX88 VIDEO4LINUX DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -2742,6 +2768,13 @@ W: http://www.chelsio.com
S: Supported
F: drivers/net/ethernet/chelsio/cxgb3/
CXGB3 ISCSI DRIVER (CXGB3I)
M: Karen Xie <kxie@chelsio.com>
L: linux-scsi@vger.kernel.org
W: http://www.chelsio.com
S: Supported
F: drivers/scsi/cxgbi/cxgb3i
CXGB3 IWARP RNIC DRIVER (IW_CXGB3)
M: Steve Wise <swise@chelsio.com>
L: linux-rdma@vger.kernel.org
@ -2756,6 +2789,13 @@ W: http://www.chelsio.com
S: Supported
F: drivers/net/ethernet/chelsio/cxgb4/
CXGB4 ISCSI DRIVER (CXGB4I)
M: Karen Xie <kxie@chelsio.com>
L: linux-scsi@vger.kernel.org
W: http://www.chelsio.com
S: Supported
F: drivers/scsi/cxgbi/cxgb4i
CXGB4 IWARP RNIC DRIVER (IW_CXGB4)
M: Steve Wise <swise@chelsio.com>
L: linux-rdma@vger.kernel.org
@ -2846,11 +2886,10 @@ F: Documentation/networking/dmfe.txt
F: drivers/net/ethernet/dec/tulip/dmfe.c
DC390/AM53C974 SCSI driver
M: Kurt Garloff <garloff@suse.de>
W: http://www.garloff.de/kurt/linux/dc390/
M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
M: Hannes Reinecke <hare@suse.de>
L: linux-scsi@vger.kernel.org
S: Maintained
F: drivers/scsi/tmscsim.*
F: drivers/scsi/am53c974.c
DC395x SCSI driver
M: Oliver Neukum <oliver@neukum.org>
@ -3386,7 +3425,7 @@ F: fs/ecryptfs/
EDAC-CORE
M: Doug Thompson <dougthompson@xmission.com>
M: Borislav Petkov <bp@alien8.de>
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Supported
@ -3435,7 +3474,7 @@ S: Maintained
F: drivers/edac/e7xxx_edac.c
EDAC-GHES
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
@ -3463,21 +3502,21 @@ S: Maintained
F: drivers/edac/i5000_edac.c
EDAC-I5400
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
F: drivers/edac/i5400_edac.c
EDAC-I7300
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
F: drivers/edac/i7300_edac.c
EDAC-I7CORE
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
@ -3520,7 +3559,7 @@ S: Maintained
F: drivers/edac/r82600_edac.c
EDAC-SBRIDGE
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
@ -3580,7 +3619,7 @@ S: Maintained
F: drivers/net/ethernet/ibm/ehea/
EM28XX VIDEO4LINUX DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -4714,6 +4753,7 @@ L: linux-iio@vger.kernel.org
S: Maintained
F: drivers/iio/
F: drivers/staging/iio/
F: include/linux/iio/
IKANOS/ADI EAGLE ADSL USB DRIVER
M: Matthieu Castet <castet.matthieu@free.fr>
@ -5945,7 +5985,7 @@ S: Maintained
F: drivers/media/radio/radio-maxiradio*
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
P: LinuxTV.org Project
L: linux-media@vger.kernel.org
W: http://linuxtv.org
@ -5974,10 +6014,13 @@ W: http://linuxtv.org
S: Odd Fixes
F: drivers/media/parport/pms*
MEGARAID SCSI DRIVERS
M: Neela Syam Kolli <megaraidlinux@lsi.com>
MEGARAID SCSI/SAS DRIVERS
M: Kashyap Desai <kashyap.desai@avagotech.com>
M: Sumit Saxena <sumit.saxena@avagotech.com>
M: Uday Lingala <uday.lingala@avagotech.com>
L: megaraidlinux.pdl@avagotech.com
L: linux-scsi@vger.kernel.org
W: http://megaraid.lsilogic.com
W: http://www.lsi.com
S: Maintained
F: Documentation/scsi/megaraid.txt
F: drivers/scsi/megaraid.*
@ -6288,7 +6331,6 @@ F: drivers/scsi/g_NCR5380.*
F: drivers/scsi/g_NCR5380_mmio.c
F: drivers/scsi/mac_scsi.*
F: drivers/scsi/pas16.*
F: drivers/scsi/sun3_NCR5380.c
F: drivers/scsi/sun3_scsi.*
F: drivers/scsi/sun3_scsi_vme.c
F: drivers/scsi/t128.*
@ -6544,6 +6586,13 @@ S: Maintained
F: Documentation/scsi/NinjaSCSI.txt
F: drivers/scsi/nsp32*
NIOS2 ARCHITECTURE
M: Ley Foon Tan <lftan@altera.com>
L: nios2-dev@lists.rocketboards.org (moderated for non-subscribers)
T: git git://git.rocketboards.org/linux-socfpga.git
S: Maintained
F: arch/nios2/
NTB DRIVER
M: Jon Mason <jdmason@kudzu.us>
M: Dave Jiang <dave.jiang@intel.com>
@ -6594,6 +6643,23 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
S: Maintained
F: arch/arm/*omap*/
F: drivers/i2c/busses/i2c-omap.c
F: drivers/irqchip/irq-omap-intc.c
F: drivers/mfd/*omap*.c
F: drivers/mfd/menelaus.c
F: drivers/mfd/palmas.c
F: drivers/mfd/tps65217.c
F: drivers/mfd/tps65218.c
F: drivers/mfd/tps65910.c
F: drivers/mfd/twl-core.[ch]
F: drivers/mfd/twl4030*.c
F: drivers/mfd/twl6030*.c
F: drivers/mfd/twl6040*.c
F: drivers/regulator/palmas-regulator*.c
F: drivers/regulator/pbias-regulator.c
F: drivers/regulator/tps65217-regulator.c
F: drivers/regulator/tps65218-regulator.c
F: drivers/regulator/tps65910-regulator.c
F: drivers/regulator/twl-regulator.c
F: include/linux/i2c-omap.h
OMAP DEVICE TREE SUPPORT
@ -6604,6 +6670,9 @@ L: devicetree@vger.kernel.org
S: Maintained
F: arch/arm/boot/dts/*omap*
F: arch/arm/boot/dts/*am3*
F: arch/arm/boot/dts/*am4*
F: arch/arm/boot/dts/*am5*
F: arch/arm/boot/dts/*dra7*
OMAP CLOCK FRAMEWORK SUPPORT
M: Paul Walmsley <paul@pwsan.com>
@ -6633,6 +6702,14 @@ L: linux-omap@vger.kernel.org
S: Maintained
F: sound/soc/omap/
OMAP GENERAL PURPOSE MEMORY CONTROLLER SUPPORT
M: Roger Quadros <rogerq@ti.com>
M: Tony Lindgren <tony@atomide.com>
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/memory/omap-gpmc.c
F: arch/arm/mach-omap2/*gpmc*
OMAP FRAMEBUFFER SUPPORT
M: Tomi Valkeinen <tomi.valkeinen@ti.com>
L: linux-fbdev@vger.kernel.org
@ -6851,11 +6928,12 @@ F: drivers/scsi/osd/
F: include/scsi/osd_*
F: fs/exofs/
OVERLAYFS FILESYSTEM
OVERLAY FILESYSTEM
M: Miklos Szeredi <miklos@szeredi.hu>
L: linux-fsdevel@vger.kernel.org
L: linux-unionfs@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
S: Supported
F: fs/overlayfs/*
F: fs/overlayfs/
F: Documentation/filesystems/overlayfs.txt
P54 WIRELESS DRIVER
@ -7179,6 +7257,7 @@ F: drivers/crypto/picoxcell*
PIN CONTROL SUBSYSTEM
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-gpio@vger.kernel.org
S: Maintained
F: drivers/pinctrl/
F: include/linux/pinctrl/
@ -7974,7 +8053,7 @@ S: Odd Fixes
F: drivers/media/i2c/saa6588*
SAA7134 VIDEO4LINUX DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -8432,7 +8511,7 @@ S: Maintained
F: drivers/media/radio/si4713/radio-usb-si4713.c
SIANO DVB DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -8483,7 +8562,6 @@ F: arch/arm/mach-s3c24xx/bast-irq.c
TI DAVINCI MACHINE SUPPORT
M: Sekhar Nori <nsekhar@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/
S: Supported
@ -8493,7 +8571,6 @@ F: drivers/i2c/busses/i2c-davinci.c
TI DAVINCI SERIES MEDIA DRIVER
M: Lad, Prabhakar <prabhakar.csengg@gmail.com>
L: linux-media@vger.kernel.org
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
W: http://linuxtv.org/
Q: http://patchwork.linuxtv.org/project/linux-media/list/
T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
@ -8645,7 +8722,9 @@ S: Maintained
F: drivers/leds/leds-net48xx.c
SOFTLOGIC 6x10 MPEG CODEC
M: Ismael Luceno <ismael.luceno@corp.bluecherry.net>
M: Bluecherry Maintainers <maintainers@bluecherrydvr.com>
M: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
M: Andrey Utkin <andrey.krieger.utkin@gmail.com>
L: linux-media@vger.kernel.org
S: Supported
F: drivers/media/pci/solo6x10/
@ -9119,7 +9198,7 @@ S: Maintained
F: drivers/media/i2c/tda9840*
TEA5761 TUNER DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -9127,7 +9206,7 @@ S: Odd fixes
F: drivers/media/tuners/tea5761.*
TEA5767 TUNER DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -9439,7 +9518,7 @@ F: include/linux/shmem_fs.h
F: mm/shmem.c
TM6000 VIDEO4LINUX DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@ -9703,11 +9782,6 @@ S: Maintained
F: Documentation/hid/hiddev.txt
F: drivers/hid/usbhid/
USB/IP DRIVERS
L: linux-usb@vger.kernel.org
S: Orphan
F: drivers/staging/usbip/
USB ISP116X DRIVER
M: Olav Kongas <ok@artecdesign.ee>
L: linux-usb@vger.kernel.org
@ -10265,7 +10339,7 @@ S: Maintained
F: arch/x86/kernel/cpu/mcheck/*
XC2028/3028 TUNER DRIVER
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git

7
Makefile
View File

@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 18
SUBLEVEL = 0
EXTRAVERSION = -rc3
EXTRAVERSION =
NAME = Diseased Newt
# *DOCUMENTATION*
@ -297,7 +297,7 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
HOSTCC = gcc
HOSTCXX = g++
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
HOSTCXXFLAGS = -O2
ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
@ -401,7 +401,8 @@ KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
-Wno-format-security
-Wno-format-security \
-std=gnu89
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=

2
arch/arc/include/asm/io.h
View File

@ -13,8 +13,6 @@
#include <asm/byteorder.h>
#include <asm/page.h>
#define PCI_IOBASE ((void __iomem *)0)
extern void __iomem *ioremap(unsigned long physaddr, unsigned long size);
extern void __iomem *ioremap_prot(phys_addr_t offset, unsigned long size,
unsigned long flags);

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