system/linux
system/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux synced 2024-09-20 02:57:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branches 'for-4.4/upstream-fixes', 'for-4.5/async-suspend', 'for-4.5/container-of-cleanups', 'for-4.5/core', 'for-4.5/i2c-hid', 'for-4.5/logitech', 'for-4.5/multitouch', 'for-4.5/sony', 'for-4.5/upstream' and 'for-4.5/wacom' into for-linus

Browse source
This commit is contained in:
Jiri Kosina 2016-01-14 16:11:06 +01:00
parent 76833559eb 64bebefcf3 2cf83833fc 5d9374cf5f 6cf2e31bea 5f008c9859 73e7d63efb b71b5578a8 7775fb929d 0bbfe28ad0
commit 83f1bfd6f5
3183 changed files with 132117 additions and 81126 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
Documentation/ABI/testing/sysfs-driver-st Normal file
View file

@ -0,0 +1,12 @@
What: /sys/bus/scsi/drivers/st/debug_flag
Date: October 2015
Kernel Version: ?.?
Contact: shane.seymour@hpe.com
Description:
This file allows you to turn debug output from the st driver
off if you write a '0' to the file or on if you write a '1'.
Note that debug output requires that the module be compiled
with the #define DEBUG set to a non-zero value (this is the
default). If DEBUG is set to 0 then this file will not
appear in sysfs as its presence is conditional upon debug
output support being compiled into the module.

13
Documentation/DMA-API.txt
View file

@ -141,19 +141,6 @@ memory back to the pool before you destroy it.
Part Ic - DMA addressing limitations
------------------------------------
int
dma_supported(struct device *dev, u64 mask)
Checks to see if the device can support DMA to the memory described by
mask.
Returns: 1 if it can and 0 if it can't.
Notes: This routine merely tests to see if the mask is possible. It
won't change the current mask settings. It is more intended as an
internal API for use by the platform than an external API for use by
driver writers.
int
dma_set_mask_and_coherent(struct device *dev, u64 mask)

2
Documentation/DocBook/Makefile
View file

@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
include Documentation/DocBook/media/Makefile

209
Documentation/DocBook/drm.tmpl → Documentation/DocBook/gpu.tmpl
View file

@ -2,9 +2,9 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="drmDevelopersGuide">
<book id="gpuDevelopersGuide">
<bookinfo>
<title>Linux DRM Developer's Guide</title>
<title>Linux GPU Driver Developer's Guide</title>
<authorgroup>
<author>
@ -40,6 +40,16 @@
</address>
</affiliation>
</author>
<author>
<firstname>Lukas</firstname>
<surname>Wunner</surname>
<contrib>vga_switcheroo documentation</contrib>
<affiliation>
<address>
<email>lukas@wunner.de</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
@ -51,6 +61,10 @@
<year>2012</year>
<holder>Laurent Pinchart</holder>
</copyright>
<copyright>
<year>2015</year>
<holder>Lukas Wunner</holder>
</copyright>
<legalnotice>
<para>
@ -69,6 +83,13 @@
<revremark>Added extensive documentation about driver internals.
</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>2015-10-11</date>
<authorinitials>LW</authorinitials>
<revremark>Added vga_switcheroo documentation.
</revremark>
</revision>
</revhistory>
</bookinfo>
@ -78,9 +99,9 @@
<title>DRM Core</title>
<partintro>
<para>
This first part of the DRM Developer's Guide documents core DRM code,
helper libraries for writing drivers and generic userspace interfaces
exposed by DRM drivers.
This first part of the GPU Driver Developer's Guide documents core DRM
code, helper libraries for writing drivers and generic userspace
interfaces exposed by DRM drivers.
</para>
</partintro>
@ -138,14 +159,10 @@
<para>
At the core of every DRM driver is a <structname>drm_driver</structname>
structure. Drivers typically statically initialize a drm_driver structure,
and then pass it to one of the <function>drm_*_init()</function> functions
to register it with the DRM subsystem.
</para>
<para>
Newer drivers that no longer require a <structname>drm_bus</structname>
structure can alternatively use the low-level device initialization and
registration functions such as <function>drm_dev_alloc()</function> and
<function>drm_dev_register()</function> directly.
and then pass it to <function>drm_dev_alloc()</function> to allocate a
device instance. After the device instance is fully initialized it can be
registered (which makes it accessible from userspace) using
<function>drm_dev_register()</function>.
</para>
<para>
The <structname>drm_driver</structname> structure contains static
@ -296,83 +313,12 @@ char *date;</synopsis>
</sect3>
</sect2>
<sect2>
<title>Device Registration</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI and platform devices, respectively.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_platform.c
<para>
New drivers that no longer rely on the services provided by the
<structname>drm_bus</structname> structure can call the low-level
device registration functions directly. The
<function>drm_dev_alloc()</function> function can be used to allocate
and initialize a new <structname>drm_device</structname> structure.
Drivers will typically want to perform some additional setup on this
structure, such as allocating driver-specific data and storing a
pointer to it in the DRM device's <structfield>dev_private</structfield>
field. Drivers should also set the device's unique name using the
<function>drm_dev_set_unique()</function> function. After it has been
set up a device can be registered with the DRM subsystem by calling
<function>drm_dev_register()</function>. This will cause the device to
be exposed to userspace and will call the driver's
<structfield>.load()</structfield> implementation. When a device is
removed, the DRM device can safely be unregistered and freed by calling
<function>drm_dev_unregister()</function> followed by a call to
<function>drm_dev_unref()</function>.
</para>
<title>Device Instance and Driver Handling</title>
!Pdrivers/gpu/drm/drm_drv.c driver instance overview
!Edrivers/gpu/drm/drm_drv.c
</sect2>
<sect2>
<title>Driver Load</title>
<para>
The <methodname>load</methodname> method is the driver and device
initialization entry point. The method is responsible for allocating and
initializing driver private data, performing resource allocation and
mapping (e.g. acquiring
clocks, mapping registers or allocating command buffers), initializing
the memory manager (<xref linkend="drm-memory-management"/>), installing
the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up
vertical blanking handling (<xref linkend="drm-vertical-blank"/>), mode
setting (<xref linkend="drm-mode-setting"/>) and initial output
configuration (<xref linkend="drm-kms-init"/>).
</para>
<note><para>
If compatibility is a concern (e.g. with drivers converted over from
User Mode Setting to Kernel Mode Setting), care must be taken to prevent
device initialization and control that is incompatible with currently
active userspace drivers. For instance, if user level mode setting
drivers are in use, it would be problematic to perform output discovery
&amp; configuration at load time. Likewise, if user-level drivers
unaware of memory management are in use, memory management and command
buffer setup may need to be omitted. These requirements are
driver-specific, and care needs to be taken to keep both old and new
applications and libraries working.
</para></note>
<synopsis>int (*load) (struct drm_device *, unsigned long flags);</synopsis>
<para>
The method takes two arguments, a pointer to the newly created
<structname>drm_device</structname> and flags. The flags are used to
pass the <structfield>driver_data</structfield> field of the device id
corresponding to the device passed to <function>drm_*_init()</function>.
Only PCI devices currently use this, USB and platform DRM drivers have
their <methodname>load</methodname> method called with flags to 0.
</para>
<sect3>
<title>Driver Private Data</title>
<para>
The driver private hangs off the main
<structname>drm_device</structname> structure and can be used for
tracking various device-specific bits of information, like register
offsets, command buffer status, register state for suspend/resume, etc.
At load time, a driver may simply allocate one and set
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
appropriately; it should be freed and
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
set to NULL when the driver is unloaded.
</para>
</sect3>
<sect3 id="drm-irq-registration">
<title>IRQ Registration</title>
<para>
@ -465,6 +411,18 @@ char *date;</synopsis>
</para>
</sect3>
</sect2>
<sect2>
<title>Bus-specific Device Registration and PCI Support</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI and platform devices respectively and are
only provided for historical reasons. These are all deprecated and
shouldn't be used in new drivers. Besides that there's a few
helpers for pci drivers.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_platform.c
</sect2>
</sect1>
<!-- Internals: memory management -->
@ -3646,10 +3604,11 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
plane properties to default value, so that a subsequent open of the
device will not inherit state from the previous user. It can also be
used to execute delayed power switching state changes, e.g. in
conjunction with the vga-switcheroo infrastructure. Beyond that KMS
drivers should not do any further cleanup. Only legacy UMS drivers might
need to clean up device state so that the vga console or an independent
fbdev driver could take over.
conjunction with the vga_switcheroo infrastructure (see
<xref linkend="vga_switcheroo"/>). Beyond that KMS drivers should not
do any further cleanup. Only legacy UMS drivers might need to clean up
device state so that the vga console or an independent fbdev driver
could take over.
</para>
</sect2>
<sect2>
@ -3747,11 +3706,14 @@ int num_ioctls;</synopsis>
</para></listitem>
<listitem><para>
DRM_UNLOCKED - The ioctl handler will be called without locking
the DRM global mutex
the DRM global mutex. This is the enforced default for kms drivers
(i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
any more for new drivers.
</para></listitem>
</itemizedlist>
</para>
</para>
!Edrivers/gpu/drm/drm_ioctl.c
</sect2>
</sect1>
<sect1>
@ -3949,8 +3911,8 @@ int num_ioctls;</synopsis>
<partintro>
<para>
This second part of the DRM Developer's Guide documents driver code,
implementation details and also all the driver-specific userspace
This second part of the GPU Driver Developer's Guide documents driver
code, implementation details and also all the driver-specific userspace
interfaces. Especially since all hardware-acceleration interfaces to
userspace are driver specific for efficiency and other reasons these
interfaces can be rather substantial. Hence every driver has its own
@ -4051,6 +4013,7 @@ int num_ioctls;</synopsis>
<title>High Definition Audio</title>
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
!Idrivers/gpu/drm/i915/intel_audio.c
!Iinclude/drm/i915_component.h
</sect2>
<sect2>
<title>Panel Self Refresh PSR (PSR/SRD)</title>
@ -4237,6 +4200,20 @@ int num_ioctls;</synopsis>
!Idrivers/gpu/drm/i915/i915_gem_shrinker.c
</sect2>
</sect1>
<sect1>
<title>GuC-based Command Submission</title>
<sect2>
<title>GuC</title>
!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
!Idrivers/gpu/drm/i915/intel_guc_loader.c
</sect2>
<sect2>
<title>GuC Client</title>
!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison
!Idrivers/gpu/drm/i915/i915_guc_submission.c
</sect2>
</sect1>
<sect1>
<title> Tracing </title>
<para>
@ -4260,4 +4237,50 @@ int num_ioctls;</synopsis>
</chapter>
!Cdrivers/gpu/drm/i915/i915_irq.c
</part>
<part id="vga_switcheroo">
<title>vga_switcheroo</title>
<partintro>
!Pdrivers/gpu/vga/vga_switcheroo.c Overview
</partintro>
<chapter id="modes_of_use">
<title>Modes of Use</title>
<sect1>
<title>Manual switching and manual power control</title>
!Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control
</sect1>
<sect1>
<title>Driver power control</title>
!Pdrivers/gpu/vga/vga_switcheroo.c Driver power control
</sect1>
</chapter>
<chapter id="pubfunctions">
<title>Public functions</title>
!Edrivers/gpu/vga/vga_switcheroo.c
</chapter>
<chapter id="pubstructures">
<title>Public structures</title>
!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops
</chapter>
<chapter id="pubconstants">
<title>Public constants</title>
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id
!Finclude/linux/vga_switcheroo.h vga_switcheroo_state
</chapter>
<chapter id="privstructures">
<title>Private structures</title>
!Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv
!Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client
</chapter>
!Cdrivers/gpu/vga/vga_switcheroo.c
!Cinclude/linux/vga_switcheroo.h
</part>
</book>

7
Documentation/IPMI.txt
View file

@ -587,7 +587,7 @@ used to control it:
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
preaction=<preaction type> preop=<preop type> start_now=x
nowayout=x ifnum_to_use=n
nowayout=x ifnum_to_use=n panic_wdt_timeout=<t>
ifnum_to_use specifies which interface the watchdog timer should use.
The default is -1, which means to pick the first one registered.
@ -597,7 +597,9 @@ is the amount of seconds before the reset that the pre-timeout panic will
occur (if pretimeout is zero, then pretimeout will not be enabled). Note
that the pretimeout is the time before the final timeout. So if the
timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout
will occur in 40 second (10 seconds before the timeout).
will occur in 40 second (10 seconds before the timeout). The panic_wdt_timeout
is the value of timeout which is set on kernel panic, in order to let actions
such as kdump to occur during panic.
The action may be "reset", "power_cycle", or "power_off", and
specifies what to do when the timer times out, and defaults to
@ -634,6 +636,7 @@ for configuring the watchdog:
ipmi_watchdog.preop=<preop type>
ipmi_watchdog.start_now=x
ipmi_watchdog.nowayout=x
ipmi_watchdog.panic_wdt_timeout=<t>
The options are the same as the module parameter options.

15
Documentation/SubmittingPatches
View file

@ -718,8 +718,21 @@ generates appropriate diffstats by default.)
See more details on the proper patch format in the following
references.
15) Explicit In-Reply-To headers
--------------------------------
15) Sending "git pull" requests
It can be helpful to manually add In-Reply-To: headers to a patch
(e.g., when using "git send email") to associate the patch with
previous relevant discussion, e.g. to link a bug fix to the email with
the bug report. However, for a multi-patch series, it is generally
best to avoid using In-Reply-To: to link to older versions of the
series. This way multiple versions of the patch don't become an
unmanageable forest of references in email clients. If a link is
helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in
the cover email text) to link to an earlier version of the patch series.
16) Sending "git pull" requests
-------------------------------
If you have a series of patches, it may be most convenient to have the

58
Documentation/acpi/i2c-muxes.txt Normal file
View file

@ -0,0 +1,58 @@
ACPI I2C Muxes
--------------
Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
Device () scope per mux channel.
Consider this topology:
+------+ +------+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+------+ +------+
which corresponds to the following ASL:
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^SMB1", 0x00,
ResourceConsumer,,)
}
Device (CH00)
{
Name (_ADR, 0)
Device (CLIA)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH00", 0x00,
ResourceConsumer,,)
}
}
}
Device (CH01)
{
Name (_ADR, 1)
Device (CLIB)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH01", 0x00,
ResourceConsumer,,)
}
}
}
}
}

5
Documentation/arm/Samsung/Bootloader-interface.txt
View file

@ -19,7 +19,7 @@ executing kernel.
Address: sysram_ns_base_addr
Offset Value Purpose
=============================================================================
0x08 exynos_cpu_resume_ns System suspend
0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend
0x0c 0x00000bad (Magic cookie) System suspend
0x1c exynos4_secondary_startup Secondary CPU boot
0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
@ -56,7 +56,8 @@ Offset Value Purpose
Address: pmu_base_addr
Offset Value Purpose
=============================================================================
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
0x0908 Non-zero Secondary CPU boot up indicator
on Exynos3250 and Exynos542x
4. Glossary

18
Documentation/arm/keystone/Overview.txt
View file

@ -49,24 +49,6 @@ specified through DTS. Following are the DTS used:-
The device tree documentation for the keystone machines are located at
Documentation/devicetree/bindings/arm/keystone/keystone.txt
Known issues & workaround
-------------------------
Some of the device drivers used on keystone are re-used from that from
DaVinci and other TI SoCs. These device drivers may use clock APIs directly.
Some of the keystone specific drivers such as netcp uses run time power
management API instead to enable clock. As this API has limitations on
keystone, following workaround is needed to boot Linux.
Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise
clock frameworks will try to disable clocks that are unused and disable
the hardware. This is because netcp related power domain and clock
domains are enabled in u-boot as run time power management API currently
doesn't enable clocks for netcp due to a limitation. This workaround is
expected to be removed in the future when proper API support becomes
available. Until then, this work around is needed.
Document Author
---------------
Murali Karicheri <m-karicheri2@ti.com>

56
Documentation/arm/keystone/knav-qmss.txt Normal file
View file

@ -0,0 +1,56 @@
* Texas Instruments Keystone Navigator Queue Management SubSystem driver
Driver source code path
drivers/soc/ti/knav_qmss.c
drivers/soc/ti/knav_qmss_acc.c
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
DT documentation is available at
Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
Accumulator QMSS queues using PDSP firmware
============================================
The QMSS PDSP firmware support accumulator channel that can monitor a single
queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
driver that interface with the accumulator PDSP. This configures
accumulator channels defined in DTS (example in DT documentation) to monitor
1 or 32 queues per channel. More description on the firmware is available in
CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
git://git.ti.com/keystone-rtos/qmss-lld.git
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
channels. This firmware is available under ti-keystone folder of
firmware.git at
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
To use copy the firmware image to lib/firmware folder of the initramfs or
ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
Use of accumulated queues requires the firmware image to be present in the
file system. The driver doesn't acc queues to the supported queue range if
PDSP is not running in the SoC. The API call fails if there is a queue open
request to an acc queue and PDSP is not running. So make sure to copy firmware
to file system before using these queue types.

2
Documentation/arm/sunxi/README
View file

@ -25,7 +25,7 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
- Allwinner A13 (sun5i)
- Allwinner A13 / R8 (sun5i)
+ Datasheet
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+ User Manual

3
Documentation/block/null_blk.txt
View file

@ -70,3 +70,6 @@ use_per_node_hctx=[0/1]: Default: 0
parameter.
1: The multi-queue block layer is instantiated with a hardware dispatch
queue for each CPU node in the system.
use_lightnvm=[0/1]: Default: 0
Register device with LightNVM. Requires blk-mq to be used.

10
Documentation/devicetree/bindings/arm/amlogic.txt
View file

@ -9,6 +9,12 @@ Boards with the Amlogic Meson8 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8";
Boards with the Amlogic Meson8b SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8b";
Board compatible values:
- "geniatech,atv1200"
- "minix,neo-x8"
- "geniatech,atv1200" (Meson6)
- "minix,neo-x8" (Meson8)
- "tronfy,mxq" (Meson8b)
- "hardkernel,odroid-c1" (Meson8b)

17
Documentation/devicetree/bindings/arm/apm/scu.txt Normal file
View file

@ -0,0 +1,17 @@
APM X-GENE SoC series SCU Registers
This system clock unit contain various register that control block resets,
clock enable/disables, clock divisors and other deepsleep registers.
Properties:
- compatible : should contain two values. First value must be:
- "apm,xgene-scu"
second value must be always "syscon".
- reg : offset and length of the register set.
Example :
scu: system-clk-controller@17000000 {
compatible = "apm,xgene-scu","syscon";
reg = <0x0 0x17000000 0x0 0x400>;
};

188
Documentation/devicetree/bindings/arm/arm,scpi.txt Normal file
View file

@ -0,0 +1,188 @@
System Control and Power Interface (SCPI) Message Protocol
----------------------------------------------------------
Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
by Linux to initiate various system control and power operations.
Required properties:
- compatible : should be "arm,scpi"
- mboxes: List of phandle and mailbox channel specifiers
All the channels reserved by remote SCP firmware for use by
SCPI message protocol should be specified in any order
- shmem : List of phandle pointing to the shared memory(SHM) area between the
processors using these mailboxes for IPC, one for each mailbox
SHM can be any memory reserved for the purpose of this communication
between the processors.
See Documentation/devicetree/bindings/mailbox/mailbox.txt
for more details about the generic mailbox controller and
client driver bindings.
Clock bindings for the clocks based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Container Node
==============
Required properties:
- compatible : should be "arm,scpi-clocks"
All the clocks provided by SCP firmware via SCPI message
protocol much be listed as sub-nodes under this node.
Sub-nodes
=========
Required properties:
- compatible : shall include one of the following
"arm,scpi-dvfs-clocks" - all the clocks that are variable and index based.
These clocks don't provide an entire range of values between the
limits but only discrete points within the range. The firmware
provides the mapping for each such operating frequency and the
index associated with it. The firmware also manages the
voltage scaling appropriately with the clock scaling.
"arm,scpi-variable-clocks" - all the clocks that are variable and provide full
range within the specified range. The firmware provides the
range of values within a specified range.
Other required properties for all clocks(all from common clock binding):
- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands.
- clock-output-names : shall be the corresponding names of the outputs.
- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
node. It can be non linear and hence provide the mapping of identifiers
into the clock-output-names array.
SRAM and Shared Memory for SCPI
-------------------------------
A small area of SRAM is reserved for SCPI communication between application
processors and SCP.
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
The rest of the properties should follow the generic mmio-sram description
found in ../../misc/sysram.txt
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[2].
Valid cell values are raw identifiers (Sensor
ID) as used by the firmware. Refer to
platform documentation for your
implementation for the IDs to use. For Juno
R0 and Juno R1 refer to [3].
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal.txt
[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
Example:
sram: sram@50000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,juno-scp-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,juno-scp-shmem";
reg = <0x200 0x200>;
};
};
mailbox: mailbox0@40000000 {
....
#mbox-cells = <1>;
};
scpi_protocol: scpi@2e000000 {
compatible = "arm,scpi";
mboxes = <&mailbox 0 &mailbox 1>;
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
clocks {
compatible = "arm,scpi-clocks";
scpi_dvfs: scpi_clocks@0 {
compatible = "arm,scpi-dvfs-clocks";
#clock-cells = <1>;
clock-indices = <0>, <1>, <2>;
clock-output-names = "atlclk", "aplclk","gpuclk";
};
scpi_clk: scpi_clocks@3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
clock-indices = <3>, <4>;
clock-output-names = "pxlclk0", "pxlclk1";
};
};
scpi_sensors0: sensors {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scpi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scpi_clk 4>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scpi_sensors0 3>;
...
};
};
In the above example, the #clock-cells is set to 1 as required.
scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
and pxlclk1 with 3 and 4 as clock-indices.
The first consumer in the example is cpu@0 and it has '0' as the clock
specifier which points to the first entry in the output clocks of
scpi_dvfs i.e. "atlclk".
Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input
clock. '4' in the clock specifier here points to the second entry
in the output clocks of scpi_clocks i.e. "pxlclk1"
The thermal-sensors property in the soc_thermal node uses the
temperature sensor provided by SCP firmware to setup a thermal
zone. The ID "3" is the sensor identifier for the temperature sensor
as used by the firmware.

162
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
View file

@ -20,6 +20,25 @@ system control is required:
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
hif-cpubiuctrl node
-------------------
SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit
(BIU) block which controls and interfaces the CPU complex to the different
Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block
offers a feature called Write Pairing which consists in collapsing two adjacent
cache lines into a single (bursted) write transaction towards the memory
controller (MEMC) to maximize write bandwidth.
Required properties:
- compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon"
Optional properties:
- brcm,write-pairing:
Boolean property, which when present indicates that the chip
supports write-pairing.
example:
rdb {
#address-cells = <1>;
@ -35,6 +54,7 @@ example:
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
reg = <0x3e2400 0x5b4>;
brcm,write-pairing;
};
hif_continuation: syscon@452000 {
@ -43,8 +63,7 @@ example:
};
};
Lastly, nodes that allow for support of SMP initialization and reboot are
required:
Nodes that allow for support of SMP initialization and reboot are required:
smpboot
-------
@ -95,3 +114,142 @@ example:
compatible = "brcm,brcmstb-reboot";
syscon = <&sun_top_ctrl 0x304 0x308>;
};
Power management
----------------
For power management (particularly, S2/S3/S5 system suspend), the following SoC
components are needed:
= Always-On control block (AON CTRL)
This hardware provides control registers for the "always-on" (even in low-power
modes) hardware, such as the Power Management State Machine (PMSM).
Required properties:
- compatible : should contain "brcm,brcmstb-aon-ctrl"
- reg : the register start and length for the AON CTRL block
Example:
aon-ctrl@410000 {
compatible = "brcm,brcmstb-aon-ctrl";
reg = <0x410000 0x400>;
};
= Memory controllers
A Broadcom STB SoC typically has a number of independent memory controllers,
each of which may have several associated hardware blocks, which are versioned
independently (control registers, DDR PHYs, etc.). One might consider
describing these controllers as a parent "memory controllers" block, which
contains N sub-nodes (one for each controller in the system), each of which is
associated with a number of hardware register resources (e.g., its PHY). See
the example device tree snippet below.
== MEMC (MEMory Controller)
Represents a single memory controller instance.
Required properties:
- compatible : should contain "brcm,brcmstb-memc" and "simple-bus"
Should contain subnodes for any of the following relevant hardware resources:
== DDR PHY control
Control registers for this memory controller's DDR PHY.
Required properties:
- compatible : should contain one of these
"brcm,brcmstb-ddr-phy-v225.1"
"brcm,brcmstb-ddr-phy-v240.1"
"brcm,brcmstb-ddr-phy-v240.2"
- reg : the DDR PHY register range
== DDR SHIMPHY
Control registers for this memory controller's DDR SHIMPHY.
Required properties:
- compatible : should contain "brcm,brcmstb-ddr-shimphy-v1.0"
- reg : the DDR SHIMPHY register range
== MEMC DDR control
Sequencer DRAM parameters and control registers. Used for Self-Refresh
Power-Down (SRPD), among other things.
Required properties:
- compatible : should contain "brcm,brcmstb-memc-ddr"
- reg : the MEMC DDR register range
Example:
memory_controllers {
ranges;
compatible = "simple-bus";
memc@0 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1106000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1106000 0x21c>;
};
shimphy@f1108000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1108000 0xe4>;
};
memc-ddr@f1102000 {
reg = <0xf1102000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@1 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1186000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1186000 0x21c>;
};
shimphy@f1188000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1188000 0xe4>;
};
memc-ddr@f1182000 {
reg = <0xf1182000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@2 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1206000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1206000 0x21c>;
};
shimphy@f1208000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1208000 0xe4>;
};
memc-ddr@f1202000 {
reg = <0xf1202000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
};

34
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt Normal file
View file

@ -0,0 +1,34 @@
Broadcom Northstar Plus device tree bindings
--------------------------------------------
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
Boards with Northstar Plus SoCs shall have the following properties:
Required root node property:
BCM58522
compatible = "brcm,bcm58522", "brcm,nsp";
BCM58525
compatible = "brcm,bcm58525", "brcm,nsp";
BCM58535
compatible = "brcm,bcm58535", "brcm,nsp";
BCM58622
compatible = "brcm,bcm58622", "brcm,nsp";
BCM58623
compatible = "brcm,bcm58623", "brcm,nsp";
BCM58625
compatible = "brcm,bcm58625", "brcm,nsp";
BCM88312
compatible = "brcm,bcm88312", "brcm,nsp";

5
Documentation/devicetree/bindings/arm/coherency-fabric.txt
View file

@ -27,6 +27,11 @@ Required properties:
* For "marvell,armada-380-coherency-fabric", only one pair is needed
for the per-CPU fabric registers.
Optional properties:
- broken-idle: boolean to set when the Idle mode is not supported by the
hardware.
Examples:
coherency-fabric@d0020200 {

2
Documentation/devicetree/bindings/arm/cpus.txt
View file

@ -195,6 +195,8 @@ nodes to be present and contain the properties described below.
"marvell,armada-380-smp"
"marvell,armada-390-smp"
"marvell,armada-xp-smp"
"mediatek,mt6589-smp"
"mediatek,mt81xx-tz-smp"
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"

16
Documentation/devicetree/bindings/arm/fsl.txt
View file

@ -128,10 +128,18 @@ Example:
reg = <0x0 0x1ee0000 0x0 0x10000>;
};
Freescale LS2085A SoC Device Tree Bindings
------------------------------------------
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
----------------------------------------------------------------
LS2085A ARMv8 based Simulator model
LS2080A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2085a-simu", "fsl,ls2085a";
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
LS2080A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls2080a-qds", "fsl,ls2080a";
LS2080A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";

4
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
View file

@ -20,6 +20,10 @@ HiKey Board
Required root node properties:
- compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
HiP05 D02 Board
Required root node properties:
- compatible = "hisilicon,hip05-d02";
Hisilicon system controller
Required properties:

20
Documentation/devicetree/bindings/arm/keystone/keystone.txt
View file

@ -9,12 +9,26 @@ Required properties:
the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
type UART should use the specified compatible for those devices.
SoC families:
- Keystone 2 generic SoC:
compatible = "ti,keystone"
SoCs:
- Keystone 2 Hawking/Kepler
compatible = "ti,k2hk", "ti,keystone"
- Keystone 2 Lamarr
compatible = "ti,k2l", "ti,keystone"
- Keystone 2 Edison
compatible = "ti,k2e", "ti,keystone"
Boards:
- Keystone 2 Hawking/Kepler EVM
compatible = "ti,k2hk-evm","ti,keystone"
compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"
- Keystone 2 Lamarr EVM
compatible = "ti,k2l-evm","ti,keystone"
compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"
- Keystone 2 Edison EVM
compatible = "ti,k2e-evm","ti,keystone"
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"

20
Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt Normal file
View file

@ -0,0 +1,20 @@
MVEBU CPU Config registers
--------------------------
MVEBU (Marvell SOCs: Armada 370/XP)
Required properties:
- compatible: one of:
- "marvell,armada-370-cpu-config"
- "marvell,armada-xp-cpu-config"
- reg: Should contain CPU config registers location and length, in
their per-CPU variant
Example:
cpu-config@21000 {
compatible = "marvell,armada-xp-cpu-config";
reg = <0x21000 0x8>;
};

1
Documentation/devicetree/bindings/arm/pmu.txt
View file

@ -7,6 +7,7 @@ representation in the device tree should be done as under:-
Required properties:
- compatible : should be one of
"apm,potenza-pmu"
"arm,armv8-pmuv3"
"arm.cortex-a57-pmu"
"arm.cortex-a53-pmu"

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

@ -31,6 +31,10 @@ Main node required properties:
support, but are permitted to be present for compatibility with
existing software when "arm,psci" is later in the compatible list.
* "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is
backward compatible with PSCI 0.2 with minor specification updates,
as defined in the PSCI specification[2].
- method : The method of calling the PSCI firmware. Permitted
values are:
@ -100,3 +104,5 @@ Case 3: PSCI v0.2 and PSCI v0.1.
[1] Kernel documentation - ARM idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt
[2] Power State Coordination Interface (PSCI) specification
http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

11
Documentation/devicetree/bindings/arm/rockchip.txt
View file

@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "radxa,rock", "rockchip,rk3188";
- Radxa Rock2 Square board:
Required root node properties:
- compatible = "radxa,rock2-square", "rockchip,rk3288";
- Firefly Firefly-RK3288 board:
Required root node properties:
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
@ -31,6 +35,13 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "netxeon,r89", "rockchip,rk3288";
- Google Jaq (Haier Chromebook 11 and more):
Required root node properties:
- compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
"google,veyron-jaq-rev3", "google,veyron-jaq-rev2",
"google,veyron-jaq-rev1", "google,veyron-jaq",
"google,veyron", "rockchip,rk3288";
- Google Jerry (Hisense Chromebook C11 and more):
Required root node properties:
- compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6",

27
Documentation/devicetree/bindings/arm/samsung-boards.txt
View file

@ -1,27 +0,0 @@
* Samsung's Exynos SoC based boards
Required root node properties:
- compatible = should be one or more of the following.
- "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:
- compatible: only "samsung,secure-firmware" is currently supported
- reg: address of non-secure SYSRAM used for communication with firmware
firmware@0203F000 {
compatible = "samsung,secure-firmware";
reg = <0x0203F000 0x1000>;
};

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

@ -0,0 +1,69 @@
* Samsung's Exynos SoC based boards
Required root node properties:
- compatible = should be one or more of the following.
- "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.
* Other companies Exynos SoC based
* FriendlyARM
- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
TINY4412 board.
* Google
- "google,pi" - for Exynos5800-based Google Peach Pi
Rev 10+ board,
also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14",
"google,pi-rev13", "google,pi-rev12", "google,pi-rev11",
"google,pi-rev10", "google,peach".
- "google,pit" - for Exynos5420-based Google Peach Pit
Rev 6+ (Exynos5420),
also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14",
"google,pit-rev13", "google,pit-rev12", "google,pit-rev11",
"google,pit-rev10", "google,pit-rev9", "google,pit-rev8",
"google,pit-rev7", "google,pit-rev6", "google,peach".
- "google,snow-rev4" - for Exynos5250-based Google Snow board,
also: "google,snow"
- "google,snow-rev5" - for Exynos5250-based Google Snow
Rev 5+ board.
- "google,spring" - for Exynos5250-based Google Spring board.
* Hardkernel
- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3.
- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X.
- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2.
- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3.
- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel
Odroid XU3 Lite board.
- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4.
* Insignal
- "insignal,arndale" - for Exynos5250-based Insignal Arndale board.
- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
Octa board.
- "insignal,origen" - for Exynos4210-based Insignal Origen board.
- "insignal,origen4412 - for Exynos4412-based Insignal Origen board.
Optional nodes:
- firmware node, specifying presence and type of secure firmware:
- compatible: only "samsung,secure-firmware" is currently supported
- reg: address of non-secure SYSRAM used for communication with firmware
firmware@0203F000 {
compatible = "samsung,secure-firmware";
reg = <0x0203F000 0x1000>;
};

10
Documentation/devicetree/bindings/arm/shmobile.txt
View file

@ -39,8 +39,6 @@ Boards:
compatible = "renesas,armadillo800eva"
- BOCK-W
compatible = "renesas,bockw", "renesas,r8a7778"
- BOCK-W - Reference Device Tree Implementation
compatible = "renesas,bockw-reference", "renesas,r8a7778"
- Genmai (RTK772100BC00000BR)
compatible = "renesas,genmai", "renesas,r7s72100"
- Gose
@ -57,7 +55,7 @@ Boards:
compatible = "renesas,lager", "renesas,r8a7790"
- Marzen
compatible = "renesas,marzen", "renesas,r8a7779"
Note: Reference Device Tree Implementations are temporary implementations
to ease the migration from platform devices to Device Tree, and are
intended to be removed in the future.
- Porter (M2-LCDP)
compatible = "renesas,porter", "renesas,r8a7791"
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"

1
Documentation/devicetree/bindings/arm/sunxi.txt
View file

@ -6,6 +6,7 @@ using one of the following compatible strings:
allwinner,sun4i-a10
allwinner,sun5i-a10s
allwinner,sun5i-a13
allwinner,sun5i-r8
allwinner,sun6i-a31
allwinner,sun7i-a20
allwinner,sun8i-a23

60
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt Normal file
View file

@ -0,0 +1,60 @@
UniPhier outer cache controller
UniPhier SoCs are integrated with a full-custom outer cache controller system.
All of them have a level 2 cache controller, and some have a level 3 cache
controller as well.
Required properties:
- compatible: should be "socionext,uniphier-system-cache"
- reg: offsets and lengths of the register sets for the device. It should
contain 3 regions: control register, revision register, operation register,
in this order.
- cache-unified: specifies the cache is a unified cache.
- cache-size: specifies the size in bytes of the cache
- cache-sets: specifies the number of associativity sets of the cache
- cache-line-size: specifies the line size in bytes
- cache-level: specifies the level in the cache hierarchy. The value should
be 2 for L2 cache, 3 for L3 cache, etc.
Optional properties:
- next-level-cache: phandle to the next level cache if present. The next level
cache should be also compatible with "socionext,uniphier-system-cache".
The L2 cache must exist to use the L3 cache; the cache hierarchy must be
indicated correctly with "next-level-cache" properties.
Example 1 (system with L2):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x4>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x80000>;
cache-sets = <256>;
cache-line-size = <128>;
cache-level = <2>;
};
Example 2 (system with L2 and L3):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x8>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
next-level-cache = <&l3>;
};
l3: l3-cache@500c8000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
<0x506c8000 0x400>;
cache-unified;
cache-size = <0x400000>;
cache-sets = <512>;
cache-line-size = <256>;
cache-level = <3>;
};

14
Documentation/devicetree/bindings/powerpc/fsl/board.txt → Documentation/devicetree/bindings/board/fsl-board.txt
View file

@ -21,11 +21,14 @@ Example:
This is the memory-mapped registers for on board FPGA.
Required properities:
Required properties:
- compatible: should be a board-specific string followed by a string
indicating the type of FPGA. Example:
"fsl,<board>-fpga", "fsl,fpga-pixis"
"fsl,<board>-fpga", "fsl,fpga-pixis", or
"fsl,<board>-fpga", "fsl,fpga-qixis"
- reg: should contain the address and the length of the FPGA register set.
Optional properties:
- interrupt-parent: should specify phandle for the interrupt controller.
- interrupts: should specify event (wakeup) IRQ.
@ -38,6 +41,13 @@ Example (P1022DS):
interrupts = <8 8 0 0>;
};
Example (LS2080A-RDB):
cpld@3,0 {
compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis";
reg = <0x3 0 0x10000>;
};
* Freescale BCSR GPIO banks
Some BCSR registers act as simple GPIO controllers, each such

47
Documentation/devicetree/bindings/bus/sunxi-rsb.txt Normal file
View file

@ -0,0 +1,47 @@
Allwinner Reduced Serial Bus (RSB) controller
The RSB controller found on later Allwinner SoCs is an SMBus like 2 wire
serial bus with 1 master and up to 15 slaves. It is represented by a node
for the controller itself, and child nodes representing the slave devices.
Required properties :
- reg : Offset and length of the register set for the controller.
- compatible : Shall be "allwinner,sun8i-a23-rsb".
- interrupts : The interrupt line associated to the RSB controller.
- clocks : The gate clk associated to the RSB controller.
- resets : The reset line associated to the RSB controller.
- #address-cells : shall be 1
- #size-cells : shall be 0
Optional properties :
- clock-frequency : Desired RSB bus clock frequency in Hz. Maximum is 20MHz.
If not set this defaults to 3MHz.
Child nodes:
An RSB controller node can contain zero or more child nodes representing
slave devices on the bus. Child 'reg' properties should contain the slave
device's hardware address. The hardware address is hardwired in the device,
which can normally be found in the datasheet.
Example:
rsb@01f03400 {
compatible = "allwinner,sun8i-a23-rsb";
reg = <0x01f03400 0x400>;
interrupts = <0 39 4>;
clocks = <&apb0_gates 3>;
clock-frequency = <3000000>;
resets = <&apb0_rst 3>;
#address-cells = <1>;
#size-cells = <0>;
pmic@3e3 {
compatible = "...";
reg = <0x3e3>;
/* ... */
};
};

4
Documentation/devicetree/bindings/clock/qcom,gcc.txt
View file

@ -18,10 +18,14 @@ Required properties :
- #clock-cells : shall contain 1
- #reset-cells : shall contain 1
Optional properties :
- #power-domain-cells : shall contain 1
Example:
clock-controller@900000 {
compatible = "qcom,gcc-msm8960";
reg = <0x900000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};

4
Documentation/devicetree/bindings/clock/qcom,mmcc.txt
View file

@ -14,10 +14,14 @@ Required properties :
- #clock-cells : shall contain 1
- #reset-cells : shall contain 1
Optional properties :
- #power-domain-cells : shall contain 1
Example:
clock-controller@4000000 {
compatible = "qcom,mmcc-msm8960";
reg = <0x4000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};

65
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt Normal file
View file

@ -0,0 +1,65 @@
Broadcom VC4 (VideoCore4) GPU
The VC4 device present on the Raspberry Pi includes a display system
with HDMI output and the HVS (Hardware Video Scaler) for compositing
display planes.
Required properties for VC4:
- compatible: Should be "brcm,bcm2835-vc4"
Required properties for Pixel Valve:
- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
"brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
- reg: Physical base address and length of the PV's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for HVS:
- compatible: Should be "brcm,bcm2835-hvs"
- reg: Physical base address and length of the HVS's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for HDMI
- compatible: Should be "brcm,bcm2835-hdmi"
- reg: Physical base address and length of the two register ranges
("HDMI" and "HD", in that order)
- interrupts: The interrupt numbers
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
- ddc: phandle of the I2C controller used for DDC EDID probing
- clocks: a) hdmi: The HDMI state machine clock
b) pixel: The pixel clock.
Optional properties for HDMI:
- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear
as an interrupt/status bit in the HDMI controller
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
Example:
pixelvalve@7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
reg = <0x7e807000 0x100>;
interrupts = <2 10>; /* pixelvalve */
};
hvs@7e400000 {
compatible = "brcm,bcm2835-hvs";
reg = <0x7e400000 0x6000>;
interrupts = <2 1>;
};
hdmi: hdmi@7e902000 {
compatible = "brcm,bcm2835-hdmi";
reg = <0x7e902000 0x600>,
<0x7e808000 0x100>;
interrupts = <2 8>, <2 9>;
ddc = <&i2c2>;
hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
clocks = <&clocks BCM2835_PLLH_PIX>,
<&clocks BCM2835_CLOCK_HSM>;
clock-names = "pixel", "hdmi";
};
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};

3
Documentation/devicetree/bindings/display/msm/hdmi.txt
View file

@ -2,6 +2,7 @@ Qualcomm adreno/snapdragon hdmi output
Required properties:
- compatible: one of the following
* "qcom,hdmi-tx-8996"
* "qcom,hdmi-tx-8994"
* "qcom,hdmi-tx-8084"
* "qcom,hdmi-tx-8974"
@ -21,6 +22,7 @@ Required properties:
Optional properties:
- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
- power-domains: reference to the power domain(s), if available.
- pinctrl-names: the pin control state names; should contain "default"
- pinctrl-0: the default pinctrl state (active)
- pinctrl-1: the "sleep" pinctrl state
@ -35,6 +37,7 @@ Example:
reg-names = "core_physical";
reg = <0x04a00000 0x1000>;
interrupts = <GIC_SPI 79 0>;
power-domains = <&mmcc MDSS_GDSC>;
clock-names =
"core_clk",
"master_iface_clk",

3
Documentation/devicetree/bindings/display/msm/mdp.txt
View file

@ -11,13 +11,14 @@ Required properties:
- clock-names: the following clocks are required:
* "core_clk"
* "iface_clk"
* "lut_clk"
* "src_clk"
* "hdmi_clk"
* "mpd_clk"
Optional properties:
- gpus: phandle for gpu device
- clock-names: the following clocks are optional:
* "lut_clk"
Example:

14
Documentation/devicetree/bindings/display/renesas,du.txt
View file

@ -5,7 +5,9 @@ Required Properties:
- compatible: must be one of the following.
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
- "renesas,du-r8a7791" for R8A7791 (R-Car M2) compatible DU
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
- reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
@ -22,9 +24,9 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
- R8A7790 and R8A7791 use one functional clock per channel and one clock
per LVDS encoder. The functional clocks must be named "du.x" with "x"
being the channel numerical index. The LVDS clocks must be named
- R8A779[0134] use one functional clock per channel and one clock per LVDS
encoder (if available). The functional clocks must be named "du.x" with
"x" being the channel numerical index. The LVDS clocks must be named
"lvds.x" with "x" being the LVDS encoder numerical index.
- In addition to the functional and encoder clocks, all DU versions also
support externally supplied pixel clocks. Those clocks are optional.
@ -43,7 +45,9 @@ corresponding to each DU output.
-----------------------------------------------------------------------------
R8A7779 (H1) DPAD 0 DPAD 1 -
R8A7790 (H2) DPAD LVDS 0 LVDS 1
R8A7791 (M2) DPAD LVDS 0 -
R8A7791 (M2-W) DPAD LVDS 0 -
R8A7793 (M2-N) DPAD LVDS 0 -
R8A7794 (E2) DPAD 0 DPAD 1 -
Example: R8A7790 (R-Car H2) DU

3
Documentation/devicetree/bindings/display/ssd1307fb.txt
View file

@ -2,7 +2,8 @@
Required properties:
- compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307.
now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and
ssd1309.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM

15
Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
View file

@ -2,9 +2,10 @@ Texas Instruments DMA Crossbar (DMA request router)
Required properties:
- compatible: "ti,dra7-dma-crossbar" for DRA7xx DMA crossbar
"ti,am335x-edma-crossbar" for AM335x and AM437x
- reg: Memory map for accessing module
- #dma-cells: Should be set to <1>.
Clients should use the crossbar request number (input)
- #dma-cells: Should be set to to match with the DMA controller's dma-cells
for ti,dra7-dma-crossbar and <3> for ti,am335x-edma-crossbar.
- dma-requests: Number of DMA requests the crossbar can receive
- dma-masters: phandle pointing to the DMA controller
@ -14,6 +15,15 @@ The DMA controller node need to have the following poroperties:
Optional properties:
- ti,dma-safe-map: Safe routing value for unused request lines
Notes:
When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
the DMA event number as crossbar ID (input to the DMA crossbar).
For ti,am335x-edma-crossbar: the meaning of parameters of dmas for clients:
dmas = <&edma_xbar 12 0 1>; where <12> is the DMA request number, <0> is the TC
the event should be assigned and <1> is the mux selection for in the crossbar.
When mux 0 is used the DMA channel can be requested directly from edma node.
Example:
/* DMA controller */
@ -47,6 +57,7 @@ uart1: serial@4806a000 {
ti,hwmods = "uart1";
clock-frequency = <48000000>;
status = "disabled";
/* Requesting crossbar input 49 and 50 */
dmas = <&sdma_xbar 49>, <&sdma_xbar 50>;
dma-names = "tx", "rx";
};

117
Documentation/devicetree/bindings/dma/ti-edma.txt
View file

@ -1,4 +1,119 @@
TI EDMA
Texas Instruments eDMA
The eDMA3 consists of two components: Channel controller (CC) and Transfer
Controller(s) (TC). The CC is the main entry for DMA users since it is
responsible for the DMA channel handling, while the TCs are responsible to
execute the actual DMA tansfer.
------------------------------------------------------------------------------
eDMA3 Channel Controller
Required properties:
- compatible: "ti,edma3-tpcc" for the channel controller(s)
- #dma-cells: Should be set to <2>. The first number is the DMA request
number and the second is the TC the channel is serviced on.
- reg: Memory map of eDMA CC
- reg-names: "edma3_cc"
- interrupts: Interrupt lines for CCINT, MPERR and CCERRINT.
- interrupt-names: "edma3_ccint", "emda3_mperr" and "edma3_ccerrint"
- ti,tptcs: List of TPTCs associated with the eDMA in the following form:
<&tptc_phandle TC_priority_number>. The highest priority is 0.
Optional properties:
- ti,hwmods: Name of the hwmods associated to the eDMA CC
- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow
these channels will be SW triggered channels. The list must
contain 16 bits numbers, see example.
- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
the driver, they are allocated to be used by for example the
DSP. See example.
------------------------------------------------------------------------------
eDMA3 Transfer Controller
Required properties:
- compatible: "ti,edma3-tptc" for the transfer controller(s)
- reg: Memory map of eDMA TC
- interrupts: Interrupt number for TCerrint.
Optional properties:
- ti,hwmods: Name of the hwmods associated to the given eDMA TC
- interrupt-names: "edma3_tcerrint"
------------------------------------------------------------------------------
Example:
edma: edma@49000000 {
compatible = "ti,edma3-tpcc";
ti,hwmods = "tpcc";
reg = <0x49000000 0x10000>;
reg-names = "edma3_cc";
interrupts = <12 13 14>;
interrupt-names = "edma3_ccint", "emda3_mperr", "edma3_ccerrint";
dma-requests = <64>;
#dma-cells = <2>;
ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 7>, <&edma_tptc2 0>;
/* Channel 20 and 21 is allocated for memcpy */
ti,edma-memcpy-channels = /bits/ 16 <20 21>;
/* The following PaRAM slots are reserved: 35-45 and 100-110 */
ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
/bits/ 16 <100 10>;
};
edma_tptc0: tptc@49800000 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc0";
reg = <0x49800000 0x100000>;
interrupts = <112>;
interrupt-names = "edm3_tcerrint";
};
edma_tptc1: tptc@49900000 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc1";
reg = <0x49900000 0x100000>;
interrupts = <113>;
interrupt-names = "edm3_tcerrint";
};
edma_tptc2: tptc@49a00000 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc2";
reg = <0x49a00000 0x100000>;
interrupts = <114>;
interrupt-names = "edm3_tcerrint";
};
sham: sham@53100000 {
compatible = "ti,omap4-sham";
ti,hwmods = "sham";
reg = <0x53100000 0x200>;
interrupts = <109>;
/* DMA channel 36 executed on eDMA TC0 - low priority queue */
dmas = <&edma 36 0>;
dma-names = "rx";
};
mcasp0: mcasp@48038000 {
compatible = "ti,am33xx-mcasp-audio";
ti,hwmods = "mcasp0";
reg = <0x48038000 0x2000>,
<0x46000000 0x400000>;
reg-names = "mpu", "dat";
interrupts = <80>, <81>;
interrupt-names = "tx", "rx";
status = "disabled";
/* DMA channels 8 and 9 executed on eDMA TC2 - high priority queue */
dmas = <&edma 8 2>,
<&edma 9 2>;
dma-names = "tx", "rx";
};
------------------------------------------------------------------------------
DEPRECATED binding, new DTS files must use the ti,edma3-tpcc/ti,edma3-tptc
binding.
Required properties:
- compatible : "ti,edma3"

4
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
View file

@ -1,9 +1,9 @@
* Freescale MPC512x/MPC8xxx GPIO controller
* Freescale MPC512x/MPC8xxx/Layerscape GPIO controller
Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and

29
Documentation/devicetree/bindings/hwmon/pwm-fan.txt
View file

@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
- cooling-levels : PWM duty cycle values in a range from 0 to 255
which correspond to thermal cooling states
Example:
pwm-fan {
fan0: pwm-fan {
compatible = "pwm-fan";
status = "okay";
cooling-min-state = <0>;
cooling-max-state = <3>;
#cooling-cells = <2>;
pwms = <&pwm 0 10000 0>;
cooling-levels = <0 102 170 230>;
};
thermal-zones {
cpu_thermal: cpu-thermal {
thermal-sensors = <&tmu 0>;
polling-delay-passive = <0>;
polling-delay = <0>;
trips {
cpu_alert1: cpu-alert1 {
temperature = <100000>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "passive";
};
};
cooling-maps {
map0 {
trip = <&cpu_alert1>;
cooling-device = <&fan0 0 1>;
};
};
};

6
Documentation/devicetree/bindings/i2c/i2c-davinci.txt
View file

@ -1,10 +1,10 @@
* Texas Instruments Davinci I2C
* Texas Instruments Davinci/Keystone I2C
This file provides information, what the device node for the
davinci i2c interface contain.
davinci/keystone i2c interface contains.
Required properties:
- compatible: "ti,davinci-i2c";
- compatible: "ti,davinci-i2c" or "ti,keystone-i2c";
- reg : Offset and length of the register set for the device
Recommended properties :

9
Documentation/devicetree/bindings/i2c/i2c-imx.txt
View file

@ -14,6 +14,10 @@ Optional properties:
The absence of the propoerty indicates the default frequency 100 kHz.
- dmas: A list of two dma specifiers, one for each entry in dma-names.
- dma-names: should contain "tx" and "rx".
- scl-gpios: specify the gpio related to SCL pin
- sda-gpios: specify the gpio related to SDA pin
- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c
bus recovery, call it "gpio" state
Examples:
@ -37,4 +41,9 @@ i2c0: i2c@40066000 { /* i2c0 on vf610 */
dmas = <&edma0 0 50>,
<&edma0 0 51>;
dma-names = "rx","tx";
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
scl-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>;
sda-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;
};

1
Documentation/devicetree/bindings/i2c/i2c-rcar.txt
View file

@ -10,6 +10,7 @@ Required properties:
"renesas,i2c-r8a7792"
"renesas,i2c-r8a7793"
"renesas,i2c-r8a7794"
"renesas,i2c-r8a7795"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.

1
Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
View file

@ -10,6 +10,7 @@ Required properties:
- "renesas,iic-r8a7792" (R-Car V2H)
- "renesas,iic-r8a7793" (R-Car M2-N)
- "renesas,iic-r8a7794" (R-Car E2)
- "renesas,iic-r8a7795" (R-Car H3)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
- reg : address start and address range size of device
- interrupts : interrupt of device

25
Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt Normal file
View file

@ -0,0 +1,25 @@
UniPhier I2C controller (FIFO-builtin)
Required properties:
- compatible: should be "socionext,uniphier-fi2c".
- #address-cells: should be 1.
- #size-cells: should be 0.
- reg: offset and length of the register set for the device.
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
Optional properties:
- clock-frequency: desired I2C bus frequency in Hz. The maximum supported
value is 400000. Defaults to 100000 if not specified.
Examples:
i2c0: i2c@58780000 {
compatible = "socionext,uniphier-fi2c";
reg = <0x58780000 0x80>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = <0 41 4>;
clocks = <&i2c_clk>;
clock-frequency = <100000>;
};

25
Documentation/devicetree/bindings/i2c/i2c-uniphier.txt Normal file
View file

@ -0,0 +1,25 @@
UniPhier I2C controller (FIFO-less)
Required properties:
- compatible: should be "socionext,uniphier-i2c".
- #address-cells: should be 1.
- #size-cells: should be 0.
- reg: offset and length of the register set for the device.
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
Optional properties:
- clock-frequency: desired I2C bus frequency in Hz. The maximum supported
value is 400000. Defaults to 100000 if not specified.
Examples:
i2c0: i2c@58400000 {
compatible = "socionext,uniphier-i2c";
reg = <0x58400000 0x40>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = <0 41 1>;
clocks = <&i2c_clk>;
clock-frequency = <100000>;
};

34
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
View file

@ -1,14 +1,15 @@
* Texas Instruments tsc2005 touchscreen controller
* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
Required properties:
- compatible : "ti,tsc2005"
- reg : SPI device address
- spi-max-frequency : Maximal SPI speed
- compatible : "ti,tsc2004" or "ti,tsc2005"
- reg : Device address
- interrupts : IRQ specifier
- reset-gpios : GPIO specifier
- vio-supply : Regulator specifier
- spi-max-frequency : Maximum SPI clocking speed of the device
(for tsc2005)
Optional properties:
- vio-supply : Regulator specifier
- reset-gpios : GPIO specifier for the controller reset line
- ti,x-plate-ohms : integer, resistance of the touchscreen's X plates
in ohm (defaults to 280)
- ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
@ -18,6 +19,27 @@ Optional properties:
Example:
&i2c3 {
tsc2004@48 {
compatible = "ti,tsc2004";
reg = <0x48>;
vio-supply = <&vio>;
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
touchscreen-fuzz-pressure = <2>;
touchscreen-size-x = <4096>;
touchscreen-size-y = <4096>;
touchscreen-max-pressure = <2048>;
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
};
}
&mcspi1 {
tsc2005@0 {
compatible = "ti,tsc2005";

2
Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
View file

@ -47,7 +47,7 @@ Required properties:
- clocks: Required if the System MMU is needed to gate its clock.
- power-domains: Required if the System MMU is needed to gate its power.
Please refer to the following document:
Documentation/devicetree/bindings/arm/exynos/power_domain.txt
Documentation/devicetree/bindings/power/pd-samsung.txt
Examples:
gsc_0: gsc@13e00000 {

8
Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt
View file

@ -1,8 +1,9 @@
* Device tree bindings for ARM PL172 MultiPort Memory Controller
* Device tree bindings for ARM PL172/PL175/PL176 MultiPort Memory Controller
Required properties:
- compatible: "arm,pl172", "arm,primecell"
- compatible: Must be "arm,primecell" and exactly one from
"arm,pl172", "arm,pl175" or "arm,pl176".
- reg: Must contains offset/length value for controller.
@ -56,7 +57,8 @@ Optional child cs node config properties:
- mpmc,extended-wait: Enable extended wait.
- mpmc,buffer-enable: Enable write buffer.
- mpmc,buffer-enable: Enable write buffer, option is not supported by
PL175 and PL176 controllers.
- mpmc,write-protect: Enable write protect.

6
Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt
View file

@ -24,9 +24,9 @@ Required properties:
Optional properties:
- interrupts: Must contain a list of interrupt specifiers for memory
controller interrupts, if available.
- interrupts-names: Must contain a list of interrupt names corresponding to
the interrupts in the interrupts property, if available.
Valid interrupt names are:
- interrupt-names: Must contain a list of interrupt names corresponding to
the interrupts in the interrupts property, if available.
Valid interrupt names are:
- "sec" (secure interrupt)
- "temp" (normal (temperature) interrupt)
- power-domains: Must contain a reference to the PM domain that the memory

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

@ -22,6 +22,10 @@ Optional properties:
- samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled
down. When the system is suspended it will always go down thus triggerring
unwanted buck warm reset (setting buck voltages to default values).
- samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is
connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1
register to turn off the power. Usually the ACOKB is pulled up to VBATT so
when PWRHOLD pin goes low, the rising ACOKB will trigger power off.
Optional nodes:
- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768

83
Documentation/devicetree/bindings/mips/img/xilfpga.txt Normal file
View file

@ -0,0 +1,83 @@
Imagination University Program MIPSfpga
=======================================
Under the Imagination University Program, a microAptiv UP core has been
released for academic usage.
As we are dealing with a MIPS core instantiated on an FPGA, specifications
are fluid and can be varied in RTL.
This binding document is provided as baseline guidance for the example
project provided by IMG.
The example project runs on the Nexys4DDR board by Digilent powered by
the ARTIX-7 FPGA by Xilinx.
Relevant details about the example project and the Nexys4DDR board:
- microAptiv UP core m14Kc
- 50MHz clock speed
- 128Mbyte DDR RAM at 0x0000_0000
- 8Kbyte RAM at 0x1000_0000
- axi_intc at 0x1020_0000
- axi_uart16550 at 0x1040_0000
- axi_gpio at 0x1060_0000
- axi_i2c at 0x10A0_0000
- custom_gpio at 0x10C0_0000
- axi_ethernetlite at 0x10E0_0000
- 8Kbyte BootRAM at 0x1FC0_0000
Required properties:
--------------------
- compatible: Must include "digilent,nexys4ddr","img,xilfpga".
CPU nodes:
----------
A "cpus" node is required. Required properties:
- #address-cells: Must be 1.
- #size-cells: Must be 0.
A CPU sub-node is also required for at least CPU 0. Required properties:
- device_type: Must be "cpu".
- compatible: Must be "mips,m14Kc".
- reg: Must be <0>.
- clocks: phandle to ext clock for fixed-clock received by MIPS core.
Example:
compatible = "img,xilfpga","digilent,nexys4ddr";
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "mips,m14Kc";
reg = <0>;
clocks = <&ext>;
};
};
ext: ext {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <50000000>;
};
Boot protocol:
--------------
The BootRAM is a writeable "RAM" in FPGA at 0x1FC0_0000.
This is for easy reprogrammibility via JTAG.
The BootRAM initializes the cache and the axi_uart peripheral.
DDR initialization is already handled by a HW IP block.
When the example project bitstream is loaded, the cpu_reset button
needs to be pressed.
The bootram initializes the cache and axi_uart.
Then outputs MIPSFPGA\n\r on the serial port on the Nexys4DDR board.
At this point, the board is ready to load the Linux kernel
vmlinux file via JTAG.

5
Documentation/devicetree/bindings/net/cpsw.txt
View file

@ -48,6 +48,11 @@ Optional properties:
- mac-address : See ethernet.txt file in the same directory
- phy-handle : See ethernet.txt file in the same directory
Slave sub-nodes:
- fixed-link : See fixed-link.txt file in the same directory
Either the properties phy_id and phy-mode,
or the sub-node fixed-link can be specified
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree

10
Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt Normal file
View file

@ -0,0 +1,10 @@
* ARM Juno R1 PCIe interface
This PCIe host controller is based on PLDA XpressRICH3-AXI IP
and thus inherits all the common properties defined in plda,xpressrich3-axi.txt
as well as the base properties defined in host-generic-pci.txt.
Required properties:
- compatible: "arm,juno-r1-pcie"
- dma-coherent: The host controller bridges the AXI transactions into PCIe bus
in a manner that makes the DMA operations to appear coherent to the CPUs.

12
Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt Normal file
View file

@ -0,0 +1,12 @@
* PLDA XpressRICH3-AXI host controller
The PLDA XpressRICH3-AXI host controller can be configured in a manner that
makes it compliant with the SBSA[1] standard published by ARM Ltd. For those
scenarios, the host-generic-pci.txt bindings apply with the following additions
to the compatible property:
Required properties:
- compatible: should contain "plda,xpressrich3-axi" to identify the IP used.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/

5
Documentation/devicetree/bindings/arm/exynos/power_domain.txt → Documentation/devicetree/bindings/power/pd-samsung.txt
View file

@ -43,9 +43,8 @@ Example:
mfc_pd: power-domain@10044060 {
compatible = "samsung,exynos4210-pd";
reg = <0x10044060 0x20>;
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
<&clock CLK_MOUT_USER_ACLK333>;
clock-names = "oscclk", "pclk0", "clk0";
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_USER_ACLK333>;
clock-names = "oscclk", "clk0";
#power-domain-cells = <0>;
};

20
Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt Normal file
View file

@ -0,0 +1,20 @@
Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller)
Required properties:
- compatible: must be "brcm,bcm7038-pwm"
- reg: physical base address and length for this controller
- #pwm-cells: should be 2. See pwm.txt in this directory for a description
of the cells format
- clocks: a phandle to the reference clock for this block which is fed through
its internal variable clock frequency generator
Example:
pwm: pwm@f0408000 {
compatible = "brcm,bcm7038-pwm";
reg = <0xf0408000 0x28>;
#pwm-cells = <2>;
clocks = <&upg_fixed>;
};

17
Documentation/devicetree/bindings/pwm/pwm-berlin.txt Normal file
View file

@ -0,0 +1,17 @@
Berlin PWM controller
Required properties:
- compatible: should be "marvell,berlin-pwm"
- reg: physical base address and length of the controller's registers
- clocks: phandle to the input clock
- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
the cells format.
Example:
pwm: pwm@f7f20000 {
compatible = "marvell,berlin-pwm";
reg = <0xf7f20000 0x40>;
clocks = <&chip_clk CLKID_CFG>;
#pwm-cells = <3>;
}

42
Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt Normal file
View file

@ -0,0 +1,42 @@
MediaTek display PWM controller
Required properties:
- compatible: should be "mediatek,<name>-disp-pwm":
- "mediatek,mt8173-disp-pwm": found on mt8173 SoC.
- "mediatek,mt6595-disp-pwm": found on mt6595 SoC.
- reg: physical base address and length of the controller's registers.
- #pwm-cells: must be 2. See pwm.txt in this directory for a description of
the cell format.
- clocks: phandle and clock specifier of the PWM reference clock.
- clock-names: must contain the following:
- "main": clock used to generate PWM signals.
- "mm": sync signals from the modules of mmsys.
- pinctrl-names: Must contain a "default" entry.
- pinctrl-0: One property must exist for each entry in pinctrl-names.
See pinctrl/pinctrl-bindings.txt for details of the property values.
Example:
pwm0: pwm@1401e000 {
compatible = "mediatek,mt8173-disp-pwm",
"mediatek,mt6595-disp-pwm";
reg = <0 0x1401e000 0 0x1000>;
#pwm-cells = <2>;
clocks = <&mmsys CLK_MM_DISP_PWM026M>,
<&mmsys CLK_MM_DISP_PWM0MM>;
clock-names = "main", "mm";
pinctrl-names = "default";
pinctrl-0 = <&disp_pwm0_pins>;
};
backlight_lcd: backlight_lcd {
compatible = "pwm-backlight";
pwms = <&pwm0 0 1000000>;
brightness-levels = <
0 16 32 48 64 80 96 112
128 144 160 176 192 208 224 240
255
>;
default-brightness-level = <9>;
power-supply = <&mt6397_vio18_reg>;
enable-gpios = <&pio 95 GPIO_ACTIVE_HIGH>;
};

2
Documentation/devicetree/bindings/pwm/pwm-sun4i.txt
View file

@ -3,6 +3,8 @@ Allwinner sun4i and sun7i SoC PWM controller
Required properties:
- compatible: should be one of:
- "allwinner,sun4i-a10-pwm"
- "allwinner,sun5i-a10s-pwm"
- "allwinner,sun5i-a13-pwm"
- "allwinner,sun7i-a20-pwm"
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 3. See pwm.txt in this directory for a description of

26
Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt Normal file
View file

@ -0,0 +1,26 @@
* Renesas R-Car PWM Timer Controller
Required Properties:
- compatible: should be "renesas,pwm-rcar" and one of the following.
- "renesas,pwm-r8a7778": for R-Car M1A
- "renesas,pwm-r8a7779": for R-Car H1
- "renesas,pwm-r8a7790": for R-Car H2
- "renesas,pwm-r8a7791": for R-Car M2-W
- "renesas,pwm-r8a7794": for R-Car E2
- reg: base address and length of the registers block for the PWM.
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
the cells format.
- clocks: clock phandle and specifier pair.
- pinctrl-0: phandle, referring to a default pin configuration node.
- pinctrl-names: Set to "default".
Example: R8A7790 (R-Car H2) PWM Timer node
pwm0: pwm@e6e30000 {
compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar";
reg = <0 0xe6e30000 0 0x8>;
#pwm-cells = <2>;
clocks = <&mstp5_clks R8A7790_CLK_PWM>;
pinctrl-0 = <&pwm0_pins>;
pinctrl-names = "default";
};

18
Documentation/devicetree/bindings/rtc/dallas,ds1390.txt Normal file
View file

@ -0,0 +1,18 @@
* Dallas DS1390 SPI Serial Real-Time Clock
Required properties:
- compatible: Should contain "dallas,ds1390".
- reg: SPI address for chip
Optional properties:
- trickle-resistor-ohms : Selected resistor for trickle charger
Values usable for ds1390 are 250, 2000, 4000
Should be given if trickle charger should be enabled
- trickle-diode-disable : Do not use internal trickle charger diode
Should be given if internal trickle charger diode should be disabled
Example:
ds1390: rtc@68 {
compatible = "dallas,ds1390";
trickle-resistor-ohms = <250>;
reg = <0>;
};

25
Documentation/devicetree/bindings/rtc/pcf8563.txt Normal file
View file

@ -0,0 +1,25 @@
* Philips PCF8563/Epson RTC8564 Real Time Clock
Philips PCF8563/Epson RTC8564 Real Time Clock
Required properties:
see: Documentation/devicetree/bindings/i2c/trivial-devices.txt
Optional property:
- #clock-cells: Should be 0.
- clock-output-names:
overwrite the default clock name "pcf8563-clkout"
Example:
pcf8563: pcf8563@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
#clock-cells = <0>;
};
device {
...
clocks = <&pcf8563>;
...
};

10
Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
View file

@ -17,9 +17,9 @@ Required properties:
- reg: Address range of the SCPSYS unit
- infracfg: must contain a phandle to the infracfg controller
- clock, clock-names: clocks according to the common clock binding.
The clocks needed "mm" and "mfg". These are the
clocks which hardware needs to be enabled before
enabling certain power domains.
The clocks needed "mm", "mfg", "venc" and "venc_lt".
These are the clocks which hardware needs to be enabled
before enabling certain power domains.
Example:
@ -30,7 +30,9 @@ Example:
infracfg = <&infracfg>;
clocks = <&clk26m>,
<&topckgen CLK_TOP_MM_SEL>;
clock-names = "mfg", "mm";
<&topckgen CLK_TOP_VENC_SEL>,
<&topckgen CLK_TOP_VENC_LT_SEL>;
clock-names = "mfg", "mm", "venc", "venc_lt";
};
Example consumer:

57
Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt Normal file
View file

@ -0,0 +1,57 @@
Qualcomm Shared Memory Manager binding
This binding describes the Qualcomm Shared Memory Manager, used to share data
between various subsystems and OSes in Qualcomm platforms.
- compatible:
Usage: required
Value type: <stringlist>
Definition: must be:
"qcom,smem"
- memory-region:
Usage: required
Value type: <prop-encoded-array>
Definition: handle to memory reservation for main SMEM memory region.
- qcom,rpm-msg-ram:
Usage: required
Value type: <prop-encoded-array>
Definition: handle to RPM message memory resource
- hwlocks:
Usage: required
Value type: <prop-encoded-array>
Definition: reference to a hwspinlock used to protect allocations from
the shared memory
= EXAMPLE
The following example shows the SMEM setup for MSM8974, with a main SMEM region
at 0xfa00000 and the RPM message ram at 0xfc428000:
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
smem_region: smem@fa00000 {
reg = <0xfa00000 0x200000>;
no-map;
};
};
smem@fa00000 {
compatible = "qcom,smem";
memory-region = <&smem_region>;
qcom,rpm-msg-ram = <&rpm_msg_ram>;
hwlocks = <&tcsr_mutex 3>;
};
soc {
rpm_msg_ram: memory@fc428000 {
compatible = "qcom,rpm-msg-ram";
reg = <0xfc428000 0x4000>;
};
};

46
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt Normal file
View file

@ -0,0 +1,46 @@
* Rockchip Power Domains
Rockchip processors include support for multiple power domains which can be
powered up/down by software based on different application scenes to save power.
Required properties for power domain controller:
- compatible: Should be one of the following.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
- #power-domain-cells: Number of cells in a power-domain specifier.
Should be 1 for multiple PM domains.
- #address-cells: Should be 1.
- #size-cells: Should be 0.
Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
- clocks (optional): phandles to clocks which need to be enabled while power domain
switches state.
Example:
power: power-controller {
compatible = "rockchip,rk3288-power-controller";
#power-domain-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
pd_gpu {
reg = <RK3288_PD_GPU>;
clocks = <&cru ACLK_GPU>;
};
};
Node of a device using power domains must have a power-domains property,
containing a phandle to the power device node and an index specifying which
power domain to use.
The index should use macros in:
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
Example of the node using power domain:
node {
/* ... */
power-domains = <&power RK3288_PD_GPU>;
/* ... */
};

1
Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
View file

@ -221,7 +221,6 @@ qmss: qmss@2a40000 {
#size-cells = <1>;
ranges;
pdsp0@0x2a10000 {
firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
reg = <0x2a10000 0x1000>,
<0x2a0f000 0x100>,
<0x2a0c000 0x3c8>,

0
Documentation/devicetree/bindings/sound/ak4554.c → Documentation/devicetree/bindings/sound/ak4554.txt
View file

15
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
View file

@ -1,7 +1,9 @@
* Temperature Sensor ADC (TSADC) on rockchip SoCs
Required properties:
- compatible : "rockchip,rk3288-tsadc"
- compatible : should be "rockchip,<name>-tsadc"
"rockchip,rk3288-tsadc": found on RK3288 SoCs
"rockchip,rk3368-tsadc": found on RK3368 SoCs
- reg : physical base address of the controller and length of memory mapped
region.
- interrupts : The interrupt number to the cpu. The interrupt specifier format
@ -12,6 +14,11 @@ Required properties:
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the name "tsadc-apb".
- pinctrl-names : The pin control state names;
- pinctrl-0 : The "init" pinctrl state, it will be set before device probe.
- pinctrl-1 : The "default" pinctrl state, it will be set after reset the
TSADC controller.
- pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend.
- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
- rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
- rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
@ -27,8 +34,10 @@ tsadc: tsadc@ff280000 {
clock-names = "tsadc", "apb_pclk";
resets = <&cru SRST_TSADC>;
reset-names = "tsadc-apb";
pinctrl-names = "default";
pinctrl-0 = <&otp_out>;
pinctrl-names = "init", "default", "sleep";
pinctrl-0 = <&otp_gpio>;
pinctrl-1 = <&otp_out>;
pinctrl-2 = <&otp_gpio>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
rockchip,hw-tshut-mode = <0>;

14
Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
View file

@ -10,6 +10,8 @@ to the silicon temperature.
Required properties:
- compatible : Should be:
- "ti,omap34xx-bandgap" : for OMAP34xx bandgap
- "ti,omap36xx-bandgap" : for OMAP36xx bandgap
- "ti,omap4430-bandgap" : for OMAP4430 bandgap
- "ti,omap4460-bandgap" : for OMAP4460 bandgap
- "ti,omap4470-bandgap" : for OMAP4470 bandgap
@ -25,6 +27,18 @@ to each bandgap version, because the mapping may change from
soc to soc, apart of depending on available features.
Example:
OMAP34xx:
bandgap {
reg = <0x48002524 0x4>;
compatible = "ti,omap34xx-bandgap";
};
OMAP36xx:
bandgap {
reg = <0x48002524 0x4>;
compatible = "ti,omap36xx-bandgap";
};
OMAP4430:
bandgap {
reg = <0x4a002260 0x4 0x4a00232C 0x4>;

8
Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
View file

@ -3,10 +3,12 @@ Mediatek MT6577, MT6572 and MT6589 Timers
Required properties:
- compatible should contain:
* "mediatek,mt6589-timer" for MT6589 compatible timers
* "mediatek,mt6580-timer" for MT6580 compatible timers
* "mediatek,mt6577-timer" for all compatible timers (MT6589, MT6580,
MT6577)
* "mediatek,mt6589-timer" for MT6589 compatible timers
* "mediatek,mt8127-timer" for MT8127 compatible timers
* "mediatek,mt8135-timer" for MT8135 compatible timers
* "mediatek,mt8173-timer" for MT8173 compatible timers
* "mediatek,mt6577-timer" for MT6577 and all above compatible timers
- reg: Should contain location and length for timers register.
- clocks: Clocks driving the timer hardware. This list should include two
clocks. The order is system clock and as second clock the RTC clock.

58
Documentation/devicetree/bindings/ufs/ufs-qcom.txt Normal file
View file

@ -0,0 +1,58 @@
* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY
UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro.
Each UFS PHY node should have its own node.
To bind UFS PHY with UFS host controller, the controller node should
contain a phandle reference to UFS PHY node.
Required properties:
- compatible : compatible list, contains "qcom,ufs-phy-qmp-20nm"
or "qcom,ufs-phy-qmp-14nm" according to the relevant phy in use.
- reg : should contain PHY register address space (mandatory),
- reg-names : indicates various resources passed to driver (via reg proptery) by name.
Required "reg-names" is "phy_mem".
- #phy-cells : This property shall be set to 0
- vdda-phy-supply : phandle to main PHY supply for analog domain
- vdda-pll-supply : phandle to PHY PLL and Power-Gen block power supply
- clocks : List of phandle and clock specifier pairs
- clock-names : List of clock input name strings sorted in the same
order as the clocks property. "ref_clk_src", "ref_clk",
"tx_iface_clk" & "rx_iface_clk" are mandatory but
"ref_clk_parent" is optional
Optional properties:
- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply
- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply
- vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply
- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply
- vddp-ref-clk-always-on : specifies if this supply needs to be kept always on
Example:
ufsphy1: ufsphy@0xfc597000 {
compatible = "qcom,ufs-phy-qmp-20nm";
reg = <0xfc597000 0x800>;
reg-names = "phy_mem";
#phy-cells = <0>;
vdda-phy-supply = <&pma8084_l4>;
vdda-pll-supply = <&pma8084_l12>;
vdda-phy-max-microamp = <50000>;
vdda-pll-max-microamp = <1000>;
clock-names = "ref_clk_src",
"ref_clk_parent",
"ref_clk",
"tx_iface_clk",
"rx_iface_clk";
clocks = <&clock_rpm clk_ln_bb_clk>,
<&clock_gcc clk_pcie_1_phy_ldo >,
<&clock_gcc clk_ufs_phy_ldo>,
<&clock_gcc clk_gcc_ufs_tx_cfg_clk>,
<&clock_gcc clk_gcc_ufs_rx_cfg_clk>;
};
ufshc@0xfc598000 {
...
phys = <&ufsphy1>;
phy-names = "ufsphy";
};

11
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
View file

@ -4,11 +4,18 @@ UFSHC nodes are defined to describe on-chip UFS host controllers.
Each UFS controller instance should have its own node.
Required properties:
- compatible : compatible list, contains "jedec,ufs-1.1"
- compatible : must contain "jedec,ufs-1.1", may also list one or more
of the following:
"qcom,msm8994-ufshc"
"qcom,msm8996-ufshc"
"qcom,ufshc"
- interrupts : <interrupt mapping for UFS host controller IRQ>
- reg : <registers mapping>
Optional properties:
- phys : phandle to UFS PHY node
- phy-names : the string "ufsphy" when is found in a node, along
with "phys" attribute, provides phandle to UFS PHY node
- vdd-hba-supply : phandle to UFS host controller supply regulator node
- vcc-supply : phandle to VCC supply regulator node
- vccq-supply : phandle to VCCQ supply regulator node
@ -54,4 +61,6 @@ Example:
clocks = <&core 0>, <&ref 0>, <&iface 0>;
clock-names = "core_clk", "ref_clk", "iface_clk";
freq-table-hz = <100000000 200000000>, <0 0>, <0 0>;
phys = <&ufsphy1>;
phy-names = "ufsphy";
};

3
Documentation/devicetree/bindings/usb/dwc3.txt
View file

@ -1,6 +1,7 @@
synopsys DWC3 CORE
DWC3- USB3 CONTROLLER
DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties
as described in 'usb/generic.txt'
Required properties:
- compatible: must be "snps,dwc3"

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

@ -34,6 +34,7 @@ avago Avago Technologies
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
bosch Bosch Sensortec GmbH
boundary Boundary Devices Inc.
brcm Broadcom Corporation
buffalo Buffalo, Inc.
calxeda Calxeda
@ -171,6 +172,7 @@ pericom Pericom Technology Inc.
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
plathome Plat'Home Co., Ltd.
plda PLDA
pixcir PIXCIR MICROELECTRONICS Co., Ltd
pulsedlight PulsedLight, Inc
powervr PowerVR (deprecated, use img)
@ -228,6 +230,7 @@ toradex Toradex AG
toshiba Toshiba Corporation
toumaz Toumaz
tplink TP-LINK Technologies Co., Ltd.
tronfy Tronfy
truly Truly Semiconductors Limited
upisemi uPI Semiconductor Corp.
usi Universal Scientific Industrial Co., Ltd.

19
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt Normal file
View file

@ -0,0 +1,19 @@
BCM7038 Watchdog timer
Required properties:
- compatible : should be "brcm,bcm7038-wdt"
- reg : Specifies base physical address and size of the registers.
Optional properties:
- clocks: The clock running the watchdog. If no clock is found the
driver will default to 27000000 Hz.
Example:
watchdog@f040a7e8 {
compatible = "brcm,bcm7038-wdt";
clocks = <&upg_fixed>;
reg = <0xf040a7e8 0x16>;
};

1
Documentation/dontdiff
View file

@ -165,7 +165,6 @@ mach-types.h
machtypes.h
map
map_hugetlb
media
mconf
miboot*
mk_elfconfig

36
Documentation/email-clients.txt
View file

@ -176,11 +176,47 @@ To use 'vim' with mutt:
if you want to include the patch inline.
(a)ttach works fine without "set paste".
You can also generate patches with 'git format-patch' and then use Mutt
to send them:
$ mutt -H 0001-some-bug-fix.patch
Config options:
It should work with default settings.
However, it's a good idea to set the "send_charset" to:
set send_charset="us-ascii:utf-8"
Mutt is highly customizable. Here is a minimum configuration to start
using Mutt to send patches through Gmail:
# .muttrc
# ================ IMAP ====================
set imap_user = 'yourusername@gmail.com'
set imap_pass = 'yourpassword'
set spoolfile = imaps://imap.gmail.com/INBOX
set folder = imaps://imap.gmail.com/
set record="imaps://imap.gmail.com/[Gmail]/Sent Mail"
set postponed="imaps://imap.gmail.com/[Gmail]/Drafts"
set mbox="imaps://imap.gmail.com/[Gmail]/All Mail"
# ================ SMTP ====================
set smtp_url = "smtp://username@smtp.gmail.com:587/"
set smtp_pass = $imap_pass
set ssl_force_tls = yes # Require encrypted connection
# ================ Composition ====================
set editor = `echo \$EDITOR`
set edit_headers = yes # See the headers when editing
set charset = UTF-8 # value of $LANG; also fallback for send_charset
# Sender, email address, and sign-off line must match
unset use_domain # because joe@localhost is just embarrassing
set realname = "YOUR NAME"
set from = "username@gmail.com"
set use_from = yes
The Mutt docs have lots more information:
http://dev.mutt.org/trac/wiki/UseCases/Gmail
http://dev.mutt.org/doc/manual.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pine (TUI)

2
Documentation/filesystems/Makefile
View file

@ -1,5 +1,3 @@
subdir-y := configfs
# List of programs to build
hostprogs-y := dnotify_test

3
Documentation/filesystems/configfs/Makefile
View file

@ -1,3 +0,0 @@
ifneq ($(CONFIG_CONFIGFS_FS),)
obj-m += configfs_example_explicit.o configfs_example_macros.o
endif

38
Documentation/filesystems/configfs/configfs.txt
View file

@ -160,12 +160,6 @@ among other things. For that, it needs a type.
struct configfs_item_operations {
void (*release)(struct config_item *);
ssize_t (*show_attribute)(struct config_item *,
struct configfs_attribute *,
char *);
ssize_t (*store_attribute)(struct config_item *,
struct configfs_attribute *,
const char *, size_t);
int (*allow_link)(struct config_item *src,
struct config_item *target);
int (*drop_link)(struct config_item *src,
@ -183,9 +177,7 @@ The most basic function of a config_item_type is to define what
operations can be performed on a config_item. All items that have been
allocated dynamically will need to provide the ct_item_ops->release()
method. This method is called when the config_item's reference count
reaches zero. Items that wish to display an attribute need to provide
the ct_item_ops->show_attribute() method. Similarly, storing a new
attribute value uses the store_attribute() method.
reaches zero.
[struct configfs_attribute]
@ -193,6 +185,8 @@ attribute value uses the store_attribute() method.
char *ca_name;
struct module *ca_owner;
umode_t ca_mode;
ssize_t (*show)(struct config_item *, char *);
ssize_t (*store)(struct config_item *, const char *, size_t);
};
When a config_item wants an attribute to appear as a file in the item's
@ -202,10 +196,10 @@ config_item_type->ct_attrs. When the item appears in configfs, the
attribute file will appear with the configfs_attribute->ca_name
filename. configfs_attribute->ca_mode specifies the file permissions.
If an attribute is readable and the config_item provides a
ct_item_ops->show_attribute() method, that method will be called
whenever userspace asks for a read(2) on the attribute. The converse
will happen for write(2).
If an attribute is readable and provides a ->show method, that method will
be called whenever userspace asks for a read(2) on the attribute. If an
attribute is writable and provides a ->store method, that method will be
be called whenever userspace asks for a write(2) on the attribute.
[struct config_group]
@ -311,20 +305,10 @@ the subsystem must be ready for it.
[An Example]
The best example of these basic concepts is the simple_children
subsystem/group and the simple_child item in configfs_example_explicit.c
and configfs_example_macros.c. It shows a trivial object displaying and
storing an attribute, and a simple group creating and destroying these
children.
The only difference between configfs_example_explicit.c and
configfs_example_macros.c is how the attributes of the childless item
are defined. The childless item has extended attributes, each with
their own show()/store() operation. This follows a convention commonly
used in sysfs. configfs_example_explicit.c creates these attributes
by explicitly defining the structures involved. Conversely
configfs_example_macros.c uses some convenience macros from configfs.h
to define the attributes. These macros are similar to their sysfs
counterparts.
subsystem/group and the simple_child item in
samples/configfs/configfs_sample.c. It shows a trivial object displaying
and storing an attribute, and a simple group creating and destroying
these children.
[Hierarchy Navigation and the Subsystem Mutex]

483
Documentation/filesystems/configfs/configfs_example_explicit.c
View file

@ -1,483 +0,0 @@
/*
* vim: noexpandtab ts=8 sts=0 sw=8:
*
* configfs_example_explicit.c - This file is a demonstration module
* containing a number of configfs subsystems. It explicitly defines
* each structure without using the helper macros defined in
* configfs.h.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public
* License along with this program; if not, write to the
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
* Boston, MA 021110-1307, USA.
*
* Based on sysfs:
* sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
*
* configfs Copyright (C) 2005 Oracle. All rights reserved.
*/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/configfs.h>
/*
* 01-childless
*
* This first example is a childless subsystem. It cannot create
* any config_items. It just has attributes.
*
* Note that we are enclosing the configfs_subsystem inside a container.
* This is not necessary if a subsystem has no attributes directly
* on the subsystem. See the next example, 02-simple-children, for
* such a subsystem.
*/
struct childless {
struct configfs_subsystem subsys;
int showme;
int storeme;
};
struct childless_attribute {
struct configfs_attribute attr;
ssize_t (*show)(struct childless *, char *);
ssize_t (*store)(struct childless *, const char *, size_t);
};
static inline struct childless *to_childless(struct config_item *item)
{
return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL;
}
static ssize_t childless_showme_read(struct childless *childless,
char *page)
{
ssize_t pos;
pos = sprintf(page, "%d\n", childless->showme);
childless->showme++;
return pos;
}
static ssize_t childless_storeme_read(struct childless *childless,
char *page)
{
return sprintf(page, "%d\n", childless->storeme);
}
static ssize_t childless_storeme_write(struct childless *childless,
const char *page,
size_t count)
{
unsigned long tmp;
char *p = (char *) page;
tmp = simple_strtoul(p, &p, 10);
if ((*p != '\0') && (*p != '\n'))
return -EINVAL;
if (tmp > INT_MAX)
return -ERANGE;
childless->storeme = tmp;
return count;
}
static ssize_t childless_description_read(struct childless *childless,
char *page)
{
return sprintf(page,
"[01-childless]\n"
"\n"
"The childless subsystem is the simplest possible subsystem in\n"
"configfs. It does not support the creation of child config_items.\n"
"It only has a few attributes. In fact, it isn't much different\n"
"than a directory in /proc.\n");
}
static struct childless_attribute childless_attr_showme = {
.attr = { .ca_owner = THIS_MODULE, .ca_name = "showme", .ca_mode = S_IRUGO },
.show = childless_showme_read,
};
static struct childless_attribute childless_attr_storeme = {
.attr = { .ca_owner = THIS_MODULE, .ca_name = "storeme", .ca_mode = S_IRUGO | S_IWUSR },
.show = childless_storeme_read,
.store = childless_storeme_write,
};
static struct childless_attribute childless_attr_description = {
.attr = { .ca_owner = THIS_MODULE, .ca_name = "description", .ca_mode = S_IRUGO },
.show = childless_description_read,
};
static struct configfs_attribute *childless_attrs[] = {
&childless_attr_showme.attr,
&childless_attr_storeme.attr,
&childless_attr_description.attr,
NULL,
};
static ssize_t childless_attr_show(struct config_item *item,
struct configfs_attribute *attr,
char *page)
{
struct childless *childless = to_childless(item);
struct childless_attribute *childless_attr =
container_of(attr, struct childless_attribute, attr);
ssize_t ret = 0;
if (childless_attr->show)
ret = childless_attr->show(childless, page);
return ret;
}
static ssize_t childless_attr_store(struct config_item *item,
struct configfs_attribute *attr,
const char *page, size_t count)
{
struct childless *childless = to_childless(item);
struct childless_attribute *childless_attr =
container_of(attr, struct childless_attribute, attr);
ssize_t ret = -EINVAL;
if (childless_attr->store)
ret = childless_attr->store(childless, page, count);
return ret;
}
static struct configfs_item_operations childless_item_ops = {
.show_attribute = childless_attr_show,
.store_attribute = childless_attr_store,
};
static struct config_item_type childless_type = {
.ct_item_ops = &childless_item_ops,
.ct_attrs = childless_attrs,
.ct_owner = THIS_MODULE,
};
static struct childless childless_subsys = {
.subsys = {
.su_group = {
.cg_item = {
.ci_namebuf = "01-childless",
.ci_type = &childless_type,
},
},
},
};
/* ----------------------------------------------------------------- */
/*
* 02-simple-children
*
* This example merely has a simple one-attribute child. Note that
* there is no extra attribute structure, as the child's attribute is
* known from the get-go. Also, there is no container for the
* subsystem, as it has no attributes of its own.
*/
struct simple_child {
struct config_item item;
int storeme;
};
static inline struct simple_child *to_simple_child(struct config_item *item)
{
return item ? container_of(item, struct simple_child, item) : NULL;
}
static struct configfs_attribute simple_child_attr_storeme = {
.ca_owner = THIS_MODULE,
.ca_name = "storeme",
.ca_mode = S_IRUGO | S_IWUSR,
};
static struct configfs_attribute *simple_child_attrs[] = {
&simple_child_attr_storeme,
NULL,
};
static ssize_t simple_child_attr_show(struct config_item *item,
struct configfs_attribute *attr,
char *page)
{
ssize_t count;
struct simple_child *simple_child = to_simple_child(item);
count = sprintf(page, "%d\n", simple_child->storeme);
return count;
}
static ssize_t simple_child_attr_store(struct config_item *item,
struct configfs_attribute *attr,
const char *page, size_t count)
{
struct simple_child *simple_child = to_simple_child(item);
unsigned long tmp;
char *p = (char *) page;
tmp = simple_strtoul(p, &p, 10);
if (!p || (*p && (*p != '\n')))
return -EINVAL;
if (tmp > INT_MAX)
return -ERANGE;
simple_child->storeme = tmp;
return count;
}
static void simple_child_release(struct config_item *item)
{
kfree(to_simple_child(item));
}
static struct configfs_item_operations simple_child_item_ops = {
.release = simple_child_release,
.show_attribute = simple_child_attr_show,
.store_attribute = simple_child_attr_store,
};
static struct config_item_type simple_child_type = {
.ct_item_ops = &simple_child_item_ops,
.ct_attrs = simple_child_attrs,
.ct_owner = THIS_MODULE,
};
struct simple_children {
struct config_group group;
};
static inline struct simple_children *to_simple_children(struct config_item *item)
{
return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;
}
static struct config_item *simple_children_make_item(struct config_group *group, const char *name)
{
struct simple_child *simple_child;
simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);
if (!simple_child)
return ERR_PTR(-ENOMEM);
config_item_init_type_name(&simple_child->item, name,
&simple_child_type);
simple_child->storeme = 0;
return &simple_child->item;
}
static struct configfs_attribute simple_children_attr_description = {
.ca_owner = THIS_MODULE,
.ca_name = "description",
.ca_mode = S_IRUGO,
};
static struct configfs_attribute *simple_children_attrs[] = {
&simple_children_attr_description,
NULL,
};
static ssize_t simple_children_attr_show(struct config_item *item,
struct configfs_attribute *attr,
char *page)
{
return sprintf(page,
"[02-simple-children]\n"
"\n"
"This subsystem allows the creation of child config_items. These\n"
"items have only one attribute that is readable and writeable.\n");
}
static void simple_children_release(struct config_item *item)
{
kfree(to_simple_children(item));
}
static struct configfs_item_operations simple_children_item_ops = {
.release = simple_children_release,
.show_attribute = simple_children_attr_show,
};
/*
* Note that, since no extra work is required on ->drop_item(),
* no ->drop_item() is provided.
*/
static struct configfs_group_operations simple_children_group_ops = {
.make_item = simple_children_make_item,
};
static struct config_item_type simple_children_type = {
.ct_item_ops = &simple_children_item_ops,
.ct_group_ops = &simple_children_group_ops,
.ct_attrs = simple_children_attrs,
.ct_owner = THIS_MODULE,
};
static struct configfs_subsystem simple_children_subsys = {
.su_group = {
.cg_item = {
.ci_namebuf = "02-simple-children",
.ci_type = &simple_children_type,
},
},
};
/* ----------------------------------------------------------------- */
/*
* 03-group-children
*
* This example reuses the simple_children group from above. However,
* the simple_children group is not the subsystem itself, it is a
* child of the subsystem. Creation of a group in the subsystem creates
* a new simple_children group. That group can then have simple_child
* children of its own.
*/
static struct config_group *group_children_make_group(struct config_group *group, const char *name)
{
struct simple_children *simple_children;
simple_children = kzalloc(sizeof(struct simple_children),
GFP_KERNEL);
if (!simple_children)
return ERR_PTR(-ENOMEM);
config_group_init_type_name(&simple_children->group, name,
&simple_children_type);
return &simple_children->group;
}
static struct configfs_attribute group_children_attr_description = {
.ca_owner = THIS_MODULE,
.ca_name = "description",
.ca_mode = S_IRUGO,
};
static struct configfs_attribute *group_children_attrs[] = {
&group_children_attr_description,
NULL,
};
static ssize_t group_children_attr_show(struct config_item *item,
struct configfs_attribute *attr,
char *page)
{
return sprintf(page,
"[03-group-children]\n"
"\n"
"This subsystem allows the creation of child config_groups. These\n"
"groups are like the subsystem simple-children.\n");
}
static struct configfs_item_operations group_children_item_ops = {
.show_attribute = group_children_attr_show,
};
/*
* Note that, since no extra work is required on ->drop_item(),
* no ->drop_item() is provided.
*/
static struct configfs_group_operations group_children_group_ops = {
.make_group = group_children_make_group,
};
static struct config_item_type group_children_type = {
.ct_item_ops = &group_children_item_ops,
.ct_group_ops = &group_children_group_ops,
.ct_attrs = group_children_attrs,
.ct_owner = THIS_MODULE,
};
static struct configfs_subsystem group_children_subsys = {
.su_group = {
.cg_item = {
.ci_namebuf = "03-group-children",
.ci_type = &group_children_type,
},
},
};
/* ----------------------------------------------------------------- */
/*
* We're now done with our subsystem definitions.
* For convenience in this module, here's a list of them all. It
* allows the init function to easily register them. Most modules
* will only have one subsystem, and will only call register_subsystem
* on it directly.
*/
static struct configfs_subsystem *example_subsys[] = {
&childless_subsys.subsys,
&simple_children_subsys,
&group_children_subsys,
NULL,
};
static int __init configfs_example_init(void)
{
int ret;
int i;
struct configfs_subsystem *subsys;
for (i = 0; example_subsys[i]; i++) {
subsys = example_subsys[i];
config_group_init(&subsys->su_group);
mutex_init(&subsys->su_mutex);
ret = configfs_register_subsystem(subsys);
if (ret) {
printk(KERN_ERR "Error %d while registering subsystem %s\n",
ret,
subsys->su_group.cg_item.ci_namebuf);
goto out_unregister;
}
}
return 0;
out_unregister:
for (i--; i >= 0; i--)
configfs_unregister_subsystem(example_subsys[i]);
return ret;
}
static void __exit configfs_example_exit(void)
{
int i;
for (i = 0; example_subsys[i]; i++)
configfs_unregister_subsystem(example_subsys[i]);
}
module_init(configfs_example_init);
module_exit(configfs_example_exit);
MODULE_LICENSE("GPL");

6
Documentation/filesystems/gfs2-glocks.txt
View file

@ -5,7 +5,7 @@ This documents the basic principles of the glock state machine
internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h)
has two main (internal) locks:
1. A spinlock (gl_spin) which protects the internal state such
1. A spinlock (gl_lockref.lock) which protects the internal state such
as gl_state, gl_target and the list of holders (gl_holders)
2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other
threads from making calls to the DLM, etc. at the same time. If a
@ -82,8 +82,8 @@ rather than via the glock.
Locking rules for glock operations:
Operation | GLF_LOCK bit lock held | gl_spin spinlock held
-----------------------------------------------------------------
Operation | GLF_LOCK bit lock held | gl_lockref.lock spinlock held
-------------------------------------------------------------------------
go_xmote_th | Yes | No
go_xmote_bh | Yes | No
go_inval | Yes | No

3
Documentation/filesystems/overlayfs.txt
View file

@ -1,4 +1,5 @@
Written by: Neil Brown <neilb@suse.de>
Written by: Neil Brown
Please see MAINTAINERS file for where to send questions.
Overlay Filesystem
==================

22
Documentation/filesystems/proc.txt
View file

@ -1605,16 +1605,16 @@ Documentation/accounting.
---------------------------------------------------------------
When a process is dumped, all anonymous memory is written to a core file as
long as the size of the core file isn't limited. But sometimes we don't want
to dump some memory segments, for example, huge shared memory. Conversely,
sometimes we want to save file-backed memory segments into a core file, not
only the individual files.
to dump some memory segments, for example, huge shared memory or DAX.
Conversely, sometimes we want to save file-backed memory segments into a core
file, not only the individual files.
/proc/<pid>/coredump_filter allows you to customize which memory segments
will be dumped when the <pid> process is dumped. coredump_filter is a bitmask
of memory types. If a bit of the bitmask is set, memory segments of the
corresponding memory type are dumped, otherwise they are not dumped.
The following 7 memory types are supported:
The following 9 memory types are supported:
- (bit 0) anonymous private memory
- (bit 1) anonymous shared memory
- (bit 2) file-backed private memory
@ -1623,20 +1623,22 @@ The following 7 memory types are supported:
effective only if the bit 2 is cleared)
- (bit 5) hugetlb private memory
- (bit 6) hugetlb shared memory
- (bit 7) DAX private memory
- (bit 8) DAX shared memory
Note that MMIO pages such as frame buffer are never dumped and vDSO pages
are always dumped regardless of the bitmask status.
Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only
effected by bit 5-6.
Note that bits 0-4 don't affect hugetlb or DAX memory. hugetlb memory is
only affected by bit 5-6, and DAX is only affected by bits 7-8.
Default value of coredump_filter is 0x23; this means all anonymous memory
segments and hugetlb private memory are dumped.
The default value of coredump_filter is 0x33; this means all anonymous memory
segments, ELF header pages and hugetlb private memory are dumped.
If you don't want to dump all shared memory segments attached to pid 1234,
write 0x21 to the process's proc file.
write 0x31 to the process's proc file.
$ echo 0x21 > /proc/1234/coredump_filter
$ echo 0x31 > /proc/1234/coredump_filter
When a new process is created, the process inherits the bitmask status from its
parent. It is useful to set up coredump_filter before the program runs.

33
Documentation/hwmon/scpi-hwmon Normal file
View file

@ -0,0 +1,33 @@
Kernel driver scpi-hwmon
========================
Supported chips:
* Chips based on ARM System Control Processor Interface
Addresses scanned: -
Datasheet: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/index.html
Author: Punit Agrawal <punit.agrawal@arm.com>
Description
-----------
This driver supports hardware monitoring for SoC's based on the ARM
System Control Processor (SCP) implementing the System Control
Processor Interface (SCPI). The following sensor types are supported
by the SCP -
* temperature
* voltage
* current
* power
The SCP interface provides an API to query the available sensors and
their values which are then exported to userspace by this driver.
Usage Notes
-----------
The driver relies on device tree node to indicate the presence of SCPI
support in the kernel. See
Documentation/devicetree/bindings/arm/arm,scpi.txt for details of the
devicetree node.

3
Documentation/i2c/busses/i2c-i801
View file

@ -30,6 +30,9 @@ Supported adapters:
* Intel BayTrail (SOC)
* Intel Sunrise Point-H (PCH)
* Intel Sunrise Point-LP (PCH)
* Intel DNV (SOC)
* Intel Broxton (SOC)
* Intel Lewisburg (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller

57
Documentation/kbuild/Kconfig.recursion-issue-01 Normal file
View file

@ -0,0 +1,57 @@
# Simple Kconfig recursive issue
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Test with:
#
# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig
#
# This Kconfig file has a simple recursive dependency issue. In order to
# understand why this recursive dependency issue occurs lets consider what
# Kconfig needs to address. We iterate over what Kconfig needs to address
# by stepping through the questions it needs to address sequentially.
#
# * What values are possible for CORE?
#
# CORE_BELL_A_ADVANCED selects CORE, which means that it influences the values
# that are possible for CORE. So for example if CORE_BELL_A_ADVANCED is 'y',
# CORE must be 'y' too.
#
# * What influences CORE_BELL_A_ADVANCED ?
#
# As the name implies CORE_BELL_A_ADVANCED is an advanced feature of
# CORE_BELL_A so naturally it depends on CORE_BELL_A. So if CORE_BELL_A is 'y'
# we know CORE_BELL_A_ADVANCED can be 'y' too.
#
# * What influences CORE_BELL_A ?
#
# CORE_BELL_A depends on CORE, so CORE influences CORE_BELL_A.
#
# But that is a problem, because this means that in order to determine
# what values are possible for CORE we ended up needing to address questions
# regarding possible values of CORE itself again. Answering the original
# question of what are the possible values of CORE would make the kconfig
# tools run in a loop. When this happens Kconfig exits and complains about
# the "recursive dependency detected" error.
#
# Reading the Documentation/kbuild/Kconfig.recursion-issue-01 file it may be
# obvious that an easy to solution to this problem should just be the removal
# of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already
# since CORE_BELL_A depends on CORE. Recursive dependency issues are not always
# so trivial to resolve, we provide another example below of practical
# implications of this recursive issue where the solution is perhaps not so
# easy to understand. Note that matching semantics on the dependency on
# CORE also consist of a solution to this recursive problem.
mainmenu "Simple example to demo kconfig recursive dependency issue"
config CORE
tristate
config CORE_BELL_A
tristate
depends on CORE
config CORE_BELL_A_ADVANCED
tristate
depends on CORE_BELL_A
select CORE

63
Documentation/kbuild/Kconfig.recursion-issue-02 Normal file
View file

@ -0,0 +1,63 @@
# Cumulative Kconfig recursive issue
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Test with:
#
# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig
#
# The recursive limitations with Kconfig has some non intuitive implications on
# kconfig sematics which are documented here. One known practical implication
# of the recursive limitation is that drivers cannot negate features from other
# drivers if they share a common core requirement and use disjoint semantics to
# annotate those requirements, ie, some drivers use "depends on" while others
# use "select". For instance it means if a driver A and driver B share the same
# core requirement, and one uses "select" while the other uses "depends on" to
# annotate this, all features that driver A selects cannot now be negated by
# driver B.
#
# A perhaps not so obvious implication of this is that, if semantics on these
# core requirements are not carefully synced, as drivers evolve features
# they select or depend on end up becoming shared requirements which cannot be
# negated by other drivers.
#
# The example provided in Documentation/kbuild/Kconfig.recursion-issue-02
# describes a simple driver core layout of example features a kernel might
# have. Let's assume we have some CORE functionality, then the kernel has a
# series of bells and whistles it desires to implement, its not so advanced so
# it only supports bells at this time: CORE_BELL_A and CORE_BELL_B. If
# CORE_BELL_A has some advanced feature CORE_BELL_A_ADVANCED which selects
# CORE_BELL_A then CORE_BELL_A ends up becoming a common BELL feature which
# other bells in the system cannot negate. The reason for this issue is
# due to the disjoint use of semantics on expressing each bell's relationship
# with CORE, one uses "depends on" while the other uses "select". Another
# more important reason is that kconfig does not check for dependencies listed
# under 'select' for a symbol, when such symbols are selected kconfig them
# as mandatory required symbols. For more details on the heavy handed nature
# of select refer to Documentation/kbuild/Kconfig.select-break
#
# To fix this the "depends on CORE" must be changed to "select CORE", or the
# "select CORE" must be changed to "depends on CORE".
#
# For an example real world scenario issue refer to the attempt to remove
# "select FW_LOADER" [0], in the end the simple alternative solution to this
# problem consisted on matching semantics with newly introduced features.
#
# [0] http://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com
mainmenu "Simple example to demo cumulative kconfig recursive dependency implication"
config CORE
tristate
config CORE_BELL_A
tristate
depends on CORE
config CORE_BELL_A_ADVANCED
tristate
select CORE_BELL_A
config CORE_BELL_B
tristate
depends on !CORE_BELL_A
select CORE

33
Documentation/kbuild/Kconfig.select-break Normal file
View file

@ -0,0 +1,33 @@
# Select broken dependency issue
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Test with:
#
# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.select-break menuconfig
#
# kconfig will not complain and enable this layout for configuration. This is
# currently a feature of kconfig, given select was designed to be heavy handed.
# Kconfig currently does not check the list of symbols listed on a symbol's
# "select" list, this is done on purpose to help load a set of known required
# symbols. Because of this use of select should be used with caution. An
# example of this issue is below.
#
# The option B and C are clearly contradicting with respect to A.
# However, when A is set, C can be set as well because Kconfig does not
# visit the dependencies of the select target (in this case B). And since
# Kconfig does not visit the dependencies, it breaks the dependencies of B
# (!A).
mainmenu "Simple example to demo kconfig select broken dependency issue"
config A
bool "CONFIG A"
config B
bool "CONFIG B"
depends on !A
config C
bool "CONFIG C"
depends on A
select B

161
Documentation/kbuild/kconfig-language.txt
View file

@ -393,3 +393,164 @@ config FOO
depends on BAR && m
limits FOO to module (=m) or disabled (=n).
Kconfig recursive dependency limitations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you've hit the Kconfig error: "recursive dependency detected" you've run
into a recursive dependency issue with Kconfig, a recursive dependency can be
summarized as a circular dependency. The kconfig tools need to ensure that
Kconfig files comply with specified configuration requirements. In order to do
that kconfig must determine the values that are possible for all Kconfig
symbols, this is currently not possible if there is a circular relation
between two or more Kconfig symbols. For more details refer to the "Simple
Kconfig recursive issue" subsection below. Kconfig does not do recursive
dependency resolution; this has a few implications for Kconfig file writers.
We'll first explain why this issues exists and then provide an example
technical limitation which this brings upon Kconfig developers. Eager
developers wishing to try to address this limitation should read the next
subsections.
Simple Kconfig recursive issue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Read: Documentation/kbuild/Kconfig.recursion-issue-01
Test with:
make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig
Cumulative Kconfig recursive issue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Read: Documentation/kbuild/Kconfig.recursion-issue-02
Test with:
make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig
Practical solutions to kconfig recursive issue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Developers who run into the recursive Kconfig issue have three options
at their disposal. We document them below and also provide a list of
historical issues resolved through these different solutions.
a) Remove any superfluous "select FOO" or "depends on FOO"
b) Match dependency semantics:
b1) Swap all "select FOO" to "depends on FOO" or,
b2) Swap all "depends on FOO" to "select FOO"
The resolution to a) can be tested with the sample Kconfig file
Documentation/kbuild/Kconfig.recursion-issue-01 through the removal
of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already
since CORE_BELL_A depends on CORE. At times it may not be possible to remove
some dependency criteria, for such cases you can work with solution b).
The two different resolutions for b) can be tested in the sample Kconfig file
Documentation/kbuild/Kconfig.recursion-issue-02.
Below is a list of examples of prior fixes for these types of recursive issues;
all errors appear to involve one or more select's and one or more "depends on".
commit fix
====== ===
06b718c01208 select A -> depends on A
c22eacfe82f9 depends on A -> depends on B
6a91e854442c select A -> depends on A
118c565a8f2e select A -> select B
f004e5594705 select A -> depends on A
c7861f37b4c6 depends on A -> (null)
80c69915e5fb select A -> (null) (1)
c2218e26c0d0 select A -> depends on A (1)
d6ae99d04e1c select A -> depends on A
95ca19cf8cbf select A -> depends on A
8f057d7bca54 depends on A -> (null)
8f057d7bca54 depends on A -> select A
a0701f04846e select A -> depends on A
0c8b92f7f259 depends on A -> (null)
e4e9e0540928 select A -> depends on A (2)
7453ea886e87 depends on A > (null) (1)
7b1fff7e4fdf select A -> depends on A
86c747d2a4f0 select A -> depends on A
d9f9ab51e55e select A -> depends on A
0c51a4d8abd6 depends on A -> select A (3)
e98062ed6dc4 select A -> depends on A (3)
91e5d284a7f1 select A -> (null)
(1) Partial (or no) quote of error.
(2) That seems to be the gist of that fix.
(3) Same error.
Future kconfig work
~~~~~~~~~~~~~~~~~~~
Work on kconfig is welcomed on both areas of clarifying semantics and on
evaluating the use of a full SAT solver for it. A full SAT solver can be
desirable to enable more complex dependency mappings and / or queries,
for instance on possible use case for a SAT solver could be that of handling
the current known recursive dependency issues. It is not known if this would
address such issues but such evaluation is desirable. If support for a full SAT
solver proves too complex or that it cannot address recursive dependency issues
Kconfig should have at least clear and well defined semantics which also
addresses and documents limitations or requirements such as the ones dealing
with recursive dependencies.
Further work on both of these areas is welcomed on Kconfig. We elaborate
on both of these in the next two subsections.
Semantics of Kconfig
~~~~~~~~~~~~~~~~~~~~
The use of Kconfig is broad, Linux is now only one of Kconfig's users:
one study has completed a broad analysis of Kconfig use in 12 projects [0].
Despite its widespread use, and although this document does a reasonable job
in documenting basic Kconfig syntax a more precise definition of Kconfig
semantics is welcomed. One project deduced Kconfig semantics through
the use of the xconfig configurator [1]. Work should be done to confirm if
the deduced semantics matches our intended Kconfig design goals.
Having well defined semantics can be useful for tools for practical
evaluation of depenencies, for instance one such use known case was work to
express in boolean abstraction of the inferred semantics of Kconfig to
translate Kconfig logic into boolean formulas and run a SAT solver on this to
find dead code / features (always inactive), 114 dead features were found in
Linux using this methodology [1] (Section 8: Threats to validity).
Confirming this could prove useful as Kconfig stands as one of the the leading
industrial variability modeling languages [1] [2]. Its study would help
evaluate practical uses of such languages, their use was only theoretical
and real world requirements were not well understood. As it stands though
only reverse engineering techniques have been used to deduce semantics from
variability modeling languages such as Kconfig [3].
[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
[3] http://gsd.uwaterloo.ca/sites/default/files/icse2011.pdf
Full SAT solver for Kconfig
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Although SAT solvers [0] haven't yet been used by Kconfig directly, as noted in
the previous subsection, work has been done however to express in boolean
abstraction the inferred semantics of Kconfig to translate Kconfig logic into
boolean formulas and run a SAT solver on it [1]. Another known related project
is CADOS [2] (former VAMOS [3]) and the tools, mainly undertaker [4], which has
been introduced first with [5]. The basic concept of undertaker is to exract
variability models from Kconfig, and put them together with a propositional
formula extracted from CPP #ifdefs and build-rules into a SAT solver in order
to find dead code, dead files, and dead symbols. If using a SAT solver is
desirable on Kconfig one approach would be to evaluate repurposing such efforts
somehow on Kconfig. There is enough interest from mentors of existing projects
to not only help advise how to integrate this work upstream but also help
maintain it long term. Interested developers should visit:
http://kernelnewbies.org/KernelProjects/kconfig-sat
[0] http://www.cs.cornell.edu/~sabhar/chapters/SATSolvers-KR-Handbook.pdf
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
[2] https://cados.cs.fau.de
[3] https://vamos.cs.fau.de
[4] https://undertaker.cs.fau.de
[5] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf

18
Documentation/kernel-parameters.txt
View file

@ -932,11 +932,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The filter can be disabled or changed to another
driver later using sysfs.
drm_kms_helper.edid_firmware=[<connector>:]<file>
Broken monitors, graphic adapters and KVMs may
send no or incorrect EDID data sets. This parameter
allows to specify an EDID data set in the
/lib/firmware directory that is used instead.
drm_kms_helper.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]
Broken monitors, graphic adapters, KVMs and EDIDless
panels may send no or incorrect EDID data sets.
This parameter allows to specify an EDID data sets
in the /lib/firmware directory that are used instead.
Generic built-in EDID data sets are used, if one of
edid/1024x768.bin, edid/1280x1024.bin,
edid/1680x1050.bin, or edid/1920x1080.bin is given
@ -945,7 +945,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
available in Documentation/EDID/HOWTO.txt. An EDID
data set will only be used for a particular connector,
if its name and a colon are prepended to the EDID
name.
name. Each connector may use a unique EDID data
set by separating the files with a comma. An EDID
data set with no connector name will be used for
any connectors not explicitly specified.
dscc4.setup= [NET]
@ -1580,9 +1583,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
hwp_only
Only load intel_pstate on systems which support
hardware P state control (HWP) if available.
no_acpi
Don't use ACPI processor performance control objects
_PSS and _PPC specified limits.
intremap= [X86-64, Intel-IOMMU]
on enable Interrupt Remapping (default)

2
Documentation/networking/can.txt
View file

@ -681,7 +681,7 @@ solution for a couple of reasons:
addr.can_family = AF_CAN;
addr.can_ifindex = ifr.ifr_ifindex;
connect(s, (struct sockaddr *)&addr, sizeof(addr))
connect(s, (struct sockaddr *)&addr, sizeof(addr));
(..)

6
Documentation/networking/filter.txt
View file

@ -596,9 +596,9 @@ skb pointer). All constraints and restrictions from bpf_check_classic() apply
before a conversion to the new layout is being done behind the scenes!
Currently, the classic BPF format is being used for JITing on most of the
architectures. Only x86-64 performs JIT compilation from eBPF instruction set,
however, future work will migrate other JIT compilers as well, so that they
will profit from the very same benefits.
architectures. x86-64, aarch64 and s390x perform JIT compilation from eBPF
instruction set, however, future work will migrate other JIT compilers as well,
so that they will profit from the very same benefits.
Some core changes of the new internal format:

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

@ -709,7 +709,7 @@ tcp_limit_output_bytes - INTEGER
typical pfifo_fast qdiscs.
tcp_limit_output_bytes limits the number of bytes on qdisc
or device to reduce artificial RTT/cwnd and reduce bufferbloat.
Default: 131072
Default: 262144
tcp_challenge_ack_limit - INTEGER
Limits number of Challenge ACK sent per second, as recommended

49
Documentation/nvdimm/nvdimm.txt
View file

@ -62,6 +62,12 @@ DAX: File system extensions to bypass the page cache and block layer to
mmap persistent memory, from a PMEM block device, directly into a
process address space.
DSM: Device Specific Method: ACPI method to to control specific
device - in this case the firmware.
DCR: NVDIMM Control Region Structure defined in ACPI 6 Section 5.2.25.5.
It defines a vendor-id, device-id, and interface format for a given DIMM.
BTT: Block Translation Table: Persistent memory is byte addressable.
Existing software may have an expectation that the power-fail-atomicity
of writes is at least one sector, 512 bytes. The BTT is an indirection
@ -133,16 +139,16 @@ device driver:
registered, can be immediately attached to nd_pmem.
2. BLK (nd_blk.ko): This driver performs I/O using a set of platform
defined apertures. A set of apertures will all access just one DIMM.
Multiple windows allow multiple concurrent accesses, much like
defined apertures. A set of apertures will access just one DIMM.
Multiple windows (apertures) allow multiple concurrent accesses, much like
tagged-command-queuing, and would likely be used by different threads or
different CPUs.
The NFIT specification defines a standard format for a BLK-aperture, but
the spec also allows for vendor specific layouts, and non-NFIT BLK
implementations may other designs for BLK I/O. For this reason "nd_blk"
calls back into platform-specific code to perform the I/O. One such
implementation is defined in the "Driver Writer's Guide" and "DSM
implementations may have other designs for BLK I/O. For this reason
"nd_blk" calls back into platform-specific code to perform the I/O.
One such implementation is defined in the "Driver Writer's Guide" and "DSM
Interface Example".
@ -152,7 +158,7 @@ Why BLK?
While PMEM provides direct byte-addressable CPU-load/store access to
NVDIMM storage, it does not provide the best system RAS (recovery,
availability, and serviceability) model. An access to a corrupted
system-physical-address address causes a cpu exception while an access
system-physical-address address causes a CPU exception while an access
to a corrupted address through an BLK-aperture causes that block window
to raise an error status in a register. The latter is more aligned with
the standard error model that host-bus-adapter attached disks present.
@ -162,7 +168,7 @@ data could be interleaved in an opaque hardware specific manner across
several DIMMs.
PMEM vs BLK
BLK-apertures solve this RAS problem, but their presence is also the
BLK-apertures solve these RAS problems, but their presence is also the
major contributing factor to the complexity of the ND subsystem. They
complicate the implementation because PMEM and BLK alias in DPA space.
Any given DIMM's DPA-range may contribute to one or more
@ -220,8 +226,8 @@ socket. Each unique interface (BLK or PMEM) to DPA space is identified
by a region device with a dynamically assigned id (REGION0 - REGION5).
1. The first portion of DIMM0 and DIMM1 are interleaved as REGION0. A
single PMEM namespace is created in the REGION0-SPA-range that spans
DIMM0 and DIMM1 with a user-specified name of "pm0.0". Some of that
single PMEM namespace is created in the REGION0-SPA-range that spans most
of DIMM0 and DIMM1 with a user-specified name of "pm0.0". Some of that
interleaved system-physical-address range is reclaimed as BLK-aperture
accessed space starting at DPA-offset (a) into each DIMM. In that
reclaimed space we create two BLK-aperture "namespaces" from REGION2 and
@ -230,13 +236,13 @@ by a region device with a dynamically assigned id (REGION0 - REGION5).
2. In the last portion of DIMM0 and DIMM1 we have an interleaved
system-physical-address range, REGION1, that spans those two DIMMs as
well as DIMM2 and DIMM3. Some of REGION1 allocated to a PMEM namespace
named "pm1.0" the rest is reclaimed in 4 BLK-aperture namespaces (for
well as DIMM2 and DIMM3. Some of REGION1 is allocated to a PMEM namespace
named "pm1.0", the rest is reclaimed in 4 BLK-aperture namespaces (for
each DIMM in the interleave set), "blk2.1", "blk3.1", "blk4.0", and
"blk5.0".
3. The portion of DIMM2 and DIMM3 that do not participate in the REGION1
interleaved system-physical-address range (i.e. the DPA address below
interleaved system-physical-address range (i.e. the DPA address past
offset (b) are also included in the "blk4.0" and "blk5.0" namespaces.
Note, that this example shows that BLK-aperture namespaces don't need to
be contiguous in DPA-space.
@ -252,15 +258,15 @@ LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API
What follows is a description of the LIBNVDIMM sysfs layout and a
corresponding object hierarchy diagram as viewed through the LIBNDCTL
api. The example sysfs paths and diagrams are relative to the Example
API. The example sysfs paths and diagrams are relative to the Example
NVDIMM Platform which is also the LIBNVDIMM bus used in the LIBNDCTL unit
test.
LIBNDCTL: Context
Every api call in the LIBNDCTL library requires a context that holds the
Every API call in the LIBNDCTL library requires a context that holds the
logging parameters and other library instance state. The library is
based on the libabc template:
https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/
https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git
LIBNDCTL: instantiate a new library context example
@ -409,7 +415,7 @@ Bit 31:28 Reserved
LIBNVDIMM/LIBNDCTL: Region
----------------------
A generic REGION device is registered for each PMEM range orBLK-aperture
A generic REGION device is registered for each PMEM range or BLK-aperture
set. Per the example there are 6 regions: 2 PMEM and 4 BLK-aperture
sets on the "nfit_test.0" bus. The primary role of regions are to be a
container of "mappings". A mapping is a tuple of <DIMM,
@ -509,7 +515,7 @@ At first glance it seems since NFIT defines just PMEM and BLK interface
types that we should simply name REGION devices with something derived
from those type names. However, the ND subsystem explicitly keeps the
REGION name generic and expects userspace to always consider the
region-attributes for 4 reasons:
region-attributes for four reasons:
1. There are already more than two REGION and "namespace" types. For
PMEM there are two subtypes. As mentioned previously we have PMEM where
@ -698,8 +704,8 @@ static int configure_namespace(struct ndctl_region *region,
Why the Term "namespace"?
1. Why not "volume" for instance? "volume" ran the risk of confusing ND
as a volume manager like device-mapper.
1. Why not "volume" for instance? "volume" ran the risk of confusing
ND (libnvdimm subsystem) to a volume manager like device-mapper.
2. The term originated to describe the sub-devices that can be created
within a NVME controller (see the nvme specification:
@ -774,13 +780,14 @@ block" needs to be destroyed. Note, that to destroy a BTT the media
needs to be written in raw mode. By default, the kernel will autodetect
the presence of a BTT and disable raw mode. This autodetect behavior
can be suppressed by enabling raw mode for the namespace via the
ndctl_namespace_set_raw_mode() api.
ndctl_namespace_set_raw_mode() API.
Summary LIBNDCTL Diagram
------------------------
For the given example above, here is the view of the objects as seen by the LIBNDCTL api:
For the given example above, here is the view of the objects as seen by the
LIBNDCTL API:
+---+
|CTX| +---------+ +--------------+ +---------------+
+-+-+ +-> REGION0 +---> NAMESPACE0.0 +--> PMEM8 "pm0.0" |

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