* Re: [PATCH v11 00/27] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-06-17 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <850a0ec9-53aa-02a5-ecbd-e068b13b2764@ti.com>
Hi Sekhar,
On 05/22/2018 04:38 AM, Sekhar Nori wrote:
> Hi David,
>
> On Friday 18 May 2018 10:18 PM, David Lechner wrote:
>> This series converts mach-davinci to use the common clock framework.
>>
>> The series works like this, the first 3 patches fix some issues with the clock
>> drivers that have already been accepted into the mainline kernel.
>>
>> Then, starting with "ARM: davinci: pass clock as parameter to
>> davinci_timer_init()", we get the mach code ready for the switch by adding the
>> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
>> around the legacy clocks so that we can switch easily between the old and the
>> new.
>>
>> "ARM: davinci: switch to common clock framework" actually flips the switch
>> to start using the new clock drivers. Then the next 8 patches remove all
>> of the old clock code.
>>
>> The final four patches add device tree clock support to the one SoC that
>> supports it.
>>
>> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
>> board file).
>
> If you do end up sending a v12, you can leave out the mach-davinci
> portions unless there are any changes you need to make. I will pick them
> up from this series once the driver dependencies are merged.
>
> I do hope the drivers/clk/* changes can be merged from v4.18.
>
> Thanks,
> Sekhar
>
Are you going to pick up the arch patches from this series now that
the 4.18 merge window is closed?
All of the clk patches landed in 4.18.
^ permalink raw reply
* [PATCH 10/15] arm: dts: rk3288: Add missing cooling device properties for CPUs
From: Heiko Stuebner @ 2018-06-17 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11f16618dc965a7996976a2bca040cd87d1961d2.1527244201.git.viresh.kumar@linaro.org>
Am Freitag, 25. Mai 2018, 12:31:56 CEST schrieb Viresh Kumar:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
applied for 4.19, after adapting the patch to the opp-v2 conversion
I Cc'ed you on [for your reference].
Thanks
Heiko
^ permalink raw reply
* [PATCH 04/15] arm: dts: rk322x: Add missing cooling device properties for CPUs
From: Heiko Stuebner @ 2018-06-17 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <406021e33d541ca0318a6b15687084ca19fdd943.1527244201.git.viresh.kumar@linaro.org>
Am Freitag, 25. Mai 2018, 12:31:50 CEST schrieb Viresh Kumar:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
applied for 4.19
Thanks
Heiko
^ permalink raw reply
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Jonathan Neuschäfer @ 2018-06-17 14:31 UTC (permalink / raw)
To: linux-arm-kernel
Multiple binding documents have various forms of unbalanced quotation
marks. Fix them.
Signed-off-by: Jonathan Neusch?fer <j.neuschaefer@gmx.net>
---
Should I split this patch so that different parts can go through different trees?
---
.../devicetree/bindings/arm/samsung/samsung-boards.txt | 2 +-
.../devicetree/bindings/gpio/nintendo,hollywood-gpio.txt | 2 +-
Documentation/devicetree/bindings/input/touchscreen/hideep.txt | 2 +-
.../bindings/interrupt-controller/nvidia,tegra20-ictlr.txt | 2 +-
.../devicetree/bindings/interrupt-controller/st,stm32-exti.txt | 2 +-
Documentation/devicetree/bindings/mips/brcm/soc.txt | 2 +-
Documentation/devicetree/bindings/net/fsl-fman.txt | 2 +-
Documentation/devicetree/bindings/power/power_domain.txt | 2 +-
Documentation/devicetree/bindings/regulator/tps65090.txt | 2 +-
Documentation/devicetree/bindings/reset/st,sti-softreset.txt | 2 +-
Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt | 2 +-
Documentation/devicetree/bindings/sound/qcom,apq8096.txt | 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
index bdadc3da9556..6970f30a3770 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
@@ -66,7 +66,7 @@ Required root node properties:
- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
Octa board.
- "insignal,origen" - for Exynos4210-based Insignal Origen board.
- - "insignal,origen4412 - for Exynos4412-based Insignal Origen board.
+ - "insignal,origen4412" - for Exynos4412-based Insignal Origen board.
Optional nodes:
diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
index 20fc72d9e61e..45a61b462287 100644
--- a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
@@ -1,7 +1,7 @@
Nintendo Wii (Hollywood) GPIO controller
Required properties:
-- compatible: "nintendo,hollywood-gpio
+- compatible: "nintendo,hollywood-gpio"
- reg: Physical base address and length of the controller's registers.
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells: Should be <2>. The first cell is the pin number and the
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
index 121d9b7c79a2..1063c30d53f7 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
@@ -32,7 +32,7 @@ i2c at 00000000 {
reg = <0x6c>;
interrupt-parent = <&gpx1>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
- vdd-supply = <&ldo15_reg>";
+ vdd-supply = <&ldo15_reg>;
vid-supply = <&ldo18_reg>;
reset-gpios = <&gpx1 5 0>;
touchscreen-size-x = <1080>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
index 1099fe0788fa..f246ccbf8838 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
@@ -15,7 +15,7 @@ Required properties:
include "nvidia,tegra30-ictlr".
- reg : Specifies base physical address and size of the registers.
Each controller must be described separately (Tegra20 has 4 of them,
- whereas Tegra30 and later have 5"
+ whereas Tegra30 and later have 5).
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The value must be 3.
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
index 136bd612bd83..6a36bf66d932 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
@@ -12,7 +12,7 @@ Required properties:
specifier, shall be 2
- interrupts: interrupts references to primary interrupt controller
(only needed for exti controller with multiple exti under
- same parent interrupt: st,stm32-exti and st,stm32h7-exti")
+ same parent interrupt: st,stm32-exti and st,stm32h7-exti)
Example:
diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt b/Documentation/devicetree/bindings/mips/brcm/soc.txt
index 356c29789cf5..3a66d3c483e1 100644
--- a/Documentation/devicetree/bindings/mips/brcm/soc.txt
+++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt
@@ -152,7 +152,7 @@ Required properties:
- compatible : should contain one of:
"brcm,bcm7425-timers"
"brcm,bcm7429-timers"
- "brcm,bcm7435-timers and
+ "brcm,bcm7435-timers" and
"brcm,brcmstb-timers"
- reg : the timers register range
- interrupts : the interrupt line for this timer block
diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt
index df873d1f3b7c..f8c33890bc29 100644
--- a/Documentation/devicetree/bindings/net/fsl-fman.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fman.txt
@@ -238,7 +238,7 @@ PROPERTIES
Must include one of the following:
- "fsl,fman-dtsec" for dTSEC MAC
- "fsl,fman-xgec" for XGEC MAC
- - "fsl,fman-memac for mEMAC MAC
+ - "fsl,fman-memac" for mEMAC MAC
- cell-index
Usage: required
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 9b387f861aed..7dec508987c7 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -133,7 +133,7 @@ located inside a PM domain with index 0 of a power controller represented by a
node with the label "power".
In the second example the consumer device are partitioned across two PM domains,
the first with index 0 and the second with index 1, of a power controller that
-is represented by a node with the label "power.
+is represented by a node with the label "power".
Optional properties:
- required-opps: This contains phandle to an OPP node in another device's OPP
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt b/Documentation/devicetree/bindings/regulator/tps65090.txt
index ca69f5e3040c..ae326f263597 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -16,7 +16,7 @@ Required properties:
Optional properties:
- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.
If DCDCs are externally controlled then this property should be there.
-- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
+- dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
If DCDCs are externally controlled and if it is from GPIO then GPIO
number should be provided. If it is externally controlled and no GPIO
entry then driver will just configure this rails as external control
diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
index a21658f18fe6..3661e6153a92 100644
--- a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
+++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
@@ -15,7 +15,7 @@ Please refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
-- compatible: Should be st,stih407-softreset";
+- compatible: Should be "st,stih407-softreset";
- #reset-cells: 1, see below
example:
diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
index 6a4aadc4ce06..84b28dbe9f15 100644
--- a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
+++ b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
@@ -30,7 +30,7 @@ Required properties:
Board connectors:
* Headset Mic
- * Secondary Mic",
+ * Secondary Mic
* DMIC
* Ext Spk
diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
index aa54e49fc8a2..c7600a93ab39 100644
--- a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
+++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
@@ -35,7 +35,7 @@ This binding describes the APQ8096 sound card, which uses qdsp for audio.
"Digital Mic3"
Audio pins and MicBias on WCD9335 Codec:
- "MIC_BIAS1
+ "MIC_BIAS1"
"MIC_BIAS2"
"MIC_BIAS3"
"MIC_BIAS4"
--
2.17.1
^ permalink raw reply related
* [arm-platforms:irq/fixes-4.19 23/23] drivers/irqchip/irq-gic-v3-its.c:2335:13: error: 'nr_cpu_idx' undeclared; did you mean 'nr_cpu_ids'?
From: Marc Zyngier @ 2018-06-17 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201806172046.o5ARazOK%fengguang.wu@intel.com>
On Sun, 17 Jun 2018 13:10:48 +0100,
kbuild test robot <lkp@intel.com> wrote:
>
> [1 <text/plain; us-ascii (7bit)>]
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/fixes-4.19
> head: 2e077035935196976aa09ec043257efd56519810
> commit: 2e077035935196976aa09ec043257efd56519810 [23/23] irqchip/gic-v3-its: Don't bind LPI to unavailable NUMA node
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 2e077035935196976aa09ec043257efd56519810
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
> drivers/irqchip/irq-gic-v3-its.c: In function 'its_irq_domain_activate':
> >> drivers/irqchip/irq-gic-v3-its.c:2335:13: error: 'nr_cpu_idx' undeclared (first use in this function); did you mean 'nr_cpu_ids'?
> if (cpu >= nr_cpu_idx) {
> ^~~~~~~~~~
> nr_cpu_ids
> drivers/irqchip/irq-gic-v3-its.c:2335:13: note: each undeclared identifier is reported only once for each function it appears in
My bad, I pushed out the wrong branch, with the broken version of the
patch (Yang's patch was correct). Now fixed and pushed out again.
Thanks for the heads up.
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: generalize rk3399 #sound-dai-cells
From: Heiko Stuebner @ 2018-06-17 13:24 UTC (permalink / raw)
To: linux-arm-kernel
The soc spdif and i2s controllers always only have one compontent, so
always require #sound-dai-cells to be 0. Therefore there is no need to
duplicate this property in individual boards.
So move them to rk3399.dtsi.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 3 ---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts | 2 --
arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 3 +++
5 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index d8a2f0ba4b2b..918944aafe83 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -492,19 +492,16 @@
&i2s0 {
rockchip,playback-channels = <8>;
rockchip,capture-channels = <8>;
- #sound-dai-cells = <0>;
status = "okay";
};
&i2s1 {
rockchip,playback-channels = <2>;
rockchip,capture-channels = <2>;
- #sound-dai-cells = <0>;
status = "okay";
};
&i2s2 {
- #sound-dai-cells = <0>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 111839a18465..0130b9f98c9d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -402,7 +402,6 @@
pinctrl-0 = <&i2s0_2ch_bus>;
rockchip,playback-channels = <2>;
rockchip,capture-channels = <2>;
- #sound-dai-cells = <0>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
index 3768e1623e4f..fef2c0608999 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
@@ -149,7 +149,6 @@
&i2s0 {
rockchip,playback-channels = <8>;
rockchip,capture-channels = <8>;
- #sound-dai-cells = <0>;
status = "okay";
};
@@ -198,6 +197,5 @@
&spdif {
i2c-scl-rising-time-ns = <450>;
i2c-scl-falling-time-ns = <15>;
- #sound-dai-cells = <0>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 5dada565429c..36b60791c156 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -425,7 +425,6 @@
};
&i2s2 {
- #sound-dai-cells = <0>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index ff63d9e93b4a..adb037cd80fe 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1483,6 +1483,7 @@
pinctrl-names = "default";
pinctrl-0 = <&spdif_bus>;
power-domains = <&power RK3399_PD_SDIOAUDIO>;
+ #sound-dai-cells = <0>;
status = "disabled";
};
@@ -1498,6 +1499,7 @@
pinctrl-names = "default";
pinctrl-0 = <&i2s0_8ch_bus>;
power-domains = <&power RK3399_PD_SDIOAUDIO>;
+ #sound-dai-cells = <0>;
status = "disabled";
};
@@ -1512,6 +1514,7 @@
pinctrl-names = "default";
pinctrl-0 = <&i2s1_2ch_bus>;
power-domains = <&power RK3399_PD_SDIOAUDIO>;
+ #sound-dai-cells = <0>;
status = "disabled";
};
--
2.17.0
^ permalink raw reply related
* [PATCH] ARM: dts: rockchip: fix graph node unit address error from dtc
From: Heiko Stuebner @ 2018-06-17 13:21 UTC (permalink / raw)
To: linux-arm-kernel
The updated dtc emits a warning for the edp-panel of two rk3288 boards:
Warning (graph_endpoint): /dp at ff970000/ports/port at 1/endpoint: graph node unit address error, expected "0"
Fix this by adding the necessary @0 to the endpoint node.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm/boot/dts/rk3288-evb.dtsi | 2 +-
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi
index 39b61dce97ad..1c4dfd94e555 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -232,7 +232,7 @@
#address-cells = <1>;
#size-cells = <0>;
- edp_out_panel: endpoint {
+ edp_out_panel: endpoint at 0 {
reg = <0>;
remote-endpoint = <&panel_in_edp>;
};
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index b16d570ff029..acf5f8a2307d 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -174,7 +174,7 @@
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
- edp_out_panel: endpoint {
+ edp_out_panel: endpoint at 0 {
reg = <0>;
remote-endpoint = <&panel_in_edp>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH] ARM: dts: rockchip: convert rk3288 to operating-points-v2
From: Heiko Stuebner @ 2018-06-17 13:18 UTC (permalink / raw)
To: linux-arm-kernel
Operating points need to be present in each cpu core using it, not only
the first one. With operating-points-v1 this would require duplicating
this table into each cpu node.
With opp-v2 we can share the same table on all nodes.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 36 +++++++-------
arch/arm/boot/dts/rk3288.dtsi | 70 ++++++++++++++++++++++------
2 files changed, 75 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 823c7ed47fcf..c8c83bf544b9 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -91,22 +91,26 @@
&cpu0 {
cpu0-supply = <&vdd_cpu>;
- operating-points = <
- /* KHz uV */
- 1800000 1400000
- 1704000 1350000
- 1608000 1300000
- 1512000 1250000
- 1416000 1200000
- 1200000 1100000
- 1008000 1050000
- 816000 1000000
- 696000 950000
- 600000 900000
- 408000 900000
- 216000 900000
- 126000 900000
- >;
+};
+
+/* rk3288-c used in Veyron Chrome-devices has slightly changed OPPs */
+&cpu_opp_table {
+ /delete-node/ opp02;
+
+ opp10 {
+ opp-microvolt = <1250000>;
+ };
+ opp11 {
+ opp-microvolt = <1300000>;
+ };
+ opp12 {
+ opp-hz = /bits/ 64 <1704000000>;
+ opp-microvolt = <1350000>;
+ };
+ opp13 {
+ opp-hz = /bits/ 64 <1800000000>;
+ opp-microvolt = <1400000>;
+ };
};
&emmc {
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 2a060c2dc383..a3af3f6ad8d0 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -60,21 +60,7 @@
compatible = "arm,cortex-a12";
reg = <0x500>;
resets = <&cru SRST_CORE0>;
- operating-points = <
- /* KHz uV */
- 1608000 1350000
- 1512000 1300000
- 1416000 1200000
- 1200000 1100000
- 1008000 1050000
- 816000 1000000
- 696000 950000
- 600000 900000
- 408000 900000
- 312000 900000
- 216000 900000
- 126000 900000
- >;
+ operating-points-v2 = <&cpu_opp_table>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <40000>;
clocks = <&cru ARMCLK>;
@@ -99,6 +85,60 @@
};
};
+ cpu_opp_table: cpu-opp-table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <126000000>;
+ opp-microvolt = <900000>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <216000000>;
+ opp-microvolt = <900000>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <312000000>;
+ opp-microvolt = <900000>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <408000000>;
+ opp-microvolt = <900000>;
+ };
+ opp04 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <900000>;
+ };
+ opp05 {
+ opp-hz = /bits/ 64 <696000000>;
+ opp-microvolt = <950000>;
+ };
+ opp06 {
+ opp-hz = /bits/ 64 <816000000>;
+ opp-microvolt = <1000000>;
+ };
+ opp07 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <1050000>;
+ };
+ opp08 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <1100000>;
+ };
+ opp09 {
+ opp-hz = /bits/ 64 <1416000000>;
+ opp-microvolt = <1200000>;
+ };
+ opp10 {
+ opp-hz = /bits/ 64 <1512000000>;
+ opp-microvolt = <1300000>;
+ };
+ opp11 {
+ opp-hz = /bits/ 64 <1608000000>;
+ opp-microvolt = <1350000>;
+ };
+ };
+
amba {
compatible = "simple-bus";
#address-cells = <2>;
--
2.17.0
^ permalink raw reply related
* [PATCH V2 3/4] dt-bindings: arm: fsl: add scu binding doc
From: Dong Aisheng @ 2018-06-17 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529239789-26849-1-git-send-email-aisheng.dong@nxp.com>
The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v1->v2:
* remove status
* changed to mu1
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
new file mode 100644
index 0000000..9b7c9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -0,0 +1,38 @@
+NXP i.MX System Controller Firmware (SCFW)
+--------------------------------------------------------------------
+
+The System Controller Firmware (SCFW) is a low-level system function
+which runs on a dedicated Cortex-M core to provide power, clock, and
+resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
+(QM, QP), and i.MX8QX (QXP, DX).
+
+The AP communicates with the SC using a multi-ported MU module found
+in the LSIO subsystem. The current definition of this MU module provides
+5 remote AP connections to the SC to support up to 5 execution environments
+(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
+with the LSIO DSC IP bus. The SC firmware will communicate with this MU
+using the MSI bus.
+
+System Controller Device Node:
+=============================
+
+Required properties:
+-------------------
+- compatible: should be "fsl,imx8qxp-scu" or "fsl,imx8qm-scu"
+- fsl,mu: a phandle to the Message Unit used by SCU. Should be
+ one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
+ to make sure not use the one which is conflict with
+ other execution environments. e.g. ATF.
+
+Examples:
+--------
+lsio_mu1: mu at 5d1c0000 {
+ compatible = "fsl,imx8qxp-mu";
+ reg = <0x0 0x5d1c0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+scu {
+ compatible = "fsl,imx8qxp-scu";
+ fsl,mu = <&lsio_mu1>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH V2 2/4] dt-bindings: arm: fsl: add mu binding doc
From: Dong Aisheng @ 2018-06-17 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529239789-26849-1-git-send-email-aisheng.dong@nxp.com>
The Messaging Unit module enables two processors within
the SoC to communicate and coordinate by passing messages
(e.g. data, status and control) through the MU interface.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v1->v2:
* typo fixes
* remove status property
* remove imx6&7 compatible string which may be added later for
the generic mailbox binding
Note: Because MU used by SCU is not implemented as a mailbox driver,
Instead, they're provided in library calls to gain higher performance.
Futhermore, SCU MU has only one channel. But the binding doc claims
(Change to allow 0?)
So we did not follow the mailbox binding.
For the generic mailbox driver binding way, it may be added later.
---
.../devicetree/bindings/arm/freescale/fsl,mu.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,mu.txt
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,mu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,mu.txt
new file mode 100644
index 0000000..c37aa1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,mu.txt
@@ -0,0 +1,32 @@
+NXP i.MX Messaging Unit (MU)
+--------------------------------------------------------------------
+
+The Messaging Unit module enables two processors within the SoC to
+communicate and coordinate by passing messages (e.g. data, status
+and control) through the MU interface. The MU also provides the ability
+for one processor to signal the other processor using interrupts.
+
+Because the MU manages the messaging between processors, the MU uses
+different clocks (from each side of the different peripheral buses).
+Therefore, the MU must synchronize the accesses from one side to the
+other. The MU accomplishes synchronization using two sets of matching
+registers (Processor A-facing, Processor B-facing).
+
+Messaging Unit Device Node:
+=============================
+
+Required properties:
+-------------------
+- compatible : should be "fsl,<chip>-mu", the supported chips include
+ imx8qxp, imx8qm.
+- reg : Should contain the registers location and length
+- interrupts : Interrupt number. The interrupt specifier format depends
+ on the interrupt controller parent.
+
+Examples:
+--------
+lsio_mu0: mu at 5d1b0000 {
+ compatible = "fsl,imx8qxp-mu";
+ reg = <0x0 0x5d1b0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH V2 1/4] soc: imx: add mu library functions support
From: Dong Aisheng @ 2018-06-17 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529239789-26849-1-git-send-email-aisheng.dong@nxp.com>
This is used for i.MX multi core communication.
e.g. A core to SCU firmware(M core) on MX8.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v1->v2:
* introduce struct mu_priv to keep the private iomem info
* add the corresponding mu_exit()
---
drivers/soc/imx/Kconfig | 3 +
drivers/soc/imx/Makefile | 1 +
drivers/soc/imx/imx_mu.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++
include/soc/imx/mu.h | 24 +++++++
4 files changed, 193 insertions(+)
create mode 100644 drivers/soc/imx/imx_mu.c
create mode 100644 include/soc/imx/mu.h
diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index a5b86a2..4858cd7 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -7,4 +7,7 @@ config IMX7_PM_DOMAINS
select PM_GENERIC_DOMAINS
default y if SOC_IMX7D
+config HAVE_IMX_MU
+ bool
+
endmenu
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index aab41a5c..113dc7f 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
obj-$(CONFIG_IMX7_PM_DOMAINS) += gpcv2.o
+obj-$(CONFIG_HAVE_IMX_MU) += imx_mu.o
diff --git a/drivers/soc/imx/imx_mu.c b/drivers/soc/imx/imx_mu.c
new file mode 100644
index 0000000..44294d1
--- /dev/null
+++ b/drivers/soc/imx/imx_mu.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ * Dong Aisheng <aisheng.dong@nxp.com>
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+
+#define MU_ATR0 0x0
+#define MU_ARR0 0x10
+#define MU_ASR 0x20
+#define MU_ACR 0x24
+
+#define MU_CR_GIEn_MASK (0xf << 28)
+#define MU_CR_RIEn_MASK (0xf << 24)
+#define MU_CR_TIEn_MASK (0xf << 20)
+#define MU_CR_GIRn_MASK (0xf << 16)
+#define MU_CR_NMI_MASK (1 << 3)
+#define MU_CR_Fn_MASK 0x7
+
+#define MU_SR_TE0_MASK BIT(23)
+#define MU_SR_RF0_MASK BIT(27)
+
+#define MU_CR_RIE0_MASK BIT(27)
+#define MU_CR_GIE0_MASK BIT(31)
+
+struct mu_priv {
+ struct device_node *np;
+ void __iomem *base;
+};
+
+/*
+ * This function sets the Flag n of the MU.
+ */
+int32_t mu_set_fn(struct mu_priv *priv, uint32_t fn)
+{
+ uint32_t reg;
+
+ reg = fn & (~MU_CR_Fn_MASK);
+ if (reg > 0)
+ return -EINVAL;
+
+ reg = readl_relaxed(priv->base + MU_ACR);
+ /* Clear ABFn. */
+ reg &= ~MU_CR_Fn_MASK;
+ reg |= fn;
+ writel_relaxed(reg, priv->base + MU_ACR);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mu_set_fn);
+
+/*
+ * This function reads the status from status register.
+ */
+uint32_t mu_read_status(struct mu_priv *priv)
+{
+ return readl_relaxed(priv->base + MU_ASR);
+}
+EXPORT_SYMBOL_GPL(mu_read_status);
+
+/*
+ * This function enables specific RX full interrupt.
+ */
+void mu_enable_rx_full_int(struct mu_priv *priv, uint32_t index)
+{
+ uint32_t reg;
+
+ reg = readl_relaxed(priv->base + MU_ACR);
+ reg &= ~(MU_CR_GIRn_MASK | MU_CR_NMI_MASK);
+ reg |= MU_CR_RIE0_MASK >> index;
+ writel_relaxed(reg, priv->base + MU_ACR);
+}
+EXPORT_SYMBOL_GPL(mu_enable_rx_full_int);
+
+/*
+ * This function enables specific general purpose interrupt.
+ */
+void mu_enable_general_int(struct mu_priv *priv, uint32_t index)
+{
+ uint32_t reg;
+
+ reg = readl_relaxed(priv->base + MU_ACR);
+ reg &= ~(MU_CR_GIRn_MASK | MU_CR_NMI_MASK);
+ reg |= MU_CR_GIE0_MASK >> index;
+ writel_relaxed(reg, priv->base + MU_ACR);
+}
+EXPORT_SYMBOL_GPL(mu_enable_general_int);
+
+/*
+ * Wait and send message to the other core.
+ */
+void mu_send_msg(struct mu_priv *priv, uint32_t index, uint32_t msg)
+{
+ uint32_t mask = MU_SR_TE0_MASK >> index;
+
+ /* Wait TX register to be empty. */
+ while (!(readl_relaxed(priv->base + MU_ASR) & mask))
+ ;
+ writel_relaxed(msg, priv->base + MU_ATR0 + (index * 4));
+}
+EXPORT_SYMBOL_GPL(mu_send_msg);
+
+/*
+ * Wait to receive message from the other core.
+ */
+void mu_receive_msg(struct mu_priv *priv, uint32_t index, uint32_t *msg)
+{
+ uint32_t mask = MU_SR_RF0_MASK >> index;
+
+ /* Wait RX register to be full. */
+ while (!(readl_relaxed(priv->base + MU_ASR) & mask))
+ ;
+ *msg = readl_relaxed(priv->base + MU_ARR0 + (index * 4));
+}
+EXPORT_SYMBOL_GPL(mu_receive_msg);
+
+struct device_node *mu_node(struct mu_priv *priv)
+{
+ return priv ? priv->np : NULL;
+}
+EXPORT_SYMBOL_GPL(mu_node);
+
+struct mu_priv *mu_init(struct device_node *np)
+{
+ struct mu_priv *priv;
+ uint32_t reg;
+
+ if (WARN_ON(!np))
+ return NULL;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return ERR_PTR(-ENOMEM);
+
+ priv->np = np;
+ priv->base = of_iomap(np, 0);
+ if (!priv->base) {
+ kfree(priv);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ reg = readl_relaxed(priv->base + MU_ACR);
+ /* Clear GIEn, RIEn, TIEn, GIRn and ABFn. */
+ reg &= ~(MU_CR_GIEn_MASK | MU_CR_RIEn_MASK | MU_CR_TIEn_MASK
+ | MU_CR_GIRn_MASK | MU_CR_NMI_MASK | MU_CR_Fn_MASK);
+ writel_relaxed(reg, priv->base + MU_ACR);
+
+ return priv;
+}
+EXPORT_SYMBOL_GPL(mu_init);
+
+void mu_exit(struct mu_priv *priv)
+{
+ if (WARN_ON(!priv))
+ return;
+
+ iounmap(priv->base);
+ kfree(priv);
+}
+EXPORT_SYMBOL_GPL(mu_exit);
diff --git a/include/soc/imx/mu.h b/include/soc/imx/mu.h
new file mode 100644
index 0000000..0802193
--- /dev/null
+++ b/include/soc/imx/mu.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2018 NXP
+ */
+
+#ifndef IMX_MU_H
+#define IMX_MU_H
+
+#define MU_TR_COUNT 4
+#define MU_RR_COUNT 4
+
+struct mu_priv;
+
+void mu_exit(struct mu_priv *priv);
+struct mu_priv *mu_init(struct device_node *np);
+struct device_node *mu_node(struct mu_priv *priv);
+void mu_send_msg(struct mu_priv *priv, uint32_t index, uint32_t msg);
+void mu_receive_msg(struct mu_priv *priv, uint32_t index, uint32_t *msg);
+void mu_enable_general_int(struct mu_priv *priv, uint32_t index);
+void mu_enable_rx_full_int(struct mu_priv *priv, uint32_t index);
+uint32_t mu_read_status(struct mu_priv *priv);
+int32_t mu_set_fn(struct mu_priv *priv, uint32_t Fn);
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH V2 0/4] soc: imx: add scu firmware api support
From: Dong Aisheng @ 2018-06-17 12:49 UTC (permalink / raw)
To: linux-arm-kernel
Unlike the former i.MX Architectures, the new generation i.MX8 SoCs
(e.g. MX8QXP and MX8QM) contain a system controller which runs on a
dedicated Cortex-M core to provide power, clock, Pad, and resource
management. Communication between the host processor running
an OS and the system controller happens through a SCU protocol.
This patchset adds the SCU APIs which is implemented based on MU
and will be used by different system components.
It mainly consists of below parts:
1) MU library calls
1) Implementation of the IPC functions based on MUs (client side).
2) SCU firmware services APIs implementation ased on RPC calls which
are mostly generated by SCU firmware
Dong Aisheng (4):
soc: imx: add mu library functions support
dt-bindings: arm: fsl: add mu binding doc
dt-bindings: arm: fsl: add scu binding doc
soc: imx: add SC firmware IPC and APIs
.../devicetree/bindings/arm/freescale/fsl,mu.txt | 32 +
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 38 +
drivers/soc/imx/Kconfig | 7 +
drivers/soc/imx/Makefile | 2 +
drivers/soc/imx/imx_mu.c | 165 +++++
drivers/soc/imx/sc/Makefile | 8 +
drivers/soc/imx/sc/main/ipc.c | 250 +++++++
drivers/soc/imx/sc/main/rpc.h | 81 +++
drivers/soc/imx/sc/svc/irq/rpc.h | 23 +
drivers/soc/imx/sc/svc/irq/rpc_clnt.c | 58 ++
drivers/soc/imx/sc/svc/misc/rpc.h | 40 ++
drivers/soc/imx/sc/svc/misc/rpc_clnt.c | 368 ++++++++++
drivers/soc/imx/sc/svc/pad/rpc.h | 37 +
drivers/soc/imx/sc/svc/pad/rpc_clnt.c | 53 ++
drivers/soc/imx/sc/svc/pm/rpc.h | 40 ++
drivers/soc/imx/sc/svc/pm/rpc_clnt.c | 393 +++++++++++
drivers/soc/imx/sc/svc/rm/rpc.h | 52 ++
drivers/soc/imx/sc/svc/rm/rpc_clnt.c | 612 +++++++++++++++++
drivers/soc/imx/sc/svc/timer/rpc.h | 34 +
drivers/soc/imx/sc/svc/timer/rpc_clnt.c | 295 ++++++++
include/soc/imx/mu.h | 24 +
include/soc/imx/sc/ipc.h | 46 ++
include/soc/imx/sc/scfw.h | 24 +
include/soc/imx/sc/sci.h | 35 +
include/soc/imx/sc/svc/irq/api.h | 139 ++++
include/soc/imx/sc/svc/misc/api.h | 395 +++++++++++
include/soc/imx/sc/svc/pad/api.h | 61 ++
include/soc/imx/sc/svc/pm/api.h | 559 +++++++++++++++
include/soc/imx/sc/svc/rm/api.h | 726 ++++++++++++++++++++
include/soc/imx/sc/svc/timer/api.h | 265 +++++++
include/soc/imx/sc/types.h | 764 +++++++++++++++++++++
31 files changed, 5626 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,mu.txt
create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
create mode 100644 drivers/soc/imx/imx_mu.c
create mode 100644 drivers/soc/imx/sc/Makefile
create mode 100644 drivers/soc/imx/sc/main/ipc.c
create mode 100644 drivers/soc/imx/sc/main/rpc.h
create mode 100644 drivers/soc/imx/sc/svc/irq/rpc.h
create mode 100644 drivers/soc/imx/sc/svc/irq/rpc_clnt.c
create mode 100644 drivers/soc/imx/sc/svc/misc/rpc.h
create mode 100644 drivers/soc/imx/sc/svc/misc/rpc_clnt.c
create mode 100644 drivers/soc/imx/sc/svc/pad/rpc.h
create mode 100644 drivers/soc/imx/sc/svc/pad/rpc_clnt.c
create mode 100644 drivers/soc/imx/sc/svc/pm/rpc.h
create mode 100644 drivers/soc/imx/sc/svc/pm/rpc_clnt.c
create mode 100644 drivers/soc/imx/sc/svc/rm/rpc.h
create mode 100644 drivers/soc/imx/sc/svc/rm/rpc_clnt.c
create mode 100644 drivers/soc/imx/sc/svc/timer/rpc.h
create mode 100644 drivers/soc/imx/sc/svc/timer/rpc_clnt.c
create mode 100644 include/soc/imx/mu.h
create mode 100644 include/soc/imx/sc/ipc.h
create mode 100644 include/soc/imx/sc/scfw.h
create mode 100644 include/soc/imx/sc/sci.h
create mode 100644 include/soc/imx/sc/svc/irq/api.h
create mode 100644 include/soc/imx/sc/svc/misc/api.h
create mode 100644 include/soc/imx/sc/svc/pad/api.h
create mode 100644 include/soc/imx/sc/svc/pm/api.h
create mode 100644 include/soc/imx/sc/svc/rm/api.h
create mode 100644 include/soc/imx/sc/svc/timer/api.h
create mode 100644 include/soc/imx/sc/types.h
--
2.7.4
^ permalink raw reply
* [PATCH v2] drm/atmel-hlcdc: check stride values in the first plane
From: Boris Brezillon @ 2018-06-17 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617084826.31885-1-stefan@agner.ch>
On Sun, 17 Jun 2018 10:48:22 +0200
Stefan Agner <stefan@agner.ch> wrote:
> The statement always evaluates to true since the struct fields
> are arrays. This has shown up as a warning when compiling with
> clang:
> warning: address of array 'desc->layout.xstride' will always
> evaluate to 'true' [-Wpointer-bool-conversion]
>
> Check for values in the first plane instead.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied to drm-misc-fixes.
Thanks,
Boris
> ---
> Changes in v2:
> - Check for first value instead of dropping if statement
> (subject was: drm/atmel-hlcdc: remove unnecessary if statement)
>
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 73c875db45f4..47e0992f3908 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -839,7 +839,7 @@ static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane)
> return ret;
> }
>
> - if (desc->layout.xstride && desc->layout.pstride) {
> + if (desc->layout.xstride[0] && desc->layout.pstride[0]) {
> int ret;
>
> ret = drm_plane_create_rotation_property(&plane->base,
^ permalink raw reply
* [arm-platforms:irq/fixes-4.19 23/23] drivers/irqchip/irq-gic-v3-its.c:2335:13: error: 'nr_cpu_idx' undeclared; did you mean 'nr_cpu_ids'?
From: kbuild test robot @ 2018-06-17 12:10 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/fixes-4.19
head: 2e077035935196976aa09ec043257efd56519810
commit: 2e077035935196976aa09ec043257efd56519810 [23/23] irqchip/gic-v3-its: Don't bind LPI to unavailable NUMA node
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2e077035935196976aa09ec043257efd56519810
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All errors (new ones prefixed by >>):
drivers/irqchip/irq-gic-v3-its.c: In function 'its_irq_domain_activate':
>> drivers/irqchip/irq-gic-v3-its.c:2335:13: error: 'nr_cpu_idx' undeclared (first use in this function); did you mean 'nr_cpu_ids'?
if (cpu >= nr_cpu_idx) {
^~~~~~~~~~
nr_cpu_ids
drivers/irqchip/irq-gic-v3-its.c:2335:13: note: each undeclared identifier is reported only once for each function it appears in
vim +2335 drivers/irqchip/irq-gic-v3-its.c
2320
2321 static int its_irq_domain_activate(struct irq_domain *domain,
2322 struct irq_data *d, bool reserve)
2323 {
2324 struct its_device *its_dev = irq_data_get_irq_chip_data(d);
2325 u32 event = its_get_event_id(d);
2326 const struct cpumask *cpu_mask = cpu_online_mask;
2327 int cpu;
2328
2329 /* get the cpu_mask of local node */
2330 if (its_dev->its->numa_node >= 0)
2331 cpu_mask = cpumask_of_node(its_dev->its->numa_node);
2332
2333 /* Bind the LPI to the first possible CPU */
2334 cpu = cpumask_first_and(cpu_mask, cpu_online_mask);
> 2335 if (cpu >= nr_cpu_idx) {
2336 if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144)
2337 return -EINVAL;
2338
2339 cpu = cpumask_first(cpu_online_mask);
2340 }
2341
2342 its_dev->event_map.col_map[event] = cpu;
2343 irq_data_update_effective_affinity(d, cpumask_of(cpu));
2344
2345 /* Map the GIC IRQ and event to the device */
2346 its_send_mapti(its_dev, d->hwirq, event);
2347 return 0;
2348 }
2349
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37440 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180617/5a3fb4bf/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2] ARM: dts: am437x: make edt-ft5x06 a wakeup source
From: Daniel Mack @ 2018-06-17 11:53 UTC (permalink / raw)
To: linux-arm-kernel
The touchscreen driver no longer configures the device as wakeup source by
default. A "wakeup-source" property is needed.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
v1 ? v2: amended subject to not mention imx6 anymore
arch/arm/boot/dts/am437x-sk-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 440351ad0b80..d4be3fd0b6f4 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -610,6 +610,8 @@
touchscreen-size-x = <480>;
touchscreen-size-y = <272>;
+
+ wakeup-source;
};
tlv320aic3106: tlv320aic3106 at 1b {
--
2.17.1
^ permalink raw reply related
* Patch "spi: bcm2835aux: ensure interrupts are enabled for shared handler" has been added to the 4.16-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-17 11:23 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
spi: bcm2835aux: ensure interrupts are enabled for shared handler
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
spi-bcm2835aux-ensure-interrupts-are-enabled-for-shared-handler.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo at baz Sun Jun 17 12:07:34 CEST 2018
From: Rob Herring <robh@kernel.org>
Date: Thu, 3 May 2018 13:09:44 -0500
Subject: spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Rob Herring <robh@kernel.org>
[ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.
The root cause however is a bug in the shared handler. Shared handlers
must check that interrupts are actually enabled before servicing the
interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
[1] https://patchwork.kernel.org/patch/9781221/
Cc: Alexander Graf <agraf@suse.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-spi at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm2835aux.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@ static irqreturn_t bcm2835aux_spi_interr
struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
irqreturn_t ret = IRQ_NONE;
+ /* IRQ may be shared, so return if our interrupts are disabled */
+ if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+ (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+ return ret;
+
/* check if we have data to read */
while (bs->rx_len &&
(!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &
Patches currently in stable-queue which might be from robh at kernel.org are
queue-4.16/sh-switch-to-no_bootmem.patch
queue-4.16/spi-bcm2835aux-ensure-interrupts-are-enabled-for-shared-handler.patch
queue-4.16/dt-bindings-panel-lvds-fix-path-to-display-timing-bindings.patch
queue-4.16/dt-bindings-net-ravb-add-support-for-r8a77965-soc.patch
queue-4.16/dt-bindings-pinctrl-sunxi-fix-reference-to-driver.patch
queue-4.16/dt-bindings-serial-sh-sci-add-support-for-r8a77965-h-scif.patch
queue-4.16/doc-add-vendor-prefix-for-kieback-peter-gmbh.patch
queue-4.16/dt-bindings-dmaengine-rcar-dmac-document-r8a77965-support.patch
^ permalink raw reply
* Patch "perf cs-etm: Support unknown_thread in cs_etm_auxtrace" has been added to the 4.16-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-17 11:23 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
perf cs-etm: Support unknown_thread in cs_etm_auxtrace
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-cs-etm-support-unknown_thread-in-cs_etm_auxtrace.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo at baz Sun Jun 17 12:07:34 CEST 2018
From: Leo Yan <leo.yan@linaro.org>
Date: Thu, 10 May 2018 12:01:59 +0800
Subject: perf cs-etm: Support unknown_thread in cs_etm_auxtrace
From: Leo Yan <leo.yan@linaro.org>
[ Upstream commit 46d53620044f7b574c0f3216f8b4f2ce3559ce31 ]
CoreSight doesn't allocate thread structure for unknown_thread in ETM
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in a segmentation fault when
thread__find_addr_map() accesses the thread handler.
This commit creates a new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1525924920-4381-1-git-send-email-leo.yan at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/cs-etm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -212,6 +212,7 @@ static void cs_etm__free(struct perf_ses
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -980,6 +981,23 @@ int cs_etm__process_auxtrace_info(union
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -994,16 +1012,18 @@ int cs_etm__process_auxtrace_info(union
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
Patches currently in stable-queue which might be from leo.yan at linaro.org are
queue-4.16/perf-cs-etm-support-unknown_thread-in-cs_etm_auxtrace.patch
^ permalink raw reply
* Patch "spi: bcm2835aux: ensure interrupts are enabled for shared handler" has been added to the 4.14-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-17 11:23 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
spi: bcm2835aux: ensure interrupts are enabled for shared handler
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
spi-bcm2835aux-ensure-interrupts-are-enabled-for-shared-handler.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo at baz Sun Jun 17 12:13:49 CEST 2018
From: Rob Herring <robh@kernel.org>
Date: Thu, 3 May 2018 13:09:44 -0500
Subject: spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Rob Herring <robh@kernel.org>
[ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.
The root cause however is a bug in the shared handler. Shared handlers
must check that interrupts are actually enabled before servicing the
interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
[1] https://patchwork.kernel.org/patch/9781221/
Cc: Alexander Graf <agraf@suse.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-spi at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm2835aux.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@ static irqreturn_t bcm2835aux_spi_interr
struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
irqreturn_t ret = IRQ_NONE;
+ /* IRQ may be shared, so return if our interrupts are disabled */
+ if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+ (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+ return ret;
+
/* check if we have data to read */
while (bs->rx_len &&
(!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &
Patches currently in stable-queue which might be from robh at kernel.org are
queue-4.14/spi-bcm2835aux-ensure-interrupts-are-enabled-for-shared-handler.patch
queue-4.14/dt-bindings-panel-lvds-fix-path-to-display-timing-bindings.patch
queue-4.14/dt-bindings-pinctrl-sunxi-fix-reference-to-driver.patch
queue-4.14/dt-bindings-serial-sh-sci-add-support-for-r8a77965-h-scif.patch
queue-4.14/doc-add-vendor-prefix-for-kieback-peter-gmbh.patch
queue-4.14/dt-bindings-dmaengine-rcar-dmac-document-r8a77965-support.patch
^ permalink raw reply
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Ard Biesheuvel @ 2018-06-17 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8396d433caf1155f9ca422c6bad3200b@agner.ch>
On 17 June 2018 at 12:41, Stefan Agner <stefan@agner.ch> wrote:
> On 17.06.2018 11:40, Ard Biesheuvel wrote:
>> On 17 June 2018 at 11:30, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> On 17 June 2018 at 00:40, Stefan Agner <stefan@agner.ch> wrote:
>>>> Hi Eric,
>>>>
>>>> On 14.02.2018 19:42, Eric Biggers wrote:
>>>>> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
>>>>> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
>>>>> Speck64. Each 128-byte chunk goes through XTS preprocessing, then is
>>>>> encrypted/decrypted (doing one cipher round for all the blocks, then the
>>>>> next round, etc.), then goes through XTS postprocessing.
>>>>>
>>>>> The performance depends on the processor but can be about 3 times faster
>>>>> than the generic code. For example, on an ARMv7 processor we observe
>>>>> the following performance with Speck128/256-XTS:
>>>>>
>>>>> xts-speck128-neon: Encryption 107.9 MB/s, Decryption 108.1 MB/s
>>>>> xts(speck128-generic): Encryption 32.1 MB/s, Decryption 36.6 MB/s
>>>>>
>>>>> In comparison to AES-256-XTS without the Cryptography Extensions:
>>>>>
>>>>> xts-aes-neonbs: Encryption 41.2 MB/s, Decryption 36.7 MB/s
>>>>> xts(aes-asm): Encryption 31.7 MB/s, Decryption 30.8 MB/s
>>>>> xts(aes-generic): Encryption 21.2 MB/s, Decryption 20.9 MB/s
>>>>>
>>>>> Speck64/128-XTS is even faster:
>>>>>
>>>>> xts-speck64-neon: Encryption 138.6 MB/s, Decryption 139.1 MB/s
>>>>>
>>>>> Note that as with the generic code, only the Speck128 and Speck64
>>>>> variants are supported. Also, for now only the XTS mode of operation is
>>>>> supported, to target the disk and file encryption use cases. The NEON
>>>>> code also only handles the portion of the data that is evenly divisible
>>>>> into 128-byte chunks, with any remainder handled by a C fallback. Of
>>>>> course, other modes of operation could be added later if needed, and/or
>>>>> the NEON code could be updated to handle other buffer sizes.
>>>>>
>>>>> The XTS specification is only defined for AES which has a 128-bit block
>>>>> size, so for the GF(2^64) math needed for Speck64-XTS we use the
>>>>> reducing polynomial 'x^64 + x^4 + x^3 + x + 1' given by the original XEX
>>>>> paper. Of course, when possible users should use Speck128-XTS, but even
>>>>> that may be too slow on some processors; Speck64-XTS can be faster.
>>>>>
>>>>> Signed-off-by: Eric Biggers <ebiggers@google.com>
>>>>> ---
>>>>> arch/arm/crypto/Kconfig | 6 +
>>>>> arch/arm/crypto/Makefile | 2 +
>>>>> arch/arm/crypto/speck-neon-core.S | 432 ++++++++++++++++++++++++++++++
>>>>> arch/arm/crypto/speck-neon-glue.c | 288 ++++++++++++++++++++
>>>>> 4 files changed, 728 insertions(+)
>>>>> create mode 100644 arch/arm/crypto/speck-neon-core.S
>>>>> create mode 100644 arch/arm/crypto/speck-neon-glue.c
>>>>>
>>>>> diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
>>>>> index b8e69fe282b8..925d1364727a 100644
>>>>> --- a/arch/arm/crypto/Kconfig
>>>>> +++ b/arch/arm/crypto/Kconfig
>>>>> @@ -121,4 +121,10 @@ config CRYPTO_CHACHA20_NEON
>>>>> select CRYPTO_BLKCIPHER
>>>>> select CRYPTO_CHACHA20
>>>>>
>>>>> +config CRYPTO_SPECK_NEON
>>>>> + tristate "NEON accelerated Speck cipher algorithms"
>>>>> + depends on KERNEL_MODE_NEON
>>>>> + select CRYPTO_BLKCIPHER
>>>>> + select CRYPTO_SPECK
>>>>> +
>>>>> endif
>>>>> diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
>>>>> index 30ef8e291271..a758107c5525 100644
>>>>> --- a/arch/arm/crypto/Makefile
>>>>> +++ b/arch/arm/crypto/Makefile
>>>>> @@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
>>>>> obj-$(CONFIG_CRYPTO_SHA256_ARM) += sha256-arm.o
>>>>> obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
>>>>> obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
>>>>> +obj-$(CONFIG_CRYPTO_SPECK_NEON) += speck-neon.o
>>>>>
>>>>> ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
>>>>> ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
>>>>> @@ -53,6 +54,7 @@ ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
>>>>> crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o
>>>>> crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
>>>>> chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o
>>>>> +speck-neon-y := speck-neon-core.o speck-neon-glue.o
>>>>>
>>>>> quiet_cmd_perl = PERL $@
>>>>> cmd_perl = $(PERL) $(<) > $(@)
>>>>> diff --git a/arch/arm/crypto/speck-neon-core.S
>>>>> b/arch/arm/crypto/speck-neon-core.S
>>>>> new file mode 100644
>>>>> index 000000000000..3c1e203e53b9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/crypto/speck-neon-core.S
>>>>> @@ -0,0 +1,432 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +/*
>>>>> + * NEON-accelerated implementation of Speck128-XTS and Speck64-XTS
>>>>> + *
>>>>> + * Copyright (c) 2018 Google, Inc
>>>>> + *
>>>>> + * Author: Eric Biggers <ebiggers@google.com>
>>>>> + */
>>>>> +
>>>>> +#include <linux/linkage.h>
>>>>> +
>>>>> + .text
>>>>> + .fpu neon
>>>>> +
>>>>> + // arguments
>>>>> + ROUND_KEYS .req r0 // const {u64,u32} *round_keys
>>>>> + NROUNDS .req r1 // int nrounds
>>>>> + DST .req r2 // void *dst
>>>>> + SRC .req r3 // const void *src
>>>>> + NBYTES .req r4 // unsigned int nbytes
>>>>> + TWEAK .req r5 // void *tweak
>>>>> +
>>>>> + // registers which hold the data being encrypted/decrypted
>>>>> + X0 .req q0
>>>>> + X0_L .req d0
>>>>> + X0_H .req d1
>>>>> + Y0 .req q1
>>>>> + Y0_H .req d3
>>>>> + X1 .req q2
>>>>> + X1_L .req d4
>>>>> + X1_H .req d5
>>>>> + Y1 .req q3
>>>>> + Y1_H .req d7
>>>>> + X2 .req q4
>>>>> + X2_L .req d8
>>>>> + X2_H .req d9
>>>>> + Y2 .req q5
>>>>> + Y2_H .req d11
>>>>> + X3 .req q6
>>>>> + X3_L .req d12
>>>>> + X3_H .req d13
>>>>> + Y3 .req q7
>>>>> + Y3_H .req d15
>>>>> +
>>>>> + // the round key, duplicated in all lanes
>>>>> + ROUND_KEY .req q8
>>>>> + ROUND_KEY_L .req d16
>>>>> + ROUND_KEY_H .req d17
>>>>> +
>>>>> + // index vector for vtbl-based 8-bit rotates
>>>>> + ROTATE_TABLE .req d18
>>>>> +
>>>>> + // multiplication table for updating XTS tweaks
>>>>> + GF128MUL_TABLE .req d19
>>>>> + GF64MUL_TABLE .req d19
>>>>> +
>>>>> + // current XTS tweak value(s)
>>>>> + TWEAKV .req q10
>>>>> + TWEAKV_L .req d20
>>>>> + TWEAKV_H .req d21
>>>>> +
>>>>> + TMP0 .req q12
>>>>> + TMP0_L .req d24
>>>>> + TMP0_H .req d25
>>>>> + TMP1 .req q13
>>>>> + TMP2 .req q14
>>>>> + TMP3 .req q15
>>>>> +
>>>>> + .align 4
>>>>> +.Lror64_8_table:
>>>>> + .byte 1, 2, 3, 4, 5, 6, 7, 0
>>>>> +.Lror32_8_table:
>>>>> + .byte 1, 2, 3, 0, 5, 6, 7, 4
>>>>> +.Lrol64_8_table:
>>>>> + .byte 7, 0, 1, 2, 3, 4, 5, 6
>>>>> +.Lrol32_8_table:
>>>>> + .byte 3, 0, 1, 2, 7, 4, 5, 6
>>>>> +.Lgf128mul_table:
>>>>> + .byte 0, 0x87
>>>>> + .fill 14
>>>>> +.Lgf64mul_table:
>>>>> + .byte 0, 0x1b, (0x1b << 1), (0x1b << 1) ^ 0x1b
>>>>> + .fill 12
>>>>> +
>>>>> +/*
>>>>> + * _speck_round_128bytes() - Speck encryption round on 128 bytes at a time
>>>>> + *
>>>>> + * Do one Speck encryption round on the 128 bytes (8 blocks for
>>>>> Speck128, 16 for
>>>>> + * Speck64) stored in X0-X3 and Y0-Y3, using the round key stored in all lanes
>>>>> + * of ROUND_KEY. 'n' is the lane size: 64 for Speck128, or 32 for Speck64.
>>>>> + *
>>>>> + * The 8-bit rotates are implemented using vtbl instead of vshr + vsli because
>>>>> + * the vtbl approach is faster on some processors and the same speed on others.
>>>>> + */
>>>>> +.macro _speck_round_128bytes n
>>>>> +
>>>>> + // x = ror(x, 8)
>>>>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>>>>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>>>>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>>>>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>>>>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>>>>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>>>>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>>>>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>>>>> +
>>>>> + // x += y
>>>>> + vadd.u\n X0, Y0
>>>>> + vadd.u\n X1, Y1
>>>>> + vadd.u\n X2, Y2
>>>>> + vadd.u\n X3, Y3
>>>>> +
>>>>> + // x ^= k
>>>>> + veor X0, ROUND_KEY
>>>>> + veor X1, ROUND_KEY
>>>>> + veor X2, ROUND_KEY
>>>>> + veor X3, ROUND_KEY
>>>>> +
>>>>> + // y = rol(y, 3)
>>>>> + vshl.u\n TMP0, Y0, #3
>>>>> + vshl.u\n TMP1, Y1, #3
>>>>> + vshl.u\n TMP2, Y2, #3
>>>>> + vshl.u\n TMP3, Y3, #3
>>>>> + vsri.u\n TMP0, Y0, #(\n - 3)
>>>>> + vsri.u\n TMP1, Y1, #(\n - 3)
>>>>> + vsri.u\n TMP2, Y2, #(\n - 3)
>>>>> + vsri.u\n TMP3, Y3, #(\n - 3)
>>>>> +
>>>>> + // y ^= x
>>>>> + veor Y0, TMP0, X0
>>>>> + veor Y1, TMP1, X1
>>>>> + veor Y2, TMP2, X2
>>>>> + veor Y3, TMP3, X3
>>>>> +.endm
>>>>> +
>>>>> +/*
>>>>> + * _speck_unround_128bytes() - Speck decryption round on 128 bytes at a time
>>>>> + *
>>>>> + * This is the inverse of _speck_round_128bytes().
>>>>> + */
>>>>> +.macro _speck_unround_128bytes n
>>>>> +
>>>>> + // y ^= x
>>>>> + veor TMP0, Y0, X0
>>>>> + veor TMP1, Y1, X1
>>>>> + veor TMP2, Y2, X2
>>>>> + veor TMP3, Y3, X3
>>>>> +
>>>>> + // y = ror(y, 3)
>>>>> + vshr.u\n Y0, TMP0, #3
>>>>> + vshr.u\n Y1, TMP1, #3
>>>>> + vshr.u\n Y2, TMP2, #3
>>>>> + vshr.u\n Y3, TMP3, #3
>>>>> + vsli.u\n Y0, TMP0, #(\n - 3)
>>>>> + vsli.u\n Y1, TMP1, #(\n - 3)
>>>>> + vsli.u\n Y2, TMP2, #(\n - 3)
>>>>> + vsli.u\n Y3, TMP3, #(\n - 3)
>>>>> +
>>>>> + // x ^= k
>>>>> + veor X0, ROUND_KEY
>>>>> + veor X1, ROUND_KEY
>>>>> + veor X2, ROUND_KEY
>>>>> + veor X3, ROUND_KEY
>>>>> +
>>>>> + // x -= y
>>>>> + vsub.u\n X0, Y0
>>>>> + vsub.u\n X1, Y1
>>>>> + vsub.u\n X2, Y2
>>>>> + vsub.u\n X3, Y3
>>>>> +
>>>>> + // x = rol(x, 8);
>>>>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>>>>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>>>>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>>>>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>>>>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>>>>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>>>>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>>>>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>>>>> +.endm
>>>>> +
>>>>> +.macro _xts128_precrypt_one dst_reg, tweak_buf, tmp
>>>>> +
>>>>> + // Load the next source block
>>>>> + vld1.8 {\dst_reg}, [SRC]!
>>>>> +
>>>>> + // Save the current tweak in the tweak buffer
>>>>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>>>>> +
>>>>> + // XOR the next source block with the current tweak
>>>>> + veor \dst_reg, TWEAKV
>>>>> +
>>>>> + /*
>>>>> + * Calculate the next tweak by multiplying the current one by x,
>>>>> + * modulo p(x) = x^128 + x^7 + x^2 + x + 1.
>>>>> + */
>>>>> + vshr.u64 \tmp, TWEAKV, #63
>>>>> + vshl.u64 TWEAKV, #1
>>>>> + veor TWEAKV_H, \tmp\()_L
>>>>> + vtbl.8 \tmp\()_H, {GF128MUL_TABLE}, \tmp\()_H
>>>>> + veor TWEAKV_L, \tmp\()_H
>>>>> +.endm
>>>>> +
>>>>> +.macro _xts64_precrypt_two dst_reg, tweak_buf, tmp
>>>>> +
>>>>> + // Load the next two source blocks
>>>>> + vld1.8 {\dst_reg}, [SRC]!
>>>>> +
>>>>> + // Save the current two tweaks in the tweak buffer
>>>>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>>>>> +
>>>>> + // XOR the next two source blocks with the current two tweaks
>>>>> + veor \dst_reg, TWEAKV
>>>>> +
>>>>> + /*
>>>>> + * Calculate the next two tweaks by multiplying the current ones by x^2,
>>>>> + * modulo p(x) = x^64 + x^4 + x^3 + x + 1.
>>>>> + */
>>>>> + vshr.u64 \tmp, TWEAKV, #62
>>>>> + vshl.u64 TWEAKV, #2
>>>>> + vtbl.8 \tmp\()_L, {GF64MUL_TABLE}, \tmp\()_L
>>>>> + vtbl.8 \tmp\()_H, {GF64MUL_TABLE}, \tmp\()_H
>>>>> + veor TWEAKV, \tmp
>>>>> +.endm
>>>>> +
>>>>> +/*
>>>>> + * _speck_xts_crypt() - Speck-XTS encryption/decryption
>>>>> + *
>>>>> + * Encrypt or decrypt NBYTES bytes of data from the SRC buffer to the
>>>>> DST buffer
>>>>> + * using Speck-XTS, specifically the variant with a block size of
>>>>> '2n' and round
>>>>> + * count given by NROUNDS. The expanded round keys are given in
>>>>> ROUND_KEYS, and
>>>>> + * the current XTS tweak value is given in TWEAK. It's assumed that
>>>>> NBYTES is a
>>>>> + * nonzero multiple of 128.
>>>>> + */
>>>>> +.macro _speck_xts_crypt n, decrypting
>>>>> + push {r4-r7}
>>>>> + mov r7, sp
>>>>> +
>>>>> + /*
>>>>> + * The first four parameters were passed in registers r0-r3. Load the
>>>>> + * additional parameters, which were passed on the stack.
>>>>> + */
>>>>> + ldr NBYTES, [sp, #16]
>>>>> + ldr TWEAK, [sp, #20]
>>>>> +
>>>>> + /*
>>>>> + * If decrypting, modify the ROUND_KEYS parameter to point to the last
>>>>> + * round key rather than the first, since for decryption the round keys
>>>>> + * are used in reverse order.
>>>>> + */
>>>>> +.if \decrypting
>>>>> +.if \n == 64
>>>>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #3
>>>>> + sub ROUND_KEYS, #8
>>>>> +.else
>>>>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #2
>>>>> + sub ROUND_KEYS, #4
>>>>> +.endif
>>>>> +.endif
>>>>> +
>>>>> + // Load the index vector for vtbl-based 8-bit rotates
>>>>> +.if \decrypting
>>>>> + ldr r12, =.Lrol\n\()_8_table
>>>>> +.else
>>>>> + ldr r12, =.Lror\n\()_8_table
>>>>> +.endif
>>>>> + vld1.8 {ROTATE_TABLE}, [r12:64]
>>>>> +
>>>>> + // One-time XTS preparation
>>>>> +
>>>>> + /*
>>>>> + * Allocate stack space to store 128 bytes worth of tweaks. For
>>>>> + * performance, this space is aligned to a 16-byte boundary so that we
>>>>> + * can use the load/store instructions that declare 16-byte alignment.
>>>>> + */
>>>>> + sub sp, #128
>>>>> + bic sp, #0xf
>>>>
>>>>
>>>> This fails here when building with CONFIG_THUMB2_KERNEL=y
>>>>
>>>> AS arch/arm/crypto/speck-neon-core.o
>>>>
>>>> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>>>>
>>>> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
>>>> `bic sp,#0xf'
>>>> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
>>>> `bic sp,#0xf'
>>>> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
>>>> `bic sp,#0xf'
>>>> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
>>>> `bic sp,#0xf'
>>>>
>>>> In a quick hack this change seems to address it:
>>>>
>>>>
>>>> - sub sp, #128
>>>> - bic sp, #0xf
>>>> + mov r6, sp
>>>> + sub r6, #128
>>>> + bic r6, #0xf
>>>> + mov sp, r6
>>>>
>>>> But there is probably a better solution to address this.
>>>>
>>>
>>> Given that there is no NEON on M class cores, I recommend we put something like
>>>
>>> THUMB(bx pc)
>>> THUMB(nop.w)
>>> THUMB(.arm)
>>>
>>> at the beginning and be done with it.
>>
>> I mean nop.n or just nop, of course, and we may need a '.align 2' at
>> the beginning as well.
>
> Wouldn't it be preferable to have it assemble it in Thumb2 too? It seems
> that bic sp,#0xf is the only issue...
>
Well, in general, yes. In the case of NEON code, not really, since the
resulting code will not be smaller anyway, because the Thumb2 NEON
opcodes are all 4 bytes. Also, Thumb2-only cores don't have NEON
units, so all cores that this code can run on will be able to run in
ARM mode.
So from a maintainability pov, having code that only assembles in one
way is better than having code that must compile both to ARM and to
Thumb2 opcodes.
Just my 2 cents, anyway.
^ permalink raw reply
* [PATCH v2 2/2] ASoC: pxa: add devicetree support
From: Robert Jarzmik @ 2018-06-17 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617105001.17784-1-robert.jarzmik@free.fr>
Add the devicetree support, so that the driver can be used in a
devictree platform.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: changed compatible string to pxa250-ac97, pxa270-ac97...
---
sound/arm/pxa2xx-ac97-lib.c | 12 ++++++++++++
sound/soc/pxa/pxa2xx-ac97.c | 12 ++++++++++++
2 files changed, 24 insertions(+)
diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c
index 5950a9e218d9..8eafd3d3dff6 100644
--- a/sound/arm/pxa2xx-ac97-lib.c
+++ b/sound/arm/pxa2xx-ac97-lib.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/io.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <sound/pxa2xx-lib.h>
@@ -337,6 +338,17 @@ int pxa2xx_ac97_hw_probe(struct platform_device *dev)
dev_err(&dev->dev, "Invalid reset GPIO %d\n",
pdata->reset_gpio);
}
+ } else if (!pdata && dev->dev.of_node) {
+ pdata = devm_kzalloc(&dev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ pdata->reset_gpio = of_get_named_gpio(dev->dev.of_node,
+ "reset-gpios", 0);
+ if (pdata->reset_gpio == -ENOENT)
+ pdata->reset_gpio = -1;
+ else if (pdata->reset_gpio < 0)
+ return pdata->reset_gpio;
+ reset_gpio = pdata->reset_gpio;
} else {
if (cpu_is_pxa27x())
reset_gpio = 113;
diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
index bd36578ceb86..d6be323a13ec 100644
--- a/sound/soc/pxa/pxa2xx-ac97.c
+++ b/sound/soc/pxa/pxa2xx-ac97.c
@@ -231,6 +231,17 @@ static const struct snd_soc_component_driver pxa_ac97_component = {
.name = "pxa-ac97",
};
+#ifdef CONFIG_OF
+static const struct of_device_id pxa2xx_ac97_dt_ids[] = {
+ { .compatible = "marvell,pxa250-ac97", },
+ { .compatible = "marvell,pxa270-ac97", },
+ { .compatible = "marvell,pxa300-ac97", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pxa2xx_ac97_dt_ids);
+
+#endif
+
static int pxa2xx_ac97_dev_probe(struct platform_device *pdev)
{
int ret;
@@ -298,6 +309,7 @@ static struct platform_driver pxa2xx_ac97_driver = {
#ifdef CONFIG_PM_SLEEP
.pm = &pxa2xx_ac97_pm_ops,
#endif
+ .of_match_table = of_match_ptr(pxa2xx_ac97_dt_ids),
},
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/2] ASoC: pxa: add binding for pxa2xx-ac97 audio complex
From: Robert Jarzmik @ 2018-06-17 10:50 UTC (permalink / raw)
To: linux-arm-kernel
This adds a binding for the Marvell PXA audio complex, available in
pxa2xx and pxa3xx variants.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: Rob's review, compatible string, reset-gpios, status
---
.../bindings/sound/marvell,pxa2xx-ac97.txt | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
diff --git a/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
new file mode 100644
index 000000000000..2ea85d5be6a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
@@ -0,0 +1,27 @@
+Marvell PXA2xx audio complex
+
+This descriptions matches the AC97 controller found in pxa2xx and pxa3xx series.
+
+Required properties:
+ - compatible: should be one of the following:
+ "marvell,pxa250-ac97"
+ "marvell,pxa270-ac97"
+ "marvell,pxa300-ac97"
+ - reg: device MMIO address space
+ - interrupts: single interrupt generated by AC97 IP
+ - clocks: input clock of the AC97 IP, refer to clock-bindings.txt
+
+Optional properties:
+ - pinctrl-names, pinctrl-0: refer to pinctrl-bindings.txt
+ - reset-gpios: gpio used for AC97 reset, refer to gpio.txt
+
+Example:
+ ac97: sound at 40500000 {
+ compatible = "marvell,pxa250-ac97";
+ reg = < 0x40500000 0x1000 >;
+ interrupts = <14>;
+ reset-gpios = <&gpio 113 GPIO_ACTIVE_HIGH>;
+ #sound-dai-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = < &pmux_ac97_default >;
+ };
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Stefan Agner @ 2018-06-17 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-J9Ho8GY4EC7k_K3Wg4W_aC2kPryMD0e0SKY+biJOdDw@mail.gmail.com>
On 17.06.2018 11:40, Ard Biesheuvel wrote:
> On 17 June 2018 at 11:30, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 17 June 2018 at 00:40, Stefan Agner <stefan@agner.ch> wrote:
>>> Hi Eric,
>>>
>>> On 14.02.2018 19:42, Eric Biggers wrote:
>>>> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
>>>> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
>>>> Speck64. Each 128-byte chunk goes through XTS preprocessing, then is
>>>> encrypted/decrypted (doing one cipher round for all the blocks, then the
>>>> next round, etc.), then goes through XTS postprocessing.
>>>>
>>>> The performance depends on the processor but can be about 3 times faster
>>>> than the generic code. For example, on an ARMv7 processor we observe
>>>> the following performance with Speck128/256-XTS:
>>>>
>>>> xts-speck128-neon: Encryption 107.9 MB/s, Decryption 108.1 MB/s
>>>> xts(speck128-generic): Encryption 32.1 MB/s, Decryption 36.6 MB/s
>>>>
>>>> In comparison to AES-256-XTS without the Cryptography Extensions:
>>>>
>>>> xts-aes-neonbs: Encryption 41.2 MB/s, Decryption 36.7 MB/s
>>>> xts(aes-asm): Encryption 31.7 MB/s, Decryption 30.8 MB/s
>>>> xts(aes-generic): Encryption 21.2 MB/s, Decryption 20.9 MB/s
>>>>
>>>> Speck64/128-XTS is even faster:
>>>>
>>>> xts-speck64-neon: Encryption 138.6 MB/s, Decryption 139.1 MB/s
>>>>
>>>> Note that as with the generic code, only the Speck128 and Speck64
>>>> variants are supported. Also, for now only the XTS mode of operation is
>>>> supported, to target the disk and file encryption use cases. The NEON
>>>> code also only handles the portion of the data that is evenly divisible
>>>> into 128-byte chunks, with any remainder handled by a C fallback. Of
>>>> course, other modes of operation could be added later if needed, and/or
>>>> the NEON code could be updated to handle other buffer sizes.
>>>>
>>>> The XTS specification is only defined for AES which has a 128-bit block
>>>> size, so for the GF(2^64) math needed for Speck64-XTS we use the
>>>> reducing polynomial 'x^64 + x^4 + x^3 + x + 1' given by the original XEX
>>>> paper. Of course, when possible users should use Speck128-XTS, but even
>>>> that may be too slow on some processors; Speck64-XTS can be faster.
>>>>
>>>> Signed-off-by: Eric Biggers <ebiggers@google.com>
>>>> ---
>>>> arch/arm/crypto/Kconfig | 6 +
>>>> arch/arm/crypto/Makefile | 2 +
>>>> arch/arm/crypto/speck-neon-core.S | 432 ++++++++++++++++++++++++++++++
>>>> arch/arm/crypto/speck-neon-glue.c | 288 ++++++++++++++++++++
>>>> 4 files changed, 728 insertions(+)
>>>> create mode 100644 arch/arm/crypto/speck-neon-core.S
>>>> create mode 100644 arch/arm/crypto/speck-neon-glue.c
>>>>
>>>> diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
>>>> index b8e69fe282b8..925d1364727a 100644
>>>> --- a/arch/arm/crypto/Kconfig
>>>> +++ b/arch/arm/crypto/Kconfig
>>>> @@ -121,4 +121,10 @@ config CRYPTO_CHACHA20_NEON
>>>> select CRYPTO_BLKCIPHER
>>>> select CRYPTO_CHACHA20
>>>>
>>>> +config CRYPTO_SPECK_NEON
>>>> + tristate "NEON accelerated Speck cipher algorithms"
>>>> + depends on KERNEL_MODE_NEON
>>>> + select CRYPTO_BLKCIPHER
>>>> + select CRYPTO_SPECK
>>>> +
>>>> endif
>>>> diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
>>>> index 30ef8e291271..a758107c5525 100644
>>>> --- a/arch/arm/crypto/Makefile
>>>> +++ b/arch/arm/crypto/Makefile
>>>> @@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
>>>> obj-$(CONFIG_CRYPTO_SHA256_ARM) += sha256-arm.o
>>>> obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
>>>> obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
>>>> +obj-$(CONFIG_CRYPTO_SPECK_NEON) += speck-neon.o
>>>>
>>>> ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
>>>> ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
>>>> @@ -53,6 +54,7 @@ ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
>>>> crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o
>>>> crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
>>>> chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o
>>>> +speck-neon-y := speck-neon-core.o speck-neon-glue.o
>>>>
>>>> quiet_cmd_perl = PERL $@
>>>> cmd_perl = $(PERL) $(<) > $(@)
>>>> diff --git a/arch/arm/crypto/speck-neon-core.S
>>>> b/arch/arm/crypto/speck-neon-core.S
>>>> new file mode 100644
>>>> index 000000000000..3c1e203e53b9
>>>> --- /dev/null
>>>> +++ b/arch/arm/crypto/speck-neon-core.S
>>>> @@ -0,0 +1,432 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * NEON-accelerated implementation of Speck128-XTS and Speck64-XTS
>>>> + *
>>>> + * Copyright (c) 2018 Google, Inc
>>>> + *
>>>> + * Author: Eric Biggers <ebiggers@google.com>
>>>> + */
>>>> +
>>>> +#include <linux/linkage.h>
>>>> +
>>>> + .text
>>>> + .fpu neon
>>>> +
>>>> + // arguments
>>>> + ROUND_KEYS .req r0 // const {u64,u32} *round_keys
>>>> + NROUNDS .req r1 // int nrounds
>>>> + DST .req r2 // void *dst
>>>> + SRC .req r3 // const void *src
>>>> + NBYTES .req r4 // unsigned int nbytes
>>>> + TWEAK .req r5 // void *tweak
>>>> +
>>>> + // registers which hold the data being encrypted/decrypted
>>>> + X0 .req q0
>>>> + X0_L .req d0
>>>> + X0_H .req d1
>>>> + Y0 .req q1
>>>> + Y0_H .req d3
>>>> + X1 .req q2
>>>> + X1_L .req d4
>>>> + X1_H .req d5
>>>> + Y1 .req q3
>>>> + Y1_H .req d7
>>>> + X2 .req q4
>>>> + X2_L .req d8
>>>> + X2_H .req d9
>>>> + Y2 .req q5
>>>> + Y2_H .req d11
>>>> + X3 .req q6
>>>> + X3_L .req d12
>>>> + X3_H .req d13
>>>> + Y3 .req q7
>>>> + Y3_H .req d15
>>>> +
>>>> + // the round key, duplicated in all lanes
>>>> + ROUND_KEY .req q8
>>>> + ROUND_KEY_L .req d16
>>>> + ROUND_KEY_H .req d17
>>>> +
>>>> + // index vector for vtbl-based 8-bit rotates
>>>> + ROTATE_TABLE .req d18
>>>> +
>>>> + // multiplication table for updating XTS tweaks
>>>> + GF128MUL_TABLE .req d19
>>>> + GF64MUL_TABLE .req d19
>>>> +
>>>> + // current XTS tweak value(s)
>>>> + TWEAKV .req q10
>>>> + TWEAKV_L .req d20
>>>> + TWEAKV_H .req d21
>>>> +
>>>> + TMP0 .req q12
>>>> + TMP0_L .req d24
>>>> + TMP0_H .req d25
>>>> + TMP1 .req q13
>>>> + TMP2 .req q14
>>>> + TMP3 .req q15
>>>> +
>>>> + .align 4
>>>> +.Lror64_8_table:
>>>> + .byte 1, 2, 3, 4, 5, 6, 7, 0
>>>> +.Lror32_8_table:
>>>> + .byte 1, 2, 3, 0, 5, 6, 7, 4
>>>> +.Lrol64_8_table:
>>>> + .byte 7, 0, 1, 2, 3, 4, 5, 6
>>>> +.Lrol32_8_table:
>>>> + .byte 3, 0, 1, 2, 7, 4, 5, 6
>>>> +.Lgf128mul_table:
>>>> + .byte 0, 0x87
>>>> + .fill 14
>>>> +.Lgf64mul_table:
>>>> + .byte 0, 0x1b, (0x1b << 1), (0x1b << 1) ^ 0x1b
>>>> + .fill 12
>>>> +
>>>> +/*
>>>> + * _speck_round_128bytes() - Speck encryption round on 128 bytes at a time
>>>> + *
>>>> + * Do one Speck encryption round on the 128 bytes (8 blocks for
>>>> Speck128, 16 for
>>>> + * Speck64) stored in X0-X3 and Y0-Y3, using the round key stored in all lanes
>>>> + * of ROUND_KEY. 'n' is the lane size: 64 for Speck128, or 32 for Speck64.
>>>> + *
>>>> + * The 8-bit rotates are implemented using vtbl instead of vshr + vsli because
>>>> + * the vtbl approach is faster on some processors and the same speed on others.
>>>> + */
>>>> +.macro _speck_round_128bytes n
>>>> +
>>>> + // x = ror(x, 8)
>>>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>>>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>>>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>>>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>>>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>>>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>>>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>>>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>>>> +
>>>> + // x += y
>>>> + vadd.u\n X0, Y0
>>>> + vadd.u\n X1, Y1
>>>> + vadd.u\n X2, Y2
>>>> + vadd.u\n X3, Y3
>>>> +
>>>> + // x ^= k
>>>> + veor X0, ROUND_KEY
>>>> + veor X1, ROUND_KEY
>>>> + veor X2, ROUND_KEY
>>>> + veor X3, ROUND_KEY
>>>> +
>>>> + // y = rol(y, 3)
>>>> + vshl.u\n TMP0, Y0, #3
>>>> + vshl.u\n TMP1, Y1, #3
>>>> + vshl.u\n TMP2, Y2, #3
>>>> + vshl.u\n TMP3, Y3, #3
>>>> + vsri.u\n TMP0, Y0, #(\n - 3)
>>>> + vsri.u\n TMP1, Y1, #(\n - 3)
>>>> + vsri.u\n TMP2, Y2, #(\n - 3)
>>>> + vsri.u\n TMP3, Y3, #(\n - 3)
>>>> +
>>>> + // y ^= x
>>>> + veor Y0, TMP0, X0
>>>> + veor Y1, TMP1, X1
>>>> + veor Y2, TMP2, X2
>>>> + veor Y3, TMP3, X3
>>>> +.endm
>>>> +
>>>> +/*
>>>> + * _speck_unround_128bytes() - Speck decryption round on 128 bytes at a time
>>>> + *
>>>> + * This is the inverse of _speck_round_128bytes().
>>>> + */
>>>> +.macro _speck_unround_128bytes n
>>>> +
>>>> + // y ^= x
>>>> + veor TMP0, Y0, X0
>>>> + veor TMP1, Y1, X1
>>>> + veor TMP2, Y2, X2
>>>> + veor TMP3, Y3, X3
>>>> +
>>>> + // y = ror(y, 3)
>>>> + vshr.u\n Y0, TMP0, #3
>>>> + vshr.u\n Y1, TMP1, #3
>>>> + vshr.u\n Y2, TMP2, #3
>>>> + vshr.u\n Y3, TMP3, #3
>>>> + vsli.u\n Y0, TMP0, #(\n - 3)
>>>> + vsli.u\n Y1, TMP1, #(\n - 3)
>>>> + vsli.u\n Y2, TMP2, #(\n - 3)
>>>> + vsli.u\n Y3, TMP3, #(\n - 3)
>>>> +
>>>> + // x ^= k
>>>> + veor X0, ROUND_KEY
>>>> + veor X1, ROUND_KEY
>>>> + veor X2, ROUND_KEY
>>>> + veor X3, ROUND_KEY
>>>> +
>>>> + // x -= y
>>>> + vsub.u\n X0, Y0
>>>> + vsub.u\n X1, Y1
>>>> + vsub.u\n X2, Y2
>>>> + vsub.u\n X3, Y3
>>>> +
>>>> + // x = rol(x, 8);
>>>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>>>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>>>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>>>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>>>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>>>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>>>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>>>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>>>> +.endm
>>>> +
>>>> +.macro _xts128_precrypt_one dst_reg, tweak_buf, tmp
>>>> +
>>>> + // Load the next source block
>>>> + vld1.8 {\dst_reg}, [SRC]!
>>>> +
>>>> + // Save the current tweak in the tweak buffer
>>>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>>>> +
>>>> + // XOR the next source block with the current tweak
>>>> + veor \dst_reg, TWEAKV
>>>> +
>>>> + /*
>>>> + * Calculate the next tweak by multiplying the current one by x,
>>>> + * modulo p(x) = x^128 + x^7 + x^2 + x + 1.
>>>> + */
>>>> + vshr.u64 \tmp, TWEAKV, #63
>>>> + vshl.u64 TWEAKV, #1
>>>> + veor TWEAKV_H, \tmp\()_L
>>>> + vtbl.8 \tmp\()_H, {GF128MUL_TABLE}, \tmp\()_H
>>>> + veor TWEAKV_L, \tmp\()_H
>>>> +.endm
>>>> +
>>>> +.macro _xts64_precrypt_two dst_reg, tweak_buf, tmp
>>>> +
>>>> + // Load the next two source blocks
>>>> + vld1.8 {\dst_reg}, [SRC]!
>>>> +
>>>> + // Save the current two tweaks in the tweak buffer
>>>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>>>> +
>>>> + // XOR the next two source blocks with the current two tweaks
>>>> + veor \dst_reg, TWEAKV
>>>> +
>>>> + /*
>>>> + * Calculate the next two tweaks by multiplying the current ones by x^2,
>>>> + * modulo p(x) = x^64 + x^4 + x^3 + x + 1.
>>>> + */
>>>> + vshr.u64 \tmp, TWEAKV, #62
>>>> + vshl.u64 TWEAKV, #2
>>>> + vtbl.8 \tmp\()_L, {GF64MUL_TABLE}, \tmp\()_L
>>>> + vtbl.8 \tmp\()_H, {GF64MUL_TABLE}, \tmp\()_H
>>>> + veor TWEAKV, \tmp
>>>> +.endm
>>>> +
>>>> +/*
>>>> + * _speck_xts_crypt() - Speck-XTS encryption/decryption
>>>> + *
>>>> + * Encrypt or decrypt NBYTES bytes of data from the SRC buffer to the
>>>> DST buffer
>>>> + * using Speck-XTS, specifically the variant with a block size of
>>>> '2n' and round
>>>> + * count given by NROUNDS. The expanded round keys are given in
>>>> ROUND_KEYS, and
>>>> + * the current XTS tweak value is given in TWEAK. It's assumed that
>>>> NBYTES is a
>>>> + * nonzero multiple of 128.
>>>> + */
>>>> +.macro _speck_xts_crypt n, decrypting
>>>> + push {r4-r7}
>>>> + mov r7, sp
>>>> +
>>>> + /*
>>>> + * The first four parameters were passed in registers r0-r3. Load the
>>>> + * additional parameters, which were passed on the stack.
>>>> + */
>>>> + ldr NBYTES, [sp, #16]
>>>> + ldr TWEAK, [sp, #20]
>>>> +
>>>> + /*
>>>> + * If decrypting, modify the ROUND_KEYS parameter to point to the last
>>>> + * round key rather than the first, since for decryption the round keys
>>>> + * are used in reverse order.
>>>> + */
>>>> +.if \decrypting
>>>> +.if \n == 64
>>>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #3
>>>> + sub ROUND_KEYS, #8
>>>> +.else
>>>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #2
>>>> + sub ROUND_KEYS, #4
>>>> +.endif
>>>> +.endif
>>>> +
>>>> + // Load the index vector for vtbl-based 8-bit rotates
>>>> +.if \decrypting
>>>> + ldr r12, =.Lrol\n\()_8_table
>>>> +.else
>>>> + ldr r12, =.Lror\n\()_8_table
>>>> +.endif
>>>> + vld1.8 {ROTATE_TABLE}, [r12:64]
>>>> +
>>>> + // One-time XTS preparation
>>>> +
>>>> + /*
>>>> + * Allocate stack space to store 128 bytes worth of tweaks. For
>>>> + * performance, this space is aligned to a 16-byte boundary so that we
>>>> + * can use the load/store instructions that declare 16-byte alignment.
>>>> + */
>>>> + sub sp, #128
>>>> + bic sp, #0xf
>>>
>>>
>>> This fails here when building with CONFIG_THUMB2_KERNEL=y
>>>
>>> AS arch/arm/crypto/speck-neon-core.o
>>>
>>> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>>>
>>> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
>>> `bic sp,#0xf'
>>> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
>>> `bic sp,#0xf'
>>> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
>>> `bic sp,#0xf'
>>> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
>>> `bic sp,#0xf'
>>>
>>> In a quick hack this change seems to address it:
>>>
>>>
>>> - sub sp, #128
>>> - bic sp, #0xf
>>> + mov r6, sp
>>> + sub r6, #128
>>> + bic r6, #0xf
>>> + mov sp, r6
>>>
>>> But there is probably a better solution to address this.
>>>
>>
>> Given that there is no NEON on M class cores, I recommend we put something like
>>
>> THUMB(bx pc)
>> THUMB(nop.w)
>> THUMB(.arm)
>>
>> at the beginning and be done with it.
>
> I mean nop.n or just nop, of course, and we may need a '.align 2' at
> the beginning as well.
Wouldn't it be preferable to have it assemble it in Thumb2 too? It seems
that bic sp,#0xf is the only issue...
--
Stefan
^ permalink raw reply
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Ard Biesheuvel @ 2018-06-17 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_VLcp7gxH-8OY-XoHyB=SKVRYRG5D3KV_fNQ4zn4hgFQ@mail.gmail.com>
On 17 June 2018 at 11:30, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 17 June 2018 at 00:40, Stefan Agner <stefan@agner.ch> wrote:
>> Hi Eric,
>>
>> On 14.02.2018 19:42, Eric Biggers wrote:
>>> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
>>> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
>>> Speck64. Each 128-byte chunk goes through XTS preprocessing, then is
>>> encrypted/decrypted (doing one cipher round for all the blocks, then the
>>> next round, etc.), then goes through XTS postprocessing.
>>>
>>> The performance depends on the processor but can be about 3 times faster
>>> than the generic code. For example, on an ARMv7 processor we observe
>>> the following performance with Speck128/256-XTS:
>>>
>>> xts-speck128-neon: Encryption 107.9 MB/s, Decryption 108.1 MB/s
>>> xts(speck128-generic): Encryption 32.1 MB/s, Decryption 36.6 MB/s
>>>
>>> In comparison to AES-256-XTS without the Cryptography Extensions:
>>>
>>> xts-aes-neonbs: Encryption 41.2 MB/s, Decryption 36.7 MB/s
>>> xts(aes-asm): Encryption 31.7 MB/s, Decryption 30.8 MB/s
>>> xts(aes-generic): Encryption 21.2 MB/s, Decryption 20.9 MB/s
>>>
>>> Speck64/128-XTS is even faster:
>>>
>>> xts-speck64-neon: Encryption 138.6 MB/s, Decryption 139.1 MB/s
>>>
>>> Note that as with the generic code, only the Speck128 and Speck64
>>> variants are supported. Also, for now only the XTS mode of operation is
>>> supported, to target the disk and file encryption use cases. The NEON
>>> code also only handles the portion of the data that is evenly divisible
>>> into 128-byte chunks, with any remainder handled by a C fallback. Of
>>> course, other modes of operation could be added later if needed, and/or
>>> the NEON code could be updated to handle other buffer sizes.
>>>
>>> The XTS specification is only defined for AES which has a 128-bit block
>>> size, so for the GF(2^64) math needed for Speck64-XTS we use the
>>> reducing polynomial 'x^64 + x^4 + x^3 + x + 1' given by the original XEX
>>> paper. Of course, when possible users should use Speck128-XTS, but even
>>> that may be too slow on some processors; Speck64-XTS can be faster.
>>>
>>> Signed-off-by: Eric Biggers <ebiggers@google.com>
>>> ---
>>> arch/arm/crypto/Kconfig | 6 +
>>> arch/arm/crypto/Makefile | 2 +
>>> arch/arm/crypto/speck-neon-core.S | 432 ++++++++++++++++++++++++++++++
>>> arch/arm/crypto/speck-neon-glue.c | 288 ++++++++++++++++++++
>>> 4 files changed, 728 insertions(+)
>>> create mode 100644 arch/arm/crypto/speck-neon-core.S
>>> create mode 100644 arch/arm/crypto/speck-neon-glue.c
>>>
>>> diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
>>> index b8e69fe282b8..925d1364727a 100644
>>> --- a/arch/arm/crypto/Kconfig
>>> +++ b/arch/arm/crypto/Kconfig
>>> @@ -121,4 +121,10 @@ config CRYPTO_CHACHA20_NEON
>>> select CRYPTO_BLKCIPHER
>>> select CRYPTO_CHACHA20
>>>
>>> +config CRYPTO_SPECK_NEON
>>> + tristate "NEON accelerated Speck cipher algorithms"
>>> + depends on KERNEL_MODE_NEON
>>> + select CRYPTO_BLKCIPHER
>>> + select CRYPTO_SPECK
>>> +
>>> endif
>>> diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
>>> index 30ef8e291271..a758107c5525 100644
>>> --- a/arch/arm/crypto/Makefile
>>> +++ b/arch/arm/crypto/Makefile
>>> @@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
>>> obj-$(CONFIG_CRYPTO_SHA256_ARM) += sha256-arm.o
>>> obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
>>> obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
>>> +obj-$(CONFIG_CRYPTO_SPECK_NEON) += speck-neon.o
>>>
>>> ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
>>> ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
>>> @@ -53,6 +54,7 @@ ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
>>> crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o
>>> crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
>>> chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o
>>> +speck-neon-y := speck-neon-core.o speck-neon-glue.o
>>>
>>> quiet_cmd_perl = PERL $@
>>> cmd_perl = $(PERL) $(<) > $(@)
>>> diff --git a/arch/arm/crypto/speck-neon-core.S
>>> b/arch/arm/crypto/speck-neon-core.S
>>> new file mode 100644
>>> index 000000000000..3c1e203e53b9
>>> --- /dev/null
>>> +++ b/arch/arm/crypto/speck-neon-core.S
>>> @@ -0,0 +1,432 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * NEON-accelerated implementation of Speck128-XTS and Speck64-XTS
>>> + *
>>> + * Copyright (c) 2018 Google, Inc
>>> + *
>>> + * Author: Eric Biggers <ebiggers@google.com>
>>> + */
>>> +
>>> +#include <linux/linkage.h>
>>> +
>>> + .text
>>> + .fpu neon
>>> +
>>> + // arguments
>>> + ROUND_KEYS .req r0 // const {u64,u32} *round_keys
>>> + NROUNDS .req r1 // int nrounds
>>> + DST .req r2 // void *dst
>>> + SRC .req r3 // const void *src
>>> + NBYTES .req r4 // unsigned int nbytes
>>> + TWEAK .req r5 // void *tweak
>>> +
>>> + // registers which hold the data being encrypted/decrypted
>>> + X0 .req q0
>>> + X0_L .req d0
>>> + X0_H .req d1
>>> + Y0 .req q1
>>> + Y0_H .req d3
>>> + X1 .req q2
>>> + X1_L .req d4
>>> + X1_H .req d5
>>> + Y1 .req q3
>>> + Y1_H .req d7
>>> + X2 .req q4
>>> + X2_L .req d8
>>> + X2_H .req d9
>>> + Y2 .req q5
>>> + Y2_H .req d11
>>> + X3 .req q6
>>> + X3_L .req d12
>>> + X3_H .req d13
>>> + Y3 .req q7
>>> + Y3_H .req d15
>>> +
>>> + // the round key, duplicated in all lanes
>>> + ROUND_KEY .req q8
>>> + ROUND_KEY_L .req d16
>>> + ROUND_KEY_H .req d17
>>> +
>>> + // index vector for vtbl-based 8-bit rotates
>>> + ROTATE_TABLE .req d18
>>> +
>>> + // multiplication table for updating XTS tweaks
>>> + GF128MUL_TABLE .req d19
>>> + GF64MUL_TABLE .req d19
>>> +
>>> + // current XTS tweak value(s)
>>> + TWEAKV .req q10
>>> + TWEAKV_L .req d20
>>> + TWEAKV_H .req d21
>>> +
>>> + TMP0 .req q12
>>> + TMP0_L .req d24
>>> + TMP0_H .req d25
>>> + TMP1 .req q13
>>> + TMP2 .req q14
>>> + TMP3 .req q15
>>> +
>>> + .align 4
>>> +.Lror64_8_table:
>>> + .byte 1, 2, 3, 4, 5, 6, 7, 0
>>> +.Lror32_8_table:
>>> + .byte 1, 2, 3, 0, 5, 6, 7, 4
>>> +.Lrol64_8_table:
>>> + .byte 7, 0, 1, 2, 3, 4, 5, 6
>>> +.Lrol32_8_table:
>>> + .byte 3, 0, 1, 2, 7, 4, 5, 6
>>> +.Lgf128mul_table:
>>> + .byte 0, 0x87
>>> + .fill 14
>>> +.Lgf64mul_table:
>>> + .byte 0, 0x1b, (0x1b << 1), (0x1b << 1) ^ 0x1b
>>> + .fill 12
>>> +
>>> +/*
>>> + * _speck_round_128bytes() - Speck encryption round on 128 bytes at a time
>>> + *
>>> + * Do one Speck encryption round on the 128 bytes (8 blocks for
>>> Speck128, 16 for
>>> + * Speck64) stored in X0-X3 and Y0-Y3, using the round key stored in all lanes
>>> + * of ROUND_KEY. 'n' is the lane size: 64 for Speck128, or 32 for Speck64.
>>> + *
>>> + * The 8-bit rotates are implemented using vtbl instead of vshr + vsli because
>>> + * the vtbl approach is faster on some processors and the same speed on others.
>>> + */
>>> +.macro _speck_round_128bytes n
>>> +
>>> + // x = ror(x, 8)
>>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>>> +
>>> + // x += y
>>> + vadd.u\n X0, Y0
>>> + vadd.u\n X1, Y1
>>> + vadd.u\n X2, Y2
>>> + vadd.u\n X3, Y3
>>> +
>>> + // x ^= k
>>> + veor X0, ROUND_KEY
>>> + veor X1, ROUND_KEY
>>> + veor X2, ROUND_KEY
>>> + veor X3, ROUND_KEY
>>> +
>>> + // y = rol(y, 3)
>>> + vshl.u\n TMP0, Y0, #3
>>> + vshl.u\n TMP1, Y1, #3
>>> + vshl.u\n TMP2, Y2, #3
>>> + vshl.u\n TMP3, Y3, #3
>>> + vsri.u\n TMP0, Y0, #(\n - 3)
>>> + vsri.u\n TMP1, Y1, #(\n - 3)
>>> + vsri.u\n TMP2, Y2, #(\n - 3)
>>> + vsri.u\n TMP3, Y3, #(\n - 3)
>>> +
>>> + // y ^= x
>>> + veor Y0, TMP0, X0
>>> + veor Y1, TMP1, X1
>>> + veor Y2, TMP2, X2
>>> + veor Y3, TMP3, X3
>>> +.endm
>>> +
>>> +/*
>>> + * _speck_unround_128bytes() - Speck decryption round on 128 bytes at a time
>>> + *
>>> + * This is the inverse of _speck_round_128bytes().
>>> + */
>>> +.macro _speck_unround_128bytes n
>>> +
>>> + // y ^= x
>>> + veor TMP0, Y0, X0
>>> + veor TMP1, Y1, X1
>>> + veor TMP2, Y2, X2
>>> + veor TMP3, Y3, X3
>>> +
>>> + // y = ror(y, 3)
>>> + vshr.u\n Y0, TMP0, #3
>>> + vshr.u\n Y1, TMP1, #3
>>> + vshr.u\n Y2, TMP2, #3
>>> + vshr.u\n Y3, TMP3, #3
>>> + vsli.u\n Y0, TMP0, #(\n - 3)
>>> + vsli.u\n Y1, TMP1, #(\n - 3)
>>> + vsli.u\n Y2, TMP2, #(\n - 3)
>>> + vsli.u\n Y3, TMP3, #(\n - 3)
>>> +
>>> + // x ^= k
>>> + veor X0, ROUND_KEY
>>> + veor X1, ROUND_KEY
>>> + veor X2, ROUND_KEY
>>> + veor X3, ROUND_KEY
>>> +
>>> + // x -= y
>>> + vsub.u\n X0, Y0
>>> + vsub.u\n X1, Y1
>>> + vsub.u\n X2, Y2
>>> + vsub.u\n X3, Y3
>>> +
>>> + // x = rol(x, 8);
>>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>>> +.endm
>>> +
>>> +.macro _xts128_precrypt_one dst_reg, tweak_buf, tmp
>>> +
>>> + // Load the next source block
>>> + vld1.8 {\dst_reg}, [SRC]!
>>> +
>>> + // Save the current tweak in the tweak buffer
>>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>>> +
>>> + // XOR the next source block with the current tweak
>>> + veor \dst_reg, TWEAKV
>>> +
>>> + /*
>>> + * Calculate the next tweak by multiplying the current one by x,
>>> + * modulo p(x) = x^128 + x^7 + x^2 + x + 1.
>>> + */
>>> + vshr.u64 \tmp, TWEAKV, #63
>>> + vshl.u64 TWEAKV, #1
>>> + veor TWEAKV_H, \tmp\()_L
>>> + vtbl.8 \tmp\()_H, {GF128MUL_TABLE}, \tmp\()_H
>>> + veor TWEAKV_L, \tmp\()_H
>>> +.endm
>>> +
>>> +.macro _xts64_precrypt_two dst_reg, tweak_buf, tmp
>>> +
>>> + // Load the next two source blocks
>>> + vld1.8 {\dst_reg}, [SRC]!
>>> +
>>> + // Save the current two tweaks in the tweak buffer
>>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>>> +
>>> + // XOR the next two source blocks with the current two tweaks
>>> + veor \dst_reg, TWEAKV
>>> +
>>> + /*
>>> + * Calculate the next two tweaks by multiplying the current ones by x^2,
>>> + * modulo p(x) = x^64 + x^4 + x^3 + x + 1.
>>> + */
>>> + vshr.u64 \tmp, TWEAKV, #62
>>> + vshl.u64 TWEAKV, #2
>>> + vtbl.8 \tmp\()_L, {GF64MUL_TABLE}, \tmp\()_L
>>> + vtbl.8 \tmp\()_H, {GF64MUL_TABLE}, \tmp\()_H
>>> + veor TWEAKV, \tmp
>>> +.endm
>>> +
>>> +/*
>>> + * _speck_xts_crypt() - Speck-XTS encryption/decryption
>>> + *
>>> + * Encrypt or decrypt NBYTES bytes of data from the SRC buffer to the
>>> DST buffer
>>> + * using Speck-XTS, specifically the variant with a block size of
>>> '2n' and round
>>> + * count given by NROUNDS. The expanded round keys are given in
>>> ROUND_KEYS, and
>>> + * the current XTS tweak value is given in TWEAK. It's assumed that
>>> NBYTES is a
>>> + * nonzero multiple of 128.
>>> + */
>>> +.macro _speck_xts_crypt n, decrypting
>>> + push {r4-r7}
>>> + mov r7, sp
>>> +
>>> + /*
>>> + * The first four parameters were passed in registers r0-r3. Load the
>>> + * additional parameters, which were passed on the stack.
>>> + */
>>> + ldr NBYTES, [sp, #16]
>>> + ldr TWEAK, [sp, #20]
>>> +
>>> + /*
>>> + * If decrypting, modify the ROUND_KEYS parameter to point to the last
>>> + * round key rather than the first, since for decryption the round keys
>>> + * are used in reverse order.
>>> + */
>>> +.if \decrypting
>>> +.if \n == 64
>>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #3
>>> + sub ROUND_KEYS, #8
>>> +.else
>>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #2
>>> + sub ROUND_KEYS, #4
>>> +.endif
>>> +.endif
>>> +
>>> + // Load the index vector for vtbl-based 8-bit rotates
>>> +.if \decrypting
>>> + ldr r12, =.Lrol\n\()_8_table
>>> +.else
>>> + ldr r12, =.Lror\n\()_8_table
>>> +.endif
>>> + vld1.8 {ROTATE_TABLE}, [r12:64]
>>> +
>>> + // One-time XTS preparation
>>> +
>>> + /*
>>> + * Allocate stack space to store 128 bytes worth of tweaks. For
>>> + * performance, this space is aligned to a 16-byte boundary so that we
>>> + * can use the load/store instructions that declare 16-byte alignment.
>>> + */
>>> + sub sp, #128
>>> + bic sp, #0xf
>>
>>
>> This fails here when building with CONFIG_THUMB2_KERNEL=y
>>
>> AS arch/arm/crypto/speck-neon-core.o
>>
>> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>>
>> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
>> `bic sp,#0xf'
>> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
>> `bic sp,#0xf'
>> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
>> `bic sp,#0xf'
>> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
>> `bic sp,#0xf'
>>
>> In a quick hack this change seems to address it:
>>
>>
>> - sub sp, #128
>> - bic sp, #0xf
>> + mov r6, sp
>> + sub r6, #128
>> + bic r6, #0xf
>> + mov sp, r6
>>
>> But there is probably a better solution to address this.
>>
>
> Given that there is no NEON on M class cores, I recommend we put something like
>
> THUMB(bx pc)
> THUMB(nop.w)
> THUMB(.arm)
>
> at the beginning and be done with it.
I mean nop.n or just nop, of course, and we may need a '.align 2' at
the beginning as well.
^ permalink raw reply
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Ard Biesheuvel @ 2018-06-17 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bf0d6851c95b40ca970949229e6e6a00@agner.ch>
On 17 June 2018 at 00:40, Stefan Agner <stefan@agner.ch> wrote:
> Hi Eric,
>
> On 14.02.2018 19:42, Eric Biggers wrote:
>> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
>> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
>> Speck64. Each 128-byte chunk goes through XTS preprocessing, then is
>> encrypted/decrypted (doing one cipher round for all the blocks, then the
>> next round, etc.), then goes through XTS postprocessing.
>>
>> The performance depends on the processor but can be about 3 times faster
>> than the generic code. For example, on an ARMv7 processor we observe
>> the following performance with Speck128/256-XTS:
>>
>> xts-speck128-neon: Encryption 107.9 MB/s, Decryption 108.1 MB/s
>> xts(speck128-generic): Encryption 32.1 MB/s, Decryption 36.6 MB/s
>>
>> In comparison to AES-256-XTS without the Cryptography Extensions:
>>
>> xts-aes-neonbs: Encryption 41.2 MB/s, Decryption 36.7 MB/s
>> xts(aes-asm): Encryption 31.7 MB/s, Decryption 30.8 MB/s
>> xts(aes-generic): Encryption 21.2 MB/s, Decryption 20.9 MB/s
>>
>> Speck64/128-XTS is even faster:
>>
>> xts-speck64-neon: Encryption 138.6 MB/s, Decryption 139.1 MB/s
>>
>> Note that as with the generic code, only the Speck128 and Speck64
>> variants are supported. Also, for now only the XTS mode of operation is
>> supported, to target the disk and file encryption use cases. The NEON
>> code also only handles the portion of the data that is evenly divisible
>> into 128-byte chunks, with any remainder handled by a C fallback. Of
>> course, other modes of operation could be added later if needed, and/or
>> the NEON code could be updated to handle other buffer sizes.
>>
>> The XTS specification is only defined for AES which has a 128-bit block
>> size, so for the GF(2^64) math needed for Speck64-XTS we use the
>> reducing polynomial 'x^64 + x^4 + x^3 + x + 1' given by the original XEX
>> paper. Of course, when possible users should use Speck128-XTS, but even
>> that may be too slow on some processors; Speck64-XTS can be faster.
>>
>> Signed-off-by: Eric Biggers <ebiggers@google.com>
>> ---
>> arch/arm/crypto/Kconfig | 6 +
>> arch/arm/crypto/Makefile | 2 +
>> arch/arm/crypto/speck-neon-core.S | 432 ++++++++++++++++++++++++++++++
>> arch/arm/crypto/speck-neon-glue.c | 288 ++++++++++++++++++++
>> 4 files changed, 728 insertions(+)
>> create mode 100644 arch/arm/crypto/speck-neon-core.S
>> create mode 100644 arch/arm/crypto/speck-neon-glue.c
>>
>> diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
>> index b8e69fe282b8..925d1364727a 100644
>> --- a/arch/arm/crypto/Kconfig
>> +++ b/arch/arm/crypto/Kconfig
>> @@ -121,4 +121,10 @@ config CRYPTO_CHACHA20_NEON
>> select CRYPTO_BLKCIPHER
>> select CRYPTO_CHACHA20
>>
>> +config CRYPTO_SPECK_NEON
>> + tristate "NEON accelerated Speck cipher algorithms"
>> + depends on KERNEL_MODE_NEON
>> + select CRYPTO_BLKCIPHER
>> + select CRYPTO_SPECK
>> +
>> endif
>> diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
>> index 30ef8e291271..a758107c5525 100644
>> --- a/arch/arm/crypto/Makefile
>> +++ b/arch/arm/crypto/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
>> obj-$(CONFIG_CRYPTO_SHA256_ARM) += sha256-arm.o
>> obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
>> obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
>> +obj-$(CONFIG_CRYPTO_SPECK_NEON) += speck-neon.o
>>
>> ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
>> ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
>> @@ -53,6 +54,7 @@ ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
>> crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o
>> crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
>> chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o
>> +speck-neon-y := speck-neon-core.o speck-neon-glue.o
>>
>> quiet_cmd_perl = PERL $@
>> cmd_perl = $(PERL) $(<) > $(@)
>> diff --git a/arch/arm/crypto/speck-neon-core.S
>> b/arch/arm/crypto/speck-neon-core.S
>> new file mode 100644
>> index 000000000000..3c1e203e53b9
>> --- /dev/null
>> +++ b/arch/arm/crypto/speck-neon-core.S
>> @@ -0,0 +1,432 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * NEON-accelerated implementation of Speck128-XTS and Speck64-XTS
>> + *
>> + * Copyright (c) 2018 Google, Inc
>> + *
>> + * Author: Eric Biggers <ebiggers@google.com>
>> + */
>> +
>> +#include <linux/linkage.h>
>> +
>> + .text
>> + .fpu neon
>> +
>> + // arguments
>> + ROUND_KEYS .req r0 // const {u64,u32} *round_keys
>> + NROUNDS .req r1 // int nrounds
>> + DST .req r2 // void *dst
>> + SRC .req r3 // const void *src
>> + NBYTES .req r4 // unsigned int nbytes
>> + TWEAK .req r5 // void *tweak
>> +
>> + // registers which hold the data being encrypted/decrypted
>> + X0 .req q0
>> + X0_L .req d0
>> + X0_H .req d1
>> + Y0 .req q1
>> + Y0_H .req d3
>> + X1 .req q2
>> + X1_L .req d4
>> + X1_H .req d5
>> + Y1 .req q3
>> + Y1_H .req d7
>> + X2 .req q4
>> + X2_L .req d8
>> + X2_H .req d9
>> + Y2 .req q5
>> + Y2_H .req d11
>> + X3 .req q6
>> + X3_L .req d12
>> + X3_H .req d13
>> + Y3 .req q7
>> + Y3_H .req d15
>> +
>> + // the round key, duplicated in all lanes
>> + ROUND_KEY .req q8
>> + ROUND_KEY_L .req d16
>> + ROUND_KEY_H .req d17
>> +
>> + // index vector for vtbl-based 8-bit rotates
>> + ROTATE_TABLE .req d18
>> +
>> + // multiplication table for updating XTS tweaks
>> + GF128MUL_TABLE .req d19
>> + GF64MUL_TABLE .req d19
>> +
>> + // current XTS tweak value(s)
>> + TWEAKV .req q10
>> + TWEAKV_L .req d20
>> + TWEAKV_H .req d21
>> +
>> + TMP0 .req q12
>> + TMP0_L .req d24
>> + TMP0_H .req d25
>> + TMP1 .req q13
>> + TMP2 .req q14
>> + TMP3 .req q15
>> +
>> + .align 4
>> +.Lror64_8_table:
>> + .byte 1, 2, 3, 4, 5, 6, 7, 0
>> +.Lror32_8_table:
>> + .byte 1, 2, 3, 0, 5, 6, 7, 4
>> +.Lrol64_8_table:
>> + .byte 7, 0, 1, 2, 3, 4, 5, 6
>> +.Lrol32_8_table:
>> + .byte 3, 0, 1, 2, 7, 4, 5, 6
>> +.Lgf128mul_table:
>> + .byte 0, 0x87
>> + .fill 14
>> +.Lgf64mul_table:
>> + .byte 0, 0x1b, (0x1b << 1), (0x1b << 1) ^ 0x1b
>> + .fill 12
>> +
>> +/*
>> + * _speck_round_128bytes() - Speck encryption round on 128 bytes at a time
>> + *
>> + * Do one Speck encryption round on the 128 bytes (8 blocks for
>> Speck128, 16 for
>> + * Speck64) stored in X0-X3 and Y0-Y3, using the round key stored in all lanes
>> + * of ROUND_KEY. 'n' is the lane size: 64 for Speck128, or 32 for Speck64.
>> + *
>> + * The 8-bit rotates are implemented using vtbl instead of vshr + vsli because
>> + * the vtbl approach is faster on some processors and the same speed on others.
>> + */
>> +.macro _speck_round_128bytes n
>> +
>> + // x = ror(x, 8)
>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>> +
>> + // x += y
>> + vadd.u\n X0, Y0
>> + vadd.u\n X1, Y1
>> + vadd.u\n X2, Y2
>> + vadd.u\n X3, Y3
>> +
>> + // x ^= k
>> + veor X0, ROUND_KEY
>> + veor X1, ROUND_KEY
>> + veor X2, ROUND_KEY
>> + veor X3, ROUND_KEY
>> +
>> + // y = rol(y, 3)
>> + vshl.u\n TMP0, Y0, #3
>> + vshl.u\n TMP1, Y1, #3
>> + vshl.u\n TMP2, Y2, #3
>> + vshl.u\n TMP3, Y3, #3
>> + vsri.u\n TMP0, Y0, #(\n - 3)
>> + vsri.u\n TMP1, Y1, #(\n - 3)
>> + vsri.u\n TMP2, Y2, #(\n - 3)
>> + vsri.u\n TMP3, Y3, #(\n - 3)
>> +
>> + // y ^= x
>> + veor Y0, TMP0, X0
>> + veor Y1, TMP1, X1
>> + veor Y2, TMP2, X2
>> + veor Y3, TMP3, X3
>> +.endm
>> +
>> +/*
>> + * _speck_unround_128bytes() - Speck decryption round on 128 bytes at a time
>> + *
>> + * This is the inverse of _speck_round_128bytes().
>> + */
>> +.macro _speck_unround_128bytes n
>> +
>> + // y ^= x
>> + veor TMP0, Y0, X0
>> + veor TMP1, Y1, X1
>> + veor TMP2, Y2, X2
>> + veor TMP3, Y3, X3
>> +
>> + // y = ror(y, 3)
>> + vshr.u\n Y0, TMP0, #3
>> + vshr.u\n Y1, TMP1, #3
>> + vshr.u\n Y2, TMP2, #3
>> + vshr.u\n Y3, TMP3, #3
>> + vsli.u\n Y0, TMP0, #(\n - 3)
>> + vsli.u\n Y1, TMP1, #(\n - 3)
>> + vsli.u\n Y2, TMP2, #(\n - 3)
>> + vsli.u\n Y3, TMP3, #(\n - 3)
>> +
>> + // x ^= k
>> + veor X0, ROUND_KEY
>> + veor X1, ROUND_KEY
>> + veor X2, ROUND_KEY
>> + veor X3, ROUND_KEY
>> +
>> + // x -= y
>> + vsub.u\n X0, Y0
>> + vsub.u\n X1, Y1
>> + vsub.u\n X2, Y2
>> + vsub.u\n X3, Y3
>> +
>> + // x = rol(x, 8);
>> + vtbl.8 X0_L, {X0_L}, ROTATE_TABLE
>> + vtbl.8 X0_H, {X0_H}, ROTATE_TABLE
>> + vtbl.8 X1_L, {X1_L}, ROTATE_TABLE
>> + vtbl.8 X1_H, {X1_H}, ROTATE_TABLE
>> + vtbl.8 X2_L, {X2_L}, ROTATE_TABLE
>> + vtbl.8 X2_H, {X2_H}, ROTATE_TABLE
>> + vtbl.8 X3_L, {X3_L}, ROTATE_TABLE
>> + vtbl.8 X3_H, {X3_H}, ROTATE_TABLE
>> +.endm
>> +
>> +.macro _xts128_precrypt_one dst_reg, tweak_buf, tmp
>> +
>> + // Load the next source block
>> + vld1.8 {\dst_reg}, [SRC]!
>> +
>> + // Save the current tweak in the tweak buffer
>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>> +
>> + // XOR the next source block with the current tweak
>> + veor \dst_reg, TWEAKV
>> +
>> + /*
>> + * Calculate the next tweak by multiplying the current one by x,
>> + * modulo p(x) = x^128 + x^7 + x^2 + x + 1.
>> + */
>> + vshr.u64 \tmp, TWEAKV, #63
>> + vshl.u64 TWEAKV, #1
>> + veor TWEAKV_H, \tmp\()_L
>> + vtbl.8 \tmp\()_H, {GF128MUL_TABLE}, \tmp\()_H
>> + veor TWEAKV_L, \tmp\()_H
>> +.endm
>> +
>> +.macro _xts64_precrypt_two dst_reg, tweak_buf, tmp
>> +
>> + // Load the next two source blocks
>> + vld1.8 {\dst_reg}, [SRC]!
>> +
>> + // Save the current two tweaks in the tweak buffer
>> + vst1.8 {TWEAKV}, [\tweak_buf:128]!
>> +
>> + // XOR the next two source blocks with the current two tweaks
>> + veor \dst_reg, TWEAKV
>> +
>> + /*
>> + * Calculate the next two tweaks by multiplying the current ones by x^2,
>> + * modulo p(x) = x^64 + x^4 + x^3 + x + 1.
>> + */
>> + vshr.u64 \tmp, TWEAKV, #62
>> + vshl.u64 TWEAKV, #2
>> + vtbl.8 \tmp\()_L, {GF64MUL_TABLE}, \tmp\()_L
>> + vtbl.8 \tmp\()_H, {GF64MUL_TABLE}, \tmp\()_H
>> + veor TWEAKV, \tmp
>> +.endm
>> +
>> +/*
>> + * _speck_xts_crypt() - Speck-XTS encryption/decryption
>> + *
>> + * Encrypt or decrypt NBYTES bytes of data from the SRC buffer to the
>> DST buffer
>> + * using Speck-XTS, specifically the variant with a block size of
>> '2n' and round
>> + * count given by NROUNDS. The expanded round keys are given in
>> ROUND_KEYS, and
>> + * the current XTS tweak value is given in TWEAK. It's assumed that
>> NBYTES is a
>> + * nonzero multiple of 128.
>> + */
>> +.macro _speck_xts_crypt n, decrypting
>> + push {r4-r7}
>> + mov r7, sp
>> +
>> + /*
>> + * The first four parameters were passed in registers r0-r3. Load the
>> + * additional parameters, which were passed on the stack.
>> + */
>> + ldr NBYTES, [sp, #16]
>> + ldr TWEAK, [sp, #20]
>> +
>> + /*
>> + * If decrypting, modify the ROUND_KEYS parameter to point to the last
>> + * round key rather than the first, since for decryption the round keys
>> + * are used in reverse order.
>> + */
>> +.if \decrypting
>> +.if \n == 64
>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #3
>> + sub ROUND_KEYS, #8
>> +.else
>> + add ROUND_KEYS, ROUND_KEYS, NROUNDS, lsl #2
>> + sub ROUND_KEYS, #4
>> +.endif
>> +.endif
>> +
>> + // Load the index vector for vtbl-based 8-bit rotates
>> +.if \decrypting
>> + ldr r12, =.Lrol\n\()_8_table
>> +.else
>> + ldr r12, =.Lror\n\()_8_table
>> +.endif
>> + vld1.8 {ROTATE_TABLE}, [r12:64]
>> +
>> + // One-time XTS preparation
>> +
>> + /*
>> + * Allocate stack space to store 128 bytes worth of tweaks. For
>> + * performance, this space is aligned to a 16-byte boundary so that we
>> + * can use the load/store instructions that declare 16-byte alignment.
>> + */
>> + sub sp, #128
>> + bic sp, #0xf
>
>
> This fails here when building with CONFIG_THUMB2_KERNEL=y
>
> AS arch/arm/crypto/speck-neon-core.o
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
> `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
> `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
> `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
> `bic sp,#0xf'
>
> In a quick hack this change seems to address it:
>
>
> - sub sp, #128
> - bic sp, #0xf
> + mov r6, sp
> + sub r6, #128
> + bic r6, #0xf
> + mov sp, r6
>
> But there is probably a better solution to address this.
>
Given that there is no NEON on M class cores, I recommend we put something like
THUMB(bx pc)
THUMB(nop.w)
THUMB(.arm)
at the beginning and be done with it.
^ permalink raw reply
* [PATCH v2] drm/atmel-hlcdc: check stride values in the first plane
From: Boris Brezillon @ 2018-06-17 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617084826.31885-1-stefan@agner.ch>
On Sun, 17 Jun 2018 10:48:22 +0200
Stefan Agner <stefan@agner.ch> wrote:
> The statement always evaluates to true since the struct fields
> are arrays. This has shown up as a warning when compiling with
> clang:
> warning: address of array 'desc->layout.xstride' will always
> evaluate to 'true' [-Wpointer-bool-conversion]
>
> Check for values in the first plane instead.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
I'll add
Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
Cc: stable at vger.kernel.org
when applying.
Thanks,
Boris
> ---
> Changes in v2:
> - Check for first value instead of dropping if statement
> (subject was: drm/atmel-hlcdc: remove unnecessary if statement)
>
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 73c875db45f4..47e0992f3908 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -839,7 +839,7 @@ static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane)
> return ret;
> }
>
> - if (desc->layout.xstride && desc->layout.pstride) {
> + if (desc->layout.xstride[0] && desc->layout.pstride[0]) {
> int ret;
>
> ret = drm_plane_create_rotation_property(&plane->base,
^ 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