aboutsummaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/00-INDEX2
-rw-r--r--Documentation/ABI/testing/sysfs-bus-pci7
-rw-r--r--Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration5
-rw-r--r--Documentation/ABI/testing/sysfs-devices-system-cpu16
-rw-r--r--Documentation/ABI/testing/sysfs-platform-sst-atom17
l---------Documentation/Changes1
-rw-r--r--Documentation/DocBook/Makefile2
-rw-r--r--Documentation/DocBook/crypto-API.tmpl2092
-rw-r--r--Documentation/IPMI.txt57
-rw-r--r--Documentation/admin-guide/index.rst1
-rw-r--r--Documentation/admin-guide/kernel-parameters.txt4
-rw-r--r--Documentation/admin-guide/ras.rst1190
-rw-r--r--Documentation/arm/stm32/overview.txt3
-rw-r--r--Documentation/arm/stm32/stm32f746-overview.txt34
-rw-r--r--Documentation/crypto/api-aead.rst23
-rw-r--r--Documentation/crypto/api-akcipher.rst20
-rw-r--r--Documentation/crypto/api-digest.rst35
-rw-r--r--Documentation/crypto/api-intro.txt5
-rw-r--r--Documentation/crypto/api-kpp.rst38
-rw-r--r--Documentation/crypto/api-rng.rst14
-rw-r--r--Documentation/crypto/api-samples.rst224
-rw-r--r--Documentation/crypto/api-skcipher.rst62
-rw-r--r--Documentation/crypto/api.rst25
-rw-r--r--Documentation/crypto/architecture.rst441
-rw-r--r--Documentation/crypto/devel-algos.rst247
-rw-r--r--Documentation/crypto/index.rst24
-rw-r--r--Documentation/crypto/intro.rst74
-rw-r--r--Documentation/crypto/userspace-if.rst387
-rw-r--r--Documentation/dev-tools/sparse.rst14
-rw-r--r--Documentation/device-mapper/delay.txt4
-rw-r--r--Documentation/device-mapper/dm-crypt.txt2
-rw-r--r--Documentation/device-mapper/linear.txt8
-rw-r--r--Documentation/device-mapper/striped.txt4
-rw-r--r--Documentation/device-mapper/switch.txt2
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic,scpi.txt20
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic.txt19
-rw-r--r--Documentation/devicetree/bindings/arm/arm,scpi.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/arm-boards3
-rw-r--r--Documentation/devicetree/bindings/arm/atmel-at91.txt16
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,ns2.txt (renamed from Documentation/devicetree/bindings/arm/bcm/ns2.txt)0
-rw-r--r--Documentation/devicetree/bindings/arm/cpus.txt1
-rw-r--r--Documentation/devicetree/bindings/arm/fsl.txt34
-rw-r--r--Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt4
-rw-r--r--Documentation/devicetree/bindings/arm/juno,scpi.txt26
-rw-r--r--Documentation/devicetree/bindings/arm/keystone/ti,sci.txt81
-rw-r--r--Documentation/devicetree/bindings/arm/omap/omap.txt9
-rw-r--r--Documentation/devicetree/bindings/arm/oxnas.txt5
-rw-r--r--Documentation/devicetree/bindings/arm/qcom.txt3
-rw-r--r--Documentation/devicetree/bindings/arm/rockchip.txt16
-rw-r--r--Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt5
-rw-r--r--Documentation/devicetree/bindings/arm/shmobile.txt36
-rw-r--r--Documentation/devicetree/bindings/arm/sunxi.txt1
-rw-r--r--Documentation/devicetree/bindings/arm/swir.txt12
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt2
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-st.txt15
-rw-r--r--Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt132
-rw-r--r--Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt20
-rw-r--r--Documentation/devicetree/bindings/clock/imx31-clock.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/qoriq-clock.txt3
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl-sec4.txt20
-rw-r--r--Documentation/devicetree/bindings/dma/nbpfaxi.txt8
-rw-r--r--Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt12
-rw-r--r--Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt1
-rw-r--r--Documentation/devicetree/bindings/dma/snps-dma.txt2
-rw-r--r--Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt108
-rw-r--r--Documentation/devicetree/bindings/firmware/qcom,scm.txt2
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt16
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt23
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt39
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt19
-rw-r--r--Documentation/devicetree/bindings/gpio/mrvl-gpio.txt6
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt20
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-pxa.txt1
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-rcar.txt32
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt17
-rw-r--r--Documentation/devicetree/bindings/i2c/trivial-devices.txt3
-rw-r--r--Documentation/devicetree/bindings/input/da9062-onkey.txt45
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt3
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt3
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt2
-rw-r--r--Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt52
-rw-r--r--Documentation/devicetree/bindings/media/exynos5-gsc.txt3
-rw-r--r--Documentation/devicetree/bindings/media/hix5hd2-ir.txt6
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adv7604.txt3
-rw-r--r--Documentation/devicetree/bindings/media/mediatek-mdp.txt109
-rw-r--r--Documentation/devicetree/bindings/media/mediatek-vcodec.txt57
-rw-r--r--Documentation/devicetree/bindings/media/renesas,fcp.txt8
-rw-r--r--Documentation/devicetree/bindings/media/renesas,fdp1.txt37
-rw-r--r--Documentation/devicetree/bindings/media/s5p-mfc.txt1
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt20
-rw-r--r--Documentation/devicetree/bindings/mfd/altera-a10sr.txt46
-rw-r--r--Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt1
-rw-r--r--Documentation/devicetree/bindings/mfd/rn5t618.txt16
-rw-r--r--Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt1
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-cadence.txt6
-rw-r--r--Documentation/devicetree/bindings/mtd/oxnas-nand.txt41
-rw-r--r--Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt56
-rw-r--r--Documentation/devicetree/bindings/mtd/tango-nand.txt38
-rw-r--r--Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt13
-rw-r--r--Documentation/devicetree/bindings/net/phy.txt10
-rw-r--r--Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt43
-rw-r--r--Documentation/devicetree/bindings/pci/layerscape-pci.txt1
-rw-r--r--Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt110
-rw-r--r--Documentation/devicetree/bindings/pci/pci.txt6
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie.txt14
-rw-r--r--Documentation/devicetree/bindings/pci/rcar-pci.txt1
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt3
-rw-r--r--Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt8
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt2
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-hibvt.txt21
-rw-r--r--Documentation/devicetree/bindings/regulator/tps65218.txt87
-rw-r--r--Documentation/devicetree/bindings/reset/oxnas,reset.txt44
-rw-r--r--Documentation/devicetree/bindings/reset/st,sti-powerdown.txt12
-rw-r--r--Documentation/devicetree/bindings/reset/st,sti-softreset.txt8
-rw-r--r--Documentation/devicetree/bindings/rng/omap_rng.txt14
-rw-r--r--Documentation/devicetree/bindings/rtc/epson,rtc7301.txt16
-rw-r--r--Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt37
-rw-r--r--Documentation/devicetree/bindings/rtc/twl-rtc.txt19
-rw-r--r--Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt41
-rw-r--r--Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt21
-rw-r--r--Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt25
-rw-r--r--Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt2
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/scpsys.txt13
-rw-r--r--Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt88
-rw-r--r--Documentation/devicetree/bindings/sound/cs35l34.txt64
-rw-r--r--Documentation/devicetree/bindings/sound/cs42l42.txt110
-rw-r--r--Documentation/devicetree/bindings/sound/davinci-mcbsp.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt5
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt85
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt20
-rw-r--r--Documentation/devicetree/bindings/sound/rt5514.txt3
-rw-r--r--Documentation/devicetree/bindings/sound/rt5663.txt6
-rwxr-xr-xDocumentation/devicetree/bindings/sound/rt5665.txt68
-rw-r--r--Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt38
-rw-r--r--Documentation/devicetree/bindings/sound/sun4i-codec.txt65
-rw-r--r--Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt16
-rw-r--r--Documentation/devicetree/bindings/sound/tlv320aic31xx.txt1
-rw-r--r--Documentation/devicetree/bindings/sound/wm8580.txt4
-rw-r--r--Documentation/devicetree/bindings/sram/sram.txt2
-rw-r--r--Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt17
-rw-r--r--Documentation/devicetree/bindings/thermal/st-thermal.txt28
-rw-r--r--Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt17
-rw-r--r--Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt (renamed from Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt)6
-rw-r--r--Documentation/devicetree/bindings/usb/atmel-usb.txt10
-rw-r--r--Documentation/devicetree/bindings/vendor-prefixes.txt16
-rw-r--r--Documentation/dmaengine/client.txt16
-rw-r--r--Documentation/dmaengine/dmatest.txt10
-rw-r--r--Documentation/dmaengine/provider.txt2
-rw-r--r--Documentation/dmaengine/pxa_dma.txt2
-rw-r--r--Documentation/dontdiff1
-rw-r--r--Documentation/driver-api/edac.rst178
-rw-r--r--Documentation/driver-api/index.rst1
-rw-r--r--Documentation/edac.txt812
-rw-r--r--Documentation/features/io/dma-api-debug/arch-support.txt2
-rw-r--r--Documentation/features/io/dma-contiguous/arch-support.txt2
-rw-r--r--Documentation/features/io/sg-chain/arch-support.txt2
-rw-r--r--Documentation/filesystems/00-INDEX2
-rw-r--r--Documentation/filesystems/Locking4
-rw-r--r--Documentation/filesystems/logfs.txt241
-rw-r--r--Documentation/filesystems/overlayfs.txt26
-rw-r--r--Documentation/filesystems/porting4
-rw-r--r--Documentation/filesystems/sysfs-pci.txt2
-rw-r--r--Documentation/filesystems/vfs.txt11
-rw-r--r--Documentation/filesystems/xfs.txt12
-rw-r--r--Documentation/i2c/busses/i2c-mlxcpld47
-rw-r--r--Documentation/i2c/smbus-protocol12
-rw-r--r--Documentation/index.rst1
-rw-r--r--Documentation/laptops/thinkpad-acpi.txt1
-rw-r--r--Documentation/livepatch/livepatch.txt2
-rw-r--r--Documentation/media/Makefile2
-rw-r--r--Documentation/media/kapi/cec-core.rst38
-rw-r--r--Documentation/media/kapi/csi2.rst61
-rw-r--r--Documentation/media/kapi/dtv-core.rst8
-rw-r--r--Documentation/media/media_kapi.rst1
-rw-r--r--Documentation/media/typical_media_device.svg2974
-rw-r--r--Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst156
-rw-r--r--Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst488
-rw-r--r--Documentation/media/uapi/cec/cec-ioc-dqevent.rst182
-rw-r--r--Documentation/media/uapi/cec/cec-ioc-g-mode.rst317
-rw-r--r--Documentation/media/uapi/cec/cec-ioc-receive.rst418
-rw-r--r--Documentation/media/uapi/v4l/control.rst88
-rw-r--r--Documentation/media/uapi/v4l/dev-codec.rst2
-rw-r--r--Documentation/media/uapi/v4l/extended-controls.rst6
-rw-r--r--Documentation/media/uapi/v4l/hsv-formats.rst19
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-002.rst5
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-003.rst5
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-006.rst31
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-013.rst5
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst157
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-reserved.rst10
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-rgb.rst2
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-srggb10p.rst2
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-srggb12.rst2
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-srggb16.rst (renamed from Documentation/media/uapi/v4l/pixfmt-sbggr16.rst)25
-rw-r--r--Documentation/media/uapi/v4l/pixfmt-srggb8.rst2
-rw-r--r--Documentation/media/uapi/v4l/pixfmt.rst1
-rw-r--r--Documentation/media/uapi/v4l/subdev-image-processing-crop.svg299
-rw-r--r--Documentation/media/uapi/v4l/subdev-image-processing-full.svg779
-rw-r--r--Documentation/media/uapi/v4l/subdev-image-processing-scaling-multi-source.svg566
-rw-r--r--Documentation/media/uapi/v4l/v4l2.rst9
-rw-r--r--Documentation/media/uapi/v4l/vidioc-g-dv-timings.rst11
-rw-r--r--Documentation/media/uapi/v4l/vidioc-g-tuner.rst4
-rw-r--r--Documentation/media/v4l-drivers/au0828-cardlist.rst18
-rw-r--r--Documentation/media/v4l-drivers/bttv-cardlist.rst340
-rw-r--r--Documentation/media/v4l-drivers/cx23885-cardlist.rst122
-rw-r--r--Documentation/media/v4l-drivers/cx88-cardlist.rst188
-rw-r--r--Documentation/media/v4l-drivers/em28xx-cardlist.rst206
-rw-r--r--Documentation/media/v4l-drivers/gspca-cardlist.rst843
-rw-r--r--Documentation/media/v4l-drivers/index.rst3
-rw-r--r--Documentation/media/v4l-drivers/ivtv-cardlist.rst61
-rw-r--r--Documentation/media/v4l-drivers/rcar-fdp1.rst37
-rw-r--r--Documentation/media/v4l-drivers/saa7134-cardlist.rst400
-rw-r--r--Documentation/media/v4l-drivers/saa7164-cardlist.rst36
-rw-r--r--Documentation/media/v4l-drivers/tm6000-cardlist.rst39
-rw-r--r--Documentation/media/v4l-drivers/tuner-cardlist.rst188
-rw-r--r--Documentation/media/v4l-drivers/usbvision-cardlist.rst142
-rw-r--r--Documentation/media/videodev2.h.rst.exceptions7
-rw-r--r--Documentation/security/keys-trusted-encrypted.txt2
-rwxr-xr-xDocumentation/sphinx/rstFlatTable.py5
-rw-r--r--Documentation/trace/events.txt9
-rw-r--r--Documentation/trace/ftrace.txt15
-rw-r--r--Documentation/translations/zh_CN/sparse.txt7
-rw-r--r--Documentation/virtual/kvm/locking.txt8
-rw-r--r--Documentation/x86/intel_rdt_ui.txt214
225 files changed, 11989 insertions, 6670 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 5bd4b07c2f90..c8a8eb1a2b11 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -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
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index b3bc50f650ee..5a1732b78707 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -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.
diff --git a/Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration b/Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration
index 4cf1e72222d9..ec950c93e5c6 100644
--- a/Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration
+++ b/Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration
@@ -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.
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 498741737055..2a4a423d08e0 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -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
diff --git a/Documentation/ABI/testing/sysfs-platform-sst-atom b/Documentation/ABI/testing/sysfs-platform-sst-atom
new file mode 100644
index 000000000000..0d07c0395660
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-sst-atom
@@ -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
diff --git a/Documentation/Changes b/Documentation/Changes
new file mode 120000
index 000000000000..7564ae1682ba
--- /dev/null
+++ b/Documentation/Changes
@@ -0,0 +1 @@
+process/changes.rst \ No newline at end of file
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index caab9039362f..c75e5d6b8fa8 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -13,7 +13,7 @@ DOCBOOKS := z8530book.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
+ writing_musb_glue_layer.xml iio.xml
ifeq ($(DOCBOOKS),)
diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl
deleted file mode 100644
index 088b79c341ff..000000000000
--- a/Documentation/DocBook/crypto-API.tmpl
+++ /dev/null
@@ -1,2092 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
-
-<book id="KernelCryptoAPI">
- <bookinfo>
- <title>Linux Kernel Crypto API</title>
-
- <authorgroup>
- <author>
- <firstname>Stephan</firstname>
- <surname>Mueller</surname>
- <affiliation>
- <address>
- <email>smueller@chronox.de</email>
- </address>
- </affiliation>
- </author>
- <author>
- <firstname>Marek</firstname>
- <surname>Vasut</surname>
- <affiliation>
- <address>
- <email>marek@denx.de</email>
- </address>
- </affiliation>
- </author>
- </authorgroup>
-
- <copyright>
- <year>2014</year>
- <holder>Stephan Mueller</holder>
- </copyright>
-
-
- <legalnotice>
- <para>
- This documentation is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later
- version.
- </para>
-
- <para>
- This program is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- See the GNU General Public License for more details.
- </para>
-
- <para>
- You should have received a copy of the GNU General Public
- License along with this program; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- </para>
-
- <para>
- For more details see the file COPYING in the source
- distribution of Linux.
- </para>
- </legalnotice>
- </bookinfo>
-
- <toc></toc>
-
- <chapter id="Intro">
- <title>Kernel Crypto API Interface Specification</title>
-
- <sect1><title>Introduction</title>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- The kernel crypto API serves the following entity types:
-
- <itemizedlist>
- <listitem>
- <para>consumers requesting cryptographic services</para>
- </listitem>
- <listitem>
- <para>data transformation implementations (typically ciphers)
- that can be called by consumers using the kernel crypto
- API</para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- 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).
- </para>
-
- <para>
- Note: The terms "transformation" and cipher algorithm are used
- interchangeably.
- </para>
- </sect1>
-
- <sect1><title>Terminology</title>
- <para>
- The transformation implementation is an actual code or interface
- to hardware which implements a certain transformation with precisely
- defined behavior.
- </para>
-
- <para>
- 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).
- </para>
-
- <para>
- 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:
- </para>
-
- <orderedlist>
- <listitem>
- <para>Initialization of a cipher handle.</para>
- </listitem>
- <listitem>
- <para>Execution of all intended cipher operations applicable
- for the handle where the cipher handle must be furnished to
- every API call.</para>
- </listitem>
- <listitem>
- <para>Destruction of a cipher handle.</para>
- </listitem>
- </orderedlist>
-
- <para>
- 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_*.
- </para>
-
- <para>
- The transformation context is private data associated with
- the transformation object.
- </para>
- </sect1>
- </chapter>
-
- <chapter id="Architecture"><title>Kernel Crypto API Architecture</title>
- <sect1><title>Cipher algorithm types</title>
- <para>
- The kernel crypto API provides different API calls for the
- following cipher types:
-
- <itemizedlist>
- <listitem><para>Symmetric ciphers</para></listitem>
- <listitem><para>AEAD ciphers</para></listitem>
- <listitem><para>Message digest, including keyed message digest</para></listitem>
- <listitem><para>Random number generation</para></listitem>
- <listitem><para>User space interface</para></listitem>
- </itemizedlist>
- </para>
- </sect1>
-
- <sect1><title>Ciphers And Templates</title>
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- A single block cipher may even be called with multiple templates.
- However, templates cannot be used without a single cipher.
- </para>
-
- <para>
- See /proc/crypto and search for "name". For example:
-
- <itemizedlist>
- <listitem><para>aes</para></listitem>
- <listitem><para>ecb(aes)</para></listitem>
- <listitem><para>cmac(aes)</para></listitem>
- <listitem><para>ccm(aes)</para></listitem>
- <listitem><para>rfc4106(gcm(aes))</para></listitem>
- <listitem><para>sha1</para></listitem>
- <listitem><para>hmac(sha1)</para></listitem>
- <listitem><para>authenc(hmac(sha1),cbc(aes))</para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- In these examples, "aes" and "sha1" are the ciphers and all
- others are the templates.
- </para>
- </sect1>
-
- <sect1><title>Synchronous And Asynchronous Operation</title>
- <para>
- The kernel crypto API provides synchronous and asynchronous
- API operations.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
- </sect1>
-
- <sect1><title>Crypto API Cipher References And Priority</title>
- <para>
- A cipher is referenced by the caller with a string. That string
- has the following semantics:
-
- <programlisting>
- template(single block cipher)
- </programlisting>
-
- 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
-
- <programlisting>
- template1(template2(single block cipher)))
- </programlisting>
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>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)</para>
- </listitem>
- <listitem>
- <para>driver: the unique name of the cipher -- this name can
- be used by the cipher allocation API calls</para>
- </listitem>
- <listitem>
- <para>module: the kernel module providing the cipher
- implementation (or "kernel" for statically linked ciphers)</para>
- </listitem>
- <listitem>
- <para>priority: the priority value of the cipher implementation</para>
- </listitem>
- <listitem>
- <para>refcnt: the reference count of the respective cipher
- (i.e. the number of current consumers of this cipher)</para>
- </listitem>
- <listitem>
- <para>selftest: specification whether the self test for the
- cipher passed</para>
- </listitem>
- <listitem>
- <para>type:
- <itemizedlist>
- <listitem>
- <para>skcipher for symmetric key ciphers</para>
- </listitem>
- <listitem>
- <para>cipher for single block ciphers that may be used with
- an additional template</para>
- </listitem>
- <listitem>
- <para>shash for synchronous message digest</para>
- </listitem>
- <listitem>
- <para>ahash for asynchronous message digest</para>
- </listitem>
- <listitem>
- <para>aead for AEAD cipher type</para>
- </listitem>
- <listitem>
- <para>compression for compression type transformations</para>
- </listitem>
- <listitem>
- <para>rng for random number generator</para>
- </listitem>
- <listitem>
- <para>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)</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- <listitem>
- <para>blocksize: blocksize of cipher in bytes</para>
- </listitem>
- <listitem>
- <para>keysize: key size in bytes</para>
- </listitem>
- <listitem>
- <para>ivsize: IV size in bytes</para>
- </listitem>
- <listitem>
- <para>seedsize: required size of seed data for random number
- generator</para>
- </listitem>
- <listitem>
- <para>digestsize: output size of the message digest</para>
- </listitem>
- <listitem>
- <para>geniv: IV generation type:
- <itemizedlist>
- <listitem>
- <para>eseqiv for encrypted sequence number based IV
- generation</para>
- </listitem>
- <listitem>
- <para>seqiv for sequence number based IV generation</para>
- </listitem>
- <listitem>
- <para>chainiv for chain iv generation</para>
- </listitem>
- <listitem>
- <para>&lt;builtin&gt; is a marker that the cipher implements
- IV generation and handling as it is specific to the given
- cipher</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </itemizedlist>
- </sect1>
-
- <sect1><title>Key Sizes</title>
- <para>
- 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.
- </para>
- </sect1>
-
- <sect1><title>Cipher Allocation Type And Masks</title>
- <para>
- 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).
- </para>
-
- <para>
- 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:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>CRYPTO_ALG_TYPE_CIPHER Single block cipher</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_COMPRESS Compression</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with
- Associated Data (MAC)</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher</para>
- </listitem>
- <listitem>
- <para>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)</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_DIGEST Raw message digest</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_HASH Alias for CRYPTO_ALG_TYPE_DIGEST</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_RNG Random Number Generation</para>
- </listitem>
- <listitem>
- <para>CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher</para>
- </listitem>
- <listitem>
- <para>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.</para>
- </listitem>
- </itemizedlist>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
- </sect1>
-
- <sect1><title>Internal Structure of Kernel Crypto API</title>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <sect2><title>Generic AEAD Cipher Structure</title>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- The blocks below indicate the cipher type as well as the specific
- logic implemented in the cipher.
- </para>
-
- <para>
- 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.
- </para>
-
- <programlisting>
-<![CDATA[
-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) |
-+-----------+
-]]>
- </programlisting>
-
- <para>
- 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:
- </para>
-
- <orderedlist>
- <listitem>
- <para>
- esp_output() invokes crypto_aead_encrypt() to trigger an encryption
- operation of the AEAD cipher with IV generator.
- </para>
-
- <para>
- In case of GCM, the SEQIV implementation is registered as GIVCIPHER
- in crypto_rfc4106_alloc().
- </para>
-
- <para>
- The SEQIV performs its operation to generate an IV where the core
- function is seqiv_geniv().
- </para>
- </listitem>
-
- <listitem>
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- The GCM implementation is responsible to invoke the CTR mode AES and
- the GHASH cipher in the right manner to implement the GCM
- specification.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The GCM AEAD cipher type implementation now invokes the SKCIPHER API
- with the instantiated CTR(AES) cipher handle.
- </para>
-
- <para>
- During instantiation of the CTR(AES) cipher, the CIPHER type
- implementation of AES is instantiated. The cipher handle for AES is
- retained.
- </para>
-
- <para>
- 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.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
- cipher handle to encrypt one block.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The GCM AEAD implementation also invokes the GHASH cipher
- implementation via the AHASH API.
- </para>
- </listitem>
- </orderedlist>
-
- <para>
- 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).
- </para>
- </sect2>
-
- <sect2><title>Generic Block Cipher Structure</title>
- <para>
- Generic block ciphers follow the same concept as depicted with the ASCII
- art picture above.
- </para>
-
- <para>
- 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.
- </para>
- </sect2>
-
- <sect2><title>Generic Keyed Message Digest Structure</title>
- <para>
- Keyed message digest implementations again follow the same concept as
- depicted in the ASCII art picture above.
- </para>
-
- <para>
- For example, HMAC(SHA256) is implemented with hmac.c and
- sha256_generic.c. The following ASCII art illustrates the
- implementation:
- </para>
-
- <programlisting>
-<![CDATA[
-kernel crypto API | Caller
- |
-+-----------+ (1) |
-| | <------------------ some_function
-| ahash |
-| (hmac) | ---+
-+-----------+ |
- | (2)
-+-----------+ |
-| | <--+
-| shash |
-| (sha256) |
-+-----------+
-]]>
- </programlisting>
-
- <para>
- The following call sequence is applicable when a caller triggers
- an HMAC operation:
- </para>
-
- <orderedlist>
- <listitem>
- <para>
- The AHASH API functions are invoked by the caller. The HMAC
- implementation performs its operation as needed.
- </para>
-
- <para>
- During initialization of the HMAC cipher, the SHASH cipher type of
- SHA256 is instantiated. The cipher handle for the SHA256 instance is
- retained.
- </para>
-
- <para>
- At one time, the HMAC implementation requires a SHA256 operation
- where the SHA256 cipher handle is used.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The HMAC instance now invokes the SHASH API with the SHA256
- cipher handle to calculate the message digest.
- </para>
- </listitem>
- </orderedlist>
- </sect2>
- </sect1>
- </chapter>
-
- <chapter id="Development"><title>Developing Cipher Algorithms</title>
- <sect1><title>Registering And Unregistering Transformation</title>
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <programlisting>
- int crypto_register_alg(struct crypto_alg *alg);
- int crypto_register_algs(struct crypto_alg *algs, int count);
- </programlisting>
-
- <para>
- The counterparts to those functions are listed below.
- </para>
-
- <programlisting>
- int crypto_unregister_alg(struct crypto_alg *alg);
- int crypto_unregister_algs(struct crypto_alg *algs, int count);
- </programlisting>
-
- <para>
- 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 &lt; 0 implies
- an error.
- </para>
-
- <para>
- The bulk registration/unregistration functions
- register/unregister each transformation in the given array of
- length count. They handle errors as follows:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- crypto_unregister_algs() tries to unregister all the given
- transformations, continuing on error. It logs errors and
- always returns zero.
- </para>
- </listitem>
- </itemizedlist>
-
- </sect1>
-
- <sect1><title>Single-Block Symmetric Ciphers [CIPHER]</title>
- <para>
- Example of transformations: aes, arc4, ...
- </para>
-
- <para>
- 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.
- </para>
-
- <sect2><title>Registration specifics</title>
- <para>
- 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.
- </para>
-
- <para>
- See struct cipher_alg below.
- </para>
- </sect2>
-
- <sect2><title>Cipher Definition With struct cipher_alg</title>
- <para>
- Struct cipher_alg defines a single block cipher.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- <programlisting>
- KEY ---. PLAINTEXT ---.
- v v
- .cia_setkey() -&gt; .cia_encrypt()
- |
- '-----&gt; CIPHERTEXT
- </programlisting>
- </para>
-
- <para>
- Please note that a pattern where .cia_setkey() is called
- multiple times is also valid:
- </para>
-
- <para>
- <programlisting>
-
- KEY1 --. PLAINTEXT1 --. KEY2 --. PLAINTEXT2 --.
- v v v v
- .cia_setkey() -&gt; .cia_encrypt() -&gt; .cia_setkey() -&gt; .cia_encrypt()
- | |
- '---&gt; CIPHERTEXT1 '---&gt; CIPHERTEXT2
- </programlisting>
- </para>
-
- </sect2>
- </sect1>
-
- <sect1><title>Multi-Block Ciphers</title>
- <para>
- Example of transformations: cbc(aes), ecb(arc4), ...
- </para>
-
- <para>
- 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.
- </para>
-
- <sect2><title>Registration Specifics</title>
-
- <para>
- The registration of multi-block cipher algorithms
- is one of the most standard procedures throughout the crypto API.
- </para>
-
- <para>
- 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.
- </para>
- </sect2>
-
- <sect2><title>Cipher Definition With struct blkcipher_alg and ablkcipher_alg</title>
- <para>
- Struct blkcipher_alg defines a synchronous block cipher whereas
- struct ablkcipher_alg defines an asynchronous block cipher.
- </para>
-
- <para>
- Please refer to the single block cipher description for schematics
- of the block cipher usage.
- </para>
- </sect2>
-
- <sect2><title>Specifics Of Asynchronous Multi-Block Cipher</title>
- <para>
- There are a couple of specifics to the asynchronous interface.
- </para>
-
- <para>
- 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.
- </para>
- </sect2>
- </sect1>
-
- <sect1><title>Hashing [HASH]</title>
-
- <para>
- Example of transformations: crc32, md5, sha1, sha256,...
- </para>
-
- <sect2><title>Registering And Unregistering The Transformation</title>
-
- <para>
- 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:
- </para>
-
- <programlisting>
- 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);
- </programlisting>
-
- <para>
- The respective counterparts for unregistering the HASH
- transformation are as follows:
- </para>
-
- <programlisting>
- 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);
- </programlisting>
- </sect2>
-
- <sect2><title>Cipher Definition With struct shash_alg and ahash_alg</title>
- <para>
- 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.
- </para>
-
- <programlisting>
- I) DATA -----------.
- v
- .init() -&gt; .update() -&gt; .final() ! .update() might not be called
- ^ | | at all in this scenario.
- '----' '---&gt; HASH
-
- II) DATA -----------.-----------.
- v v
- .init() -&gt; .update() -&gt; .finup() ! .update() may not be called
- ^ | | at all in this scenario.
- '----' '---&gt; HASH
-
- III) DATA -----------.
- v
- .digest() ! The entire process is handled
- | by the .digest() call.
- '---------------&gt; HASH
- </programlisting>
-
- <para>
- Here is a schematic of how the .export()/.import() functions are
- called when used from another part of the kernel.
- </para>
-
- <programlisting>
- KEY--. DATA--.
- v v ! .update() may not be called
- .setkey() -&gt; .init() -&gt; .update() -&gt; .export() at all in this scenario.
- ^ | |
- '-----' '--&gt; PARTIAL_HASH
-
- ----------- other transformations happen here -----------
-
- PARTIAL_HASH--. DATA1--.
- v v
- .import -&gt; .update() -&gt; .final() ! .update() may not be called
- ^ | | at all in this scenario.
- '----' '--&gt; HASH1
-
- PARTIAL_HASH--. DATA2-.
- v v
- .import -&gt; .finup()
- |
- '---------------&gt; HASH2
- </programlisting>
- </sect2>
-
- <sect2><title>Specifics Of Asynchronous HASH Transformation</title>
- <para>
- 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.
- </para>
- </sect2>
- </sect1>
- </chapter>
-
- <chapter id="User"><title>User Space Interface</title>
- <sect1><title>Introduction</title>
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- [1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
- </para>
-
- </sect1>
-
- <sect1><title>User Space API General Remarks</title>
- <para>
- The kernel crypto API is accessible from user space. Currently,
- the following ciphers are accessible:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>Message digest including keyed message digest (HMAC, CMAC)</para>
- </listitem>
-
- <listitem>
- <para>Symmetric ciphers</para>
- </listitem>
-
- <listitem>
- <para>AEAD ciphers</para>
- </listitem>
-
- <listitem>
- <para>Random Number Generators</para>
- </listitem>
- </itemizedlist>
-
- <para>
- 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:
- </para>
-
- <programlisting>
-#ifndef AF_ALG
-#define AF_ALG 38
-#endif
-#ifndef SOL_ALG
-#define SOL_ALG 279
-#endif
- </programlisting>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- To initialize the socket interface, the following sequence has to
- be performed by the consumer:
- </para>
-
- <orderedlist>
- <listitem>
- <para>
- Create a socket of type AF_ALG with the struct sockaddr_alg
- parameter specified below for the different cipher types.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Invoke bind with the socket descriptor
- </para>
- </listitem>
-
- <listitem>
- <para>
- 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.
- </para>
- </listitem>
- </orderedlist>
- </sect1>
-
- <sect1><title>In-place Cipher operation</title>
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
- </sect1>
-
- <sect1><title>Message Digest API</title>
- <para>
- 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:
- </para>
-
- <programlisting>
-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 */
-};
- </programlisting>
-
- <para>
- 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.
- </para>
-
- <para>
- 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:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- 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.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
- </sect1>
-
- <sect1><title>Symmetric Cipher API</title>
- <para>
- The operation is very similar to the message digest discussion.
- During initialization, the struct sockaddr data structure must be
- filled as follows:
- </para>
-
- <programlisting>
-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 */
-};
- </programlisting>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- specification of the cipher operation type with one of these flags:
- </para>
- <itemizedlist>
- <listitem>
- <para>ALG_OP_ENCRYPT - encryption of data</para>
- </listitem>
- <listitem>
- <para>ALG_OP_DECRYPT - decryption of data</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- specification of the IV information marked with the flag ALG_SET_IV
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The send system call family allows the following flag to be specified:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- 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.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
- </sect1>
-
- <sect1><title>AEAD Cipher API</title>
- <para>
- The operation is very similar to the symmetric cipher discussion.
- During initialization, the struct sockaddr data structure must be
- filled as follows:
- </para>
-
- <programlisting>
-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 */
-};
- </programlisting>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- specification of the cipher operation type with one of these flags:
- </para>
- <itemizedlist>
- <listitem>
- <para>ALG_OP_ENCRYPT - encryption of data</para>
- </listitem>
- <listitem>
- <para>ALG_OP_DECRYPT - decryption of data</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- specification of the IV information marked with the flag ALG_SET_IV
- </para>
- </listitem>
-
- <listitem>
- <para>
- 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.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The send system call family allows the following flag to be specified:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- 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.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- The authenticated decryption operation may indicate an integrity error.
- Such breach in integrity is marked with the -EBADMSG error code.
- </para>
-
- <sect2><title>AEAD Memory Structure</title>
- <para>
- The AEAD cipher operates with the following information that
- is communicated between user and kernel space as one data stream:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>plaintext or ciphertext</para>
- </listitem>
-
- <listitem>
- <para>associated authentication data (AAD)</para>
- </listitem>
-
- <listitem>
- <para>authentication tag</para>
- </listitem>
- </itemizedlist>
-
- <para>
- 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.
- </para>
-
- <para>
- The user space caller must arrange the aforementioned information
- in the following order:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- AEAD encryption input: AAD || plaintext
- </para>
- </listitem>
-
- <listitem>
- <para>
- AEAD decryption input: AAD || ciphertext || authentication tag
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The output buffer the user space caller provides must be at least as
- large to hold the following data:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- AEAD encryption output: ciphertext || authentication tag
- </para>
- </listitem>
-
- <listitem>
- <para>
- AEAD decryption output: plaintext
- </para>
- </listitem>
- </itemizedlist>
- </sect2>
- </sect1>
-
- <sect1><title>Random Number Generator API</title>
- <para>
- Again, the operation is very similar to the other APIs.
- During initialization, the struct sockaddr data structure must be
- filled as follows:
- </para>
-
- <programlisting>
-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 */
-};
- </programlisting>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- </sect1>
-
- <sect1><title>Zero-Copy Interface</title>
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- Zero-copy can be used with the following code example (a complete working
- example is provided with libkcapi):
- </para>
-
- <programlisting>
-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);
- </programlisting>
-
- </sect1>
-
- <sect1><title>Setsockopt Interface</title>
- <para>
- 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).
- </para>
-
- <para>
- Each setsockopt invocation must use the level SOL_ALG.
- </para>
-
- <para>
- The setsockopt interface allows setting the following data using
- the mentioned optname:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- ALG_SET_KEY -- Setting the key. Key setting is applicable to:
- </para>
- <itemizedlist>
- <listitem>
- <para>the skcipher cipher type (symmetric ciphers)</para>
- </listitem>
- <listitem>
- <para>the hash cipher type (keyed message digests)</para>
- </listitem>
- <listitem>
- <para>the AEAD cipher type</para>
- </listitem>
- <listitem>
- <para>the RNG cipher type to provide the seed</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- 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).
- </para>
- </listitem>
- </itemizedlist>
-
- </sect1>
-
- <sect1><title>User space API example</title>
- <para>
- 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.
- </para>
-
- <para>
- [1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
- </para>
-
- </sect1>
-
- </chapter>
-
- <chapter id="API"><title>Programming Interface</title>
- <para>
- 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.
- </para>
- <sect1><title>Block Cipher Context Data Structures</title>
-!Pinclude/linux/crypto.h Block Cipher Context Data Structures
-!Finclude/crypto/aead.h aead_request
- </sect1>
- <sect1><title>Block Cipher Algorithm Definitions</title>
-!Pinclude/linux/crypto.h Block Cipher Algorithm Definitions
-!Finclude/linux/crypto.h crypto_alg
-!Finclude/linux/crypto.h ablkcipher_alg
-!Finclude/crypto/aead.h aead_alg
-!Finclude/linux/crypto.h blkcipher_alg
-!Finclude/linux/crypto.h cipher_alg
-!Finclude/crypto/rng.h rng_alg
- </sect1>
- <sect1><title>Symmetric Key Cipher API</title>
-!Pinclude/crypto/skcipher.h Symmetric Key Cipher API
-!Finclude/crypto/skcipher.h crypto_alloc_skcipher
-!Finclude/crypto/skcipher.h crypto_free_skcipher
-!Finclude/crypto/skcipher.h crypto_has_skcipher
-!Finclude/crypto/skcipher.h crypto_skcipher_ivsize
-!Finclude/crypto/skcipher.h crypto_skcipher_blocksize
-!Finclude/crypto/skcipher.h crypto_skcipher_setkey
-!Finclude/crypto/skcipher.h crypto_skcipher_reqtfm
-!Finclude/crypto/skcipher.h crypto_skcipher_encrypt
-!Finclude/crypto/skcipher.h crypto_skcipher_decrypt
- </sect1>
- <sect1><title>Symmetric Key Cipher Request Handle</title>
-!Pinclude/crypto/skcipher.h Symmetric Key Cipher Request Handle
-!Finclude/crypto/skcipher.h crypto_skcipher_reqsize
-!Finclude/crypto/skcipher.h skcipher_request_set_tfm
-!Finclude/crypto/skcipher.h skcipher_request_alloc
-!Finclude/crypto/skcipher.h skcipher_request_free
-!Finclude/crypto/skcipher.h skcipher_request_set_callback
-!Finclude/crypto/skcipher.h skcipher_request_set_crypt
- </sect1>
- <sect1><title>Asynchronous Block Cipher API - Deprecated</title>
-!Pinclude/linux/crypto.h Asynchronous Block Cipher API
-!Finclude/linux/crypto.h crypto_alloc_ablkcipher
-!Finclude/linux/crypto.h crypto_free_ablkcipher
-!Finclude/linux/crypto.h crypto_has_ablkcipher
-!Finclude/linux/crypto.h crypto_ablkcipher_ivsize
-!Finclude/linux/crypto.h crypto_ablkcipher_blocksize
-!Finclude/linux/crypto.h crypto_ablkcipher_setkey
-!Finclude/linux/crypto.h crypto_ablkcipher_reqtfm
-!Finclude/linux/crypto.h crypto_ablkcipher_encrypt
-!Finclude/linux/crypto.h crypto_ablkcipher_decrypt
- </sect1>
- <sect1><title>Asynchronous Cipher Request Handle - Deprecated</title>
-!Pinclude/linux/crypto.h Asynchronous Cipher Request Handle
-!Finclude/linux/crypto.h crypto_ablkcipher_reqsize
-!Finclude/linux/crypto.h ablkcipher_request_set_tfm
-!Finclude/linux/crypto.h ablkcipher_request_alloc
-!Finclude/linux/crypto.h ablkcipher_request_free
-!Finclude/linux/crypto.h ablkcipher_request_set_callback
-!Finclude/linux/crypto.h ablkcipher_request_set_crypt
- </sect1>
- <sect1><title>Authenticated Encryption With Associated Data (AEAD) Cipher API</title>
-!Pinclude/crypto/aead.h Authenticated Encryption With Associated Data (AEAD) Cipher API
-!Finclude/crypto/aead.h crypto_alloc_aead
-!Finclude/crypto/aead.h crypto_free_aead
-!Finclude/crypto/aead.h crypto_aead_ivsize
-!Finclude/crypto/aead.h crypto_aead_authsize
-!Finclude/crypto/aead.h crypto_aead_blocksize
-!Finclude/crypto/aead.h crypto_aead_setkey
-!Finclude/crypto/aead.h crypto_aead_setauthsize
-!Finclude/crypto/aead.h crypto_aead_encrypt
-!Finclude/crypto/aead.h crypto_aead_decrypt
- </sect1>
- <sect1><title>Asynchronous AEAD Request Handle</title>
-!Pinclude/crypto/aead.h Asynchronous AEAD Request Handle
-!Finclude/crypto/aead.h crypto_aead_reqsize
-!Finclude/crypto/aead.h aead_request_set_tfm
-!Finclude/crypto/aead.h aead_request_alloc
-!Finclude/crypto/aead.h aead_request_free
-!Finclude/crypto/aead.h aead_request_set_callback
-!Finclude/crypto/aead.h aead_request_set_crypt
-!Finclude/crypto/aead.h aead_request_set_ad
- </sect1>
- <sect1><title>Synchronous Block Cipher API - Deprecated</title>
-!Pinclude/linux/crypto.h Synchronous Block Cipher API
-!Finclude/linux/crypto.h crypto_alloc_blkcipher
-!Finclude/linux/crypto.h crypto_free_blkcipher
-!Finclude/linux/crypto.h crypto_has_blkcipher
-!Finclude/linux/crypto.h crypto_blkcipher_name
-!Finclude/linux/crypto.h crypto_blkcipher_ivsize
-!Finclude/linux/crypto.h crypto_blkcipher_blocksize
-!Finclude/linux/crypto.h crypto_blkcipher_setkey
-!Finclude/linux/crypto.h crypto_blkcipher_encrypt
-!Finclude/linux/crypto.h crypto_blkcipher_encrypt_iv
-!Finclude/linux/crypto.h crypto_blkcipher_decrypt
-!Finclude/linux/crypto.h crypto_blkcipher_decrypt_iv
-!Finclude/linux/crypto.h crypto_blkcipher_set_iv
-!Finclude/linux/crypto.h crypto_blkcipher_get_iv
- </sect1>
- <sect1><title>Single Block Cipher API</title>
-!Pinclude/linux/crypto.h Single Block Cipher API
-!Finclude/linux/crypto.h crypto_alloc_cipher
-!Finclude/linux/crypto.h crypto_free_cipher
-!Finclude/linux/crypto.h crypto_has_cipher
-!Finclude/linux/crypto.h crypto_cipher_blocksize
-!Finclude/linux/crypto.h crypto_cipher_setkey
-!Finclude/linux/crypto.h crypto_cipher_encrypt_one
-!Finclude/linux/crypto.h crypto_cipher_decrypt_one
- </sect1>
- <sect1><title>Message Digest Algorithm Definitions</title>
-!Pinclude/crypto/hash.h Message Digest Algorithm Definitions
-!Finclude/crypto/hash.h hash_alg_common
-!Finclude/crypto/hash.h ahash_alg
-!Finclude/crypto/hash.h shash_alg
- </sect1>
- <sect1><title>Asynchronous Message Digest API</title>
-!Pinclude/crypto/hash.h Asynchronous Message Digest API
-!Finclude/crypto/hash.h crypto_alloc_ahash
-!Finclude/crypto/hash.h crypto_free_ahash
-!Finclude/crypto/hash.h crypto_ahash_init
-!Finclude/crypto/hash.h crypto_ahash_digestsize
-!Finclude/crypto/hash.h crypto_ahash_reqtfm
-!Finclude/crypto/hash.h crypto_ahash_reqsize
-!Finclude/crypto/hash.h crypto_ahash_setkey
-!Finclude/crypto/hash.h crypto_ahash_finup
-!Finclude/crypto/hash.h crypto_ahash_final
-!Finclude/crypto/hash.h crypto_ahash_digest
-!Finclude/crypto/hash.h crypto_ahash_export
-!Finclude/crypto/hash.h crypto_ahash_import
- </sect1>
- <sect1><title>Asynchronous Hash Request Handle</title>
-!Pinclude/crypto/hash.h Asynchronous Hash Request Handle
-!Finclude/crypto/hash.h ahash_request_set_tfm
-!Finclude/crypto/hash.h ahash_request_alloc
-!Finclude/crypto/hash.h ahash_request_free
-!Finclude/crypto/hash.h ahash_request_set_callback
-!Finclude/crypto/hash.h ahash_request_set_crypt
- </sect1>
- <sect1><title>Synchronous Message Digest API</title>
-!Pinclude/crypto/hash.h Synchronous Message Digest API
-!Finclude/crypto/hash.h crypto_alloc_shash
-!Finclude/crypto/hash.h crypto_free_shash
-!Finclude/crypto/hash.h crypto_shash_blocksize
-!Finclude/crypto/hash.h crypto_shash_digestsize
-!Finclude/crypto/hash.h crypto_shash_descsize
-!Finclude/crypto/hash.h crypto_shash_setkey
-!Finclude/crypto/hash.h crypto_shash_digest
-!Finclude/crypto/hash.h crypto_shash_export
-!Finclude/crypto/hash.h crypto_shash_import
-!Finclude/crypto/hash.h crypto_shash_init
-!Finclude/crypto/hash.h crypto_shash_update
-!Finclude/crypto/hash.h crypto_shash_final
-!Finclude/crypto/hash.h crypto_shash_finup
- </sect1>
- <sect1><title>Crypto API Random Number API</title>
-!Pinclude/crypto/rng.h Random number generator API
-!Finclude/crypto/rng.h crypto_alloc_rng
-!Finclude/crypto/rng.h crypto_rng_alg
-!Finclude/crypto/rng.h crypto_free_rng
-!Finclude/crypto/rng.h crypto_rng_generate
-!Finclude/crypto/rng.h crypto_rng_get_bytes
-!Finclude/crypto/rng.h crypto_rng_reset
-!Finclude/crypto/rng.h crypto_rng_seedsize
-!Cinclude/crypto/rng.h
- </sect1>
- <sect1><title>Asymmetric Cipher API</title>
-!Pinclude/crypto/akcipher.h Generic Public Key API
-!Finclude/crypto/akcipher.h akcipher_alg
-!Finclude/crypto/akcipher.h akcipher_request
-!Finclude/crypto/akcipher.h crypto_alloc_akcipher
-!Finclude/crypto/akcipher.h crypto_free_akcipher
-!Finclude/crypto/akcipher.h crypto_akcipher_set_pub_key
-!Finclude/crypto/akcipher.h crypto_akcipher_set_priv_key
- </sect1>
- <sect1><title>Asymmetric Cipher Request Handle</title>
-!Finclude/crypto/akcipher.h akcipher_request_alloc
-!Finclude/crypto/akcipher.h akcipher_request_free
-!Finclude/crypto/akcipher.h akcipher_request_set_callback
-!Finclude/crypto/akcipher.h akcipher_request_set_crypt
-!Finclude/crypto/akcipher.h crypto_akcipher_maxsize
-!Finclude/crypto/akcipher.h crypto_akcipher_encrypt
-!Finclude/crypto/akcipher.h crypto_akcipher_decrypt
-!Finclude/crypto/akcipher.h crypto_akcipher_sign
-!Finclude/crypto/akcipher.h crypto_akcipher_verify
- </sect1>
- </chapter>
-
- <chapter id="Code"><title>Code Examples</title>
- <sect1><title>Code Example For Symmetric Key Cipher Operation</title>
- <programlisting>
-
-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-&gt;data;
-
- if (error == -EINPROGRESS)
- return;
- result-&gt;err = error;
- complete(&amp;result-&gt;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-&gt;req);
- else
- rc = crypto_skcipher_decrypt(sk-&gt;req);
-
- switch (rc) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- rc = wait_for_completion_interruptible(
- &amp;sk-&gt;result.completion);
- if (!rc &amp;&amp; !sk-&gt;result.err) {
- reinit_completion(&amp;sk-&gt;result.completion);
- break;
- }
- default:
- pr_info("skcipher encrypt returned with %d result %d\n",
- rc, sk-&gt;result.err);
- break;
- }
- init_completion(&amp;sk-&gt;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,
- &amp;sk.result);
-
- /* AES 256 with random key */
- get_random_bytes(&amp;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(&amp;sk.sg, scratchpad, 16);
- skcipher_request_set_crypt(req, &amp;sk.sg, &amp;sk.sg, 16, ivdata);
- init_completion(&amp;sk.result.completion);
-
- /* encrypt data */
- ret = test_skcipher_encdec(&amp;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;
-}
- </programlisting>
- </sect1>
-
- <sect1><title>Code Example For Use of Operational State Memory With SHASH</title>
- <programlisting>
-
-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-&gt;shash.tfm = alg;
- sdesc-&gt;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(&amp;sdesc-&gt;shash, data, datalen, digest);
- kfree(sdesc);
- return ret;
-}
- </programlisting>
- </sect1>
-
- <sect1><title>Code Example For Random Number Generator Usage</title>
- <programlisting>
-
-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 &lt; 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;
-}
- </programlisting>
- </sect1>
- </chapter>
- </book>
diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt
index c0d8788e75d3..72292308d0f5 100644
--- a/Documentation/IPMI.txt
+++ b/Documentation/IPMI.txt
@@ -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.
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 2681cbd24cdd..8ddae4e4299a 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -59,6 +59,7 @@ configure specific aspects of kernel behavior to your liking.
binfmt-misc
mono
java
+ ras
.. only:: subproject and html
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index be2d6d0a03a4..21e2d8863705 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1441,6 +1441,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 | ... }
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
new file mode 100644
index 000000000000..d71340e86c27
--- /dev/null
+++ b/Documentation/admin-guide/ras.rst
@@ -0,0 +1,1190 @@
+.. include:: <isonum.txt>
+
+============================================
+Reliability, Availability and Serviceability
+============================================
+
+RAS concepts
+************
+
+Reliability, Availability and Serviceability (RAS) is a concept used on
+servers meant to measure their robusteness.
+
+Reliability
+ is the probability that a system will produce correct outputs.
+
+ * Generally measured as Mean Time Between Failures (MTBF)
+ * Enhanced by features that help to avoid, detect and repair hardware faults
+
+Availability
+ is the probability that a system is operational at a given time
+
+ * Generally measured as a percentage of downtime per a period of time
+ * Often uses mechanisms to detect and correct hardware faults in
+ runtime;
+
+Serviceability (or maintainability)
+ is the simplicity and speed with which a system can be repaired or
+ maintained
+
+ * Generally measured on Mean Time Between Repair (MTBR)
+
+Improving RAS
+-------------
+
+In order to reduce systems downtime, a system should be capable of detecting
+hardware errors, and, when possible correcting them in runtime. It should
+also provide mechanisms to detect hardware degradation, in order to warn
+the system administrator to take the action of replacing a component before
+it causes data loss or system downtime.
+
+Among the monitoring measures, the most usual ones include:
+
+* CPU – detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory – add error correction logic (ECC) to detect and correct errors;
+* I/O – add CRC checksums for tranfered data;
+* Storage – RAID, journal file systems, checksums,
+ Self-Monitoring, Analysis and Reporting Technology (SMART).
+
+By monitoring the number of occurrences of error detections, it is possible
+to identify if the probability of hardware errors is increasing, and, on such
+case, do a preventive maintainance to replace a degrated component while
+those errors are correctable.
+
+Types of errors
+---------------
+
+Most mechanisms used on modern systems use use technologies like Hamming
+Codes that allow error correction when the number of errors on a bit packet
+is below a threshold. If the number of errors is above, those mechanisms
+can indicate with a high degree of confidence that an error happened, but
+they can't correct.
+
+Also, sometimes an error occur on a component that it is not used. For
+example, a part of the memory that it is not currently allocated.
+
+That defines some categories of errors:
+
+* **Correctable Error (CE)** - the error detection mechanism detected and
+ corrected the error. Such errors are usually not fatal, although some
+ Kernel mechanisms allow the system administrator to consider them as fatal.
+
+* **Uncorrected Error (UE)** - the amount of errors happened above the error
+ correction threshold, and the system was unable to auto-correct.
+
+* **Fatal Error** - when an UE error happens on a critical component of the
+ system (for example, a piece of the Kernel got corrupted by an UE), the
+ only reliable way to avoid data corruption is to hang or reboot the machine.
+
+* **Non-fatal Error** - when an UE error happens on an unused component,
+ like a CPU in power down state or an unused memory bank, the system may
+ still run, eventually replacing the affected hardware by a hot spare,
+ if available.
+
+ Also, when an error happens on an userspace process, it is also possible to
+ kill such process and let userspace restart it.
+
+The mechanism for handling non-fatal errors is usually complex and may
+require the help of some userspace application, in order to apply the
+policy desired by the system administrator.
+
+Identifying a bad hardware component
+------------------------------------
+
+Just detecting a hardware flaw is usually not enough, as the system needs
+to pinpoint to the minimal replaceable unit (MRU) that should be exchanged
+to make the hardware reliable again.
+
+So, it requires not only error logging facilities, but also mechanisms that
+will translate the error message to the silkscreen or component label for
+the MRU.
+
+Typically, it is very complex for memory, as modern CPUs interlace memory
+from different memory modules, in order to provide a better performance. The
+DMI BIOS usually have a list of memory module labels, with can be obtained
+using the ``dmidecode`` tool. For example, on a desktop machine, it shows::
+
+ Memory Device
+ Total Width: 64 bits
+ Data Width: 64 bits
+ Size: 16384 MB
+ Form Factor: SODIMM
+ Set: None
+ Locator: ChannelA-DIMM0
+ Bank Locator: BANK 0
+ Type: DDR4
+ Type Detail: Synchronous
+ Speed: 2133 MHz
+ Rank: 2
+ Configured Clock Speed: 2133 MHz
+
+On the above example, a DDR4 SO-DIMM memory module is located at the
+system's memory labeled as "BANK 0", as given by the *bank locator* field.
+Please notice that, on such system, the *total width* is equal to the
+*data witdh*. It means that such memory module doesn't have error
+detection/correction mechanisms.
+
+Unfortunately, not all systems use the same field to specify the memory
+bank. On this example, from an older server, ``dmidecode`` shows::
+
+ Memory Device
+ Array Handle: 0x1000
+ Error Information Handle: Not Provided
+ Total Width: 72 bits
+ Data Width: 64 bits
+ Size: 8192 MB
+ Form Factor: DIMM
+ Set: 1
+ Locator: DIMM_A1
+ Bank Locator: Not Specified
+ Type: DDR3
+ Type Detail: Synchronous Registered (Buffered)
+ Speed: 1600 MHz
+ Rank: 2
+ Configured Clock Speed: 1600 MHz
+
+There, the DDR3 RDIMM memory module is located at the system's memory labeled
+as "DIMM_A1", as given by the *locator* field. Please notice that this
+memory module has 64 bits of *data witdh* and 72 bits of *total width*. So,
+it has 8 extra bits to be used by error detection and correction mechanisms.
+Such kind of memory is called Error-correcting code memory (ECC memory).
+
+To make things even worse, it is not uncommon that systems with different
+labels on their system's board to use exactly the same BIOS, meaning that
+the labels provided by the BIOS won't match the real ones.
+
+ECC memory
+----------
+
+As mentioned on the previous section, ECC memory has extra bits to be
+used for error correction. So, on 64 bit systems, a memory module
+has 64 bits of *data width*, and 74 bits of *total width*. So, there are
+8 bits extra bits to be used for the error detection and correction
+mechanisms. Those extra bits are called *syndrome*\ [#f1]_\ [#f2]_.
+
+So, when the cpu requests the memory controller to write a word with
+*data width*, the memory controller calculates the *syndrome* in real time,
+using Hamming code, or some other error correction code, like SECDED+,
+producing a code with *total width* size. Such code is then written
+on the memory modules.
+
+At read, the *total width* bits code is converted back, using the same
+ECC code used on write, producing a word with *data width* and a *syndrome*.
+The word with *data width* is sent to the CPU, even when errors happen.
+
+The memory controller also looks at the *syndrome* in order to check if
+there was an error, and if the ECC code was able to fix such error.
+If the error was corrected, a Corrected Error (CE) happened. If not, an
+Uncorrected Error (UE) happened.
+
+The information about the CE/UE errors is stored on some special registers
+at the memory controller and can be accessed by reading such registers,
+either by BIOS, by some special CPUs or by Linux EDAC driver. On x86 64
+bit CPUs, such errors can also be retrieved via the Machine Check
+Architecture (MCA)\ [#f3]_.
+
+.. [#f1] Please notice that several memory controllers allow operation on a
+ mode called "Lock-Step", where it groups two memory modules together,
+ doing 128-bit reads/writes. That gives 16 bits for error correction, with
+ significatively improves the error correction mechanism, at the expense
+ that, when an error happens, there's no way to know what memory module is
+ to blame. So, it has to blame both memory modules.
+
+.. [#f2] Some memory controllers also allow using memory in mirror mode.
+ On such mode, the same data is written to two memory modules. At read,
+ the system checks both memory modules, in order to check if both provide
+ identical data. On such configuration, when an error happens, there's no
+ way to know what memory module is to blame. So, it has to blame both
+ memory modules (or 4 memory modules, if the system is also on Lock-step
+ mode).
+
+.. [#f3] For more details about the Machine Check Architecture (MCA),
+ please read Documentation/x86/x86_64/machinecheck at the Kernel tree.
+
+EDAC - Error Detection And Correction
+*************************************
+
+.. note::
+
+ "bluesmoke" was the name for this device driver subsystem when it
+ was "out-of-tree" and maintained at http://bluesmoke.sourceforge.net.
+ That site is mostly archaic now and can be used only for historical
+ purposes.
+
+ When the subsystem was pushed upstream for the first time, on
+ Kernel 2.6.16, for the first time, it was renamed to ``EDAC``.
+
+Purpose
+-------
+
+The ``edac`` kernel module's goal is to detect and report hardware errors
+that occur within the computer system running under linux.
+
+Memory
+------
+
+Memory Correctable Errors (CE) and Uncorrectable Errors (UE) are the
+primary errors being harvested. These types of errors are harvested by
+the ``edac_mc`` device.
+
+Detecting CE events, then harvesting those events and reporting them,
+**can** but must not necessarily be a predictor of future UE events. With
+CE events only, the system can and will continue to operate as no data
+has been damaged yet.
+
+However, preventive maintenance and proactive part replacement of memory
+modules exhibiting CEs can reduce the likelihood of the dreaded UE events
+and system panics.
+
+Other hardware elements
+-----------------------
+
+A new feature for EDAC, the ``edac_device`` class of device, was added in
+the 2.6.23 version of the kernel.
+
+This new device type allows for non-memory type of ECC hardware detectors
+to have their states harvested and presented to userspace via the sysfs
+interface.
+
+Some architectures have ECC detectors for L1, L2 and L3 caches,
+along with DMA engines, fabric switches, main data path switches,
+interconnections, and various other hardware data paths. If the hardware
+reports it, then a edac_device device probably can be constructed to
+harvest and present that to userspace.
+
+
+PCI bus scanning
+----------------
+
+In addition, PCI devices are scanned for PCI Bus Parity and SERR Errors
+in order to determine if errors are occurring during data transfers.
+
+The presence of PCI Parity errors must be examined with a grain of salt.
+There are several add-in adapters that do **not** follow the PCI specification
+with regards to Parity generation and reporting. The specification says
+the vendor should tie the parity status bits to 0 if they do not intend
+to generate parity. Some vendors do not do this, and thus the parity bit
+can "float" giving false positives.
+
+There is a PCI device attribute located in sysfs that is checked by
+the EDAC PCI scanning code. If that attribute is set, PCI parity/error
+scanning is skipped for that device. The attribute is::
+
+ broken_parity_status
+
+and is located in ``/sys/devices/pci<XXX>/0000:XX:YY.Z`` directories for
+PCI devices.
+
+
+Versioning
+----------
+
+EDAC is composed of a "core" module (``edac_core.ko``) and several Memory
+Controller (MC) driver modules. On a given system, the CORE is loaded
+and one MC driver will be loaded. Both the CORE and the MC driver (or
+``edac_device`` driver) have individual versions that reflect current
+release level of their respective modules.
+
+Thus, to "report" on what version a system is running, one must report
+both the CORE's and the MC driver's versions.
+
+
+Loading
+-------
+
+If ``edac`` was statically linked with the kernel then no loading
+is necessary. If ``edac`` was built as modules then simply modprobe
+the ``edac`` pieces that you need. You should be able to modprobe
+hardware-specific modules and have the dependencies load the necessary
+core modules.
+
+Example::
+
+ $ modprobe amd76x_edac
+
+loads both the ``amd76x_edac.ko`` memory controller module and the
+``edac_mc.ko`` core module.
+
+
+Sysfs interface
+---------------
+
+EDAC presents a ``sysfs`` interface for control and reporting purposes. It
+lives in the /sys/devices/system/edac directory.
+
+Within this directory there currently reside 2 components:
+
+ ======= ==============================
+ mc memory controller(s) system
+ pci PCI control and status system
+ ======= ==============================
+
+
+
+Memory Controller (mc) Model
+----------------------------
+
+Each ``mc`` device controls a set of memory modules [#f4]_. These modules
+are laid out in a Chip-Select Row (``csrowX``) and Channel table (``chX``).
+There can be multiple csrows and multiple channels.
+
+.. [#f4] Nowadays, the term DIMM (Dual In-line Memory Module) is widely
+ used to refer to a memory module, although there are other memory
+ packaging alternatives, like SO-DIMM, SIMM, etc. Along this document,
+ and inside the EDAC system, the term "dimm" is used for all memory
+ modules, even when they use a different kind of packaging.
+
+Memory controllers allow for several csrows, with 8 csrows being a
+typical value. Yet, the actual number of csrows depends on the layout of
+a given motherboard, memory controller and memory module characteristics.
+
+Dual channels allow for dual data length (e. g. 128 bits, on 64 bit systems)
+data transfers to/from the CPU from/to memory. Some newer chipsets allow
+for more than 2 channels, like Fully Buffered DIMMs (FB-DIMMs) memory
+controllers. The following example will assume 2 channels:
+
+ +------------+-----------------------+
+ | Chip | Channels |
+ | Select +-----------+-----------+
+ | rows | ``ch0`` | ``ch1`` |
+ +============+===========+===========+
+ | ``csrow0`` | DIMM_A0 | DIMM_B0 |
+ +------------+ | |
+ | ``csrow1`` | | |
+ +------------+-----------+-----------+
+ | ``csrow2`` | DIMM_A1 | DIMM_B1 |
+ +------------+ | |
+ | ``csrow3`` | | |
+ +------------+-----------+-----------+
+
+In the above example, there are 4 physical slots on the motherboard
+for memory DIMMs:
+
+ +---------+---------+
+ | DIMM_A0 | DIMM_B0 |
+ +---------+---------+
+ | DIMM_A1 | DIMM_B1 |
+ +---------+---------+
+
+Labels for these slots are usually silk-screened on the motherboard.
+Slots labeled ``A`` are channel 0 in this example. Slots labeled ``B`` are
+channel 1. Notice that there are two csrows possible on a physical DIMM.
+These csrows are allocated their csrow assignment based on the slot into
+which the memory DIMM is placed. Thus, when 1 DIMM is placed in each
+Channel, the csrows cross both DIMMs.
+
+Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
+Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above
+will have just one csrow (csrow0). csrow1 will be empty. On the other
+hand, when 2 dual ranked DIMMs are similarly placed, then both csrow0
+and csrow1 will be populated. The pattern repeats itself for csrow2 and
+csrow3.
+
+The representation of the above is reflected in the directory
+tree in EDAC's sysfs interface. Starting in directory
+``/sys/devices/system/edac/mc``, each memory controller will be
+represented by its own ``mcX`` directory, where ``X`` is the
+index of the MC::
+
+ ..../edac/mc/
+ |
+ |->mc0
+ |->mc1
+ |->mc2
+ ....
+
+Under each ``mcX`` directory each ``csrowX`` is again represented by a
+``csrowX``, where ``X`` is the csrow index::
+
+ .../mc/mc0/
+ |
+ |->csrow0
+ |->csrow2
+ |->csrow3
+ ....
+
+Notice that there is no csrow1, which indicates that csrow0 is composed
+of a single ranked DIMMs. This should also apply in both Channels, in
+order to have dual-channel mode be operational. Since both csrow2 and
+csrow3 are populated, this indicates a dual ranked set of DIMMs for
+channels 0 and 1.
+
+Within each of the ``mcX`` and ``csrowX`` directories are several EDAC
+control and attribute files.
+
+``mcX`` directories
+-------------------
+
+In ``mcX`` directories are EDAC control and attribute files for
+this ``X`` instance of the memory controllers.
+
+For a description of the sysfs API, please see:
+
+ Documentation/ABI/testing/sysfs-devices-edac
+
+
+``dimmX`` or ``rankX`` directories
+----------------------------------
+
+The recommended way to use the EDAC subsystem is to look at the information
+provided by the ``dimmX`` or ``rankX`` directories [#f5]_.
+
+A typical EDAC system has the following structure under
+``/sys/devices/system/edac/``\ [#f6]_::
+
+ /sys/devices/system/edac/
+ ├── mc
+ │   ├── mc0
+ │   │   ├── ce_count
+ │   │   ├── ce_noinfo_count
+ │   │   ├── dimm0
+ │   │   │   ├── dimm_dev_type
+ │   │   │   ├── dimm_edac_mode
+ │   │   │   ├── dimm_label
+ │   │   │   ├── dimm_location
+ │   │   │   ├── dimm_mem_type
+ │   │   │   ├── size
+ │   │   │   └── uevent
+ │   │   ├── max_location
+ │   │   ├── mc_name
+ │   │   ├── reset_counters
+ │   │   ├── seconds_since_reset
+ │   │   ├── size_mb
+ │   │   ├── ue_count
+ │   │   ├── ue_noinfo_count
+ │   │   └── uevent
+ │   ├── mc1
+ │   │   ├── ce_count
+ │   │   ├── ce_noinfo_count
+ │   │   ├── dimm0
+ │   │   │   ├── dimm_dev_type
+ │   │   │   ├── dimm_edac_mode
+ │   │   │   ├── dimm_label
+ │   │   │   ├── dimm_location
+ │   │   │   ├── dimm_mem_type
+ │   │   │   ├── size
+ │   │   │   └── uevent
+ │   │   ├── max_location
+ │   │   ├── mc_name
+ │   │   ├── reset_counters
+ │   │   ├── seconds_since_reset
+ │   │   ├── size_mb
+ │   │   ├── ue_count
+ │   │   ├── ue_noinfo_count
+ │   │   └── uevent
+ │   └── uevent
+ └── uevent
+
+In the ``dimmX`` directories are EDAC control and attribute files for
+this ``X`` memory module:
+
+- ``size`` - Total memory managed by this csrow attribute file
+
+ This attribute file displays, in count of megabytes, the memory
+ that this csrow contains.
+
+- ``dimm_dev_type`` - Device type attribute file
+
+ This attribute file will display what type of DRAM device is
+ being utilized on this DIMM.
+ Examples:
+
+ - x1
+ - x2
+ - x4
+ - x8
+
+- ``dimm_edac_mode`` - EDAC Mode of operation attribute file
+
+ This attribute file will display what type of Error detection
+ and correction is being utilized.
+
+- ``dimm_label`` - memory module label control file
+
+ This control file allows this DIMM to have a label assigned
+ to it. With this label in the module, when errors occur
+ the output can provide the DIMM label in the system log.
+ This becomes vital for panic events to isolate the
+ cause of the UE event.
+
+ DIMM Labels must be assigned after booting, with information
+ that correctly identifies the physical slot with its
+ silk screen label. This information is currently very
+ motherboard specific and determination of this information
+ must occur in userland at this time.
+
+- ``dimm_location`` - location of the memory module
+
+ The location can have up to 3 levels, and describe how the
+ memory controller identifies the location of a memory module.
+ Depending on the type of memory and memory controller, it
+ can be:
+
+ - *csrow* and *channel* - used when the memory controller
+ doesn't identify a single DIMM - e. g. in ``rankX`` dir;
+ - *branch*, *channel*, *slot* - typically used on FB-DIMM memory
+ controllers;
+ - *channel*, *slot* - used on Nehalem and newer Intel drivers.
+
+- ``dimm_mem_type`` - Memory Type attribute file
+
+ This attribute file will display what type of memory is currently
+ on this csrow. Normally, either buffered or unbuffered memory.
+ Examples:
+
+ - Registered-DDR
+ - Unbuffered-DDR
+
+.. [#f5] On some systems, the memory controller doesn't have any logic
+ to identify the memory module. On such systems, the directory is called ``rankX`` and works on a similar way as the ``csrowX`` directories.
+ On modern Intel memory controllers, the memory controller identifies the
+ memory modules directly. On such systems, the directory is called ``dimmX``.
+
+.. [#f6] There are also some ``power`` directories and ``subsystem``
+ symlinks inside the sysfs mapping that are automatically created by
+ the sysfs subsystem. Currently, they serve no purpose.
+
+``csrowX`` directories
+----------------------
+
+When CONFIG_EDAC_LEGACY_SYSFS is enabled, sysfs will contain the ``csrowX``
+directories. As this API doesn't work properly for Rambus, FB-DIMMs and
+modern Intel Memory Controllers, this is being deprecated in favor of
+``dimmX`` directories.
+
+In the ``csrowX`` directories are EDAC control and attribute files for
+this ``X`` instance of csrow:
+
+
+- ``ue_count`` - Total Uncorrectable Errors count attribute file
+
+ This attribute file displays the total count of uncorrectable
+ errors that have occurred on this csrow. If panic_on_ue is set
+ this counter will not have a chance to increment, since EDAC
+ will panic the system.
+
+
+- ``ce_count`` - Total Correctable Errors count attribute file
+
+ This attribute file displays the total count of correctable
+ errors that have occurred on this csrow. This count is very
+ important to examine. CEs provide early indications that a
+ DIMM is beginning to fail. This count field should be
+ monitored for non-zero values and report such information
+ to the system administrator.
+
+
+- ``size_mb`` - Total memory managed by this csrow attribute file
+
+ This attribute file displays, in count of megabytes, the memory
+ that this csrow contains.
+
+
+- ``mem_type`` - Memory Type attribute file
+
+ This attribute file will display what type of memory is currently
+ on this csrow. Normally, either buffered or unbuffered memory.
+ Examples:
+
+ - Registered-DDR
+ - Unbuffered-DDR
+
+
+- ``edac_mode`` - EDAC Mode of operation attribute file
+
+ This attribute file will display what type of Error detection
+ and correction is being utilized.
+
+
+- ``dev_type`` - Device type attribute file
+
+ This attribute file will display what type of DRAM device is
+ being utilized on this DIMM.
+ Examples:
+
+ - x1
+ - x2
+ - x4
+ - x8
+
+
+- ``ch0_ce_count`` - Channel 0 CE Count attribute file
+
+ This attribute file will display the count of CEs on this
+ DIMM located in channel 0.
+
+
+- ``ch0_ue_count`` - Channel 0 UE Count attribute file
+
+ This attribute file will display the count of UEs on this
+ DIMM located in channel 0.
+
+
+- ``ch0_dimm_label`` - Channel 0 DIMM Label control file
+
+
+ This control file allows this DIMM to have a label assigned
+ to it. With this label in the module, when errors occur
+ the output can provide the DIMM label in the system log.
+ This becomes vital for panic events to isolate the
+ cause of the UE event.
+
+ DIMM Labels must be assigned after booting, with information
+ that correctly identifies the physical slot with its
+ silk screen label. This information is currently very
+ motherboard specific and determination of this information
+ must occur in userland at this time.
+
+
+- ``ch1_ce_count`` - Channel 1 CE Count attribute file
+
+
+ This attribute file will display the count of CEs on this
+ DIMM located in channel 1.
+
+
+- ``ch1_ue_count`` - Channel 1 UE Count attribute file
+
+
+ This attribute file will display the count of UEs on this
+ DIMM located in channel 0.
+
+
+- ``ch1_dimm_label`` - Channel 1 DIMM Label control file
+
+ This control file allows this DIMM to have a label assigned
+ to it. With this label in the module, when errors occur
+ the output can provide the DIMM label in the system log.
+ This becomes vital for panic events to isolate the
+ cause of the UE event.
+
+ DIMM Labels must be assigned after booting, with information
+ that correctly identifies the physical slot with its
+ silk screen label. This information is currently very
+ motherboard specific and determination of this information
+ must occur in userland at this time.
+
+
+System Logging
+--------------
+
+If logging for UEs and CEs is enabled, then system logs will contain
+information indicating that errors have been detected::
+
+ EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0, channel 1 "DIMM_B1": amd76x_edac
+ EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0, channel 1 "DIMM_B1": amd76x_edac
+
+
+The structure of the message is:
+
+ +---------------------------------------+-------------+
+ | Content + Example |
+ +=======================================+=============+
+ | The memory controller | MC0 |
+ +---------------------------------------+-------------+
+ | Error type | CE |
+ +---------------------------------------+-------------+
+ | Memory page | 0x283 |
+ +---------------------------------------+-------------+
+ | Offset in the page | 0xce0 |
+ +---------------------------------------+-------------+
+ | The byte granularity | grain 8 |
+ | or resolution of the error | |
+ +---------------------------------------+-------------+
+ | The error syndrome | 0xb741 |
+ +---------------------------------------+-------------+
+ | Memory row | row 0 +
+ +---------------------------------------+-------------+
+ | Memory channel | channel 1 |
+ +---------------------------------------+-------------+
+ | DIMM label, if set prior | DIMM B1 |
+ +---------------------------------------+-------------+
+ | And then an optional, driver-specific | |
+ | message that may have additional | |
+ | information. | |
+ +---------------------------------------+-------------+
+
+Both UEs and CEs with no info will lack all but memory controller, error
+type, a notice of "no info" and then an optional, driver-specific error
+message.
+
+
+PCI Bus Parity Detection
+------------------------
+
+On Header Type 00 devices, the primary status is looked at for any
+parity error regardless of whether parity is enabled on the device or
+not. (The spec indicates parity is generated in some cases). On Header
+Type 01 bridges, the secondary status register is also looked at to see
+if parity occurred on the bus on the other side of the bridge.
+
+
+Sysfs configuration
+-------------------
+
+Under ``/sys/devices/system/edac/pci`` are control and attribute files as
+follows:
+
+
+- ``check_pci_parity`` - Enable/Disable PCI Parity checking control file
+
+ This control file enables or disables the PCI Bus Parity scanning
+ operation. Writing a 1 to this file enables the scanning. Writing
+ a 0 to this file disables the scanning.
+
+ Enable::
+
+ echo "1" >/sys/devices/system/edac/pci/check_pci_parity
+
+ Disable::
+
+ echo "0" >/sys/devices/system/edac/pci/check_pci_parity
+
+
+- ``pci_parity_count`` - Parity Count
+
+ This attribute file will display the number of parity errors that
+ have been detected.
+
+
+Module parameters
+-----------------
+
+- ``edac_mc_panic_on_ue`` - Panic on UE control file
+
+ An uncorrectable error will cause a machine panic. This is usually
+ desirable. It is a bad idea to continue when an uncorrectable error
+ occurs - it is indeterminate what was uncorrected and the operating
+ system context might be so mangled that continuing will lead to further
+ corruption. If the kernel has MCE configured, then EDAC will never
+ notice the UE.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_panic_on_ue=[0|1]
+
+ RUN TIME::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue
+
+
+- ``edac_mc_log_ue`` - Log UE control file
+
+
+ Generate kernel messages describing uncorrectable errors. These errors
+ are reported through the system message log system. UE statistics
+ will be accumulated even when UE logging is disabled.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_log_ue=[0|1]
+
+ RUN TIME::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue
+
+
+- ``edac_mc_log_ce`` - Log CE control file
+
+
+ Generate kernel messages describing correctable errors. These
+ errors are reported through the system message log system.
+ CE statistics will be accumulated even when CE logging is disabled.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_log_ce=[0|1]
+
+ RUN TIME::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce
+
+
+- ``edac_mc_poll_msec`` - Polling period control file
+
+
+ The time period, in milliseconds, for polling for error information.
+ Too small a value wastes resources. Too large a value might delay
+ necessary handling of errors and might loose valuable information for
+ locating the error. 1000 milliseconds (once each second) is the current
+ default. Systems which require all the bandwidth they can get, may
+ increase this.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_poll_msec=[0|1]
+
+ RUN TIME::
+
+ echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec
+
+
+- ``panic_on_pci_parity`` - Panic on PCI PARITY Error
+
+
+ This control file enables or disables panicking when a parity
+ error has been detected.
+
+
+ module/kernel parameter::
+
+ edac_panic_on_pci_pe=[0|1]
+
+ Enable::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
+
+ Disable::
+
+ echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
+
+
+
+EDAC device type
+----------------
+
+In the header file, edac_pci.h, there is a series of edac_device structures
+and APIs for the EDAC_DEVICE.
+
+User space access to an edac_device is through the sysfs interface.
+
+At the location ``/sys/devices/system/edac`` (sysfs) new edac_device devices
+will appear.
+
+There is a three level tree beneath the above ``edac`` directory. For example,
+the ``test_device_edac`` device (found at the http://bluesmoke.sourceforget.net
+website) installs itself as::
+
+ /sys/devices/system/edac/test-instance
+
+in this directory are various controls, a symlink and one or more ``instance``
+directories.
+
+The standard default controls are:
+
+ ============== =======================================================
+ log_ce boolean to log CE events
+ log_ue boolean to log UE events
+ panic_on_ue boolean to ``panic`` the system if an UE is encountered
+ (default off, can be set true via startup script)
+ poll_msec time period between POLL cycles for events
+ ============== =======================================================
+
+The test_device_edac device adds at least one of its own custom control:
+
+ ============== ==================================================
+ test_bits which in the current test driver does nothing but
+ show how it is installed. A ported driver can
+ add one or more such controls and/or attributes
+ for specific uses.
+ One out-of-tree driver uses controls here to allow
+ for ERROR INJECTION operations to hardware
+ injection registers
+ ============== ==================================================
+
+The symlink points to the 'struct dev' that is registered for this edac_device.
+
+Instances
+---------
+
+One or more instance directories are present. For the ``test_device_edac``
+case:
+
+ +----------------+
+ | test-instance0 |
+ +----------------+
+
+
+In this directory there are two default counter attributes, which are totals of
+counter in deeper subdirectories.
+
+ ============== ====================================
+ ce_count total of CE events of subdirectories
+ ue_count total of UE events of subdirectories
+ ============== ====================================
+
+Blocks
+------
+
+At the lowest directory level is the ``block`` directory. There can be 0, 1
+or more blocks specified in each instance:
+
+ +-------------+
+ | test-block0 |
+ +-------------+
+
+In this directory the default attributes are:
+
+ ============== ================================================
+ ce_count which is counter of CE events for this ``block``
+ of hardware being monitored
+ ue_count which is counter of UE events for this ``block``
+ of hardware being monitored
+ ============== ================================================
+
+
+The ``test_device_edac`` device adds 4 attributes and 1 control:
+
+ ================== ====================================================
+ test-block-bits-0 for every POLL cycle this counter
+ is incremented
+ test-block-bits-1 every 10 cycles, this counter is bumped once,
+ and test-block-bits-0 is set to 0
+ test-block-bits-2 every 100 cycles, this counter is bumped once,
+ and test-block-bits-1 is set to 0
+ test-block-bits-3 every 1000 cycles, this counter is bumped once,
+ and test-block-bits-2 is set to 0
+ ================== ====================================================
+
+
+ ================== ====================================================
+ reset-counters writing ANY thing to this control will
+ reset all the above counters.
+ ================== ====================================================
+
+
+Use of the ``test_device_edac`` driver should enable any others to create their own
+unique drivers for their hardware systems.
+
+The ``test_device_edac`` sample driver is located at the
+http://bluesmoke.sourceforge.net project site for EDAC.
+
+
+Usage of EDAC APIs on Nehalem and newer Intel CPUs
+--------------------------------------------------
+
+On older Intel architectures, the memory controller was part of the North
+Bridge chipset. Nehalem, Sandy Bridge, Ivy Bridge, Haswell, Sky Lake and
+newer Intel architectures integrated an enhanced version of the memory
+controller (MC) inside the CPUs.
+
+This chapter will cover the differences of the enhanced memory controllers
+found on newer Intel CPUs, such as ``i7core_edac``, ``sb_edac`` and
+``sbx_edac`` drivers.
+
+.. note::
+
+ The Xeon E7 processor families use a separate chip for the memory
+ controller, called Intel Scalable Memory Buffer. This section doesn't
+ apply for such families.
+
+1) There is one Memory Controller per Quick Patch Interconnect
+ (QPI). At the driver, the term "socket" means one QPI. This is
+ associated with a physical CPU socket.
+
+ Each MC have 3 physical read channels, 3 physical write channels and
+ 3 logic channels. The driver currently sees it as just 3 channels.
+ Each channel can have up to 3 DIMMs.
+
+ The minimum known unity is DIMMs. There are no information about csrows.
+ As EDAC API maps the minimum unity is csrows, the driver sequentially
+ maps channel/DIMM into different csrows.
+
+ For example, supposing the following layout::
+
+ Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
+ dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+ dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
+ Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
+ dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+ Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
+ dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+
+ The driver will map it as::
+
+ csrow0: channel 0, dimm0
+ csrow1: channel 0, dimm1
+ csrow2: channel 1, dimm0
+ csrow3: channel 2, dimm0
+
+ exports one DIMM per csrow.
+
+ Each QPI is exported as a different memory controller.
+
+2) The MC has the ability to inject errors to test drivers. The drivers
+ implement this functionality via some error injection nodes:
+
+ For injecting a memory error, there are some sysfs nodes, under
+ ``/sys/devices/system/edac/mc/mc?/``:
+
+ - ``inject_addrmatch/*``:
+ Controls the error injection mask register. It is possible to specify
+ several characteristics of the address to match an error code::
+
+ dimm = the affected dimm. Numbers are relative to a channel;
+ rank = the memory rank;
+ channel = the channel that will generate an error;
+ bank = the affected bank;
+ page = the page address;
+ column (or col) = the address column.
+
+ each of the above values can be set to "any" to match any valid value.
+
+ At driver init, all values are set to any.
+
+ For example, to generate an error at rank 1 of dimm 2, for any channel,
+ any bank, any page, any column::
+
+ echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
+ echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
+
+ To return to the default behaviour of matching any, you can do::
+
+ echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
+ echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
+
+ - ``inject_eccmask``:
+ specifies what bits will have troubles,
+
+ - ``inject_section``:
+ specifies what ECC cache section will get the error::
+
+ 3 for both
+ 2 for the highest
+ 1 for the lowest
+
+ - ``inject_type``:
+ specifies the type of error, being a combination of the following bits::
+
+ bit 0 - repeat
+ bit 1 - ecc
+ bit 2 - parity
+
+ - ``inject_enable``:
+ starts the error generation when something different than 0 is written.
+
+ All inject vars can be read. root permission is needed for write.
+
+ Datasheet states that the error will only be generated after a write on an
+ address that matches inject_addrmatch. It seems, however, that reading will
+ also produce an error.
+
+ For example, the following code will generate an error for any write access
+ at socket 0, on any DIMM/address on channel 2::
+
+ echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
+ echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
+ echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
+ echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
+ echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
+ dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
+
+ For socket 1, it is needed to replace "mc0" by "mc1" at the above
+ commands.
+
+ The generated error message will look like::
+
+ EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
+
+3) Corrected Error memory register counters
+
+ Those newer MCs have some registers to count memory errors. The driver
+ uses those registers to report Corrected Errors on devices with Registered
+ DIMMs.
+
+ However, those counters don't work with Unregistered DIMM. As the chipset
+ offers some counters that also work with UDIMMs (but with a worse level of
+ granularity than the default ones), the driver exposes those registers for
+ UDIMM memories.
+
+ They can be read by looking at the contents of ``all_channel_counts/``::
+
+ $ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
+ /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
+ 0
+ /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
+ 0
+ /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
+ 0
+
+ What happens here is that errors on different csrows, but at the same
+ dimm number will increment the same counter.
+ So, in this memory mapping::
+
+ csrow0: channel 0, dimm0
+ csrow1: channel 0, dimm1
+ csrow2: channel 1, dimm0
+ csrow3: channel 2, dimm0
+
+ The hardware will increment udimm0 for an error at the first dimm at either
+ csrow0, csrow2 or csrow3;
+
+ The hardware will increment udimm1 for an error at the second dimm at either
+ csrow0, csrow2 or csrow3;
+
+ The hardware will increment udimm2 for an error at the third dimm at either
+ csrow0, csrow2 or csrow3;
+
+4) Standard error counters
+
+ The standard error counters are generated when an mcelog error is received
+ by the driver. Since, with UDIMM, this is counted by software, it is
+ possible that some errors could be lost. With RDIMM's, they display the
+ contents of the registers
+
+Reference documents used on ``amd64_edac``
+------------------------------------------
+
+``amd64_edac`` module is based on the following documents
+(available from http://support.amd.com/en-us/search/tech-docs):
+
+1. :Title: BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD
+ Opteron Processors
+ :AMD publication #: 26094
+ :Revision: 3.26
+ :Link: http://support.amd.com/TechDocs/26094.PDF
+
+2. :Title: BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh
+ Processors
+ :AMD publication #: 32559
+ :Revision: 3.00
+ :Issue Date: May 2006
+ :Link: http://support.amd.com/TechDocs/32559.pdf
+
+3. :Title: BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h
+ Processors
+ :AMD publication #: 31116
+ :Revision: 3.00
+ :Issue Date: September 07, 2007
+ :Link: http://support.amd.com/TechDocs/31116.pdf
+
+4. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
+ Models 30h-3Fh Processors
+ :AMD publication #: 49125
+ :Revision: 3.06
+ :Issue Date: 2/12/2015 (latest release)
+ :Link: http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf
+
+5. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
+ Models 60h-6Fh Processors
+ :AMD publication #: 50742
+ :Revision: 3.01
+ :Issue Date: 7/23/2015 (latest release)
+ :Link: http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf
+
+6. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h
+ Models 00h-0Fh Processors
+ :AMD publication #: 48751
+ :Revision: 3.03
+ :Issue Date: 2/23/2015 (latest release)
+ :Link: http://support.amd.com/TechDocs/48751_16h_bkdg.pdf
+
+Credits
+=======
+
+* Written by Doug Thompson <dougthompson@xmission.com>
+
+ - 7 Dec 2005
+ - 17 Jul 2007 Updated
+
+* |copy| Mauro Carvalho Chehab
+
+ - 05 Aug 2009 Nehalem interface
+ - 26 Oct 2016 Converted to ReST and cleanups at the Nehalem section
+
+* EDAC authors/maintainers:
+
+ - Doug Thompson, Dave Jiang, Dave Peterson et al,
+ - Mauro Carvalho Chehab
+ - Borislav Petkov
+ - original author: Thayne Harbaugh
diff --git a/Documentation/arm/stm32/overview.txt b/Documentation/arm/stm32/overview.txt
index 09aed5588d7c..a03b0357c017 100644
--- a/Documentation/arm/stm32/overview.txt
+++ b/Documentation/arm/stm32/overview.txt
@@ -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
diff --git a/Documentation/arm/stm32/stm32f746-overview.txt b/Documentation/arm/stm32/stm32f746-overview.txt
new file mode 100644
index 000000000000..cffd2b1ccd6f
--- /dev/null
+++ b/Documentation/arm/stm32/stm32f746-overview.txt
@@ -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>
+
+
+
+
+
diff --git a/Documentation/crypto/api-aead.rst b/Documentation/crypto/api-aead.rst
new file mode 100644
index 000000000000..d15256f1ae36
--- /dev/null
+++ b/Documentation/crypto/api-aead.rst
@@ -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
diff --git a/Documentation/crypto/api-akcipher.rst b/Documentation/crypto/api-akcipher.rst
new file mode 100644
index 000000000000..40aa8746e2a1
--- /dev/null
+++ b/Documentation/crypto/api-akcipher.rst
@@ -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
diff --git a/Documentation/crypto/api-digest.rst b/Documentation/crypto/api-digest.rst
new file mode 100644
index 000000000000..07356fa99200
--- /dev/null
+++ b/Documentation/crypto/api-digest.rst
@@ -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
diff --git a/Documentation/crypto/api-intro.txt b/Documentation/crypto/api-intro.txt
index beda682e8d77..45d943fcae5b 100644
--- a/Documentation/crypto/api-intro.txt
+++ b/Documentation/crypto/api-intro.txt
@@ -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>
diff --git a/Documentation/crypto/api-kpp.rst b/Documentation/crypto/api-kpp.rst
new file mode 100644
index 000000000000..7d86ab906bdf
--- /dev/null
+++ b/Documentation/crypto/api-kpp.rst
@@ -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
diff --git a/Documentation/crypto/api-rng.rst b/Documentation/crypto/api-rng.rst
new file mode 100644
index 000000000000..10ba7436cee4
--- /dev/null
+++ b/Documentation/crypto/api-rng.rst
@@ -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
diff --git a/Documentation/crypto/api-samples.rst b/Documentation/crypto/api-samples.rst
new file mode 100644
index 000000000000..0a10819f6107
--- /dev/null
+++ b/Documentation/crypto/api-samples.rst
@@ -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;
+ }
diff --git a/Documentation/crypto/api-skcipher.rst b/Documentation/crypto/api-skcipher.rst
new file mode 100644
index 000000000000..b20028a361a9
--- /dev/null
+++ b/Documentation/crypto/api-skcipher.rst
@@ -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
diff --git a/Documentation/crypto/api.rst b/Documentation/crypto/api.rst
new file mode 100644
index 000000000000..2e519193ab4a
--- /dev/null
+++ b/Documentation/crypto/api.rst
@@ -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
diff --git a/Documentation/crypto/architecture.rst b/Documentation/crypto/architecture.rst
new file mode 100644
index 000000000000..ca2d09b991f5
--- /dev/null
+++ b/Documentation/crypto/architecture.rst
@@ -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.
diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
new file mode 100644
index 000000000000..66f50d32dcec
--- /dev/null
+++ b/Documentation/crypto/devel-algos.rst
@@ -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.
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
new file mode 100644
index 000000000000..94c4786f2573
--- /dev/null
+++ b/Documentation/crypto/index.rst
@@ -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
diff --git a/Documentation/crypto/intro.rst b/Documentation/crypto/intro.rst
new file mode 100644
index 000000000000..9aa89ebbfba9
--- /dev/null
+++ b/Documentation/crypto/intro.rst
@@ -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.
diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
new file mode 100644
index 000000000000..de5a72e32bc9
--- /dev/null
+++ b/Documentation/crypto/userspace-if.rst
@@ -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
diff --git a/Documentation/dev-tools/sparse.rst b/Documentation/dev-tools/sparse.rst
index 8c250e8a2105..78aa00a604a0 100644
--- a/Documentation/dev-tools/sparse.rst
+++ b/Documentation/dev-tools/sparse.rst
@@ -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.
diff --git a/Documentation/device-mapper/delay.txt b/Documentation/device-mapper/delay.txt
index a07b5927f4a8..4b1d22a44ce4 100644
--- a/Documentation/device-mapper/delay.txt
+++ b/Documentation/device-mapper/delay.txt
@@ -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
]]
diff --git a/Documentation/device-mapper/dm-crypt.txt b/Documentation/device-mapper/dm-crypt.txt
index 6f15fcea9566..ff1f87bf26e8 100644
--- a/Documentation/device-mapper/dm-crypt.txt
+++ b/Documentation/device-mapper/dm-crypt.txt
@@ -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"
]]
[[
diff --git a/Documentation/device-mapper/linear.txt b/Documentation/device-mapper/linear.txt
index d5307d380a45..7cb98d89d3f8 100644
--- a/Documentation/device-mapper/linear.txt
+++ b/Documentation/device-mapper/linear.txt
@@ -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);
diff --git a/Documentation/device-mapper/striped.txt b/Documentation/device-mapper/striped.txt
index 45f3b91ea4c3..07ec492cceee 100644
--- a/Documentation/device-mapper/striped.txt
+++ b/Documentation/device-mapper/striped.txt
@@ -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;
}
diff --git a/Documentation/device-mapper/switch.txt b/Documentation/device-mapper/switch.txt
index 424835e57f27..5bd4831db4a8 100644
--- a/Documentation/device-mapper/switch.txt
+++ b/Documentation/device-mapper/switch.txt
@@ -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,
diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
new file mode 100644
index 000000000000..7b9a861e9306
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index fcc6f6c10803..9b2b41ab6817 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.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)
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index faa4b44572e3..401831973638 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -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:
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index ab318a56fca2..b6e810c2781a 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -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>;
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index e1f5ad855f14..29737b9b616e 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/bcm/ns2.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,ns2.txt
index 35f056f4a1c3..35f056f4a1c3 100644
--- a/Documentation/devicetree/bindings/arm/bcm/ns2.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,ns2.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index c1dcf4cade2e..a1bcfeed5f24 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -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"
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index dbbc0952021c..d6ee9c6e1dbb 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -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";
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 3f81575aa6be..7df79a715611 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -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:
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
new file mode 100644
index 000000000000..2ace8696bbee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/juno,scpi.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
new file mode 100644
index 000000000000..31f5f9a104cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -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 {
+ ...
+ ...
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f53e2ee65e35..05f95c3ed7d4 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -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"
diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt
index b9e49711ba05..ac64e60f99f1 100644
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ b/Documentation/devicetree/bindings/arm/oxnas.txt
@@ -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)
diff --git a/Documentation/devicetree/bindings/arm/qcom.txt b/Documentation/devicetree/bindings/arm/qcom.txt
index 3e24518c6678..028d16e72186 100644
--- a/Documentation/devicetree/bindings/arm/qcom.txt
+++ b/Documentation/devicetree/bindings/arm/qcom.txt
@@ -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:
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 55f388f954de..cc4ace6397ab 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -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";
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
index 0ea7f14ef294..3c551894f621 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 2f0b7169f132..253bf9b86690 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 3975d0a0e4c2..4d6467cc2aa2 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/arm/swir.txt b/Documentation/devicetree/bindings/arm/swir.txt
new file mode 100644
index 000000000000..042be73a95d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/swir.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
index 032a7606b862..fc33ca01e9ba 100644
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -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.
diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt
index e1d01df8e3c1..909c9935360d 100644
--- a/Documentation/devicetree/bindings/ata/ahci-st.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-st.txt
@@ -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";
diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
new file mode 100644
index 000000000000..83b0e54f727c
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
@@ -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;
+ ...
+ };
+};
diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
new file mode 100644
index 000000000000..72daefc6b4a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
@@ -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>;
+};
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842c694f..8163d565f697 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -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>;
};
diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index 16a3ec433119..df9cb5ac5f72 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index adeca34c5a33..10a425f451fc 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
index d5e2522b9ec1..d2e1e62e346a 100644
--- a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
+++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
@@ -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.
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index fd5618bd8fbc..55492c264d17 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -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:
diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
index 5f2ce669789a..3316a9c2e638 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f5583293c9c..4775c66f4508 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -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:
diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
new file mode 100644
index 000000000000..e821e16ad65b
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
@@ -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 = "...";
+ ...
+ };
+};
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 3b4436e56865..20f26fbce875 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
new file mode 100644
index 000000000000..817a8d4bf903
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt
new file mode 100644
index 000000000000..f8e288c71b2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
new file mode 100644
index 000000000000..6406f9337eeb
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
new file mode 100644
index 000000000000..2fd8e7a84734
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index c3d016532d8e..30fd2201b3d4 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -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>;
};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
new file mode 100644
index 000000000000..70c054a9a997
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
@@ -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>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac507e9..d30f0b11d853 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -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 :
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..2b8bd33dbf8d 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -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>;
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
index 214f94c25d37..7716acc55dec 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -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>;
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index df720ca00fcf..cdd7b48826c3 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -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)
diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt
index ab0e0488fe92..5f9fbc68e58a 100644
--- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
+++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
@@ -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;
+ };
};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
index 853dff96dd9f..d4927c202aef 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
@@ -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";
};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
index 820fee4b77b6..ce85ee508238 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
@@ -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:
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
index bccaa4e73045..537643e86f61 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -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)
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
index e893615ef635..b48d7d30012c 100644
--- a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
@@ -12,7 +12,7 @@ Required properties:
Example:
-mailbox: mailbox@7e00b800 {
+mailbox: mailbox@7e00b880 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;
diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
new file mode 100644
index 000000000000..b99d25fc2f26
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
@@ -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>;
+};
diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 5fe9372abb37..26ca25b6d264 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
index fb5e7606643a..54e1bede6244 100644
--- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -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";
};
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 8337f75c75da..9cbd92eb5d05 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -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 {
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
new file mode 100644
index 000000000000..4182063a54db
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -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>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 59a47a5b924b..46c15c54175d 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -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*/
diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt b/Documentation/devicetree/bindings/media/renesas,fcp.txt
index 27f9b8e459ac..3ec91803ba58 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
@@ -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>;
diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.txt b/Documentation/devicetree/bindings/media/renesas,fdp1.txt
new file mode 100644
index 000000000000..8dd1007bb573
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,fdp1.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 92c94f5ecbf1..2c901286d818 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -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.
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
new file mode 100644
index 000000000000..ec1dd408d573
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
@@ -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>;
+};
diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
new file mode 100644
index 000000000000..ea151f295ad7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
@@ -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>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
index 37a088f9a648..9e5eba4a4f0d 100644
--- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
@@ -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:
diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt b/Documentation/devicetree/bindings/mfd/rn5t618.txt
index 9e6770b105c9..65c23263cc54 100644
--- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
+++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt
@@ -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
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index 07184e8f894e..ea9c1c9607f6 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -13,6 +13,7 @@ Required Properties:
- "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following,
before RK3288
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
+ - "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK1108
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368
- "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3399
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
index 750374fc9d94..c0f37cb41a9b 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
@@ -1,7 +1,9 @@
* Cadence SD/SDIO/eMMC Host Controller
Required properties:
-- compatible: should be "cdns,sd4hc".
+- compatible: should be one of the following:
+ "cdns,sd4hc" - default of the IP
+ "socionext,uniphier-sd4hc" - for Socionext UniPhier SoCs
- reg: offset and length of the register set for the device.
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
@@ -19,7 +21,7 @@ if supported. See mmc.txt for details.
Example:
emmc: sdhci@5a000000 {
- compatible = "cdns,sd4hc";
+ compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
reg = <0x5a000000 0x400>;
interrupts = <0 78 4>;
clocks = <&clk 4>;
diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
new file mode 100644
index 000000000000..56d5c19da41d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
@@ -0,0 +1,41 @@
+* Oxford Semiconductor OXNAS NAND Controller
+
+Please refer to nand.txt for generic information regarding MTD NAND bindings.
+
+Required properties:
+ - compatible: "oxsemi,ox820-nand"
+ - reg: Base address and length for NAND mapped memory.
+
+Optional Properties:
+ - clocks: phandle to the NAND gate clock if needed.
+ - resets: phandle to the NAND reset control if needed.
+
+Example:
+
+nandc: nand-controller@41000000 {
+ compatible = "oxsemi,ox820-nand";
+ reg = <0x41000000 0x100000>;
+ clocks = <&stdclk CLK_820_NAND>;
+ resets = <&reset RESET_NAND>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "hamming";
+
+ partition@0 {
+ label = "boot";
+ reg = <0x00000000 0x00e00000>;
+ read-only;
+ };
+
+ partition@e00000 {
+ label = "ubi";
+ reg = <0x00e00000 0x07200000>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
new file mode 100644
index 000000000000..0040eb8895e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
@@ -0,0 +1,56 @@
+* Samsung S3C2410 and compatible NAND flash controller
+
+Required properties:
+- compatible : The possible values are:
+ "samsung,s3c2410-nand"
+ "samsung,s3c2412-nand"
+ "samsung,s3c2440-nand"
+- reg : register's location and length.
+- #address-cells, #size-cells : see nand.txt
+- clocks : phandle to the nand controller clock
+- clock-names : must contain "nand"
+
+Optional child nodes:
+Child nodes representing the available nand chips.
+
+Optional child properties:
+- nand-ecc-mode : see nand.txt
+- nand-on-flash-bbt : see nand.txt
+
+Each child device node may optionally contain a 'partitions' sub-node,
+which further contains sub-nodes describing the flash partition mapping.
+See partition.txt for more detail.
+
+Example:
+
+nand-controller@4e000000 {
+ compatible = "samsung,s3c2440-nand";
+ reg = <0x4e000000 0x40>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clocks = <&clocks HCLK_NAND>;
+ clock-names = "nand";
+
+ nand {
+ nand-ecc-mode = "soft";
+ nand-on-flash-bbt;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0 0x040000>;
+ };
+
+ partition@40000 {
+ label = "kernel";
+ reg = <0x040000 0x500000>;
+ };
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
new file mode 100644
index 000000000000..ad5a02f2ac8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
@@ -0,0 +1,38 @@
+Sigma Designs Tango4 NAND Flash Controller (NFC)
+
+Required properties:
+
+- compatible: "sigma,smp8758-nand"
+- reg: address/size of nfc_reg, nfc_mem, and pbus_reg
+- dmas: reference to the DMA channel used by the controller
+- dma-names: "nfc_sbox"
+- clocks: reference to the system clock
+- #address-cells: <1>
+- #size-cells: <0>
+
+Children nodes represent the available NAND chips.
+See Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
+
+Example:
+
+ nandc: nand-controller@2c000 {
+ compatible = "sigma,smp8758-nand";
+ reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;
+ dmas = <&dma0 3>;
+ dma-names = "nfc_sbox";
+ clocks = <&clkgen SYS_CLK>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>; /* CS0 */
+ nand-ecc-strength = <14>;
+ nand-ecc-step-size = <1024>;
+ };
+
+ nand@1 {
+ reg = <1>; /* CS1 */
+ nand-ecc-strength = <14>;
+ nand-ecc-step-size = <1024>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
index 063c02da018a..eea73adc678f 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
@@ -2,11 +2,14 @@ Hisilicon hix5hd2 gmac controller
Required properties:
- compatible: should contain one of the following SoC strings:
- * "hisilicon,hix5hd2-gemac"
- * "hisilicon,hi3798cv200-gemac"
+ * "hisilicon,hix5hd2-gmac"
+ * "hisilicon,hi3798cv200-gmac"
+ * "hisilicon,hi3516a-gmac"
and one of the following version string:
- * "hisilicon,hisi-gemac-v1"
- * "hisilicon,hisi-gemac-v2"
+ * "hisilicon,hisi-gmac-v1"
+ * "hisilicon,hisi-gmac-v2"
+ The version v1 includes SoCs hix5hd2.
+ The version v2 includes SoCs hi3798cv200, hi3516a.
- reg: specifies base physical address(s) and size of the device registers.
The first region is the MAC register base and size.
The second region is external interface control register.
@@ -35,7 +38,7 @@ Required properties:
Example:
gmac0: ethernet@f9840000 {
- compatible = "hisilicon,hi3798cv200-gemac", "hisilicon,hisi-gemac-v2";
+ compatible = "hisilicon,hi3798cv200-gmac", "hisilicon,hisi-gmac-v2";
reg = <0xf9840000 0x1000>,<0xf984300c 0x4>;
interrupts = <0 71 4>;
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 54749b60a466..ff1bc4b1bb3b 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -38,8 +38,14 @@ Optional Properties:
- enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
compensate for the board being designed with the lanes swapped.
-- eee-broken-modes: Bits to clear in the MDIO_AN_EEE_ADV register to
- disable EEE broken modes.
+- eee-broken-100tx:
+- eee-broken-1000t:
+- eee-broken-10gt:
+- eee-broken-1000kx:
+- eee-broken-10gkx4:
+- eee-broken-10gkr:
+ Mark the corresponding energy efficient ethernet mode as broken and
+ request the ethernet to stop advertising it.
Example:
diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index 01b88f4e0d5b..b8e48b4762b2 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -1,10 +1,17 @@
* Broadcom iProc PCIe controller with the platform bus interface
Required properties:
-- compatible: Must be "brcm,iproc-pcie" for PAXB, or "brcm,iproc-pcie-paxc"
- for PAXC. PAXB-based root complex is used for external endpoint devices.
- PAXC-based root complex is connected to emulated endpoint devices
- internal to the ASIC
+- compatible:
+ "brcm,iproc-pcie" for the first generation of PAXB based controller,
+used in SoCs including NSP, Cygnus, NS2, and Pegasus
+ "brcm,iproc-pcie-paxb-v2" for the second generation of PAXB-based
+controllers, used in Stingray
+ "brcm,iproc-pcie-paxc" for the first generation of PAXC based
+controller, used in NS2
+ "brcm,iproc-pcie-paxc-v2" for the second generation of PAXC based
+controller, used in Stingray
+ PAXB-based root complex is used for external endpoint devices. PAXC-based
+root complex is connected to emulated endpoint devices internal to the ASIC
- reg: base address and length of the PCIe controller I/O register space
- #interrupt-cells: set to <1>
- interrupt-map-mask and interrupt-map, standard PCI properties to define the
@@ -19,6 +26,10 @@ Required properties:
Optional properties:
- phys: phandle of the PCIe PHY device
- phy-names: must be "pcie-phy"
+- dma-coherent: present if DMA operations are coherent
+- dma-ranges: Some PAXB-based root complexes do not have inbound mapping done
+ by the ASIC after power on reset. In this case, SW is required to configure
+the mapping, based on inbound memory regions specified by this property.
- brcm,pcie-ob: Some iProc SoCs do not have the outbound address mapping done
by the ASIC after power on reset. In this case, SW needs to configure it
@@ -29,11 +40,6 @@ effective:
Required:
- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
address used by the iProc PCIe core (not the PCIe address)
-- brcm,pcie-ob-window-size: The outbound address mapping window size (in MB)
-
-Optional:
-- brcm,pcie-ob-oarr-size: Some iProc SoCs need the OARR size bit to be set to
-increase the outbound window size
MSI support (optional):
@@ -41,10 +47,19 @@ For older platforms without MSI integrated in the GIC, iProc PCIe core provides
an event queue based MSI support. The iProc MSI uses host memories to store
MSI posted writes in the event queues
-- msi-parent: Link to the device node of the MSI controller. On newer iProc
-platforms, the MSI controller may be gicv2m or gicv3-its. On older iProc
-platforms without MSI support in its interrupt controller, one may use the
-event queue based MSI support integrated within the iProc PCIe core.
+On newer iProc platforms, gicv2m or gicv3-its based MSI support should be used
+
+- msi-map: Maps a Requester ID to an MSI controller and associated MSI
+sideband data
+
+- msi-parent: Link to the device node of the MSI controller, used when no MSI
+sideband data is passed between the iProc PCIe controller and the MSI
+controller
+
+Refer to the following binding documents for more detailed description on
+the use of 'msi-map' and 'msi-parent':
+ Documentation/devicetree/bindings/pci/pci-msi.txt
+ Documentation/devicetree/bindings/interrupt-controller/msi.txt
When the iProc event queue based MSI is used, one needs to define the
following properties in the MSI device node:
@@ -80,9 +95,7 @@ Example:
phy-names = "pcie-phy";
brcm,pcie-ob;
- brcm,pcie-ob-oarr-size;
brcm,pcie-ob-axi-offset = <0x00000000>;
- brcm,pcie-ob-window-size = <256>;
msi-parent = <&msi0>;
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 41e9f55a1467..ee1c72d5162e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -15,6 +15,7 @@ Required properties:
- compatible: should contain the platform identifier such as:
"fsl,ls1021a-pcie", "snps,dw-pcie"
"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
+ "fsl,ls1046a-pcie"
- reg: base addresses and lengths of the PCIe controller
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
index b8cc395fffea..982a74ea6df9 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -110,6 +110,20 @@ Power supplies for Tegra124:
- avdd-pll-erefe-supply: Power supply for PLLE (shared with USB3). Must
supply 1.05 V.
+Power supplies for Tegra210:
+- Required:
+ - avdd-pll-uerefe-supply: Power supply for PLLE (shared with USB3). Must
+ supply 1.05 V.
+ - hvddio-pex-supply: High-voltage supply for PCIe I/O and PCIe output
+ clocks. Must supply 1.8 V.
+ - dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
+ - dvdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
+ supply 1.05 V.
+ - hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3).
+ Must supply 3.3 V.
+ - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
+ supply 1.8 V.
+
Root ports are defined as subnodes of the PCIe controller node.
Required properties:
@@ -436,3 +450,99 @@ Board DTS:
status = "okay";
};
};
+
+Tegra210:
+---------
+
+SoC DTSI:
+
+ pcie-controller@01003000 {
+ compatible = "nvidia,tegra210-pcie";
+ device_type = "pci";
+ reg = <0x0 0x01003000 0x0 0x00000800 /* PADS registers */
+ 0x0 0x01003800 0x0 0x00000800 /* AFI registers */
+ 0x0 0x02000000 0x0 0x10000000>; /* configuration space */
+ reg-names = "pads", "afi", "cs";
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
+ interrupt-names = "intr", "msi";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+
+ bus-range = <0x00 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x82000000 0 0x01000000 0x0 0x01000000 0 0x00001000 /* port 0 configuration space */
+ 0x82000000 0 0x01001000 0x0 0x01001000 0 0x00001000 /* port 1 configuration space */
+ 0x81000000 0 0x0 0x0 0x12000000 0 0x00010000 /* downstream I/O (64 KiB) */
+ 0x82000000 0 0x13000000 0x0 0x13000000 0 0x0d000000 /* non-prefetchable memory (208 MiB) */
+ 0xc2000000 0 0x20000000 0x0 0x20000000 0 0x20000000>; /* prefetchable memory (512 MiB) */
+
+ clocks = <&tegra_car TEGRA210_CLK_PCIE>,
+ <&tegra_car TEGRA210_CLK_AFI>,
+ <&tegra_car TEGRA210_CLK_PLL_E>,
+ <&tegra_car TEGRA210_CLK_CML0>;
+ clock-names = "pex", "afi", "pll_e", "cml";
+ resets = <&tegra_car 70>,
+ <&tegra_car 72>,
+ <&tegra_car 74>;
+ reset-names = "pex", "afi", "pcie_x";
+ status = "disabled";
+
+ pci@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x01000000 0 0x1000>;
+ reg = <0x000800 0 0 0 0>;
+ status = "disabled";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <4>;
+ };
+
+ pci@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0x01001000 0 0x1000>;
+ reg = <0x001000 0 0 0 0>;
+ status = "disabled";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <1>;
+ };
+ };
+
+Board DTS:
+
+ pcie-controller@01003000 {
+ status = "okay";
+
+ avdd-pll-uerefe-supply = <&avdd_1v05_pll>;
+ hvddio-pex-supply = <&vdd_1v8>;
+ dvddio-pex-supply = <&vdd_pex_1v05>;
+ dvdd-pex-pll-supply = <&vdd_pex_1v05>;
+ hvdd-pex-pll-e-supply = <&vdd_1v8>;
+ vddio-pex-ctl-supply = <&vdd_1v8>;
+
+ pci@1,0 {
+ phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-0}>,
+ <&{/padctl@7009f000/pads/pcie/lanes/pcie-1}>,
+ <&{/padctl@7009f000/pads/pcie/lanes/pcie-2}>,
+ <&{/padctl@7009f000/pads/pcie/lanes/pcie-3}>;
+ phy-names = "pcie-0", "pcie-1", "pcie-2", "pcie-3";
+ status = "okay";
+ };
+
+ pci@2,0 {
+ phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-4}>;
+ phy-names = "pcie-0";
+ status = "okay";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
index 08dcfad09f8d..50f9e2ca5b13 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -18,3 +18,9 @@ driver implementation may support the following properties:
host bridges in the system, otherwise potentially conflicting domain numbers
may be assigned to root buses behind different host bridges. The domain
number for each host bridge in the system must be unique.
+- max-link-speed:
+ If present this property specifies PCI gen for link capability. Host
+ drivers could add this as a strategy to avoid unnecessary operation for
+ unsupported link speed, for instance, trying to do training for
+ unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2'
+ for gen2, and '1' for gen1. Any other values are invalid.
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
index 4059a6f89bc1..e15f9b19901f 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -7,6 +7,7 @@
- "qcom,pcie-ipq8064" for ipq8064
- "qcom,pcie-apq8064" for apq8064
- "qcom,pcie-apq8084" for apq8084
+ - "qcom,pcie-msm8996" for msm8996 or apq8096
- reg:
Usage: required
@@ -92,6 +93,17 @@
- "aux" Auxiliary (AUX) clock
- "bus_master" Master AXI clock
- "bus_slave" Slave AXI clock
+
+- clock-names:
+ Usage: required for msm8996/apq8096
+ Value type: <stringlist>
+ Definition: Should contain the following entries
+ - "pipe" Pipe Clock driving internal logic
+ - "aux" Auxiliary (AUX) clock
+ - "cfg" Configuration clock
+ - "bus_master" Master AXI clock
+ - "bus_slave" Slave AXI clock
+
- resets:
Usage: required
Value type: <prop-encoded-array>
@@ -115,7 +127,7 @@
- "core" Core reset
- power-domains:
- Usage: required for apq8084
+ Usage: required for apq8084 and msm8996/apq8096
Value type: <prop-encoded-array>
Definition: A phandle and power domain specifier pair to the
power domain which is responsible for collapsing
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 6cf99690eef9..eee518db90b9 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
"renesas,pcie-r8a7793" for the R8A7793 SoC;
"renesas,pcie-r8a7795" for the R8A7795 SoC;
"renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
+ "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 66dcaa9efd74..e705acd3612c 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -7,6 +7,9 @@ Required properties:
- reg : offset and length of the register set for the mux registers
+- #pinctrl-cells : number of cells in addition to the index, set to 1
+ for pinctrl-single,pins and 2 for pinctrl-single,bits
+
- pinctrl-single,register-width : pinmux register access width in bits
- pinctrl-single,function-mask : mask of allowed pinmux function bits
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
index 0725fb37a973..d91715bc8d52 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
@@ -1,12 +1,14 @@
-DT bindings for the Renesas R-Car System Controller
+DT bindings for the Renesas R-Car (RZ/G) System Controller
== System Controller Node ==
-The R-Car System Controller provides power management for the CPU cores and
-various coprocessors.
+The R-Car (RZ/G) System Controller provides power management for the CPU cores
+and various coprocessors.
Required properties:
- compatible: Must contain exactly one of the following:
+ - "renesas,r8a7743-sysc" (RZ/G1M)
+ - "renesas,r8a7745-sysc" (RZ/G1E)
- "renesas,r8a7779-sysc" (R-Car H1)
- "renesas,r8a7790-sysc" (R-Car H2)
- "renesas,r8a7791-sysc" (R-Car M2-W)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
index fb6fb31bc4c4..cf573e85b11d 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
@@ -3,7 +3,7 @@ BCM2835 PWM controller (Raspberry Pi controller)
Required properties:
- compatible: should be "brcm,bcm2835-pwm"
- reg: physical base address and length of the controller's registers
-- clock: This clock defines the base clock frequency of the PWM hardware
+- clocks: This clock defines the base clock frequency of the PWM hardware
system, the period and the duty_cycle of the PWM signal is a multiple of
the base period.
- #pwm-cells: Should be 2. See pwm.txt in this directory for a description of
diff --git a/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
new file mode 100644
index 000000000000..fa7849d67836
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
@@ -0,0 +1,21 @@
+Hisilicon PWM controller
+
+Required properties:
+-compatible: should contain one SoC specific compatible string
+ The SoC specific strings supported including:
+ "hisilicon,hi3516cv300-pwm"
+ "hisilicon,hi3519v100-pwm"
+- reg: physical base address and length of the controller's registers.
+- clocks: phandle and clock specifier of the PWM reference clock.
+- resets: phandle and reset specifier for the PWM controller reset.
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+ the cells format.
+
+Example:
+ pwm: pwm@12130000 {
+ compatible = "hisilicon,hi3516cv300-pwm";
+ reg = <0x12130000 0x10000>;
+ clocks = <&crg_ctrl HI3516CV300_PWM_CLK>;
+ resets = <&crg_ctrl 0x38 0>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt b/Documentation/devicetree/bindings/regulator/tps65218.txt
index fccc1d24af58..02f0e9bbfbf8 100644
--- a/Documentation/devicetree/bindings/regulator/tps65218.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -1,23 +1,78 @@
TPS65218 family of regulators
Required properties:
-For tps65218 regulators/LDOs
-- compatible:
- - "ti,tps65218-dcdc1" for DCDC1
- - "ti,tps65218-dcdc2" for DCDC2
- - "ti,tps65218-dcdc3" for DCDC3
- - "ti,tps65218-dcdc4" for DCDC4
- - "ti,tps65218-dcdc5" for DCDC5
- - "ti,tps65218-dcdc6" for DCDC6
- - "ti,tps65218-ldo1" for LDO1
-
-Optional properties:
-- Any optional property defined in bindings/regulator/regulator.txt
+- compatible: "ti,tps65218"
+- reg: I2C slave address
+
+- List of regulators provided by this controller, must be named
+ after their hardware counterparts: dcdc[1-6] and ldo1
+- This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Not all regulators for the given
+ device need to be present. The definition for each of these nodes is defined
+ using the standard binding for regulators found at ./regulator.txt.
+
+ The valid names for regulators are:
+ tps65217: regulator-dcdc1, regulator-dcdc2, regulator-dcdc3, regulator-dcdc4,
+ regulator-dcdc5, regulator-dcdc6, regulator-ldo1, regulator-ls3.
+ Each regulator is defined using the standard binding for regulators.
Example:
+tps65218: tps65218@24 {
+ reg = <0x24>;
+ compatible = "ti,tps65218";
+ interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>; /* NMIn */
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ dcdc1: regulator-dcdc1 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1378000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ regulator-name = "vdcdc3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ regulator-name = "v1_0bat";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ regulator-name = "v1_8bat";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: regulator-ldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
- xyz: regulator@0 {
- compatible = "ti,tps65218-dcdc1";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3000000>;
+ ls3: regulator-ls3 {
+ regulator-min-microvolt = <100000>;
+ regulator-max-microvolt = <1000000>;
};
+};
diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
index 6f06db930030..d27ccb5d04fc 100644
--- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt
+++ b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
@@ -5,45 +5,19 @@ Please also refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
-- compatible: Should be "oxsemi,ox810se-reset"
+- compatible: For OX810SE, should be "oxsemi,ox810se-reset"
+ For OX820, should be "oxsemi,ox820-reset"
- #reset-cells: 1, see below
Parent node should have the following properties :
-- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+- compatible: For OX810SE, should be :
+ "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+ For OX820, should be :
+ "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-For OX810SE, the indices are :
- - 0 : ARM
- - 1 : COPRO
- - 2 : Reserved
- - 3 : Reserved
- - 4 : USBHS
- - 5 : USBHSPHY
- - 6 : MAC
- - 7 : PCI
- - 8 : DMA
- - 9 : DPE
- - 10 : DDR
- - 11 : SATA
- - 12 : SATA_LINK
- - 13 : SATA_PHY
- - 14 : Reserved
- - 15 : NAND
- - 16 : GPIO
- - 17 : UART1
- - 18 : UART2
- - 19 : MISC
- - 20 : I2S
- - 21 : AHB_MON
- - 22 : UART3
- - 23 : UART4
- - 24 : SGDMA
- - 25 : Reserved
- - 26 : Reserved
- - 27 : Reserved
- - 28 : Reserved
- - 29 : Reserved
- - 30 : Reserved
- - 31 : BUS
+Reset indices are in dt-bindings include files :
+- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h
+- For OX820: include/dt-bindings/reset/oxsemi,ox820.h
example:
diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
index 1cfd21d1dfa1..92527138bc93 100644
--- a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
@@ -16,15 +16,14 @@ Please refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
-- compatible: Should be "st,<chip>-powerdown"
- ex: "st,stih415-powerdown", "st,stih416-powerdown"
+- compatible: Should be "st,stih407-powerdown"
- #reset-cells: 1, see below
example:
powerdown: powerdown-controller {
+ compatible = "st,stih407-powerdown";
#reset-cells = <1>;
- compatible = "st,stih415-powerdown";
};
@@ -37,11 +36,10 @@ index specifying which channel to use, as described in reset.txt
example:
- usb1: usb@fe200000 {
- resets = <&powerdown STIH41X_USB1_POWERDOWN>;
+ st_dwc3: dwc3@8f94000 {
+ resets = <&powerdown STIH407_USB3_POWERDOWN>,
};
Macro definitions for the supported reset channels can be found in:
-include/dt-bindings/reset/stih415-resets.h
-include/dt-bindings/reset/stih416-resets.h
+include/dt-bindings/reset/stih407-resets.h
diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
index 891a2fd85ed6..a21658f18fe6 100644
--- a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
+++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
@@ -15,15 +15,14 @@ Please refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
-- compatible: Should be "st,<chip>-softreset" example:
- "st,stih415-softreset" or "st,stih416-softreset";
+- compatible: Should be st,stih407-softreset";
- #reset-cells: 1, see below
example:
softreset: softreset-controller {
#reset-cells = <1>;
- compatible = "st,stih415-softreset";
+ compatible = "st,stih407-softreset";
};
@@ -42,5 +41,4 @@ example:
Macro definitions for the supported reset channels can be found in:
-include/dt-bindings/reset/stih415-resets.h
-include/dt-bindings/reset/stih416-resets.h
+include/dt-bindings/reset/stih407-resets.h
diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt
index 6a62acd86953..471477299ece 100644
--- a/Documentation/devicetree/bindings/rng/omap_rng.txt
+++ b/Documentation/devicetree/bindings/rng/omap_rng.txt
@@ -1,4 +1,4 @@
-OMAP SoC HWRNG Module
+OMAP SoC and Inside-Secure HWRNG Module
Required properties:
@@ -6,11 +6,13 @@ Required properties:
RNG versions:
- "ti,omap2-rng" for OMAP2.
- "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+ - "inside-secure,safexcel-eip76" for SoCs with EIP76 IP block
Note that these two versions are incompatible.
- ti,hwmods: Name of the hwmod associated with the RNG module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt number for the RNG module.
- Only used for "ti,omap4-rng".
+ Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76"
+- clocks: the trng clock source
Example:
/* AM335x */
@@ -20,3 +22,11 @@ rng: rng@48310000 {
reg = <0x48310000 0x2000>;
interrupts = <111>;
};
+
+/* SafeXcel IP-76 */
+trng: rng@f2760000 {
+ compatible = "inside-secure,safexcel-eip76";
+ reg = <0xf2760000 0x7d>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpm_syscon0 1 25>;
+};
diff --git a/Documentation/devicetree/bindings/rtc/epson,rtc7301.txt b/Documentation/devicetree/bindings/rtc/epson,rtc7301.txt
new file mode 100644
index 000000000000..5f9df3f1467c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/epson,rtc7301.txt
@@ -0,0 +1,16 @@
+EPSON TOYOCOM RTC-7301SF/DG
+
+Required properties:
+
+- compatible: Should be "epson,rtc7301sf" or "epson,rtc7301dg"
+- reg: Specifies base physical address and size of the registers.
+- interrupts: A single interrupt specifier.
+
+Example:
+
+rtc: rtc@44a00000 {
+ compatible = "epson,rtc7301dg";
+ reg = <0x44a00000 0x10000>;
+ interrupt-parent = <&axi_intc_0>;
+ interrupts = <3 2>;
+};
diff --git a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
new file mode 100644
index 000000000000..41c7ae18fd7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
@@ -0,0 +1,37 @@
+JZ4740 and similar SoCs real-time clock driver
+
+Required properties:
+
+- compatible: One of:
+ - "ingenic,jz4740-rtc" - for use with the JZ4740 SoC
+ - "ingenic,jz4780-rtc" - for use with the JZ4780 SoC
+- reg: Address range of rtc register set
+- interrupts: IRQ number for the alarm interrupt
+- clocks: phandle to the "rtc" clock
+- clock-names: must be "rtc"
+
+Optional properties:
+- system-power-controller: To use this component as the
+ system power controller
+- reset-pin-assert-time-ms: Reset pin low-level assertion
+ time after wakeup (default 60ms; range 0-125ms if RTC clock
+ at 32 kHz)
+- min-wakeup-pin-assert-time-ms: Minimum wakeup pin assertion
+ time (default 100ms; range 0-2s if RTC clock at 32 kHz)
+
+Example:
+
+rtc@10003000 {
+ compatible = "ingenic,jz4740-rtc";
+ reg = <0x10003000 0x40>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <32>;
+
+ clocks = <&rtc_clock>;
+ clock-names = "rtc";
+
+ system-power-controller;
+ reset-pin-assert-time-ms = <60>;
+ min-wakeup-pin-assert-time-ms = <100>;
+};
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
index 596e0c97be7a..8f9a94f2f896 100644
--- a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -1,12 +1,11 @@
-* TI twl RTC
-
-The TWL family (twl4030/6030) contains a RTC.
+* Texas Instruments TWL4030/6030 RTC
Required properties:
-- compatible : Should be twl4030-rtc
-
-Examples:
-
-rtc@0 {
- compatible = "ti,twl4030-rtc";
-};
+- compatible : Should be "ti,twl4030-rtc"
+- interrupts : Should be the interrupt number.
+
+Example:
+ rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
diff --git a/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt b/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt
new file mode 100644
index 000000000000..d89f99971368
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt
@@ -0,0 +1,41 @@
+* Device Tree Bindings for IBM Virtual Trusted Platform Module(vtpm)
+
+Required properties:
+
+- compatible : property name that conveys the platform architecture
+ identifiers, as 'IBM,vtpm'
+- device_type : specifies type of virtual device
+- interrupts : property specifying the interrupt source number and
+ sense code associated with this virtual I/O Adapters
+- ibm,my-drc-index : integer index for the connector between the device
+ and its parent - present only if Dynamic
+ Reconfiguration(DR) Connector is enabled
+- ibm,#dma-address-cells: specifies the number of cells that are used to
+ encode the physical address field of dma-window
+ properties
+- ibm,#dma-size-cells : specifies the number of cells that are used to
+ encode the size field of dma-window properties
+- ibm,my-dma-window : specifies DMA window associated with this virtual
+ IOA
+- ibm,loc-code : specifies the unique and persistent location code
+ associated with this virtual I/O Adapters
+- linux,sml-base : 64-bit base address of the reserved memory allocated
+ for the firmware event log
+- linux,sml-size : size of the memory allocated for the firmware event log
+
+Example (IBM Virtual Trusted Platform Module)
+---------------------------------------------
+
+ vtpm@30000003 {
+ ibm,#dma-size-cells = <0x2>;
+ compatible = "IBM,vtpm";
+ device_type = "IBM,vtpm";
+ ibm,my-drc-index = <0x30000003>;
+ ibm,#dma-address-cells = <0x2>;
+ linux,sml-base = <0xc60e 0x0>;
+ interrupts = <0xa0003 0x0>;
+ ibm,my-dma-window = <0x10000003 0x0 0x0 0x0 0x10000000>;
+ ibm,loc-code = "U8286.41A.10082DV-V3-C3";
+ reg = <0x30000003>;
+ linux,sml-size = <0xbce10200>;
+ };
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt b/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt
new file mode 100644
index 000000000000..8cb638b7e89c
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt
@@ -0,0 +1,21 @@
+* Device Tree Bindings for I2C based Trusted Platform Module(TPM)
+
+Required properties:
+
+- compatible : 'manufacturer,model', eg. nuvoton,npct650
+- label : human readable string describing the device, eg. "tpm"
+- linux,sml-base : 64-bit base address of the reserved memory allocated for
+ the firmware event log
+- linux,sml-size : size of the memory allocated for the firmware event log
+
+Example (for OpenPower Systems with Nuvoton TPM 2.0 on I2C)
+----------------------------------------------------------
+
+tpm@57 {
+ reg = <0x57>;
+ label = "tpm";
+ compatible = "nuvoton,npct650", "nuvoton,npct601";
+ linux,sml-base = <0x7f 0xfd450000>;
+ linux,sml-size = <0x10000>;
+ status = "okay";
+};
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt b/Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt
new file mode 100644
index 000000000000..41d740545189
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt
@@ -0,0 +1,25 @@
+Trusted Computing Group MMIO Trusted Platform Module
+
+The TCG defines multi vendor standard for accessing a TPM chip, this
+is the standard protocol defined to access the TPM via MMIO. Typically
+this interface will be implemented over Intel's LPC bus.
+
+Refer to the 'TCG PC Client Specific TPM Interface Specification (TIS)' TCG
+publication for the specification.
+
+Required properties:
+
+- compatible: should contain a string below for the chip, followed by
+ "tcg,tpm-tis-mmio". Valid chip strings are:
+ * "atmel,at97sc3204"
+- reg: The location of the MMIO registers, should be at least 0x5000 bytes
+- interrupt-parent/interrupts: An optional interrupt indicating command completion.
+
+Example:
+
+ tpm_tis@90000 {
+ compatible = "atmel,at97sc3204", "tcg,tpm-tis-mmio";
+ reg = <0x90000 0x5000>;
+ interrupt-parent = <&EIC0>;
+ interrupts = <1 2>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
index 845850caf088..c93a2d1c1a65 100644
--- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
@@ -10,7 +10,7 @@ Required properties:
See ../reset/reset.txt for details.
- reset-names : Must include the following entries:
- serial
-- dmas : Must contain an entry for each entry in clock-names.
+- dmas : Must contain an entry for each entry in dma-names.
See ../dma/dma.txt for details.
- dma-names : Must include the following entries:
- rx
diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index e8f15e34027f..16fe94d7783c 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,17 +9,20 @@ domain control.
The driver implements the Generic PM domain bindings described in
power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h.
+include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
Required properties:
-- compatible: Must be "mediatek,mt8173-scpsys"
+- compatible: Should be one of:
+ - "mediatek,mt2701-scpsys"
+ - "mediatek,mt8173-scpsys"
- #power-domain-cells: Must be 1
- reg: Address range of the SCPSYS unit
- infracfg: must contain a phandle to the infracfg controller
- clock, clock-names: clocks according to the common clock binding.
- The clocks needed "mm", "mfg", "venc" and "venc_lt".
- These are the clocks which hardware needs to be enabled
- before enabling certain power domains.
+ These are clocks which hardware needs to be
+ enabled before enabling certain power domains.
+ Required clocks for MT2701: "mm", "mfg", "ethif"
+ Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
Optional properties:
- vdec-supply: Power supply for the vdec power domain
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
new file mode 100644
index 000000000000..5b9b38f578bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -0,0 +1,88 @@
+Devicetree bindings for the Axentia TSE-850 audio complex
+
+Required properties:
+ - compatible: "axentia,tse850-pcm5142"
+ - axentia,ssc-controller: The phandle of the atmel SSC controller used as
+ cpu dai.
+ - axentia,audio-codec: The phandle of the PCM5142 codec.
+ - axentia,add-gpios: gpio specifier that controls the mixer.
+ - axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
+ - axentia,loop2-gpios: gpio specifier that controls loop relays on channel 2.
+ - axentia,ana-supply: Regulator that supplies the output amplifier. Must
+ support voltages in the 2V - 20V range, in 1V steps.
+
+The schematics explaining the gpios are as follows:
+
+ loop1 relays
+ IN1 +---o +------------+ o---+ OUT1
+ \ /
+ + +
+ | / |
+ +--o +--. |
+ | add | |
+ | V |
+ | .---. |
+ DAC +----------->|Sum|---+
+ | '---' |
+ | |
+ + +
+
+ IN2 +---o--+------------+--o---+ OUT2
+ loop2 relays
+
+The 'loop1' gpio pin controlls two relays, which are either in loop position,
+meaning that input and output are directly connected, or they are in mixer
+position, meaning that the signal is passed through the 'Sum' mixer. Similarly
+for 'loop2'.
+
+In the above, the 'loop1' relays are inactive, thus feeding IN1 to the mixer
+(if 'add' is active) and feeding the mixer output to OUT1. The 'loop2' relays
+are active, short-cutting the TSE-850 from channel 2. IN1, IN2, OUT1 and OUT2
+are TSE-850 connectors and DAC is the PCB name of the (filtered) output from
+the PCM5142 codec.
+
+Example:
+
+ &i2c {
+ codec: pcm5142@4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <&reg_3v3>;
+ DVDD-supply = <&reg_3v3>;
+ CPVDD-supply = <&reg_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+ };
+
+ ana: ana-reg {
+ compatible = "pwm-regulator";
+
+ regulator-name = "ANA";
+
+ pwms = <&pwm0 2 1000 PWM_POLARITY_INVERTED>;
+ pwm-dutycycle-unit = <1000>;
+ pwm-dutycycle-range = <100 1000>;
+
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <20000000>;
+ regulator-ramp-delay = <1000>;
+ };
+
+ sound {
+ compatible = "axentia,tse850-pcm5142";
+
+ axentia,ssc-controller = <&ssc0>;
+ axentia,audio-codec = <&codec>;
+
+ axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
+ axentia,loop1-gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ axentia,loop2-gpios = <&pioA 11 GPIO_ACTIVE_LOW>;
+
+ axentia,ana-supply = <&ana>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/cs35l34.txt b/Documentation/devicetree/bindings/sound/cs35l34.txt
new file mode 100644
index 000000000000..b218ead2e68e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cs35l34.txt
@@ -0,0 +1,64 @@
+CS35L34 Speaker Amplifier
+
+Required properties:
+
+ - compatible : "cirrus,cs35l34"
+
+ - reg : the I2C address of the device for I2C.
+
+ - VA-supply, VP-supply : power supplies for the device,
+ as covered in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+ - cirrus,boost-vtge-millivolt : Boost Voltage Value. Configures the boost
+ converter's output voltage in mV. The range is from VP to 8V with
+ increments of 100mV.
+
+ - cirrus,boost-nanohenry: Inductor value for boost converter. The value is
+ in nH and they can be values of 1000nH, 1100nH, 1200nH, 1500nH, and 2200nH.
+
+Optional properties:
+
+ - reset-gpios: GPIO used to reset the amplifier.
+
+ - interrupt-parent : Specifies the phandle of the interrupt controller to
+ which the IRQs from CS35L34 are delivered to.
+ - interrupts : IRQ line info CS35L34.
+ (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ for further information relating to interrupt properties)
+
+ - cirrus,boost-peak-milliamp : Boost converter peak current limit in mA. The
+ range starts at 1200mA and goes to a maximum of 3840mA with increments of
+ 80mA. The default value is 2480mA.
+
+ - cirrus,i2s-sdinloc : ADSP SDIN I2S channel location. Indicates whether the
+ received mono data is in the left or right portion of the I2S frame
+ according to the AD0 pin or directly via this configuration.
+ 0x0 (Default) = Selected by AD0 input (if AD0 = LOW, use left channel),
+ 0x2 = Left,
+ 0x1 = Selected by the inversion of the AD0 input (if AD0 = LOW, use right
+ channel),
+ 0x3 = Right.
+
+ - cirrus,gain-zc-disable: Boolean property. If set, the gain change will take
+ effect without waiting for a zero cross.
+
+ - cirrus,tdm-rising-edge: Boolean property. If set, data is on the rising edge of
+ SCLK. Otherwise, data is on the falling edge of SCLK.
+
+
+Example:
+
+cs35l34: cs35l34@40 {
+ compatible = "cirrus,cs35l34";
+ reg = <0x40>;
+
+ interrupt-parent = <&gpio8>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ reset-gpios = <&gpio 10 0>;
+
+ cirrus,boost-vtge-milltvolt = <8000>; /* 8V */
+ cirrus,boost-ind-nanohenry = <1000>; /* 1uH */
+ cirrus,boost-peak-milliamp = <3000>; /* 3A */
+};
diff --git a/Documentation/devicetree/bindings/sound/cs42l42.txt b/Documentation/devicetree/bindings/sound/cs42l42.txt
new file mode 100644
index 000000000000..9a2c5e2423d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cs42l42.txt
@@ -0,0 +1,110 @@
+CS42L42 audio CODEC
+
+Required properties:
+
+ - compatible : "cirrus,cs42l42"
+
+ - reg : the I2C address of the device for I2C.
+
+ - VP-supply, VCP-supply, VD_FILT-supply, VL-supply, VA-supply :
+ power supplies for the device, as covered in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Optional properties:
+
+ - reset-gpios : a GPIO spec for the reset pin. If specified, it will be
+ deasserted before communication to the codec starts.
+
+ - interrupt-parent : Specifies the phandle of the interrupt controller to
+ which the IRQs from CS42L42 are delivered to.
+
+ - interrupts : IRQ line info CS42L42.
+ (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ for further information relating to interrupt properties)
+
+ - cirrus,ts-inv : Boolean property. For jacks that invert the tip sense
+ polarity. Normal jacks will short tip sense pin to HS1 when headphones are
+ plugged in and leave tip sense floating when not plugged in. Inverting jacks
+ short tip sense when unplugged and float when plugged in.
+
+ 0 = (Default) Non-inverted
+ 1 = Inverted
+
+ - cirrus,ts-dbnc-rise : Debounce the rising edge of TIP_SENSE_PLUG. With no
+ debounce, the tip sense pin might be noisy on a plug event.
+
+ 0 - 0ms,
+ 1 - 125ms,
+ 2 - 250ms,
+ 3 - 500ms,
+ 4 - 750ms,
+ 5 - (Default) 1s,
+ 6 - 1.25s,
+ 7 - 1.5s,
+
+ - cirrus,ts-dbnc-fall : Debounce the falling edge of TIP_SENSE_UNPLUG.
+ With no debounce, the tip sense pin might be noisy on an unplug event.
+
+ 0 - 0ms,
+ 1 - 125ms,
+ 2 - 250ms,
+ 3 - 500ms,
+ 4 - 750ms,
+ 5 - (Default) 1s,
+ 6 - 1.25s,
+ 7 - 1.5s,
+
+ - cirrus,btn-det-init-dbnce : This sets how long the driver sleeps after
+ enabling button detection interrupts. After auto-detection and before
+ servicing button interrupts, the HS bias needs time to settle. If you
+ don't wait, there is possibility for erroneous button interrupt.
+
+ 0ms - 200ms,
+ Default = 100ms
+
+ - cirrus,btn-det-event-dbnce : This sets how long the driver delays after
+ receiving a button press interrupt. With level detect interrupts, you want
+ to wait a small amount of time to make sure the button press is making a
+ clean connection with the bias resistors.
+
+ 0ms - 20ms,
+ Default = 10ms
+
+ - cirrus,bias-lvls : For a level-detect headset button scheme, each button
+ will bias the mic pin to a certain voltage. To determine which button was
+ pressed, the driver will compare this biased voltage to sequential,
+ decreasing voltages and will stop when a comparator is tripped,
+ indicating a comparator voltage < bias voltage. This value represents a
+ percentage of the internally generated HS bias voltage. For different
+ hardware setups, a designer might want to tweak this. This is an array of
+ descending values for the comparator voltage.
+
+ Array of 4 values
+ Each 0-63
+ < x1 x2 x3 x4 >
+ Default = < 15 8 4 1>
+
+
+Example:
+
+cs42l42: cs42l42@48 {
+ compatible = "cirrus,cs42l42";
+ reg = <0x48>;
+ VA-supply = <&dummy_vreg>;
+ VP-supply = <&dummy_vreg>;
+ VCP-supply = <&dummy_vreg>;
+ VD_FILT-supply = <&dummy_vreg>;
+ VL-supply = <&dummy_vreg>;
+
+ reset-gpios = <&axi_gpio_0 1 0>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <55 8>
+
+ cirrus,ts-inv = <0x00>;
+ cirrus,ts-dbnc-rise = <0x05>;
+ cirrus,ts-dbnc-fall = <0x00>;
+ cirrus,btn-det-init-dbnce = <100>;
+ cirrus,btn-det-event-dbnce = <10>;
+ cirrus,bias-lvls = <0x0F 0x08 0x04 0x01>;
+ cirrus,hs-bias-ramp-rate = <0x02>;
+}; \ No newline at end of file
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
index 55b53e1fd72c..e0b6165c9cfc 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
@@ -43,7 +43,7 @@ mcbsp0: mcbsp@1d10000 {
<0x00310000 0x1000>;
reg-names = "mpu", "dat";
interrupts = <97 98>;
- interrupts-names = "rx", "tx";
+ interrupt-names = "rx", "tx";
dmas = <&edma0 3 1
&edma0 2 1>;
dma-names = "tx", "rx";
diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
index d9d8635ff94c..6a4aadc4ce06 100644
--- a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
+++ b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
@@ -44,8 +44,7 @@ Required dai-link subnodes:
Required CPU/CODEC subnodes properties:
-link-name : Name of the dai link.
--sound-dai : phandle and port of CPU/CODEC
--capture-dai : phandle and port of CPU/CODEC
+-sound-dai : phandle/s and port of CPU/CODEC
Example:
@@ -73,7 +72,7 @@ sound: sound {
sound-dai = <&lpass MI2S_PRIMARY>;
};
codec {
- sound-dai = <&wcd_codec 0>;
+ sound-dai = <&lpass_codec 0>, <&wcd_codec 0>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt
new file mode 100644
index 000000000000..ccb401cfef9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt
@@ -0,0 +1,85 @@
+msm8916 analog audio CODEC
+
+Bindings for codec Analog IP which is integrated in pmic pm8916,
+
+## Bindings for codec core on pmic:
+
+Required properties
+ - compatible = "qcom,pm8916-wcd-analog-codec";
+ - reg: represents the slave base address provided to the peripheral.
+ - interrupt-parent : The parent interrupt controller.
+ - interrupts: List of interrupts in given SPMI peripheral.
+ - interrupt-names: Names specified to above list of interrupts in same
+ order. List of supported interrupt names are:
+ "cdc_spk_cnp_int" - Speaker click and pop interrupt.
+ "cdc_spk_clip_int" - Speaker clip interrupt.
+ "cdc_spk_ocp_int" - Speaker over current protect interrupt.
+ "mbhc_ins_rem_det1" - jack insert removal detect interrupt 1.
+ "mbhc_but_rel_det" - button release interrupt.
+ "mbhc_but_press_det" - button press event
+ "mbhc_ins_rem_det" - jack insert removal detect interrupt.
+ "mbhc_switch_int" - multi button headset interrupt.
+ "cdc_ear_ocp_int" - Earphone over current protect interrupt.
+ "cdc_hphr_ocp_int" - Headphone R over current protect interrupt.
+ "cdc_hphl_ocp_det" - Headphone L over current protect interrupt.
+ "cdc_ear_cnp_int" - earphone cnp interrupt.
+ "cdc_hphr_cnp_int" - hphr click and pop interrupt.
+ "cdc_hphl_cnp_int" - hphl click and pop interrupt.
+
+ - clocks: Handle to mclk.
+ - clock-names: should be "mclk"
+ - vdd-cdc-io-supply: phandle to VDD_CDC_IO regulator DT node.
+ - vdd-cdc-tx-rx-cx-supply: phandle to VDD_CDC_TX/RX/CX regulator DT node.
+ - vdd-micbias-supply: phandle of VDD_MICBIAS supply's regulator DT node.
+
+Optional Properties:
+- qcom,micbias1-ext-cap: boolean, present if micbias1 has external capacitor
+ connected.
+- qcom,micbias2-ext-cap: boolean, present if micbias2 has external capacitor
+ connected.
+
+Example:
+
+spmi_bus {
+ ...
+ audio-codec@f000{
+ compatible = "qcom,pm8916-wcd-analog-codec";
+ reg = <0xf000 0x200>;
+ reg-names = "pmic-codec-core";
+ clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
+ clock-names = "mclk";
+ interrupt-parent = <&spmi_bus>;
+ interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
+ interrupt-names = "cdc_spk_cnp_int",
+ "cdc_spk_clip_int",
+ "cdc_spk_ocp_int",
+ "mbhc_ins_rem_det1",
+ "mbhc_but_rel_det",
+ "mbhc_but_press_det",
+ "mbhc_ins_rem_det",
+ "mbhc_switch_int",
+ "cdc_ear_ocp_int",
+ "cdc_hphr_ocp_int",
+ "cdc_hphl_ocp_det",
+ "cdc_ear_cnp_int",
+ "cdc_hphr_cnp_int",
+ "cdc_hphl_cnp_int";
+ VDD-CDC-IO-supply = <&pm8916_l5>;
+ VDD-CDC-TX-RX-CX-supply = <&pm8916_l5>;
+ VDD-MICBIAS-supply = <&pm8916_l13>;
+ #sound-dai-cells = <1>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt
new file mode 100644
index 000000000000..1c8e4cb25176
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt
@@ -0,0 +1,20 @@
+msm8916 digital audio CODEC
+
+## Bindings for codec core in lpass:
+
+Required properties
+ - compatible = "qcom,msm8916-wcd-digital-codec";
+ - reg: address space for lpass codec.
+ - clocks: Handle to mclk and ahbclk
+ - clock-names: should be "mclk", "ahbix-clk".
+
+Example:
+
+audio-codec@771c000{
+ compatible = "qcom,msm8916-wcd-digital-codec";
+ reg = <0x0771c000 0x400>;
+ clocks = <&gcc GCC_ULTAUDIO_AHBFABRIC_IXFABRIC_CLK>,
+ <&gcc GCC_CODEC_DIGCODEC_CLK>;
+ clock-names = "ahbix-clk", "mclk";
+ #sound-dai-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/sound/rt5514.txt b/Documentation/devicetree/bindings/sound/rt5514.txt
index 9cabfc18cb57..929ca6756b02 100644
--- a/Documentation/devicetree/bindings/sound/rt5514.txt
+++ b/Documentation/devicetree/bindings/sound/rt5514.txt
@@ -13,6 +13,9 @@ Optional properties:
- clocks: The phandle of the master clock to the CODEC
- clock-names: Should be "mclk"
+- realtek,dmic-init-delay-ms
+ Set the DMIC initial delay (ms) to wait it ready.
+
Pins on the device (for linking into audio routes) for RT5514:
* DMIC1L
diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt b/Documentation/devicetree/bindings/sound/rt5663.txt
index 7d3c974c6e2e..70eaeaed2b18 100644
--- a/Documentation/devicetree/bindings/sound/rt5663.txt
+++ b/Documentation/devicetree/bindings/sound/rt5663.txt
@@ -1,10 +1,10 @@
-RT5663/RT5668 audio CODEC
+RT5663 audio CODEC
This device supports I2C only.
Required properties:
-- compatible : One of "realtek,rt5663" or "realtek,rt5668".
+- compatible : "realtek,rt5663".
- reg : The I2C address of the device.
@@ -12,7 +12,7 @@ Required properties:
Optional properties:
-Pins on the device (for linking into audio routes) for RT5663/RT5668:
+Pins on the device (for linking into audio routes) for RT5663:
* IN1P
* IN1N
diff --git a/Documentation/devicetree/bindings/sound/rt5665.txt b/Documentation/devicetree/bindings/sound/rt5665.txt
new file mode 100755
index 000000000000..419c89219681
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5665.txt
@@ -0,0 +1,68 @@
+RT5665/RT5666/RT5668 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : One of "realtek,rt5665", "realtek,rt5666" or "realtek,rt5668".
+
+- reg : The I2C address of the device.
+
+- interrupts : The CODEC's interrupt output.
+
+Optional properties:
+
+- realtek,in1-differential
+- realtek,in2-differential
+- realtek,in3-differential
+- realtek,in4-differential
+ Boolean. Indicate MIC1/2/3/4 input are differential, rather than single-ended.
+
+- realtek,dmic1-data-pin
+ 0: dmic1 is not used
+ 1: using GPIO4 pin as dmic1 data pin
+ 2: using IN2N pin as dmic2 data pin
+
+- realtek,dmic2-data-pin
+ 0: dmic2 is not used
+ 1: using GPIO5 pin as dmic2 data pin
+ 2: using IN2P pin as dmic2 data pin
+
+- realtek,jd-src
+ 0: No JD is used
+ 1: using JD1 as JD source
+
+- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
+
+Pins on the device (for linking into audio routes) for RT5659/RT5658:
+
+ * DMIC L1
+ * DMIC R1
+ * DMIC L2
+ * DMIC R2
+ * IN1P
+ * IN1N
+ * IN2P
+ * IN2N
+ * IN3P
+ * IN3N
+ * IN4P
+ * IN4N
+ * HPOL
+ * HPOR
+ * LOUTL
+ * LOUTR
+ * MONOOUT
+ * PDML
+ * PDMR
+
+Example:
+
+rt5659 {
+ compatible = "realtek,rt5665";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio>;
+ interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
+ realtek,ldo1-en-gpios =
+ <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt
new file mode 100644
index 000000000000..94442e5673b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt
@@ -0,0 +1,38 @@
+Samsung Exynos5433 TM2(E) audio complex with WM5110 codec
+
+Required properties:
+
+ - compatible : "samsung,tm2-audio"
+ - model : the user-visible name of this sound complex
+ - audio-codec : the phandle of the wm5110 audio codec node,
+ as described in ../mfd/arizona.txt
+ - i2s-controller : the phandle of the I2S controller
+ - audio-amplifier : the phandle of the MAX98504 amplifier
+ - samsung,audio-routing : a list of the connections between audio components;
+ each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source; valid names for sources and sinks are the
+ WM5110's and MAX98504's pins and the jacks on the
+ board: HP, SPK, Main Mic, Sub Mic, Third Mic,
+ Headset Mic
+ - mic-bias-gpios : GPIO pin that enables the Main Mic bias regulator
+
+
+Example:
+
+sound {
+ compatible = "samsung,tm2-audio";
+ audio-codec = <&wm5110>;
+ i2s-controller = <&i2s0>;
+ audio-amplifier = <&max98504>;
+ mic-bias-gpios = <&gpr3 2 0>;
+ model = "wm5110";
+ samsung,audio-routing =
+ "HP", "HPOUT1L",
+ "HP", "HPOUT1R",
+ "SPK", "SPKOUT",
+ "SPKOUT", "HPOUT2L",
+ "SPKOUT", "HPOUT2R",
+ "Main Mic", "MICBIAS2",
+ "IN1R", "Main Mic";
+};
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index 0dce690f78f5..3033bd8aab0f 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -1,8 +1,12 @@
* Allwinner A10 Codec
Required properties:
-- compatible: must be either "allwinner,sun4i-a10-codec" or
- "allwinner,sun7i-a20-codec"
+- compatible: must be one of the following compatibles:
+ - "allwinner,sun4i-a10-codec"
+ - "allwinner,sun6i-a31-codec"
+ - "allwinner,sun7i-a20-codec"
+ - "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -17,6 +21,43 @@ Required properties:
Optional properties:
- allwinner,pa-gpios: gpio to enable external amplifier
+Required properties for the following compatibles:
+ - "allwinner,sun6i-a31-codec"
+ - "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
+- resets: phandle to the reset control for this device
+- allwinner,audio-routing: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names include:
+
+ Audio pins on the SoC:
+ "HP"
+ "HPCOM"
+ "LINEIN"
+ "LINEOUT" (not on sun8i-a23)
+ "MIC1"
+ "MIC2"
+ "MIC3" (sun6i-a31 only)
+
+ Microphone biases from the SoC:
+ "HBIAS"
+ "MBIAS"
+
+ Board connectors:
+ "Headphone"
+ "Headset Mic"
+ "Line In"
+ "Line Out"
+ "Mic"
+ "Speaker"
+
+Required properties for the following compatibles:
+ - "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
+- allwinner,codec-analog-controls: A phandle to the codec analog controls
+ block in the PRCM.
+
Example:
codec: codec@01c22c00 {
#sound-dai-cells = <0>;
@@ -28,3 +69,23 @@ codec: codec@01c22c00 {
dmas = <&dma 0 19>, <&dma 0 19>;
dma-names = "rx", "tx";
};
+
+codec: codec@01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun6i-a31-codec";
+ reg = <0x01c22c00 0x98>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_APB1_CODEC>, <&ccu CLK_CODEC>;
+ clock-names = "apb", "codec";
+ resets = <&ccu RST_APB1_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Speaker", "LINEOUT",
+ "LINEIN", "Line In",
+ "MIC1", "MBIAS",
+ "MIC1", "Mic",
+ "MIC2", "HBIAS",
+ "MIC2", "Headset Mic";
+};
diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
new file mode 100644
index 000000000000..779b735781ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
@@ -0,0 +1,16 @@
+* Allwinner Codec Analog Controls
+
+Required properties:
+- compatible: must be one of the following compatibles:
+ - "allwinner,sun8i-a23-codec-analog"
+ - "allwinner,sun8i-h3-codec-analog"
+
+Required properties if not a sub-node of the PRCM node:
+- reg: must contain the registers location and length
+
+Example:
+prcm: prcm@01f01400 {
+ codec_analog: codec-analog {
+ compatible = "allwinner,sun8i-a23-codec-analog";
+ };
+};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
index 9340d2ddcc54..6fbba562eaa7 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
@@ -12,6 +12,7 @@ Required properties:
"ti,tlv320aic3120" - TLV320AIC3120 (mono speaker amp, MiniDSP)
"ti,tlv320aic3111" - TLV320AIC3111 (stereo speaker amp, MiniDSP)
"ti,tlv320dac3100" - TLV320DAC3100 (no ADC, mono speaker amp, no MiniDSP)
+ "ti,tlv320dac3101" - TLV320DAC3101 (no ADC, stereo speaker amp, no MiniDSP)
- reg - <int> - I2C slave address
- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
diff --git a/Documentation/devicetree/bindings/sound/wm8580.txt b/Documentation/devicetree/bindings/sound/wm8580.txt
index 7d9821f348da..78fce9b14954 100644
--- a/Documentation/devicetree/bindings/sound/wm8580.txt
+++ b/Documentation/devicetree/bindings/sound/wm8580.txt
@@ -1,10 +1,10 @@
-WM8580 audio CODEC
+WM8580 and WM8581 audio CODEC
This device supports I2C only.
Required properties:
- - compatible : "wlf,wm8580"
+ - compatible : "wlf,wm8580", "wlf,wm8581"
- reg : the I2C address of the device.
diff --git a/Documentation/devicetree/bindings/sram/sram.txt b/Documentation/devicetree/bindings/sram/sram.txt
index add48f09015e..068c2c03c38f 100644
--- a/Documentation/devicetree/bindings/sram/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sram.txt
@@ -4,7 +4,7 @@ Simple IO memory regions to be managed by the genalloc API.
Required properties:
-- compatible : mmio-sram
+- compatible : mmio-sram or atmel,sama5d2-securam
- reg : SRAM iomem address range
diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
new file mode 100644
index 000000000000..474531d2b2c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
@@ -0,0 +1,17 @@
+Binding for Thermal Sensor driver for BCM2835 SoCs.
+
+Required parameters:
+-------------------
+
+compatible: should be one of: "brcm,bcm2835-thermal",
+ "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal"
+reg: Address range of the thermal registers.
+clocks: Phandle of the clock used by the thermal sensor.
+
+Example:
+
+thermal: thermal@7e212000 {
+ compatible = "brcm,bcm2835-thermal";
+ reg = <0x7e212000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_TSENS>;
+};
diff --git a/Documentation/devicetree/bindings/thermal/st-thermal.txt b/Documentation/devicetree/bindings/thermal/st-thermal.txt
index 3b9251b4a145..a2f939137e35 100644
--- a/Documentation/devicetree/bindings/thermal/st-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/st-thermal.txt
@@ -3,17 +3,8 @@ Binding for Thermal Sensor driver for STMicroelectronics STi series of SoCs.
Required parameters:
-------------------
-compatible : st,<SoC>-<module>-thermal; should be one of:
- "st,stih415-sas-thermal",
- "st,stih415-mpe-thermal",
- "st,stih416-sas-thermal"
- "st,stih416-mpe-thermal"
- "st,stid127-thermal" or
- "st,stih407-thermal"
- according to the SoC type (stih415, stih416, stid127, stih407)
- and module type (sas or mpe). On stid127 & stih407 there is only
- one die/module, so there is no module type in the compatible
- string.
+compatible : Should be "st,stih407-thermal"
+
clock-names : Should be "thermal".
See: Documentation/devicetree/bindings/resource-names.txt
clocks : Phandle of the clock used by the thermal sensor.
@@ -25,18 +16,17 @@ Optional parameters:
reg : For non-sysconf based sensors, this should be the physical base
address and length of the sensor's registers.
interrupts : Standard way to define interrupt number.
- Interrupt is mandatory to be defined when compatible is
- "stih416-mpe-thermal".
NB: For thermal sensor's for which no interrupt has been
defined, a polling delay of 1000ms will be used to read the
temperature from device.
Example:
- temp1@fdfe8000 {
- compatible = "st,stih416-mpe-thermal";
- reg = <0xfdfe8000 0x10>;
- clock-names = "thermal";
- clocks = <&clk_m_mpethsens>;
- interrupts = <GIC_SPI 23 IRQ_TYPE_NONE>;
+ temp0@91a0000 {
+ compatible = "st,stih407-thermal";
+ reg = <0x91a0000 0x28>;
+ clock-names = "thermal";
+ clocks = <&CLK_SYSIN>;
+ interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
+ st,passive_cooling_temp = <110>;
};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
new file mode 100644
index 000000000000..e3cfce8fecc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
@@ -0,0 +1,17 @@
+NPS Network Processor
+
+Required properties:
+
+- compatible : should be "ezchip,nps400-timer0"
+
+Clocks required for compatible = "ezchip,nps400-timer0":
+- interrupts : The interrupt of the first timer
+- clocks : Must contain a single entry describing the clock input
+
+Example:
+
+timer {
+ compatible = "ezchip,nps400-timer0";
+ interrupts = <3>;
+ clocks = <&sysclk>;
+};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
index c8c03d700382..c0ab4190b8fb 100644
--- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
@@ -2,14 +2,14 @@ NPS Network Processor
Required properties:
-- compatible : should be "ezchip,nps400-timer"
+- compatible : should be "ezchip,nps400-timer1"
-Clocks required for compatible = "ezchip,nps400-timer":
+Clocks required for compatible = "ezchip,nps400-timer1":
- clocks : Must contain a single entry describing the clock input
Example:
timer {
- compatible = "ezchip,nps400-timer";
+ compatible = "ezchip,nps400-timer1";
clocks = <&sysclk>;
};
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index f4262ed60582..ad8ea56a9ed3 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -6,9 +6,9 @@ Required properties:
- compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
used in host mode.
- reg: Address and length of the register set for the device
- - interrupts: Should contain ehci interrupt
+ - interrupts: Should contain ohci interrupt
- clocks: Should reference the peripheral, host and system clocks
- - clock-names: Should contains two strings
+ - clock-names: Should contain three strings
"ohci_clk" for the peripheral clock
"hclk" for the host clock
"uhpck" for the system clock
@@ -35,7 +35,7 @@ Required properties:
- reg: Address and length of the register set for the device
- interrupts: Should contain ehci interrupt
- clocks: Should reference the peripheral and the UTMI clocks
- - clock-names: Should contains two strings
+ - clock-names: Should contain two strings
"ehci_clk" for the peripheral clock
"usb_clk" for the UTMI clock
@@ -58,7 +58,7 @@ Required properties:
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
- clocks: Should reference the peripheral and the AHB clocks
- - clock-names: Should contains two strings
+ - clock-names: Should contain two strings
"pclk" for the peripheral clock
"hclk" for the AHB clock
@@ -85,7 +85,7 @@ Required properties:
- reg: Address and length of the register set for the device
- interrupts: Should contain usba interrupt
- clocks: Should reference the peripheral and host clocks
- - clock-names: Should contains two strings
+ - clock-names: Should contain two strings
"pclk" for the peripheral clock
"hclk" for the host clock
- ep childnode: To specify the number of endpoints and their properties.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 98371753a08f..16d3b5e7f5d1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -24,9 +24,11 @@ ampire Ampire Co., Ltd.
ams AMS AG
amstaos AMS-Taos Inc.
analogix Analogix Semiconductor, Inc.
+andestech Andes Technology Corporation
apm Applied Micro Circuits Corporation (APM)
aptina Aptina Imaging
arasan Arasan Chip Systems
+aries Aries Embedded GmbH
arm ARM Ltd.
armadeus ARMadeus Systems SARL
arrow Arrow Electronics
@@ -68,6 +70,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
@@ -137,6 +140,7 @@ infineon Infineon Technologies
inforce Inforce Computing
ingenic Ingenic Semiconductor
innolux Innolux Corporation
+inside-secure INSIDE Secure
intel Intel Corporation
intercontrol Inter Control Group
invensense InvenSense Inc.
@@ -160,6 +164,7 @@ lg LG Corporation
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
+macnica Macnica Americas
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
mcube mCube
@@ -185,20 +190,24 @@ mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
mundoreader Mundo Reader S.L.
murata Murata Manufacturing Co., Ltd.
mxicy Macronix International Co., Ltd.
+myir MYIR Tech Limited
national National Semiconductor
nec NEC LCD Technologies, Ltd.
neonode Neonode Inc.
netgear NETGEAR
netlogic Broadcom Corporation (formerly NetLogic Microsystems)
netxeon Shenzhen Netxeon Technology CO., LTD
+nexbox Nexbox
newhaven Newhaven Display International
-nvd New Vision Display
+ni National Instruments
nintendo Nintendo
nokia Nokia
nuvoton Nuvoton Technology Corporation
+nvd New Vision Display
nvidia NVIDIA
nxp NXP Semiconductors
okaya Okaya Electric America, Inc.
+oki Oki Electric Industry Co., Ltd.
olimex OLIMEX Ltd.
onion Onion Corporation
onnn ON Semiconductor Corp.
@@ -214,6 +223,7 @@ parade Parade Technologies Inc.
pericom Pericom Technology Inc.
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
+pine64 Pine64
pixcir PIXCIR MICROELECTRONICS Co., Ltd
plathome Plat'Home Co., Ltd.
plda PLDA
@@ -235,8 +245,10 @@ realtek Realtek Semiconductor Corp.
renesas Renesas Electronics Corporation
richtek Richtek Technology Corporation
ricoh Ricoh Co. Ltd.
+rikomagic Rikomagic Tech Corp. Ltd
rockchip Fuzhou Rockchip Electronics Co., Ltd
samsung Samsung Semiconductor
+samtec Samtec/Softing company
sandisk Sandisk Corporation
sbs Smart Battery System
schindler Schindler
@@ -281,6 +293,7 @@ tcg Trusted Computing Group
tcl Toby Churchill Ltd.
technexion TechNexion
technologic Technologic Systems
+terasic Terasic Inc.
thine THine Electronics, Inc.
ti Texas Instruments
tlm Trusted Logic Mobility
@@ -295,6 +308,7 @@ tronfy Tronfy
tronsmart Tronsmart
truly Truly Semiconductors Limited
tyan Tyan Computer Corporation
+udoo Udoo
uniwest United Western Technologies Corp (UniWest)
upisemi uPI Semiconductor Corp.
urt United Radiant Technology Corporation
diff --git a/Documentation/dmaengine/client.txt b/Documentation/dmaengine/client.txt
index 9e33189745f0..c72b4563de10 100644
--- a/Documentation/dmaengine/client.txt
+++ b/Documentation/dmaengine/client.txt
@@ -37,8 +37,8 @@ The slave DMA usage consists of following steps:
2. Set slave and controller specific parameters
Next step is always to pass some specific information to the DMA
- driver. Most of the generic information which a slave DMA can use
- is in struct dma_slave_config. This allows the clients to specify
+ driver. Most of the generic information which a slave DMA can use
+ is in struct dma_slave_config. This allows the clients to specify
DMA direction, DMA addresses, bus widths, DMA burst lengths etc
for the peripheral.
@@ -52,7 +52,7 @@ The slave DMA usage consists of following steps:
struct dma_slave_config *config)
Please see the dma_slave_config structure definition in dmaengine.h
- for a detailed explanation of the struct members. Please note
+ for a detailed explanation of the struct members. Please note
that the 'direction' member will be going away as it duplicates the
direction given in the prepare call.
@@ -101,7 +101,7 @@ The slave DMA usage consists of following steps:
desc = dmaengine_prep_slave_sg(chan, sgl, nr_sg, direction, flags);
Once a descriptor has been obtained, the callback information can be
- added and the descriptor must then be submitted. Some DMA engine
+ added and the descriptor must then be submitted. Some DMA engine
drivers may hold a spinlock between a successful preparation and
submission so it is important that these two operations are closely
paired.
@@ -138,7 +138,7 @@ The slave DMA usage consists of following steps:
activity via other DMA engine calls not covered in this document.
dmaengine_submit() will not start the DMA operation, it merely adds
- it to the pending queue. For this, see step 5, dma_async_issue_pending.
+ it to the pending queue. For this, see step 5, dma_async_issue_pending.
5. Issue pending DMA requests and wait for callback notification
@@ -184,13 +184,13 @@ Further APIs:
3. int dmaengine_resume(struct dma_chan *chan)
- Resume a previously paused DMA channel. It is invalid to resume a
+ Resume a previously paused DMA channel. It is invalid to resume a
channel which is not currently paused.
4. enum dma_status dma_async_is_tx_complete(struct dma_chan *chan,
dma_cookie_t cookie, dma_cookie_t *last, dma_cookie_t *used)
- This can be used to check the status of the channel. Please see
+ This can be used to check the status of the channel. Please see
the documentation in include/linux/dmaengine.h for a more complete
description of this API.
@@ -200,7 +200,7 @@ Further APIs:
Note:
Not all DMA engine drivers can return reliable information for
- a running DMA channel. It is recommended that DMA engine users
+ a running DMA channel. It is recommended that DMA engine users
pause or stop (via dmaengine_terminate_all()) the channel before
using this API.
diff --git a/Documentation/dmaengine/dmatest.txt b/Documentation/dmaengine/dmatest.txt
index dd77a81bdb80..fb683c72dea8 100644
--- a/Documentation/dmaengine/dmatest.txt
+++ b/Documentation/dmaengine/dmatest.txt
@@ -34,7 +34,7 @@ command:
% ls -1 /sys/class/dma/
Once started a message like "dmatest: Started 1 threads using dma0chan0" is
-emitted. After that only test failure messages are reported until the test
+emitted. After that only test failure messages are reported until the test
stops.
Note that running a new test will not stop any in progress test.
@@ -43,11 +43,11 @@ The following command returns the state of the test.
% cat /sys/module/dmatest/parameters/run
To wait for test completion userpace can poll 'run' until it is false, or use
-the wait parameter. Specifying 'wait=1' when loading the module causes module
+the wait parameter. Specifying 'wait=1' when loading the module causes module
initialization to pause until a test run has completed, while reading
/sys/module/dmatest/parameters/wait waits for any running test to complete
-before returning. For example, the following scripts wait for 42 tests
-to complete before exiting. Note that if 'iterations' is set to 'infinite' then
+before returning. For example, the following scripts wait for 42 tests
+to complete before exiting. Note that if 'iterations' is set to 'infinite' then
waiting is disabled.
Example:
@@ -81,7 +81,7 @@ Example of output:
The message format is unified across the different types of errors. A number in
the parens represents additional information, e.g. error code, error counter,
-or status. A test thread also emits a summary line at completion listing the
+or status. A test thread also emits a summary line at completion listing the
number of tests executed, number that failed, and a result code.
Example:
diff --git a/Documentation/dmaengine/provider.txt b/Documentation/dmaengine/provider.txt
index c4fd47540b31..e33bc1c8ed2c 100644
--- a/Documentation/dmaengine/provider.txt
+++ b/Documentation/dmaengine/provider.txt
@@ -384,7 +384,7 @@ where to put them)
- The descriptor should be prepared for reuse by invoking
dmaengine_desc_set_reuse() which will set DMA_CTRL_REUSE.
- dmaengine_desc_set_reuse() will succeed only when channel support
- reusable descriptor as exhibited by capablities
+ reusable descriptor as exhibited by capabilities
- As a consequence, if a device driver wants to skip the dma_map_sg() and
dma_unmap_sg() in between 2 transfers, because the DMA'd data wasn't used,
it can resubmit the transfer right after its completion.
diff --git a/Documentation/dmaengine/pxa_dma.txt b/Documentation/dmaengine/pxa_dma.txt
index 413ef9cfaa4d..0736d44b5438 100644
--- a/Documentation/dmaengine/pxa_dma.txt
+++ b/Documentation/dmaengine/pxa_dma.txt
@@ -29,7 +29,7 @@ Constraints
d) Bandwidth guarantee
The PXA architecture has 4 levels of DMAs priorities : high, normal, low.
- The high prorities get twice as much bandwidth as the normal, which get twice
+ The high priorities get twice as much bandwidth as the normal, which get twice
as much as the low priorities.
A driver should be able to request a priority, especially the real-time
ones such as pxa_camera with (big) throughputs.
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 5385cba941d2..a23edccd2059 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -139,7 +139,6 @@ hpet_example
hugepage-mmap
hugepage-shm
ihex2fw
-ikconfig.h*
inat-tables.c
initramfs_list
int16.c
diff --git a/Documentation/driver-api/edac.rst b/Documentation/driver-api/edac.rst
new file mode 100644
index 000000000000..b8c742aa0a71
--- /dev/null
+++ b/Documentation/driver-api/edac.rst
@@ -0,0 +1,178 @@
+Error Detection And Correction (EDAC) Devices
+=============================================
+
+Main Concepts used at the EDAC subsystem
+----------------------------------------
+
+There are several things to be aware of that aren't at all obvious, like
+*sockets, *socket sets*, *banks*, *rows*, *chip-select rows*, *channels*,
+etc...
+
+These are some of the many terms that are thrown about that don't always
+mean what people think they mean (Inconceivable!). In the interest of
+creating a common ground for discussion, terms and their definitions
+will be established.
+
+* Memory devices
+
+The individual DRAM chips on a memory stick. These devices commonly
+output 4 and 8 bits each (x4, x8). Grouping several of these in parallel
+provides the number of bits that the memory controller expects:
+typically 72 bits, in order to provide 64 bits + 8 bits of ECC data.
+
+* Memory Stick
+
+A printed circuit board that aggregates multiple memory devices in
+parallel. In general, this is the Field Replaceable Unit (FRU) which
+gets replaced, in the case of excessive errors. Most often it is also
+called DIMM (Dual Inline Memory Module).
+
+* Memory Socket
+
+A physical connector on the motherboard that accepts a single memory
+stick. Also called as "slot" on several datasheets.
+
+* Channel
+
+A memory controller channel, responsible to communicate with a group of
+DIMMs. Each channel has its own independent control (command) and data
+bus, and can be used independently or grouped with other channels.
+
+* Branch
+
+It is typically the highest hierarchy on a Fully-Buffered DIMM memory
+controller. Typically, it contains two channels. Two channels at the
+same branch can be used in single mode or in lockstep mode. When
+lockstep is enabled, the cacheline is doubled, but it generally brings
+some performance penalty. Also, it is generally not possible to point to
+just one memory stick when an error occurs, as the error correction code
+is calculated using two DIMMs instead of one. Due to that, it is capable
+of correcting more errors than on single mode.
+
+* Single-channel
+
+The data accessed by the memory controller is contained into one dimm
+only. E. g. if the data is 64 bits-wide, the data flows to the CPU using
+one 64 bits parallel access. Typically used with SDR, DDR, DDR2 and DDR3
+memories. FB-DIMM and RAMBUS use a different concept for channel, so
+this concept doesn't apply there.
+
+* Double-channel
+
+The data size accessed by the memory controller is interlaced into two
+dimms, accessed at the same time. E. g. if the DIMM is 64 bits-wide (72
+bits with ECC), the data flows to the CPU using a 128 bits parallel
+access.
+
+* Chip-select row
+
+This is the name of the DRAM signal used to select the DRAM ranks to be
+accessed. Common chip-select rows for single channel are 64 bits, for
+dual channel 128 bits. It may not be visible by the memory controller,
+as some DIMM types have a memory buffer that can hide direct access to
+it from the Memory Controller.
+
+* Single-Ranked stick
+
+A Single-ranked stick has 1 chip-select row of memory. Motherboards
+commonly drive two chip-select pins to a memory stick. A single-ranked
+stick, will occupy only one of those rows. The other will be unused.
+
+.. _doubleranked:
+
+* Double-Ranked stick
+
+A double-ranked stick has two chip-select rows which access different
+sets of memory devices. The two rows cannot be accessed concurrently.
+
+* Double-sided stick
+
+**DEPRECATED TERM**, see :ref:`Double-Ranked stick <doubleranked>`.
+
+A double-sided stick has two chip-select rows which access different sets
+of memory devices. The two rows cannot be accessed concurrently.
+"Double-sided" is irrespective of the memory devices being mounted on
+both sides of the memory stick.
+
+* Socket set
+
+All of the memory sticks that are required for a single memory access or
+all of the memory sticks spanned by a chip-select row. A single socket
+set has two chip-select rows and if double-sided sticks are used these
+will occupy those chip-select rows.
+
+* Bank
+
+This term is avoided because it is unclear when needing to distinguish
+between chip-select rows and socket sets.
+
+
+Memory Controllers
+------------------
+
+Most of the EDAC core is focused on doing Memory Controller error detection.
+The :c:func:`edac_mc_alloc`. It uses internally the struct ``mem_ctl_info``
+to describe the memory controllers, with is an opaque struct for the EDAC
+drivers. Only the EDAC core is allowed to touch it.
+
+.. kernel-doc:: include/linux/edac.h
+
+.. kernel-doc:: drivers/edac/edac_mc.h
+
+PCI Controllers
+---------------
+
+The EDAC subsystem provides a mechanism to handle PCI controllers by calling
+the :c:func:`edac_pci_alloc_ctl_info`. It will use the struct
+:c:type:`edac_pci_ctl_info` to describe the PCI controllers.
+
+.. kernel-doc:: drivers/edac/edac_pci.h
+
+EDAC Blocks
+-----------
+
+The EDAC subsystem also provides a generic mechanism to report errors on
+other parts of the hardware via :c:func:`edac_device_alloc_ctl_info` function.
+
+The structures :c:type:`edac_dev_sysfs_block_attribute`,
+:c:type:`edac_device_block`, :c:type:`edac_device_instance` and
+:c:type:`edac_device_ctl_info` provide a generic or abstract 'edac_device'
+representation at sysfs.
+
+This set of structures and the code that implements the APIs for the same, provide for registering EDAC type devices which are NOT standard memory or
+PCI, like:
+
+- CPU caches (L1 and L2)
+- DMA engines
+- Core CPU switches
+- Fabric switch units
+- PCIe interface controllers
+- other EDAC/ECC type devices that can be monitored for
+ errors, etc.
+
+It allows for a 2 level set of hierarchy.
+
+For example, a cache could be composed of L1, L2 and L3 levels of cache.
+Each CPU core would have its own L1 cache, while sharing L2 and maybe L3
+caches. On such case, those can be represented via the following sysfs
+nodes::
+
+ /sys/devices/system/edac/..
+
+ pci/ <existing pci directory (if available)>
+ mc/ <existing memory device directory>
+ cpu/cpu0/.. <L1 and L2 block directory>
+ /L1-cache/ce_count
+ /ue_count
+ /L2-cache/ce_count
+ /ue_count
+ cpu/cpu1/.. <L1 and L2 block directory>
+ /L1-cache/ce_count
+ /ue_count
+ /L2-cache/ce_count
+ /ue_count
+ ...
+
+ the L1 and L2 directories would be "edac_device_block's"
+
+.. kernel-doc:: drivers/edac/edac_device.h
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index a528178a54a5..5475a2807e7a 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -26,6 +26,7 @@ available subsections can be seen below.
spi
i2c
hsi
+ edac
miscellaneous
vme
80211/index
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
deleted file mode 100644
index f89cfd85ae13..000000000000
--- a/Documentation/edac.txt
+++ /dev/null
@@ -1,812 +0,0 @@
-EDAC - Error Detection And Correction
-=====================================
-
-"bluesmoke" was the name for this device driver when it
-was "out-of-tree" and maintained at sourceforge.net -
-bluesmoke.sourceforge.net. That site is mostly archaic now and can be
-used only for historical purposes.
-
-When the subsystem was pushed into 2.6.16 for the first time, it was
-renamed to 'EDAC'.
-
-PURPOSE
--------
-
-The 'edac' kernel module's goal is to detect and report hardware errors
-that occur within the computer system running under linux.
-
-MEMORY
-------
-
-Memory Correctable Errors (CE) and Uncorrectable Errors (UE) are the
-primary errors being harvested. These types of errors are harvested by
-the 'edac_mc' device.
-
-Detecting CE events, then harvesting those events and reporting them,
-*can* but must not necessarily be a predictor of future UE events. With
-CE events only, the system can and will continue to operate as no data
-has been damaged yet.
-
-However, preventive maintenance and proactive part replacement of memory
-DIMMs exhibiting CEs can reduce the likelihood of the dreaded UE events
-and system panics.
-
-OTHER HARDWARE ELEMENTS
------------------------
-
-A new feature for EDAC, the edac_device class of device, was added in
-the 2.6.23 version of the kernel.
-
-This new device type allows for non-memory type of ECC hardware detectors
-to have their states harvested and presented to userspace via the sysfs
-interface.
-
-Some architectures have ECC detectors for L1, L2 and L3 caches,
-along with DMA engines, fabric switches, main data path switches,
-interconnections, and various other hardware data paths. If the hardware
-reports it, then a edac_device device probably can be constructed to
-harvest and present that to userspace.
-
-
-PCI BUS SCANNING
-----------------
-
-In addition, PCI devices are scanned for PCI Bus Parity and SERR Errors
-in order to determine if errors are occurring during data transfers.
-
-The presence of PCI Parity errors must be examined with a grain of salt.
-There are several add-in adapters that do *not* follow the PCI specification
-with regards to Parity generation and reporting. The specification says
-the vendor should tie the parity status bits to 0 if they do not intend
-to generate parity. Some vendors do not do this, and thus the parity bit
-can "float" giving false positives.
-
-There is a PCI device attribute located in sysfs that is checked by
-the EDAC PCI scanning code. If that attribute is set, PCI parity/error
-scanning is skipped for that device. The attribute is:
-
- broken_parity_status
-
-and is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for
-PCI devices.
-
-
-VERSIONING
-----------
-
-EDAC is composed of a "core" module (edac_core.ko) and several Memory
-Controller (MC) driver modules. On a given system, the CORE is loaded
-and one MC driver will be loaded. Both the CORE and the MC driver (or
-edac_device driver) have individual versions that reflect current
-release level of their respective modules.
-
-Thus, to "report" on what version a system is running, one must report
-both the CORE's and the MC driver's versions.
-
-
-LOADING
--------
-
-If 'edac' was statically linked with the kernel then no loading
-is necessary. If 'edac' was built as modules then simply modprobe
-the 'edac' pieces that you need. You should be able to modprobe
-hardware-specific modules and have the dependencies load the necessary
-core modules.
-
-Example:
-
-$> modprobe amd76x_edac
-
-loads both the amd76x_edac.ko memory controller module and the edac_mc.ko
-core module.
-
-
-SYSFS INTERFACE
----------------
-
-EDAC presents a 'sysfs' interface for control and reporting purposes. It
-lives in the /sys/devices/system/edac directory.
-
-Within this directory there currently reside 2 components:
-
- mc memory controller(s) system
- pci PCI control and status system
-
-
-
-Memory Controller (mc) Model
-----------------------------
-
-Each 'mc' device controls a set of DIMM memory modules. These modules
-are laid out in a Chip-Select Row (csrowX) and Channel table (chX).
-There can be multiple csrows and multiple channels.
-
-Memory controllers allow for several csrows, with 8 csrows being a
-typical value. Yet, the actual number of csrows depends on the layout of
-a given motherboard, memory controller and DIMM characteristics.
-
-Dual channels allows for 128 bit data transfers to/from the CPU from/to
-memory. Some newer chipsets allow for more than 2 channels, like Fully
-Buffered DIMMs (FB-DIMMs). The following example will assume 2 channels:
-
-
- Channel 0 Channel 1
- ===================================
- csrow0 | DIMM_A0 | DIMM_B0 |
- csrow1 | DIMM_A0 | DIMM_B0 |
- ===================================
-
- ===================================
- csrow2 | DIMM_A1 | DIMM_B1 |
- csrow3 | DIMM_A1 | DIMM_B1 |
- ===================================
-
-In the above example table there are 4 physical slots on the motherboard
-for memory DIMMs:
-
- DIMM_A0
- DIMM_B0
- DIMM_A1
- DIMM_B1
-
-Labels for these slots are usually silk-screened on the motherboard.
-Slots labeled 'A' are channel 0 in this example. Slots labeled 'B' are
-channel 1. Notice that there are two csrows possible on a physical DIMM.
-These csrows are allocated their csrow assignment based on the slot into
-which the memory DIMM is placed. Thus, when 1 DIMM is placed in each
-Channel, the csrows cross both DIMMs.
-
-Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
-Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above
-will have 1 csrow, csrow0. csrow1 will be empty. On the other hand,
-when 2 dual ranked DIMMs are similarly placed, then both csrow0 and
-csrow1 will be populated. The pattern repeats itself for csrow2 and
-csrow3.
-
-The representation of the above is reflected in the directory
-tree in EDAC's sysfs interface. Starting in directory
-/sys/devices/system/edac/mc each memory controller will be represented
-by its own 'mcX' directory, where 'X' is the index of the MC.
-
-
- ..../edac/mc/
- |
- |->mc0
- |->mc1
- |->mc2
- ....
-
-Under each 'mcX' directory each 'csrowX' is again represented by a
-'csrowX', where 'X' is the csrow index:
-
-
- .../mc/mc0/
- |
- |->csrow0
- |->csrow2
- |->csrow3
- ....
-
-Notice that there is no csrow1, which indicates that csrow0 is composed
-of a single ranked DIMMs. This should also apply in both Channels, in
-order to have dual-channel mode be operational. Since both csrow2 and
-csrow3 are populated, this indicates a dual ranked set of DIMMs for
-channels 0 and 1.
-
-
-Within each of the 'mcX' and 'csrowX' directories are several EDAC
-control and attribute files.
-
-
-'mcX' directories
------------------
-
-In 'mcX' directories are EDAC control and attribute files for
-this 'X' instance of the memory controllers.
-
-For a description of the sysfs API, please see:
- Documentation/ABI/testing/sysfs-devices-edac
-
-
-
-'csrowX' directories
---------------------
-
-When CONFIG_EDAC_LEGACY_SYSFS is enabled, sysfs will contain the csrowX
-directories. As this API doesn't work properly for Rambus, FB-DIMMs and
-modern Intel Memory Controllers, this is being deprecated in favor of
-dimmX directories.
-
-In the 'csrowX' directories are EDAC control and attribute files for
-this 'X' instance of csrow:
-
-
-Total Uncorrectable Errors count attribute file:
-
- 'ue_count'
-
- This attribute file displays the total count of uncorrectable
- errors that have occurred on this csrow. If panic_on_ue is set
- this counter will not have a chance to increment, since EDAC
- will panic the system.
-
-
-Total Correctable Errors count attribute file:
-
- 'ce_count'
-
- This attribute file displays the total count of correctable
- errors that have occurred on this csrow. This count is very
- important to examine. CEs provide early indications that a
- DIMM is beginning to fail. This count field should be
- monitored for non-zero values and report such information
- to the system administrator.
-
-
-Total memory managed by this csrow attribute file:
-
- 'size_mb'
-
- This attribute file displays, in count of megabytes, the memory
- that this csrow contains.
-
-
-Memory Type attribute file:
-
- 'mem_type'
-
- This attribute file will display what type of memory is currently
- on this csrow. Normally, either buffered or unbuffered memory.
- Examples:
- Registered-DDR
- Unbuffered-DDR
-
-
-EDAC Mode of operation attribute file:
-
- 'edac_mode'
-
- This attribute file will display what type of Error detection
- and correction is being utilized.
-
-
-Device type attribute file:
-
- 'dev_type'
-
- This attribute file will display what type of DRAM device is
- being utilized on this DIMM.
- Examples:
- x1
- x2
- x4
- x8
-
-
-Channel 0 CE Count attribute file:
-
- 'ch0_ce_count'
-
- This attribute file will display the count of CEs on this
- DIMM located in channel 0.
-
-
-Channel 0 UE Count attribute file:
-
- 'ch0_ue_count'
-
- This attribute file will display the count of UEs on this
- DIMM located in channel 0.
-
-
-Channel 0 DIMM Label control file:
-
- 'ch0_dimm_label'
-
- This control file allows this DIMM to have a label assigned
- to it. With this label in the module, when errors occur
- the output can provide the DIMM label in the system log.
- This becomes vital for panic events to isolate the
- cause of the UE event.
-
- DIMM Labels must be assigned after booting, with information
- that correctly identifies the physical slot with its
- silk screen label. This information is currently very
- motherboard specific and determination of this information
- must occur in userland at this time.
-
-
-Channel 1 CE Count attribute file:
-
- 'ch1_ce_count'
-
- This attribute file will display the count of CEs on this
- DIMM located in channel 1.
-
-
-Channel 1 UE Count attribute file:
-
- 'ch1_ue_count'
-
- This attribute file will display the count of UEs on this
- DIMM located in channel 0.
-
-
-Channel 1 DIMM Label control file:
-
- 'ch1_dimm_label'
-
- This control file allows this DIMM to have a label assigned
- to it. With this label in the module, when errors occur
- the output can provide the DIMM label in the system log.
- This becomes vital for panic events to isolate the
- cause of the UE event.
-
- DIMM Labels must be assigned after booting, with information
- that correctly identifies the physical slot with its
- silk screen label. This information is currently very
- motherboard specific and determination of this information
- must occur in userland at this time.
-
-
-
-SYSTEM LOGGING
---------------
-
-If logging for UEs and CEs is enabled, then system logs will contain
-information indicating that errors have been detected:
-
-EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0,
-channel 1 "DIMM_B1": amd76x_edac
-
-EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0,
-channel 1 "DIMM_B1": amd76x_edac
-
-
-The structure of the message is:
- the memory controller (MC0)
- Error type (CE)
- memory page (0x283)
- offset in the page (0xce0)
- the byte granularity (grain 8)
- or resolution of the error
- the error syndrome (0xb741)
- memory row (row 0)
- memory channel (channel 1)
- DIMM label, if set prior (DIMM B1
- and then an optional, driver-specific message that may
- have additional information.
-
-Both UEs and CEs with no info will lack all but memory controller, error
-type, a notice of "no info" and then an optional, driver-specific error
-message.
-
-
-PCI Bus Parity Detection
-------------------------
-
-On Header Type 00 devices, the primary status is looked at for any
-parity error regardless of whether parity is enabled on the device or
-not. (The spec indicates parity is generated in some cases). On Header
-Type 01 bridges, the secondary status register is also looked at to see
-if parity occurred on the bus on the other side of the bridge.
-
-
-SYSFS CONFIGURATION
--------------------
-
-Under /sys/devices/system/edac/pci are control and attribute files as follows:
-
-
-Enable/Disable PCI Parity checking control file:
-
- 'check_pci_parity'
-
-
- This control file enables or disables the PCI Bus Parity scanning
- operation. Writing a 1 to this file enables the scanning. Writing
- a 0 to this file disables the scanning.
-
- Enable:
- echo "1" >/sys/devices/system/edac/pci/check_pci_parity
-
- Disable:
- echo "0" >/sys/devices/system/edac/pci/check_pci_parity
-
-
-Parity Count:
-
- 'pci_parity_count'
-
- This attribute file will display the number of parity errors that
- have been detected.
-
-
-
-MODULE PARAMETERS
------------------
-
-Panic on UE control file:
-
- 'edac_mc_panic_on_ue'
-
- An uncorrectable error will cause a machine panic. This is usually
- desirable. It is a bad idea to continue when an uncorrectable error
- occurs - it is indeterminate what was uncorrected and the operating
- system context might be so mangled that continuing will lead to further
- corruption. If the kernel has MCE configured, then EDAC will never
- notice the UE.
-
- LOAD TIME: module/kernel parameter: edac_mc_panic_on_ue=[0|1]
-
- RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue
-
-
-Log UE control file:
-
- 'edac_mc_log_ue'
-
- Generate kernel messages describing uncorrectable errors. These errors
- are reported through the system message log system. UE statistics
- will be accumulated even when UE logging is disabled.
-
- LOAD TIME: module/kernel parameter: edac_mc_log_ue=[0|1]
-
- RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue
-
-
-Log CE control file:
-
- 'edac_mc_log_ce'
-
- Generate kernel messages describing correctable errors. These
- errors are reported through the system message log system.
- CE statistics will be accumulated even when CE logging is disabled.
-
- LOAD TIME: module/kernel parameter: edac_mc_log_ce=[0|1]
-
- RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce
-
-
-Polling period control file:
-
- 'edac_mc_poll_msec'
-
- The time period, in milliseconds, for polling for error information.
- Too small a value wastes resources. Too large a value might delay
- necessary handling of errors and might loose valuable information for
- locating the error. 1000 milliseconds (once each second) is the current
- default. Systems which require all the bandwidth they can get, may
- increase this.
-
- LOAD TIME: module/kernel parameter: edac_mc_poll_msec=[0|1]
-
- RUN TIME: echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec
-
-
-Panic on PCI PARITY Error:
-
- 'panic_on_pci_parity'
-
-
- This control file enables or disables panicking when a parity
- error has been detected.
-
-
- module/kernel parameter: edac_panic_on_pci_pe=[0|1]
-
- Enable:
- echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
-
- Disable:
- echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
-
-
-
-EDAC device type
-----------------
-
-In the header file, edac_core.h, there is a series of edac_device structures
-and APIs for the EDAC_DEVICE.
-
-User space access to an edac_device is through the sysfs interface.
-
-At the location /sys/devices/system/edac (sysfs) new edac_device devices will
-appear.
-
-There is a three level tree beneath the above 'edac' directory. For example,
-the 'test_device_edac' device (found at the bluesmoke.sourceforget.net website)
-installs itself as:
-
- /sys/devices/systm/edac/test-instance
-
-in this directory are various controls, a symlink and one or more 'instance'
-directories.
-
-The standard default controls are:
-
- log_ce boolean to log CE events
- log_ue boolean to log UE events
- panic_on_ue boolean to 'panic' the system if an UE is encountered
- (default off, can be set true via startup script)
- poll_msec time period between POLL cycles for events
-
-The test_device_edac device adds at least one of its own custom control:
-
- test_bits which in the current test driver does nothing but
- show how it is installed. A ported driver can
- add one or more such controls and/or attributes
- for specific uses.
- One out-of-tree driver uses controls here to allow
- for ERROR INJECTION operations to hardware
- injection registers
-
-The symlink points to the 'struct dev' that is registered for this edac_device.
-
-INSTANCES
----------
-
-One or more instance directories are present. For the 'test_device_edac' case:
-
- test-instance0
-
-
-In this directory there are two default counter attributes, which are totals of
-counter in deeper subdirectories.
-
- ce_count total of CE events of subdirectories
- ue_count total of UE events of subdirectories
-
-BLOCKS
-------
-
-At the lowest directory level is the 'block' directory. There can be 0, 1
-or more blocks specified in each instance.
-
- test-block0
-
-
-In this directory the default attributes are:
-
- ce_count which is counter of CE events for this 'block'
- of hardware being monitored
- ue_count which is counter of UE events for this 'block'
- of hardware being monitored
-
-
-The 'test_device_edac' device adds 4 attributes and 1 control:
-
- test-block-bits-0 for every POLL cycle this counter
- is incremented
- test-block-bits-1 every 10 cycles, this counter is bumped once,
- and test-block-bits-0 is set to 0
- test-block-bits-2 every 100 cycles, this counter is bumped once,
- and test-block-bits-1 is set to 0
- test-block-bits-3 every 1000 cycles, this counter is bumped once,
- and test-block-bits-2 is set to 0
-
-
- reset-counters writing ANY thing to this control will
- reset all the above counters.
-
-
-Use of the 'test_device_edac' driver should enable any others to create their own
-unique drivers for their hardware systems.
-
-The 'test_device_edac' sample driver is located at the
-bluesmoke.sourceforge.net project site for EDAC.
-
-
-NEHALEM USAGE OF EDAC APIs
---------------------------
-
-This chapter documents some EXPERIMENTAL mappings for EDAC API to handle
-Nehalem EDAC driver. They will likely be changed on future versions
-of the driver.
-
-Due to the way Nehalem exports Memory Controller data, some adjustments
-were done at i7core_edac driver. This chapter will cover those differences
-
-1) On Nehalem, there is one Memory Controller per Quick Patch Interconnect
- (QPI). At the driver, the term "socket" means one QPI. This is
- associated with a physical CPU socket.
-
- Each MC have 3 physical read channels, 3 physical write channels and
- 3 logic channels. The driver currently sees it as just 3 channels.
- Each channel can have up to 3 DIMMs.
-
- The minimum known unity is DIMMs. There are no information about csrows.
- As EDAC API maps the minimum unity is csrows, the driver sequentially
- maps channel/dimm into different csrows.
-
- For example, supposing the following layout:
- Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
- dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
- dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
- Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
- dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
- Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
- dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
- The driver will map it as:
- csrow0: channel 0, dimm0
- csrow1: channel 0, dimm1
- csrow2: channel 1, dimm0
- csrow3: channel 2, dimm0
-
-exports one
- DIMM per csrow.
-
- Each QPI is exported as a different memory controller.
-
-2) Nehalem MC has the ability to generate errors. The driver implements this
- functionality via some error injection nodes:
-
- For injecting a memory error, there are some sysfs nodes, under
- /sys/devices/system/edac/mc/mc?/:
-
- inject_addrmatch/*:
- Controls the error injection mask register. It is possible to specify
- several characteristics of the address to match an error code:
- dimm = the affected dimm. Numbers are relative to a channel;
- rank = the memory rank;
- channel = the channel that will generate an error;
- bank = the affected bank;
- page = the page address;
- column (or col) = the address column.
- each of the above values can be set to "any" to match any valid value.
-
- At driver init, all values are set to any.
-
- For example, to generate an error at rank 1 of dimm 2, for any channel,
- any bank, any page, any column:
- echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
- echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
-
- To return to the default behaviour of matching any, you can do:
- echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
- echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
-
- inject_eccmask:
- specifies what bits will have troubles,
-
- inject_section:
- specifies what ECC cache section will get the error:
- 3 for both
- 2 for the highest
- 1 for the lowest
-
- inject_type:
- specifies the type of error, being a combination of the following bits:
- bit 0 - repeat
- bit 1 - ecc
- bit 2 - parity
-
- inject_enable starts the error generation when something different
- than 0 is written.
-
- All inject vars can be read. root permission is needed for write.
-
- Datasheet states that the error will only be generated after a write on an
- address that matches inject_addrmatch. It seems, however, that reading will
- also produce an error.
-
- For example, the following code will generate an error for any write access
- at socket 0, on any DIMM/address on channel 2:
-
- echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
- echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
- echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
- echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
- echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
- dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
-
- For socket 1, it is needed to replace "mc0" by "mc1" at the above
- commands.
-
- The generated error message will look like:
-
- EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
-
-3) Nehalem specific Corrected Error memory counters
-
- Nehalem have some registers to count memory errors. The driver uses those
- registers to report Corrected Errors on devices with Registered Dimms.
-
- However, those counters don't work with Unregistered Dimms. As the chipset
- offers some counters that also work with UDIMMS (but with a worse level of
- granularity than the default ones), the driver exposes those registers for
- UDIMM memories.
-
- They can be read by looking at the contents of all_channel_counts/
-
- $ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
- /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
- 0
- /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
- 0
- /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
- 0
-
- What happens here is that errors on different csrows, but at the same
- dimm number will increment the same counter.
- So, in this memory mapping:
- csrow0: channel 0, dimm0
- csrow1: channel 0, dimm1
- csrow2: channel 1, dimm0
- csrow3: channel 2, dimm0
- The hardware will increment udimm0 for an error at the first dimm at either
- csrow0, csrow2 or csrow3;
- The hardware will increment udimm1 for an error at the second dimm at either
- csrow0, csrow2 or csrow3;
- The hardware will increment udimm2 for an error at the third dimm at either
- csrow0, csrow2 or csrow3;
-
-4) Standard error counters
-
- The standard error counters are generated when an mcelog error is received
- by the driver. Since, with udimm, this is counted by software, it is
- possible that some errors could be lost. With rdimm's, they display the
- contents of the registers
-
-AMD64_EDAC REFERENCE DOCUMENTS USED
------------------------------------
-amd64_edac module is based on the following documents
-(available from http://support.amd.com/en-us/search/tech-docs):
-
-1. Title: BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD
- Opteron Processors
- AMD publication #: 26094
- Revision: 3.26
- Link: http://support.amd.com/TechDocs/26094.PDF
-
-2. Title: BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh
- Processors
- AMD publication #: 32559
- Revision: 3.00
- Issue Date: May 2006
- Link: http://support.amd.com/TechDocs/32559.pdf
-
-3. Title: BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h
- Processors
- AMD publication #: 31116
- Revision: 3.00
- Issue Date: September 07, 2007
- Link: http://support.amd.com/TechDocs/31116.pdf
-
-4. Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
- Models 30h-3Fh Processors
- AMD publication #: 49125
- Revision: 3.06
- Issue Date: 2/12/2015 (latest release)
- Link: http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf
-
-5. Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
- Models 60h-6Fh Processors
- AMD publication #: 50742
- Revision: 3.01
- Issue Date: 7/23/2015 (latest release)
- Link: http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf
-
-6. Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h
- Models 00h-0Fh Processors
- AMD publication #: 48751
- Revision: 3.03
- Issue Date: 2/23/2015 (latest release)
- Link: http://support.amd.com/TechDocs/48751_16h_bkdg.pdf
-
-CREDITS:
-========
-
-Written by Doug Thompson <dougthompson@xmission.com>
-7 Dec 2005
-17 Jul 2007 Updated
-
-(c) Mauro Carvalho Chehab
-05 Aug 2009 Nehalem interface
-
-EDAC authors/maintainers:
-
- Doug Thompson, Dave Jiang, Dave Peterson et al,
- Mauro Carvalho Chehab
- Borislav Petkov
- original author: Thayne Harbaugh
diff --git a/Documentation/features/io/dma-api-debug/arch-support.txt b/Documentation/features/io/dma-api-debug/arch-support.txt
index 4f4a3443b114..ffa522a9bdfd 100644
--- a/Documentation/features/io/dma-api-debug/arch-support.txt
+++ b/Documentation/features/io/dma-api-debug/arch-support.txt
@@ -36,5 +36,5 @@
| um: | TODO |
| unicore32: | TODO |
| x86: | ok |
- | xtensa: | TODO |
+ | xtensa: | ok |
-----------------------
diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt
index a97e8e3f4ebb..83d2cf989ea3 100644
--- a/Documentation/features/io/dma-contiguous/arch-support.txt
+++ b/Documentation/features/io/dma-contiguous/arch-support.txt
@@ -36,5 +36,5 @@
| um: | TODO |
| unicore32: | TODO |
| x86: | ok |
- | xtensa: | TODO |
+ | xtensa: | ok |
-----------------------
diff --git a/Documentation/features/io/sg-chain/arch-support.txt b/Documentation/features/io/sg-chain/arch-support.txt
index b9b675539b9d..6ca98f9911bb 100644
--- a/Documentation/features/io/sg-chain/arch-support.txt
+++ b/Documentation/features/io/sg-chain/arch-support.txt
@@ -7,7 +7,7 @@
| arch |status|
-----------------------
| alpha: | TODO |
- | arc: | TODO |
+ | arc: | ok |
| arm: | ok |
| arm64: | ok |
| avr32: | TODO |
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index f66e748fc5e4..b7bd6c9009cc 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -87,8 +87,6 @@ jfs.txt
- info and mount options for the JFS filesystem.
locks.txt
- info on file locking implementations, flock() vs. fcntl(), etc.
-logfs.txt
- - info on the LogFS flash filesystem.
mandatory-locking.txt
- info on the Linux implementation of Sys V mandatory file locking.
ncpfs.txt
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 1b5f15653b1b..ace63cd7af8c 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -20,7 +20,7 @@ prototypes:
void (*d_iput)(struct dentry *, struct inode *);
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
struct vfsmount *(*d_automount)(struct path *path);
- int (*d_manage)(struct dentry *, bool);
+ int (*d_manage)(const struct path *, bool);
struct dentry *(*d_real)(struct dentry *, const struct inode *,
unsigned int);
@@ -556,7 +556,7 @@ till "end_pgoff". ->map_pages() is called with page table locked and must
not block. If it's not possible to reach a page without blocking,
filesystem should skip it. Filesystem should use do_set_pte() to setup
page table entry. Pointer to entry associated with the page is passed in
-"pte" field in fault_env structure. Pointers to entries for other offsets
+"pte" field in vm_fault structure. Pointers to entries for other offsets
should be calculated relative to "pte".
->page_mkwrite() is called when a previously read-only pte is
diff --git a/Documentation/filesystems/logfs.txt b/Documentation/filesystems/logfs.txt
deleted file mode 100644
index bca42c22a143..000000000000
--- a/Documentation/filesystems/logfs.txt
+++ /dev/null
@@ -1,241 +0,0 @@
-
-The LogFS Flash Filesystem
-==========================
-
-Specification
-=============
-
-Superblocks
------------
-
-Two superblocks exist at the beginning and end of the filesystem.
-Each superblock is 256 Bytes large, with another 3840 Bytes reserved
-for future purposes, making a total of 4096 Bytes.
-
-Superblock locations may differ for MTD and block devices. On MTD the
-first non-bad block contains a superblock in the first 4096 Bytes and
-the last non-bad block contains a superblock in the last 4096 Bytes.
-On block devices, the first 4096 Bytes of the device contain the first
-superblock and the last aligned 4096 Byte-block contains the second
-superblock.
-
-For the most part, the superblocks can be considered read-only. They
-are written only to correct errors detected within the superblocks,
-move the journal and change the filesystem parameters through tunefs.
-As a result, the superblock does not contain any fields that require
-constant updates, like the amount of free space, etc.
-
-Segments
---------
-
-The space in the device is split up into equal-sized segments.
-Segments are the primary write unit of LogFS. Within each segments,
-writes happen from front (low addresses) to back (high addresses. If
-only a partial segment has been written, the segment number, the
-current position within and optionally a write buffer are stored in
-the journal.
-
-Segments are erased as a whole. Therefore Garbage Collection may be
-required to completely free a segment before doing so.
-
-Journal
---------
-
-The journal contains all global information about the filesystem that
-is subject to frequent change. At mount time, it has to be scanned
-for the most recent commit entry, which contains a list of pointers to
-all currently valid entries.
-
-Object Store
-------------
-
-All space except for the superblocks and journal is part of the object
-store. Each segment contains a segment header and a number of
-objects, each consisting of the object header and the payload.
-Objects are either inodes, directory entries (dentries), file data
-blocks or indirect blocks.
-
-Levels
-------
-
-Garbage collection (GC) may fail if all data is written
-indiscriminately. One requirement of GC is that data is separated
-roughly according to the distance between the tree root and the data.
-Effectively that means all file data is on level 0, indirect blocks
-are on levels 1, 2, 3 4 or 5 for 1x, 2x, 3x, 4x or 5x indirect blocks,
-respectively. Inode file data is on level 6 for the inodes and 7-11
-for indirect blocks.
-
-Each segment contains objects of a single level only. As a result,
-each level requires its own separate segment to be open for writing.
-
-Inode File
-----------
-
-All inodes are stored in a special file, the inode file. Single
-exception is the inode file's inode (master inode) which for obvious
-reasons is stored in the journal instead. Instead of data blocks, the
-leaf nodes of the inode files are inodes.
-
-Aliases
--------
-
-Writes in LogFS are done by means of a wandering tree. A naïve
-implementation would require that for each write or a block, all
-parent blocks are written as well, since the block pointers have
-changed. Such an implementation would not be very efficient.
-
-In LogFS, the block pointer changes are cached in the journal by means
-of alias entries. Each alias consists of its logical address - inode
-number, block index, level and child number (index into block) - and
-the changed data. Any 8-byte word can be changes in this manner.
-
-Currently aliases are used for block pointers, file size, file used
-bytes and the height of an inodes indirect tree.
-
-Segment Aliases
----------------
-
-Related to regular aliases, these are used to handle bad blocks.
-Initially, bad blocks are handled by moving the affected segment
-content to a spare segment and noting this move in the journal with a
-segment alias, a simple (to, from) tupel. GC will later empty this
-segment and the alias can be removed again. This is used on MTD only.
-
-Vim
----
-
-By cleverly predicting the life time of data, it is possible to
-separate long-living data from short-living data and thereby reduce
-the GC overhead later. Each type of distinc life expectency (vim) can
-have a separate segment open for writing. Each (level, vim) tupel can
-be open just once. If an open segment with unknown vim is encountered
-at mount time, it is closed and ignored henceforth.
-
-Indirect Tree
--------------
-
-Inodes in LogFS are similar to FFS-style filesystems with direct and
-indirect block pointers. One difference is that LogFS uses a single
-indirect pointer that can be either a 1x, 2x, etc. indirect pointer.
-A height field in the inode defines the height of the indirect tree
-and thereby the indirection of the pointer.
-
-Another difference is the addressing of indirect blocks. In LogFS,
-the first 16 pointers in the first indirect block are left empty,
-corresponding to the 16 direct pointers in the inode. In ext2 (maybe
-others as well) the first pointer in the first indirect block
-corresponds to logical block 12, skipping the 12 direct pointers.
-So where ext2 is using arithmetic to better utilize space, LogFS keeps
-arithmetic simple and uses compression to save space.
-
-Compression
------------
-
-Both file data and metadata can be compressed. Compression for file
-data can be enabled with chattr +c and disabled with chattr -c. Doing
-so has no effect on existing data, but new data will be stored
-accordingly. New inodes will inherit the compression flag of the
-parent directory.
-
-Metadata is always compressed. However, the space accounting ignores
-this and charges for the uncompressed size. Failing to do so could
-result in GC failures when, after moving some data, indirect blocks
-compress worse than previously. Even on a 100% full medium, GC may
-not consume any extra space, so the compression gains are lost space
-to the user.
-
-However, they are not lost space to the filesystem internals. By
-cheating the user for those bytes, the filesystem gained some slack
-space and GC will run less often and faster.
-
-Garbage Collection and Wear Leveling
-------------------------------------
-
-Garbage collection is invoked whenever the number of free segments
-falls below a threshold. The best (known) candidate is picked based
-on the least amount of valid data contained in the segment. All
-remaining valid data is copied elsewhere, thereby invalidating it.
-
-The GC code also checks for aliases and writes then back if their
-number gets too large.
-
-Wear leveling is done by occasionally picking a suboptimal segment for
-garbage collection. If a stale segments erase count is significantly
-lower than the active segments' erase counts, it will be picked. Wear
-leveling is rate limited, so it will never monopolize the device for
-more than one segment worth at a time.
-
-Values for "occasionally", "significantly lower" are compile time
-constants.
-
-Hashed directories
-------------------
-
-To satisfy efficient lookup(), directory entries are hashed and
-located based on the hash. In order to both support large directories
-and not be overly inefficient for small directories, several hash
-tables of increasing size are used. For each table, the hash value
-modulo the table size gives the table index.
-
-Tables sizes are chosen to limit the number of indirect blocks with a
-fully populated table to 0, 1, 2 or 3 respectively. So the first
-table contains 16 entries, the second 512-16, etc.
-
-The last table is special in several ways. First its size depends on
-the effective 32bit limit on telldir/seekdir cookies. Since logfs
-uses the upper half of the address space for indirect blocks, the size
-is limited to 2^31. Secondly the table contains hash buckets with 16
-entries each.
-
-Using single-entry buckets would result in birthday "attacks". At
-just 2^16 used entries, hash collisions would be likely (P >= 0.5).
-My math skills are insufficient to do the combinatorics for the 17x
-collisions necessary to overflow a bucket, but testing showed that in
-10,000 runs the lowest directory fill before a bucket overflow was
-188,057,130 entries with an average of 315,149,915 entries. So for
-directory sizes of up to a million, bucket overflows should be
-virtually impossible under normal circumstances.
-
-With carefully chosen filenames, it is obviously possible to cause an
-overflow with just 21 entries (4 higher tables + 16 entries + 1). So
-there may be a security concern if a malicious user has write access
-to a directory.
-
-Open For Discussion
-===================
-
-Device Address Space
---------------------
-
-A device address space is used for caching. Both block devices and
-MTD provide functions to either read a single page or write a segment.
-Partial segments may be written for data integrity, but where possible
-complete segments are written for performance on simple block device
-flash media.
-
-Meta Inodes
------------
-
-Inodes are stored in the inode file, which is just a regular file for
-most purposes. At umount time, however, the inode file needs to
-remain open until all dirty inodes are written. So
-generic_shutdown_super() may not close this inode, but shouldn't
-complain about remaining inodes due to the inode file either. Same
-goes for mapping inode of the device address space.
-
-Currently logfs uses a hack that essentially copies part of fs/inode.c
-code over. A general solution would be preferred.
-
-Indirect block mapping
-----------------------
-
-With compression, the block device (or mapping inode) cannot be used
-to cache indirect blocks. Some other place is required. Currently
-logfs uses the top half of each inode's address space. The low 8TB
-(on 32bit) are filled with file data, the high 8TB are used for
-indirect blocks.
-
-One problem is that 16TB files created on 64bit systems actually have
-data in the top 8TB. But files >16TB would cause problems anyway, so
-only the limit has changed.
diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt
index bcbf9710e4af..634d03e20c2d 100644
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -66,7 +66,7 @@ At mount time, the two directories given as mount options "lowerdir" and
"upperdir" are combined into a merged directory:
mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
-workdir=/work /merged
+ workdir=/work /merged
The "workdir" needs to be an empty directory on the same filesystem
as upperdir.
@@ -118,6 +118,7 @@ programs.
seek offsets are assigned sequentially when the directories are read.
Thus if
+
- read part of a directory
- remember an offset, and close the directory
- re-open the directory some time later
@@ -130,6 +131,23 @@ directory.
Readdir on directories that are not merged is simply handled by the
underlying directory (upper or lower).
+renaming directories
+--------------------
+
+When renaming a directory that is on the lower layer or merged (i.e. the
+directory was not created on the upper layer to start with) overlayfs can
+handle it in two different ways:
+
+1. return EXDEV error: this error is returned by rename(2) when trying to
+ move a file or directory across filesystem boundaries. Hence
+ applications are usually prepared to hande this error (mv(1) for example
+ recursively copies the directory tree). This is the default behavior.
+
+2. If the "redirect_dir" feature is enabled, then the directory will be
+ copied up (but not the contents). Then the "trusted.overlay.redirect"
+ extended attribute is set to the path of the original location from the
+ root of the overlay. Finally the directory is moved to the new
+ location.
Non-directories
---------------
@@ -185,13 +203,13 @@ filesystem, so both st_dev and st_ino of the file may change.
Any open files referring to this inode will access the old data.
-Any file locks (and leases) obtained before copy_up will not apply
-to the copied up file.
-
If a file with multiple hard links is copied up, then this will
"break" the link. Changes will not be propagated to other names
referring to the same inode.
+Unless "redirect_dir" feature is enabled, rename(2) on a lower or merged
+directory will fail with EXDEV.
+
Changes to underlying filesystems
---------------------------------
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index bdd025ceb763..95280079c0b3 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -596,3 +596,7 @@ in your dentry operations instead.
[mandatory]
->rename() has an added flags argument. Any flags not handled by the
filesystem should result in EINVAL being returned.
+--
+[recommended]
+ ->readlink is optional for symlinks. Don't set, unless filesystem needs
+ to fake something for readlink(2).
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
index 74eaac26f8b8..6ea1ceda6f52 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -17,6 +17,7 @@ that support it. For example, a given bus might look like this:
| |-- resource0
| |-- resource1
| |-- resource2
+ | |-- revision
| |-- rom
| |-- subsystem_device
| |-- subsystem_vendor
@@ -41,6 +42,7 @@ files, each with their own function.
resource PCI resource host addresses (ascii, ro)
resource0..N PCI resource N, if present (binary, mmap, rw[1])
resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap)
+ revision PCI revision (ascii, ro)
rom PCI ROM resource, if present (binary, ro)
subsystem_device PCI subsystem device (ascii, ro)
subsystem_vendor PCI subsystem vendor (ascii, ro)
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index b5039a00caaf..b968084eeac1 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -451,9 +451,6 @@ otherwise noted.
exist; this is checked by the VFS. Unlike plain rename,
source and target may be of different type.
- readlink: called by the readlink(2) system call. Only required if
- you want to support reading symbolic links
-
get_link: called by the VFS to follow a symbolic link to the
inode it points to. Only required if you want to support
symbolic links. This method returns the symlink body
@@ -468,6 +465,12 @@ otherwise noted.
argument. If request can't be handled without leaving RCU mode,
have it return ERR_PTR(-ECHILD).
+ readlink: this is now just an override for use by readlink(2) for the
+ cases when ->get_link uses nd_jump_link() or object is not in
+ fact a symlink. Normally filesystems should only implement
+ ->get_link for symlinks and readlink(2) will automatically use
+ that.
+
permission: called by the VFS to check for access rights on a POSIX-like
filesystem.
@@ -948,7 +951,7 @@ struct dentry_operations {
void (*d_iput)(struct dentry *, struct inode *);
char *(*d_dname)(struct dentry *, char *, int);
struct vfsmount *(*d_automount)(struct path *);
- int (*d_manage)(struct dentry *, bool);
+ int (*d_manage)(const struct path *, bool);
struct dentry *(*d_real)(struct dentry *, const struct inode *,
unsigned int);
};
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index c2d44e6e117b..3b9b5c149f32 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -51,13 +51,6 @@ default behaviour.
CRC enabled filesystems always use the attr2 format, and so
will reject the noattr2 mount option if it is set.
- barrier (*)
- nobarrier
- Enables/disables the use of block layer write barriers for
- writes into the journal and for data integrity operations.
- This allows for drive level write caching to be enabled, for
- devices that support write barriers.
-
discard
nodiscard (*)
Enable/disable the issuing of commands to let the block
@@ -228,7 +221,10 @@ default behaviour.
Deprecated Mount Options
========================
-None at present.
+ Name Removal Schedule
+ ---- ----------------
+ barrier no earlier than v4.15
+ nobarrier no earlier than v4.15
Removed Mount Options
diff --git a/Documentation/i2c/busses/i2c-mlxcpld b/Documentation/i2c/busses/i2c-mlxcpld
new file mode 100644
index 000000000000..4e46c440b38d
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-mlxcpld
@@ -0,0 +1,47 @@
+Driver i2c-mlxcpld
+
+Author: Michael Shych <michaelsh@mellanox.com>
+
+This is the Mellanox I2C controller logic, implemented in Lattice CPLD
+device.
+Device supports:
+ - Master mode.
+ - One physical bus.
+ - Polling mode.
+
+This controller is equipped within the next Mellanox systems:
+"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
+"msn2740", "msn2100".
+
+The next transaction types are supported:
+ - Receive Byte/Block.
+ - Send Byte/Block.
+ - Read Byte/Block.
+ - Write Byte/Block.
+
+Registers:
+CTRL 0x1 - control reg.
+ Resets all the registers.
+HALF_CYC 0x4 - cycle reg.
+ Configure the width of I2C SCL half clock cycle (in 4 LPC_CLK
+ units).
+I2C_HOLD 0x5 - hold reg.
+ OE (output enable) is delayed by value set to this register
+ (in LPC_CLK units)
+CMD 0x6 - command reg.
+ Bit 0, 0 = write, 1 = read.
+ Bits [7:1] - the 7bit Address of the I2C device.
+ It should be written last as it triggers an I2C transaction.
+NUM_DATA 0x7 - data size reg.
+ Number of data bytes to write in read transaction
+NUM_ADDR 0x8 - address reg.
+ Number of address bytes to write in read transaction.
+STATUS 0x9 - status reg.
+ Bit 0 - transaction is completed.
+ Bit 4 - ACK/NACK.
+DATAx 0xa - 0x54 - 68 bytes data buffer regs.
+ For write transaction address is specified in four first bytes
+ (DATA1 - DATA4), data starting from DATA4.
+ For read transactions address is sent in a separate transaction and
+ specified in the four first bytes (DATA0 - DATA3). Data is read
+ starting from DATA0.
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index 14d4ec1be245..092d474f5843 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -200,10 +200,14 @@ alerting device's address.
[S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
This is implemented in the following way in the Linux kernel:
-* I2C bus drivers which support SMBus Host Notify should call
- i2c_setup_smbus_host_notify() to setup SMBus Host Notify support.
-* I2C drivers for devices which can trigger SMBus Host Notify should implement
- the optional alert() callback.
+* I2C bus drivers which support SMBus Host Notify should report
+ I2C_FUNC_SMBUS_HOST_NOTIFY.
+* I2C bus drivers trigger SMBus Host Notify by a call to
+ i2c_handle_smbus_host_notify().
+* I2C drivers for devices which can trigger SMBus Host Notify will have
+ client->irq assigned to a Host Notify IRQ if noone else specified an other.
+
+There is currently no way to retrieve the data parameter from the client.
Packet Error Checking (PEC)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 2bd8fdc9207c..cb5d77699c60 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -58,6 +58,7 @@ needed).
gpu/index
security/index
sound/index
+ crypto/index
Korean translations
-------------------
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 72a150d8f3df..ba2e7d254842 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -540,6 +540,7 @@ Events that are propagated by the driver to userspace:
0x6022 ALARM: a sensor is extremely hot
0x6030 System thermal table changed
0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED)
+0x60C0 X1 Yoga 2016, Tablet mode status changed
Battery nearly empty alarms are a last resort attempt to get the
operating system to hibernate or shutdown cleanly (0x2313), or shutdown
diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt
index 6c43f6ebee8d..f5967316deb9 100644
--- a/Documentation/livepatch/livepatch.txt
+++ b/Documentation/livepatch/livepatch.txt
@@ -87,7 +87,7 @@ The theory about how to apply functions a safe way is rather complex.
The aim is to define a so-called consistency model. It attempts to define
conditions when the new implementation could be used so that the system
stays consistent. The theory is not yet finished. See the discussion at
-http://thread.gmane.org/gmane.linux.kernel/1823033/focus=1828189
+https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
The current consistency model is very simple. It guarantees that either
the old or the new function is called. But various functions get redirected
diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index 4d8e2ff378c4..32663602ff25 100644
--- a/Documentation/media/Makefile
+++ b/Documentation/media/Makefile
@@ -88,7 +88,7 @@ $(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} $(SRC_DIR)/videodev2.
$(BUILDDIR)/media.h.rst: ${UAPI}/media.h ${PARSER} $(SRC_DIR)/media.h.rst.exceptions
@$($(quiet)gen_rst)
-$(BUILDDIR)/cec.h.rst: ${KAPI}/cec.h ${PARSER} $(SRC_DIR)/cec.h.rst.exceptions
+$(BUILDDIR)/cec.h.rst: ${UAPI}/cec.h ${PARSER} $(SRC_DIR)/cec.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/lirc.h.rst: ${UAPI}/lirc.h ${PARSER} $(SRC_DIR)/lirc.h.rst.exceptions
diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst
index 88c33b53ec13..81c6d8e93774 100644
--- a/Documentation/media/kapi/cec-core.rst
+++ b/Documentation/media/kapi/cec-core.rst
@@ -37,9 +37,8 @@ The struct cec_adapter represents the CEC adapter hardware. It is created by
calling cec_allocate_adapter() and deleted by calling cec_delete_adapter():
.. c:function::
- struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
- void *priv, const char *name, u32 caps, u8 available_las,
- struct device *parent);
+ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, void *priv,
+ const char *name, u32 caps, u8 available_las);
.. c:function::
void cec_delete_adapter(struct cec_adapter *adap);
@@ -66,20 +65,19 @@ available_las:
the number of simultaneous logical addresses that this
adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS.
-parent:
- the parent device.
-
To register the /dev/cecX device node and the remote control device (if
CEC_CAP_RC is set) you call:
.. c:function::
- int cec_register_adapter(struct cec_adapter \*adap);
+ int cec_register_adapter(struct cec_adapter *adap, struct device *parent);
+
+where parent is the parent device.
To unregister the devices call:
.. c:function::
- void cec_unregister_adapter(struct cec_adapter \*adap);
+ void cec_unregister_adapter(struct cec_adapter *adap);
Note: if cec_register_adapter() fails, then call cec_delete_adapter() to
clean up. But if cec_register_adapter() succeeded, then only call
@@ -106,13 +104,13 @@ your driver:
int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
u32 signal_free_time, struct cec_msg *msg);
- void (\*adap_log_status)(struct cec_adapter *adap);
+ void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
/* High-level callbacks */
...
};
-The three low-level ops deal with various aspects of controlling the CEC adapter
+The five low-level ops deal with various aspects of controlling the CEC adapter
hardware:
@@ -238,6 +236,18 @@ When a CEC message was received:
Speaks for itself.
+Implementing the interrupt handler
+----------------------------------
+
+Typically the CEC hardware provides interrupts that signal when a transmit
+finished and whether it was successful or not, and it provides and interrupt
+when a CEC message was received.
+
+The CEC driver should always process the transmit interrupts first before
+handling the receive interrupt. The framework expects to see the cec_transmit_done
+call before the cec_received_msg call, otherwise it can get confused if the
+received message was in reply to the transmitted message.
+
Implementing the High-Level CEC Adapter
---------------------------------------
@@ -247,11 +257,11 @@ CEC protocol driven. The following high-level callbacks are available:
.. code-block:: none
struct cec_adap_ops {
- /\* Low-level callbacks \*/
+ /* Low-level callbacks */
...
- /\* High-level CEC message callback \*/
- int (\*received)(struct cec_adapter \*adap, struct cec_msg \*msg);
+ /* High-level CEC message callback */
+ int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
};
The received() callback allows the driver to optionally handle a newly
@@ -263,7 +273,7 @@ received CEC message
If the driver wants to process a CEC message, then it can implement this
callback. If it doesn't want to handle this message, then it should return
-ENOMSG, otherwise the CEC framework assumes it processed this message and
-it will not no anything with it.
+it will not do anything with it.
CEC framework functions
diff --git a/Documentation/media/kapi/csi2.rst b/Documentation/media/kapi/csi2.rst
new file mode 100644
index 000000000000..2004db00b12b
--- /dev/null
+++ b/Documentation/media/kapi/csi2.rst
@@ -0,0 +1,61 @@
+MIPI CSI-2
+==========
+
+CSI-2 is a data bus intended for transferring images from cameras to
+the host SoC. It is defined by the `MIPI alliance`_.
+
+.. _`MIPI alliance`: http://www.mipi.org/
+
+Transmitter drivers
+-------------------
+
+CSI-2 transmitter, such as a sensor or a TV tuner, drivers need to
+provide the CSI-2 receiver with information on the CSI-2 bus
+configuration. These include the V4L2_CID_LINK_FREQ and
+V4L2_CID_PIXEL_RATE controls and
+(:c:type:`v4l2_subdev_video_ops`->s_stream() callback). These
+interface elements must be present on the sub-device represents the
+CSI-2 transmitter.
+
+The V4L2_CID_LINK_FREQ control is used to tell the receiver driver the
+frequency (and not the symbol rate) of the link. The
+V4L2_CID_PIXEL_RATE is may be used by the receiver to obtain the pixel
+rate the transmitter uses. The
+:c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an
+ability to start and stop the stream.
+
+The value of the V4L2_CID_PIXEL_RATE is calculated as follows::
+
+ pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample
+
+where
+
+.. list-table:: variables in pixel rate calculation
+ :header-rows: 1
+
+ * - variable or constant
+ - description
+ * - link_freq
+ - The value of the V4L2_CID_LINK_FREQ integer64 menu item.
+ * - nr_of_lanes
+ - Number of data lanes used on the CSI-2 link. This can
+ be obtained from the OF endpoint configuration.
+ * - 2
+ - Two bits are transferred per clock cycle per lane.
+ * - bits_per_sample
+ - Number of bits per sample.
+
+The transmitter drivers must configure the CSI-2 transmitter to *LP-11
+mode* whenever the transmitter is powered on but not active. Some
+transmitters do this automatically but some have to be explicitly
+programmed to do so.
+
+Receiver drivers
+----------------
+
+Before the receiver driver may enable the CSI-2 transmitter by using
+the :c:type:`v4l2_subdev_video_ops`->s_stream(), it must have powered
+the transmitter up by using the
+:c:type:`v4l2_subdev_core_ops`->s_power() callback. This may take
+place either indirectly by using :c:func:`v4l2_pipeline_pm_use` or
+directly.
diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst
index a3c4642eabfc..ff86bf0abeae 100644
--- a/Documentation/media/kapi/dtv-core.rst
+++ b/Documentation/media/kapi/dtv-core.rst
@@ -8,14 +8,6 @@ Digital TV Common functions
.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
-
-
-.. kernel-doc:: drivers/media/dvb-core/dvb_math.h
- :export: drivers/media/dvb-core/dvb_math.c
-
-.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
- :export: drivers/media/dvb-core/dvbdev.c
-
Digital TV Ring buffer
----------------------
diff --git a/Documentation/media/media_kapi.rst b/Documentation/media/media_kapi.rst
index f282ca270369..bc0638956a43 100644
--- a/Documentation/media/media_kapi.rst
+++ b/Documentation/media/media_kapi.rst
@@ -33,3 +33,4 @@ For more details see the file COPYING in the source distribution of Linux.
kapi/rc-core
kapi/mc-core
kapi/cec-core
+ kapi/csi2
diff --git a/Documentation/media/typical_media_device.svg b/Documentation/media/typical_media_device.svg
index f0c82f72c4b6..0c8abd69f39a 100644
--- a/Documentation/media/typical_media_device.svg
+++ b/Documentation/media/typical_media_device.svg
@@ -1,28 +1,2948 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg stroke-linejoin="round" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://www.w3.org/2000/svg" clip-path="url(#a)" xml:space="preserve" fill-rule="evenodd" height="178.78mm" viewBox="0 0 24285.662 17877.829" width="251.99mm" version="1.2" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" preserveAspectRatio="xMidYMid" stroke-width="28.222"><defs><clipPath id="a" clipPathUnits="userSpaceOnUse"><rect y="0" x="0" width="28000" height="21000"/></clipPath></defs><g transform="matrix(1.004 0 0 1 -2185.6 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#fcf" d="m12231 4800c-516 0-1031 515-1031 1031v4124c0 516 515 1032 1031 1032h8538c516 0 1032-516 1032-1032v-4124c0-516-516-1031-1032-1031h-8538z"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#ffc" d="m3595 15607c-293 0-585 292-585 585v2340c0 293 292 586 585 586h3275c293 0 586-293 586-586v-2340c0-293-293-585-586-585h-3275z"/></g><g transform="translate(-2197.3 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#e6e6e6" d="m2663 2186c-461 0-922 461-922 922v11169c0 461 461 923 922 923h3692c461 0 922-462 922-923v-11169c0-461-461-922-922-922h-3692z"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#ff8080" d="m4461 8602h-2260v-1086h4520v1086h-2260z"/><path fill="none" d="m4461 8602h-2260v-1086h4520v1086h-2260z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="8275" x="2579" class="TextPosition"><tspan fill="#000000">Audio decoder</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#ff8080" d="m4461 11772h-2260v-1270h4520v1270h-2260z"/><path fill="none" d="m4461 11772h-2260v-1270h4520v1270h-2260z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="11353" x="2617" class="TextPosition"><tspan fill="#000000">Video decoder</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#ff8080" d="m4453 10217h-2269v-1224h4537v1224h-2268z"/><path fill="none" d="m4453 10217h-2269v-1224h4537v1224h-2268z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="9821" x="2571" class="TextPosition"><tspan fill="#000000">Audio encoder</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2468.2)" class="com.sun.star.drawing.RectangleShape"><path fill="#cfc" d="m15711 12832h-3810v-1281h7620v1281h-3810z"/><path fill="none" d="m15711 12832h-3810v-1281h7620v1281h-3810z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="12407" x="12377" class="TextPosition"><tspan fill="#000000">Button Key/IR input logic</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2411.8)" class="com.sun.star.drawing.RectangleShape"><path fill="#cfe7f5" d="m14169 14572h-2268v-1412h4536v1412h-2268z"/><path fill="none" d="m14169 14572h-2268v-1412h4536v1412h-2268z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="14082" x="12882" class="TextPosition"><tspan fill="#000000">EEPROM</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#fc9" d="m5140 17662h-1563v-1715h3126v1715h-1563z"/><path fill="none" d="m5140 17662h-1563v-1715h3126v1715h-1563z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="17020" x="4276" class="TextPosition"><tspan fill="#000000">Sensor</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m6719 8030 385-353v176h1167v-176l386 353-386 354v-177h-1167v177l-385-354z"/><path fill="none" d="m6719 8030 385-353v176h1167v-176l386 353-386 354v-177h-1167v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m6719 9612 385-353v176h1167v-176l386 353-386 354v-177h-1167v177l-385-354z"/><path fill="none" d="m6719 9612 385-353v176h1167v-176l386 353-386 354v-177h-1167v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m6721 11100 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z"/><path fill="none" d="m6721 11100 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2411.8)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9962 13854 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z"/><path fill="none" d="m9962 13854 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2468.2)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9962 12163 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z"/><path fill="none" d="m9962 12163 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9962 17158 670-353v176h2028v-176l671 353-671 354v-177h-2028v177l-670-354z"/><path fill="none" d="m9962 17158 670-353v176h2028v-176l671 353-671 354v-177h-2028v177l-670-354z" stroke="#3465af"/></g><g transform="matrix(0 .83339 -1.0005 0 30268 -5276.3)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m23229 12779 1009-978 1009 978h-505v2959h505l-1009 979-1009-979h504v-2959h-504z"/><path fill="none" d="m23229 12779 1009-978 1009 978h-505v2959h505l-1009 979-1009-979h504v-2959h-504z" stroke="#3465af"/></g><g transform="translate(-9973.6 -666.6)" class="com.sun.star.drawing.TextShape"><text class="TextShape"><tspan font-size="706px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="15832" x="24341" class="TextPosition" transform="matrix(0,-1,1,0,8509,40173)"><tspan fill="#000000">System Bus</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#cff" d="m13151 9262h-1250v-875h2499v875h-1249z"/><path fill="none" d="m13151 9262h-1250v-875h2499v875h-1249z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="9040" x="12215" class="TextPosition"><tspan fill="#000000">Demux</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9996 8765 373-357v178h1130v-178l374 357-374 358v-179h-1130v179l-373-358z"/><path fill="none" d="m9996 8765 373-357v178h1130v-178l374 357-374 358v-179h-1130v179l-373-358z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9996 7378 373-358v179h1130v-179l374 358-374 358v-179h-1130v179l-373-358z"/><path fill="none" d="m9996 7378 373-358v179h1130v-179l374 358-374 358v-179h-1130v179l-373-358z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#cff" d="m16322 7992h-4421v-1270h8841v1270h-4420z"/><path fill="none" d="m16322 7992h-4421v-1270h8841v1270h-4420z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="7573" x="12786" class="TextPosition"><tspan fill="#000000">Conditional Access Module</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#ff8080" d="m4445 13287h-2269v-1224h4537v1224h-2268z"/><path fill="none" d="m4445 13287h-2269v-1224h4537v1224h-2268z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="12891" x="2601" class="TextPosition"><tspan fill="#000000">Video encoder</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m6721 12634 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z"/><path fill="none" d="m6721 12634 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m20791 7545 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z"/><path fill="none" d="m20791 7545 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2028 -2186)" class="com.sun.star.drawing.TextShape"><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="14478" x="1990" class="TextPosition"><tspan fill="#000000">Radio / Analog TV</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.TextShape"><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="700" class="TextParagraph"><tspan y="10724" x="14956" class="TextPosition"><tspan fill="#000000">Digital TV</tspan></tspan></tspan></text>
-</g><g transform="translate(-8970.5 -1395.8)" class="com.sun.star.drawing.TextShape"><text class="TextShape"><tspan font-size="494px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="19167" x="14724" class="TextPosition"><tspan fill="#000000">PS.: picture is not complete: other blocks may be present</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.TextShape"><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="18561" x="4199" class="TextPosition"><tspan fill="#000000">Webcam</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2468.2)" class="com.sun.star.drawing.RectangleShape"><path fill="#f90" d="m14552 16372h-2650v-1412h5299v1412h-2649z"/><path fill="none" d="m14552 16372h-2650v-1412h5299v1412h-2649z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="15882" x="12265" class="TextPosition"><tspan fill="#000000">Processing blocks</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2468.2)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9962 15654 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z"/><path fill="none" d="m9962 15654 385-353v176h1166v-176l386 353-386 354v-177h-1166v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m6702 16954 397-353v176h1201v-176l398 353-398 354v-177h-1201v177l-397-354z"/><path fill="none" d="m6702 16954 397-353v176h1201v-176l398 353-398 354v-177h-1201v177l-397-354z" stroke="#3465af"/></g><g transform="translate(-2479.5 -2186)" class="com.sun.star.drawing.TextShape"><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="8792" x="22850" class="TextPosition"><tspan fill="#000000">Smartcard</tspan></tspan></tspan></text>
-</g><g transform="matrix(1.0048 0 0 1 -2207.4 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#fcf" d="m2766 2600c-333 0-666 333-666 666v2668c0 333 333 666 666 666h18368c333 0 667-333 667-666v-2668c0-333-334-666-667-666h-18368z"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#ff8080" d="m5121 5155h-1614v-1816h3227v1816h-1613z"/><path fill="none" d="m5121 5155h-1614v-1816h3227v1816h-1613z" stroke="#3465af"/><text font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextShape"><tspan class="TextParagraph"><tspan y="4111" x="4374" class="TextPosition"><tspan fill="#000000">Tuner</tspan></tspan></tspan><tspan class="TextParagraph"><tspan y="4814" x="4151" class="TextPosition"><tspan fill="#000000">FM/TV</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#ff8080" d="m2902 3702c0 111 40 202 88 202h530c48 0 89-91 89-202 0-110-41-202-89-202h-530c-48 0-88 92-88 202z"/><path fill="none" d="m2902 3702c0 111 40 202 88 202h530c48 0 89-91 89-202 0-110-41-202-89-202h-530c-48 0-88 92-88 202z" stroke="#3465af"/><path fill="#ffb3b3" d="m2902 3702c0 111 40 202 88 202s88-91 88-202c0-110-40-202-88-202s-88 92-88 202z"/><path fill="none" d="m2902 3702c0 111 40 202 88 202s88-91 88-202c0-110-40-202-88-202s-88 92-88 202z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#ff8080" d="m2903 4267c0 110 40 202 88 202h530c48 0 89-92 89-202s-41-203-89-203h-530c-48 0-88 93-88 203z"/><path fill="none" d="m2903 4267c0 110 40 202 88 202h530c48 0 89-92 89-202s-41-203-89-203h-530c-48 0-88 93-88 203z" stroke="#3465af"/><path fill="#ffb3b3" d="m2903 4267c0 110 40 202 88 202s88-92 88-202-40-203-88-203-88 93-88 203z"/><path fill="none" d="m2903 4267c0 110 40 202 88 202s88-92 88-202-40-203-88-203-88 93-88 203z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m6719 4196 385-353v176h1167v-176l386 353-386 354v-177h-1167v177l-385-354z"/><path fill="none" d="m6719 4196 385-353v176h1167v-176l386 353-386 354v-177h-1167v177l-385-354z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9979 4150 402-368v184h1217v-184l403 368-403 369v-185h-1217v185l-402-369z"/><path fill="none" d="m9979 4150 402-368v184h1217v-184l403 368-403 369v-185h-1217v185l-402-369z" stroke="#3465af"/></g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.RectangleShape"><path fill="#cff" d="m16500 6189h-4500v-1389h9e3v1389h-4500z"/><path fill="none" d="m16500 6189h-4500v-1389h9e3v1389h-4500z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="5710" x="12051" class="TextPosition"><tspan fill="#000000">Satellite Equipment Control (SEC)</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#cff" d="m13400 4600h-1400v-1e3h2800v1e3h-1400z"/><path fill="none" d="m13400 4600h-1400v-1e3h2800v1e3h-1400z" stroke="#3465af"/><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="4316" x="12465" class="TextPosition"><tspan fill="#000000">Demod</tspan></tspan></tspan></text>
-</g><g transform="translate(-2140.9 -2186)" class="com.sun.star.drawing.CustomShape"><path fill="#729fcf" d="m9979 5451 402-368v184h1217v-184l403 368-403 369v-185h-1217v185l-402-369z"/><path fill="none" d="m9979 5451 402-368v184h1217v-184l403 368-403 369v-185h-1217v185l-402-369z" stroke="#3465af"/></g><path fill="#ff9" d="m7855.1 9099v7302h-1270v-14605h1270v7303z"/><path fill="none" d="m7855.1 9099v7302h-1270v-14605h1270v7303z" stroke="#3465af"/><text y="-6640.4663" x="-20770.572" transform="rotate(-90)" class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="7409.5396" x="-11193.634" class="TextPosition" transform="matrix(0,-1,1,0,-4473,23627)"><tspan fill="#000000">I2C Bus (control bus)</tspan></tspan></tspan></text>
-<g transform="translate(-2197.3 -2186)" class="com.sun.star.drawing.TextShape"><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="3278" x="9391" class="TextPosition"><tspan fill="#000000">Digital TV Frontend</tspan></tspan></tspan></text>
-</g><g transform="matrix(1.015 0 0 .99994 -2233.3 -2185.7)" class="com.sun.star.drawing.CustomShape"><g stroke="#3465af" fill="none"><path d="m3e3 2800c-18 0-35 1-53 3"/><path d="m2915 2808c-17 3-35 7-52 12"/><path d="m2832 2830c-16 6-33 12-49 20"/><path d="m2754 2864c-15 8-31 17-46 27"/><path d="m2681 2909c-14 10-28 21-42 32"/><path d="m2614 2962c-13 12-26 24-38 37"/><path d="m2554 3023c-11 13-22 27-33 41"/><path d="m2502 3091c-10 14-19 29-28 45"/><path d="m2459 3164c-8 16-15 32-22 49"/><path d="m2426 3243c-5 17-10 34-14 51"/><path d="m2406 3326c-3 18-5 35-6 53"/><path d="m2400 3411v53"/><path d="m2400 3497v53"/><path d="m2400 3582v53"/><path d="m2400 3668v53"/><path d="m2400 3753v53"/><path d="m2400 3839v53"/><path d="m2400 3924v53"/><path d="m2400 4009v54"/><path d="m2400 4095v53"/><path d="m2400 4180v53"/><path d="m2400 4266v53"/><path d="m2400 4351v53"/><path d="m2400 4437v53"/><path d="m2400 4522v53"/><path d="m2400 4607v54"/><path d="m2400 4693v53"/><path d="m2400 4778v53"/><path d="m2400 4864v53"/><path d="m2400 4949v53"/><path d="m2400 5035v53"/><path d="m2400 5120v53"/><path d="m2400 5205v54"/><path d="m2400 5291v53"/><path d="m2400 5376v53"/><path d="m2400 5462v53"/><path d="m2400 5547v53"/><path d="m2400 5633v53"/><path d="m2400 5718v53"/><path d="m2400 5803c0 18 1 36 3 53"/><path d="m2408 5888c4 18 8 35 13 52"/><path d="m2431 5971c6 16 13 33 20 49"/><path d="m2466 6049c8 15 17 31 27 46"/><path d="m2511 6122c10 14 21 28 32 42"/><path d="m2564 6188c12 13 25 26 38 38"/><path d="m2626 6248c13 11 27 23 41 33"/><path d="m2694 6300c14 10 29 19 45 27"/><path d="m2768 6343c15 7 32 15 48 21"/><path d="m2847 6375c17 5 34 10 51 14"/><path d="m2930 6395c17 2 35 4 53 5"/><path d="m3015 6400h53"/><path d="m3100 6400h53"/><path d="m3186 6400h53"/><path d="m3271 6400h53"/><path d="m3357 6400h53"/><path d="m3442 6400h53"/><path d="m3527 6400h54"/><path d="m3613 6400h53"/><path d="m3698 6400h53"/><path d="m3784 6400h53"/><path d="m3869 6400h53"/><path d="m3955 6400h53"/><path d="m4040 6400h53"/><path d="m4125 6400h54"/><path d="m4211 6400h53"/><path d="m4296 6400h53"/><path d="m4382 6400h53"/><path d="m4467 6400h53"/><path d="m4553 6400h53"/><path d="m4638 6400h53"/><path d="m4723 6400h54"/><path d="m4809 6400h53"/><path d="m4894 6400h53"/><path d="m4980 6400h53"/><path d="m5065 6400h53"/><path d="m5151 6400h53"/><path d="m5236 6400h53"/><path d="m5322 6400h53"/><path d="m5407 6400h53"/><path d="m5492 6400h53"/><path d="m5578 6400h53"/><path d="m5663 6400h53"/><path d="m5749 6400h53"/><path d="m5834 6400h53"/><path d="m5920 6400h53"/><path d="m6005 6400h53"/><path d="m6090 6400h53"/><path d="m6176 6400h53"/><path d="m6261 6400h53"/><path d="m6347 6400h53"/><path d="m6432 6400h53"/><path d="m6518 6400h53"/><path d="m6603 6400h53"/><path d="m6688 6400h54"/><path d="m6774 6400h53"/><path d="m6859 6400h53"/><path d="m6945 6400h53"/><path d="m7030 6400h53"/><path d="m7116 6400h53"/><path d="m7201 6400h53"/><path d="m7286 6400h54"/><path d="m7372 6400h53"/><path d="m7457 6400h53"/><path d="m7543 6400h53"/><path d="m7628 6400h53"/><path d="m7714 6400h53"/><path d="m7799 6400h53"/><path d="m7884 6400h54"/><path d="m7970 6400h53"/><path d="m8055 6400h53"/><path d="m8141 6400h53"/><path d="m8226 6400h53"/><path d="m8312 6400h53"/><path d="m8397 6400h53"/><path d="m8482 6400h54"/><path d="m8568 6400h53"/><path d="m8653 6400h53"/><path d="m8739 6400h53"/><path d="m8824 6400h53"/><path d="m8910 6400h53"/><path d="m8995 6400h53"/><path d="m9081 6400h53"/><path d="m9166 6400h53"/><path d="m9251 6400h53"/><path d="m9337 6400h53"/><path d="m9422 6400h53"/><path d="m9508 6400h53"/><path d="m9593 6400h53"/><path d="m9679 6400h53"/><path d="m9764 6400h53"/><path d="m9849 6400h53"/><path d="m9935 6400h53"/><path d="m10020 6400h53"/><path d="m10106 6400h53"/><path d="m10191 6400h53"/><path d="m10277 6400h53"/><path d="m10362 6400h53"/><path d="m10447 6400h53"/><path d="m10533 6400h53"/><path d="m10618 6400h53"/><path d="m10704 6400h53"/><path d="m10789 6400h53"/><path d="m10875 6400h53"/><path d="m10960 6400h53"/><path d="m11045 6400h54"/><path d="m11131 6400h53"/><path d="m11216 6400h53"/><path d="m11302 6400h53"/><path d="m11387 6400h53"/><path d="m11473 6400h53"/><path d="m11558 6400h53"/><path d="m11643 6400h54"/><path d="m11729 6400h53"/><path d="m11814 6400h53"/><path d="m11900 6400h53"/><path d="m11985 6400h53"/><path d="m12071 6400h53"/><path d="m12156 6400h53"/><path d="m12241 6400h54"/><path d="m12327 6400h53"/><path d="m12412 6400h53"/><path d="m12498 6400h53"/><path d="m12583 6400h53"/><path d="m12669 6400h53"/><path d="m12754 6400h53"/><path d="m12839 6400h54"/><path d="m12925 6400h53"/><path d="m13010 6400h53"/><path d="m13096 6400h53"/><path d="m13181 6400h53"/><path d="m13267 6400h53"/><path d="m13352 6400h53"/><path d="m13438 6400h53"/><path d="m13523 6400h53"/><path d="m13608 6400h53"/><path d="m13694 6400h53"/><path d="m13779 6400h53"/><path d="m13865 6400h53"/><path d="m13950 6400h53"/><path d="m14036 6400h53"/><path d="m14121 6400h53"/><path d="m14206 6400h53"/><path d="m14292 6400h53"/><path d="m14377 6400h53"/><path d="m14463 6400h53"/><path d="m14548 6400h53"/><path d="m14634 6400h53"/><path d="m14719 6400h53"/><path d="m14804 6400h54"/><path d="m14890 6400h53"/><path d="m14975 6400h53"/><path d="m15061 6400h53"/><path d="m15146 6400h53"/><path d="m15232 6400h53"/><path d="m15317 6400h53"/><path d="m15402 6400h54"/><path d="m15488 6400h53"/><path d="m15573 6400h53"/><path d="m15659 6400h53"/><path d="m15744 6400h53"/><path d="m15830 6400h53"/><path d="m15915 6400h53"/><path d="m16000 6400h54"/><path d="m16086 6400h53"/><path d="m16171 6400h53"/><path d="m16257 6400h53"/><path d="m16342 6400h53"/><path d="m16428 6400h53"/><path d="m16513 6400h53"/><path d="m16598 6400h54"/><path d="m16684 6400h53"/><path d="m16769 6400h53"/><path d="m16855 6400h53"/><path d="m16940 6400h53"/><path d="m17026 6400h53"/><path d="m17111 6400h53"/><path d="m17196 6400h54"/><path d="m17282 6400h53"/><path d="m17367 6400h53"/><path d="m17453 6400h53"/><path d="m17538 6400h53"/><path d="m17624 6400h53"/><path d="m17709 6400h53"/><path d="m17795 6400h53"/><path d="m17880 6400h53"/><path d="m17965 6400h53"/><path d="m18051 6400h53"/><path d="m18136 6400h53"/><path d="m18222 6400h53"/><path d="m18307 6400h53"/><path d="m18393 6400h53"/><path d="m18478 6400h53"/><path d="m18563 6400h53"/><path d="m18649 6400h53"/><path d="m18734 6400h53"/><path d="m18820 6400h53"/><path d="m18905 6400h53"/><path d="m18991 6400h53"/><path d="m19076 6400h53"/><path d="m19161 6400h54"/><path d="m19247 6400h53"/><path d="m19332 6400h53"/><path d="m19418 6400h53"/><path d="m19503 6400h53"/><path d="m19589 6400h53"/><path d="m19674 6400h53"/><path d="m19759 6400h54"/><path d="m19845 6400h53"/><path d="m19930 6400h53"/><path d="m20016 6400h53"/><path d="m20101 6400h53"/><path d="m20187 6400h53"/><path d="m20272 6400h53"/><path d="m20357 6400h54"/><path d="m20443 6400h53"/><path d="m20528 6400h53"/><path d="m20614 6400c17-1 35-2 53-5"/><path d="m20699 6390c17-4 34-9 51-14"/><path d="m20781 6365c16-6 32-13 48-21"/><path d="m20858 6329c15-8 31-17 45-27"/><path d="m20930 6283c14-10 28-21 42-32"/><path d="m20996 6229c13-12 25-25 37-38"/><path d="m21055 6167c11-14 22-28 33-42"/><path d="m21106 6098c10-15 19-30 27-45"/><path d="m21148 6024c7-16 14-33 20-49"/><path d="m21179 5944c5-17 9-34 13-51"/><path d="m21197 5861c2-18 4-35 4-53"/><path d="m21201 5776v-54"/><path d="m21201 5690v-53"/><path d="m21201 5605v-53"/><path d="m21201 5519v-53"/><path d="m21201 5434v-53"/><path d="m21201 5348v-53"/><path d="m21201 5263v-53"/><path d="m21201 5178v-54"/><path d="m21201 5092v-53"/><path d="m21201 5007v-53"/><path d="m21201 4921v-53"/><path d="m21201 4836v-53"/><path d="m21201 4750v-53"/><path d="m21201 4665v-53"/><path d="m21201 4579v-53"/><path d="m21201 4494v-53"/><path d="m21201 4409v-53"/><path d="m21201 4323v-53"/><path d="m21201 4238v-53"/><path d="m21201 4152v-53"/><path d="m21201 4067v-53"/><path d="m21201 3981v-53"/><path d="m21201 3896v-53"/><path d="m21201 3811v-53"/><path d="m21201 3725v-53"/><path d="m21201 3640v-53"/><path d="m21201 3554v-53"/><path d="m21201 3469v-53"/><path d="m21201 3383c-1-17-3-35-5-52"/><path d="m21190 3299c-4-17-8-35-14-51"/><path d="m21165 3217c-6-16-13-33-21-49"/><path d="m21129 3140c-9-16-18-31-28-46"/><path d="m21082 3068c-10-14-21-28-33-42"/><path d="m21027 3002c-12-13-24-25-37-37"/><path d="m20965 2944c-14-12-28-22-42-33"/><path d="m20896 2893c-15-9-30-18-46-27"/><path d="m20821 2852c-16-8-32-14-49-20"/><path d="m20741 2821c-17-5-34-9-51-12"/><path d="m20658 2804c-18-3-35-4-53-4"/><path d="m20573 2800h-53"/><path d="m20487 2800h-53"/><path d="m20402 2800h-53"/><path d="m20316 2800h-53"/><path d="m20231 2800h-53"/><path d="m20146 2800h-54"/><path d="m20060 2800h-53"/><path d="m19975 2800h-53"/><path d="m19889 2800h-53"/><path d="m19804 2800h-53"/><path d="m19718 2800h-53"/><path d="m19633 2800h-53"/><path d="m19548 2800h-54"/><path d="m19462 2800h-53"/><path d="m19377 2800h-53"/><path d="m19291 2800h-53"/><path d="m19206 2800h-53"/><path d="m19120 2800h-53"/><path d="m19035 2800h-53"/><path d="m18950 2800h-54"/><path d="m18864 2800h-53"/><path d="m18779 2800h-53"/><path d="m18693 2800h-53"/><path d="m18608 2800h-53"/><path d="m18522 2800h-53"/><path d="m18437 2800h-53"/><path d="m18352 2800h-54"/><path d="m18266 2800h-53"/><path d="m18181 2800h-53"/><path d="m18095 2800h-53"/><path d="m18010 2800h-53"/><path d="m17924 2800h-53"/><path d="m17839 2800h-53"/><path d="m17753 2800h-53"/><path d="m17668 2800h-53"/><path d="m17583 2800h-53"/><path d="m17497 2800h-53"/><path d="m17412 2800h-53"/><path d="m17326 2800h-53"/><path d="m17241 2800h-53"/><path d="m17155 2800h-53"/><path d="m17070 2800h-53"/><path d="m16985 2800h-53"/><path d="m16899 2800h-53"/><path d="m16814 2800h-53"/><path d="m16728 2800h-53"/><path d="m16643 2800h-53"/><path d="m16557 2800h-53"/><path d="m16472 2800h-53"/><path d="m16387 2800h-54"/><path d="m16301 2800h-53"/><path d="m16216 2800h-53"/><path d="m16130 2800h-53"/><path d="m16045 2800h-53"/><path d="m15959 2800h-53"/><path d="m15874 2800h-53"/><path d="m15789 2800h-54"/><path d="m15703 2800h-53"/><path d="m15618 2800h-53"/><path d="m15532 2800h-53"/><path d="m15447 2800h-53"/><path d="m15361 2800h-53"/><path d="m15276 2800h-53"/><path d="m15191 2800h-54"/><path d="m15105 2800h-53"/><path d="m15020 2800h-53"/><path d="m14934 2800h-53"/><path d="m14849 2800h-53"/><path d="m14763 2800h-53"/><path d="m14678 2800h-53"/><path d="m14593 2800h-54"/><path d="m14507 2800h-53"/><path d="m14422 2800h-53"/><path d="m14336 2800h-53"/><path d="m14251 2800h-53"/><path d="m14165 2800h-53"/><path d="m14080 2800h-53"/><path d="m13994 2800h-53"/><path d="m13909 2800h-53"/><path d="m13824 2800h-53"/><path d="m13738 2800h-53"/><path d="m13653 2800h-53"/><path d="m13567 2800h-53"/><path d="m13482 2800h-53"/><path d="m13396 2800h-53"/><path d="m13311 2800h-53"/><path d="m13226 2800h-53"/><path d="m13140 2800h-53"/><path d="m13055 2800h-53"/><path d="m12969 2800h-53"/><path d="m12884 2800h-53"/><path d="m12798 2800h-53"/><path d="m12713 2800h-53"/><path d="m12628 2800h-53"/><path d="m12542 2800h-53"/><path d="m12457 2800h-53"/><path d="m12371 2800h-53"/><path d="m12286 2800h-53"/><path d="m12200 2800h-53"/><path d="m12115 2800h-53"/><path d="m12030 2800h-54"/><path d="m11944 2800h-53"/><path d="m11859 2800h-53"/><path d="m11773 2800h-53"/><path d="m11688 2800h-53"/><path d="m11602 2800h-53"/><path d="m11517 2800h-53"/><path d="m11432 2800h-54"/><path d="m11346 2800h-53"/><path d="m11261 2800h-53"/><path d="m11175 2800h-53"/><path d="m11090 2800h-53"/><path d="m11004 2800h-53"/><path d="m10919 2800h-53"/><path d="m10834 2800h-54"/><path d="m10748 2800h-53"/><path d="m10663 2800h-53"/><path d="m10577 2800h-53"/><path d="m10492 2800h-53"/><path d="m10406 2800h-53"/><path d="m10321 2800h-53"/><path d="m10236 2800h-54"/><path d="m10150 2800h-53"/><path d="m10065 2800h-53"/><path d="m9979 2800h-53"/><path d="m9894 2800h-53"/><path d="m9808 2800h-53"/><path d="m9723 2800h-53"/><path d="m9637 2800h-53"/><path d="m9552 2800h-53"/><path d="m9467 2800h-53"/><path d="m9381 2800h-53"/><path d="m9296 2800h-53"/><path d="m9210 2800h-53"/><path d="m9125 2800h-53"/><path d="m9039 2800h-53"/><path d="m8954 2800h-53"/><path d="m8869 2800h-53"/><path d="m8783 2800h-53"/><path d="m8698 2800h-53"/><path d="m8612 2800h-53"/><path d="m8527 2800h-53"/><path d="m8441 2800h-53"/><path d="m8356 2800h-53"/><path d="m8271 2800h-54"/><path d="m8185 2800h-53"/><path d="m8100 2800h-53"/><path d="m8014 2800h-53"/><path d="m7929 2800h-53"/><path d="m7843 2800h-53"/><path d="m7758 2800h-53"/><path d="m7673 2800h-54"/><path d="m7587 2800h-53"/><path d="m7502 2800h-53"/><path d="m7416 2800h-53"/><path d="m7331 2800h-53"/><path d="m7245 2800h-53"/><path d="m7160 2800h-53"/><path d="m7075 2800h-54"/><path d="m6989 2800h-53"/><path d="m6904 2800h-53"/><path d="m6818 2800h-53"/><path d="m6733 2800h-53"/><path d="m6647 2800h-53"/><path d="m6562 2800h-53"/><path d="m6477 2800h-54"/><path d="m6391 2800h-53"/><path d="m6306 2800h-53"/><path d="m6220 2800h-53"/><path d="m6135 2800h-53"/><path d="m6049 2800h-53"/><path d="m5964 2800h-53"/><path d="m5879 2800h-54"/><path d="m5793 2800h-53"/><path d="m5708 2800h-53"/><path d="m5622 2800h-53"/><path d="m5537 2800h-53"/><path d="m5451 2800h-53"/><path d="m5366 2800h-53"/><path d="m5280 2800h-53"/><path d="m5195 2800h-53"/><path d="m5110 2800h-53"/><path d="m5024 2800h-53"/><path d="m4939 2800h-53"/><path d="m4853 2800h-53"/><path d="m4768 2800h-53"/><path d="m4682 2800h-53"/><path d="m4597 2800h-53"/><path d="m4512 2800h-53"/><path d="m4426 2800h-53"/><path d="m4341 2800h-53"/><path d="m4255 2800h-53"/><path d="m4170 2800h-53"/><path d="m4084 2800h-53"/><path d="m3999 2800h-53"/><path d="m3914 2800h-54"/><path d="m3828 2800h-53"/><path d="m3743 2800h-53"/><path d="m3657 2800h-53"/><path d="m3572 2800h-53"/><path d="m3486 2800h-53"/><path d="m3401 2800h-53"/><path d="m3316 2800h-54"/><path d="m3230 2800h-53"/><path d="m3145 2800h-53"/><path d="m3059 2800h-53"/></g></g><g transform="translate(-2197.3 -2186)"><rect height="1100.7" width="1213.6" y="6917.1" x="23255" fill="#f3e777"/><path fill="#ca4677" d="m22802 7700.4v-405.46l150.7-169.16c82.886-93.039 170.53-186.62 194.77-207.96l44.069-38.798 783.23-0.086 783.23-0.086v613.5 613.5h-978-978v-405.46zm1027.7 136.98v-78.372l-169.91 4.925-169.91 4.9249-5.09 45.854c-8.249 74.303 46.711 101.04 207.69 101.04h137.21v-78.372zm235.86-262.94 4.495-341.31 207.2-8.6408 207.2-8.6408 5.144-46.443c9.596-86.615-41.863-102.05-322.02-96.607l-246.71 4.7956-4.438 419.08-4.439 419.08h74.537 74.538l4.494-341.31zm391.3 313.72c26.41-19.286 36.255-41.399 32.697-73.447l-5.09-45.854h-174.05-174.05l-5.38 48.984c-9.97 90.771 0.993 97.91 150.36 97.91 99.305 0 148.27-7.6982 175.52-27.594zm-627.16-274.84v-77.768h-174.05-174.05v66.246c0 36.436 4.973 71.431 11.051 77.768 6.078 6.3366 84.401 11.521 174.05 11.521h163v-77.768zm659.89-4.9154 5.125-74.042-179.18 4.9155-179.18 4.9155-5.38 48.984c-10.473 95.348-2.259 99.57 183.28 94.197l170.2-4.9284 5.125-74.042zm-659.89-237.63v-78.372l-169.91 4.925-169.91 4.925-5.097 73.447-5.097 73.447h175 175v-78.372zm659.86 4.925-5.097-73.447h-174.05-174.05l-5.38 48.984c-10.289 93.673-2.146 97.91 188.15 97.91h175.52l-5.097-73.447zm-659.86-228.98v-77.768h-137.21c-97.358 0-147.91 7.8138-174.05 26.902-34.952 25.523-49.645 92.242-25.79 117.11 6.078 6.3366 84.401 11.521 174.05 11.521h163v-77.768z"/></g><g transform="matrix(.84874 0 0 .76147 2408.1 3615.3)"><rect height="3076.2" width="2734.3" y="13264" x="19249" fill="#6076b3"/><g stroke-linejoin="round" fill-rule="evenodd" stroke-width="28.222" fill="#e0ee2c"><rect y="13369" width="356.65" x="18937" height="180.95"/><rect y="13708" width="356.65" x="18937" height="180.95"/><rect y="14048" width="356.65" x="18937" height="180.95"/><rect y="14387" width="356.65" x="18937" height="180.95"/><rect y="14726" width="356.65" x="18937" height="180.95"/><rect y="15066" width="356.65" x="18937" height="180.95"/><rect y="15405" width="356.65" x="18937" height="180.95"/><rect y="15744" width="356.65" x="18937" height="180.95"/><rect y="16083" width="356.65" x="18937" height="180.95"/><rect y="13324" width="356.65" x="21939" height="180.95"/><rect y="13663" width="356.65" x="21939" height="180.95"/><rect y="14002" width="356.65" x="21939" height="180.95"/><rect y="14342" width="356.65" x="21939" height="180.95"/><rect y="14681" width="356.65" x="21939" height="180.95"/><rect y="15020" width="356.65" x="21939" height="180.95"/><rect y="15360" width="356.65" x="21939" height="180.95"/><rect y="15699" width="356.65" x="21939" height="180.95"/><rect y="16038" width="356.65" x="21939" height="180.95"/></g><g stroke-linejoin="round" fill-rule="evenodd" transform="matrix(.98702 0 0 .90336 -2675 7020.8)" class="com.sun.star.drawing.TextShape" stroke-width="28.222"><text class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"/></text>
-<text style="word-spacing:0px;letter-spacing:0px" xml:space="preserve" font-size="1128.9px" y="9042.0264" x="22439.668" font-family="Sans" line-height="125%" fill="#000000"><tspan y="9042.0264" x="22439.668">CPU</tspan></text>
-</g></g><g stroke-linejoin="round" fill-rule="evenodd" transform="translate(-11752 543.6)" class="com.sun.star.drawing.TextShape" stroke-width="28.222"><text class="TextShape"><tspan font-size="706px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="15832" x="24341" class="TextPosition" transform="matrix(0,-1,1,0,8509,40173)"><tspan fill="#000000">PCI, USB, SPI, I2C, ...</tspan></tspan></tspan></text>
-</g><g stroke-linejoin="round" fill-rule="evenodd" transform="translate(-655.31 963.83)" class="com.sun.star.drawing.RectangleShape" stroke-width="28.222"><g transform="matrix(.49166 0 0 1.0059 6045.6 -82.24)"><path fill="#cfe7f5" d="m14169 14572h-2268v-1412h4536v1412h-2268z"/><path fill="none" d="m14169 14572h-2268v-1412h4536v1412h-2268z" stroke="#3465af"/></g><text y="-395.11282" x="-790.22229" class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="13686.9" x="12091.779" class="TextPosition"><tspan fill="#000000">Bridge</tspan></tspan></tspan></text>
-<text y="338.66486" x="-846.66675" class="TextShape"><tspan font-size="635px" font-family="&apos;Times New Roman&apos;, serif" font-weight="400" class="TextParagraph"><tspan y="14420.677" x="12035.335" class="TextPosition"><tspan fill="#000000"> DMA</tspan></tspan></tspan></text>
-</g></svg>
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ clip-path="url(#a)"
+ xml:space="preserve"
+ height="179mm"
+ viewBox="0 0 22648.239 17899.829"
+ width="235mm"
+ version="1.2"
+ preserveAspectRatio="xMidYMid"
+ id="svg2"
+ inkscape:version="0.91 r13725"
+ sodipodi:docname="typical_media_device.svg"
+ style="fill-rule:evenodd;stroke-width:28.22200012;stroke-linejoin:round"><metadata
+ id="metadata1533"><rdf:RDF><cc:Work
+ rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1920"
+ inkscape:window-height="997"
+ id="namedview1531"
+ showgrid="false"
+ fit-margin-top="0"
+ fit-margin-left="0"
+ fit-margin-right="0"
+ fit-margin-bottom="0"
+ inkscape:zoom="1.2707744"
+ inkscape:cx="410.32614"
+ inkscape:cy="316.736"
+ inkscape:window-x="1920"
+ inkscape:window-y="30"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="svg2" /><defs
+ id="defs4"><clipPath
+ id="a"
+ clipPathUnits="userSpaceOnUse"><rect
+ y="0"
+ x="0"
+ width="28000"
+ height="21000"
+ id="rect7" /></clipPath></defs><path
+ style="fill:#ffccff"
+ inkscape:connector-curvature="0"
+ id="path11"
+ d="m 10145.77,2636.013 c -518.0641,0 -1035.1241,515 -1035.1241,1031 l 0,4124 c 0,516 517.06,1032 1035.1241,1032 l 8572.152,0 c 518.064,0 1036.128,-516 1036.128,-1032 l 0,-4124 c 0,-516 -518.064,-1031 -1036.128,-1031 l -8572.152,0 z" /><path
+ style="fill:#ffffcc"
+ inkscape:connector-curvature="0"
+ id="path15"
+ d="m 1505.5459,13443.013 c -293,0 -585,292 -585,585 l 0,2340 c 0,293 292,586 585,586 l 3275,0 c 293,0 586,-293 586,-586 l 0,-2340 c 0,-293 -293,-585 -586,-585 l -3275,0 z" /><path
+ style="fill:#e6e6e6"
+ inkscape:connector-curvature="0"
+ id="path19"
+ d="m 517.1459,22.013 c -461,0 -922,461 -922,922 l 0,11169 c 0,461 461,923 922,923 l 3692,0 c 461,0 922,-462 922,-923 l 0,-11169 c 0,-461 -461,-922 -922,-922 l -3692,0 z" /><path
+ style="fill:#ff8080"
+ inkscape:connector-curvature="0"
+ id="path23"
+ d="m 2371.5459,6438.013 -2260,0 0,-1086 4520,0 0,1086 -2260,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path25"
+ d="m 2371.5459,6438.013 -2260,0 0,-1086 4520,0 0,1086 -2260,0 z" /><text
+ id="text27"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan29"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan31"
+ class="TextPosition"
+ x="489.5459"
+ y="6111.0132"><tspan
+ style="fill:#000000"
+ id="tspan33">Audio decoder</tspan></tspan></tspan></text>
+<path
+ style="fill:#ff8080"
+ inkscape:connector-curvature="0"
+ id="path37"
+ d="m 2371.5459,9608.013 -2260,0 0,-1270 4520,0 0,1270 -2260,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path39"
+ d="m 2371.5459,9608.013 -2260,0 0,-1270 4520,0 0,1270 -2260,0 z" /><text
+ id="text41"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan43"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan45"
+ class="TextPosition"
+ x="527.5459"
+ y="9189.0127"><tspan
+ style="fill:#000000"
+ id="tspan47">Video decoder</tspan></tspan></tspan></text>
+<path
+ style="fill:#ff8080"
+ inkscape:connector-curvature="0"
+ id="path51"
+ d="m 2363.5459,8053.013 -2269,0 0,-1224 4537,0 0,1224 -2268,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path53"
+ d="m 2363.5459,8053.013 -2269,0 0,-1224 4537,0 0,1224 -2268,0 z" /><text
+ id="text55"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan57"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan59"
+ class="TextPosition"
+ x="481.5459"
+ y="7657.0132"><tspan
+ style="fill:#000000"
+ id="tspan61">Audio encoder</tspan></tspan></tspan></text>
+<path
+ style="fill:#ccffcc"
+ inkscape:connector-curvature="0"
+ id="path65"
+ d="m 13621.546,10385.813 -3810.0001,0 0,-1281 7620.0001,0 0,1281 -3810,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path67"
+ d="m 13621.546,10385.813 -3810.0001,0 0,-1281 7620.0001,0 0,1281 -3810,0 z" /><text
+ id="text69"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2446.187"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan71"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan73"
+ class="TextPosition"
+ x="10287.546"
+ y="9960.8135"><tspan
+ style="fill:#000000"
+ id="tspan75">Button Key/IR input logic</tspan></tspan></tspan></text>
+<path
+ style="fill:#cfe7f5"
+ inkscape:connector-curvature="0"
+ id="path79"
+ d="m 12079.546,12182.213 -2268.0001,0 0,-1412 4536.0001,0 0,1412 -2268,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path81"
+ d="m 12079.546,12182.213 -2268.0001,0 0,-1412 4536.0001,0 0,1412 -2268,0 z" /><text
+ id="text83"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2389.7871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan85"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan87"
+ class="TextPosition"
+ x="10792.546"
+ y="11692.213"><tspan
+ style="fill:#000000"
+ id="tspan89">EEPROM</tspan></tspan></tspan></text>
+<path
+ style="fill:#ffcc99"
+ inkscape:connector-curvature="0"
+ id="path93"
+ d="m 3050.5459,15498.013 -1563,0 0,-1715 3126,0 0,1715 -1563,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path95"
+ d="m 3050.5459,15498.013 -1563,0 0,-1715 3126,0 0,1715 -1563,0 z" /><text
+ id="text97"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan99"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan101"
+ class="TextPosition"
+ x="2186.5459"
+ y="14856.013"><tspan
+ style="fill:#000000"
+ id="tspan103">Sensor</tspan></tspan></tspan></text>
+<path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path107"
+ d="m 4629.5459,5866.013 385,-353 0,176 1167,0 0,-176 386,353 -386,354 0,-177 -1167,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path109"
+ d="m 4629.5459,5866.013 385,-353 0,176 1167,0 0,-176 386,353 -386,354 0,-177 -1167,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path113"
+ d="m 4629.5459,7448.013 385,-353 0,176 1167,0 0,-176 386,353 -386,354 0,-177 -1167,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path115"
+ d="m 4629.5459,7448.013 385,-353 0,176 1167,0 0,-176 386,353 -386,354 0,-177 -1167,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path119"
+ d="m 4631.5459,8936.013 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path121"
+ d="m 4631.5459,8936.013 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path125"
+ d="m 7872.5459,11464.213 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path127"
+ d="m 7872.5459,11464.213 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path131"
+ d="m 7872.5459,9716.813 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path133"
+ d="m 7872.5459,9716.813 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path137"
+ d="m 7872.5459,14994.013 670,-353 0,176 2028.0001,0 0,-176 671,353 -671,354 0,-177 -2028.0001,0 0,177 -670,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path139"
+ d="m 7872.5459,14994.013 670,-353 0,176 2028.0001,0 0,-176 671,353 -671,354 0,-177 -2028.0001,0 0,177 -670,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path143"
+ d="m 17534.058,14104.529 978.488,840.891 -978.488,840.89 0,-420.862 -2960.48,0 0,420.862 -979.489,-840.89 979.489,-840.891 0,420.029 2960.48,0 0,-420.029 z" /><path
+ style="fill:none;stroke:#3465af;stroke-width:25.77035904"
+ inkscape:connector-curvature="0"
+ id="path145"
+ d="m 17534.058,14104.529 978.488,840.891 -978.488,840.89 0,-420.862 -2960.48,0 0,420.862 -979.489,-840.89 979.489,-840.891 0,420.029 2960.48,0 0,-420.029 z" /><text
+ id="text149"
+ class="TextShape"
+ x="-9922.1533"
+ y="-644.58704"><tspan
+ style="font-weight:400;font-size:706px;font-family:'Times New Roman', serif"
+ id="tspan151"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="706px"><tspan
+ id="tspan153"
+ transform="matrix(0,-1,1,0,8509,40173)"
+ class="TextPosition"
+ x="14418.847"
+ y="15187.413"><tspan
+ style="fill:#000000"
+ id="tspan155">System Bus</tspan></tspan></tspan></text>
+<path
+ style="fill:#ccffff"
+ inkscape:connector-curvature="0"
+ id="path159"
+ d="m 11061.546,7098.013 -1250.0001,0 0,-875 2499.0001,0 0,875 -1249,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path161"
+ d="m 11061.546,7098.013 -1250.0001,0 0,-875 2499.0001,0 0,875 -1249,0 z" /><text
+ id="text163"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan165"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan167"
+ class="TextPosition"
+ x="10125.546"
+ y="6876.0132"><tspan
+ style="fill:#000000"
+ id="tspan169">Demux</tspan></tspan></tspan></text>
+<path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path173"
+ d="m 7906.5459,6601.013 373,-357 0,178 1130,0 0,-178 374,357 -374,358 0,-179 -1130,0 0,179 -373,-358 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path175"
+ d="m 7906.5459,6601.013 373,-357 0,178 1130,0 0,-178 374,357 -374,358 0,-179 -1130,0 0,179 -373,-358 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path179"
+ d="m 7906.5459,5214.013 373,-358 0,179 1130,0 0,-179 374,358 -374,358 0,-179 -1130,0 0,179 -373,-358 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path181"
+ d="m 7906.5459,5214.013 373,-358 0,179 1130,0 0,-179 374,358 -374,358 0,-179 -1130,0 0,179 -373,-358 z" /><path
+ style="fill:#ccffff"
+ inkscape:connector-curvature="0"
+ id="path185"
+ d="m 14232.546,5828.013 -4421.0001,0 0,-1270 8841.0001,0 0,1270 -4420,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path187"
+ d="m 14232.546,5828.013 -4421.0001,0 0,-1270 8841.0001,0 0,1270 -4420,0 z" /><text
+ id="text189"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan191"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan193"
+ class="TextPosition"
+ x="10696.546"
+ y="5409.0132"><tspan
+ style="fill:#000000"
+ id="tspan195">Conditional Access Module</tspan></tspan></tspan></text>
+<path
+ style="fill:#ff8080"
+ inkscape:connector-curvature="0"
+ id="path199"
+ d="m 2355.5459,11123.013 -2269,0 0,-1224 4537,0 0,1224 -2268,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path201"
+ d="m 2355.5459,11123.013 -2269,0 0,-1224 4537,0 0,1224 -2268,0 z" /><text
+ id="text203"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan205"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan207"
+ class="TextPosition"
+ x="511.5459"
+ y="10727.013"><tspan
+ style="fill:#000000"
+ id="tspan209">Video encoder</tspan></tspan></tspan></text>
+<path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path213"
+ d="m 4631.5459,10470.013 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path215"
+ d="m 4631.5459,10470.013 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path219"
+ d="m 18701.546,5381.013 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path221"
+ d="m 18701.546,5381.013 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><text
+ id="text225"
+ class="TextShape"
+ x="-1976.5541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan227"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan229"
+ class="TextPosition"
+ x="13.4459"
+ y="12314.013"><tspan
+ style="fill:#000000"
+ id="tspan231">Radio / Analog TV</tspan></tspan></tspan></text>
+<text
+ id="text235"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:700;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan237"
+ class="TextParagraph"
+ font-weight="700"
+ font-size="635px"><tspan
+ id="tspan239"
+ class="TextPosition"
+ x="12866.546"
+ y="8560.0127"><tspan
+ style="fill:#000000"
+ id="tspan241">Digital TV</tspan></tspan></tspan></text>
+<text
+ id="text245"
+ class="TextShape"
+ x="-8919.0537"
+ y="-1373.787"><tspan
+ style="font-weight:400;font-size:494px;font-family:'Times New Roman', serif"
+ id="tspan247"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="494px"><tspan
+ id="tspan249"
+ class="TextPosition"
+ x="5804.9458"
+ y="17793.213"><tspan
+ style="fill:#000000"
+ id="tspan251">PS.: picture is not complete: other blocks may be present</tspan></tspan></tspan></text>
+<text
+ id="text255"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan257"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan259"
+ class="TextPosition"
+ x="2109.5459"
+ y="16397.014"><tspan
+ style="fill:#000000"
+ id="tspan261">Webcam</tspan></tspan></tspan></text>
+<path
+ style="fill:#ff9900"
+ inkscape:connector-curvature="0"
+ id="path265"
+ d="m 12462.546,13925.813 -2650.0001,0 0,-1412 5299.0001,0 0,1412 -2649,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path267"
+ d="m 12462.546,13925.813 -2650.0001,0 0,-1412 5299.0001,0 0,1412 -2649,0 z" /><text
+ id="text269"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2446.187"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan271"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan273"
+ class="TextPosition"
+ x="10175.546"
+ y="13435.813"><tspan
+ style="fill:#000000"
+ id="tspan275">Processing blocks</tspan></tspan></tspan></text>
+<path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path279"
+ d="m 7872.5459,13207.813 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path281"
+ d="m 7872.5459,13207.813 385,-353 0,176 1166,0 0,-176 386,353 -386,354 0,-177 -1166,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path285"
+ d="m 4612.5459,14790.013 397,-353 0,176 1201,0 0,-176 398,353 -398,354 0,-177 -1201,0 0,177 -397,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path287"
+ d="m 4612.5459,14790.013 397,-353 0,176 1201,0 0,-176 398,353 -398,354 0,-177 -1201,0 0,177 -397,-354 z" /><text
+ id="text291"
+ class="TextShape"
+ x="-2428.0542"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan293"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan295"
+ class="TextPosition"
+ x="20421.945"
+ y="6628.0132"><tspan
+ style="fill:#000000"
+ id="tspan297">Smartcard</tspan></tspan></tspan></text>
+<path
+ style="fill:#ffccff"
+ inkscape:connector-curvature="0"
+ id="path301"
+ d="m 623.3227,436.013 c -334.5984,0 -669.1968,333 -669.1968,666 l 0,2668 c 0,333 334.5984,666 669.1968,666 l 18456.1663,0 c 334.598,0 670.202,-333 670.202,-666 l 0,-2668 c 0,-333 -335.604,-666 -670.202,-666 l -18456.1663,0 z" /><path
+ style="fill:#ff8080"
+ inkscape:connector-curvature="0"
+ id="path305"
+ d="m 3031.5459,2991.013 -1614,0 0,-1816 3227,0 0,1816 -1613,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path307"
+ d="m 3031.5459,2991.013 -1614,0 0,-1816 3227,0 0,1816 -1613,0 z" /><text
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="text309"
+ class="TextShape"
+ font-weight="400"
+ font-size="635px"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ id="tspan311"
+ class="TextParagraph"><tspan
+ id="tspan313"
+ class="TextPosition"
+ x="2284.5459"
+ y="1947.0129"><tspan
+ style="fill:#000000"
+ id="tspan315">Tuner</tspan></tspan></tspan><tspan
+ id="tspan317"
+ class="TextParagraph"><tspan
+ id="tspan319"
+ class="TextPosition"
+ x="2061.5459"
+ y="2650.0129"><tspan
+ style="fill:#000000"
+ id="tspan321">FM/TV</tspan></tspan></tspan></text>
+<path
+ style="fill:#ff8080"
+ inkscape:connector-curvature="0"
+ id="path325"
+ d="m 812.5459,1538.013 c 0,111 40,202 88,202 l 530,0 c 48,0 89,-91 89,-202 0,-110 -41,-202 -89,-202 l -530,0 c -48,0 -88,92 -88,202 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path327"
+ d="m 812.5459,1538.013 c 0,111 40,202 88,202 l 530,0 c 48,0 89,-91 89,-202 0,-110 -41,-202 -89,-202 l -530,0 c -48,0 -88,92 -88,202 z" /><path
+ style="fill:#ffb3b3"
+ inkscape:connector-curvature="0"
+ id="path329"
+ d="m 812.5459,1538.013 c 0,111 40,202 88,202 48,0 88,-91 88,-202 0,-110 -40,-202 -88,-202 -48,0 -88,92 -88,202 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path331"
+ d="m 812.5459,1538.013 c 0,111 40,202 88,202 48,0 88,-91 88,-202 0,-110 -40,-202 -88,-202 -48,0 -88,92 -88,202 z" /><path
+ style="fill:#ff8080"
+ inkscape:connector-curvature="0"
+ id="path335"
+ d="m 813.5459,2103.013 c 0,110 40,202 88,202 l 530,0 c 48,0 89,-92 89,-202 0,-110 -41,-203 -89,-203 l -530,0 c -48,0 -88,93 -88,203 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path337"
+ d="m 813.5459,2103.013 c 0,110 40,202 88,202 l 530,0 c 48,0 89,-92 89,-202 0,-110 -41,-203 -89,-203 l -530,0 c -48,0 -88,93 -88,203 z" /><path
+ style="fill:#ffb3b3"
+ inkscape:connector-curvature="0"
+ id="path339"
+ d="m 813.5459,2103.013 c 0,110 40,202 88,202 48,0 88,-92 88,-202 0,-110 -40,-203 -88,-203 -48,0 -88,93 -88,203 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path341"
+ d="m 813.5459,2103.013 c 0,110 40,202 88,202 48,0 88,-92 88,-202 0,-110 -40,-203 -88,-203 -48,0 -88,93 -88,203 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path345"
+ d="m 4629.5459,2032.013 385,-353 0,176 1167,0 0,-176 386,353 -386,354 0,-177 -1167,0 0,177 -385,-354 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path347"
+ d="m 4629.5459,2032.013 385,-353 0,176 1167,0 0,-176 386,353 -386,354 0,-177 -1167,0 0,177 -385,-354 z" /><path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path351"
+ d="m 7889.5459,1986.013 402,-368 0,184 1217,0 0,-184 403,368 -403,369 0,-185 -1217,0 0,185 -402,-369 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path353"
+ d="m 7889.5459,1986.013 402,-368 0,184 1217,0 0,-184 403,368 -403,369 0,-185 -1217,0 0,185 -402,-369 z" /><path
+ style="fill:#ccffff"
+ inkscape:connector-curvature="0"
+ id="path357"
+ d="m 14410.546,4025.013 -4500.0001,0 0,-1389 9000.0001,0 0,1389 -4500,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path359"
+ d="m 14410.546,4025.013 -4500.0001,0 0,-1389 9000.0001,0 0,1389 -4500,0 z" /><text
+ id="text361"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan363"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan365"
+ class="TextPosition"
+ x="9961.5459"
+ y="3546.0129"><tspan
+ style="fill:#000000"
+ id="tspan367">Satellite Equipment Control (SEC)</tspan></tspan></tspan></text>
+<path
+ style="fill:#ccffff"
+ inkscape:connector-curvature="0"
+ id="path371"
+ d="m 11310.546,2436.013 -1400.0001,0 0,-1000 2800.0001,0 0,1000 -1400,0 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path373"
+ d="m 11310.546,2436.013 -1400.0001,0 0,-1000 2800.0001,0 0,1000 -1400,0 z" /><text
+ id="text375"
+ class="TextShape"
+ x="-2089.4541"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan377"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan379"
+ class="TextPosition"
+ x="10375.546"
+ y="2152.0129"><tspan
+ style="fill:#000000"
+ id="tspan381">Demod</tspan></tspan></tspan></text>
+<path
+ style="fill:#729fcf"
+ inkscape:connector-curvature="0"
+ id="path385"
+ d="m 7889.5459,3287.013 402,-368 0,184 1217,0 0,-184 403,368 -403,369 0,-185 -1217,0 0,185 -402,-369 z" /><path
+ style="fill:none;stroke:#3465af"
+ inkscape:connector-curvature="0"
+ id="path387"
+ d="m 7889.5459,3287.013 402,-368 0,184 1217,0 0,-184 403,368 -403,369 0,-185 -1217,0 0,185 -402,-369 z" /><path
+ d="m 7906.5459,9121.013 0,7302 -1270,0 0,-14605 1270,0 0,7303 z"
+ id="path389"
+ inkscape:connector-curvature="0"
+ style="fill:#ffff99" /><path
+ d="m 7906.5459,9121.013 0,7302 -1270,0 0,-14605 1270,0 0,7303 z"
+ id="path391"
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#3465af" /><text
+ y="-6589.021"
+ x="-20792.584"
+ transform="matrix(0,-1,1,0,0,0)"
+ class="TextShape"
+ id="text393"><tspan
+ font-size="635px"
+ font-weight="400"
+ class="TextParagraph"
+ id="tspan395"
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"><tspan
+ y="7460.9849"
+ x="-11215.646"
+ class="TextPosition"
+ transform="matrix(0,-1,1,0,-4473,23627)"
+ id="tspan397"><tspan
+ id="tspan399"
+ style="fill:#000000">I2C Bus (control bus)</tspan></tspan></tspan></text>
+<text
+ id="text403"
+ class="TextShape"
+ x="-2145.854"
+ y="-2163.9871"><tspan
+ style="font-weight:400;font-size:635px;font-family:'Times New Roman', serif"
+ id="tspan405"
+ class="TextParagraph"
+ font-weight="400"
+ font-size="635px"><tspan
+ id="tspan407"
+ class="TextPosition"
+ x="7245.146"
+ y="1114.0129"><tspan
+ style="fill:#000000"
+ id="tspan409">Digital TV Frontend</tspan></tspan></tspan></text>
+<path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 863.1459,636.145 c -18.27,0 -35.525,0.99994 -53.795,2.99982"
+ id="path415"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 776.8709,644.14452 c -17.255,2.99982 -35.525,6.99958 -52.78,11.99928"
+ id="path417"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 692.6259,666.1432 c -16.24,5.99964 -33.495,11.99928 -49.735,19.9988"
+ id="path419"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 613.4559,700.14116 c -15.225,7.99952 -31.465,16.99898 -46.69,26.99838"
+ id="path421"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 539.3609,745.13846 c -14.21,9.9994 -28.42,20.99874 -42.63,31.99808"
+ id="path423"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 471.3559,798.13528 c -13.195,11.99928 -26.39,23.99856 -38.57,36.99778"
+ id="path425"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 410.4559,859.13162 c -11.165,12.99922 -22.33,26.99838 -33.495,40.99754"
+ id="path427"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 357.6759,927.12754 c -10.15,13.99916 -19.285,28.99826 -28.42,44.9973"
+ id="path429"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 314.0309,1000.1232 c -8.12,15.999 -15.225,31.998 -22.33,48.997"
+ id="path431"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 280.5359,1079.1184 c -5.075,16.999 -10.15,33.998 -14.21,50.997"
+ id="path433"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 260.2359,1162.1134 c -3.045,17.999 -5.075,34.9979 -6.09,52.9969"
+ id="path435"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1247.1083 0,52.9969"
+ id="path437"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1333.1032 0,52.9968"
+ id="path439"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1418.0981 0,52.9968"
+ id="path441"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1504.0929 0,52.9968"
+ id="path443"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1589.0878 0,52.9968"
+ id="path445"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1675.0827 0,52.9968"
+ id="path447"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1760.0776 0,52.9968"
+ id="path449"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1845.0725 0,53.9967"
+ id="path451"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,1931.0673 0,52.9968"
+ id="path453"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2016.0622 0,52.9968"
+ id="path455"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2102.057 0,52.9969"
+ id="path457"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2187.0519 0,52.9969"
+ id="path459"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2273.0468 0,52.9968"
+ id="path461"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2358.0417 0,52.9968"
+ id="path463"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2443.0366 0,53.9967"
+ id="path465"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2529.0314 0,52.9968"
+ id="path467"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2614.0263 0,52.9968"
+ id="path469"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2700.0212 0,52.9968"
+ id="path471"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2785.0161 0,52.9968"
+ id="path473"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2871.0109 0,52.9968"
+ id="path475"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,2956.0058 0,52.9968"
+ id="path477"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3041.0007 0,53.9968"
+ id="path479"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3126.9955 0,52.9969"
+ id="path481"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3211.9904 0,52.9969"
+ id="path483"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3297.9853 0,52.9968"
+ id="path485"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3382.9802 0,52.9968"
+ id="path487"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3468.975 0,52.9968"
+ id="path489"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3553.9699 0,52.9968"
+ id="path491"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 254.1459,3638.9648 c 0,17.9989 1.015,35.9979 3.045,52.9968"
+ id="path493"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 262.2659,3723.9597 c 4.06,17.9989 8.12,34.9979 13.195,51.9969"
+ id="path495"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 285.6109,3806.9547 c 6.09,15.9991 13.195,32.9981 20.3,48.9971"
+ id="path497"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 321.1359,3884.9501 c 8.12,14.9991 17.255,30.9981 27.405,45.9972"
+ id="path499"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 366.8109,3957.9457 c 10.15,13.9991 21.315,27.9983 32.48,41.9975"
+ id="path501"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 420.6059,4023.9417 c 12.18,12.9992 25.375,25.9985 38.57,37.9977"
+ id="path503"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 483.5359,4083.9381 c 13.195,10.9994 27.405,22.9986 41.615,32.998"
+ id="path505"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 552.5559,4135.935 c 14.21,9.9994 29.435,18.9989 45.675,26.9984"
+ id="path507"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 627.6659,4178.9324 c 15.225,6.9996 32.48,14.9991 48.72,20.9988"
+ id="path509"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 707.8509,4210.9305 c 17.255,4.9997 34.51,9.9994 51.765,13.9992"
+ id="path511"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 792.0959,4230.9293 c 17.255,1.9999 35.525,3.9998 53.795,4.9997"
+ id="path513"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 878.3709,4235.929 53.795,0"
+ id="path515"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 964.6459,4235.929 53.795,0"
+ id="path517"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1051.9359,4235.929 53.795,0"
+ id="path519"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1138.2109,4235.929 53.795,0"
+ id="path521"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1225.5009,4235.929 53.795,0"
+ id="path523"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1311.7759,4235.929 53.795,0"
+ id="path525"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1398.0509,4235.929 54.81,0"
+ id="path527"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1485.3409,4235.929 53.795,0"
+ id="path529"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1571.6159,4235.929 53.795,0"
+ id="path531"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1658.9059,4235.929 53.795,0"
+ id="path533"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1745.1809,4235.929 53.795,0"
+ id="path535"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1832.4709,4235.929 53.795,0"
+ id="path537"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 1918.7459,4235.929 53.795,0"
+ id="path539"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2005.0209,4235.929 54.81,0"
+ id="path541"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2092.3109,4235.929 53.795,0"
+ id="path543"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2178.5859,4235.929 53.795,0"
+ id="path545"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2265.8759,4235.929 53.795,0"
+ id="path547"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2352.1509,4235.929 53.795,0"
+ id="path549"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2439.4409,4235.929 53.795,0"
+ id="path551"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2525.7159,4235.929 53.795,0"
+ id="path553"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2611.9909,4235.929 54.81,0"
+ id="path555"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2699.2809,4235.929 53.795,0"
+ id="path557"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2785.5559,4235.929 53.795,0"
+ id="path559"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2872.8459,4235.929 53.795,0"
+ id="path561"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 2959.1209,4235.929 53.795,0"
+ id="path563"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3046.4109,4235.929 53.795,0"
+ id="path565"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3132.6859,4235.929 53.795,0"
+ id="path567"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3219.9759,4235.929 53.795,0"
+ id="path569"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3306.2509,4235.929 53.795,0"
+ id="path571"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3392.5259,4235.929 53.795,0"
+ id="path573"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3479.8159,4235.929 53.795,0"
+ id="path575"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3566.0909,4235.929 53.795,0"
+ id="path577"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3653.3809,4235.929 53.795,0"
+ id="path579"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3739.6559,4235.929 53.795,0"
+ id="path581"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3826.9459,4235.929 53.795,0"
+ id="path583"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3913.2209,4235.929 53.795,0"
+ id="path585"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 3999.4959,4235.929 53.795,0"
+ id="path587"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4086.7859,4235.929 53.795,0"
+ id="path589"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4173.0609,4235.929 53.795,0"
+ id="path591"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4260.3509,4235.929 53.795,0"
+ id="path593"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4346.6259,4235.929 53.795,0"
+ id="path595"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4433.9159,4235.929 53.795,0"
+ id="path597"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4520.1909,4235.929 53.795,0"
+ id="path599"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4606.4659,4235.929 54.81,0"
+ id="path601"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4693.7559,4235.929 53.795,0"
+ id="path603"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4780.0309,4235.929 53.795,0"
+ id="path605"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4867.3209,4235.929 53.795,0"
+ id="path607"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 4953.5959,4235.929 53.795,0"
+ id="path609"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5040.8859,4235.929 53.795,0"
+ id="path611"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5127.1609,4235.929 53.795,0"
+ id="path613"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5213.4359,4235.929 54.81,0"
+ id="path615"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5300.7259,4235.929 53.795,0"
+ id="path617"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5387.0009,4235.929 53.795,0"
+ id="path619"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5474.2909,4235.929 53.795,0"
+ id="path621"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5560.5659,4235.929 53.795,0"
+ id="path623"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5647.8559,4235.929 53.795,0"
+ id="path625"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5734.1309,4235.929 53.795,0"
+ id="path627"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5820.4059,4235.929 54.81,0"
+ id="path629"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5907.6959,4235.929 53.795,0"
+ id="path631"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 5993.9709,4235.929 53.795,0"
+ id="path633"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6081.2609,4235.929 53.795,0"
+ id="path635"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6167.5359,4235.929 53.795,0"
+ id="path637"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6254.8259,4235.929 53.795,0"
+ id="path639"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6341.1009,4235.929 53.795,0"
+ id="path641"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6427.3759,4235.929 54.81,0"
+ id="path643"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6514.6659,4235.929 53.795,0"
+ id="path645"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6600.9409,4235.929 53.795,0"
+ id="path647"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6688.2309,4235.929 53.795,0"
+ id="path649"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6774.5059,4235.929 53.795,0"
+ id="path651"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6861.7959,4235.929 53.795,0"
+ id="path653"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 6948.0709,4235.929 53.795,0"
+ id="path655"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7035.3609,4235.929 53.795,0"
+ id="path657"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7121.6359,4235.929 53.795,0"
+ id="path659"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7207.9109,4235.929 53.795,0"
+ id="path661"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7295.2009,4235.929 53.795,0"
+ id="path663"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7381.4759,4235.929 53.795,0"
+ id="path665"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7468.7659,4235.929 53.795,0"
+ id="path667"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7555.0409,4235.929 53.795,0"
+ id="path669"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7642.3309,4235.929 53.795,0"
+ id="path671"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7728.6059,4235.929 53.795,0"
+ id="path673"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7814.8809,4235.929 53.795,0"
+ id="path675"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7902.1709,4235.929 53.795,0"
+ id="path677"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 7988.4459,4235.929 53.795,0"
+ id="path679"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8075.7359,4235.929 53.795,0"
+ id="path681"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8162.0109,4235.929 53.795,0"
+ id="path683"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8249.3009,4235.929 53.795,0"
+ id="path685"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8335.5759,4235.929 53.795,0"
+ id="path687"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8421.8509,4235.929 53.795,0"
+ id="path689"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8509.1409,4235.929 53.795,0"
+ id="path691"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8595.4159,4235.929 53.795,0"
+ id="path693"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8682.7059,4235.929 53.795,0"
+ id="path695"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8768.9809,4235.929 53.795,0"
+ id="path697"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8856.2709,4235.929 53.795,0"
+ id="path699"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 8942.5459,4235.929 53.795,0"
+ id="path701"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9028.8209,4235.929 54.81,0"
+ id="path703"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9116.1109,4235.929 53.795,0"
+ id="path705"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9202.3859,4235.929 53.795,0"
+ id="path707"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9289.6759,4235.929 53.795,0"
+ id="path709"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9375.9509,4235.929 53.795,0"
+ id="path711"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9463.2409,4235.929 53.795,0"
+ id="path713"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9549.5159,4235.929 53.795,0"
+ id="path715"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9635.7909,4235.929 54.81,0"
+ id="path717"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9723.0809,4235.929 53.795,0"
+ id="path719"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9809.3559,4235.929 53.795,0"
+ id="path721"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9896.6459,4235.929 53.795,0"
+ id="path723"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 9982.9209,4235.929 53.7951,0"
+ id="path725"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10070.211,4235.929 53.795,0"
+ id="path727"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10156.486,4235.929 53.795,0"
+ id="path729"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10242.761,4235.929 54.81,0"
+ id="path731"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10330.051,4235.929 53.795,0"
+ id="path733"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10416.326,4235.929 53.795,0"
+ id="path735"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10503.616,4235.929 53.795,0"
+ id="path737"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10589.891,4235.929 53.795,0"
+ id="path739"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10677.181,4235.929 53.795,0"
+ id="path741"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10763.456,4235.929 53.795,0"
+ id="path743"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10849.731,4235.929 54.81,0"
+ id="path745"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 10937.021,4235.929 53.795,0"
+ id="path747"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11023.296,4235.929 53.795,0"
+ id="path749"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11110.586,4235.929 53.795,0"
+ id="path751"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11196.861,4235.929 53.795,0"
+ id="path753"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11284.151,4235.929 53.795,0"
+ id="path755"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11370.426,4235.929 53.795,0"
+ id="path757"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11457.716,4235.929 53.795,0"
+ id="path759"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11543.991,4235.929 53.795,0"
+ id="path761"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11630.266,4235.929 53.795,0"
+ id="path763"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11717.556,4235.929 53.795,0"
+ id="path765"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11803.831,4235.929 53.795,0"
+ id="path767"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11891.121,4235.929 53.795,0"
+ id="path769"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11977.396,4235.929 53.795,0"
+ id="path771"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12064.686,4235.929 53.795,0"
+ id="path773"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12150.961,4235.929 53.795,0"
+ id="path775"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12237.236,4235.929 53.795,0"
+ id="path777"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12324.526,4235.929 53.795,0"
+ id="path779"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12410.801,4235.929 53.795,0"
+ id="path781"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12498.091,4235.929 53.795,0"
+ id="path783"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12584.366,4235.929 53.795,0"
+ id="path785"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12671.656,4235.929 53.795,0"
+ id="path787"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12757.931,4235.929 53.795,0"
+ id="path789"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12844.206,4235.929 54.81,0"
+ id="path791"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12931.496,4235.929 53.795,0"
+ id="path793"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13017.771,4235.929 53.795,0"
+ id="path795"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13105.061,4235.929 53.795,0"
+ id="path797"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13191.336,4235.929 53.795,0"
+ id="path799"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13278.626,4235.929 53.795,0"
+ id="path801"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13364.901,4235.929 53.795,0"
+ id="path803"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13451.176,4235.929 54.81,0"
+ id="path805"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13538.466,4235.929 53.795,0"
+ id="path807"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13624.741,4235.929 53.795,0"
+ id="path809"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13712.031,4235.929 53.795,0"
+ id="path811"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13798.306,4235.929 53.795,0"
+ id="path813"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13885.596,4235.929 53.795,0"
+ id="path815"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13971.871,4235.929 53.795,0"
+ id="path817"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14058.146,4235.929 54.81,0"
+ id="path819"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14145.436,4235.929 53.795,0"
+ id="path821"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14231.711,4235.929 53.795,0"
+ id="path823"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14319.001,4235.929 53.795,0"
+ id="path825"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14405.276,4235.929 53.795,0"
+ id="path827"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14492.566,4235.929 53.795,0"
+ id="path829"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14578.841,4235.929 53.795,0"
+ id="path831"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14665.116,4235.929 54.81,0"
+ id="path833"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14752.406,4235.929 53.795,0"
+ id="path835"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14838.681,4235.929 53.795,0"
+ id="path837"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14925.971,4235.929 53.795,0"
+ id="path839"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15012.246,4235.929 53.795,0"
+ id="path841"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15099.536,4235.929 53.795,0"
+ id="path843"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15185.811,4235.929 53.795,0"
+ id="path845"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15272.086,4235.929 54.81,0"
+ id="path847"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15359.376,4235.929 53.795,0"
+ id="path849"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15445.651,4235.929 53.795,0"
+ id="path851"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15532.941,4235.929 53.795,0"
+ id="path853"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15619.216,4235.929 53.795,0"
+ id="path855"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15706.506,4235.929 53.795,0"
+ id="path857"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15792.781,4235.929 53.795,0"
+ id="path859"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15880.071,4235.929 53.795,0"
+ id="path861"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15966.346,4235.929 53.795,0"
+ id="path863"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16052.621,4235.929 53.795,0"
+ id="path865"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16139.911,4235.929 53.795,0"
+ id="path867"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16226.186,4235.929 53.795,0"
+ id="path869"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16313.476,4235.929 53.795,0"
+ id="path871"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16399.751,4235.929 53.795,0"
+ id="path873"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16487.041,4235.929 53.795,0"
+ id="path875"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16573.316,4235.929 53.795,0"
+ id="path877"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16659.591,4235.929 53.795,0"
+ id="path879"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16746.881,4235.929 53.795,0"
+ id="path881"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16833.156,4235.929 53.795,0"
+ id="path883"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16920.446,4235.929 53.795,0"
+ id="path885"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17006.721,4235.929 53.795,0"
+ id="path887"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17094.011,4235.929 53.795,0"
+ id="path889"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17180.286,4235.929 53.795,0"
+ id="path891"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17266.561,4235.929 54.81,0"
+ id="path893"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17353.851,4235.929 53.795,0"
+ id="path895"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17440.126,4235.929 53.795,0"
+ id="path897"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17527.416,4235.929 53.795,0"
+ id="path899"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17613.691,4235.929 53.795,0"
+ id="path901"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17700.981,4235.929 53.795,0"
+ id="path903"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17787.256,4235.929 53.795,0"
+ id="path905"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17873.531,4235.929 54.81,0"
+ id="path907"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17960.821,4235.929 53.795,0"
+ id="path909"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18047.096,4235.929 53.795,0"
+ id="path911"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18134.386,4235.929 53.795,0"
+ id="path913"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18220.661,4235.929 53.795,0"
+ id="path915"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18307.951,4235.929 53.795,0"
+ id="path917"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18394.226,4235.929 53.795,0"
+ id="path919"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18480.501,4235.929 54.81,0"
+ id="path921"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18567.791,4235.929 53.795,0"
+ id="path923"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18654.066,4235.929 53.795,0"
+ id="path925"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18741.356,4235.929 c 17.255,-0.9999 35.525,-1.9999 53.795,-4.9997"
+ id="path927"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18827.631,4225.9296 c 17.255,-3.9998 34.51,-8.9995 51.765,-13.9992"
+ id="path929"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18910.861,4200.9311 c 16.24,-5.9996 32.48,-12.9992 48.72,-20.9987"
+ id="path931"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18989.016,4164.9333 c 15.225,-7.9996 31.465,-16.999 45.675,-26.9984"
+ id="path933"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19062.096,4118.936 c 14.21,-9.9994 28.42,-20.9987 42.63,-31.9981"
+ id="path935"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19129.086,4064.9393 c 13.195,-11.9993 25.375,-24.9985 37.555,-37.9978"
+ id="path937"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19188.971,4002.943 c 11.165,-13.9992 22.33,-27.9983 33.495,-41.9975"
+ id="path939"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19240.736,3933.9471 c 10.15,-14.9991 19.285,-29.9982 27.405,-44.9973"
+ id="path941"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19283.366,3859.9516 c 7.105,-15.9991 14.21,-32.9981 20.3,-48.9971"
+ id="path943"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19314.831,3779.9564 c 5.075,-16.999 9.135,-33.998 13.195,-50.997"
+ id="path945"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19333.101,3696.9613 c 2.03,-17.9989 4.06,-34.9979 4.06,-52.9968"
+ id="path947"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3611.9664 0,-53.9967"
+ id="path949"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3525.9716 0,-52.9968"
+ id="path951"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3440.9767 0,-52.9968"
+ id="path953"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3354.9819 0,-52.9969"
+ id="path955"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3269.987 0,-52.9969"
+ id="path957"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3183.9921 0,-52.9968"
+ id="path959"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3098.9972 0,-52.9968"
+ id="path961"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,3014.0023 0,-53.9967"
+ id="path963"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2928.0075 0,-52.9968"
+ id="path965"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2843.0126 0,-52.9968"
+ id="path967"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2757.0177 0,-52.9968"
+ id="path969"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2672.0228 0,-52.9968"
+ id="path971"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2586.028 0,-52.9968"
+ id="path973"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2501.0331 0,-52.9968"
+ id="path975"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2415.0383 0,-52.9969"
+ id="path977"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2330.0434 0,-52.9969"
+ id="path979"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2245.0485 0,-52.9969"
+ id="path981"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2159.0536 0,-52.9968"
+ id="path983"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,2074.0587 0,-52.9968"
+ id="path985"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1988.0639 0,-52.9968"
+ id="path987"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1903.069 0,-52.9968"
+ id="path989"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1817.0741 0,-52.9968"
+ id="path991"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1732.0792 0,-52.9968"
+ id="path993"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1647.0843 0,-52.9968"
+ id="path995"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1561.0895 0,-52.9968"
+ id="path997"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1476.0946 0,-52.9968"
+ id="path999"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1390.0998 0,-52.9969"
+ id="path1001"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1305.1049 0,-52.9969"
+ id="path1003"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19337.161,1219.11 c -1.015,-16.999 -3.045,-34.9979 -5.075,-51.9969"
+ id="path1005"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19325.996,1135.1151 c -4.06,-16.999 -8.12,-34.9979 -14.21,-50.997"
+ id="path1007"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19300.621,1053.12 c -6.09,-15.9991 -13.195,-32.998 -21.315,-48.9971"
+ id="path1009"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19264.081,976.1246 c -9.135,-15.99904 -18.27,-30.99814 -28.42,-45.99724"
+ id="path1011"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19216.376,904.12892 c -10.15,-13.99916 -21.315,-27.99832 -33.495,-41.99748"
+ id="path1013"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19160.551,838.13288 c -12.18,-12.99922 -24.36,-24.9985 -37.555,-36.99778"
+ id="path1015"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19097.621,780.13636 c -14.21,-11.99928 -28.42,-21.99868 -42.63,-32.99802"
+ id="path1017"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 19027.586,729.13942 c -15.225,-8.99946 -30.45,-17.99892 -46.69,-26.99838"
+ id="path1019"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18951.461,688.14188 c -16.24,-7.99952 -32.48,-13.99916 -49.735,-19.9988"
+ id="path1021"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18870.261,657.14374 c -17.255,-4.9997 -34.51,-8.99946 -51.765,-11.99928"
+ id="path1023"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18786.016,640.14476 c -18.27,-2.99982 -35.525,-3.99976 -53.795,-3.99976"
+ id="path1025"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18699.741,636.145 -53.795,0"
+ id="path1027"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18612.451,636.145 -53.795,0"
+ id="path1029"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18526.176,636.145 -53.795,0"
+ id="path1031"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18438.886,636.145 -53.795,0"
+ id="path1033"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18352.611,636.145 -53.795,0"
+ id="path1035"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18266.336,636.145 -54.81,0"
+ id="path1037"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18179.046,636.145 -53.795,0"
+ id="path1039"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18092.771,636.145 -53.795,0"
+ id="path1041"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 18005.481,636.145 -53.795,0"
+ id="path1043"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17919.206,636.145 -53.795,0"
+ id="path1045"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17831.916,636.145 -53.795,0"
+ id="path1047"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17745.641,636.145 -53.795,0"
+ id="path1049"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17659.366,636.145 -54.81,0"
+ id="path1051"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17572.076,636.145 -53.795,0"
+ id="path1053"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17485.801,636.145 -53.795,0"
+ id="path1055"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17398.511,636.145 -53.795,0"
+ id="path1057"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17312.236,636.145 -53.795,0"
+ id="path1059"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17224.946,636.145 -53.795,0"
+ id="path1061"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17138.671,636.145 -53.795,0"
+ id="path1063"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 17052.396,636.145 -54.81,0"
+ id="path1065"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16965.106,636.145 -53.795,0"
+ id="path1067"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16878.831,636.145 -53.795,0"
+ id="path1069"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16791.541,636.145 -53.795,0"
+ id="path1071"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16705.266,636.145 -53.795,0"
+ id="path1073"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16617.976,636.145 -53.795,0"
+ id="path1075"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16531.701,636.145 -53.795,0"
+ id="path1077"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16445.426,636.145 -54.81,0"
+ id="path1079"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16358.136,636.145 -53.795,0"
+ id="path1081"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16271.861,636.145 -53.795,0"
+ id="path1083"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16184.571,636.145 -53.795,0"
+ id="path1085"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16098.296,636.145 -53.795,0"
+ id="path1087"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 16011.006,636.145 -53.795,0"
+ id="path1089"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15924.731,636.145 -53.795,0"
+ id="path1091"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15837.441,636.145 -53.795,0"
+ id="path1093"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15751.166,636.145 -53.795,0"
+ id="path1095"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15664.891,636.145 -53.795,0"
+ id="path1097"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15577.601,636.145 -53.795,0"
+ id="path1099"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15491.326,636.145 -53.795,0"
+ id="path1101"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15404.036,636.145 -53.795,0"
+ id="path1103"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15317.761,636.145 -53.795,0"
+ id="path1105"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15230.471,636.145 -53.795,0"
+ id="path1107"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15144.196,636.145 -53.795,0"
+ id="path1109"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 15057.921,636.145 -53.795,0"
+ id="path1111"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14970.631,636.145 -53.795,0"
+ id="path1113"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14884.356,636.145 -53.795,0"
+ id="path1115"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14797.066,636.145 -53.795,0"
+ id="path1117"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14710.791,636.145 -53.795,0"
+ id="path1119"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14623.501,636.145 -53.795,0"
+ id="path1121"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14537.226,636.145 -53.795,0"
+ id="path1123"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14450.951,636.145 -54.81,0"
+ id="path1125"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14363.661,636.145 -53.795,0"
+ id="path1127"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14277.386,636.145 -53.795,0"
+ id="path1129"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14190.096,636.145 -53.795,0"
+ id="path1131"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14103.821,636.145 -53.795,0"
+ id="path1133"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 14016.531,636.145 -53.795,0"
+ id="path1135"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13930.256,636.145 -53.795,0"
+ id="path1137"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13843.981,636.145 -54.81,0"
+ id="path1139"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13756.691,636.145 -53.795,0"
+ id="path1141"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13670.416,636.145 -53.795,0"
+ id="path1143"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13583.126,636.145 -53.795,0"
+ id="path1145"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13496.851,636.145 -53.795,0"
+ id="path1147"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13409.561,636.145 -53.795,0"
+ id="path1149"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13323.286,636.145 -53.795,0"
+ id="path1151"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13237.011,636.145 -54.81,0"
+ id="path1153"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13149.721,636.145 -53.795,0"
+ id="path1155"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 13063.446,636.145 -53.795,0"
+ id="path1157"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12976.156,636.145 -53.795,0"
+ id="path1159"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12889.881,636.145 -53.795,0"
+ id="path1161"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12802.591,636.145 -53.795,0"
+ id="path1163"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12716.316,636.145 -53.795,0"
+ id="path1165"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12630.041,636.145 -54.81,0"
+ id="path1167"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12542.751,636.145 -53.795,0"
+ id="path1169"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12456.476,636.145 -53.795,0"
+ id="path1171"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12369.186,636.145 -53.795,0"
+ id="path1173"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12282.911,636.145 -53.795,0"
+ id="path1175"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12195.621,636.145 -53.795,0"
+ id="path1177"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12109.346,636.145 -53.795,0"
+ id="path1179"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 12022.056,636.145 -53.795,0"
+ id="path1181"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11935.781,636.145 -53.795,0"
+ id="path1183"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11849.506,636.145 -53.795,0"
+ id="path1185"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke-width:28.432024"
+ d="m 11762.216,636.145 -53.795,0"
+ id="path1187"
+ inkscape:connector-curvature="0" /><path
+ style="fill:none;stroke:#3465af;stroke