summaryrefslogtreecommitdiffstats
path: root/Documentation/devicetree/bindings/arm
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2016-01-14 11:13:28 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2016-01-14 11:13:28 -0800
commit5339f9d4c2ceccab00b28d65bd5c2b2cd6a3de05 (patch)
tree765564f61fc270c415de903b0dfb1e040c02944a /Documentation/devicetree/bindings/arm
parentcf8d7e3850ee44dc2f0a69405d731af62528a948 (diff)
parent183223770ae8625df8966ed15811d1b3ee8720aa (diff)
downloadop-kernel-dev-5339f9d4c2ceccab00b28d65bd5c2b2cd6a3de05.zip
op-kernel-dev-5339f9d4c2ceccab00b28d65bd5c2b2cd6a3de05.tar.gz
Merge tag 'devicetree-for-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull DeviceTree updates from Rob Herring: - Rework and export the changeset API to make it available to users other than DT overlays - ARM secure devices binding - OCTEON USB binding - Clean-up of various SRAM binding docs - Various other binding doc updates * tag 'devicetree-for-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (21 commits) drivers/of: Export OF changeset functions Fix documentation for adp1653 DT ARM: psci: Fix indentation in DT bindings of/platform: export of_default_bus_match_table of/unittest: Show broken behaviour in the platform bus of: fix declaration of of_io_request_and_map of/address: replace printk(KERN_ERR ...) with pr_err(...) of/irq: optimize device node matching loop in of_irq_init() dt-bindings: tda998x: Document the required 'port' node. net/macb: bindings doc: Merge cdns-emac to macb dt-bindings: Misc fix for the ATH79 DDR controllers dt-bindings: Misc fix for the ATH79 MISC interrupt controllers Documentation: dt: Add bindings for Secure-only devices dt-bindings: ARM: add arm,cortex-a72 compatible string ASoC: Atmel: ClassD: add GCK's parent clock in DT binding DT: add Olimex to vendor prefixes Documentation: fsl-quadspi: Add fsl,ls1021-qspi compatible string Documentation/devicetree: document OCTEON USB bindings usb: misc: usb3503: Describe better how to bind clock to the hub dt-bindings: Consolidate SRAM bindings from all vendors ...
Diffstat (limited to 'Documentation/devicetree/bindings/arm')
-rw-r--r--Documentation/devicetree/bindings/arm/arm,scpi.txt2
-rw-r--r--Documentation/devicetree/bindings/arm/cpus.txt1
-rw-r--r--Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt38
-rw-r--r--Documentation/devicetree/bindings/arm/psci.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt16
-rw-r--r--Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt30
-rw-r--r--Documentation/devicetree/bindings/arm/secure.txt53
7 files changed, 69 insertions, 96 deletions
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index 86302de..313dabd 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -63,7 +63,7 @@ Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
The rest of the properties should follow the generic mmio-sram description
-found in ../../misc/sysram.txt
+found in ../../sram/sram.txt
Each sub-node represents the reserved area for SCPI.
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 6aca64f..c352c11b 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -157,6 +157,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-a17"
"arm,cortex-a53"
"arm,cortex-a57"
+ "arm,cortex-a72"
"arm,cortex-m0"
"arm,cortex-m0+"
"arm,cortex-m1"
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
deleted file mode 100644
index 4a0a4f7..0000000
--- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Samsung Exynos SYSRAM for SMP bringup:
-------------------------------------
-
-Samsung SMP-capable Exynos SoCs use part of the SYSRAM for the bringup
-of the secondary cores. Once the core gets powered up it executes the
-code that is residing at some specific location of the SYSRAM.
-
-Therefore reserved section sub-nodes have to be added to the mmio-sram
-declaration. These nodes are of two types depending upon secure or
-non-secure execution environment.
-
-Required sub-node properties:
-- compatible : depending upon boot mode, should be
- "samsung,exynos4210-sysram" : for Secure SYSRAM
- "samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
-
-The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sysram.txt
-
-Example:
-
- sysram@02020000 {
- compatible = "mmio-sram";
- reg = <0x02020000 0x54000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x02020000 0x54000>;
-
- smp-sysram@0 {
- compatible = "samsung,exynos4210-sysram";
- reg = <0x0 0x1000>;
- };
-
- smp-sysram@53000 {
- compatible = "samsung,exynos4210-sysram-ns";
- reg = <0x53000 0x1000>;
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index a9adab8..a2c4f1d 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -23,17 +23,20 @@ Main node required properties:
- compatible : should contain at least one of:
- * "arm,psci" : for implementations complying to PSCI versions prior to
- 0.2. For these cases function IDs must be provided.
-
- * "arm,psci-0.2" : for implementations complying to PSCI 0.2. Function
- IDs are not required and should be ignored by an OS with PSCI 0.2
- support, but are permitted to be present for compatibility with
- existing software when "arm,psci" is later in the compatible list.
-
- * "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is
- backward compatible with PSCI 0.2 with minor specification updates,
- as defined in the PSCI specification[2].
+ * "arm,psci" : For implementations complying to PSCI versions prior
+ to 0.2.
+ For these cases function IDs must be provided.
+
+ * "arm,psci-0.2" : For implementations complying to PSCI 0.2.
+ Function IDs are not required and should be ignored by
+ an OS with PSCI 0.2 support, but are permitted to be
+ present for compatibility with existing software when
+ "arm,psci" is later in the compatible list.
+
+ * "arm,psci-1.0" : For implementations complying to PSCI 1.0.
+ PSCI 1.0 is backward compatible with PSCI 0.2 with
+ minor specification updates, as defined in the PSCI
+ specification[2].
- method : The method of calling the PSCI firmware. Permitted
values are:
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
deleted file mode 100644
index 6b42fda..0000000
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Rockchip SRAM for pmu:
-------------------------------
-
-The sram of pmu is used to store the function of resume from maskrom(the 1st
-level loader). This is a common use of the "pmu-sram" because it keeps power
-even in low power states in the system.
-
-Required node properties:
-- compatible : should be "rockchip,rk3288-pmu-sram"
-- reg : physical base address and the size of the registers window
-
-Example:
- sram@ff720000 {
- compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
- reg = <0xff720000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
deleted file mode 100644
index d9416fb..0000000
--- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Rockchip SRAM for smp bringup:
-------------------------------
-
-Rockchip's smp-capable SoCs use the first part of the sram for the bringup
-of the cores. Once the core gets powered up it executes the code that is
-residing at the very beginning of the sram.
-
-Therefore a reserved section sub-node has to be added to the mmio-sram
-declaration.
-
-Required sub-node properties:
-- compatible : should be "rockchip,rk3066-smp-sram"
-
-The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sram.txt
-
-Example:
-
- sram: sram@10080000 {
- compatible = "mmio-sram";
- reg = <0x10080000 0x10000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- smp-sram@10080000 {
- compatible = "rockchip,rk3066-smp-sram";
- reg = <0x10080000 0x50>;
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
new file mode 100644
index 0000000..e31303f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/secure.txt
@@ -0,0 +1,53 @@
+* ARM Secure world bindings
+
+ARM CPUs with TrustZone support have two distinct address spaces,
+"Normal" and "Secure". Most devicetree consumers (including the Linux
+kernel) are not TrustZone aware and run entirely in either the Normal
+world or the Secure world. However some devicetree consumers are
+TrustZone aware and need to be able to determine whether devices are
+visible only in the Secure address space, only in the Normal address
+space, or visible in both. (One example of that situation would be a
+virtual machine which boots Secure firmware and wants to tell the
+firmware about the layout of the machine via devicetree.)
+
+The general principle of the naming scheme for Secure world bindings
+is that any property that needs a different value in the Secure world
+can be supported by prefixing the property name with "secure-". So for
+instance "secure-foo" would override "foo". For property names with
+a vendor prefix, the Secure variant of "vendor,foo" would be
+"vendor,secure-foo". If there is no "secure-" property then the Secure
+world value is the same as specified for the Normal world by the
+non-prefixed property. However, only the properties listed below may
+validly have "secure-" versions; this list will be enlarged on a
+case-by-case basis.
+
+Defining the bindings in this way means that a device tree which has
+been annotated to indicate the presence of Secure-only devices can
+still be processed unmodified by existing Non-secure software (and in
+particular by the kernel).
+
+Note that it is still valid for bindings intended for purely Secure
+world consumers (like kernels that run entirely in Secure) to simply
+describe the view of Secure world using the standard bindings. These
+secure- bindings only need to be used where both the Secure and Normal
+world views need to be described in a single device tree.
+
+Valid Secure world properties:
+
+- secure-status : specifies whether the device is present and usable
+ in the secure world. The combination of this with "status" allows
+ the various possible combinations of device visibility to be
+ specified. If "secure-status" is not specified it defaults to the
+ same value as "status"; if "status" is not specified either then
+ both default to "okay". This means the following combinations are
+ possible:
+
+ /* Neither specified: default to visible in both S and NS */
+ secure-status = "okay"; /* visible in both */
+ status = "okay"; /* visible in both */
+ status = "okay"; secure-status = "okay"; /* visible in both */
+ secure-status = "disabled"; /* NS-only */
+ status = "okay"; secure-status = "disabled"; /* NS-only */
+ status = "disabled"; secure-status = "okay"; /* S-only */
+ status = "disabled"; /* disabled in both */
+ status = "disabled"; secure-status = "disabled"; /* disabled in both */
OpenPOWER on IntegriCloud