* [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
Cygnus SoC
Fixes: b51c05a331ff ("ARM: dts: add I2C device nodes for Broadcom Cygnus")
Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi bus")
Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 9fe4f5a..835a6f7 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -216,7 +216,7 @@
reg = <0x18008000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
@@ -245,7 +245,7 @@
reg = <0x1800b000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
--
2.1.4
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: cygnus: Fix PCIe controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix PCIe controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
Cygnus SoC
Fixes: cd590b50a936 ("ARM: dts: enable PCIe support for Cygnus")
Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi
bus")
Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
Fixes: f6b889358a82 ("ARM: dts: Enable MSI support for Broadcom Cygnus")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 835a6f7..2c4df2d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -256,7 +256,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <0>;
@@ -278,10 +278,10 @@
compatible = "brcm,iproc-msi";
msi-controller;
interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>,
- <GIC_SPI 97 IRQ_TYPE_NONE>,
- <GIC_SPI 98 IRQ_TYPE_NONE>,
- <GIC_SPI 99 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
};
};
@@ -291,7 +291,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <1>;
@@ -313,10 +313,10 @@
compatible = "brcm,iproc-msi";
msi-controller;
interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 102 IRQ_TYPE_NONE>,
- <GIC_SPI 103 IRQ_TYPE_NONE>,
- <GIC_SPI 104 IRQ_TYPE_NONE>,
- <GIC_SPI 105 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
};
};
--
2.1.4
^ permalink raw reply related
* [PATCH 3/5] ARM64: dts: ns2: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for
Broadcom NS2 SoC
Fixes: 7ac674e8df7a ("arm64: dts: Add I2C nodes for NS2")
Fixes: 63a913c157f5 ("arm64: dts: move ns2 into northstar2 directory")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 4a2a6af..c0e4896 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -566,7 +566,7 @@
reg = <0x66080000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 394 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 394 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
@@ -594,7 +594,7 @@
reg = <0x660b0000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 395 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
--
2.1.4
^ permalink raw reply related
* [PATCH 4/5] ARM64: dts: ns2: Fix PCIe controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix PCIe controller interrupt to use IRQ_TYPE_LEVEL_HIGH for
Broadcom NS2 SoC
Fixes: fd5e5dd56a2f ("arm64: dts: Add PCIe0 and PCIe4 DT nodes for NS2")
Fixes: 63a913c157f5 ("arm64: dts: move ns2 into northstar2 directory")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index c0e4896..4057197 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -118,7 +118,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 281 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 281 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <0>;
@@ -149,7 +149,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 305 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <4>;
--
2.1.4
^ permalink raw reply related
* [PATCH 5/5] ARM64: dts: Stingray: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for
Broadcom Stingray SoC
Fixes: 1256ea18875d ("arm64: dts: Add I2C DT nodes for Stingray SoC")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..b203152 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -409,7 +409,7 @@
reg = <0x000b0000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 177 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
@@ -453,7 +453,7 @@
reg = <0x000e0000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 178 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
--
2.1.4
^ permalink raw reply related
* [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 (RFC)
NOTE:
* As per ARM recommendations[2], and discussions in list[1] ARM
Cortex-A9/12/17 do not need additional steps in u-boot to enable the
OS level workarounds.
* This itself is'nt a complete solution and is based on recommendation
This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on
linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag).
* I think it is necessary on older SoCs without firmware support
(such as older OMAPs and AM*) to have kernel support mirroring what we do in
u-boot to support additional cores AND/OR low power states where contexts are
lost (assuming ACR states are'nt saved). just my 2 cents.
Few of the tests (with linux next-20180612):
AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15)
OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15)
OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8)
AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8)
Nishanth Menon (4):
ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
CVE-2017-5715
ARM: Introduce ability to enable invalidate of BTB with ICIALLU on
Cortex-A15 for CVE-2017-5715
ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of
BTB) to facilitate CVE_2017-5715 WA in OS
ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for
CVE-2017-5715
arch/arm/Kconfig | 9 +++++++++
arch/arm/cpu/armv7/start.S | 15 +++++++++++++--
arch/arm/mach-omap2/Kconfig | 3 +++
3 files changed, 25 insertions(+), 2 deletions(-)
[1] https://marc.info/?t=151639906500002&r=1&w=2
[2] https://developer.arm.com/support/security-update
[3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in:
https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2
[4]
https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
https://www.op-tee.org/security-advisories/
https://www.linaro.org/blog/meltdown-spectre/
--
2.15.1
^ permalink raw reply
* [PATCH 1/4] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/Kconfig | 5 +++++
arch/arm/cpu/armv7/start.S | 7 +++++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d53..9e32d5b43cb0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -108,6 +108,8 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_621766
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
+# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+
config ARM_ERRATA_430973
bool
@@ -177,6 +179,9 @@ config ARM_ERRATA_852423
config ARM_ERRATA_855873
bool
+config ARM_CORTEX_A8_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index c996525f861e..3beaf5a93d81 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -252,12 +252,15 @@ skip_errata_801819:
pop {r1-r5} @ Restore the cpu info - fall through
#endif
-#ifdef CONFIG_ARM_ERRATA_430973
+#if defined(CONFIG_ARM_ERRATA_430973) || defined (CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+ orr r0, r0, #(0x1 << 6) @ Set IBE bit always to enable OS WA
+#else
cmp r2, #0x21 @ Only on < r2p1
orrlt r0, r0, #(0x1 << 6) @ Set IBE bit
-
+#endif
push {r1-r5} @ Save the cpu info registers
bl v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
--
2.15.1
^ permalink raw reply related
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
be done unconditionally for Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
right locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/Kconfig | 4 ++++
arch/arm/cpu/armv7/start.S | 8 ++++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9e32d5b43cb0..98f58fd27696 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -109,6 +109,7 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
config ARM_ERRATA_430973
bool
@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
config ARM_CORTEX_A8_CVE_2017_5715
bool
+config ARM_CORTEX_A15_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 3beaf5a93d81..81edec01bf32 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -241,6 +241,14 @@ skip_errata_798870:
skip_errata_801819:
#endif
+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
+ push {r1-r5} @ Save the cpu info registers
+ bl v7_arch_cp15_set_acr
+ pop {r1-r5} @ Restore the cpu info - fall through
+#endif
+
#ifdef CONFIG_ARM_ERRATA_454179
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
--
2.15.1
^ permalink raw reply related
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
function to setup the bits, we are able to override the settings.
Without this enabled, Linux kernel reports:
CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
With this enabled, Linux kernel reports:
CPU0: Spectre v2: using ICIALLU workaround
NOTE: This by itself does not enable the workaround for CPU1 (on
OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 3bb1ecb58de0..77820cc8d1e4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -53,6 +53,7 @@ config OMAP54XX
bool "OMAP54XX SoC"
select ARM_ERRATA_798870
select SYS_THUMB_BUILD
+ select ARM_CORTEX_A15_CVE_2017_5715
imply NAND_OMAP_ELM
imply NAND_OMAP_GPMC
imply SPL_DISPLAY_PRINT
--
2.15.1
^ permalink raw reply related
* [PATCH 4/4] ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
Enable CVE-2017-5715 option to set the IBE bit. This enables kernel
workarounds necessary for the said CVE.
With this enabled, Linux reports:
CPU0: Spectre v2: using BPIALL workaround
This workaround may need to be re-applied in OS environment around low
power transition resume states where context of ACR would be lost (off-mode
etc).
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 77820cc8d1e4..f4babc8d2600 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -10,6 +10,7 @@ config OMAP34XX
select ARM_ERRATA_454179
select ARM_ERRATA_621766
select ARM_ERRATA_725233
+ select ARM_CORTEX_A8_CVE_2017_5715
select USE_TINY_PRINTF
imply NAND_OMAP_GPMC
imply SPL_EXT_SUPPORT
@@ -116,6 +117,7 @@ config AM43XX
config AM33XX
bool "AM33XX SoC"
select SPECIFY_CONSOLE_INDEX
+ select ARM_CORTEX_A8_CVE_2017_5715
imply NAND_OMAP_ELM
imply NAND_OMAP_GPMC
imply SPL_NAND_AM33XX_BCH
--
2.15.1
^ permalink raw reply related
* [RFC V2 3/3] perf: qcom: Add Falkor CPU PMU IMPLEMENTATION DEFINED event support
From: Agustin Vega-Frias @ 2018-06-12 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612144055.m2h26n64spfm6k6o@lakrids.cambridge.arm.com>
Hi Mark,
On 2018-06-12 10:40, Mark Rutland wrote:
> Hi,
>
> On Thu, Jun 07, 2018 at 09:56:48AM -0400, Agustin Vega-Frias wrote:
>> Selection of these events can be envisioned as indexing them from
>> a 3D matrix:
>> - the first index selects a Region Event Selection Register
>> (PMRESRx_EL0)
>> - the second index selects a group from which only one event at a time
>> can be selected
>> - the third index selects the event
>>
>> The event is encoded into perf_event_attr.config as 0xPRCCG, where:
>> P [config:16 ] = prefix (flag that indicates a matrix-based
>> event)
>> R [config:12-15] = register (specifies the PMRESRx_EL0 instance)
>> G [config:0-3 ] = group (specifies the event group)
>> CC [config:4-11 ] = code (specifies the event)
>>
>> Events with the P flag set to zero are treated as common PMUv3 events
>> and are directly programmed into PMXEVTYPERx_EL0.
>>
>> The first two indexes are set combining the RESR and group number with
>> a base number and writing it into the architected PMXEVTYPER_EL0
>> register.
>> The third index is set by writing the code into the bits corresponding
>> with the group into the appropriate IMPLEMENTATION DEFINED PMRESRx_EL0
>> register.
>
> When are the IMP DEF registers accessible at EL0? Are those goverend by
> the same controls as the architected registers?
No, there is a separate IMP DEF register to control access.
>
> [...]
>
>> +/*
>> + * Qualcomm Technologies CPU PMU IMPLEMENTATION DEFINED extensions
>> support
>> + *
>> + * Current extensions supported:
>> + *
>> + * - Matrix-based microarchitectural events support
>> + *
>> + * Selection of these events can be envisioned as indexing them
>> from
>> + * a 3D matrix:
>> + * - the first index selects a Region Event Selection Register
>> (PMRESRx_EL0)
>> + * - the second index selects a group from which only one event at
>> a time
>> + * can be selected
>> + * - the third index selects the event
>> + *
>> + * The event is encoded into perf_event_attr.config as 0xPRCCG,
>> where:
>> + * P [config:16 ] = prefix (flag that indicates a
>> matrix-based event)
>> + * R [config:12-15] = register (specifies the PMRESRx_EL0
>> instance)
>> + * G [config:0-3 ] = group (specifies the event group)
>> + * CC [config:4-11 ] = code (specifies the event)
>> + *
>> + * Events with the P flag set to zero are treated as common PMUv3
>> events
>> + * and are directly programmed into PMXEVTYPERx_EL0.
>
> When PMUv3 is given a raw event code, the config fields should be the
> PMU event number, and this conflicts with RESERVED encodings.
>
> I'd rather we used a separate field for the QC extension events. e.g.
> turn config1 into a flags field, and move the P flag there.
>
> We *should* add code to sanity check those fields are zero in the PMUv3
> driver, even though it's a potential ABI break to start now.
I should have stated clearly that in this case the event code is
directly
programmed into PMXEVTYPERx_EL0.evtCount, not by this code, but by the
PMUv3
code, which will do the masking and ensure reserved bits are not
touched.
IOW, that case is no different from the raw event or a common event
case.
I would prefer to keep the flag in config because it allows the use of
raw code encodings to access these events more easily, and given that
the flag is never propagated to any register I believe it is safe.
>
>> + *
>> + * The first two indexes are set combining the RESR and group
>> number with
>> + * a base number and writing it into the architected PMXEVTYPER_EL0
>> register.
>> + * The third index is set by writing the code into the bits
>> corresponding
>> + * with the group into the appropriate IMPLEMENTATION DEFINED
>> PMRESRx_EL0
>> + * register.
>> + */
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/perf/arm_pmu.h>
>
> You'll also need:
>
> #include <linux/bitops.h>
> #include <linux/device.h>
> #include <linux/perf_event.h>
> #include <linux/printk.h>
> #include <linux/types.h>
>
> #include <asm/barrier.h>
> #include <asm/sysreg.h>
>
Will do.
>> +
>> +#define pmresr0_el0 sys_reg(3, 5, 11, 3, 0)
>> +#define pmresr1_el0 sys_reg(3, 5, 11, 3, 2)
>> +#define pmresr2_el0 sys_reg(3, 5, 11, 3, 4)
>> +#define pmxevcntcr_el0 sys_reg(3, 5, 11, 0, 3)
>> +
>> +#define QC_EVT_PFX_SHIFT 16
>> +#define QC_EVT_REG_SHIFT 12
>> +#define QC_EVT_CODE_SHIFT 4
>> +#define QC_EVT_GRP_SHIFT 0
>> +#define QC_EVT_PFX_MASK GENMASK(QC_EVT_PFX_SHIFT,
>> QC_EVT_PFX_SHIFT)
>> +#define QC_EVT_REG_MASK GENMASK(QC_EVT_REG_SHIFT + 3,
>> QC_EVT_REG_SHIFT)
>> +#define QC_EVT_CODE_MASK GENMASK(QC_EVT_CODE_SHIFT + 7,
>> QC_EVT_CODE_SHIFT)
>> +#define QC_EVT_GRP_MASK GENMASK(QC_EVT_GRP_SHIFT + 3,
>> QC_EVT_GRP_SHIFT)
>> +#define QC_EVT_PRG_MASK (QC_EVT_PFX_MASK | QC_EVT_REG_MASK |
>> QC_EVT_GRP_MASK)
>> +#define QC_EVT_PRG(event) ((event) & QC_EVT_PRG_MASK)
>> +#define QC_EVT_REG(event) (((event) & QC_EVT_REG_MASK) >>
>> QC_EVT_REG_SHIFT)
>> +#define QC_EVT_CODE(event) (((event) & QC_EVT_CODE_MASK) >>
>> QC_EVT_CODE_SHIFT)
>> +#define QC_EVT_GROUP(event) (((event) & QC_EVT_GRP_MASK) >>
>> QC_EVT_GRP_SHIFT)
>> +
>> +#define QC_MAX_GROUP 7
>> +#define QC_MAX_RESR 2
>> +#define QC_BITS_PER_GROUP 8
>> +#define QC_RESR_ENABLE BIT_ULL(63)
>> +#define QC_RESR_EVT_BASE 0xd8
>> +
>> +static struct arm_pmu *def_ops;
>> +
>> +static inline void falkor_write_pmresr(u64 reg, u64 val)
>> +{
>> + if (reg == 0)
>> + write_sysreg_s(val, pmresr0_el0);
>> + else if (reg == 1)
>> + write_sysreg_s(val, pmresr1_el0);
>> + else
>> + write_sysreg_s(val, pmresr2_el0);
>> +}
>> +
>> +static inline u64 falkor_read_pmresr(u64 reg)
>> +{
>> + return (reg == 0 ? read_sysreg_s(pmresr0_el0) :
>> + reg == 1 ? read_sysreg_s(pmresr1_el0) :
>> + read_sysreg_s(pmresr2_el0));
>> +}
>
> Please use switch statements for both of these.
Will do.
>
>> +
>> +static void falkor_set_resr(u64 reg, u64 group, u64 code)
>> +{
>> + u64 shift = group * QC_BITS_PER_GROUP;
>> + u64 mask = GENMASK(shift + QC_BITS_PER_GROUP - 1, shift);
>> + u64 val;
>> +
>> + val = falkor_read_pmresr(reg) & ~mask;
>> + val |= (code << shift);
>> + val |= QC_RESR_ENABLE;
>> + falkor_write_pmresr(reg, val);
>> +}
>> +
>> +static void falkor_clear_resr(u64 reg, u64 group)
>> +{
>> + u32 shift = group * QC_BITS_PER_GROUP;
>> + u64 mask = GENMASK(shift + QC_BITS_PER_GROUP - 1, shift);
>> + u64 val = falkor_read_pmresr(reg) & ~mask;
>> +
>> + falkor_write_pmresr(reg, val == QC_RESR_ENABLE ? 0 : val);
>> +}
>> +
>> +/*
>> + * Check if e1 and e2 conflict with each other
>> + *
>> + * e1 is a matrix-based microarchitectural event we are checking
>> against e2.
>> + * A conflict exists if the events use the same reg, group, and a
>> different
>> + * code. Events with the same code are allowed because they could be
>> using
>> + * different filters (e.g. one to count user space and the other to
>> count
>> + * kernel space events).
>> + */
>
> What problem occurs when there's a conflict?
No real problem at the hardware level since only one event can be
selected
at a time from a group, but if this is not detected and dealt with the
user
will receive incorrect information.
Selection is done through the PMRESRx_EL0 registers, these are 64bit
registers
with an enable bit (63) one 7-bit field for group 7 (62-56) event
selection, and
seven 8-bit fields for group 6 to group 0 event selection. So it is
physically
impossible to select two events.
>
> Does the filter matter at all? When happens if I open two identical
> events, both counting the same reg, group, and code, with the same
> filter?
That is possible and allowed, similar to counting the same common event
in two configurable counters. Only problem is wasting a counter
resource.
>
>> +static inline int events_conflict(struct perf_event *e1, struct
>> perf_event *e2)
>> +{
>> + if ((e1 != e2) &&
>> + (e1->pmu == e2->pmu) &&
>> + (QC_EVT_PRG(e1->attr.config) == QC_EVT_PRG(e2->attr.config)) &&
>> + (QC_EVT_CODE(e1->attr.config) != QC_EVT_CODE(e2->attr.config)))
>> {
>> + pr_debug_ratelimited(
>> + "Group exclusion: conflicting events %llx %llx\n",
>> + e1->attr.config,
>> + e2->attr.config);
>> + return 1;
>> + }
>> + return 0;
>> +}
>
> This would be easier to read as a series of tests:
>
> static inline bool events_conflict(struct perf_event *new,
> struct perf_event *other)
> {
> /* own group leader */
> if (new == other)
> return false;
>
> /* software events can't conflict */
> if (is_sw_event(other))
> return false;
>
> /* No conflict if using different reg or group */
> if (QC_EVT_PRG(new->attr.config) != QC_EVT_PRG(other->attr.config))
> return false;
>
> /* Same reg and group is fine so long as code matches */
> if (QC_EVT_CODE(new->attr.config) == QC_EVT_PRG(other->attr.config)
> return false;
>
>
> pr_debug_ratelimited("Group exclusion: conflicting events %llx
> %llx\n",
> new->attr.config, other->attr.config);
>
> return true;
>
> }
Will rework.
>
>> +
>> +/*
>> + * Check if the given event is valid for the PMU and if so return the
>> value
>> + * that can be used in PMXEVTYPER_EL0 to select the event
>> + */
>> +static int falkor_map_event(struct perf_event *event)
>> +{
>> + u64 reg = QC_EVT_REG(event->attr.config);
>> + u64 group = QC_EVT_GROUP(event->attr.config);
>> + struct perf_event *leader;
>> + struct perf_event *sibling;
>> +
>> + if (!(event->attr.config & QC_EVT_PFX_MASK))
>> + /* Common PMUv3 event, forward to the original op */
>> + return def_ops->map_event(event);
>
> The QC event codes should only be used when either:
>
> * event->attr.type is PERF_TYPE_RAW, or:
>
> * event->pmu.type is this PMU's dynamic type
>
> ... otherwise this will accept events meant for other PMUs, and/or
> override conflicting events in other type namespaces (e.g.
> PERF_EVENT_TYPE_HW, PERF_EVENT_TYPE_CACHE).
>
Will add a check.
>> +
>> + /* Is it a valid matrix event? */
>> + if ((group > QC_MAX_GROUP) || (reg > QC_MAX_RESR))
>> + return -ENOENT;
>> +
>> + /* If part of an event group, check if the event can be put in it */
>> +
>> + leader = event->group_leader;
>> + if (events_conflict(event, leader))
>> + return -ENOENT;
>> +
>> + for_each_sibling_event(sibling, leader)
>> + if (events_conflict(event, sibling))
>> + return -ENOENT;
>> +
>> + return QC_RESR_EVT_BASE + reg*8 + group;
>
> Nit: spacing around binary operators please.
>
>> +}
>> +
>> +/*
>> + * Find a slot for the event on the current CPU
>> + */
>> +static int falkor_get_event_idx(struct pmu_hw_events *cpuc, struct
>> perf_event *event)
>> +{
>> + int idx;
>> +
>> + if (!!(event->attr.config & QC_EVT_PFX_MASK))
>
> The '!!' isn't required.
>
>> + /* Matrix event, check for conflicts with existing events */
>> + for_each_set_bit(idx, cpuc->used_mask, ARMPMU_MAX_HWEVENTS)
>> + if (cpuc->events[idx] &&
>> + events_conflict(event, cpuc->events[idx]))
>> + return -ENOENT;
>> +
>> + /* Let the original op handle the rest */
>> + idx = def_ops->get_event_idx(cpuc, event);
>
> Same comments as for falkor_map_event().
>
>> +
>> + /*
>> + * This is called for actually allocating the events, but also with
>> + * a dummy pmu_hw_events when validating groups, for that case we
>> + * need to ensure that cpuc->events[idx] is NULL so we don't use
>> + * an uninitialized pointer. Conflicts for matrix events in groups
>> + * are checked during event mapping anyway (see falkor_event_map).
>> + */
>> + cpuc->events[idx] = NULL;
>> +
>> + return idx;
>> +}
>> +
>> +/*
>> + * Reset the PMU
>> + */
>> +static void falkor_reset(void *info)
>> +{
>> + struct arm_pmu *pmu = (struct arm_pmu *)info;
>> + u32 i, ctrs = pmu->num_events;
>> +
>> + /* PMRESRx_EL0 regs are unknown at reset, except for the EN field */
>> + for (i = 0; i <= QC_MAX_RESR; i++)
>> + falkor_write_pmresr(i, 0);
>> +
>> + /* PMXEVCNTCRx_EL0 regs are unknown at reset */
>> + for (i = 0; i <= ctrs; i++) {
>> + write_sysreg(i, pmselr_el0);
>> + isb();
>> + write_sysreg_s(0, pmxevcntcr_el0);
>> + }
>> +
>> + /* Let the original op handle the rest */
>> + def_ops->reset(info);
>> +}
>> +
>> +/*
>> + * Enable the given event
>> + */
>> +static void falkor_enable(struct perf_event *event)
>> +{
>> + if (!!(event->attr.config & QC_EVT_PFX_MASK)) {
>
> The '!!' isn't required.
>
>> + /* Matrix event, program the appropriate PMRESRx_EL0 */
>> + struct arm_pmu *pmu = to_arm_pmu(event->pmu);
>> + struct pmu_hw_events *events = this_cpu_ptr(pmu->hw_events);
>> + u64 reg = QC_EVT_REG(event->attr.config);
>> + u64 code = QC_EVT_CODE(event->attr.config);
>> + u64 group = QC_EVT_GROUP(event->attr.config);
>> + unsigned long flags;
>> +
>> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
>> + falkor_set_resr(reg, group, code);
>> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>
> Why is the spinlock required?
>
> AFACIT this should only ever be called in contexts where IRQs are
> disabled already.
>
falkor_set_resr is a read-modify-write operation. The PMUv3 code uses
the spinlock to protect the counter selection too
(armv8pmu_enable_event).
I believe this is to deal with event rotation which can potentially
be active when we are creating new events.
>> + }
>> +
>> + /* Let the original op handle the rest */
>> + def_ops->enable(event);
>> +}
>> +
>> +/*
>> + * Disable the given event
>> + */
>> +static void falkor_disable(struct perf_event *event)
>> +{
>> + /* Use the original op to disable the counter and interrupt */
>> + def_ops->enable(event);
>> +
>> + if (!!(event->attr.config & QC_EVT_PFX_MASK)) {
>> + /* Matrix event, de-program the appropriate PMRESRx_EL0 */
>> + struct arm_pmu *pmu = to_arm_pmu(event->pmu);
>> + struct pmu_hw_events *events = this_cpu_ptr(pmu->hw_events);
>> + u64 reg = QC_EVT_REG(event->attr.config);
>> + u64 group = QC_EVT_GROUP(event->attr.config);
>> + unsigned long flags;
>> +
>> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
>> + falkor_clear_resr(reg, group);
>> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>> + }
>> +}
>
> Same comments as with falkor_enable().
>
>> +
>> +PMU_FORMAT_ATTR(event, "config:0-15");
>> +PMU_FORMAT_ATTR(prefix, "config:16");
>> +PMU_FORMAT_ATTR(reg, "config:12-15");
>> +PMU_FORMAT_ATTR(code, "config:4-11");
>> +PMU_FORMAT_ATTR(group, "config:0-3");
>
> What sort of events are available? Do you plan to add anything to the
> userspace event database in tools/perf/pmu-events/ ?
>
Yes, we are still doing some internal work to see what we can put in
the driver or as JSON events.
>> +
>> +static struct attribute *falkor_pmu_formats[] = {
>> + &format_attr_event.attr,
>> + &format_attr_prefix.attr,
>> + &format_attr_reg.attr,
>> + &format_attr_code.attr,
>> + &format_attr_group.attr,
>> + NULL,
>> +};
>> +
>> +static struct attribute_group falkor_pmu_format_attr_group = {
>> + .name = "format",
>> + .attrs = falkor_pmu_formats,
>> +};
>> +
>> +static int qcom_falkor_pmu_init(struct arm_pmu *pmu, struct device
>> *dev)
>> +{
>> + /* Save base arm_pmu so we can invoke its ops when appropriate */
>> + def_ops = devm_kmemdup(dev, pmu, sizeof(*def_ops), GFP_KERNEL);
>> + if (!def_ops) {
>> + pr_warn("Failed to allocate arm_pmu for QCOM extensions");
>> + return -ENODEV;
>> + }
>> +
>> + pmu->name = "qcom_pmuv3";
>
> All the other CPU PMUs on an ARM ACPI system will have an index suffix,
> e.g. "armv8_pmuv3_0". I can see why we might want to change the name to
> indicate the QC extensions, but I think we should keep the existing
> pattern, with a '_0' suffix here.
This overrides the name before the suffix is added, so the PMU name will
be
qcom_pmuv3_0 for Centriq 2400 which has only Falkor CPUs.
>
>> +
>> + /* Override the necessary ops */
>> + pmu->map_event = falkor_map_event;
>> + pmu->get_event_idx = falkor_get_event_idx;
>> + pmu->reset = falkor_reset;
>> + pmu->enable = falkor_enable;
>> + pmu->disable = falkor_disable;
>
> I'm somewhat concerned by hooking into the existing PMU code at this
> level, but I don't currently have a better suggestion.
>
IMO this is no different from other PMUs implemented on top of the
arm_pmu
framework. The difference is of course that I'm calling back into the
base
PMUv3 ops, but the alternative would be to duplicate, which is what we
want
to avoid.
Thanks for the detailed feedback, I'll try to submit V3 before week's
end.
Let me know if you have any concerns about my replies above.
Thanks,
Agust?n
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Rob Herring @ 2018-06-12 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527858967-16047-7-git-send-email-suzuki.poulose@arm.com>
On Fri, Jun 01, 2018 at 02:16:05PM +0100, Suzuki K Poulose wrote:
> The coresight drivers relied on default bindings for graph
> in DT, while reusing the "reg" field of the "ports" to indicate
> the actual hardware port number for the connections. However,
> with the rules getting stricter w.r.t to the address mismatch
> with the label, it is no longer possible to use the port address
> field for the hardware port number. Hence, we add an explicit
> property to denote the hardware port number, "coresight,hwid"
> which must be specified for each "endpoint".
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> .../devicetree/bindings/arm/coresight.txt | 26 +++++++++---
> drivers/hwtracing/coresight/of_coresight.c | 46 ++++++++++++++++------
> 2 files changed, 54 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index bd36e40..385581a 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -104,7 +104,11 @@ properties to uniquely identify the connection details.
> "slave-mode"
>
> * Hardware Port number at the component:
> - - The hardware port number is assumed to be the address of the "port" component.
> + - (Obsolete) The hardware port number is assumed to be the address of the "port" component.
> + - Each "endpoint" must define the hardware port of the local end of the
> + connection using the following property:
> + "coresight,hwid" - 32bit integer, hardware port number at the local end.
"coresight" is not a vendor and properties are in the form
[<vendor>,]<prop-name>.
> +
>
>
> Example:
> @@ -120,6 +124,7 @@ Example:
> etb_in_port: endpoint at 0 {
There shouldn't be a unit address here because there is no reg property.
> slave-mode;
> remote-endpoint = <&replicator_out_port0>;
> + coresight,hwid = <0>;
It doesn't make sense for these to be in the endpoint. If you had
multiple endpoints, then you would have to duplicate it. "ports" are
a single data stream. "endpoints" are connections to that stream. So if
you have a muxed (input) or fanout/1-to-many (output) connection, then
you have multiple endpoints.
The same applied to the slave-mode property, but that ship has sailed.
No reason to continue that though.
> };
> };
> };
> @@ -134,6 +139,7 @@ Example:
> tpiu_in_port: endpoint at 0 {
> slave-mode;
> remote-endpoint = <&replicator_out_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -154,6 +160,7 @@ Example:
> reg = <0>;
> replicator_out_port0: endpoint {
> remote-endpoint = <&etb_in_port>;
> + coresight,hwid = <0>;
> };
> };
>
> @@ -161,15 +168,17 @@ Example:
> reg = <1>;
> replicator_out_port1: endpoint {
> remote-endpoint = <&tpiu_in_port>;
> + coresight,hwid = <1>;
> };
> };
>
> /* replicator input port */
> port at 2 {
> - reg = <0>;
> + reg = <1>;
This will still get flagged as an error. reg must be 2 here.
Rob
^ permalink raw reply
* [PATCH 1/3] dt-bindings: pinctrl: Add gpio interrupt bindings for Actions S900 SoC
From: Rob Herring @ 2018-06-12 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602165415.30956-2-manivannan.sadhasivam@linaro.org>
On Sat, Jun 02, 2018 at 10:24:13PM +0530, Manivannan Sadhasivam wrote:
> Add gpio interrupt bindings for Actions Semi S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/pinctrl/actions,s900-pinctrl.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
From: Rob Herring @ 2018-06-12 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060125.9518-2-nm@ti.com>
On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of this SoC are:
> * Quad ARMv8 A53 cores split over two clusters
> * GICv3 compliant GIC500
> * Configurable L3 Cache and IO-coherent architecture
> * Dual lock-step capable R5F uC for safety-critical applications
> * High data throughput capable distributed DMA architecture under NAVSS
> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
> PRUs and dual RTUs
> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
> * Centralized System Controller for Security, Power, and Resource
> management.
> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
> * Flash subystem with OSPI and Hyperbus interfaces
> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
> GPIO
>
> See AM65x Technical Reference Manual (SPRUID7, April 2018)
> for further details: http://www.ti.com/lit/pdf/spruid7
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
> MAINTAINERS | 7 ++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
> new file mode 100644
> index 000000000000..cbabb1b89f6f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
> @@ -0,0 +1,33 @@
> +Texas Instruments K3 Multicore SoC architecture device tree bindings
> +--------------------------------------------------------------------
> +
> +Boards based on K3 Multicore SoC architecture shall have the following property:
> +- compatible: Every hardware block introduced in K3 Multicore SoC
> + architecture shall be of the form:
> + "ti,XXX-YYY", where:
> + 'XXX' represents the specific SoC part for which the support is added.
> + 'YYY' represents the corresponding peripheral in SoC being supported.
No need to explain standard DT convention here. (But I don't think we
have this convention documented anywhere, so patches welcome. :))
> +
> + NOTE: Generic devices such as GIC or legacy devices shall use the specified
> + compatible for those devices.
> +
> + Example:
> + compatible = "ti,am654-i2c";
> +
> +SoCs
> +-------------------------------------------
> +
> +Each device tree root node must specify which exact SoC in K3 Multicore SoC
> +architecture it uses, using one of the following compatible values:
> +
> +- AM654
> + compatible = "ti,am654";
> +
> +Boards
> +-------------------------------------------
> +
> +In addition, each device tree root node must specify which one or more
> +of the following board-specific compatible values:
> +
> +- AM654 EVM
> + compatible = "ti,am654-evm", "ti,am654";
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f39a8de1bbd7..cfb35b252ac7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2086,6 +2086,13 @@ L: linux-kernel at vger.kernel.org
> S: Maintained
> F: drivers/memory/*emif*
>
> +ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
> +M: Tero Kristo <t-kristo@ti.com>
> +M: Nishanth Menon <nm@ti.com>
> +L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S: Supported
> +F: Documentation/devicetree/bindings/arm/ti/k3.txt
> +
> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
> M: Santosh Shilimkar <ssantosh@kernel.org>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> --
> 2.15.1
>
^ permalink raw reply
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
From: Rob Herring @ 2018-06-12 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060125.9518-4-nm@ti.com>
On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
> AM654 uses a UART controller that is compatible (partially) with
> existing 8250 UART, however, has a few differences with respect to DMA
> support and control paths. Introduce a base definition that allows us
> to build up the differences in follow on patches.
>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Vignesh R <vigneshr@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
> drivers/tty/serial/8250/8250_omap.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 4b0f05adb228..c35d5ece1156 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -1,6 +1,7 @@
> OMAP UART controller
>
> Required properties:
> +- compatible : should be "ti,am654-uart" for AM654 controllers
Not compatible with any existing TI 8250 UARTs?
> - compatible : should be "ti,omap2-uart" for OMAP2 controllers
> - compatible : should be "ti,omap3-uart" for OMAP3 controllers
> - compatible : should be "ti,omap4-uart" for OMAP4 controllers
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 1b337fee07ed..a019286f8bb6 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
> static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
>
> static const struct of_device_id omap8250_dt_ids[] = {
> + { .compatible = "ti,am654-uart" },
> { .compatible = "ti,omap2-uart" },
> { .compatible = "ti,omap3-uart" },
> { .compatible = "ti,omap4-uart", .data = &omap4_habit, },
> --
> 2.15.1
>
^ permalink raw reply
* [RFC PATCH 5/8] dt-bindings: mailbox: ti,message-manager: Add support for secure proxy threads
From: Rob Herring @ 2018-06-12 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605061629.4759-6-nm@ti.com>
On Tue, Jun 05, 2018 at 01:16:26AM -0500, Nishanth Menon wrote:
> Secure Proxy is another communication scheme in Texas Instrument's
> devices intended to provide an unique communication path from various
> processors in the System on Chip(SoC) to a central System Controller.
>
> Secure proxy is, in effect, an evolution of current generation Message
> Manager hardware block found in K2G devices. However the following
> changes have taken place:
>
> Secure Proxy instance exposes "threads" or "proxies" which is
> primary representation of "a" communication channel. Each thread is
> preconfigured by System controller configuration based on SoC usage
> requirements. Secure proxy by itself represents a single "queue" of
> communication but allows the proxies to be independently operated.
>
> Each Secure proxy thread can uniquely have their own error and threshold
> interrupts allowing for more fine control of IRQ handling.
>
> Provide an hardware description of the same for device tree
> representation.
>
> See AM65x Technical Reference Manual (SPRUID7, April 2018)
> for further details: http://www.ti.com/lit/pdf/spruid7
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> .../bindings/mailbox/ti,message-manager.txt | 58 +++++++++++++++++++---
> 1 file changed, 50 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> index ebf0e3710cee..de796e90cac6 100644
> --- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> @@ -7,22 +7,40 @@ manager is broken up into queues in different address regions that are called
> "proxies" - each instance is unidirectional and is instantiated at SoC
> integration level to indicate receive or transmit path.
>
> +This can also be used to describe Texas Instrument's Secure Proxy
> +controller that allows for individually configurable "threads" or
> +"proxies" which allow for independent communication scheme.
There seems to be very little re-use here. I think I would make this
its own doc.
Rob
^ permalink raw reply
* [PATCH] ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores
From: Nishanth Menon @ 2018-06-12 21:36 UTC (permalink / raw)
To: linux-arm-kernel
Call secure services to enable ACTLR[0] (Enable invalidates of BTB with
ICIALLU) when branch hardening is enabled for kernel.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Based on: next-20180612 +
Uboot series posted: https://marc.info/?l=u-boot&m=152883522011042&w=2
With Just u-boot changes alone: OMAP5-uevm: https://pastebin.ubuntu.com/p/9yDM22bJ6n/
with kernel changes added on: https://pastebin.ubuntu.com/p/gXPBGGYRPX/
arch/arm/mach-omap2/omap-smp.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 69df3620eca5..28fc80ea675b 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -109,6 +109,32 @@ void omap5_erratum_workaround_801819(void)
static inline void omap5_erratum_workaround_801819(void) { }
#endif
+#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+static void omap5_harden_predictor(void)
+{
+ u32 acr, acr_mask;
+
+ asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
+
+ /*
+ * BIT(0) - Disables streaming. All write-allocate lines allocate in
+ */
+ acr_mask = BIT(0);
+
+ /* do we already have it done.. if yes, skip expensive smc */
+ if ((acr & acr_mask) == acr_mask)
+ return;
+
+ acr |= acr_mask;
+ omap_smc1(OMAP5_DRA7_MON_SET_ACR_INDEX, acr);
+
+ pr_debug("%s: ARM ACR setup for CVE_2017_5715 applied on CPU%d\n",
+ __func__, smp_processor_id());
+}
+#else
+static inline void omap5_harden_predictor(void) { }
+#endif
+
static void omap4_secondary_init(unsigned int cpu)
{
/*
@@ -131,6 +157,8 @@ static void omap4_secondary_init(unsigned int cpu)
set_cntfreq();
/* Configure ACR to disable streaming WA for 801819 */
omap5_erratum_workaround_801819();
+ /* Enable ACR to allow for ICUALLU workaround */
+ omap5_harden_predictor();
}
/*
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 1/3] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Rob Herring @ 2018-06-12 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605062640.3356-2-nm@ti.com>
On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TISCI) permits the
> ability for Operating Systems to running in virtual machines to be
...for OSs running in virtual...
> able to independently communicate with the firmware without the need
> going through an hypervisor.
>
> The "host-id" in effect is the hardware representation of the
> host (example: VMs locked to a core) as identified to the System
> Controller.
So the hypervisor will fill in host-id's for each VM instance?
>
> This is introduced as an optional parameter to maintain consistency
> with legacy device tree blobs.
>
> We call this with a vendor prefix to prevent any possible confusion
> with SCSI ID (m68k) kernel option.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> index 31f5f9a104cc..b56a02c10ae6 100644
> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> @@ -45,11 +45,15 @@ Optional Properties:
> 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
> +- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
> + for identification of host processing entities such as virtual
> + machines
>
> Example (K2G):
> -------------
> pmmc: pmmc {
> compatible = "ti,k2g-sci";
> + ti,host-id = <2>;
> mbox-names = "rx", "tx";
> mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
> <&msgmgr &msgmgr_proxy_pmmc_tx>;
> --
> 2.15.1
>
^ permalink raw reply
* [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
From: Russell King - ARM Linux @ 2018-06-12 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGo_u6qyf1Z+zSG-17TYRDPzG8V_0_-nk1F15HB4tPyT9rbUYQ@mail.gmail.com>
On Tue, Jun 12, 2018 at 02:13:38PM -0500, Nishanth Menon wrote:
> On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon <nm@ti.com> wrote:
> >> Hi Folks,
> >>
> >> This is a follow through on the discussion we have had in [1].
> >> This itself is'nt a complete solution and is based on recommendation
> >> This from Arm[2] for variant 2 CVE-2017-5715
> >>
> >> The Linux kernel discussions are spread out in [3], ATF and OPTEE
> >> status are available in [4].
> >>
> >> This is just an RFC series (build tested at this point) to check if
> >> the direction is fine and should follow the final solution once kernel
> >> patches get to upstream, IMHO.
> >>
> >> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
> >> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> >> OS level workarounds.
> >>
> >> Nishanth Menon (2):
> >> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> >> CVE-2017-5715
> >> ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
> >> CVE-2017-5715
> >
>
> I started respinning the series, while there is definitely a use of
> implementing in u-boot,
> I am starting to wonder if we should also be doing this in kernel.
How does the kernel set the bit when the kernel is running in non-secure
mode, when the ACTLR is read-only in that mode?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/4] dt-bindings: arm: remove PMC bindings
From: Rob Herring @ 2018-06-12 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607084107.4461-2-alexandre.belloni@bootlin.com>
On Thu, Jun 07, 2018 at 10:41:04AM +0200, Alexandre Belloni wrote:
> The PMC bindings are fully described in
> Documentation/devicetree/bindings/clock/at91-clock.txt. Remove the
> duplicate and incomplete documentation.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> .../devicetree/bindings/arm/atmel-pmc.txt | 14 --------------
> 1 file changed, 14 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/atmel-pmc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/4] dt-bindings: clk: at91: Document all the PMC compatibles
From: Rob Herring @ 2018-06-12 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607084107.4461-3-alexandre.belloni@bootlin.com>
On Thu, Jun 07, 2018 at 10:41:05AM +0200, Alexandre Belloni wrote:
> Add missing PMC compatibles to the list of available compatibles.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> Documentation/devicetree/bindings/clock/at91-clock.txt | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612214049.GA17671@n2100.armlinux.org.uk>
On 21:40-20180612, Russell King - ARM Linux wrote:
[...]
> > I started respinning the series, while there is definitely a use of
> > implementing in u-boot,
> > I am starting to wonder if we should also be doing this in kernel.
>
> How does the kernel set the bit when the kernel is running in non-secure
> mode, when the ACTLR is read-only in that mode?
For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
it:
https://patchwork.kernel.org/patch/10461273/
This'd be similar in implementation to ARM erratum 801819 workaround
that needs two pieces (u-boot + kernel). I am not really worried about
OMAP5/DRA7 since they should'nt loose context in Low power modes.
Other SoCs need to be aware of the constraints.
/me wishes PSCI was a standard during ARMv7, but it was'nt... So
legacy v7 SoCs have implementations that are kind of different (even
smc calling conventions vary).
--
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
From: Nishanth Menon @ 2018-06-12 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612210519.GA17653@rob-hp-laptop>
On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
> > + architecture shall be of the form:
> > + "ti,XXX-YYY", where:
> > + 'XXX' represents the specific SoC part for which the support is added.
> > + 'YYY' represents the corresponding peripheral in SoC being supported.
>
> No need to explain standard DT convention here. (But I don't think we
> have this convention documented anywhere, so patches welcome. :))
>
Thanks. Will drop off from my series (will skip the generic dts
convention for now ;) ).
--
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
From: Nishanth Menon @ 2018-06-12 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612210640.GA20728@rob-hp-laptop>
On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > @@ -1,6 +1,7 @@
> > OMAP UART controller
> >
> > Required properties:
> > +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Base is compatible, however there are differences in DMA operation and
few additional bits. omap4-uart is sufficient for a basic PIO mode of
operation given initialization a bootloader might do for base console.
I will split the bindings off into it's own patch to keep the confusion
to a minimum and allowing serial driver change to go in independently.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH 5/8] dt-bindings: mailbox: ti,message-manager: Add support for secure proxy threads
From: Nishanth Menon @ 2018-06-12 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612211128.GA22038@rob-hp-laptop>
On 21:11-20180612, Rob Herring wrote:
[...]
> > diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > index ebf0e3710cee..de796e90cac6 100644
> > --- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > @@ -7,22 +7,40 @@ manager is broken up into queues in different address regions that are called
> > "proxies" - each instance is unidirectional and is instantiated at SoC
> > integration level to indicate receive or transmit path.
> >
> > +This can also be used to describe Texas Instrument's Secure Proxy
> > +controller that allows for individually configurable "threads" or
> > +"proxies" which allow for independent communication scheme.
>
> There seems to be very little re-use here. I think I would make this
> its own doc.
Agreed. will do the same in the formal series. Thanks.
--
Regards,
Nishanth Menon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox