Merge branches 'for-4.10/upstream-fixes', 'for-4.11/intel-ish', 'for-4.11/mayflash', 'for-4.11/microsoft', 'for-4.11/rmi', 'for-4.11/upstream' and 'for-4.11/wacom' into for-linus
Jiri Kosina
commit
53f724b243
4
.mailmap
4
.mailmap
|
|
@ -137,6 +137,7 @@ Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
|
|||
Rudolf Marek <R.Marek@sh.cvut.cz>
|
||||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
Sarangdhar Joshi <spjoshi@codeaurora.org>
|
||||
Sam Ravnborg <sam@mars.ravnborg.org>
|
||||
Santosh Shilimkar <ssantosh@kernel.org>
|
||||
Santosh Shilimkar <santosh.shilimkar@oracle.org>
|
||||
|
|
@ -150,10 +151,13 @@ Shuah Khan <shuah@kernel.org> <shuah.kh@samsung.com>
|
|||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
Stephen Hemminger <shemminger@osdl.org>
|
||||
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
|
||||
Subhash Jadavani <subhashj@codeaurora.org>
|
||||
Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
|
||||
Sumit Semwal <sumit.semwal@ti.com>
|
||||
Tejun Heo <htejun@gmail.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Thomas Pedersen <twp@codeaurora.org>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
|
|
|
|||
2
CREDITS
2
CREDITS
|
|
@ -3949,8 +3949,6 @@ E: gwingerde@gmail.com
|
|||
D: Ralink rt2x00 WLAN driver
|
||||
D: Minix V2 file-system
|
||||
D: Misc fixes
|
||||
S: Geessinkweg 177
|
||||
S: 7544 TX Enschede
|
||||
S: The Netherlands
|
||||
|
||||
N: Lars Wirzenius
|
||||
|
|
|
|||
|
|
@ -152,8 +152,6 @@ driver-model/
|
|||
- directory with info about Linux driver model.
|
||||
early-userspace/
|
||||
- info about initramfs, klibc, and userspace early during boot.
|
||||
edac.txt
|
||||
- information on EDAC - Error Detection And Correction
|
||||
efi-stub.txt
|
||||
- How to use the EFI boot stub to bypass GRUB or elilo on EFI systems.
|
||||
eisa.txt
|
||||
|
|
|
|||
|
|
@ -294,3 +294,10 @@ Description:
|
|||
a firmware bug to the system vendor. Writing to this file
|
||||
taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
|
||||
reduces the supportability of your system.
|
||||
|
||||
What: /sys/bus/pci/devices/.../revision
|
||||
Date: November 2016
|
||||
Contact: Emil Velikov <emil.l.velikov@gmail.com>
|
||||
Description:
|
||||
This file contains the revision field of the the PCI device.
|
||||
The value comes from device config space. The file is read only.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,9 @@
|
|||
What: Attribute for calibrating ST-Ericsson AB8500 Real Time Clock
|
||||
What: /sys/class/rtc/rtc0/device/rtc_calibration
|
||||
Date: Oct 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Mark Godfrey <mark.godfrey@stericsson.com>
|
||||
Description: The rtc_calibration attribute allows the userspace to
|
||||
Description: Attribute for calibrating ST-Ericsson AB8500 Real Time Clock
|
||||
The rtc_calibration attribute allows the userspace to
|
||||
calibrate the AB8500.s 32KHz Real Time Clock.
|
||||
Every 60 seconds the AB8500 will correct the RTC's value
|
||||
by adding to it the value of this attribute.
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
What: /sys/devices/.../deferred_probe
|
||||
Date: August 2016
|
||||
Contact: Ben Hutchings <ben.hutchings@codethink.co.uk>
|
||||
Description:
|
||||
The /sys/devices/.../deferred_probe attribute is
|
||||
present for all devices. If a driver detects during
|
||||
probing a device that a related device is not yet
|
||||
ready, it may defer probing of the first device. The
|
||||
kernel will retry probing the first device after any
|
||||
other device is successfully probed. This attribute
|
||||
reads as 1 if probing of this device is currently
|
||||
deferred, or 0 otherwise.
|
||||
|
|
@ -272,6 +272,22 @@ Description: Parameters for the CPU cache attributes
|
|||
the modified cache line is written to main
|
||||
memory only when it is replaced
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu*/cache/index*/id
|
||||
Date: September 2016
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Cache id
|
||||
|
||||
The id provides a unique number for a specific instance of
|
||||
a cache of a particular type. E.g. there may be a level
|
||||
3 unified cache on each socket in a server and we may
|
||||
assign them ids 0, 1, 2, ...
|
||||
|
||||
Note that id value can be non-contiguous. E.g. level 1
|
||||
caches typically exist per core, but there may not be a
|
||||
power of two cores on a socket, so these caches may be
|
||||
numbered 0, 1, 2, 3, 4, 5, 8, 9, 10, ...
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub_turbo_stat
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
What: /sys/devices/platform/8086%x:00/firmware_version
|
||||
Date: November 2016
|
||||
KernelVersion: 4.10
|
||||
Contact: "Sebastien Guiriec" <sebastien.guiriec@intel.com>
|
||||
Description:
|
||||
LPE Firmware version for SST driver on all atom
|
||||
plaforms (BYT/CHT/Merrifield/BSW).
|
||||
If the FW has never been loaded it will display:
|
||||
"FW not yet loaded"
|
||||
If FW has been loaded it will display:
|
||||
"v01.aa.bb.cc"
|
||||
aa: Major version is reflecting SoC version:
|
||||
0d: BYT FW
|
||||
0b: BSW FW
|
||||
07: Merrifield FW
|
||||
bb: Minor version
|
||||
cc: Build version
|
||||
|
|
@ -0,0 +1 @@
|
|||
process/changes.rst
|
||||
|
|
@ -12,8 +12,8 @@ DOCBOOKS := z8530book.xml \
|
|||
kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||
80211.xml sh.xml regulator.xml w1.xml \
|
||||
writing_musb_glue_layer.xml crypto-API.xml iio.xml
|
||||
sh.xml regulator.xml w1.xml \
|
||||
writing_musb_glue_layer.xml iio.xml
|
||||
|
||||
ifeq ($(DOCBOOKS),)
|
||||
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -111,6 +111,8 @@ ipmi_ssif - A driver for accessing BMCs on the SMBus. It uses the
|
|||
I2C kernel driver's SMBus interfaces to send and receive IPMI messages
|
||||
over the SMBus.
|
||||
|
||||
ipmi_powernv - A driver for access BMCs on POWERNV systems.
|
||||
|
||||
ipmi_watchdog - IPMI requires systems to have a very capable watchdog
|
||||
timer. This driver implements the standard Linux watchdog timer
|
||||
interface on top of the IPMI message handler.
|
||||
|
|
@ -118,17 +120,15 @@ interface on top of the IPMI message handler.
|
|||
ipmi_poweroff - Some systems support the ability to be turned off via
|
||||
IPMI commands.
|
||||
|
||||
These are all individually selectable via configuration options.
|
||||
bt-bmc - This is not part of the main driver, but instead a driver for
|
||||
accessing a BMC-side interface of a BT interface. It is used on BMCs
|
||||
running Linux to provide an interface to the host.
|
||||
|
||||
Note that the KCS-only interface has been removed. The af_ipmi driver
|
||||
is no longer supported and has been removed because it was impossible
|
||||
to do 32 bit emulation on 64-bit kernels with it.
|
||||
These are all individually selectable via configuration options.
|
||||
|
||||
Much documentation for the interface is in the include files. The
|
||||
IPMI include files are:
|
||||
|
||||
net/af_ipmi.h - Contains the socket interface.
|
||||
|
||||
linux/ipmi.h - Contains the user interface and IOCTL interface for IPMI.
|
||||
|
||||
linux/ipmi_smi.h - Contains the interface for system management interfaces
|
||||
|
|
@ -245,6 +245,16 @@ addressed (because some boards actually have multiple BMCs on them)
|
|||
and the user should not have to care what type of SMI is below them.
|
||||
|
||||
|
||||
Watching For Interfaces
|
||||
|
||||
When your code comes up, the IPMI driver may or may not have detected
|
||||
if IPMI devices exist. So you might have to defer your setup until
|
||||
the device is detected, or you might be able to do it immediately.
|
||||
To handle this, and to allow for discovery, you register an SMI
|
||||
watcher with ipmi_smi_watcher_register() to iterate over interfaces
|
||||
and tell you when they come and go.
|
||||
|
||||
|
||||
Creating the User
|
||||
|
||||
To user the message handler, you must first create a user using
|
||||
|
|
@ -263,7 +273,7 @@ closing the device automatically destroys the user.
|
|||
|
||||
Messaging
|
||||
|
||||
To send a message from kernel-land, the ipmi_request() call does
|
||||
To send a message from kernel-land, the ipmi_request_settime() call does
|
||||
pretty much all message handling. Most of the parameter are
|
||||
self-explanatory. However, it takes a "msgid" parameter. This is NOT
|
||||
the sequence number of messages. It is simply a long value that is
|
||||
|
|
@ -352,11 +362,12 @@ that for more details.
|
|||
The SI Driver
|
||||
-------------
|
||||
|
||||
The SI driver allows up to 4 KCS or SMIC interfaces to be configured
|
||||
in the system. By default, scan the ACPI tables for interfaces, and
|
||||
if it doesn't find any the driver will attempt to register one KCS
|
||||
interface at the spec-specified I/O port 0xca2 without interrupts.
|
||||
You can change this at module load time (for a module) with:
|
||||
The SI driver allows KCS, BT, and SMIC interfaces to be configured
|
||||
in the system. It discovers interfaces through a host of different
|
||||
methods, depending on the system.
|
||||
|
||||
You can specify up to four interfaces on the module load line and
|
||||
control some module parameters:
|
||||
|
||||
modprobe ipmi_si.o type=<type1>,<type2>....
|
||||
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
|
||||
|
|
@ -367,7 +378,7 @@ You can change this at module load time (for a module) with:
|
|||
force_kipmid=<enable1>,<enable2>,...
|
||||
kipmid_max_busy_us=<ustime1>,<ustime2>,...
|
||||
unload_when_empty=[0|1]
|
||||
trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
|
||||
trydmi=[0|1] tryacpi=[0|1]
|
||||
tryplatform=[0|1] trypci=[0|1]
|
||||
|
||||
Each of these except try... items is a list, the first item for the
|
||||
|
|
@ -386,10 +397,6 @@ use the I/O port given as the device address.
|
|||
If you specify irqs as non-zero for an interface, the driver will
|
||||
attempt to use the given interrupt for the device.
|
||||
|
||||
trydefaults sets whether the standard IPMI interface at 0xca2 and
|
||||
any interfaces specified by ACPE are tried. By default, the driver
|
||||
tries it, set this value to zero to turn this off.
|
||||
|
||||
The other try... items disable discovery by their corresponding
|
||||
names. These are all enabled by default, set them to zero to disable
|
||||
them. The tryplatform disables openfirmware.
|
||||
|
|
@ -434,7 +441,7 @@ kernel command line as:
|
|||
|
||||
ipmi_si.type=<type1>,<type2>...
|
||||
ipmi_si.ports=<port1>,<port2>... ipmi_si.addrs=<addr1>,<addr2>...
|
||||
ipmi_si.irqs=<irq1>,<irq2>... ipmi_si.trydefaults=[0|1]
|
||||
ipmi_si.irqs=<irq1>,<irq2>...
|
||||
ipmi_si.regspacings=<sp1>,<sp2>,...
|
||||
ipmi_si.regsizes=<size1>,<size2>,...
|
||||
ipmi_si.regshifts=<shift1>,<shift2>,...
|
||||
|
|
@ -444,11 +451,6 @@ kernel command line as:
|
|||
|
||||
It works the same as the module parameters of the same names.
|
||||
|
||||
By default, the driver will attempt to detect any device specified by
|
||||
ACPI, and if none of those then a KCS device at the spec-specified
|
||||
0xca2. If you want to turn this off, set the "trydefaults" option to
|
||||
false.
|
||||
|
||||
If your IPMI interface does not support interrupts and is a KCS or
|
||||
SMIC interface, the IPMI driver will start a kernel thread for the
|
||||
interface to help speed things up. This is a low-priority kernel
|
||||
|
|
@ -500,7 +502,8 @@ at module load time (for a module) with:
|
|||
addr=<i2caddr1>[,<i2caddr2>[,...]]
|
||||
adapter=<adapter1>[,<adapter2>[...]]
|
||||
dbg=<flags1>,<flags2>...
|
||||
slave_addrs=<addr1>,<addr2>,...
|
||||
slave_addrs=<addr1>,<addr2>,...
|
||||
tryacpi=[0|1] trydmi=[0|1]
|
||||
[dbg_probe=1]
|
||||
|
||||
The addresses are normal I2C addresses. The adapter is the string
|
||||
|
|
@ -513,6 +516,9 @@ spaces in kernel parameters.
|
|||
The debug flags are bit flags for each BMC found, they are:
|
||||
IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
|
||||
|
||||
The tryxxx parameters can be used to disable detecting interfaces
|
||||
from various sources.
|
||||
|
||||
Setting dbg_probe to 1 will enable debugging of the probing and
|
||||
detection process for BMCs on the SMBusses.
|
||||
|
||||
|
|
@ -535,7 +541,8 @@ kernel command line as:
|
|||
ipmi_ssif.adapter=<adapter1>[,<adapter2>[...]]
|
||||
ipmi_ssif.dbg=<flags1>[,<flags2>[...]]
|
||||
ipmi_ssif.dbg_probe=1
|
||||
ipmi_ssif.slave_addrs=<addr1>[,<addr2>[...]]
|
||||
ipmi_ssif.slave_addrs=<addr1>[,<addr2>[...]]
|
||||
ipmi_ssif.tryacpi=[0|1] ipmi_ssif.trydmi=[0|1]
|
||||
|
||||
These are the same options as on the module command line.
|
||||
|
||||
|
|
|
|||
|
|
@ -59,6 +59,7 @@ configure specific aspects of kernel behavior to your liking.
|
|||
binfmt-misc
|
||||
mono
|
||||
java
|
||||
ras
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
|
|
|||
|
|
@ -106,6 +106,16 @@
|
|||
use by PCI
|
||||
Format: <irq>,<irq>...
|
||||
|
||||
acpi_mask_gpe= [HW,ACPI]
|
||||
Due to the existence of _Lxx/_Exx, some GPEs triggered
|
||||
by unsupported hardware/firmware features can result in
|
||||
GPE floodings that cannot be automatically disabled by
|
||||
the GPE dispatcher.
|
||||
This facility can be used to prevent such uncontrolled
|
||||
GPE floodings.
|
||||
Format: <int>
|
||||
Support masking of GPEs numbered from 0x00 to 0x7f.
|
||||
|
||||
acpi_no_auto_serialize [HW,ACPI]
|
||||
Disable auto-serialization of AML methods
|
||||
AML control methods that contain the opcodes to create
|
||||
|
|
@ -1441,6 +1451,10 @@
|
|||
The builtin appraise policy appraises all files
|
||||
owned by uid=0.
|
||||
|
||||
ima_canonical_fmt [IMA]
|
||||
Use the canonical format for the binary runtime
|
||||
measurements, instead of host native format.
|
||||
|
||||
ima_hash= [IMA]
|
||||
Format: { md5 | sha1 | rmd160 | sha256 | sha384
|
||||
| sha512 | ... }
|
||||
|
|
@ -3807,10 +3821,11 @@
|
|||
it if 0 is given (See Documentation/cgroup-v1/memory.txt)
|
||||
|
||||
swiotlb= [ARM,IA-64,PPC,MIPS,X86]
|
||||
Format: { <int> | force }
|
||||
Format: { <int> | force | noforce }
|
||||
<int> -- Number of I/O TLB slabs
|
||||
force -- force using of bounce buffers even if they
|
||||
wouldn't be automatically used by the kernel
|
||||
noforce -- Never use bounce buffers (for debugging)
|
||||
|
||||
switches= [HW,M68k]
|
||||
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -5,7 +5,8 @@ Introduction
|
|||
------------
|
||||
|
||||
The STMicroelectronics family of Cortex-M based MCUs are supported by the
|
||||
'STM32' platform of ARM Linux. Currently only the STM32F429 is supported.
|
||||
'STM32' platform of ARM Linux. Currently only the STM32F429 (Cortex-M4)
|
||||
and STM32F746 (Cortex-M7) are supported.
|
||||
|
||||
|
||||
Configuration
|
||||
|
|
|
|||
|
|
@ -0,0 +1,34 @@
|
|||
STM32F746 Overview
|
||||
==================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
The STM32F746 is a Cortex-M7 MCU aimed at various applications.
|
||||
It features:
|
||||
- Cortex-M7 core running up to @216MHz
|
||||
- 1MB internal flash, 320KBytes internal RAM (+4KB of backup SRAM)
|
||||
- FMC controller to connect SDRAM, NOR and NAND memories
|
||||
- Dual mode QSPI
|
||||
- SD/MMC/SDIO support
|
||||
- Ethernet controller
|
||||
- USB OTFG FS & HS controllers
|
||||
- I2C, SPI, CAN busses support
|
||||
- Several 16 & 32 bits general purpose timers
|
||||
- Serial Audio interface
|
||||
- LCD controller
|
||||
- HDMI-CEC
|
||||
- SPDIFRX
|
||||
|
||||
Resources
|
||||
---------
|
||||
Datasheet and reference manual are publicly available on ST website:
|
||||
- http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f7-series/stm32f7x6/stm32f746ng.html
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
Alexandre Torgue <alexandre.torgue@st.com>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -54,9 +54,9 @@ This is the hardware sector size of the device, in bytes.
|
|||
|
||||
io_poll (RW)
|
||||
------------
|
||||
When read, this file shows the total number of block IO polls and how
|
||||
many returned success. Writing '0' to this file will disable polling
|
||||
for this device. Writing any non-zero value will enable this feature.
|
||||
When read, this file shows whether polling is enabled (1) or disabled
|
||||
(0). Writing '0' to this file will disable polling for this device.
|
||||
Writing any non-zero value will enable this feature.
|
||||
|
||||
io_poll_delay (RW)
|
||||
------------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
Authenticated Encryption With Associated Data (AEAD) Algorithm Definitions
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/aead.h
|
||||
:doc: Authenticated Encryption With Associated Data (AEAD) Cipher API
|
||||
|
||||
.. kernel-doc:: include/crypto/aead.h
|
||||
:functions: aead_request aead_alg
|
||||
|
||||
Authenticated Encryption With Associated Data (AEAD) Cipher API
|
||||
---------------------------------------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/aead.h
|
||||
:functions: crypto_alloc_aead crypto_free_aead crypto_aead_ivsize crypto_aead_authsize crypto_aead_blocksize crypto_aead_setkey crypto_aead_setauthsize crypto_aead_encrypt crypto_aead_decrypt
|
||||
|
||||
Asynchronous AEAD Request Handle
|
||||
--------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/aead.h
|
||||
:doc: Asynchronous AEAD Request Handle
|
||||
|
||||
.. kernel-doc:: include/crypto/aead.h
|
||||
:functions: crypto_aead_reqsize aead_request_set_tfm aead_request_alloc aead_request_free aead_request_set_callback aead_request_set_crypt aead_request_set_ad
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
Asymmetric Cipher Algorithm Definitions
|
||||
---------------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/akcipher.h
|
||||
:functions: akcipher_alg akcipher_request
|
||||
|
||||
Asymmetric Cipher API
|
||||
---------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/akcipher.h
|
||||
:doc: Generic Public Key API
|
||||
|
||||
.. kernel-doc:: include/crypto/akcipher.h
|
||||
:functions: crypto_alloc_akcipher crypto_free_akcipher crypto_akcipher_set_pub_key crypto_akcipher_set_priv_key crypto_akcipher_maxsize crypto_akcipher_encrypt crypto_akcipher_decrypt crypto_akcipher_sign crypto_akcipher_verify
|
||||
|
||||
Asymmetric Cipher Request Handle
|
||||
--------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/akcipher.h
|
||||
:functions: akcipher_request_alloc akcipher_request_free akcipher_request_set_callback akcipher_request_set_crypt
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
Message Digest Algorithm Definitions
|
||||
------------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:doc: Message Digest Algorithm Definitions
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:functions: hash_alg_common ahash_alg shash_alg
|
||||
|
||||
Asynchronous Message Digest API
|
||||
-------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:doc: Asynchronous Message Digest API
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:functions: crypto_alloc_ahash crypto_free_ahash crypto_ahash_init crypto_ahash_digestsize crypto_ahash_reqtfm crypto_ahash_reqsize crypto_ahash_setkey crypto_ahash_finup crypto_ahash_final crypto_ahash_digest crypto_ahash_export crypto_ahash_import
|
||||
|
||||
Asynchronous Hash Request Handle
|
||||
--------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:doc: Asynchronous Hash Request Handle
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:functions: ahash_request_set_tfm ahash_request_alloc ahash_request_free ahash_request_set_callback ahash_request_set_crypt
|
||||
|
||||
Synchronous Message Digest API
|
||||
------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:doc: Synchronous Message Digest API
|
||||
|
||||
.. kernel-doc:: include/crypto/hash.h
|
||||
:functions: crypto_alloc_shash crypto_free_shash crypto_shash_blocksize crypto_shash_digestsize crypto_shash_descsize crypto_shash_setkey crypto_shash_digest crypto_shash_export crypto_shash_import crypto_shash_init crypto_shash_update crypto_shash_final crypto_shash_finup
|
||||
|
|
@ -44,12 +44,9 @@ one block while the former can operate on an arbitrary amount of data,
|
|||
subject to block size requirements (i.e., non-stream ciphers can only
|
||||
process multiples of blocks).
|
||||
|
||||
Support for hardware crypto devices via an asynchronous interface is
|
||||
under development.
|
||||
|
||||
Here's an example of how to use the API:
|
||||
|
||||
#include <crypto/ahash.h>
|
||||
#include <crypto/hash.h>
|
||||
#include <linux/err.h>
|
||||
#include <linux/scatterlist.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,38 @@
|
|||
Key-agreement Protocol Primitives (KPP) Cipher Algorithm Definitions
|
||||
--------------------------------------------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/kpp.h
|
||||
:functions: kpp_request crypto_kpp kpp_alg kpp_secret
|
||||
|
||||
Key-agreement Protocol Primitives (KPP) Cipher API
|
||||
--------------------------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/kpp.h
|
||||
:doc: Generic Key-agreement Protocol Primitives API
|
||||
|
||||
.. kernel-doc:: include/crypto/kpp.h
|
||||
:functions: crypto_alloc_kpp crypto_free_kpp crypto_kpp_set_secret crypto_kpp_generate_public_key crypto_kpp_compute_shared_secret crypto_kpp_maxsize
|
||||
|
||||
Key-agreement Protocol Primitives (KPP) Cipher Request Handle
|
||||
-------------------------------------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/kpp.h
|
||||
:functions: kpp_request_alloc kpp_request_free kpp_request_set_callback kpp_request_set_input kpp_request_set_output
|
||||
|
||||
ECDH Helper Functions
|
||||
---------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/ecdh.h
|
||||
:doc: ECDH Helper Functions
|
||||
|
||||
.. kernel-doc:: include/crypto/ecdh.h
|
||||
:functions: ecdh crypto_ecdh_key_len crypto_ecdh_encode_key crypto_ecdh_decode_key
|
||||
|
||||
DH Helper Functions
|
||||
-------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/dh.h
|
||||
:doc: DH Helper Functions
|
||||
|
||||
.. kernel-doc:: include/crypto/dh.h
|
||||
:functions: dh crypto_dh_key_len crypto_dh_encode_key crypto_dh_decode_key
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Random Number Algorithm Definitions
|
||||
-----------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/rng.h
|
||||
:functions: rng_alg
|
||||
|
||||
Crypto API Random Number API
|
||||
----------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/rng.h
|
||||
:doc: Random number generator API
|
||||
|
||||
.. kernel-doc:: include/crypto/rng.h
|
||||
:functions: crypto_alloc_rng crypto_rng_alg crypto_free_rng crypto_rng_generate crypto_rng_get_bytes crypto_rng_reset crypto_rng_seedsize
|
||||
|
|
@ -0,0 +1,224 @@
|
|||
Code Examples
|
||||
=============
|
||||
|
||||
Code Example For Symmetric Key Cipher Operation
|
||||
-----------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
|
||||
struct tcrypt_result {
|
||||
struct completion completion;
|
||||
int err;
|
||||
};
|
||||
|
||||
/* tie all data structures together */
|
||||
struct skcipher_def {
|
||||
struct scatterlist sg;
|
||||
struct crypto_skcipher *tfm;
|
||||
struct skcipher_request *req;
|
||||
struct tcrypt_result result;
|
||||
};
|
||||
|
||||
/* Callback function */
|
||||
static void test_skcipher_cb(struct crypto_async_request *req, int error)
|
||||
{
|
||||
struct tcrypt_result *result = req->data;
|
||||
|
||||
if (error == -EINPROGRESS)
|
||||
return;
|
||||
result->err = error;
|
||||
complete(&result->completion);
|
||||
pr_info("Encryption finished successfully\n");
|
||||
}
|
||||
|
||||
/* Perform cipher operation */
|
||||
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
|
||||
int enc)
|
||||
{
|
||||
int rc = 0;
|
||||
|
||||
if (enc)
|
||||
rc = crypto_skcipher_encrypt(sk->req);
|
||||
else
|
||||
rc = crypto_skcipher_decrypt(sk->req);
|
||||
|
||||
switch (rc) {
|
||||
case 0:
|
||||
break;
|
||||
case -EINPROGRESS:
|
||||
case -EBUSY:
|
||||
rc = wait_for_completion_interruptible(
|
||||
&sk->result.completion);
|
||||
if (!rc && !sk->result.err) {
|
||||
reinit_completion(&sk->result.completion);
|
||||
break;
|
||||
}
|
||||
default:
|
||||
pr_info("skcipher encrypt returned with %d result %d\n",
|
||||
rc, sk->result.err);
|
||||
break;
|
||||
}
|
||||
init_completion(&sk->result.completion);
|
||||
|
||||
return rc;
|
||||
}
|
||||
|
||||
/* Initialize and trigger cipher operation */
|
||||
static int test_skcipher(void)
|
||||
{
|
||||
struct skcipher_def sk;
|
||||
struct crypto_skcipher *skcipher = NULL;
|
||||
struct skcipher_request *req = NULL;
|
||||
char *scratchpad = NULL;
|
||||
char *ivdata = NULL;
|
||||
unsigned char key[32];
|
||||
int ret = -EFAULT;
|
||||
|
||||
skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0);
|
||||
if (IS_ERR(skcipher)) {
|
||||
pr_info("could not allocate skcipher handle\n");
|
||||
return PTR_ERR(skcipher);
|
||||
}
|
||||
|
||||
req = skcipher_request_alloc(skcipher, GFP_KERNEL);
|
||||
if (!req) {
|
||||
pr_info("could not allocate skcipher request\n");
|
||||
ret = -ENOMEM;
|
||||
goto out;
|
||||
}
|
||||
|
||||
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
|
||||
test_skcipher_cb,
|
||||
&sk.result);
|
||||
|
||||
/* AES 256 with random key */
|
||||
get_random_bytes(&key, 32);
|
||||
if (crypto_skcipher_setkey(skcipher, key, 32)) {
|
||||
pr_info("key could not be set\n");
|
||||
ret = -EAGAIN;
|
||||
goto out;
|
||||
}
|
||||
|
||||
/* IV will be random */
|
||||
ivdata = kmalloc(16, GFP_KERNEL);
|
||||
if (!ivdata) {
|
||||
pr_info("could not allocate ivdata\n");
|
||||
goto out;
|
||||
}
|
||||
get_random_bytes(ivdata, 16);
|
||||
|
||||
/* Input data will be random */
|
||||
scratchpad = kmalloc(16, GFP_KERNEL);
|
||||
if (!scratchpad) {
|
||||
pr_info("could not allocate scratchpad\n");
|
||||
goto out;
|
||||
}
|
||||
get_random_bytes(scratchpad, 16);
|
||||
|
||||
sk.tfm = skcipher;
|
||||
sk.req = req;
|
||||
|
||||
/* We encrypt one block */
|
||||
sg_init_one(&sk.sg, scratchpad, 16);
|
||||
skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
|
||||
init_completion(&sk.result.completion);
|
||||
|
||||
/* encrypt data */
|
||||
ret = test_skcipher_encdec(&sk, 1);
|
||||
if (ret)
|
||||
goto out;
|
||||
|
||||
pr_info("Encryption triggered successfully\n");
|
||||
|
||||
out:
|
||||
if (skcipher)
|
||||
crypto_free_skcipher(skcipher);
|
||||
if (req)
|
||||
skcipher_request_free(req);
|
||||
if (ivdata)
|
||||
kfree(ivdata);
|
||||
if (scratchpad)
|
||||
kfree(scratchpad);
|
||||
return ret;
|
||||
}
|
||||
|
||||
|
||||
Code Example For Use of Operational State Memory With SHASH
|
||||
-----------------------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
|
||||
struct sdesc {
|
||||
struct shash_desc shash;
|
||||
char ctx[];
|
||||
};
|
||||
|
||||
static struct sdescinit_sdesc(struct crypto_shash *alg)
|
||||
{
|
||||
struct sdescsdesc;
|
||||
int size;
|
||||
|
||||
size = sizeof(struct shash_desc) + crypto_shash_descsize(alg);
|
||||
sdesc = kmalloc(size, GFP_KERNEL);
|
||||
if (!sdesc)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
sdesc->shash.tfm = alg;
|
||||
sdesc->shash.flags = 0x0;
|
||||
return sdesc;
|
||||
}
|
||||
|
||||
static int calc_hash(struct crypto_shashalg,
|
||||
const unsigned chardata, unsigned int datalen,
|
||||
unsigned chardigest) {
|
||||
struct sdescsdesc;
|
||||
int ret;
|
||||
|
||||
sdesc = init_sdesc(alg);
|
||||
if (IS_ERR(sdesc)) {
|
||||
pr_info("trusted_key: can't alloc %s\n", hash_alg);
|
||||
return PTR_ERR(sdesc);
|
||||
}
|
||||
|
||||
ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest);
|
||||
kfree(sdesc);
|
||||
return ret;
|
||||
}
|
||||
|
||||
|
||||
Code Example For Random Number Generator Usage
|
||||
----------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
|
||||
static int get_random_numbers(u8 *buf, unsigned int len)
|
||||
{
|
||||
struct crypto_rngrng = NULL;
|
||||
chardrbg = "drbg_nopr_sha256"; /* Hash DRBG with SHA-256, no PR */
|
||||
int ret;
|
||||
|
||||
if (!buf || !len) {
|
||||
pr_debug("No output buffer provided\n");
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
rng = crypto_alloc_rng(drbg, 0, 0);
|
||||
if (IS_ERR(rng)) {
|
||||
pr_debug("could not allocate RNG handle for %s\n", drbg);
|
||||
return -PTR_ERR(rng);
|
||||
}
|
||||
|
||||
ret = crypto_rng_get_bytes(rng, buf, len);
|
||||
if (ret < 0)
|
||||
pr_debug("generation of random numbers failed\n");
|
||||
else if (ret == 0)
|
||||
pr_debug("RNG returned no data");
|
||||
else
|
||||
pr_debug("RNG returned %d bytes of data\n", ret);
|
||||
|
||||
out:
|
||||
crypto_free_rng(rng);
|
||||
return ret;
|
||||
}
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
Block Cipher Algorithm Definitions
|
||||
----------------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:doc: Block Cipher Algorithm Definitions
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:functions: crypto_alg ablkcipher_alg blkcipher_alg cipher_alg
|
||||
|
||||
Symmetric Key Cipher API
|
||||
------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/skcipher.h
|
||||
:doc: Symmetric Key Cipher API
|
||||
|
||||
.. kernel-doc:: include/crypto/skcipher.h
|
||||
:functions: crypto_alloc_skcipher crypto_free_skcipher crypto_has_skcipher crypto_skcipher_ivsize crypto_skcipher_blocksize crypto_skcipher_setkey crypto_skcipher_reqtfm crypto_skcipher_encrypt crypto_skcipher_decrypt
|
||||
|
||||
Symmetric Key Cipher Request Handle
|
||||
-----------------------------------
|
||||
|
||||
.. kernel-doc:: include/crypto/skcipher.h
|
||||
:doc: Symmetric Key Cipher Request Handle
|
||||
|
||||
.. kernel-doc:: include/crypto/skcipher.h
|
||||
:functions: crypto_skcipher_reqsize skcipher_request_set_tfm skcipher_request_alloc skcipher_request_free skcipher_request_set_callback skcipher_request_set_crypt
|
||||
|
||||
Single Block Cipher API
|
||||
-----------------------
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:doc: Single Block Cipher API
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:functions: crypto_alloc_cipher crypto_free_cipher crypto_has_cipher crypto_cipher_blocksize crypto_cipher_setkey crypto_cipher_encrypt_one crypto_cipher_decrypt_one
|
||||
|
||||
Asynchronous Block Cipher API - Deprecated
|
||||
------------------------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:doc: Asynchronous Block Cipher API
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:functions: crypto_free_ablkcipher crypto_has_ablkcipher crypto_ablkcipher_ivsize crypto_ablkcipher_blocksize crypto_ablkcipher_setkey crypto_ablkcipher_reqtfm crypto_ablkcipher_encrypt crypto_ablkcipher_decrypt
|
||||
|
||||
Asynchronous Cipher Request Handle - Deprecated
|
||||
-----------------------------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:doc: Asynchronous Cipher Request Handle
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:functions: crypto_ablkcipher_reqsize ablkcipher_request_set_tfm ablkcipher_request_alloc ablkcipher_request_free ablkcipher_request_set_callback ablkcipher_request_set_crypt
|
||||
|
||||
Synchronous Block Cipher API - Deprecated
|
||||
-----------------------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:doc: Synchronous Block Cipher API
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
:functions: crypto_alloc_blkcipher rypto_free_blkcipher crypto_has_blkcipher crypto_blkcipher_name crypto_blkcipher_ivsize crypto_blkcipher_blocksize crypto_blkcipher_setkey crypto_blkcipher_encrypt crypto_blkcipher_encrypt_iv crypto_blkcipher_decrypt crypto_blkcipher_decrypt_iv crypto_blkcipher_set_iv crypto_blkcipher_get_iv
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
Programming Interface
|
||||
=====================
|
||||
|
||||
Please note that the kernel crypto API contains the AEAD givcrypt API
|
||||
(crypto_aead_giv\* and aead_givcrypt\* function calls in
|
||||
include/crypto/aead.h). This API is obsolete and will be removed in the
|
||||
future. To obtain the functionality of an AEAD cipher with internal IV
|
||||
generation, use the IV generator as a regular cipher. For example,
|
||||
rfc4106(gcm(aes)) is the AEAD cipher with external IV generation and
|
||||
seqniv(rfc4106(gcm(aes))) implies that the kernel crypto API generates
|
||||
the IV. Different IV generators are available.
|
||||
|
||||
.. class:: toc-title
|
||||
|
||||
Table of contents
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
api-skcipher
|
||||
api-aead
|
||||
api-digest
|
||||
api-rng
|
||||
api-akcipher
|
||||
api-kpp
|
||||
|
|
@ -0,0 +1,441 @@
|
|||
Kernel Crypto API Architecture
|
||||
==============================
|
||||
|
||||
Cipher algorithm types
|
||||
----------------------
|
||||
|
||||
The kernel crypto API provides different API calls for the following
|
||||
cipher types:
|
||||
|
||||
- Symmetric ciphers
|
||||
|
||||
- AEAD ciphers
|
||||
|
||||
- Message digest, including keyed message digest
|
||||
|
||||
- Random number generation
|
||||
|
||||
- User space interface
|
||||
|
||||
Ciphers And Templates
|
||||
---------------------
|
||||
|
||||
The kernel crypto API provides implementations of single block ciphers
|
||||
and message digests. In addition, the kernel crypto API provides
|
||||
numerous "templates" that can be used in conjunction with the single
|
||||
block ciphers and message digests. Templates include all types of block
|
||||
chaining mode, the HMAC mechanism, etc.
|
||||
|
||||
Single block ciphers and message digests can either be directly used by
|
||||
a caller or invoked together with a template to form multi-block ciphers
|
||||
or keyed message digests.
|
||||
|
||||
A single block cipher may even be called with multiple templates.
|
||||
However, templates cannot be used without a single cipher.
|
||||
|
||||
See /proc/crypto and search for "name". For example:
|
||||
|
||||
- aes
|
||||
|
||||
- ecb(aes)
|
||||
|
||||
- cmac(aes)
|
||||
|
||||
- ccm(aes)
|
||||
|
||||
- rfc4106(gcm(aes))
|
||||
|
||||
- sha1
|
||||
|
||||
- hmac(sha1)
|
||||
|
||||
- authenc(hmac(sha1),cbc(aes))
|
||||
|
||||
In these examples, "aes" and "sha1" are the ciphers and all others are
|
||||
the templates.
|
||||
|
||||
Synchronous And Asynchronous Operation
|
||||
--------------------------------------
|
||||
|
||||
The kernel crypto API provides synchronous and asynchronous API
|
||||
operations.
|
||||
|
||||
When using the synchronous API operation, the caller invokes a cipher
|
||||
operation which is performed synchronously by the kernel crypto API.
|
||||
That means, the caller waits until the cipher operation completes.
|
||||
Therefore, the kernel crypto API calls work like regular function calls.
|
||||
For synchronous operation, the set of API calls is small and
|
||||
conceptually similar to any other crypto library.
|
||||
|
||||
Asynchronous operation is provided by the kernel crypto API which
|
||||
implies that the invocation of a cipher operation will complete almost
|
||||
instantly. That invocation triggers the cipher operation but it does not
|
||||
signal its completion. Before invoking a cipher operation, the caller
|
||||
must provide a callback function the kernel crypto API can invoke to
|
||||
signal the completion of the cipher operation. Furthermore, the caller
|
||||
must ensure it can handle such asynchronous events by applying
|
||||
appropriate locking around its data. The kernel crypto API does not
|
||||
perform any special serialization operation to protect the caller's data
|
||||
integrity.
|
||||
|
||||
Crypto API Cipher References And Priority
|
||||
-----------------------------------------
|
||||
|
||||
A cipher is referenced by the caller with a string. That string has the
|
||||
following semantics:
|
||||
|
||||
::
|
||||
|
||||
template(single block cipher)
|
||||
|
||||
|
||||
where "template" and "single block cipher" is the aforementioned
|
||||
template and single block cipher, respectively. If applicable,
|
||||
additional templates may enclose other templates, such as
|
||||
|
||||
::
|
||||
|
||||
template1(template2(single block cipher)))
|
||||
|
||||
|
||||
The kernel crypto API may provide multiple implementations of a template
|
||||
or a single block cipher. For example, AES on newer Intel hardware has
|
||||
the following implementations: AES-NI, assembler implementation, or
|
||||
straight C. Now, when using the string "aes" with the kernel crypto API,
|
||||
which cipher implementation is used? The answer to that question is the
|
||||
priority number assigned to each cipher implementation by the kernel
|
||||
crypto API. When a caller uses the string to refer to a cipher during
|
||||
initialization of a cipher handle, the kernel crypto API looks up all
|
||||
implementations providing an implementation with that name and selects
|
||||
the implementation with the highest priority.
|
||||
|
||||
Now, a caller may have the need to refer to a specific cipher
|
||||
implementation and thus does not want to rely on the priority-based
|
||||
selection. To accommodate this scenario, the kernel crypto API allows
|
||||
the cipher implementation to register a unique name in addition to
|
||||
common names. When using that unique name, a caller is therefore always
|
||||
sure to refer to the intended cipher implementation.
|
||||
|
||||
The list of available ciphers is given in /proc/crypto. However, that
|
||||
list does not specify all possible permutations of templates and
|
||||
ciphers. Each block listed in /proc/crypto may contain the following
|
||||
information -- if one of the components listed as follows are not
|
||||
applicable to a cipher, it is not displayed:
|
||||
|
||||
- name: the generic name of the cipher that is subject to the
|
||||
priority-based selection -- this name can be used by the cipher
|
||||
allocation API calls (all names listed above are examples for such
|
||||
generic names)
|
||||
|
||||
- driver: the unique name of the cipher -- this name can be used by the
|
||||
cipher allocation API calls
|
||||
|
||||
- module: the kernel module providing the cipher implementation (or
|
||||
"kernel" for statically linked ciphers)
|
||||
|
||||
- priority: the priority value of the cipher implementation
|
||||
|
||||
- refcnt: the reference count of the respective cipher (i.e. the number
|
||||
of current consumers of this cipher)
|
||||
|
||||
- selftest: specification whether the self test for the cipher passed
|
||||
|
||||
- type:
|
||||
|
||||
- skcipher for symmetric key ciphers
|
||||
|
||||
- cipher for single block ciphers that may be used with an
|
||||
additional template
|
||||
|
||||
- shash for synchronous message digest
|
||||
|
||||
- ahash for asynchronous message digest
|
||||
|
||||
- aead for AEAD cipher type
|
||||
|
||||
- compression for compression type transformations
|
||||
|
||||
- rng for random number generator
|
||||
|
||||
- givcipher for cipher with associated IV generator (see the geniv
|
||||
entry below for the specification of the IV generator type used by
|
||||
the cipher implementation)
|
||||
|
||||
- kpp for a Key-agreement Protocol Primitive (KPP) cipher such as
|
||||
an ECDH or DH implementation
|
||||
|
||||
- blocksize: blocksize of cipher in bytes
|
||||
|
||||
- keysize: key size in bytes
|
||||
|
||||
- ivsize: IV size in bytes
|
||||
|
||||
- seedsize: required size of seed data for random number generator
|
||||
|
||||
- digestsize: output size of the message digest
|
||||
|
||||
- geniv: IV generation type:
|
||||
|
||||
- eseqiv for encrypted sequence number based IV generation
|
||||
|
||||
- seqiv for sequence number based IV generation
|
||||
|
||||
- chainiv for chain iv generation
|
||||
|
||||
- <builtin> is a marker that the cipher implements IV generation and
|
||||
handling as it is specific to the given cipher
|
||||
|
||||
Key Sizes
|
||||
---------
|
||||
|
||||
When allocating a cipher handle, the caller only specifies the cipher
|
||||
type. Symmetric ciphers, however, typically support multiple key sizes
|
||||
(e.g. AES-128 vs. AES-192 vs. AES-256). These key sizes are determined
|
||||
with the length of the provided key. Thus, the kernel crypto API does
|
||||
not provide a separate way to select the particular symmetric cipher key
|
||||
size.
|
||||
|
||||
Cipher Allocation Type And Masks
|
||||
--------------------------------
|
||||
|
||||
The different cipher handle allocation functions allow the specification
|
||||
of a type and mask flag. Both parameters have the following meaning (and
|
||||
are therefore not covered in the subsequent sections).
|
||||
|
||||
The type flag specifies the type of the cipher algorithm. The caller
|
||||
usually provides a 0 when the caller wants the default handling.
|
||||
Otherwise, the caller may provide the following selections which match
|
||||
the aforementioned cipher types:
|
||||
|
||||
- CRYPTO_ALG_TYPE_CIPHER Single block cipher
|
||||
|
||||
- CRYPTO_ALG_TYPE_COMPRESS Compression
|
||||
|
||||
- CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data
|
||||
(MAC)
|
||||
|
||||
- CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher
|
||||
|
||||
- CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher
|
||||
|
||||
- CRYPTO_ALG_TYPE_GIVCIPHER Asynchronous multi-block cipher packed
|
||||
together with an IV generator (see geniv field in the /proc/crypto
|
||||
listing for the known IV generators)
|
||||
|
||||
- CRYPTO_ALG_TYPE_KPP Key-agreement Protocol Primitive (KPP) such as
|
||||
an ECDH or DH implementation
|
||||
|
||||
- CRYPTO_ALG_TYPE_DIGEST Raw message digest
|
||||
|
||||
- CRYPTO_ALG_TYPE_HASH Alias for CRYPTO_ALG_TYPE_DIGEST
|
||||
|
||||
- CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash
|
||||
|
||||
- CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash
|
||||
|
||||
- CRYPTO_ALG_TYPE_RNG Random Number Generation
|
||||
|
||||
- CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher
|
||||
|
||||
- CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of
|
||||
CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression /
|
||||
decompression instead of performing the operation on one segment
|
||||
only. CRYPTO_ALG_TYPE_PCOMPRESS is intended to replace
|
||||
CRYPTO_ALG_TYPE_COMPRESS once existing consumers are converted.
|
||||
|
||||
The mask flag restricts the type of cipher. The only allowed flag is
|
||||
CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
|
||||
asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
|
||||
|
||||
When the caller provides a mask and type specification, the caller
|
||||
limits the search the kernel crypto API can perform for a suitable
|
||||
cipher implementation for the given cipher name. That means, even when a
|
||||
caller uses a cipher name that exists during its initialization call,
|
||||
the kernel crypto API may not select it due to the used type and mask
|
||||
field.
|
||||
|
||||
Internal Structure of Kernel Crypto API
|
||||
---------------------------------------
|
||||
|
||||
The kernel crypto API has an internal structure where a cipher
|
||||
implementation may use many layers and indirections. This section shall
|
||||
help to clarify how the kernel crypto API uses various components to
|
||||
implement the complete cipher.
|
||||
|
||||
The following subsections explain the internal structure based on
|
||||
existing cipher implementations. The first section addresses the most
|
||||
complex scenario where all other scenarios form a logical subset.
|
||||
|
||||
Generic AEAD Cipher Structure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following ASCII art decomposes the kernel crypto API layers when
|
||||
using the AEAD cipher with the automated IV generation. The shown
|
||||
example is used by the IPSEC layer.
|
||||
|
||||
For other use cases of AEAD ciphers, the ASCII art applies as well, but
|
||||
the caller may not use the AEAD cipher with a separate IV generator. In
|
||||
this case, the caller must generate the IV.
|
||||
|
||||
The depicted example decomposes the AEAD cipher of GCM(AES) based on the
|
||||
generic C implementations (gcm.c, aes-generic.c, ctr.c, ghash-generic.c,
|
||||
seqiv.c). The generic implementation serves as an example showing the
|
||||
complete logic of the kernel crypto API.
|
||||
|
||||
It is possible that some streamlined cipher implementations (like
|
||||
AES-NI) provide implementations merging aspects which in the view of the
|
||||
kernel crypto API cannot be decomposed into layers any more. In case of
|
||||
the AES-NI implementation, the CTR mode, the GHASH implementation and
|
||||
the AES cipher are all merged into one cipher implementation registered
|
||||
with the kernel crypto API. In this case, the concept described by the
|
||||
following ASCII art applies too. However, the decomposition of GCM into
|
||||
the individual sub-components by the kernel crypto API is not done any
|
||||
more.
|
||||
|
||||
Each block in the following ASCII art is an independent cipher instance
|
||||
obtained from the kernel crypto API. Each block is accessed by the
|
||||
caller or by other blocks using the API functions defined by the kernel
|
||||
crypto API for the cipher implementation type.
|
||||
|
||||
The blocks below indicate the cipher type as well as the specific logic
|
||||
implemented in the cipher.
|
||||
|
||||
The ASCII art picture also indicates the call structure, i.e. who calls
|
||||
which component. The arrows point to the invoked block where the caller
|
||||
uses the API applicable to the cipher type specified for the block.
|
||||
|
||||
::
|
||||
|
||||
|
||||
kernel crypto API | IPSEC Layer
|
||||
|
|
||||
+-----------+ |
|
||||
| | (1)
|
||||
| aead | <----------------------------------- esp_output
|
||||
| (seqiv) | ---+
|
||||
+-----------+ |
|
||||
| (2)
|
||||
+-----------+ |
|
||||
| | <--+ (2)
|
||||
| aead | <----------------------------------- esp_input
|
||||
| (gcm) | ------------+
|
||||
+-----------+ |
|
||||
| (3) | (5)
|
||||
v v
|
||||
+-----------+ +-----------+
|
||||
| | | |
|
||||
| skcipher | | ahash |
|
||||
| (ctr) | ---+ | (ghash) |
|
||||
+-----------+ | +-----------+
|
||||
|
|
||||
+-----------+ | (4)
|
||||
| | <--+
|
||||
| cipher |
|
||||
| (aes) |
|
||||
+-----------+
|
||||
|
||||
|
||||
|
||||
The following call sequence is applicable when the IPSEC layer triggers
|
||||
an encryption operation with the esp_output function. During
|
||||
configuration, the administrator set up the use of rfc4106(gcm(aes)) as
|
||||
the cipher for ESP. The following call sequence is now depicted in the
|
||||
ASCII art above:
|
||||
|
||||
1. esp_output() invokes crypto_aead_encrypt() to trigger an
|
||||
encryption operation of the AEAD cipher with IV generator.
|
||||
|
||||
In case of GCM, the SEQIV implementation is registered as GIVCIPHER
|
||||
in crypto_rfc4106_alloc().
|
||||
|
||||
The SEQIV performs its operation to generate an IV where the core
|
||||
function is seqiv_geniv().
|
||||
|
||||
2. Now, SEQIV uses the AEAD API function calls to invoke the associated
|
||||
AEAD cipher. In our case, during the instantiation of SEQIV, the
|
||||
cipher handle for GCM is provided to SEQIV. This means that SEQIV
|
||||
invokes AEAD cipher operations with the GCM cipher handle.
|
||||
|
||||
During instantiation of the GCM handle, the CTR(AES) and GHASH
|
||||
ciphers are instantiated. The cipher handles for CTR(AES) and GHASH
|
||||
are retained for later use.
|
||||
|
||||
The GCM implementation is responsible to invoke the CTR mode AES and
|
||||
the GHASH cipher in the right manner to implement the GCM
|
||||
specification.
|
||||
|
||||
3. The GCM AEAD cipher type implementation now invokes the SKCIPHER API
|
||||
with the instantiated CTR(AES) cipher handle.
|
||||
|
||||
During instantiation of the CTR(AES) cipher, the CIPHER type
|
||||
implementation of AES is instantiated. The cipher handle for AES is
|
||||
retained.
|
||||
|
||||
That means that the SKCIPHER implementation of CTR(AES) only
|
||||
implements the CTR block chaining mode. After performing the block
|
||||
chaining operation, the CIPHER implementation of AES is invoked.
|
||||
|
||||
4. The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
|
||||
cipher handle to encrypt one block.
|
||||
|
||||
5. The GCM AEAD implementation also invokes the GHASH cipher
|
||||
implementation via the AHASH API.
|
||||
|
||||
When the IPSEC layer triggers the esp_input() function, the same call
|
||||
sequence is followed with the only difference that the operation starts
|
||||
with step (2).
|
||||
|
||||
Generic Block Cipher Structure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Generic block ciphers follow the same concept as depicted with the ASCII
|
||||
art picture above.
|
||||
|
||||
For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
|
||||
ASCII art picture above applies as well with the difference that only
|
||||
step (4) is used and the SKCIPHER block chaining mode is CBC.
|
||||
|
||||
Generic Keyed Message Digest Structure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Keyed message digest implementations again follow the same concept as
|
||||
depicted in the ASCII art picture above.
|
||||
|
||||
For example, HMAC(SHA256) is implemented with hmac.c and
|
||||
sha256_generic.c. The following ASCII art illustrates the
|
||||
implementation:
|
||||
|
||||
::
|
||||
|
||||
|
||||
kernel crypto API | Caller
|
||||
|
|
||||
+-----------+ (1) |
|
||||
| | <------------------ some_function
|
||||
| ahash |
|
||||
| (hmac) | ---+
|
||||
+-----------+ |
|
||||
| (2)
|
||||
+-----------+ |
|
||||
| | <--+
|
||||
| shash |
|
||||
| (sha256) |
|
||||
+-----------+
|
||||
|
||||
|
||||
|
||||
The following call sequence is applicable when a caller triggers an HMAC
|
||||
operation:
|
||||
|
||||
1. The AHASH API functions are invoked by the caller. The HMAC
|
||||
implementation performs its operation as needed.
|
||||
|
||||
During initialization of the HMAC cipher, the SHASH cipher type of
|
||||
SHA256 is instantiated. The cipher handle for the SHA256 instance is
|
||||
retained.
|
||||
|
||||
At one time, the HMAC implementation requires a SHA256 operation
|
||||
where the SHA256 cipher handle is used.
|
||||
|
||||
2. The HMAC instance now invokes the SHASH API with the SHA256 cipher
|
||||
handle to calculate the message digest.
|
||||
|
|
@ -0,0 +1,247 @@
|
|||
Developing Cipher Algorithms
|
||||
============================
|
||||
|
||||
Registering And Unregistering Transformation
|
||||
--------------------------------------------
|
||||
|
||||
There are three distinct types of registration functions in the Crypto
|
||||
API. One is used to register a generic cryptographic transformation,
|
||||
while the other two are specific to HASH transformations and
|
||||
COMPRESSion. We will discuss the latter two in a separate chapter, here
|
||||
we will only look at the generic ones.
|
||||
|
||||
Before discussing the register functions, the data structure to be
|
||||
filled with each, struct crypto_alg, must be considered -- see below
|
||||
for a description of this data structure.
|
||||
|
||||
The generic registration functions can be found in
|
||||
include/linux/crypto.h and their definition can be seen below. The
|
||||
former function registers a single transformation, while the latter
|
||||
works on an array of transformation descriptions. The latter is useful
|
||||
when registering transformations in bulk, for example when a driver
|
||||
implements multiple transformations.
|
||||
|
||||
::
|
||||
|
||||
int crypto_register_alg(struct crypto_alg *alg);
|
||||
int crypto_register_algs(struct crypto_alg *algs, int count);
|
||||
|
||||
|
||||
The counterparts to those functions are listed below.
|
||||
|
||||
::
|
||||
|
||||
int crypto_unregister_alg(struct crypto_alg *alg);
|
||||
int crypto_unregister_algs(struct crypto_alg *algs, int count);
|
||||
|
||||
|
||||
Notice that both registration and unregistration functions do return a
|
||||
value, so make sure to handle errors. A return code of zero implies
|
||||
success. Any return code < 0 implies an error.
|
||||
|
||||
The bulk registration/unregistration functions register/unregister each
|
||||
transformation in the given array of length count. They handle errors as
|
||||
follows:
|
||||
|
||||
- crypto_register_algs() succeeds if and only if it successfully
|
||||
registers all the given transformations. If an error occurs partway
|
||||
through, then it rolls back successful registrations before returning
|
||||
the error code. Note that if a driver needs to handle registration
|
||||
errors for individual transformations, then it will need to use the
|
||||
non-bulk function crypto_register_alg() instead.
|
||||
|
||||
- crypto_unregister_algs() tries to unregister all the given
|
||||
transformations, continuing on error. It logs errors and always
|
||||
returns zero.
|
||||
|
||||
Single-Block Symmetric Ciphers [CIPHER]
|
||||
---------------------------------------
|
||||
|
||||
Example of transformations: aes, arc4, ...
|
||||
|
||||
This section describes the simplest of all transformation
|
||||
implementations, that being the CIPHER type used for symmetric ciphers.
|
||||
The CIPHER type is used for transformations which operate on exactly one
|
||||
block at a time and there are no dependencies between blocks at all.
|
||||
|
||||
Registration specifics
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The registration of [CIPHER] algorithm is specific in that struct
|
||||
crypto_alg field .cra_type is empty. The .cra_u.cipher has to be
|
||||
filled in with proper callbacks to implement this transformation.
|
||||
|
||||
See struct cipher_alg below.
|
||||
|
||||
Cipher Definition With struct cipher_alg
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Struct cipher_alg defines a single block cipher.
|
||||
|
||||
Here are schematics of how these functions are called when operated from
|
||||
other part of the kernel. Note that the .cia_setkey() call might happen
|
||||
before or after any of these schematics happen, but must not happen
|
||||
during any of these are in-flight.
|
||||
|
||||
::
|
||||
|
||||
KEY ---. PLAINTEXT ---.
|
||||
v v
|
||||
.cia_setkey() -> .cia_encrypt()
|
||||
|
|
||||
'-----> CIPHERTEXT
|
||||
|
||||
|
||||
Please note that a pattern where .cia_setkey() is called multiple times
|
||||
is also valid:
|
||||
|
||||
::
|
||||
|
||||
|
||||
KEY1 --. PLAINTEXT1 --. KEY2 --. PLAINTEXT2 --.
|
||||
v v v v
|
||||
.cia_setkey() -> .cia_encrypt() -> .cia_setkey() -> .cia_encrypt()
|
||||
| |
|
||||
'---> CIPHERTEXT1 '---> CIPHERTEXT2
|
||||
|
||||
|
||||
Multi-Block Ciphers
|
||||
-------------------
|
||||
|
||||
Example of transformations: cbc(aes), ecb(arc4), ...
|
||||
|
||||
This section describes the multi-block cipher transformation
|
||||
implementations. The multi-block ciphers are used for transformations
|
||||
which operate on scatterlists of data supplied to the transformation
|
||||
functions. They output the result into a scatterlist of data as well.
|
||||
|
||||
Registration Specifics
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The registration of multi-block cipher algorithms is one of the most
|
||||
standard procedures throughout the crypto API.
|
||||
|
||||
Note, if a cipher implementation requires a proper alignment of data,
|
||||
the caller should use the functions of crypto_skcipher_alignmask() to
|
||||
identify a memory alignment mask. The kernel crypto API is able to
|
||||
process requests that are unaligned. This implies, however, additional
|
||||
overhead as the kernel crypto API needs to perform the realignment of
|
||||
the data which may imply moving of data.
|
||||
|
||||
Cipher Definition With struct blkcipher_alg and ablkcipher_alg
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Struct blkcipher_alg defines a synchronous block cipher whereas struct
|
||||
ablkcipher_alg defines an asynchronous block cipher.
|
||||
|
||||
Please refer to the single block cipher description for schematics of
|
||||
the block cipher usage.
|
||||
|
||||
Specifics Of Asynchronous Multi-Block Cipher
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are a couple of specifics to the asynchronous interface.
|
||||
|
||||
First of all, some of the drivers will want to use the Generic
|
||||
ScatterWalk in case the hardware needs to be fed separate chunks of the
|
||||
scatterlist which contains the plaintext and will contain the
|
||||
ciphertext. Please refer to the ScatterWalk interface offered by the
|
||||
Linux kernel scatter / gather list implementation.
|
||||
|
||||
Hashing [HASH]
|
||||
--------------
|
||||
|
||||
Example of transformations: crc32, md5, sha1, sha256,...
|
||||
|
||||
Registering And Unregistering The Transformation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are multiple ways to register a HASH transformation, depending on
|
||||
whether the transformation is synchronous [SHASH] or asynchronous
|
||||
[AHASH] and the amount of HASH transformations we are registering. You
|
||||
can find the prototypes defined in include/crypto/internal/hash.h:
|
||||
|
||||
::
|
||||
|
||||
int crypto_register_ahash(struct ahash_alg *alg);
|
||||
|
||||
int crypto_register_shash(struct shash_alg *alg);
|
||||
int crypto_register_shashes(struct shash_alg *algs, int count);
|
||||
|
||||
|
||||
The respective counterparts for unregistering the HASH transformation
|
||||
are as follows:
|
||||
|
||||
::
|
||||
|
||||
int crypto_unregister_ahash(struct ahash_alg *alg);
|
||||
|
||||
int crypto_unregister_shash(struct shash_alg *alg);
|
||||
int crypto_unregister_shashes(struct shash_alg *algs, int count);
|
||||
|
||||
|
||||
Cipher Definition With struct shash_alg and ahash_alg
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Here are schematics of how these functions are called when operated from
|
||||
other part of the kernel. Note that the .setkey() call might happen
|
||||
before or after any of these schematics happen, but must not happen
|
||||
during any of these are in-flight. Please note that calling .init()
|
||||
followed immediately by .finish() is also a perfectly valid
|
||||
transformation.
|
||||
|
||||
::
|
||||
|
||||
I) DATA -----------.
|
||||
v
|
||||
.init() -> .update() -> .final() ! .update() might not be called
|
||||
^ | | at all in this scenario.
|
||||
'----' '---> HASH
|
||||
|
||||
II) DATA -----------.-----------.
|
||||
v v
|
||||
.init() -> .update() -> .finup() ! .update() may not be called
|
||||
^ | | at all in this scenario.
|
||||
'----' '---> HASH
|
||||
|
||||
III) DATA -----------.
|
||||
v
|
||||
.digest() ! The entire process is handled
|
||||
| by the .digest() call.
|
||||
'---------------> HASH
|
||||
|
||||
|
||||
Here is a schematic of how the .export()/.import() functions are called
|
||||
when used from another part of the kernel.
|
||||
|
||||
::
|
||||
|
||||
KEY--. DATA--.
|
||||
v v ! .update() may not be called
|
||||
.setkey() -> .init() -> .update() -> .export() at all in this scenario.
|
||||
^ | |
|
||||
'-----' '--> PARTIAL_HASH
|
||||
|
||||
----------- other transformations happen here -----------
|
||||
|
||||
PARTIAL_HASH--. DATA1--.
|
||||
v v
|
||||
.import -> .update() -> .final() ! .update() may not be called
|
||||
^ | | at all in this scenario.
|
||||
'----' '--> HASH1
|
||||
|
||||
PARTIAL_HASH--. DATA2-.
|
||||
v v
|
||||
.import -> .finup()
|
||||
|
|
||||
'---------------> HASH2
|
||||
|
||||
|
||||
Specifics Of Asynchronous HASH Transformation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some of the drivers will want to use the Generic ScatterWalk in case the
|
||||
implementation needs to be fed separate chunks of the scatterlist which
|
||||
contains the input data. The buffer containing the resulting hash will
|
||||
always be properly aligned to .cra_alignmask so there is no need to
|
||||
worry about this.
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
=======================
|
||||
Linux Kernel Crypto API
|
||||
=======================
|
||||
|
||||
:Author: Stephan Mueller
|
||||
:Author: Marek Vasut
|
||||
|
||||
This documentation outlines the Linux kernel crypto API with its
|
||||
concepts, details about developing cipher implementations, employment of the API
|
||||
for cryptographic use cases, as well as programming examples.
|
||||
|
||||
.. class:: toc-title
|
||||
|
||||
Table of contents
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
intro
|
||||
architecture
|
||||
devel-algos
|
||||
userspace-if
|
||||
api
|
||||
api-samples
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
Kernel Crypto API Interface Specification
|
||||
=========================================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The kernel crypto API offers a rich set of cryptographic ciphers as well
|
||||
as other data transformation mechanisms and methods to invoke these.
|
||||
This document contains a description of the API and provides example
|
||||
code.
|
||||
|
||||
To understand and properly use the kernel crypto API a brief explanation
|
||||
of its structure is given. Based on the architecture, the API can be
|
||||
separated into different components. Following the architecture
|
||||
specification, hints to developers of ciphers are provided. Pointers to
|
||||
the API function call documentation are given at the end.
|
||||
|
||||
The kernel crypto API refers to all algorithms as "transformations".
|
||||
Therefore, a cipher handle variable usually has the name "tfm". Besides
|
||||
cryptographic operations, the kernel crypto API also knows compression
|
||||
transformations and handles them the same way as ciphers.
|
||||
|
||||
The kernel crypto API serves the following entity types:
|
||||
|
||||
- consumers requesting cryptographic services
|
||||
|
||||
- data transformation implementations (typically ciphers) that can be
|
||||
called by consumers using the kernel crypto API
|
||||
|
||||
This specification is intended for consumers of the kernel crypto API as
|
||||
well as for developers implementing ciphers. This API specification,
|
||||
however, does not discuss all API calls available to data transformation
|
||||
implementations (i.e. implementations of ciphers and other
|
||||
transformations (such as CRC or even compression algorithms) that can
|
||||
register with the kernel crypto API).
|
||||
|
||||
Note: The terms "transformation" and cipher algorithm are used
|
||||
interchangeably.
|
||||
|
||||
Terminology
|
||||
-----------
|
||||
|
||||
The transformation implementation is an actual code or interface to
|
||||
hardware which implements a certain transformation with precisely
|
||||
defined behavior.
|
||||
|
||||
The transformation object (TFM) is an instance of a transformation
|
||||
implementation. There can be multiple transformation objects associated
|
||||
with a single transformation implementation. Each of those
|
||||
transformation objects is held by a crypto API consumer or another
|
||||
transformation. Transformation object is allocated when a crypto API
|
||||
consumer requests a transformation implementation. The consumer is then
|
||||
provided with a structure, which contains a transformation object (TFM).
|
||||
|
||||
The structure that contains transformation objects may also be referred
|
||||
to as a "cipher handle". Such a cipher handle is always subject to the
|
||||
following phases that are reflected in the API calls applicable to such
|
||||
a cipher handle:
|
||||
|
||||
1. Initialization of a cipher handle.
|
||||
|
||||
2. Execution of all intended cipher operations applicable for the handle
|
||||
where the cipher handle must be furnished to every API call.
|
||||
|
||||
3. Destruction of a cipher handle.
|
||||
|
||||
When using the initialization API calls, a cipher handle is created and
|
||||
returned to the consumer. Therefore, please refer to all initialization
|
||||
API calls that refer to the data structure type a consumer is expected
|
||||
to receive and subsequently to use. The initialization API calls have
|
||||
all the same naming conventions of crypto_alloc\*.
|
||||
|
||||
The transformation context is private data associated with the
|
||||
transformation object.
|
||||
|
|
@ -0,0 +1,387 @@
|
|||
User Space Interface
|
||||
====================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The concepts of the kernel crypto API visible to kernel space is fully
|
||||
applicable to the user space interface as well. Therefore, the kernel
|
||||
crypto API high level discussion for the in-kernel use cases applies
|
||||
here as well.
|
||||
|
||||
The major difference, however, is that user space can only act as a
|
||||
consumer and never as a provider of a transformation or cipher
|
||||
algorithm.
|
||||
|
||||
The following covers the user space interface exported by the kernel
|
||||
crypto API. A working example of this description is libkcapi that can
|
||||
be obtained from [1]. That library can be used by user space
|
||||
applications that require cryptographic services from the kernel.
|
||||
|
||||
Some details of the in-kernel kernel crypto API aspects do not apply to
|
||||
user space, however. This includes the difference between synchronous
|
||||
and asynchronous invocations. The user space API call is fully
|
||||
synchronous.
|
||||
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
|
||||
User Space API General Remarks
|
||||
------------------------------
|
||||
|
||||
The kernel crypto API is accessible from user space. Currently, the
|
||||
following ciphers are accessible:
|
||||
|
||||
- Message digest including keyed message digest (HMAC, CMAC)
|
||||
|
||||
- Symmetric ciphers
|
||||
|
||||
- AEAD ciphers
|
||||
|
||||
- Random Number Generators
|
||||
|
||||
The interface is provided via socket type using the type AF_ALG. In
|
||||
addition, the setsockopt option type is SOL_ALG. In case the user space
|
||||
header files do not export these flags yet, use the following macros:
|
||||
|
||||
::
|
||||
|
||||
#ifndef AF_ALG
|
||||
#define AF_ALG 38
|
||||
#endif
|
||||
#ifndef SOL_ALG
|
||||
#define SOL_ALG 279
|
||||
#endif
|
||||
|
||||
|
||||
A cipher is accessed with the same name as done for the in-kernel API
|
||||
calls. This includes the generic vs. unique naming schema for ciphers as
|
||||
well as the enforcement of priorities for generic names.
|
||||
|
||||
To interact with the kernel crypto API, a socket must be created by the
|
||||
user space application. User space invokes the cipher operation with the
|
||||
send()/write() system call family. The result of the cipher operation is
|
||||
obtained with the read()/recv() system call family.
|
||||
|
||||
The following API calls assume that the socket descriptor is already
|
||||
opened by the user space application and discusses only the kernel
|
||||
crypto API specific invocations.
|
||||
|
||||
To initialize the socket interface, the following sequence has to be
|
||||
performed by the consumer:
|
||||
|
||||
1. Create a socket of type AF_ALG with the struct sockaddr_alg
|
||||
parameter specified below for the different cipher types.
|
||||
|
||||
2. Invoke bind with the socket descriptor
|
||||
|
||||
3. Invoke accept with the socket descriptor. The accept system call
|
||||
returns a new file descriptor that is to be used to interact with the
|
||||
particular cipher instance. When invoking send/write or recv/read
|
||||
system calls to send data to the kernel or obtain data from the
|
||||
kernel, the file descriptor returned by accept must be used.
|
||||
|
||||
In-place Cipher operation
|
||||
-------------------------
|
||||
|
||||
Just like the in-kernel operation of the kernel crypto API, the user
|
||||
space interface allows the cipher operation in-place. That means that
|
||||
the input buffer used for the send/write system call and the output
|
||||
buffer used by the read/recv system call may be one and the same. This
|
||||
is of particular interest for symmetric cipher operations where a
|
||||
copying of the output data to its final destination can be avoided.
|
||||
|
||||
If a consumer on the other hand wants to maintain the plaintext and the
|
||||
ciphertext in different memory locations, all a consumer needs to do is
|
||||
to provide different memory pointers for the encryption and decryption
|
||||
operation.
|
||||
|
||||
Message Digest API
|
||||
------------------
|
||||
|
||||
The message digest type to be used for the cipher operation is selected
|
||||
when invoking the bind syscall. bind requires the caller to provide a
|
||||
filled struct sockaddr data structure. This data structure must be
|
||||
filled as follows:
|
||||
|
||||
::
|
||||
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "hash", /* this selects the hash logic in the kernel */
|
||||
.salg_name = "sha1" /* this is the cipher name */
|
||||
};
|
||||
|
||||
|
||||
The salg_type value "hash" applies to message digests and keyed message
|
||||
digests. Though, a keyed message digest is referenced by the appropriate
|
||||
salg_name. Please see below for the setsockopt interface that explains
|
||||
how the key can be set for a keyed message digest.
|
||||
|
||||
Using the send() system call, the application provides the data that
|
||||
should be processed with the message digest. The send system call allows
|
||||
the following flags to be specified:
|
||||
|
||||
- MSG_MORE: If this flag is set, the send system call acts like a
|
||||
message digest update function where the final hash is not yet
|
||||
calculated. If the flag is not set, the send system call calculates
|
||||
the final message digest immediately.
|
||||
|
||||
With the recv() system call, the application can read the message digest
|
||||
from the kernel crypto API. If the buffer is too small for the message
|
||||
digest, the flag MSG_TRUNC is set by the kernel.
|
||||
|
||||
In order to set a message digest key, the calling application must use
|
||||
the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
|
||||
operation is performed without the initial HMAC state change caused by
|
||||
the key.
|
||||
|
||||
Symmetric Cipher API
|
||||
--------------------
|
||||
|
||||
The operation is very similar to the message digest discussion. During
|
||||
initialization, the struct sockaddr data structure must be filled as
|
||||
follows:
|
||||
|
||||
::
|
||||
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "skcipher", /* this selects the symmetric cipher */
|
||||
.salg_name = "cbc(aes)" /* this is the cipher name */
|
||||
};
|
||||
|
||||
|
||||
Before data can be sent to the kernel using the write/send system call
|
||||
family, the consumer must set the key. The key setting is described with
|
||||
the setsockopt invocation below.
|
||||
|
||||
Using the sendmsg() system call, the application provides the data that
|
||||
should be processed for encryption or decryption. In addition, the IV is
|
||||
specified with the data structure provided by the sendmsg() system call.
|
||||
|
||||
The sendmsg system call parameter of struct msghdr is embedded into the
|
||||
struct cmsghdr data structure. See recv(2) and cmsg(3) for more
|
||||
information on how the cmsghdr data structure is used together with the
|
||||
send/recv system call family. That cmsghdr data structure holds the
|
||||
following information specified with a separate header instances:
|
||||
|
||||
- specification of the cipher operation type with one of these flags:
|
||||
|
||||
- ALG_OP_ENCRYPT - encryption of data
|
||||
|
||||
- ALG_OP_DECRYPT - decryption of data
|
||||
|
||||
- specification of the IV information marked with the flag ALG_SET_IV
|
||||
|
||||
The send system call family allows the following flag to be specified:
|
||||
|
||||
- MSG_MORE: If this flag is set, the send system call acts like a
|
||||
cipher update function where more input data is expected with a
|
||||
subsequent invocation of the send system call.
|
||||
|
||||
Note: The kernel reports -EINVAL for any unexpected data. The caller
|
||||
must make sure that all data matches the constraints given in
|
||||
/proc/crypto for the selected cipher.
|
||||
|
||||
With the recv() system call, the application can read the result of the
|
||||
cipher operation from the kernel crypto API. The output buffer must be
|
||||
at least as large as to hold all blocks of the encrypted or decrypted
|
||||
data. If the output data size is smaller, only as many blocks are
|
||||
returned that fit into that output buffer size.
|
||||
|
||||
AEAD Cipher API
|
||||
---------------
|
||||
|
||||
The operation is very similar to the symmetric cipher discussion. During
|
||||
initialization, the struct sockaddr data structure must be filled as
|
||||
follows:
|
||||
|
||||
::
|
||||
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "aead", /* this selects the symmetric cipher */
|
||||
.salg_name = "gcm(aes)" /* this is the cipher name */
|
||||
};
|
||||
|
||||
|
||||
Before data can be sent to the kernel using the write/send system call
|
||||
family, the consumer must set the key. The key setting is described with
|
||||
the setsockopt invocation below.
|
||||
|
||||
In addition, before data can be sent to the kernel using the write/send
|
||||
system call family, the consumer must set the authentication tag size.
|
||||
To set the authentication tag size, the caller must use the setsockopt
|
||||
invocation described below.
|
||||
|
||||
Using the sendmsg() system call, the application provides the data that
|
||||
should be processed for encryption or decryption. In addition, the IV is
|
||||
specified with the data structure provided by the sendmsg() system call.
|
||||
|
||||
The sendmsg system call parameter of struct msghdr is embedded into the
|
||||
struct cmsghdr data structure. See recv(2) and cmsg(3) for more
|
||||
information on how the cmsghdr data structure is used together with the
|
||||
send/recv system call family. That cmsghdr data structure holds the
|
||||
following information specified with a separate header instances:
|
||||
|
||||
- specification of the cipher operation type with one of these flags:
|
||||
|
||||
- ALG_OP_ENCRYPT - encryption of data
|
||||
|
||||
- ALG_OP_DECRYPT - decryption of data
|
||||
|
||||
- specification of the IV information marked with the flag ALG_SET_IV
|
||||
|
||||
- specification of the associated authentication data (AAD) with the
|
||||
flag ALG_SET_AEAD_ASSOCLEN. The AAD is sent to the kernel together
|
||||
with the plaintext / ciphertext. See below for the memory structure.
|
||||
|
||||
The send system call family allows the following flag to be specified:
|
||||
|
||||
- MSG_MORE: If this flag is set, the send system call acts like a
|
||||
cipher update function where more input data is expected with a
|
||||
subsequent invocation of the send system call.
|
||||
|
||||
Note: The kernel reports -EINVAL for any unexpected data. The caller
|
||||
must make sure that all data matches the constraints given in
|
||||
/proc/crypto for the selected cipher.
|
||||
|
||||
With the recv() system call, the application can read the result of the
|
||||
cipher operation from the kernel crypto API. The output buffer must be
|
||||
at least as large as defined with the memory structure below. If the
|
||||
output data size is smaller, the cipher operation is not performed.
|
||||
|
||||
The authenticated decryption operation may indicate an integrity error.
|
||||
Such breach in integrity is marked with the -EBADMSG error code.
|
||||
|
||||
AEAD Memory Structure
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The AEAD cipher operates with the following information that is
|
||||
communicated between user and kernel space as one data stream:
|
||||
|
||||
- plaintext or ciphertext
|
||||
|
||||
- associated authentication data (AAD)
|
||||
|
||||
- authentication tag
|
||||
|
||||
The sizes of the AAD and the authentication tag are provided with the
|
||||
sendmsg and setsockopt calls (see there). As the kernel knows the size
|
||||
of the entire data stream, the kernel is now able to calculate the right
|
||||
offsets of the data components in the data stream.
|
||||
|
||||
The user space caller must arrange the aforementioned information in the
|
||||
following order:
|
||||
|
||||
- AEAD encryption input: AAD \|\| plaintext
|
||||
|
||||
- AEAD decryption input: AAD \|\| ciphertext \|\| authentication tag
|
||||
|
||||
The output buffer the user space caller provides must be at least as
|
||||
large to hold the following data:
|
||||
|
||||
- AEAD encryption output: ciphertext \|\| authentication tag
|
||||
|
||||
- AEAD decryption output: plaintext
|
||||
|
||||
Random Number Generator API
|
||||
---------------------------
|
||||
|
||||
Again, the operation is very similar to the other APIs. During
|
||||
initialization, the struct sockaddr data structure must be filled as
|
||||
follows:
|
||||
|
||||
::
|
||||
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "rng", /* this selects the symmetric cipher */
|
||||
.salg_name = "drbg_nopr_sha256" /* this is the cipher name */
|
||||
};
|
||||
|
||||
|
||||
Depending on the RNG type, the RNG must be seeded. The seed is provided
|
||||
using the setsockopt interface to set the key. For example, the
|
||||
ansi_cprng requires a seed. The DRBGs do not require a seed, but may be
|
||||
seeded.
|
||||
|
||||
Using the read()/recvmsg() system calls, random numbers can be obtained.
|
||||
The kernel generates at most 128 bytes in one call. If user space
|
||||
requires more data, multiple calls to read()/recvmsg() must be made.
|
||||
|
||||
WARNING: The user space caller may invoke the initially mentioned accept
|
||||
system call multiple times. In this case, the returned file descriptors
|
||||
have the same state.
|
||||
|
||||
Zero-Copy Interface
|
||||
-------------------
|
||||
|
||||
In addition to the send/write/read/recv system call family, the AF_ALG
|
||||
interface can be accessed with the zero-copy interface of
|
||||
splice/vmsplice. As the name indicates, the kernel tries to avoid a copy
|
||||
operation into kernel space.
|
||||
|
||||
The zero-copy operation requires data to be aligned at the page
|
||||
boundary. Non-aligned data can be used as well, but may require more
|
||||
operations of the kernel which would defeat the speed gains obtained
|
||||
from the zero-copy interface.
|
||||
|
||||
The system-interent limit for the size of one zero-copy operation is 16
|
||||
pages. If more data is to be sent to AF_ALG, user space must slice the
|
||||
input into segments with a maximum size of 16 pages.
|
||||
|
||||
Zero-copy can be used with the following code example (a complete
|
||||
working example is provided with libkcapi):
|
||||
|
||||
::
|
||||
|
||||
int pipes[2];
|
||||
|
||||
pipe(pipes);
|
||||
/* input data in iov */
|
||||
vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
|
||||
/* opfd is the file descriptor returned from accept() system call */
|
||||
splice(pipes[0], NULL, opfd, NULL, ret, 0);
|
||||
read(opfd, out, outlen);
|
||||
|
||||
|
||||
Setsockopt Interface
|
||||
--------------------
|
||||
|
||||
In addition to the read/recv and send/write system call handling to send
|
||||
and retrieve data subject to the cipher operation, a consumer also needs
|
||||
to set the additional information for the cipher operation. This
|
||||
additional information is set using the setsockopt system call that must
|
||||
be invoked with the file descriptor of the open cipher (i.e. the file
|
||||
descriptor returned by the accept system call).
|
||||
|
||||
Each setsockopt invocation must use the level SOL_ALG.
|
||||
|
||||
The setsockopt interface allows setting the following data using the
|
||||
mentioned optname:
|
||||
|
||||
- ALG_SET_KEY -- Setting the key. Key setting is applicable to:
|
||||
|
||||
- the skcipher cipher type (symmetric ciphers)
|
||||
|
||||
- the hash cipher type (keyed message digests)
|
||||
|
||||
- the AEAD cipher type
|
||||
|
||||
- the RNG cipher type to provide the seed
|
||||
|
||||
- ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size for
|
||||
AEAD ciphers. For a encryption operation, the authentication tag of
|
||||
the given size will be generated. For a decryption operation, the
|
||||
provided ciphertext is assumed to contain an authentication tag of
|
||||
the given size (see section about AEAD memory layout below).
|
||||
|
||||
User space API example
|
||||
----------------------
|
||||
|
||||
Please see [1] for libkcapi which provides an easy-to-use wrapper around
|
||||
the aforementioned Netlink kernel interface. [1] also contains a test
|
||||
application that invokes all libkcapi API calls.
|
||||
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
|
|
@ -51,13 +51,6 @@ sure that bitwise types don't get mixed up (little-endian vs big-endian
|
|||
vs cpu-endian vs whatever), and there the constant "0" really _is_
|
||||
special.
|
||||
|
||||
__bitwise__ - to be used for relatively compact stuff (gfp_t, etc.) that
|
||||
is mostly warning-free and is supposed to stay that way. Warnings will
|
||||
be generated without __CHECK_ENDIAN__.
|
||||
|
||||
__bitwise - noisy stuff; in particular, __le*/__be* are that. We really
|
||||
don't want to drown in noise unless we'd explicitly asked for it.
|
||||
|
||||
Using sparse for lock checking
|
||||
------------------------------
|
||||
|
||||
|
|
@ -109,9 +102,4 @@ be recompiled or not. The latter is a fast way to check the whole tree if you
|
|||
have already built it.
|
||||
|
||||
The optional make variable CF can be used to pass arguments to sparse. The
|
||||
build system passes -Wbitwise to sparse automatically. To perform endianness
|
||||
checks, you may define __CHECK_ENDIAN__::
|
||||
|
||||
make C=2 CF="-D__CHECK_ENDIAN__"
|
||||
|
||||
These checks are disabled by default as they generate a host of warnings.
|
||||
build system passes -Wbitwise to sparse automatically.
|
||||
|
|
|
|||
|
|
@ -16,12 +16,12 @@ Example scripts
|
|||
[[
|
||||
#!/bin/sh
|
||||
# Create device delaying rw operation for 500ms
|
||||
echo "0 `blockdev --getsize $1` delay $1 0 500" | dmsetup create delayed
|
||||
echo "0 `blockdev --getsz $1` delay $1 0 500" | dmsetup create delayed
|
||||
]]
|
||||
|
||||
[[
|
||||
#!/bin/sh
|
||||
# Create device delaying only write operation for 500ms and
|
||||
# splitting reads and writes to different devices $1 $2
|
||||
echo "0 `blockdev --getsize $1` delay $1 0 0 $2 0 500" | dmsetup create delayed
|
||||
echo "0 `blockdev --getsz $1` delay $1 0 0 $2 0 500" | dmsetup create delayed
|
||||
]]
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ https://gitlab.com/cryptsetup/cryptsetup
|
|||
[[
|
||||
#!/bin/sh
|
||||
# Create a crypt device using dmsetup
|
||||
dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
|
||||
dmsetup create crypt1 --table "0 `blockdev --getsz $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
|
||||
]]
|
||||
|
||||
[[
|
||||
|
|
|
|||
|
|
@ -16,15 +16,15 @@ Example scripts
|
|||
[[
|
||||
#!/bin/sh
|
||||
# Create an identity mapping for a device
|
||||
echo "0 `blockdev --getsize $1` linear $1 0" | dmsetup create identity
|
||||
echo "0 `blockdev --getsz $1` linear $1 0" | dmsetup create identity
|
||||
]]
|
||||
|
||||
|
||||
[[
|
||||
#!/bin/sh
|
||||
# Join 2 devices together
|
||||
size1=`blockdev --getsize $1`
|
||||
size2=`blockdev --getsize $2`
|
||||
size1=`blockdev --getsz $1`
|
||||
size2=`blockdev --getsz $2`
|
||||
echo "0 $size1 linear $1 0
|
||||
$size1 $size2 linear $2 0" | dmsetup create joined
|
||||
]]
|
||||
|
|
@ -44,7 +44,7 @@ if (!defined($dev)) {
|
|||
die("Please specify a device.\n");
|
||||
}
|
||||
|
||||
my $dev_size = `blockdev --getsize $dev`;
|
||||
my $dev_size = `blockdev --getsz $dev`;
|
||||
my $extents = int($dev_size / $extent_size) -
|
||||
(($dev_size % $extent_size) ? 1 : 0);
|
||||
|
||||
|
|
|
|||
|
|
@ -37,9 +37,9 @@ if (!$num_devs) {
|
|||
die("Specify at least one device\n");
|
||||
}
|
||||
|
||||
$min_dev_size = `blockdev --getsize $devs[0]`;
|
||||
$min_dev_size = `blockdev --getsz $devs[0]`;
|
||||
for ($i = 1; $i < $num_devs; $i++) {
|
||||
my $this_size = `blockdev --getsize $devs[$i]`;
|
||||
my $this_size = `blockdev --getsz $devs[$i]`;
|
||||
$min_dev_size = ($min_dev_size < $this_size) ?
|
||||
$min_dev_size : $this_size;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ Assume that you have volumes vg1/switch0 vg1/switch1 vg1/switch2 with
|
|||
the same size.
|
||||
|
||||
Create a switch device with 64kB region size:
|
||||
dmsetup create switch --table "0 `blockdev --getsize /dev/vg1/switch0`
|
||||
dmsetup create switch --table "0 `blockdev --getsz /dev/vg1/switch0`
|
||||
switch 3 128 0 /dev/vg1/switch0 0 /dev/vg1/switch1 0 /dev/vg1/switch2 0"
|
||||
|
||||
Set mappings for the first 7 entries to point to devices switch0, switch1,
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
System Control and Power Interface (SCPI) Message Protocol
|
||||
(in addition to the standard binding in [0])
|
||||
----------------------------------------------------------
|
||||
Required properties
|
||||
|
||||
- compatible : should be "amlogic,meson-gxbb-scpi"
|
||||
|
||||
AMLOGIC SRAM and Shared Memory for SCPI
|
||||
------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "amlogic,meson-gxbb-sram"
|
||||
|
||||
Each sub-node represents the reserved area for SCPI.
|
||||
|
||||
Required sub-node properties:
|
||||
- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
|
||||
memory on Amlogic GXBB SoC.
|
||||
|
||||
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
|
||||
|
|
@ -17,6 +17,18 @@ Boards with the Amlogic Meson GXBaby SoC shall have the following properties:
|
|||
Required root node property:
|
||||
compatible: "amlogic,meson-gxbb";
|
||||
|
||||
Boards with the Amlogic Meson GXL S905X SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,s905x", "amlogic,meson-gxl";
|
||||
|
||||
Boards with the Amlogic Meson GXL S905D SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,s905d", "amlogic,meson-gxl";
|
||||
|
||||
Boards with the Amlogic Meson GXM S912 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,s912", "amlogic,meson-gxm";
|
||||
|
||||
Board compatible values:
|
||||
- "geniatech,atv1200" (Meson6)
|
||||
- "minix,neo-x8" (Meson8)
|
||||
|
|
@ -28,3 +40,10 @@ Board compatible values:
|
|||
- "hardkernel,odroid-c2" (Meson gxbb)
|
||||
- "amlogic,p200" (Meson gxbb)
|
||||
- "amlogic,p201" (Meson gxbb)
|
||||
- "amlogic,p212" (Meson gxl s905x)
|
||||
- "amlogic,p230" (Meson gxl s905d)
|
||||
- "amlogic,p231" (Meson gxl s905d)
|
||||
- "amlogic,q200" (Meson gxm s912)
|
||||
- "amlogic,q201" (Meson gxm s912)
|
||||
- "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
|
||||
- "nexbox,a1" (Meson gxm s912)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,10 @@ by Linux to initiate various system control and power operations.
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "arm,scpi"
|
||||
- compatible : should be
|
||||
* "arm,scpi" : For implementations complying to SCPI v1.0 or above
|
||||
* "arm,scpi-pre-1.0" : For implementations complying to all
|
||||
unversioned releases prior to SCPI v1.0
|
||||
- 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
|
||||
|
|
@ -59,18 +62,14 @@ 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 ../../sram/sram.txt
|
||||
The properties should follow the generic mmio-sram description found in [3]
|
||||
|
||||
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
|
||||
- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
|
||||
shared memory
|
||||
|
||||
Sensor bindings for the sensors based on SCPI Message Protocol
|
||||
--------------------------------------------------------------
|
||||
|
|
@ -81,11 +80,9 @@ Required properties:
|
|||
- #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].
|
||||
Valid cell values are raw identifiers (Sensor ID)
|
||||
as used by the firmware. Refer to platform details
|
||||
for your implementation for the IDs to use.
|
||||
|
||||
Power domain bindings for the power domains based on SCPI Message Protocol
|
||||
------------------------------------------------------------
|
||||
|
|
@ -112,7 +109,7 @@ Required properties:
|
|||
[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
|
||||
[3] Documentation/devicetree/bindings/sram/sram.txt
|
||||
[4] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -148,11 +148,12 @@ Example:
|
|||
|
||||
/dts-v1/;
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include "skeleton.dtsi"
|
||||
|
||||
/ {
|
||||
model = "ARM RealView PB1176 with device tree";
|
||||
compatible = "arm,realview-pb1176";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
soc {
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -225,3 +225,19 @@ required properties:
|
|||
compatible = "atmel,sama5d3-sfr", "syscon";
|
||||
reg = <0xf0038000 0x60>;
|
||||
};
|
||||
|
||||
Security Module (SECUMOD)
|
||||
|
||||
The Security Module macrocell provides all necessary secure functions to avoid
|
||||
voltage, temperature, frequency and mechanical attacks on the chip. It also
|
||||
embeds secure memories that can be scrambled
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-secumod", "syscon".
|
||||
<chip> can be "sama5d2".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
secumod@fc040000 {
|
||||
compatible = "atmel,sama5d2-secumod", "syscon";
|
||||
reg = <0xfc040000 0x100>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -178,6 +178,7 @@ nodes to be present and contain the properties described below.
|
|||
"marvell,pj4b"
|
||||
"marvell,sheeva-v5"
|
||||
"nvidia,tegra132-denver"
|
||||
"nvidia,tegra186-denver"
|
||||
"qcom,krait"
|
||||
"qcom,kryo"
|
||||
"qcom,scorpion"
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ Freescale LS1021A Platform Device Tree Bindings
|
|||
Required root node compatible properties:
|
||||
- compatible = "fsl,ls1021a";
|
||||
|
||||
Freescale LS1021A SoC-specific Device Tree Bindings
|
||||
Freescale SoC-specific Device Tree Bindings
|
||||
-------------------------------------------
|
||||
|
||||
Freescale SCFG
|
||||
|
|
@ -105,7 +105,11 @@ Freescale SCFG
|
|||
configuration and status registers for the chip. Such as getting PEX port
|
||||
status.
|
||||
Required properties:
|
||||
- compatible: should be "fsl,ls1021a-scfg"
|
||||
- compatible: Should contain a chip-specific compatible string,
|
||||
Chip-specific strings are of the form "fsl,<chip>-scfg",
|
||||
The following <chip>s are known to be supported:
|
||||
ls1021a, ls1043a, ls1046a, ls2080a.
|
||||
|
||||
- reg: should contain base address and length of SCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
|
|
@ -119,7 +123,11 @@ Freescale DCFG
|
|||
configuration and status for the device. Such as setting the secondary
|
||||
core start address and release the secondary core from holdoff and startup.
|
||||
Required properties:
|
||||
- compatible: should be "fsl,ls1021a-dcfg"
|
||||
- compatible: Should contain a chip-specific compatible string,
|
||||
Chip-specific strings are of the form "fsl,<chip>-dcfg",
|
||||
The following <chip>s are known to be supported:
|
||||
ls1021a, ls1043a, ls1046a, ls2080a.
|
||||
|
||||
- reg : should contain base address and length of DCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
|
|
@ -131,6 +139,10 @@ Example:
|
|||
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
|
||||
----------------------------------------------------------------
|
||||
|
||||
LS1043A SoC
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls1043a";
|
||||
|
||||
LS1043A ARMv8 based RDB Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls1043a-rdb", "fsl,ls1043a";
|
||||
|
|
@ -139,6 +151,22 @@ LS1043A ARMv8 based QDS Board
|
|||
Required root node properties:
|
||||
- compatible = "fsl,ls1043a-qds", "fsl,ls1043a";
|
||||
|
||||
LS1046A SoC
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls1046a";
|
||||
|
||||
LS1046A ARMv8 based QDS Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls1046a-qds", "fsl,ls1046a";
|
||||
|
||||
LS1046A ARMv8 based RDB Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls1046a-rdb", "fsl,ls1046a";
|
||||
|
||||
LS2080A SoC
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls2080a";
|
||||
|
||||
LS2080A ARMv8 based Simulator model
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
|
||||
|
|
|
|||
|
|
@ -28,6 +28,10 @@ HiP06 D03 Board
|
|||
Required root node properties:
|
||||
- compatible = "hisilicon,hip06-d03";
|
||||
|
||||
HiP07 D05 Board
|
||||
Required root node properties:
|
||||
- compatible = "hisilicon,hip07-d05";
|
||||
|
||||
Hisilicon system controller
|
||||
|
||||
Required properties:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
System Control and Power Interface (SCPI) Message Protocol
|
||||
(in addition to the standard binding in [0])
|
||||
|
||||
Juno SRAM and Shared Memory for SCPI
|
||||
------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
|
||||
|
||||
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
|
||||
--------------------------------------------------------------
|
||||
Required properties:
|
||||
- compatible : should be "arm,scpi-sensors".
|
||||
- #thermal-sensor-cells: should be set to 1.
|
||||
For Juno R0 and Juno R1 refer to [1] for the
|
||||
sensor identifiers
|
||||
|
||||
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
|
||||
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
Texas Instruments System Control Interface (TI-SCI) Message Protocol
|
||||
--------------------------------------------------------------------
|
||||
|
||||
Texas Instrument's processors including those belonging to Keystone generation
|
||||
of processors have separate hardware entity which is now responsible for the
|
||||
management of the System on Chip (SoC) system. These include various system
|
||||
level functions as well.
|
||||
|
||||
An example of such an SoC is K2G, which contains the system control hardware
|
||||
block called Power Management Micro Controller (PMMC). This hardware block is
|
||||
initialized early into boot process and provides services to Operating Systems
|
||||
on multiple processors including ones running Linux.
|
||||
|
||||
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
|
||||
|
||||
TI-SCI controller Device Node:
|
||||
=============================
|
||||
|
||||
The TI-SCI node describes the Texas Instrument's System Controller entity node.
|
||||
This parent node may optionally have additional children nodes which describe
|
||||
specific functionality such as clocks, power domain, reset or additional
|
||||
functionality as may be required for the SoC. This hierarchy also describes the
|
||||
relationship between the TI-SCI parent node to the child node.
|
||||
|
||||
Required properties:
|
||||
-------------------
|
||||
- compatible: should be "ti,k2g-sci"
|
||||
- mbox-names:
|
||||
"rx" - Mailbox corresponding to receive path
|
||||
"tx" - Mailbox corresponding to transmit path
|
||||
|
||||
- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
|
||||
property should contain a phandle to the mailbox controller device
|
||||
node and an args specifier that will be the phandle to the intended
|
||||
sub-mailbox child node to be used for communication.
|
||||
|
||||
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
|
||||
about the generic mailbox controller and client driver bindings. Also see
|
||||
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
|
||||
controller that is used to communicate with this System controllers.
|
||||
|
||||
Optional Properties:
|
||||
-------------------
|
||||
- reg-names:
|
||||
debug_messages - Map the Debug message region
|
||||
- reg: register space corresponding to the debug_messages
|
||||
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
|
||||
|
||||
Example (K2G):
|
||||
-------------
|
||||
pmmc: pmmc {
|
||||
compatible = "ti,k2g-sci";
|
||||
mbox-names = "rx", "tx";
|
||||
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
|
||||
<&msgmgr &msgmgr_proxy_pmmc_tx>;
|
||||
reg-names = "debug_messages";
|
||||
reg = <0x02921800 0x800>;
|
||||
};
|
||||
|
||||
|
||||
TI-SCI Client Device Node:
|
||||
=========================
|
||||
|
||||
Client nodes are maintained as children of the relevant TI-SCI device node.
|
||||
|
||||
Example (K2G):
|
||||
-------------
|
||||
pmmc: pmmc {
|
||||
compatible = "ti,k2g-sci";
|
||||
...
|
||||
|
||||
my_clk_node: clk_node {
|
||||
...
|
||||
...
|
||||
};
|
||||
|
||||
my_pd_node: pd_node {
|
||||
...
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -86,6 +86,9 @@ SoCs:
|
|||
- DRA722
|
||||
compatible = "ti,dra722", "ti,dra72", "ti,dra7"
|
||||
|
||||
- DRA718
|
||||
compatible = "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
|
||||
|
||||
- AM5728
|
||||
compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
|
|
@ -175,12 +178,18 @@ Boards:
|
|||
- AM5728 IDK
|
||||
compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
- AM5718 IDK
|
||||
compatible = "ti,am5718-idk", "ti,am5718", "ti,dra7"
|
||||
|
||||
- DRA742 EVM: Software Development Board for DRA742
|
||||
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
- DRA722 EVM: Software Development Board for DRA722
|
||||
compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7"
|
||||
|
||||
- DRA718 EVM: Software Development Board for DRA718
|
||||
compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
|
||||
|
||||
- DM3730 Logic PD Torpedo + Wireless: Commercial System on Module with WiFi and Bluetooth
|
||||
compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following properties:
|
|||
Required root node property:
|
||||
compatible: "oxsemi,ox810se"
|
||||
|
||||
Boards with the OX820 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "oxsemi,ox820"
|
||||
|
||||
Board compatible values:
|
||||
- "wd,mbwe" (OX810SE)
|
||||
- "cloudengines,pogoplugv3" (OX820)
|
||||
|
|
|
|||
|
|
@ -21,7 +21,10 @@ The 'SoC' element must be one of the following strings:
|
|||
apq8096
|
||||
msm8916
|
||||
msm8974
|
||||
msm8992
|
||||
msm8994
|
||||
msm8996
|
||||
mdm9615
|
||||
|
||||
The 'board' element must be one of the following strings:
|
||||
|
||||
|
|
|
|||
|
|
@ -25,6 +25,10 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "radxa,rock2-square", "rockchip,rk3288";
|
||||
|
||||
- Rikomagic MK808 v1 board:
|
||||
Required root node properties:
|
||||
- compatible = "rikomagic,mk808", "rockchip,rk3066a";
|
||||
|
||||
- Firefly Firefly-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
|
||||
|
|
@ -99,6 +103,18 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "mqmaker,miqi", "rockchip,rk3288";
|
||||
|
||||
- Rockchip PX3 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
|
||||
|
||||
- Rockchip PX5 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
|
||||
|
||||
- Rockchip RK1108 Evaluation board
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
|
||||
|
||||
- Rockchip RK3368 evb:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
|
||||
|
|
|
|||
|
|
@ -15,6 +15,8 @@ Required root node properties:
|
|||
- "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,tm2" - for Exynos5433-based Samsung TM2 board.
|
||||
- "samsung,tm2e" - for Exynos5433-based Samsung TM2E board.
|
||||
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
|
||||
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
|
||||
|
||||
|
|
@ -22,6 +24,9 @@ Required root node properties:
|
|||
* FriendlyARM
|
||||
- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
|
||||
TINY4412 board.
|
||||
* TOPEET
|
||||
- "topeet,itop4412-elite" - for Exynos4412-based TOPEET
|
||||
Elite base board.
|
||||
|
||||
* Google
|
||||
- "google,pi" - for Exynos5800-based Google Peach Pi
|
||||
|
|
|
|||
|
|
@ -13,6 +13,10 @@ SoCs:
|
|||
compatible = "renesas,r8a73a4"
|
||||
- R-Mobile A1 (R8A77400)
|
||||
compatible = "renesas,r8a7740"
|
||||
- RZ/G1M (R8A77430)
|
||||
compatible = "renesas,r8a7743"
|
||||
- RZ/G1E (R8A77450)
|
||||
compatible = "renesas,r8a7745"
|
||||
- R-Car M1A (R8A77781)
|
||||
compatible = "renesas,r8a7778"
|
||||
- R-Car H1 (R8A77790)
|
||||
|
|
@ -35,7 +39,7 @@ SoCs:
|
|||
|
||||
Boards:
|
||||
|
||||
- Alt
|
||||
- Alt (RTP0RC7794SEB00010S)
|
||||
compatible = "renesas,alt", "renesas,r8a7794"
|
||||
- APE6-EVM
|
||||
compatible = "renesas,ape6evm", "renesas,r8a73a4"
|
||||
|
|
@ -47,9 +51,9 @@ Boards:
|
|||
compatible = "renesas,bockw", "renesas,r8a7778"
|
||||
- Genmai (RTK772100BC00000BR)
|
||||
compatible = "renesas,genmai", "renesas,r7s72100"
|
||||
- Gose
|
||||
- Gose (RTP0RC7793SEB00010S)
|
||||
compatible = "renesas,gose", "renesas,r8a7793"
|
||||
- H3ULCB (RTP0RC7795SKB00010S)
|
||||
- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
|
||||
compatible = "renesas,h3ulcb", "renesas,r8a7795";
|
||||
- Henninger
|
||||
compatible = "renesas,henninger", "renesas,r8a7791"
|
||||
|
|
@ -61,7 +65,9 @@ Boards:
|
|||
compatible = "renesas,kzm9g", "renesas,sh73a0"
|
||||
- Lager (RTP0RC7790SEB00010S)
|
||||
compatible = "renesas,lager", "renesas,r8a7790"
|
||||
- Marzen
|
||||
- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKB00010S)
|
||||
compatible = "renesas,m3ulcb", "renesas,r8a7796";
|
||||
- Marzen (R0P7779A00010S)
|
||||
compatible = "renesas,marzen", "renesas,r8a7779"
|
||||
- Porter (M2-LCDP)
|
||||
compatible = "renesas,porter", "renesas,r8a7791"
|
||||
|
|
@ -73,5 +79,27 @@ Boards:
|
|||
compatible = "renesas,salvator-x", "renesas,r8a7796";
|
||||
- SILK (RTP0RC7794LCB00011S)
|
||||
compatible = "renesas,silk", "renesas,r8a7794"
|
||||
- SK-RZG1E (YR8A77450S000BE)
|
||||
compatible = "renesas,sk-rzg1e", "renesas,r8a7745"
|
||||
- SK-RZG1M (YR8A77430S000BE)
|
||||
compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
|
||||
- Wheat
|
||||
compatible = "renesas,wheat", "renesas,r8a7792"
|
||||
|
||||
|
||||
Most Renesas ARM SoCs have a Product Register that allows to retrieve SoC
|
||||
product and revision information. If present, a device node for this register
|
||||
should be added.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "renesas,prr".
|
||||
- reg: Base address and length of the register block.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
prr: chipid@ff000044 {
|
||||
compatible = "renesas,prr";
|
||||
reg = <0 0xff000044 0 4>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -14,4 +14,5 @@ using one of the following compatible strings:
|
|||
allwinner,sun8i-a83t
|
||||
allwinner,sun8i-h3
|
||||
allwinner,sun9i-a80
|
||||
allwinner,sun50i-a64
|
||||
nextthing,gr8
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
Sierra Wireless Modules device tree bindings
|
||||
--------------------------------------------
|
||||
|
||||
Supported Modules :
|
||||
- WP8548 : Includes MDM9615 and PM8018 in a module
|
||||
|
||||
Sierra Wireless modules shall have the following properties :
|
||||
Required root node property
|
||||
- compatible: "swir,wp8548" for the WP8548 CF3 Module
|
||||
|
||||
Board compatible values:
|
||||
- "swir,mangoh-green-wp8548" for the mangOH green board with the WP8548 module
|
||||
|
|
@ -3,7 +3,7 @@ Binding for Freescale QorIQ AHCI SATA Controller
|
|||
Required properties:
|
||||
- reg: Physical base address and size of the controller's register area.
|
||||
- compatible: Compatibility string. Must be 'fsl,<chip>-ahci', where
|
||||
chip could be ls1021a, ls2080a, ls1043a etc.
|
||||
chip could be ls1021a, ls1043a, ls1046a, ls2080a etc.
|
||||
- clocks: Input clock specifier. Refer to common clock bindings.
|
||||
- interrupts: Interrupt specifier. Refer to interrupt binding.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,21 +18,6 @@ Optional properties:
|
|||
|
||||
Example:
|
||||
|
||||
/* Example for stih416 */
|
||||
sata0: sata@fe380000 {
|
||||
compatible = "st,ahci";
|
||||
reg = <0xfe380000 0x1000>;
|
||||
interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
|
||||
interrupt-names = "hostc";
|
||||
phys = <&phy_port0 PHY_TYPE_SATA>;
|
||||
phy-names = "ahci_phy";
|
||||
resets = <&powerdown STIH416_SATA0_POWERDOWN>,
|
||||
<&softreset STIH416_SATA0_SOFTRESET>;
|
||||
reset-names = "pwr-dwn", "sw-rst";
|
||||
clocks = <&clk_s_a0_ls CLK_ICN_REG>;
|
||||
clock-names = "ahci_clk";
|
||||
};
|
||||
|
||||
/* Example for stih407 family silicon */
|
||||
sata0: sata@9b20000 {
|
||||
compatible = "st,ahci";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,132 @@
|
|||
Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
|
||||
|
||||
The Generic Memory Interface bus enables memory transfers between internal and
|
||||
external memory. Can be used to attach various high speed devices such as
|
||||
synchronous/asynchronous NOR, FPGA, UARTS and more.
|
||||
|
||||
The actual devices are instantiated from the child nodes of a GMI node.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should contain one of the following:
|
||||
For Tegra20 must contain "nvidia,tegra20-gmi".
|
||||
For Tegra30 must contain "nvidia,tegra30-gmi".
|
||||
- reg: Should contain GMI controller registers location and length.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
- clock-names: Must include the following entries: "gmi"
|
||||
- resets : Must contain an entry for each entry in reset-names.
|
||||
- reset-names : Must include the following entries: "gmi"
|
||||
- #address-cells: The number of cells used to represent physical base
|
||||
addresses in the GMI address space. Should be 2.
|
||||
- #size-cells: The number of cells used to represent the size of an address
|
||||
range in the GMI address space. Should be 1.
|
||||
- ranges: Must be set up to reflect the memory layout with three integer values
|
||||
for each chip-select line in use (only one entry is supported, see below
|
||||
comments):
|
||||
<cs-number> <offset> <physical address of mapping> <size>
|
||||
|
||||
Note that the GMI controller does not have any internal chip-select address
|
||||
decoding, because of that chip-selects either need to be managed via software
|
||||
or by employing external chip-select decoding logic.
|
||||
|
||||
If external chip-select logic is used to support multiple devices it is assumed
|
||||
that the devices use the same timing and so are probably the same type. It also
|
||||
assumes that they can fit in the 256MB address range. In this case only one
|
||||
child device is supported which represents the active chip-select line, see
|
||||
examples for more insight.
|
||||
|
||||
The chip-select number is decoded from the child nodes second address cell of
|
||||
'ranges' property, if 'ranges' property is not present or empty chip-select will
|
||||
then be decoded from the first cell of the 'reg' property.
|
||||
|
||||
Optional child cs node properties:
|
||||
|
||||
- nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
|
||||
- nvidia,snor-mux-mode: Enable address/data MUX mode.
|
||||
- nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data.
|
||||
If omitted it will be asserted with data.
|
||||
- nvidia,snor-rdy-active-high: RDY signal is active high
|
||||
- nvidia,snor-adv-active-high: ADV signal is active high
|
||||
- nvidia,snor-oe-active-high: WE/OE signal is active high
|
||||
- nvidia,snor-cs-active-high: CS signal is active high
|
||||
|
||||
Note that there is some special handling for the timing values.
|
||||
From Tegra TRM:
|
||||
Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1
|
||||
|
||||
- nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the
|
||||
bus. Valid values are 0-15, default is 1
|
||||
- nvidia,snor-hold-width: Number of cycles CE stays asserted after the
|
||||
de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N
|
||||
(in case of MASTER Request). Valid values are 0-15, default is 1
|
||||
- nvidia,snor-adv-width: Number of cycles during which ADV stays asserted.
|
||||
Valid values are 0-15, default is 1.
|
||||
- nvidia,snor-ce-width: Number of cycles before CE is asserted.
|
||||
Valid values are 0-15, default is 4
|
||||
- nvidia,snor-we-width: Number of cycles during which WE stays asserted.
|
||||
Valid values are 0-15, default is 1
|
||||
- nvidia,snor-oe-width: Number of cycles during which OE stays asserted.
|
||||
Valid values are 0-255, default is 1
|
||||
- nvidia,snor-wait-width: Number of cycles before READY is asserted.
|
||||
Valid values are 0-255, default is 3
|
||||
|
||||
Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
|
||||
controllers with a simple-bus node since they are all connected to the same
|
||||
chip-select (CS4), in this example external address decoding is provided:
|
||||
|
||||
gmi@70090000 {
|
||||
compatible = "nvidia,tegra20-gmi";
|
||||
reg = <0x70009000 0x1000>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_NOR>;
|
||||
clock-names = "gmi";
|
||||
resets = <&tegra_car 42>;
|
||||
reset-names = "gmi";
|
||||
ranges = <4 0 0xd0000000 0xfffffff>;
|
||||
|
||||
status = "okay";
|
||||
|
||||
bus@4,0 {
|
||||
compatible = "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 4 0 0x40100>;
|
||||
|
||||
nvidia,snor-mux-mode;
|
||||
nvidia,snor-adv-active-high;
|
||||
|
||||
can@0 {
|
||||
reg = <0 0x100>;
|
||||
...
|
||||
};
|
||||
|
||||
can@40000 {
|
||||
reg = <0x40000 0x100>;
|
||||
...
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example with one SJA1000 CAN controller connected to the GMI bus
|
||||
on CS4:
|
||||
|
||||
gmi@70090000 {
|
||||
compatible = "nvidia,tegra20-gmi";
|
||||
reg = <0x70009000 0x1000>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_NOR>;
|
||||
clock-names = "gmi";
|
||||
resets = <&tegra_car 42>;
|
||||
reset-names = "gmi";
|
||||
ranges = <4 0 0xd0000000 0xfffffff>;
|
||||
|
||||
status = "okay";
|
||||
|
||||
can@4,0 {
|
||||
reg = <4 0 0x100>;
|
||||
nvidia,snor-mux-mode;
|
||||
nvidia,snor-adv-active-high;
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
* Device tree bindings for Texas Instruments da8xx master peripheral
|
||||
priority driver
|
||||
|
||||
DA8XX SoCs feature a set of registers allowing to change the priority of all
|
||||
peripherals classified as masters.
|
||||
|
||||
Documentation:
|
||||
OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "ti,da850-mstpri" - for da850 based boards
|
||||
- reg: offset and length of the mstpri registers
|
||||
|
||||
Example for da850-lcdk is shown below.
|
||||
|
||||
mstpri {
|
||||
compatible = "ti,da850-mstpri";
|
||||
reg = <0x14110 0x0c>;
|
||||
};
|
||||
|
|
@ -77,7 +77,7 @@ Examples:
|
|||
clks: ccm@53f80000{
|
||||
compatible = "fsl,imx31-ccm";
|
||||
reg = <0x53f80000 0x4000>;
|
||||
interrupts = <0 31 0x04 0 53 0x04>;
|
||||
interrupts = <31>, <53>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -32,6 +32,9 @@ Required properties:
|
|||
* "fsl,b4420-clockgen"
|
||||
* "fsl,b4860-clockgen"
|
||||
* "fsl,ls1021a-clockgen"
|
||||
* "fsl,ls1043a-clockgen"
|
||||
* "fsl,ls1046a-clockgen"
|
||||
* "fsl,ls2080a-clockgen"
|
||||
Chassis-version clock strings include:
|
||||
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
|
||||
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
|
||||
|
|
|
|||
|
|
@ -123,6 +123,9 @@ PROPERTIES
|
|||
|
||||
|
||||
EXAMPLE
|
||||
|
||||
iMX6QDL/SX requires four clocks
|
||||
|
||||
crypto@300000 {
|
||||
compatible = "fsl,sec-v4.0";
|
||||
fsl,sec-era = <2>;
|
||||
|
|
@ -139,6 +142,23 @@ EXAMPLE
|
|||
clock-names = "mem", "aclk", "ipg", "emi_slow";
|
||||
};
|
||||
|
||||
|
||||
iMX6UL does only require three clocks
|
||||
|
||||
crypto: caam@2140000 {
|
||||
compatible = "fsl,sec-v4.0";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x2140000 0x3c000>;
|
||||
ranges = <0 0x2140000 0x3c000>;
|
||||
interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
clocks = <&clks IMX6UL_CLK_CAAM_MEM>,
|
||||
<&clks IMX6UL_CLK_CAAM_ACLK>,
|
||||
<&clks IMX6UL_CLK_CAAM_IPG>;
|
||||
clock-names = "mem", "aclk", "ipg";
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Job Ring (JR) Node
|
||||
|
||||
|
|
|
|||
|
|
@ -23,6 +23,14 @@ Required properties
|
|||
#define NBPF_SLAVE_RQ_LEVEL 4
|
||||
|
||||
Optional properties:
|
||||
- max-burst-mem-read: limit burst size for memory reads
|
||||
(DMA_MEM_TO_MEM/DMA_MEM_TO_DEV) to this value, specified in bytes, rather
|
||||
than using the maximum burst size allowed by the hardware's buffer size.
|
||||
- max-burst-mem-write: limit burst size for memory writes
|
||||
(DMA_DEV_TO_MEM/DMA_MEM_TO_MEM) to this value, specified in bytes, rather
|
||||
than using the maximum burst size allowed by the hardware's buffer size.
|
||||
If both max-burst-mem-read and max-burst-mem-write are set, DMA_MEM_TO_MEM
|
||||
will use the lower value.
|
||||
|
||||
You can use dma-channels and dma-requests as described in dma.txt, although they
|
||||
won't be used, this information is derived from the compatibility string.
|
||||
|
|
|
|||
|
|
@ -5,13 +5,13 @@ memcpy and memset capabilities. It has been designed for virtualized
|
|||
environments.
|
||||
|
||||
Each HIDMA HW instance consists of multiple DMA channels. These channels
|
||||
share the same bandwidth. The bandwidth utilization can be parititioned
|
||||
share the same bandwidth. The bandwidth utilization can be partitioned
|
||||
among channels based on the priority and weight assignments.
|
||||
|
||||
There are only two priority levels and 15 weigh assignments possible.
|
||||
|
||||
Other parameters here determine how much of the system bus this HIDMA
|
||||
instance can use like maximum read/write request and and number of bytes to
|
||||
instance can use like maximum read/write request and number of bytes to
|
||||
read/write in a single burst.
|
||||
|
||||
Main node required properties:
|
||||
|
|
@ -47,12 +47,18 @@ When the OS is not in control of the management interface (i.e. it's a guest),
|
|||
the channel nodes appear on their own, not under a management node.
|
||||
|
||||
Required properties:
|
||||
- compatible: must contain "qcom,hidma-1.0"
|
||||
- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
|
||||
for MSI capable HW.
|
||||
- reg: Addresses for the transfer and event channel
|
||||
- interrupts: Should contain the event interrupt
|
||||
- desc-count: Number of asynchronous requests this channel can handle
|
||||
- iommus: required a iommu node
|
||||
|
||||
Optional properties for MSI:
|
||||
- msi-parent : See the generic MSI binding described in
|
||||
devicetree/bindings/interrupt-controller/msi.txt for a description of the
|
||||
msi-parent property.
|
||||
|
||||
Example:
|
||||
|
||||
Hypervisor OS configuration:
|
||||
|
|
|
|||
|
|
@ -24,6 +24,7 @@ Required Properties:
|
|||
- "renesas,dmac-r8a7793" (R-Car M2-N)
|
||||
- "renesas,dmac-r8a7794" (R-Car E2)
|
||||
- "renesas,dmac-r8a7795" (R-Car H3)
|
||||
- "renesas,dmac-r8a7796" (R-Car M3-W)
|
||||
|
||||
- reg: base address and length of the registers block for the DMAC
|
||||
|
||||
|
|
|
|||
|
|
@ -27,6 +27,8 @@ Optional properties:
|
|||
that services interrupts for this device
|
||||
- is_private: The device channels should be marked as private and not for by the
|
||||
general purpose DMA channel allocator. False if not passed.
|
||||
- multi-block: Multi block transfers supported by hardware. Array property with
|
||||
one cell per channel. 0: not supported, 1 (default): supported.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,108 @@
|
|||
NVIDIA Tegra Boot and Power Management Processor (BPMP)
|
||||
|
||||
The BPMP is a specific processor in Tegra chip, which is designed for
|
||||
booting process handling and offloading the power management, clock
|
||||
management, and reset control tasks from the CPU. The binding document
|
||||
defines the resources that would be used by the BPMP firmware driver,
|
||||
which can create the interprocessor communication (IPC) between the CPU
|
||||
and BPMP.
|
||||
|
||||
Required properties:
|
||||
- name : Should be bpmp
|
||||
- compatible
|
||||
Array of strings
|
||||
One of:
|
||||
- "nvidia,tegra186-bpmp"
|
||||
- mboxes : The phandle of mailbox controller and the mailbox specifier.
|
||||
- shmem : List of the phandle of the TX and RX shared memory area that
|
||||
the IPC between CPU and BPMP is based on.
|
||||
- #clock-cells : Should be 1.
|
||||
- #power-domain-cells : Should be 1.
|
||||
- #reset-cells : Should be 1.
|
||||
|
||||
This node is a mailbox consumer. See the following files for details of
|
||||
the mailbox subsystem, and the specifiers implemented by the relevant
|
||||
provider(s):
|
||||
|
||||
- .../mailbox/mailbox.txt
|
||||
- .../mailbox/nvidia,tegra186-hsp.txt
|
||||
|
||||
This node is a clock, power domain, and reset provider. See the following
|
||||
files for general documentation of those features, and the specifiers
|
||||
implemented by this node:
|
||||
|
||||
- .../clock/clock-bindings.txt
|
||||
- <dt-bindings/clock/tegra186-clock.h>
|
||||
- ../power/power_domain.txt
|
||||
- <dt-bindings/power/tegra186-powergate.h>
|
||||
- .../reset/reset.txt
|
||||
- <dt-bindings/reset/tegra186-reset.h>
|
||||
|
||||
The BPMP implements some services which must be represented by separate nodes.
|
||||
For example, it can provide access to certain I2C controllers, and the I2C
|
||||
bindings represent each I2C controller as a device tree node. Such nodes should
|
||||
be nested directly inside the main BPMP node.
|
||||
|
||||
Software can determine whether a child node of the BPMP node represents a device
|
||||
by checking for a compatible property. Any node with a compatible property
|
||||
represents a device that can be instantiated. Nodes without a compatible
|
||||
property may be used to provide configuration information regarding the BPMP
|
||||
itself, although no such configuration nodes are currently defined by this
|
||||
binding.
|
||||
|
||||
The BPMP firmware defines no single global name-/numbering-space for such
|
||||
services. Put another way, the numbering scheme for I2C buses is distinct from
|
||||
the numbering scheme for any other service the BPMP may provide (e.g. a future
|
||||
hypothetical SPI bus service). As such, child device nodes will have no reg
|
||||
property, and the BPMP node will have no #address-cells or #size-cells property.
|
||||
|
||||
The shared memory bindings for BPMP
|
||||
-----------------------------------
|
||||
|
||||
The shared memory area for the IPC TX and RX between CPU and BPMP are
|
||||
predefined and work on top of sysram, which is an SRAM inside the chip.
|
||||
|
||||
See ".../sram/sram.txt" for the bindings.
|
||||
|
||||
Example:
|
||||
|
||||
hsp_top0: hsp@03c00000 {
|
||||
...
|
||||
#mbox-cells = <2>;
|
||||
};
|
||||
|
||||
sysram@30000000 {
|
||||
compatible = "nvidia,tegra186-sysram", "mmio-sram";
|
||||
reg = <0x0 0x30000000 0x0 0x50000>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
ranges = <0 0x0 0x0 0x30000000 0x0 0x50000>;
|
||||
|
||||
cpu_bpmp_tx: shmem@4e000 {
|
||||
compatible = "nvidia,tegra186-bpmp-shmem";
|
||||
reg = <0x0 0x4e000 0x0 0x1000>;
|
||||
label = "cpu-bpmp-tx";
|
||||
pool;
|
||||
};
|
||||
|
||||
cpu_bpmp_rx: shmem@4f000 {
|
||||
compatible = "nvidia,tegra186-bpmp-shmem";
|
||||
reg = <0x0 0x4f000 0x0 0x1000>;
|
||||
label = "cpu-bpmp-rx";
|
||||
pool;
|
||||
};
|
||||
};
|
||||
|
||||
bpmp {
|
||||
compatible = "nvidia,tegra186-bpmp";
|
||||
mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
|
||||
shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
|
||||
i2c {
|
||||
compatible = "...";
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -10,8 +10,10 @@ Required properties:
|
|||
* "qcom,scm-apq8064" for APQ8064 platforms
|
||||
* "qcom,scm-msm8660" for MSM8660 platforms
|
||||
* "qcom,scm-msm8690" for MSM8690 platforms
|
||||
* "qcom,scm-msm8996" for MSM8996 platforms
|
||||
* "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
|
||||
- clocks: One to three clocks may be required based on compatible.
|
||||
* No clock required for "qcom,scm-msm8996"
|
||||
* Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
|
||||
* Core, iface, and bus clocks required for "qcom,scm"
|
||||
- clock-names: Must contain "core" for the core clock, "iface" for the interface
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
Altera FPGA To SDRAM Bridge Driver
|
||||
|
||||
Required properties:
|
||||
- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
|
||||
|
||||
Optional properties:
|
||||
- bridge-enable : 0 if driver should disable bridge at startup
|
||||
1 if driver should enable bridge at startup
|
||||
Default is to leave bridge in current state.
|
||||
|
||||
Example:
|
||||
fpga_bridge3: fpga-bridge@ffc25080 {
|
||||
compatible = "altr,socfpga-fpga2sdram-bridge";
|
||||
reg = <0xffc25080 0x4>;
|
||||
bridge-enable = <0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
Altera Freeze Bridge Controller Driver
|
||||
|
||||
The Altera Freeze Bridge Controller manages one or more freeze bridges.
|
||||
The controller can freeze/disable the bridges which prevents signal
|
||||
changes from passing through the bridge. The controller can also
|
||||
unfreeze/enable the bridges which allows traffic to pass through the
|
||||
bridge normally.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should contain "altr,freeze-bridge-controller"
|
||||
- regs : base address and size for freeze bridge module
|
||||
|
||||
Optional properties:
|
||||
- bridge-enable : 0 if driver should disable bridge at startup
|
||||
1 if driver should enable bridge at startup
|
||||
Default is to leave bridge in current state.
|
||||
|
||||
Example:
|
||||
freeze-controller@100000450 {
|
||||
compatible = "altr,freeze-bridge-controller";
|
||||
regs = <0x1000 0x10>;
|
||||
bridge-enable = <0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
Altera FPGA/HPS Bridge Driver
|
||||
|
||||
Required properties:
|
||||
- regs : base address and size for AXI bridge module
|
||||
- compatible : Should contain one of:
|
||||
"altr,socfpga-lwhps2fpga-bridge",
|
||||
"altr,socfpga-hps2fpga-bridge", or
|
||||
"altr,socfpga-fpga2hps-bridge"
|
||||
- resets : Phandle and reset specifier for this bridge's reset
|
||||
- clocks : Clocks used by this module.
|
||||
|
||||
Optional properties:
|
||||
- bridge-enable : 0 if driver should disable bridge at startup.
|
||||
1 if driver should enable bridge at startup.
|
||||
Default is to leave bridge in its current state.
|
||||
|
||||
Example:
|
||||
fpga_bridge0: fpga-bridge@ff400000 {
|
||||
compatible = "altr,socfpga-lwhps2fpga-bridge";
|
||||
reg = <0xff400000 0x100000>;
|
||||
resets = <&rst LWHPS2FPGA_RESET>;
|
||||
clocks = <&l4_main_clk>;
|
||||
bridge-enable = <0>;
|
||||
};
|
||||
|
||||
fpga_bridge1: fpga-bridge@ff500000 {
|
||||
compatible = "altr,socfpga-hps2fpga-bridge";
|
||||
reg = <0xff500000 0x10000>;
|
||||
resets = <&rst HPS2FPGA_RESET>;
|
||||
clocks = <&l4_main_clk>;
|
||||
bridge-enable = <1>;
|
||||
};
|
||||
|
||||
fpga_bridge2: fpga-bridge@ff600000 {
|
||||
compatible = "altr,socfpga-fpga2hps-bridge";
|
||||
reg = <0xff600000 0x100000>;
|
||||
resets = <&rst FPGA2HPS_RESET>;
|
||||
clocks = <&l4_main_clk>;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
Altera SOCFPGA Arria10 FPGA Manager
|
||||
|
||||
Required properties:
|
||||
- compatible : should contain "altr,socfpga-a10-fpga-mgr"
|
||||
- reg : base address and size for memory mapped io.
|
||||
- The first index is for FPGA manager register access.
|
||||
- The second index is for writing FPGA configuration data.
|
||||
- resets : Phandle and reset specifier for the device's reset.
|
||||
- clocks : Clocks used by the device.
|
||||
|
||||
Example:
|
||||
|
||||
fpga_mgr: fpga-mgr@ffd03000 {
|
||||
compatible = "altr,socfpga-a10-fpga-mgr";
|
||||
reg = <0xffd03000 0x100
|
||||
0xffcfe400 0x20>;
|
||||
clocks = <&l4_mp_clk>;
|
||||
resets = <&rst FPGAMGR_RESET>;
|
||||
};
|
||||
|
|
@ -17,7 +17,9 @@ Required properties:
|
|||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source.
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be one. It is the pin number.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify flags. See gpio.txt for possible
|
||||
values.
|
||||
|
||||
Example for a MMP platform:
|
||||
|
||||
|
|
@ -27,7 +29,7 @@ Example for a MMP platform:
|
|||
interrupts = <49>;
|
||||
interrupt-names = "gpio_mux";
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
* Freescale Low Power Inter IC (LPI2C) for i.MX
|
||||
|
||||
Required properties:
|
||||
- compatible :
|
||||
- "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc
|
||||
- "fsl,imx8dv-lpi2c" for LPI2C compatible with the one integrated on i.MX8DV soc
|
||||
- reg : address and length of the lpi2c master registers
|
||||
- interrupt-parent : core interrupt controller
|
||||
- interrupts : lpi2c interrupt
|
||||
- clocks : lpi2c clock specifier
|
||||
|
||||
Examples:
|
||||
|
||||
lpi2c7: lpi2c7@40A50000 {
|
||||
compatible = "fsl,imx8dv-lpi2c";
|
||||
reg = <0x40A50000 0x10000>;
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clks IMX7ULP_CLK_LPI2C7>;
|
||||
};
|
||||
|
|
@ -7,6 +7,7 @@ Required properties :
|
|||
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
|
||||
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
|
||||
as shown in the example below.
|
||||
For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
|
||||
|
||||
Recommended properties :
|
||||
|
||||
|
|
|
|||
|
|
@ -1,17 +1,25 @@
|
|||
I2C for R-Car platforms
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of
|
||||
"renesas,i2c-rcar"
|
||||
"renesas,i2c-r8a7778"
|
||||
"renesas,i2c-r8a7779"
|
||||
"renesas,i2c-r8a7790"
|
||||
"renesas,i2c-r8a7791"
|
||||
"renesas,i2c-r8a7792"
|
||||
"renesas,i2c-r8a7793"
|
||||
"renesas,i2c-r8a7794"
|
||||
"renesas,i2c-r8a7795"
|
||||
"renesas,i2c-r8a7796"
|
||||
- compatible:
|
||||
"renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
|
||||
"renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
|
||||
"renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
|
||||
"renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
|
||||
"renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
|
||||
"renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
|
||||
"renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
|
||||
"renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
|
||||
"renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
|
||||
"renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
|
||||
"renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
|
||||
"renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
|
||||
"renesas,i2c-rcar" (deprecated)
|
||||
|
||||
When compatible with the generic version, nodes must list the
|
||||
SoC-specific version corresponding to the platform first followed
|
||||
by the generic version.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt specifier.
|
||||
|
|
@ -33,7 +41,7 @@ Examples :
|
|||
i2c0: i2c@e6508000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "renesas,i2c-r8a7791";
|
||||
compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
|
||||
reg = <0 0xe6508000 0 0x40>;
|
||||
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
|
||||
|
|
|
|||
|
|
@ -1,8 +1,7 @@
|
|||
Device tree configuration for Renesas IIC (sh_mobile) driver
|
||||
|
||||
Required properties:
|
||||
- compatible : "renesas,iic-<soctype>". "renesas,rmobile-iic" as fallback
|
||||
Examples with soctypes are:
|
||||
- compatible :
|
||||
- "renesas,iic-r8a73a4" (R-Mobile APE6)
|
||||
- "renesas,iic-r8a7740" (R-Mobile A1)
|
||||
- "renesas,iic-r8a7790" (R-Car H2)
|
||||
|
|
@ -12,6 +11,17 @@ Required properties:
|
|||
- "renesas,iic-r8a7794" (R-Car E2)
|
||||
- "renesas,iic-r8a7795" (R-Car H3)
|
||||
- "renesas,iic-sh73a0" (SH-Mobile AG5)
|
||||
- "renesas,rcar-gen2-iic" (generic R-Car Gen2 compatible device)
|
||||
- "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device)
|
||||
- "renesas,rmobile-iic" (generic device)
|
||||
|
||||
When compatible with a generic R-Car version, nodes
|
||||
must list the SoC-specific version corresponding to
|
||||
the platform first followed by the generic R-Car
|
||||
version.
|
||||
|
||||
renesas,rmobile-iic must always follow.
|
||||
|
||||
- reg : address start and address range size of device
|
||||
- interrupts : interrupt of device
|
||||
- clocks : clock for device
|
||||
|
|
@ -31,7 +41,8 @@ Pinctrl properties might be needed, too. See there.
|
|||
Example:
|
||||
|
||||
iic0: i2c@e6500000 {
|
||||
compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
|
||||
compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
|
||||
"renesas,rmobile-iic";
|
||||
reg = <0 0xe6500000 0 0x425>;
|
||||
interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp3_clks R8A7790_CLK_IIC0>;
|
||||
|
|
|
|||
|
|
@ -62,6 +62,9 @@ wants to support one of the below features, it should adapt the bindings below.
|
|||
"irq" and "wakeup" names are recognized by I2C core, other names are
|
||||
left to individual drivers.
|
||||
|
||||
- host-notify
|
||||
device uses SMBus host notify protocol instead of interrupt line.
|
||||
|
||||
- multi-master
|
||||
states that there is another master active on this bus. The OS can use
|
||||
this information to adapt power management to keep the arbitration awake
|
||||
|
|
@ -81,6 +84,11 @@ Binding may contain optional "interrupts" property, describing interrupts
|
|||
used by the device. I2C core will assign "irq" interrupt (or the very first
|
||||
interrupt if not using interrupt names) as primary interrupt for the slave.
|
||||
|
||||
Alternatively, devices supporting SMbus Host Notify, and connected to
|
||||
adapters that support this feature, may use "host-notify" property. I2C
|
||||
core will create a virtual interrupt for Host Notify and assign it as
|
||||
primary interrupt for the slave.
|
||||
|
||||
Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
|
||||
interrupt for the device. If "wakeup" interrupt name is not present in the
|
||||
binding, then primary interrupt will be used as wakeup interrupt.
|
||||
|
|
|
|||
|
|
@ -138,6 +138,8 @@ nuvoton,npct501 i2c trusted platform module (TPM)
|
|||
nuvoton,npct601 i2c trusted platform module (TPM2)
|
||||
nxp,pca9556 Octal SMBus and I2C registered interface
|
||||
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
|
||||
nxp,pcf2127 Real-time clock
|
||||
nxp,pcf2129 Real-time clock
|
||||
nxp,pcf8563 Real-time clock/calendar
|
||||
nxp,pcf85063 Tiny Real-Time Clock
|
||||
oki,ml86v7667 OKI ML86V7667 video decoder
|
||||
|
|
@ -167,4 +169,5 @@ ti,tsc2003 I2C Touch-Screen Controller
|
|||
ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
|
||||
ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
|
||||
ti,tmp275 Digital Temperature Sensor
|
||||
winbond,w83793 Winbond/Nuvoton H/W Monitor
|
||||
winbond,wpct301 i2c trusted platform module (TPM)
|
||||
|
|
|
|||
|
|
@ -1,32 +1,47 @@
|
|||
* Dialog DA9062/63 OnKey Module
|
||||
* Dialog DA9061/62/63 OnKey Module
|
||||
|
||||
This module is part of the DA9062/DA9063. For more details about entire
|
||||
chips see Documentation/devicetree/bindings/mfd/da9062.txt and
|
||||
Documentation/devicetree/bindings/mfd/da9063.txt
|
||||
This module is part of the DA9061/DA9062/DA9063. For more details about entire
|
||||
DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
|
||||
For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
|
||||
|
||||
This module provides KEY_POWER, KEY_SLEEP and events.
|
||||
This module provides the KEY_POWER event.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be one of:
|
||||
dlg,da9062-onkey
|
||||
dlg,da9063-onkey
|
||||
- compatible: should be one of the following valid compatible string lines:
|
||||
"dlg,da9061-onkey", "dlg,da9062-onkey"
|
||||
"dlg,da9062-onkey"
|
||||
"dlg,da9063-onkey"
|
||||
|
||||
Optional properties:
|
||||
|
||||
- dlg,disable-key-power : Disable power-down using a long key-press. If this
|
||||
- dlg,disable-key-power : Disable power-down using a long key-press. If this
|
||||
entry exists the OnKey driver will remove support for the KEY_POWER key
|
||||
press. If this entry does not exist then by default the key-press
|
||||
triggered power down is enabled and the OnKey will support both KEY_POWER
|
||||
and KEY_SLEEP.
|
||||
press when triggered using a long press of the OnKey.
|
||||
|
||||
Example:
|
||||
|
||||
pmic0: da9062@58 {
|
||||
Example: DA9063
|
||||
|
||||
pmic0: da9063@58 {
|
||||
onkey {
|
||||
compatible = "dlg,da9063-onkey";
|
||||
dlg,disable-key-power;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
Example: DA9062
|
||||
|
||||
pmic0: da9062@58 {
|
||||
onkey {
|
||||
compatible = "dlg,da9062-onkey";
|
||||
dlg,disable-key-power;
|
||||
};
|
||||
};
|
||||
|
||||
Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
|
||||
|
||||
pmic0: da9061@58 {
|
||||
onkey {
|
||||
compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
|
||||
dlg,disable-key-power;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -17,6 +17,8 @@ Optional properties:
|
|||
This value depends on the touch screen.
|
||||
- pre-charge-time: the touch screen need some time to precharge.
|
||||
This value depends on the touch screen.
|
||||
- touchscreen-average-samples: Number of data samples which are averaged for
|
||||
each read. Valid values are 1, 4, 8, 16 and 32.
|
||||
|
||||
Example:
|
||||
tsc: tsc@02040000 {
|
||||
|
|
@ -32,5 +34,6 @@ Example:
|
|||
xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
|
||||
measure-delay-time = <0xfff>;
|
||||
pre-charge-time = <0xffff>;
|
||||
touchscreen-average-samples = <32>;
|
||||
status = "okay";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -18,6 +18,8 @@ Optional properties:
|
|||
- touchscreen-inverted-y : See touchscreen.txt
|
||||
- touchscreen-swapped-x-y : See touchscreen.txt
|
||||
- silead,max-fingers : maximum number of fingers the touchscreen can detect
|
||||
- vddio-supply : regulator phandle for controller VDDIO
|
||||
- avdd-supply : regulator phandle for controller AVDD
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,9 @@ Optional properties for Touchscreens:
|
|||
- touchscreen-fuzz-pressure : pressure noise value of the absolute input
|
||||
device (arbitrary range dependent on the
|
||||
controller)
|
||||
- touchscreen-average-samples : Number of data samples which are averaged
|
||||
for each read (valid values dependent on the
|
||||
controller)
|
||||
- touchscreen-inverted-x : X axis is inverted (boolean)
|
||||
- touchscreen-inverted-y : Y axis is inverted (boolean)
|
||||
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
|
||||
|
|
|
|||
|
|
@ -8,8 +8,9 @@ This driver provides a simple power button event via an Interrupt.
|
|||
Required properties:
|
||||
- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton"
|
||||
|
||||
Required properties for TPS65218:
|
||||
Required properties:
|
||||
- interrupts: should be one of the following
|
||||
- <2>: For controllers compatible with tps65217
|
||||
- <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
|
||||
|
||||
Examples:
|
||||
|
|
@ -17,6 +18,7 @@ Examples:
|
|||
&tps {
|
||||
tps65217-pwrbutton {
|
||||
compatible = "ti,tps65217-pwrbutton";
|
||||
interrupts = <2>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Required properties:
|
|||
|
||||
Example:
|
||||
|
||||
mailbox: mailbox@7e00b800 {
|
||||
mailbox: mailbox@7e00b880 {
|
||||
compatible = "brcm,bcm2835-mbox";
|
||||
reg = <0x7e00b880 0x40>;
|
||||
interrupts = <0 1>;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
NVIDIA Tegra Hardware Synchronization Primitives (HSP)
|
||||
|
||||
The HSP modules are used for the processors to share resources and communicate
|
||||
together. It provides a set of hardware synchronization primitives for
|
||||
interprocessor communication. So the interprocessor communication (IPC)
|
||||
protocols can use hardware synchronization primitives, when operating between
|
||||
two processors not in an SMP relationship.
|
||||
|
||||
The features that HSP supported are shared mailboxes, shared semaphores,
|
||||
arbitrated semaphores and doorbells.
|
||||
|
||||
Required properties:
|
||||
- name : Should be hsp
|
||||
- compatible
|
||||
Array of strings.
|
||||
one of:
|
||||
- "nvidia,tegra186-hsp"
|
||||
- reg : Offset and length of the register set for the device.
|
||||
- interrupt-names
|
||||
Array of strings.
|
||||
Contains a list of names for the interrupts described by the interrupt
|
||||
property. May contain the following entries, in any order:
|
||||
- "doorbell"
|
||||
Users of this binding MUST look up entries in the interrupt property
|
||||
by name, using this interrupt-names property to do so.
|
||||
- interrupts
|
||||
Array of interrupt specifiers.
|
||||
Must contain one entry per entry in the interrupt-names property,
|
||||
in a matching order.
|
||||
- #mbox-cells : Should be 2.
|
||||
|
||||
The mbox specifier of the "mboxes" property in the client node should
|
||||
contain two data. The first one should be the HSP type and the second
|
||||
one should be the ID that the client is going to use. Those information
|
||||
can be found in the following file.
|
||||
|
||||
- <dt-bindings/mailbox/tegra186-hsp.h>.
|
||||
|
||||
Example:
|
||||
|
||||
hsp_top0: hsp@3c00000 {
|
||||
compatible = "nvidia,tegra186-hsp";
|
||||
reg = <0x0 0x03c00000 0x0 0xa0000>;
|
||||
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "doorbell";
|
||||
#mbox-cells = <2>;
|
||||
};
|
||||
|
||||
client {
|
||||
...
|
||||
mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_XXX>;
|
||||
};
|
||||
|
|
@ -3,7 +3,8 @@
|
|||
G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "samsung,exynos5-gsc"
|
||||
- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
|
||||
5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
|
||||
- reg: should contain G-Scaler physical address location and length.
|
||||
- interrupts: should contain G-Scaler interrupt number
|
||||
|
||||
|
|
|
|||
|
|
@ -8,10 +8,11 @@ Required properties:
|
|||
the device. The interrupt specifier format depends on the interrupt
|
||||
controller parent.
|
||||
- clocks: clock phandle and specifier pair.
|
||||
- hisilicon,power-syscon: phandle of syscon used to control power.
|
||||
|
||||
Optional properties:
|
||||
- linux,rc-map-name : Remote control map name.
|
||||
- hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files.
|
||||
Provide correct clocks instead.
|
||||
|
||||
Example node:
|
||||
|
||||
|
|
@ -19,7 +20,6 @@ Example node:
|
|||
compatible = "hisilicon,hix5hd2-ir";
|
||||
reg = <0xf8001000 0x1000>;
|
||||
interrupts = <0 47 4>;
|
||||
clocks = <&clock HIX5HD2_FIXED_24M>;
|
||||
hisilicon,power-syscon = <&sysctrl>;
|
||||
clocks = <&clock HIX5HD2_IR_CLOCK>;
|
||||
linux,rc-map-name = "rc-tivo";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -34,6 +34,7 @@ The digital output port node must contain at least one endpoint.
|
|||
Optional Properties:
|
||||
|
||||
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
|
||||
- default-input: Select which input is selected after reset.
|
||||
|
||||
Optional Endpoint Properties:
|
||||
|
||||
|
|
@ -47,8 +48,6 @@ Optional Endpoint Properties:
|
|||
If none of hsync-active, vsync-active and pclk-sample is specified the
|
||||
endpoint will use embedded BT.656 synchronization.
|
||||
|
||||
- default-input: Select which input is selected after reset.
|
||||
|
||||
Example:
|
||||
|
||||
hdmi_receiver@4c {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,109 @@
|
|||
* Mediatek Media Data Path
|
||||
|
||||
Media Data Path is used for scaling and color space conversion.
|
||||
|
||||
Required properties (controller (parent) node):
|
||||
- compatible: "mediatek,mt8173-mdp"
|
||||
- mediatek,vpu: the node of video processor unit, see
|
||||
Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
|
||||
|
||||
Required properties (all function blocks, child node):
|
||||
- compatible: Should be one of
|
||||
"mediatek,mt8173-mdp-rdma" - read DMA
|
||||
"mediatek,mt8173-mdp-rsz" - resizer
|
||||
"mediatek,mt8173-mdp-wdma" - write DMA
|
||||
"mediatek,mt8173-mdp-wrot" - write DMA with rotation
|
||||
- reg: Physical base address and length of the function block register space
|
||||
- clocks: device clocks, see
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
|
||||
- power-domains: a phandle to the power domain, see
|
||||
Documentation/devicetree/bindings/power/power_domain.txt for details.
|
||||
|
||||
Required properties (DMA function blocks, child node):
|
||||
- compatible: Should be one of
|
||||
"mediatek,mt8173-mdp-rdma"
|
||||
"mediatek,mt8173-mdp-wdma"
|
||||
"mediatek,mt8173-mdp-wrot"
|
||||
- iommus: should point to the respective IOMMU block with master port as
|
||||
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
|
||||
for details.
|
||||
- mediatek,larb: must contain the local arbiters in the current Socs, see
|
||||
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
|
||||
for details.
|
||||
|
||||
Example:
|
||||
mdp {
|
||||
compatible = "mediatek,mt8173-mdp";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
ranges;
|
||||
mediatek,vpu = <&vpu>;
|
||||
|
||||
mdp_rdma0: rdma@14001000 {
|
||||
compatible = "mediatek,mt8173-mdp-rdma";
|
||||
reg = <0 0x14001000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_RDMA0>,
|
||||
<&mmsys CLK_MM_MUTEX_32K>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
iommus = <&iommu M4U_PORT_MDP_RDMA0>;
|
||||
mediatek,larb = <&larb0>;
|
||||
};
|
||||
|
||||
mdp_rdma1: rdma@14002000 {
|
||||
compatible = "mediatek,mt8173-mdp-rdma";
|
||||
reg = <0 0x14002000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_RDMA1>,
|
||||
<&mmsys CLK_MM_MUTEX_32K>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
iommus = <&iommu M4U_PORT_MDP_RDMA1>;
|
||||
mediatek,larb = <&larb4>;
|
||||
};
|
||||
|
||||
mdp_rsz0: rsz@14003000 {
|
||||
compatible = "mediatek,mt8173-mdp-rsz";
|
||||
reg = <0 0x14003000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_RSZ0>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
};
|
||||
|
||||
mdp_rsz1: rsz@14004000 {
|
||||
compatible = "mediatek,mt8173-mdp-rsz";
|
||||
reg = <0 0x14004000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_RSZ1>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
};
|
||||
|
||||
mdp_rsz2: rsz@14005000 {
|
||||
compatible = "mediatek,mt8173-mdp-rsz";
|
||||
reg = <0 0x14005000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_RSZ2>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
};
|
||||
|
||||
mdp_wdma0: wdma@14006000 {
|
||||
compatible = "mediatek,mt8173-mdp-wdma";
|
||||
reg = <0 0x14006000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_WDMA>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
iommus = <&iommu M4U_PORT_MDP_WDMA>;
|
||||
mediatek,larb = <&larb0>;
|
||||
};
|
||||
|
||||
mdp_wrot0: wrot@14007000 {
|
||||
compatible = "mediatek,mt8173-mdp-wrot";
|
||||
reg = <0 0x14007000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_WROT0>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
iommus = <&iommu M4U_PORT_MDP_WROT0>;
|
||||
mediatek,larb = <&larb0>;
|
||||
};
|
||||
|
||||
mdp_wrot1: wrot@14008000 {
|
||||
compatible = "mediatek,mt8173-mdp-wrot";
|
||||
reg = <0 0x14008000 0 0x1000>;
|
||||
clocks = <&mmsys CLK_MM_MDP_WROT1>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
|
||||
iommus = <&iommu M4U_PORT_MDP_WROT1>;
|
||||
mediatek,larb = <&larb4>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,25 +1,74 @@
|
|||
Mediatek Video Codec
|
||||
|
||||
Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
|
||||
supports high resolution encoding functionalities.
|
||||
supports high resolution encoding and decoding functionalities.
|
||||
|
||||
Required properties:
|
||||
- compatible : "mediatek,mt8173-vcodec-enc" for encoder
|
||||
"mediatek,mt8173-vcodec-dec" for decoder.
|
||||
- reg : Physical base address of the video codec registers and length of
|
||||
memory mapped region.
|
||||
- interrupts : interrupt number to the cpu.
|
||||
- mediatek,larb : must contain the local arbiters in the current Socs.
|
||||
- clocks : list of clock specifiers, corresponding to entries in
|
||||
the clock-names property.
|
||||
- clock-names: encoder must contain "venc_sel_src", "venc_sel",
|
||||
- "venc_lt_sel_src", "venc_lt_sel".
|
||||
- clock-names: encoder must contain "venc_sel_src", "venc_sel",,
|
||||
"venc_lt_sel_src", "venc_lt_sel", decoder must contain "vcodecpll",
|
||||
"univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
|
||||
"venc_lt_sel", "vdec_bus_clk_src".
|
||||
- iommus : should point to the respective IOMMU block with master port as
|
||||
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
|
||||
for details.
|
||||
- mediatek,vpu : the node of video processor unit
|
||||
|
||||
|
||||
Example:
|
||||
vcodec_enc: vcodec@0x18002000 {
|
||||
|
||||
vcodec_dec: vcodec@16000000 {
|
||||
compatible = "mediatek,mt8173-vcodec-dec";
|
||||
reg = <0 0x16000000 0 0x100>, /*VDEC_SYS*/
|
||||
<0 0x16020000 0 0x1000>, /*VDEC_MISC*/
|
||||
<0 0x16021000 0 0x800>, /*VDEC_LD*/
|
||||
<0 0x16021800 0 0x800>, /*VDEC_TOP*/
|
||||
<0 0x16022000 0 0x1000>, /*VDEC_CM*/
|
||||
<0 0x16023000 0 0x1000>, /*VDEC_AD*/
|
||||
<0 0x16024000 0 0x1000>, /*VDEC_AV*/
|
||||
<0 0x16025000 0 0x1000>, /*VDEC_PP*/
|
||||
<0 0x16026800 0 0x800>, /*VP8_VD*/
|
||||
<0 0x16027000 0 0x800>, /*VP6_VD*/
|
||||
<0 0x16027800 0 0x800>, /*VP8_VL*/
|
||||
<0 0x16028400 0 0x400>; /*VP9_VD*/
|
||||
interrupts = <GIC_SPI 204 IRQ_TYPE_LEVEL_LOW>;
|
||||
mediatek,larb = <&larb1>;
|
||||
iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>,
|
||||
<&iommu M4U_PORT_HW_VDEC_PP_EXT>,
|
||||
<&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>,
|
||||
<&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>,
|
||||
<&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>,
|
||||
<&iommu M4U_PORT_HW_VDEC_UFO_EXT>,
|
||||
<&iommu M4U_PORT_HW_VDEC_VLD_EXT>,
|
||||
<&iommu M4U_PORT_HW_VDEC_VLD2_EXT>;
|
||||
mediatek,vpu = <&vpu>;
|
||||
power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
|
||||
clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>,
|
||||
<&topckgen CLK_TOP_UNIVPLL_D2>,
|
||||
<&topckgen CLK_TOP_CCI400_SEL>,
|
||||
<&topckgen CLK_TOP_VDEC_SEL>,
|
||||
<&topckgen CLK_TOP_VCODECPLL>,
|
||||
<&apmixedsys CLK_APMIXED_VENCPLL>,
|
||||
<&topckgen CLK_TOP_VENC_LT_SEL>,
|
||||
<&topckgen CLK_TOP_VCODECPLL_370P5>;
|
||||
clock-names = "vcodecpll",
|
||||
"univpll_d2",
|
||||
"clk_cci400_sel",
|
||||
"vdec_sel",
|
||||
"vdecpll",
|
||||
"vencpll",
|
||||
"venc_lt_sel",
|
||||
"vdec_bus_clk_src";
|
||||
};
|
||||
|
||||
vcodec_enc: vcodec@0x18002000 {
|
||||
compatible = "mediatek,mt8173-vcodec-enc";
|
||||
reg = <0 0x18002000 0 0x1000>, /*VENC_SYS*/
|
||||
<0 0x19002000 0 0x1000>; /*VENC_LT_SYS*/
|
||||
|
|
|
|||
|
|
@ -11,15 +11,9 @@ are paired with. These DT bindings currently support the FCPV and FCPF.
|
|||
|
||||
- compatible: Must be one or more of the following
|
||||
|
||||
- "renesas,r8a7795-fcpv" for R8A7795 (R-Car H3) compatible 'FCP for VSP'
|
||||
- "renesas,r8a7795-fcpf" for R8A7795 (R-Car H3) compatible 'FCP for FDP'
|
||||
- "renesas,fcpv" for generic compatible 'FCP for VSP'
|
||||
- "renesas,fcpf" for generic compatible 'FCP for FDP'
|
||||
|
||||
When compatible with the generic version, nodes must list the
|
||||
SoC-specific version corresponding to the platform first, followed by the
|
||||
family-specific and/or generic versions.
|
||||
|
||||
- reg: the register base and size for the device registers
|
||||
- clocks: Reference to the functional clock
|
||||
|
||||
|
|
@ -32,7 +26,7 @@ Device node example
|
|||
-------------------
|
||||
|
||||
fcpvd1: fcp@fea2f000 {
|
||||
compatible = "renesas,r8a7795-fcpv", "renesas,fcpv";
|
||||
compatible = "renesas,fcpv";
|
||||
reg = <0 0xfea2f000 0 0x200>;
|
||||
clocks = <&cpg CPG_MOD 602>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VP>;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
Renesas R-Car Fine Display Processor (FDP1)
|
||||
-------------------------------------------
|
||||
|
||||
The FDP1 is a de-interlacing module which converts interlaced video to
|
||||
progressive video. It is capable of performing pixel format conversion between
|
||||
YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are supported as
|
||||
an input to the module.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be "renesas,fdp1"
|
||||
- reg: the register base and size for the device registers
|
||||
- interrupts : interrupt specifier for the FDP1 instance
|
||||
- clocks: reference to the functional clock
|
||||
|
||||
Optional properties:
|
||||
|
||||
- power-domains: reference to the power domain that the FDP1 belongs to, if
|
||||
any.
|
||||
- renesas,fcp: a phandle referencing the FCP that handles memory accesses
|
||||
for the FDP1. Not needed on Gen2, mandatory on Gen3.
|
||||
|
||||
Please refer to the binding documentation for the clock and/or power domain
|
||||
providers for more details.
|
||||
|
||||
|
||||
Device node example
|
||||
-------------------
|
||||
|
||||
fdp1@fe940000 {
|
||||
compatible = "renesas,fdp1";
|
||||
reg = <0 0xfe940000 0 0x2400>;
|
||||
interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 119>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VP>;
|
||||
renesas,fcp = <&fcpf0>;
|
||||
};
|
||||
|
|
@ -12,6 +12,7 @@ Required properties:
|
|||
(b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
|
||||
(c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
|
||||
(d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
|
||||
(e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
|
||||
|
||||
- reg : Physical base address of the IP registers and length of memory
|
||||
mapped region.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
|
||||
|
||||
The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs features
|
||||
a set of registers which allow to tweak the controller's behavior.
|
||||
|
||||
Documentation:
|
||||
OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "ti,da850-ddr-controller" - for da850 SoC based boards
|
||||
- reg: a tuple containing the base address of the memory
|
||||
controller and the size of the memory area to map
|
||||
|
||||
Example for da850 shown below.
|
||||
|
||||
ddrctl {
|
||||
compatible = "ti,da850-ddr-controller";
|
||||
reg = <0xb0000000 0xe8>;
|
||||
};
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
* Altera Arria10 Development Kit System Resource Chip
|
||||
|
||||
Required parent device properties:
|
||||
- compatible : "altr,a10sr"
|
||||
- spi-max-frequency : Maximum SPI frequency.
|
||||
- reg : The SPI Chip Select address for the Arria10
|
||||
System Resource chip
|
||||
- interrupt-parent : The parent interrupt controller.
|
||||
- interrupts : The interrupt line the device is connected to.
|
||||
- interrupt-controller : Marks the device node as an interrupt controller.
|
||||
- #interrupt-cells : The number of cells to describe an IRQ, should be 2.
|
||||
The first cell is the IRQ number.
|
||||
The second cell is the flags, encoded as trigger
|
||||
masks from ../interrupt-controller/interrupts.txt.
|
||||
|
||||
The A10SR consists of these sub-devices:
|
||||
|
||||
Device Description
|
||||
------ ----------
|
||||
a10sr_gpio GPIO Controller
|
||||
|
||||
Arria10 GPIO
|
||||
Required Properties:
|
||||
- compatible : Should be "altr,a10sr-gpio"
|
||||
- gpio-controller : Marks the device node as a GPIO Controller.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify flags.
|
||||
See ../gpio/gpio.txt for more information.
|
||||
|
||||
Example:
|
||||
|
||||
resource-manager@0 {
|
||||
compatible = "altr,a10sr";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <100000>;
|
||||
interrupt-parent = <&portb>;
|
||||
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
a10sr_gpio: gpio-controller {
|
||||
compatible = "altr,a10sr-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
};
|
||||
|
|
@ -10,6 +10,7 @@ voltages and other various functionality to Qualcomm SoCs.
|
|||
Value type: <string>
|
||||
Definition: must be one of:
|
||||
"qcom,pm8058"
|
||||
"qcom,pm8821"
|
||||
"qcom,pm8921"
|
||||
|
||||
- #address-cells:
|
||||
|
|
|
|||
|
|
@ -1,21 +1,25 @@
|
|||
* Ricoh RN5T567/RN5T618 PMIC
|
||||
|
||||
Ricoh RN5T567/RN5T618 is a power management IC family which integrates
|
||||
3 to 4 step-down DCDC converters, 7 low-dropout regulators, GPIOs and
|
||||
a watchdog timer. The RN5T618 provides additionally a Li-ion battery
|
||||
charger, fuel gauge and an ADC. It can be controlled through an I2C
|
||||
interface.
|
||||
Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
|
||||
integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
|
||||
GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
|
||||
The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
|
||||
fuel gauge, and an ADC.
|
||||
The RC5T619 additionnally includes USB charger detection and an RTC.
|
||||
|
||||
Required properties:
|
||||
- compatible: must be one of
|
||||
"ricoh,rn5t567"
|
||||
"ricoh,rn5t618"
|
||||
"ricoh,rc5t619"
|
||||
- reg: the I2C slave address of the device
|
||||
|
||||
Sub-nodes:
|
||||
- regulators: the node is required if the regulator functionality is
|
||||
needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, DCDC4
|
||||
(RN5T567), LDO1, LDO2, LDO3, LDO4, LDO5, LDORTC1 and LDORTC2.
|
||||
(RN5T567/RC5T619), LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7, LDO8,
|
||||
LDO9, LDO10, LDORTC1 and LDORTC2.
|
||||
LDO7-10 are specific to RC5T619.
|
||||
The common bindings for each individual regulator can be found in:
|
||||
Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue