* [PATCH v3] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Mathieu Malaterre @ 2018-05-03 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502201153.7459-1-malat@debian.org>
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following command:
find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@\1 {/g" {} +
For simplicity, two sed expressions were used to solve each warnings separately.
To make the regex expression more robust a few other issues were resolved,
namely setting unit-address to lower case, and adding a whitespace before the
the opening curly brace:
https://elinux.org/Device_Tree_Linux#Linux_conventions
This will solve as a side effect warning:
Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
Reported-by: David Daney <ddaney@caviumnetworks.com>
Suggested-by: Rob Herring <robh@kernel.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v3: remove extra 0 preventing correct fixup
v2: intermediate patch contained unrelated changes. restrict to S3 and Exynos*
arch/arm/boot/dts/exynos5420.dtsi | 36 +++++++++++++--------------
arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
arch/arm/boot/dts/s3c2416.dtsi | 8 +++---
3 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 2f3cb2a97f71..633952a96427 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -761,7 +761,7 @@
#include "exynos5420-tmu-sensor-conf.dtsi"
};
- sysmmu_g2dr: sysmmu at 0x10A60000 {
+ sysmmu_g2dr: sysmmu at 10a60000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x10A60000 0x1000>;
interrupt-parent = <&combiner>;
@@ -771,7 +771,7 @@
#iommu-cells = <0>;
};
- sysmmu_g2dw: sysmmu at 0x10A70000 {
+ sysmmu_g2dw: sysmmu at 10a70000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x10A70000 0x1000>;
interrupt-parent = <&combiner>;
@@ -781,7 +781,7 @@
#iommu-cells = <0>;
};
- sysmmu_tv: sysmmu at 0x14650000 {
+ sysmmu_tv: sysmmu at 14650000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x14650000 0x1000>;
interrupt-parent = <&combiner>;
@@ -792,7 +792,7 @@
#iommu-cells = <0>;
};
- sysmmu_gscl0: sysmmu at 0x13E80000 {
+ sysmmu_gscl0: sysmmu at 13e80000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13E80000 0x1000>;
interrupt-parent = <&combiner>;
@@ -803,7 +803,7 @@
#iommu-cells = <0>;
};
- sysmmu_gscl1: sysmmu at 0x13E90000 {
+ sysmmu_gscl1: sysmmu at 13e90000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13E90000 0x1000>;
interrupt-parent = <&combiner>;
@@ -814,7 +814,7 @@
#iommu-cells = <0>;
};
- sysmmu_scaler0r: sysmmu at 0x12880000 {
+ sysmmu_scaler0r: sysmmu at 12880000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x12880000 0x1000>;
interrupt-parent = <&combiner>;
@@ -824,7 +824,7 @@
#iommu-cells = <0>;
};
- sysmmu_scaler1r: sysmmu at 0x12890000 {
+ sysmmu_scaler1r: sysmmu at 12890000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x12890000 0x1000>;
interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
@@ -833,7 +833,7 @@
#iommu-cells = <0>;
};
- sysmmu_scaler2r: sysmmu at 0x128A0000 {
+ sysmmu_scaler2r: sysmmu at 128a0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x128A0000 0x1000>;
interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
@@ -842,7 +842,7 @@
#iommu-cells = <0>;
};
- sysmmu_scaler0w: sysmmu at 0x128C0000 {
+ sysmmu_scaler0w: sysmmu at 128c0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x128C0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -852,7 +852,7 @@
#iommu-cells = <0>;
};
- sysmmu_scaler1w: sysmmu at 0x128D0000 {
+ sysmmu_scaler1w: sysmmu at 128d0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x128D0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -862,7 +862,7 @@
#iommu-cells = <0>;
};
- sysmmu_scaler2w: sysmmu at 0x128E0000 {
+ sysmmu_scaler2w: sysmmu at 128e0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x128E0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -872,7 +872,7 @@
#iommu-cells = <0>;
};
- sysmmu_rotator: sysmmu at 0x11D40000 {
+ sysmmu_rotator: sysmmu at 11d40000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11D40000 0x1000>;
interrupt-parent = <&combiner>;
@@ -882,7 +882,7 @@
#iommu-cells = <0>;
};
- sysmmu_jpeg0: sysmmu at 0x11F10000 {
+ sysmmu_jpeg0: sysmmu at 11f10000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11F10000 0x1000>;
interrupt-parent = <&combiner>;
@@ -892,7 +892,7 @@
#iommu-cells = <0>;
};
- sysmmu_jpeg1: sysmmu at 0x11F20000 {
+ sysmmu_jpeg1: sysmmu at 11f20000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11F20000 0x1000>;
interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
@@ -901,7 +901,7 @@
#iommu-cells = <0>;
};
- sysmmu_mfc_l: sysmmu at 0x11200000 {
+ sysmmu_mfc_l: sysmmu at 11200000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11200000 0x1000>;
interrupt-parent = <&combiner>;
@@ -912,7 +912,7 @@
#iommu-cells = <0>;
};
- sysmmu_mfc_r: sysmmu at 0x11210000 {
+ sysmmu_mfc_r: sysmmu at 11210000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11210000 0x1000>;
interrupt-parent = <&combiner>;
@@ -923,7 +923,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimd1_0: sysmmu at 0x14640000 {
+ sysmmu_fimd1_0: sysmmu at 14640000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x14640000 0x1000>;
interrupt-parent = <&combiner>;
@@ -934,7 +934,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimd1_1: sysmmu at 0x14680000 {
+ sysmmu_fimd1_1: sysmmu at 14680000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x14680000 0x1000>;
interrupt-parent = <&combiner>;
diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index d31249f25ccf..2f4f40882dab 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -23,7 +23,7 @@
stdout-path = "serial2:115200n8";
};
- firmware at 02073000 {
+ firmware at 2073000 {
compatible = "samsung,secure-firmware";
reg = <0x02073000 0x1000>;
};
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
index 3c7385cab248..46cf85f3c18b 100644
--- a/arch/arm/boot/dts/s3c2416.dtsi
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -30,7 +30,7 @@
compatible = "samsung,s3c2416-irq";
};
- clocks: clock-controller at 0x4c000000 {
+ clocks: clock-controller at 4c000000 {
compatible = "samsung,s3c2416-clock";
reg = <0x4c000000 0x40>;
#clock-cells = <1>;
@@ -69,7 +69,7 @@
<&clocks SCLK_UART>;
};
- uart_3: serial at 5000C000 {
+ uart_3: serial at 5000c000 {
compatible = "samsung,s3c2440-uart";
reg = <0x5000C000 0x4000>;
interrupts = <1 18 24 4>, <1 18 25 4>;
@@ -80,7 +80,7 @@
status = "disabled";
};
- sdhci_1: sdhci at 4AC00000 {
+ sdhci_1: sdhci at 4ac00000 {
compatible = "samsung,s3c6410-sdhci";
reg = <0x4AC00000 0x100>;
interrupts = <0 0 21 3>;
@@ -91,7 +91,7 @@
status = "disabled";
};
- sdhci_0: sdhci at 4A800000 {
+ sdhci_0: sdhci at 4a800000 {
compatible = "samsung,s3c6410-sdhci";
reg = <0x4A800000 0x100>;
interrupts = <0 0 20 3>;
--
2.11.0
^ permalink raw reply related
* [PATCH v2] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Mathieu Malaterre @ 2018-05-03 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503163502.vh56ggagsirklpfe@kozik-lap>
On Thu, May 3, 2018 at 6:35 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, May 02, 2018 at 10:11:52PM +0200, Mathieu Malaterre wrote:
>> Improve the DTS files by removing all the leading "0x" and zeros to fix the
>> following dtc warnings:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>>
>> and
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> ... and dropped because apparently it does not work in all cases:
>
> arch/arm/boot/dts/exynos5422-odroidhc1.dtb: Warning (unit_address_format): /firmware at 02073000: unit name should not have leading 0s
>
> Can you check why these were not fixed?
My sed expression is not capable of handling @0 or @0,0. I've fixed it
using an updated find + sed expression but this creates lots of
incorrect changes in other files.
Thanks,
> Best regards,
> Krzysztof
>
>>
>> Converted using the following command:
>>
>> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@0\1 {/g" {} +
>>
>> For simplicity, two sed expressions were used to solve each warnings separately.
>>
>> To make the regex expression more robust a few other issues were resolved,
>> namely setting unit-address to lower case, and adding a whitespace before the
>> the opening curly brace:
>>
>> https://elinux.org/Device_Tree_Linux#Linux_conventions
>>
>> This will solve as a side effect warning:
>>
>> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>>
>> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>>
>> Reported-by: David Daney <ddaney@caviumnetworks.com>
>> Suggested-by: Rob Herring <robh@kernel.org>
>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> v2: intermediate patch contained unrelated changes. restrict to S3 and Exynos*
>>
>> arch/arm/boot/dts/exynos5420.dtsi | 36 ++++++++++++++++++------------------
>> arch/arm/boot/dts/s3c2416.dtsi | 8 ++++----
>> 2 files changed, 22 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>> index 2f3cb2a97f71..633952a96427 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -761,7 +761,7 @@
>> #include "exynos5420-tmu-sensor-conf.dtsi"
>> };
>>
>> - sysmmu_g2dr: sysmmu at 0x10A60000 {
>> + sysmmu_g2dr: sysmmu at 10a60000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x10A60000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -771,7 +771,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_g2dw: sysmmu at 0x10A70000 {
>> + sysmmu_g2dw: sysmmu at 10a70000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x10A70000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -781,7 +781,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_tv: sysmmu at 0x14650000 {
>> + sysmmu_tv: sysmmu at 14650000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x14650000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -792,7 +792,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_gscl0: sysmmu at 0x13E80000 {
>> + sysmmu_gscl0: sysmmu at 13e80000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x13E80000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -803,7 +803,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_gscl1: sysmmu at 0x13E90000 {
>> + sysmmu_gscl1: sysmmu at 13e90000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x13E90000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -814,7 +814,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_scaler0r: sysmmu at 0x12880000 {
>> + sysmmu_scaler0r: sysmmu at 12880000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x12880000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -824,7 +824,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_scaler1r: sysmmu at 0x12890000 {
>> + sysmmu_scaler1r: sysmmu at 12890000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x12890000 0x1000>;
>> interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> @@ -833,7 +833,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_scaler2r: sysmmu at 0x128A0000 {
>> + sysmmu_scaler2r: sysmmu at 128a0000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x128A0000 0x1000>;
>> interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
>> @@ -842,7 +842,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_scaler0w: sysmmu at 0x128C0000 {
>> + sysmmu_scaler0w: sysmmu at 128c0000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x128C0000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -852,7 +852,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_scaler1w: sysmmu at 0x128D0000 {
>> + sysmmu_scaler1w: sysmmu at 128d0000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x128D0000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -862,7 +862,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_scaler2w: sysmmu at 0x128E0000 {
>> + sysmmu_scaler2w: sysmmu at 128e0000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x128E0000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -872,7 +872,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_rotator: sysmmu at 0x11D40000 {
>> + sysmmu_rotator: sysmmu at 11d40000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x11D40000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -882,7 +882,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_jpeg0: sysmmu at 0x11F10000 {
>> + sysmmu_jpeg0: sysmmu at 11f10000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x11F10000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -892,7 +892,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_jpeg1: sysmmu at 0x11F20000 {
>> + sysmmu_jpeg1: sysmmu at 11f20000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x11F20000 0x1000>;
>> interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
>> @@ -901,7 +901,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_mfc_l: sysmmu at 0x11200000 {
>> + sysmmu_mfc_l: sysmmu at 11200000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x11200000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -912,7 +912,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_mfc_r: sysmmu at 0x11210000 {
>> + sysmmu_mfc_r: sysmmu at 11210000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x11210000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -923,7 +923,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_fimd1_0: sysmmu at 0x14640000 {
>> + sysmmu_fimd1_0: sysmmu at 14640000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x14640000 0x1000>;
>> interrupt-parent = <&combiner>;
>> @@ -934,7 +934,7 @@
>> #iommu-cells = <0>;
>> };
>>
>> - sysmmu_fimd1_1: sysmmu at 0x14680000 {
>> + sysmmu_fimd1_1: sysmmu at 14680000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x14680000 0x1000>;
>> interrupt-parent = <&combiner>;
>> diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
>> index 3c7385cab248..46cf85f3c18b 100644
>> --- a/arch/arm/boot/dts/s3c2416.dtsi
>> +++ b/arch/arm/boot/dts/s3c2416.dtsi
>> @@ -30,7 +30,7 @@
>> compatible = "samsung,s3c2416-irq";
>> };
>>
>> - clocks: clock-controller at 0x4c000000 {
>> + clocks: clock-controller at 4c000000 {
>> compatible = "samsung,s3c2416-clock";
>> reg = <0x4c000000 0x40>;
>> #clock-cells = <1>;
>> @@ -69,7 +69,7 @@
>> <&clocks SCLK_UART>;
>> };
>>
>> - uart_3: serial at 5000C000 {
>> + uart_3: serial at 5000c000 {
>> compatible = "samsung,s3c2440-uart";
>> reg = <0x5000C000 0x4000>;
>> interrupts = <1 18 24 4>, <1 18 25 4>;
>> @@ -80,7 +80,7 @@
>> status = "disabled";
>> };
>>
>> - sdhci_1: sdhci at 4AC00000 {
>> + sdhci_1: sdhci at 4ac00000 {
>> compatible = "samsung,s3c6410-sdhci";
>> reg = <0x4AC00000 0x100>;
>> interrupts = <0 0 21 3>;
>> @@ -91,7 +91,7 @@
>> status = "disabled";
>> };
>>
>> - sdhci_0: sdhci at 4A800000 {
>> + sdhci_0: sdhci at 4a800000 {
>> compatible = "samsung,s3c6410-sdhci";
>> reg = <0x4A800000 0x100>;
>> interrupts = <0 0 20 3>;
>> --
>> 2.11.0
>>
^ permalink raw reply
* [PATCH v3] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2018-05-03 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503184454.19131-1-malat@debian.org>
On Thu, May 03, 2018 at 08:44:53PM +0200, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@\1 {/g" {} +
The firmware node is fixed but in my case the command is doing much
more:
- smp-sysram at 0 {
+ smp-sysram@ {
- port at 0 {
+ port@ {
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Mathieu Malaterre @ 2018-05-03 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503185342.zawmhazzvkkdc3ja@kozik-lap>
On Thu, May 3, 2018 at 8:53 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, May 03, 2018 at 08:44:53PM +0200, Mathieu Malaterre wrote:
>> Improve the DTS files by removing all the leading "0x" and zeros to fix the
>> following dtc warnings:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>>
>> and
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>>
>> Converted using the following command:
>>
>> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@\1 {/g" {} +
>
> The firmware node is fixed but in my case the command is doing much
> more:
Looks like I cannot copy/paste correctly, meant to say:
find . -type f \( -iname "*.dts" -o -iname "*.dtsi" \) -exec sed -i
-e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1
{/g" -e "s/@0\+\(.\+\) {/@\1 {/g" {} +
> - smp-sysram at 0 {
> + smp-sysram@ {
>
> - port at 0 {
> + port@ {
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Laura Abbott @ 2018-05-03 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503071917.xm2xvgagvzkworay@salmiak>
On 05/03/2018 12:19 AM, Mark Rutland wrote:
> Hi Laura,
>
> On Wed, May 02, 2018 at 01:33:26PM -0700, Laura Abbott wrote:
>>
>> Implementation of stackleak based heavily on the x86 version
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> Now written in C instead of a bunch of assembly.
>
> This looks neat!
>
> I have a few minor comments below.
>
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index bf825f38d206..0ceea613c65b 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -55,6 +55,9 @@ arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
>> arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
>> arm64-obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
>>
>> +arm64-obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += erase.o
>> +KASAN_SANITIZE_erase.o := n
>
> I suspect we want to avoid the full set of instrumentation suspects here, e.g.
> GKOV, KASAN, UBSAN, and KCOV.
>
>> +
>> obj-y += $(arm64-obj-y) vdso/ probes/
>> obj-m += $(arm64-obj-m)
>> head-y := head.o
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index ec2ee720e33e..3144f1ebdc18 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -401,6 +401,11 @@ tsk .req x28 // current thread_info
>>
>> .text
>>
>> + .macro ERASE_KSTACK
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> + bl erase_kstack
>> +#endif
>> + .endm
>
> Nit: The rest of our asm macros are lower-case -- can we stick to that here?
>
>> /*
>> * Exception vectors.
>> */
>> @@ -906,6 +911,7 @@ ret_to_user:
>> cbnz x2, work_pending
>> finish_ret_to_user:
>> enable_step_tsk x1, x2
>> + ERASE_KSTACK
>> kernel_exit 0
>> ENDPROC(ret_to_user)
>
> I believe we also need this in ret_fast_syscall.
>
> [...]
>
Yeah I had this in previous versions but I managed to out think
myself. I'll add it in with a comment to avoid confusion.
>> +asmlinkage void erase_kstack(void)
>> +{
>> + unsigned long p = current->thread.lowest_stack;
>> + unsigned long boundary = p & ~(THREAD_SIZE - 1);
>> + unsigned long poison = 0;
>> + const unsigned long check_depth = STACKLEAK_POISON_CHECK_DEPTH /
>> + sizeof(unsigned long);
>> +
>> + /*
>> + * Let's search for the poison value in the stack.
>> + * Start from the lowest_stack and go to the bottom.
>> + */
>> + while (p > boundary && poison <= check_depth) {
>> + if (*(unsigned long *)p == STACKLEAK_POISON)
>> + poison++;
>> + else
>> + poison = 0;
>> +
>> + p -= sizeof(unsigned long);
>> + }
>> +
>> + /*
>> + * One long int at the bottom of the thread stack is reserved and
>> + * should not be poisoned (see CONFIG_SCHED_STACK_END_CHECK).
>> + */
>> + if (p == boundary)
>> + p += sizeof(unsigned long);
>
> I wonder if end_of_stack() should be taught about CONFIG_SCHED_STACK_END_CHECK,
> given that's supposed to return the last *usable* long on the stack, and we
> don't account for this elsewhere.
>
> If we did, then IIUC we could do:
>
> unsigned long boundary = (unsigned long)end_of_stack(current);
>
> ... at the start of the function, and not have to worry about this explicitly.
>
>> +
>> +#ifdef CONFIG_STACKLEAK_METRICS
>> + current->thread.prev_lowest_stack = p;
>> +#endif
>> +
>> + /*
>> + * So let's write the poison value to the kernel stack.
>> + * Start from the address in p and move up till the new boundary.
>> + */
>> + boundary = current_stack_pointer;
>
> I worry a little that the compiler can move the SP during a function's
> lifetime, but maybe that's only the case when there are VLAs, or something like
> that?
>
I think that's true and a risk we take writing this in C. Here's
the disassembly on gcc-7.3.1:
ffff00000809d4d8 <erase_kstack>:
ffff00000809d4d8: a9bf7bfd stp x29, x30, [sp, #-16]!
ffff00000809d4dc: d5384100 mrs x0, sp_el0
ffff00000809d4e0: 910003fd mov x29, sp
ffff00000809d4e4: f946e400 ldr x0, [x0, #3528]
ffff00000809d4e8: 9272c404 and x4, x0, #0xffffffffffffc000
ffff00000809d4ec: eb04001f cmp x0, x4
ffff00000809d4f0: 540002c9 b.ls ffff00000809d548 <erase_kstack+0x70> // b.plast
ffff00000809d4f4: d2800003 mov x3, #0x0 // #0
ffff00000809d4f8: 9297ddc5 mov x5, #0xffffffffffff4111 // #-48879
ffff00000809d4fc: 14000008 b ffff00000809d51c <erase_kstack+0x44>
ffff00000809d500: d1002000 sub x0, x0, #0x8
ffff00000809d504: 52800022 mov w2, #0x1 // #1
ffff00000809d508: eb00009f cmp x4, x0
ffff00000809d50c: d2800003 mov x3, #0x0 // #0
ffff00000809d510: 1a9f27e1 cset w1, cc // cc = lo, ul, last
ffff00000809d514: 6a01005f tst w2, w1
ffff00000809d518: 54000180 b.eq ffff00000809d548 <erase_kstack+0x70> // b.none
ffff00000809d51c: f9400001 ldr x1, [x0]
ffff00000809d520: eb05003f cmp x1, x5
ffff00000809d524: 54fffee1 b.ne ffff00000809d500 <erase_kstack+0x28> // b.any
ffff00000809d528: 91000463 add x3, x3, #0x1
ffff00000809d52c: d1002000 sub x0, x0, #0x8
ffff00000809d530: f100407f cmp x3, #0x10
ffff00000809d534: 1a9f87e2 cset w2, ls // ls = plast
ffff00000809d538: eb00009f cmp x4, x0
ffff00000809d53c: 1a9f27e1 cset w1, cc // cc = lo, ul, last
ffff00000809d540: 6a01005f tst w2, w1
ffff00000809d544: 54fffec1 b.ne ffff00000809d51c <erase_kstack+0x44> // b.any
ffff00000809d548: eb00009f cmp x4, x0
ffff00000809d54c: 91002001 add x1, x0, #0x8
ffff00000809d550: 9a800020 csel x0, x1, x0, eq // eq = none
ffff00000809d554: 910003e1 mov x1, sp
ffff00000809d558: d5384102 mrs x2, sp_el0
ffff00000809d55c: f906e840 str x0, [x2, #3536]
ffff00000809d560: cb000023 sub x3, x1, x0
ffff00000809d564: d287ffe2 mov x2, #0x3fff // #16383
ffff00000809d568: eb02007f cmp x3, x2
ffff00000809d56c: 540001a8 b.hi ffff00000809d5a0 <erase_kstack+0xc8> // b.pmore
ffff00000809d570: 9297ddc2 mov x2, #0xffffffffffff4111 // #-48879
ffff00000809d574: eb01001f cmp x0, x1
ffff00000809d578: 54000082 b.cs ffff00000809d588 <erase_kstack+0xb0> // b.hs, b.nlast
ffff00000809d57c: f8008402 str x2, [x0], #8
ffff00000809d580: eb00003f cmp x1, x0
ffff00000809d584: 54ffffc8 b.hi ffff00000809d57c <erase_kstack+0xa4> // b.pmore
ffff00000809d588: 910003e1 mov x1, sp
ffff00000809d58c: d5384100 mrs x0, sp_el0
ffff00000809d590: f906e401 str x1, [x0, #3528]
ffff00000809d594: a8c17bfd ldp x29, x30, [sp], #16
ffff00000809d598: d65f03c0 ret
ffff00000809d59c: d503201f nop
ffff00000809d5a0: d4210000 brk #0x800
ffff00000809d5a4: 00000000 .inst 0x00000000 ; undefined
It looks to be okay although admittedly that's subject to compiler
whims. It might be safer to save the stack pointer almost as soon as
we get into the function and use that?
>> +
>> + BUG_ON(boundary - p >= THREAD_SIZE);
>> +
>> + while (p < boundary) {
>> + *(unsigned long *)p = STACKLEAK_POISON;
>> + p += sizeof(unsigned long);
>> + }
>> +
>> + /* Reset the lowest_stack value for the next syscall */
>> + current->thread.lowest_stack = current_stack_pointer;
>> +}
>
> Once this function returns, its data is left on the stack. Is that not a problem?
>
> No strong feelings either way, but it might be worth mentioning in the commit
> message.
>
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index f08a2ed9db0d..156fa0a0da19 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -364,6 +364,9 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>> p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>> p->thread.cpu_context.sp = (unsigned long)childregs;
>>
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> + p->thread.lowest_stack = (unsigned long)task_stack_page(p);
>
> Nit: end_of_stack(p) would be slightly better semantically, even though
> currently equivalent to task_stack_page(p).
>
> [...]
>
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +void __used check_alloca(unsigned long size)
>> +{
>> + unsigned long sp, stack_left;
>> +
>> + sp = current_stack_pointer;
>> +
>> + stack_left = sp & (THREAD_SIZE - 1);
>> + BUG_ON(stack_left < 256 || size >= stack_left - 256);
>> +}
>
> Is this arbitrary, or is there something special about 256?
>
> Even if this is arbitrary, can we give it some mnemonic?
>
>> +EXPORT_SYMBOL(check_alloca);
>> +#endif
>> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
>> index a34e9290a699..25dd2a14560d 100644
>> --- a/drivers/firmware/efi/libstub/Makefile
>> +++ b/drivers/firmware/efi/libstub/Makefile
>> @@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB) += -I$(srctree)/scripts/dtc/libfdt
>> KBUILD_CFLAGS := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
>> -D__NO_FORTIFY \
>> $(call cc-option,-ffreestanding) \
>> - $(call cc-option,-fno-stack-protector)
>> + $(call cc-option,-fno-stack-protector) \
>> + $(DISABLE_STACKLEAK_PLUGIN)
>>
>> GCOV_PROFILE := n
>> KASAN_SANITIZE := n
>
> I believe we'll also need to do this for the KVM hyp code in arch/arm64/kvm/hyp/.
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [PATCH v3] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2018-05-03 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+7wUswQDXZTXWFd=mwo8ehFxHkOp0UA-RuO_fVBzoj-7mutSg@mail.gmail.com>
On Thu, May 3, 2018 at 8:58 PM, Mathieu Malaterre <malat@debian.org> wrote:
> On Thu, May 3, 2018 at 8:53 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Thu, May 03, 2018 at 08:44:53PM +0200, Mathieu Malaterre wrote:
>>> Improve the DTS files by removing all the leading "0x" and zeros to fix the
>>> following dtc warnings:
>>>
>>> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>>>
>>> and
>>>
>>> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>>>
>>> Converted using the following command:
>>>
>>> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@\1 {/g" {} +
>>
>> The firmware node is fixed but in my case the command is doing much
>> more:
>
> Looks like I cannot copy/paste correctly, meant to say:
>
> find . -type f \( -iname "*.dts" -o -iname "*.dtsi" \) -exec sed -i
> -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1
> {/g" -e "s/@0\+\(.\+\) {/@\1 {/g" {} +
I split it with backslash and this worked fine. I'll update the commit
message, thanks!
BR,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Laura Abbott @ 2018-05-03 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd6ad26c-1d2c-88f3-8f01-e68d2b31d6ea@linux.com>
On 05/03/2018 10:33 AM, Alexander Popov wrote:
> Hello Mark and Laura,
>
> Let me join the discussion. Mark, thanks for your feedback!
>
> On 03.05.2018 10:19, Mark Rutland wrote:
>> Hi Laura,
>>
>> On Wed, May 02, 2018 at 01:33:26PM -0700, Laura Abbott wrote:
>>>
>>> Implementation of stackleak based heavily on the x86 version
>>>
>>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>>> ---
>>> Now written in C instead of a bunch of assembly.
>>
>> This looks neat!
>>
>> I have a few minor comments below.
>>
>>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>>> index bf825f38d206..0ceea613c65b 100644
>>> --- a/arch/arm64/kernel/Makefile
>>> +++ b/arch/arm64/kernel/Makefile
>>> @@ -55,6 +55,9 @@ arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
>>> arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
>>> arm64-obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
>>>
>>> +arm64-obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += erase.o
>>> +KASAN_SANITIZE_erase.o := n
>>
>> I suspect we want to avoid the full set of instrumentation suspects here, e.g.
>> GKOV, KASAN, UBSAN, and KCOV.
>
> I've disabled KASAN instrumentation for that file on x86 because erase_kstack()
> intentionally writes to the stack and causes KASAN false positive reports.
>
> But I didn't see any conflicts with other types of instrumentation that you
> mentioned.
>
>>> +
>>> obj-y += $(arm64-obj-y) vdso/ probes/
>>> obj-m += $(arm64-obj-m)
>>> head-y := head.o
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index ec2ee720e33e..3144f1ebdc18 100644
>>> --- a/arch/arm64/kernel/entry.S
>>> +++ b/arch/arm64/kernel/entry.S
>>> @@ -401,6 +401,11 @@ tsk .req x28 // current thread_info
>>>
>>> .text
>>>
>>> + .macro ERASE_KSTACK
>>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> + bl erase_kstack
>>> +#endif
>>> + .endm
>>
>> Nit: The rest of our asm macros are lower-case -- can we stick to that here?
>>
>>> /*
>>> * Exception vectors.
>>> */
>>> @@ -906,6 +911,7 @@ ret_to_user:
>>> cbnz x2, work_pending
>>> finish_ret_to_user:
>>> enable_step_tsk x1, x2
>>> + ERASE_KSTACK
>>> kernel_exit 0
>>> ENDPROC(ret_to_user)
>>
>> I believe we also need this in ret_fast_syscall.
>>
>> [...]
>>
>>> +asmlinkage void erase_kstack(void)
>>> +{
>>> + unsigned long p = current->thread.lowest_stack;
>>> + unsigned long boundary = p & ~(THREAD_SIZE - 1);
>>> + unsigned long poison = 0;
>>> + const unsigned long check_depth = STACKLEAK_POISON_CHECK_DEPTH /
>>> + sizeof(unsigned long);
>>> +
>>> + /*
>>> + * Let's search for the poison value in the stack.
>>> + * Start from the lowest_stack and go to the bottom.
>>> + */
>>> + while (p > boundary && poison <= check_depth) {
>>> + if (*(unsigned long *)p == STACKLEAK_POISON)
>>> + poison++;
>>> + else
>>> + poison = 0;
>>> +
>>> + p -= sizeof(unsigned long);
>>> + }
>>> +
>>> + /*
>>> + * One long int at the bottom of the thread stack is reserved and
>>> + * should not be poisoned (see CONFIG_SCHED_STACK_END_CHECK).
>>> + */
>>> + if (p == boundary)
>>> + p += sizeof(unsigned long);
>>
>> I wonder if end_of_stack() should be taught about CONFIG_SCHED_STACK_END_CHECK,
>> given that's supposed to return the last *usable* long on the stack, and we
>> don't account for this elsewhere.
>
> I would be afraid to change the meaning of end_of_stack()... Currently it
> considers that magic long as usable (include/linux/sched/task_stack.h):
>
> #define task_stack_end_corrupted(task) \
> (*(end_of_stack(task)) != STACK_END_MAGIC)
>
>
>> If we did, then IIUC we could do:
>>
>> unsigned long boundary = (unsigned long)end_of_stack(current);
>>
>> ... at the start of the function, and not have to worry about this explicitly.
>
> I should mention that erase_kstack() can be called from x86 trampoline stack.
> That's why the boundary is calculated from the lowest_stack.
>
>>> +
>>> +#ifdef CONFIG_STACKLEAK_METRICS
>>> + current->thread.prev_lowest_stack = p;
>>> +#endif
>>> +
>>> + /*
>>> + * So let's write the poison value to the kernel stack.
>>> + * Start from the address in p and move up till the new boundary.
>>> + */
>>> + boundary = current_stack_pointer;
>>
>> I worry a little that the compiler can move the SP during a function's
>> lifetime, but maybe that's only the case when there are VLAs, or something like
>> that?
>
> Oh, I don't know.
>
> However, erase_kstack() doesn't call anything except simple inline functions.
> And as I see from its disasm on x86, the local variables reside in registers.
>
>>> +
>>> + BUG_ON(boundary - p >= THREAD_SIZE);
>>> +
>>> + while (p < boundary) {
>>> + *(unsigned long *)p = STACKLEAK_POISON;
>>> + p += sizeof(unsigned long);
>>> + }
>>> +
>>> + /* Reset the lowest_stack value for the next syscall */
>>> + current->thread.lowest_stack = current_stack_pointer;
>
> Laura, that might be wrong and introduce huge performance impact.
>
> I think, lowest_stack should be reset similarly to the original version.
>
Sorry, I'm not understanding here. What's the performance impact and
what do you mean by original version?
>>> +}
>>
>> Once this function returns, its data is left on the stack. Is that not a problem?
>>
>> No strong feelings either way, but it might be worth mentioning in the commit
>> message.
>
> I managed to bypass that with "register" specifier. Although it doesn't give an
> absolute guarantee.
>
I guess I was assuming gcc would be smart enough not to spill stuff
on the stack. I also intentionally removed the register keyword
since it wasn't clear gcc does much with it on a modern system? I
could be completely off base here though so please correct me if
I'm wrong. It probably is worth documenting what we are assuming about
the compiler here.
>>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>>> index f08a2ed9db0d..156fa0a0da19 100644
>>> --- a/arch/arm64/kernel/process.c
>>> +++ b/arch/arm64/kernel/process.c
>>> @@ -364,6 +364,9 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>>> p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>>> p->thread.cpu_context.sp = (unsigned long)childregs;
>>>
>>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> + p->thread.lowest_stack = (unsigned long)task_stack_page(p);
>>
>> Nit: end_of_stack(p) would be slightly better semantically, even though
>> currently equivalent to task_stack_page(p).
>
> Thanks, I agree, I'll fix it in v12.
>
>> [...]
>>
>>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> +void __used check_alloca(unsigned long size)
>>> +{
>>> + unsigned long sp, stack_left;
>>> +
>>> + sp = current_stack_pointer;
>>> +
>>> + stack_left = sp & (THREAD_SIZE - 1);
>>> + BUG_ON(stack_left < 256 || size >= stack_left - 256);
>>> +}
>>
>> Is this arbitrary, or is there something special about 256?
>>
>> Even if this is arbitrary, can we give it some mnemonic?
>
> It's just a reasonable number. We can introduce a macro for it.
>
>>> +EXPORT_SYMBOL(check_alloca);
>>> +#endif
>>> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
>>> index a34e9290a699..25dd2a14560d 100644
>>> --- a/drivers/firmware/efi/libstub/Makefile
>>> +++ b/drivers/firmware/efi/libstub/Makefile
>>> @@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB) += -I$(srctree)/scripts/dtc/libfdt
>>> KBUILD_CFLAGS := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
>>> -D__NO_FORTIFY \
>>> $(call cc-option,-ffreestanding) \
>>> - $(call cc-option,-fno-stack-protector)
>>> + $(call cc-option,-fno-stack-protector) \
>>> + $(DISABLE_STACKLEAK_PLUGIN)
>>>
>>> GCOV_PROFILE := n
>>> KASAN_SANITIZE := n
>>
>> I believe we'll also need to do this for the KVM hyp code in arch/arm64/kvm/hyp/.
>
> Could you please give more details on that? Why STACKLEAK breaks it?
>
For reference, I originally added this for the efistub because
it would not compile. I did compile this against my Fedora tree
which has KVM enabled.
> Thanks a lot!
>
> Best regards,
> Alexander
>
Thanks,
Laura
^ permalink raw reply
* [PATCH v3] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2018-05-03 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503184454.19131-1-malat@debian.org>
On Thu, May 03, 2018 at 08:44:53PM +0200, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@\1 {/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v3: remove extra 0 preventing correct fixup
> v2: intermediate patch contained unrelated changes. restrict to S3 and Exynos*
>
> arch/arm/boot/dts/exynos5420.dtsi | 36 +++++++++++++--------------
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
> arch/arm/boot/dts/s3c2416.dtsi | 8 +++---
> 3 files changed, 23 insertions(+), 23 deletions(-)
>
Thanks, applied after running the command to include few more changes.
Best regards,
Krzysztof
^ permalink raw reply
* Droid 4: very confusing config around OHCI_OMAP3_HCD
From: Pavel Machek @ 2018-05-03 19:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
For power management experiments, I tried
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_OMAP3=m
CONFIG_USB_OHCI_HCD_PLATFORM=y
and could not find resulting .ko.
Help text says:
CONFIG_USB_OHCI_HCD_OMAP3:
This option is deprecated now and the driver was removed, use
USB_OHCI_HCD_PLATFORM instead.
Enables support for the on-chip OHCI controller on
OMAP3 and later chips.
Which may partly explain it. But if the option no longer does
anything, why keep it? Certainly second part is confusing if option is
NOP...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/4585a41e/attachment.sig>
^ permalink raw reply
* Droid 4: very confusing config around OHCI_OMAP3_HCD
From: Tony Lindgren @ 2018-05-03 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503192510.GB32572@amd>
* Pavel Machek <pavel@ucw.cz> [180503 19:27]:
> Hi!
>
> For power management experiments, I tried
>
> CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_HCD_OMAP3=m
> CONFIG_USB_OHCI_HCD_PLATFORM=y
>
> and could not find resulting .ko.
>
> Help text says:
>
> CONFIG_USB_OHCI_HCD_OMAP3:
>
> This option is deprecated now and the driver was removed, use
> USB_OHCI_HCD_PLATFORM instead.
>
> Enables support for the on-chip OHCI controller on
> OMAP3 and later chips.
>
> Which may partly explain it. But if the option no longer does
> anything, why keep it? Certainly second part is confusing if option is
> NOP...
Yeah it's ohci-platform now, I think we decided to keep the old one
around to avoid breaking people's .config files for booting rather
than silently fail.
Regards,
Tony
^ permalink raw reply
* Droid 4: very confusing config around OHCI_OMAP3_HCD
From: Pavel Machek @ 2018-05-03 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503192838.GY98604@atomide.com>
On Thu 2018-05-03 12:28:38, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [180503 19:27]:
> > Hi!
> >
> > For power management experiments, I tried
> >
> > CONFIG_USB_OHCI_HCD=y
> > CONFIG_USB_OHCI_HCD_OMAP3=m
> > CONFIG_USB_OHCI_HCD_PLATFORM=y
> >
> > and could not find resulting .ko.
> >
> > Help text says:
> >
> > CONFIG_USB_OHCI_HCD_OMAP3:
> >
> > This option is deprecated now and the driver was removed, use
> > USB_OHCI_HCD_PLATFORM instead.
> >
> > Enables support for the on-chip OHCI controller on
> > OMAP3 and later chips.
> >
> > Which may partly explain it. But if the option no longer does
> > anything, why keep it? Certainly second part is confusing if option is
> > NOP...
>
> Yeah it's ohci-platform now, I think we decided to keep the old one
> around to avoid breaking people's .config files for booting rather
> than silently fail.
Ok, what about this? (Should I do the same for the other drivers?)
Or at least put (DEPRECATED) as other drivers do?
Situation is quite confusing if you already have PLATFORM=y. OMAP=m
can be selected, but nothing happens.
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5d958da..67c151a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -455,7 +455,7 @@ config USB_OHCI_HCD_AT91
Atmel chips.
config USB_OHCI_HCD_OMAP3
- tristate "OHCI support for OMAP3 and later chips"
+ tristate "dummy option for backwards compatibility"
depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
select USB_OHCI_HCD_PLATFORM
default y
@@ -463,9 +463,6 @@ config USB_OHCI_HCD_OMAP3
This option is deprecated now and the driver was removed, use
USB_OHCI_HCD_PLATFORM instead.
- Enables support for the on-chip OHCI controller on
- OMAP3 and later chips.
-
config USB_OHCI_HCD_DAVINCI
tristate "OHCI support for TI DaVinci DA8xx"
depends on ARCH_DAVINCI_DA8XX
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/9205ad12/attachment.sig>
^ permalink raw reply related
* [PATCH v2 07/27] coresight: tmc: Hide trace buffer handling for file read
From: Mathieu Poirier @ 2018-05-03 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525165857-11096-8-git-send-email-suzuki.poulose@arm.com>
On Tue, May 01, 2018 at 10:10:37AM +0100, Suzuki K Poulose wrote:
> At the moment we adjust the buffer pointers for reading the trace
> data via misc device in the common code for ETF/ETB and ETR. Since
> we are going to change how we manage the buffer for ETR, let us
> move the buffer manipulation to the respective driver files, hiding
> it from the common code. We do so by adding type specific helpers
> for finding the length of data and the pointer to the buffer,
> for a given length at a file position.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 18 +++++++++++
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 34 ++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-tmc.c | 41 ++++++++++++++-----------
> drivers/hwtracing/coresight/coresight-tmc.h | 4 +++
> 4 files changed, 79 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index e2513b7..2113e93 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -120,6 +120,24 @@ static void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
> CS_LOCK(drvdata->base);
> }
>
> +/*
> + * Return the available trace data in the buffer from @pos, with
> + * a maximum limit of @len, updating the @bufpp on where to
> + * find it.
> + */
> +ssize_t tmc_etb_get_sysfs_trace(struct tmc_drvdata *drvdata,
> + loff_t pos, size_t len, char **bufpp)
> +{
> + ssize_t actual = len;
> +
> + /* Adjust the len to available size @pos */
> + if (pos + actual > drvdata->len)
> + actual = drvdata->len - pos;
> + if (actual > 0)
> + *bufpp = drvdata->buf + pos;
> + return actual;
> +}
> +
> static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev)
> {
> int ret = 0;
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index bff46f2..53a17a8 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -92,6 +92,40 @@ static void tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
> CS_LOCK(drvdata->base);
> }
>
> +/*
> + * Return the available trace data in the buffer @pos, with a maximum
> + * limit of @len, also updating the @bufpp on where to find it.
> + */
> +ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
> + loff_t pos, size_t len, char **bufpp)
> +{
> + ssize_t actual = len;
> + char *bufp = drvdata->buf + pos;
> + char *bufend = (char *)(drvdata->vaddr + drvdata->size);
> +
> + /* Adjust the len to available size @pos */
> + if (pos + actual > drvdata->len)
> + actual = drvdata->len - pos;
> +
> + if (actual <= 0)
> + return actual;
> +
> + /*
> + * Since we use a circular buffer, with trace data starting
> + * @drvdata->buf, possibly anywhere in the buffer @drvdata->vaddr,
> + * wrap the current @pos to within the buffer.
> + */
> + if (bufp >= bufend)
> + bufp -= drvdata->size;
> + /*
> + * For simplicity, avoid copying over a wrapped around buffer.
> + */
> + if ((bufp + actual) > bufend)
> + actual = bufend - bufp;
> + *bufpp = bufp;
> + return actual;
> +}
> +
> static void tmc_etr_dump_hw(struct tmc_drvdata *drvdata)
> {
> const u32 *barrier;
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index 0ea04f5..7a4e84f 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -131,35 +131,40 @@ static int tmc_open(struct inode *inode, struct file *file)
> return 0;
> }
>
> +static inline ssize_t tmc_get_sysfs_trace(struct tmc_drvdata *drvdata,
> + loff_t pos, size_t len, char **bufpp)
> +{
> + switch (drvdata->config_type) {
> + case TMC_CONFIG_TYPE_ETB:
> + case TMC_CONFIG_TYPE_ETF:
> + return tmc_etb_get_sysfs_trace(drvdata, pos, len, bufpp);
> + case TMC_CONFIG_TYPE_ETR:
> + return tmc_etr_get_sysfs_trace(drvdata, pos, len, bufpp);
> + }
> +
> + return -EINVAL;
Extra space betwen return and -EINVAL.
> +}
> +
> static ssize_t tmc_read(struct file *file, char __user *data, size_t len,
> loff_t *ppos)
> {
> + char *bufp;
> + ssize_t actual;
> struct tmc_drvdata *drvdata = container_of(file->private_data,
> struct tmc_drvdata, miscdev);
> - char *bufp = drvdata->buf + *ppos;
> + actual = tmc_get_sysfs_trace(drvdata, *ppos, len, &bufp);
> + if (actual <= 0)
> + return 0;
>
> - if (*ppos + len > drvdata->len)
> - len = drvdata->len - *ppos;
> -
> - if (drvdata->config_type == TMC_CONFIG_TYPE_ETR) {
> - if (bufp == (char *)(drvdata->vaddr + drvdata->size))
> - bufp = drvdata->vaddr;
> - else if (bufp > (char *)(drvdata->vaddr + drvdata->size))
> - bufp -= drvdata->size;
> - if ((bufp + len) > (char *)(drvdata->vaddr + drvdata->size))
> - len = (char *)(drvdata->vaddr + drvdata->size) - bufp;
> - }
> -
> - if (copy_to_user(data, bufp, len)) {
> + if (copy_to_user(data, bufp, actual)) {
> dev_dbg(drvdata->dev, "%s: copy_to_user failed\n", __func__);
> return -EFAULT;
> }
>
> - *ppos += len;
> + *ppos += actual;
> + dev_dbg(drvdata->dev, "%zu bytes copied\n", actual);
>
> - dev_dbg(drvdata->dev, "%s: %zu bytes copied, %d bytes left\n",
> - __func__, len, (int)(drvdata->len - *ppos));
> - return len;
> + return actual;
> }
>
> static int tmc_release(struct inode *inode, struct file *file)
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index cdff853..9cbc4d5 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -184,10 +184,14 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata);
> extern const struct coresight_ops tmc_etb_cs_ops;
> extern const struct coresight_ops tmc_etf_cs_ops;
>
> +ssize_t tmc_etb_get_sysfs_trace(struct tmc_drvdata *drvdata,
> + loff_t pos, size_t len, char **bufpp);
> /* ETR functions */
> int tmc_read_prepare_etr(struct tmc_drvdata *drvdata);
> int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata);
> extern const struct coresight_ops tmc_etr_cs_ops;
> +ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
> + loff_t pos, size_t len, char **bufpp);
>
>
> #define TMC_REG_PAIR(name, lo_off, hi_off) \
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 44/61] rtc: simplify getting .drvdata
From: Alexandre Belloni @ 2018-05-03 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180419140641.27926-45-wsa+renesas@sang-engineering.com>
On 19/04/2018 16:06:14+0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/rtc/rtc-bq4802.c | 6 ++----
> drivers/rtc/rtc-ds1216.c | 6 ++----
> drivers/rtc/rtc-ds1511.c | 9 +++------
> drivers/rtc/rtc-ds1553.c | 15 +++++----------
> drivers/rtc/rtc-ds1685.c | 21 +++++++--------------
> drivers/rtc/rtc-ds1742.c | 6 ++----
> drivers/rtc/rtc-lpc32xx.c | 16 ++++++----------
> drivers/rtc/rtc-m48t59.c | 41 ++++++++++++++++-------------------------
> drivers/rtc/rtc-mv.c | 3 +--
> drivers/rtc/rtc-mxc.c | 21 +++++++--------------
> drivers/rtc/rtc-pcap.c | 15 +++++----------
> drivers/rtc/rtc-sh.c | 15 +++++----------
> drivers/rtc/rtc-stk17ta8.c | 15 +++++----------
> drivers/rtc/rtc-test.c | 3 +--
> drivers/rtc/rtc-zynqmp.c | 10 ++++------
> 15 files changed, 71 insertions(+), 131 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] tty: implement led triggers
From: Uwe Kleine-König @ 2018-05-03 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c1bb915-bd92-4433-61ec-78fdba453396@arm.com>
The rx trigger fires when data is pushed to the ldisc. This is a bit later
than the actual receiving of data but has the nice benefit that it
doesn't need adaption for each driver and isn't in the hot path.
Similarily the tx trigger fires when data taken from the ldisc.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Changes since v1, sent with Message-Id:
20180503100448.1350-1-u.kleine-koenig at pengutronix.de:
- implement tx trigger;
- introduce Kconfig symbol for conditional compilation;
- set trigger to NULL if allocating the name failed to not free random
pointers in case the port struct wasn't zeroed;
- use if/else instead of goto
drivers/tty/Kconfig | 7 +++++++
drivers/tty/tty_buffer.c | 4 ++++
drivers/tty/tty_io.c | 6 ++++++
drivers/tty/tty_port.c | 32 ++++++++++++++++++++++++++++++++
include/linux/tty.h | 7 +++++++
5 files changed, 56 insertions(+)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 0840d27381ea..07a2fb05439f 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -41,6 +41,13 @@ config VT
If unsure, say Y, or else you won't be able to do much with your new
shiny Linux system :-)
+config TTY_LEDS_TRIGGER
+ bool "Enable support for TTY actions making LEDs blink"
+ depends on LEDS_TRIGGERS
+ ---help---
+ This enable support for tty triggers. It provides two LED triggers
+ (rx and tx) for each TTY.
+
config CONSOLE_TRANSLATIONS
depends on VT
default y
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index c996b6859c5e..4d364b77b1a7 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -17,6 +17,7 @@
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/ratelimit.h>
+#include <linux/leds.h>
#define MIN_TTYB_SIZE 256
@@ -499,6 +500,7 @@ static void flush_to_ldisc(struct work_struct *work)
struct tty_buffer *head = buf->head;
struct tty_buffer *next;
int count;
+ unsigned long delay = 50 /* ms */;
/* Ldisc or user is trying to gain exclusive access */
if (atomic_read(&buf->priority))
@@ -521,6 +523,8 @@ static void flush_to_ldisc(struct work_struct *work)
continue;
}
+ led_trigger_blink_oneshot(port->led_trigger_rx, &delay, &delay, 0);
+
count = receive_buf(port, head, count);
if (!count)
break;
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 7c838b90a31d..2c840f1e1e82 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -83,6 +83,7 @@
#include <linux/timer.h>
#include <linux/ctype.h>
#include <linux/kd.h>
+#include <linux/leds.h>
#include <linux/mm.h>
#include <linux/string.h>
#include <linux/slab.h>
@@ -950,11 +951,16 @@ static inline ssize_t do_tty_write(
/* Do the write .. */
for (;;) {
size_t size = count;
+ unsigned long delay = 50 /* ms */;
+
if (size > chunk)
size = chunk;
ret = -EFAULT;
if (copy_from_user(tty->write_buf, buf, size))
break;
+
+ led_trigger_blink_oneshot(tty->port->led_trigger_tx, &delay, &delay, 0);
+
ret = write(tty, file, tty->write_buf, size);
if (ret <= 0)
break;
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 25d736880013..f042879a597c 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -16,6 +16,7 @@
#include <linux/wait.h>
#include <linux/bitops.h>
#include <linux/delay.h>
+#include <linux/leds.h>
#include <linux/module.h>
#include <linux/serdev.h>
@@ -157,6 +158,30 @@ struct device *tty_port_register_device_attr_serdev(struct tty_port *port,
tty_port_link_device(port, driver, index);
+#ifdef CONFIG_TTY_LEDS_TRIGGER
+ port->led_trigger_rx_name = kasprintf(GFP_KERNEL, "%s%d-rx",
+ driver->name, index);
+ if (port->led_trigger_rx_name) {
+ led_trigger_register_simple(port->led_trigger_rx_name,
+ &port->led_trigger_rx);
+ } else {
+ port->led_trigger_rx = NULL;
+ pr_err("Failed to allocate trigger name for %s%d\n",
+ driver->name, index);
+ }
+
+ port->led_trigger_tx_name = kasprintf(GFP_KERNEL, "%s%d-tx",
+ driver->name, index);
+ if (port->led_trigger_tx_name) {
+ led_trigger_register_simple(port->led_trigger_tx_name,
+ &port->led_trigger_tx);
+ } else {
+ port->led_trigger_tx = NULL;
+ pr_err("Failed to allocate trigger name for %s%d\n",
+ driver->name, index);
+ }
+#endif
+
dev = serdev_tty_port_register(port, device, driver, index);
if (PTR_ERR(dev) != -ENODEV) {
/* Skip creating cdev if we registered a serdev device */
@@ -206,6 +231,13 @@ void tty_port_unregister_device(struct tty_port *port,
if (ret == 0)
return;
+#ifdef CONFIG_TTY_LEDS_TRIGGER
+ led_trigger_unregister_simple(port->led_trigger_rx);
+ kfree(port->led_trigger_rx_name);
+ led_trigger_unregister_simple(port->led_trigger_tx);
+ kfree(port->led_trigger_tx_name);
+#endif
+
tty_unregister_device(driver, index);
}
EXPORT_SYMBOL_GPL(tty_port_unregister_device);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 1dd587ba6d88..b7dc957365b6 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -249,6 +249,13 @@ struct tty_port {
set to size of fifo */
struct kref kref; /* Ref counter */
void *client_data;
+
+#ifdef CONFIG_TTY_LEDS_TRIGGER
+ struct led_trigger *led_trigger_rx;
+ char *led_trigger_rx_name;
+ struct led_trigger *led_trigger_tx;
+ char *led_trigger_tx_name;
+#endif
};
/* tty_port::iflags bits -- use atomic bit ops */
--
2.17.0
^ permalink raw reply related
* [PATCH v2 04/27] coresight: Introduce support for Coresight Addrss Translation Unit
From: Mathieu Poirier @ 2018-05-03 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503173141.GB11425@xps15>
On 3 May 2018 at 11:31, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On Tue, May 01, 2018 at 10:10:34AM +0100, Suzuki K Poulose wrote:
>> Add the initial support for Coresight Address Translation Unit, which
>> augments the TMC in Coresight SoC-600 by providing an improved Scatter
>> Gather mechanism. CATU is always connected to a single TMC-ETR and
>> converts the AXI address with a translated address (from a given SG
>> table with specific format). The CATU should be programmed in pass
>> through mode and enabled if the ETR doesn't translation by CATU.
>>
>> This patch provides mechanism to enable/disable the CATU always in the
>> pass through mode.
>>
>> We reuse the existing ports mechanism to link the TMC-ETR to the
>> connected CATU.
>>
>> i.e, TMC-ETR:output_port0 -> CATU:input_port0
>>
>> Reference manual for CATU component is avilable in version r2p0 of :
>> "Arm Coresight System-on-Chip SoC-600 Technical Reference Manual",
>> under Section 4.9.
>
> Please remove the part about the TRM as it is bound to change.
>
>>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> drivers/hwtracing/coresight/Kconfig | 10 ++
>> drivers/hwtracing/coresight/Makefile | 1 +
>> drivers/hwtracing/coresight/coresight-catu.c | 195 ++++++++++++++++++++++++
>> drivers/hwtracing/coresight/coresight-catu.h | 89 +++++++++++
>> drivers/hwtracing/coresight/coresight-tmc-etr.c | 26 ++++
>> drivers/hwtracing/coresight/coresight-tmc.h | 27 ++++
>> include/linux/coresight.h | 1 +
>> 7 files changed, 349 insertions(+)
>> create mode 100644 drivers/hwtracing/coresight/coresight-catu.c
>> create mode 100644 drivers/hwtracing/coresight/coresight-catu.h
>>
>> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>> index ef9cb3c..21f638f 100644
>> --- a/drivers/hwtracing/coresight/Kconfig
>> +++ b/drivers/hwtracing/coresight/Kconfig
>> @@ -31,6 +31,16 @@ config CORESIGHT_LINK_AND_SINK_TMC
>> complies with the generic implementation of the component without
>> special enhancement or added features.
>>
>> +config CORESIGHT_CATU
>> + bool "Coresight Address Translation Unit (CATU) driver"
>> + depends on CORESIGHT_LINK_AND_SINK_TMC
>> + help
>> + Enable support for the Coresight Address Translation Unit (CATU).
>> + CATU supports a scatter gather table of 4K pages, with forward/backward
>> + lookup. CATU helps TMC ETR to use large physically non-contiguous trace
>> + buffer by translating the addersses used by ETR to the corresponding
>> + physical adderss by looking up the table.
>
> There is a couple of typos in the last sentence.
There's also a typo in the patch title.
>
>> +
>> config CORESIGHT_SINK_TPIU
>> bool "Coresight generic TPIU driver"
>> depends on CORESIGHT_LINKS_AND_SINKS
>> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>> index 61db9dd..41870de 100644
>> --- a/drivers/hwtracing/coresight/Makefile
>> +++ b/drivers/hwtracing/coresight/Makefile
>> @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>> obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
>> obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>> +obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
>> diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
>> new file mode 100644
>> index 0000000..2cd69a6
>> --- /dev/null
>> +++ b/drivers/hwtracing/coresight/coresight-catu.c
>> @@ -0,0 +1,195 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>
> Extra line
>
>> +/*
>> + * Copyright (C) 2017 ARM Limited. All rights reserved.
>
> You sure you don't want to bump this to 2018?
>
>> + *
>> + * Coresight Address Translation Unit support
>> + *
>> + * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/device.h>
>> +#include <linux/amba/bus.h>
>> +#include <linux/io.h>
>> +#include <linux/slab.h>
>
> List in alphabetical order is possible.
>
>> +
>> +#include "coresight-catu.h"
>> +#include "coresight-priv.h"
>> +
>> +#define csdev_to_catu_drvdata(csdev) \
>> + dev_get_drvdata(csdev->dev.parent)
>> +
>> +coresight_simple_reg32(struct catu_drvdata, control, CATU_CONTROL);
>> +coresight_simple_reg32(struct catu_drvdata, status, CATU_STATUS);
>> +coresight_simple_reg32(struct catu_drvdata, mode, CATU_MODE);
>> +coresight_simple_reg32(struct catu_drvdata, axictrl, CATU_AXICTRL);
>> +coresight_simple_reg32(struct catu_drvdata, irqen, CATU_IRQEN);
>> +coresight_simple_reg64(struct catu_drvdata, sladdr,
>> + CATU_SLADDRLO, CATU_SLADDRHI);
>> +coresight_simple_reg64(struct catu_drvdata, inaddr,
>> + CATU_INADDRLO, CATU_INADDRHI);
>> +
>> +static struct attribute *catu_mgmt_attrs[] = {
>> + &dev_attr_control.attr,
>> + &dev_attr_status.attr,
>> + &dev_attr_mode.attr,
>> + &dev_attr_axictrl.attr,
>> + &dev_attr_irqen.attr,
>> + &dev_attr_sladdr.attr,
>> + &dev_attr_inaddr.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group catu_mgmt_group = {
>> + .attrs = catu_mgmt_attrs,
>> + .name = "mgmt",
>> +};
>> +
>> +static const struct attribute_group *catu_groups[] = {
>> + &catu_mgmt_group,
>> + NULL,
>> +};
>> +
>> +
>> +static inline int catu_wait_for_ready(struct catu_drvdata *drvdata)
>> +{
>> + return coresight_timeout(drvdata->base,
>> + CATU_STATUS, CATU_STATUS_READY, 1);
>> +}
>> +
>> +static int catu_enable_hw(struct catu_drvdata *drvdata, void *__unused)
>> +{
>> + u32 control;
>> +
>> + if (catu_wait_for_ready(drvdata))
>> + dev_warn(drvdata->dev, "Timeout while waiting for READY\n");
>> +
>> + control = catu_read_control(drvdata);
>> + if (control & BIT(CATU_CONTROL_ENABLE)) {
>> + dev_warn(drvdata->dev, "CATU is already enabled\n");
>> + return -EBUSY;
>> + }
>> +
>> + control |= BIT(CATU_CONTROL_ENABLE);
>> + catu_write_mode(drvdata, CATU_MODE_PASS_THROUGH);
>> + catu_write_control(drvdata, control);
>> + dev_dbg(drvdata->dev, "Enabled in Pass through mode\n");
>> + return 0;
>> +}
>> +
>> +static int catu_enable(struct coresight_device *csdev, void *data)
>> +{
>> + int rc;
>> + struct catu_drvdata *catu_drvdata = csdev_to_catu_drvdata(csdev);
>> +
>> + CS_UNLOCK(catu_drvdata->base);
>> + rc = catu_enable_hw(catu_drvdata, data);
>> + CS_LOCK(catu_drvdata->base);
>> + return rc;
>> +}
>> +
>> +static int catu_disable_hw(struct catu_drvdata *drvdata)
>> +{
>> + int rc = 0;
>> +
>> + if (catu_wait_for_ready(drvdata)) {
>> + dev_info(drvdata->dev, "Timeout while waiting for READY\n");
>> + rc = -EAGAIN;
>> + }
>> +
>> + catu_write_control(drvdata, 0);
>> + dev_dbg(drvdata->dev, "Disabled\n");
>> + return rc;
>> +}
>> +
>> +static int catu_disable(struct coresight_device *csdev, void *__unused)
>> +{
>> + int rc;
>> + struct catu_drvdata *catu_drvdata = csdev_to_catu_drvdata(csdev);
>> +
>> + CS_UNLOCK(catu_drvdata->base);
>> + rc = catu_disable_hw(catu_drvdata);
>> + CS_LOCK(catu_drvdata->base);
>> +
>
> I suppose you can remove the extra line as catu_enable() doesn't have one.
>
>> + return rc;
>> +}
>> +
>> +const struct coresight_ops_helper catu_helper_ops = {
>> + .enable = catu_enable,
>> + .disable = catu_disable,
>> +};
>> +
>> +const struct coresight_ops catu_ops = {
>> + .helper_ops = &catu_helper_ops,
>> +};
>> +
>> +static int catu_probe(struct amba_device *adev, const struct amba_id *id)
>> +{
>> + int ret = 0;
>> + struct catu_drvdata *drvdata;
>> + struct coresight_desc catu_desc;
>> + struct coresight_platform_data *pdata = NULL;
>> + struct device *dev = &adev->dev;
>> + struct device_node *np = dev->of_node;
>> + void __iomem *base;
>> +
>> + if (np) {
>> + pdata = of_get_coresight_platform_data(dev, np);
>> + if (IS_ERR(pdata)) {
>> + ret = PTR_ERR(pdata);
>> + goto out;
>> + }
>> + dev->platform_data = pdata;
>> + }
>> +
>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>> + if (!drvdata) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + drvdata->dev = dev;
>> + dev_set_drvdata(dev, drvdata);
>> + base = devm_ioremap_resource(dev, &adev->res);
>> + if (IS_ERR(base)) {
>> + ret = PTR_ERR(base);
>> + goto out;
>> + }
>> +
>> + drvdata->base = base;
>> + catu_desc.pdata = pdata;
>> + catu_desc.dev = dev;
>> + catu_desc.groups = catu_groups;
>> + catu_desc.type = CORESIGHT_DEV_TYPE_HELPER;
>> + catu_desc.subtype.helper_subtype = CORESIGHT_DEV_SUBTYPE_HELPER_CATU;
>> + catu_desc.ops = &catu_ops;
>> + drvdata->csdev = coresight_register(&catu_desc);
>> + if (IS_ERR(drvdata->csdev))
>> + ret = PTR_ERR(drvdata->csdev);
>> + if (!ret)
>> + dev_info(drvdata->dev, "initialized\n");
>
> Please remove as it 1) doesn't convey HW related information and 2) the TMC
> doesn't out put anything.
>
>> +out:
>> + pm_runtime_put(&adev->dev);
>> + return ret;
>> +}
>> +
>> +static struct amba_id catu_ids[] = {
>> + {
>> + .id = 0x000bb9ee,
>> + .mask = 0x000fffff,
>> + },
>> + {},
>> +};
>> +
>> +static struct amba_driver catu_driver = {
>> + .drv = {
>> + .name = "coresight-catu",
>> + .owner = THIS_MODULE,
>> + .suppress_bind_attrs = true,
>> + },
>> + .probe = catu_probe,
>> + .id_table = catu_ids,
>> +};
>> +
>> +builtin_amba_driver(catu_driver);
>> diff --git a/drivers/hwtracing/coresight/coresight-catu.h b/drivers/hwtracing/coresight/coresight-catu.h
>> new file mode 100644
>> index 0000000..cd58d6f
>> --- /dev/null
>> +++ b/drivers/hwtracing/coresight/coresight-catu.h
>> @@ -0,0 +1,89 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +
>
> Extra line
>
>> +/*
>> + * Copyright (C) 2017 ARM Limited. All rights reserved.
>> + *
>> + * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
>> + *
>
> Extra line. In coresight-catu.c there isn't one.
>
>> + */
>> +
>> +#ifndef _CORESIGHT_CATU_H
>> +#define _CORESIGHT_CATU_H
>> +
>> +#include "coresight-priv.h"
>> +
>> +/* Register offset from base */
>> +#define CATU_CONTROL 0x000
>> +#define CATU_MODE 0x004
>> +#define CATU_AXICTRL 0x008
>> +#define CATU_IRQEN 0x00c
>> +#define CATU_SLADDRLO 0x020
>> +#define CATU_SLADDRHI 0x024
>> +#define CATU_INADDRLO 0x028
>> +#define CATU_INADDRHI 0x02c
>> +#define CATU_STATUS 0x100
>> +#define CATU_DEVARCH 0xfbc
>> +
>> +#define CATU_CONTROL_ENABLE 0
>> +
>> +#define CATU_MODE_PASS_THROUGH 0U
>> +#define CATU_MODE_TRANSLATE 1U
>> +
>> +#define CATU_STATUS_READY 8
>> +#define CATU_STATUS_ADRERR 0
>> +#define CATU_STATUS_AXIERR 4
>> +
>> +
>
> Extra line.
>
>> +#define CATU_IRQEN_ON 0x1
>> +#define CATU_IRQEN_OFF 0x0
>> +
>> +
>
> Extra line.
>
>> +struct catu_drvdata {
>> + struct device *dev;
>> + void __iomem *base;
>> + struct coresight_device *csdev;
>> + int irq;
>> +};
>> +
>> +#define CATU_REG32(name, offset) \
>> +static inline u32 \
>> +catu_read_##name(struct catu_drvdata *drvdata) \
>> +{ \
>> + return coresight_read_reg_pair(drvdata->base, offset, -1); \
>> +} \
>> +static inline void \
>> +catu_write_##name(struct catu_drvdata *drvdata, u32 val) \
>> +{ \
>> + coresight_write_reg_pair(drvdata->base, val, offset, -1); \
>> +}
>> +
>> +#define CATU_REG_PAIR(name, lo_off, hi_off) \
>> +static inline u64 \
>> +catu_read_##name(struct catu_drvdata *drvdata) \
>> +{ \
>> + return coresight_read_reg_pair(drvdata->base, lo_off, hi_off); \
>> +} \
>> +static inline void \
>> +catu_write_##name(struct catu_drvdata *drvdata, u64 val) \
>> +{ \
>> + coresight_write_reg_pair(drvdata->base, val, lo_off, hi_off); \
>> +}
>> +
>> +CATU_REG32(control, CATU_CONTROL);
>> +CATU_REG32(mode, CATU_MODE);
>> +CATU_REG_PAIR(sladdr, CATU_SLADDRLO, CATU_SLADDRHI)
>> +CATU_REG_PAIR(inaddr, CATU_INADDRLO, CATU_INADDRHI)
>> +
>> +static inline bool coresight_is_catu_device(struct coresight_device *csdev)
>> +{
>> + enum coresight_dev_subtype_helper subtype;
>> +
>> + /* Make the checkpatch happy */
>> + subtype = csdev->subtype.helper_subtype;
>> +
>> + return IS_ENABLED(CONFIG_CORESIGHT_CATU) &&
>> + csdev->type == CORESIGHT_DEV_TYPE_HELPER &&
>> + subtype == CORESIGHT_DEV_SUBTYPE_HELPER_CATU;
>> +}
>> +
>> +#endif
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> index 68fbc8f..9b0c620 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> @@ -17,9 +17,26 @@
>>
>> #include <linux/coresight.h>
>> #include <linux/dma-mapping.h>
>> +#include "coresight-catu.h"
>> #include "coresight-priv.h"
>> #include "coresight-tmc.h"
>>
>> +static inline void tmc_etr_enable_catu(struct tmc_drvdata *drvdata)
>> +{
>> + struct coresight_device *catu = tmc_etr_get_catu_device(drvdata);
>> +
>> + if (catu && helper_ops(catu)->enable)
>> + helper_ops(catu)->enable(catu, NULL);
>> +}
>> +
>> +static inline void tmc_etr_disable_catu(struct tmc_drvdata *drvdata)
>> +{
>> + struct coresight_device *catu = tmc_etr_get_catu_device(drvdata);
>> +
>> + if (catu && helper_ops(catu)->disable)
>> + helper_ops(catu)->disable(catu, NULL);
>> +}
>> +
>> static void tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
>> {
>> u32 axictl, sts;
>> @@ -27,6 +44,12 @@ static void tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
>> /* Zero out the memory to help with debug */
>> memset(drvdata->vaddr, 0, drvdata->size);
>>
>> + /*
>> + * If this ETR is connected to a CATU, enable it before we turn
>> + * this on
>> + */
>> + tmc_etr_enable_catu(drvdata);
>> +
>> CS_UNLOCK(drvdata->base);
>>
>> /* Wait for TMCSReady bit to be set */
>> @@ -116,6 +139,9 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>> tmc_disable_hw(drvdata);
>>
>> CS_LOCK(drvdata->base);
>> +
>> + /* Disable CATU device if this ETR is connected to one */
>> + tmc_etr_disable_catu(drvdata);
>> }
>>
>> static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
>> index 8df7a81..cdff853 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc.h
>> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
>> @@ -19,6 +19,7 @@
>> #define _CORESIGHT_TMC_H
>>
>> #include <linux/miscdevice.h>
>> +#include "coresight-catu.h"
>>
>> #define TMC_RSZ 0x004
>> #define TMC_STS 0x00c
>> @@ -222,4 +223,30 @@ static inline bool tmc_etr_has_cap(struct tmc_drvdata *drvdata, u32 cap)
>> return !!(drvdata->etr_caps & cap);
>> }
>>
>> +/*
>> + * TMC ETR could be connected to a CATU device, which can provide address
>> + * translation service. This is represented by the Output port of the TMC
>> + * (ETR) connected to the input port of the CATU.
>> + *
>> + * Returns : coresight_device ptr for the CATU device if a CATU is found.
>> + * : NULL otherwise.
>> + */
>> +static inline struct coresight_device *
>> +tmc_etr_get_catu_device(struct tmc_drvdata *drvdata)
>> +{
>> + int i;
>> + struct coresight_device *tmp, *etr = drvdata->csdev;
>> +
>> + if (!IS_ENABLED(CONFIG_CORESIGHT_CATU))
>> + return NULL;
>> +
>> + for (i = 0; i < etr->nr_outport; i++) {
>> + tmp = etr->conns[0].child_dev;
>> + if (tmp && coresight_is_catu_device(tmp))
>> + return tmp;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> #endif
>> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>> index 5e926f7..c0e1568 100644
>> --- a/include/linux/coresight.h
>> +++ b/include/linux/coresight.h
>> @@ -72,6 +72,7 @@ enum coresight_dev_subtype_source {
>>
>> enum coresight_dev_subtype_helper {
>> CORESIGHT_DEV_SUBTYPE_HELPER_NONE,
>> + CORESIGHT_DEV_SUBTYPE_HELPER_CATU,
>> };
>>
>> /**
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH v2 10/27] dts: bindings: Restrict coresight tmc-etr scatter-gather mode
From: Mathieu Poirier @ 2018-05-03 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501131300.GA31425@rob-hp-laptop>
On 1 May 2018 at 07:13, Rob Herring <robh@kernel.org> wrote:
> On Tue, May 01, 2018 at 10:10:40AM +0100, Suzuki K Poulose wrote:
>> We are about to add the support for ETR builtin scatter-gather mode
>> for dealing with large amount of trace buffers. However, on some of
>> the platforms, using the ETR SG mode can lock up the system due to
>> the way the ETR is connected to the memory subsystem.
>>
>> In SG mode, the ETR performs READ from the scatter-gather table to
>> fetch the next page and regular WRITE of trace data. If the READ
>> operation doesn't complete(due to the memory subsystem issues,
>> which we have seen on a couple of platforms) the trace WRITE
>> cannot proceed leading to issues. So, we by default do not
>> use the SG mode, unless it is known to be safe on the platform.
>> We define a DT property for the TMC node to specify whether we
>> have a proper SG mode.
>>
>> Cc: Mathieu Poirier <matheiu.poirier@linaro.org>
>> Cc: Mike Leach <mike.leach@linaro.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: John Horley <john.horley@arm.com>
>> Cc: Robert Walker <robert.walker@arm.com>
>> Cc: devicetree at vger.kernel.org
>> Cc: frowand.list at gmail.com
>> Cc: Rob Herring <robh@kernel.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> Documentation/devicetree/bindings/arm/coresight.txt | 3 +++
>> drivers/hwtracing/coresight/coresight-tmc.c | 8 +++++++-
>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
>> index cdd84d0..7c0c8f0 100644
>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>> @@ -88,6 +88,9 @@ its hardware characteristcs.
>> * arm,buffer-size: size of contiguous buffer space for TMC ETR
>> (embedded trace router)
>>
>> + * scatter-gather: boolean. Indicates that the TMC-ETR can safely
>> + use the SG mode on this system.
>> +
>
> Needs a vendor prefix.
>
Thinking further on this, do we need to make it device specific as
well - something like "arm,etr-scatter-gather"? That way we don't
have to redefine "scatter-gather" for other ARM devices if they happen
to need the same property but for different reasons.
>> * Optional property for CATU :
>> * interrupts : Exactly one SPI may be listed for reporting the address
>> error
^ permalink raw reply
* [PATCH v2 12/27] coresight: tmc-etr: Allow commandline option to override SG use
From: Mathieu Poirier @ 2018-05-03 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525165857-11096-13-git-send-email-suzuki.poulose@arm.com>
On Tue, May 01, 2018 at 10:10:42AM +0100, Suzuki K Poulose wrote:
> The Coresight TMC-ETR SG mode could be unsafe on a platform where
> the ETR is not properly connected to account for READ operations.
> We use a DT node property to indicate if the system is safe.
> This patch also provides a command line parameter to "force"
> the use of SG mode to override the firmware information.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Mike Leach <mike.leach@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Hi
>
> This is more of a debug patch for people who may want to
> test their platform without too much of hacking. I am not
> too keen on pushing this patch in.
I am not either nor do I personally need it to test this feature. We can leave
it in for now (and subsequent version) if you need it but we agree that I won't
queue it to my tree when the time comes.
> ---
> Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++
> drivers/hwtracing/coresight/coresight-tmc.c | 7 ++++++-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 11fc28e..03b51c3 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -675,6 +675,14 @@
> Enable/disable the CPU sampling based debugging.
> 0: default value, disable debugging
> 1: enable debugging at boot time
> + coresight_tmc.etr_force_sg
> + [ARM, ARM64]
> + Format: <bool>
> + Force using the TMC ETR builtin scatter-gather mode
> + even when it may be unsafe to use.
> + Default : 0, do not force using the builtin SG mode.
> + 1, Allow using the SG, ignoring the firmware
> + provided information.
>
> cpuidle.off=1 [CPU_IDLE]
> disable the cpuidle sub-system
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index e38379c..c7bc681 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -20,6 +20,7 @@
> #include <linux/err.h>
> #include <linux/fs.h>
> #include <linux/miscdevice.h>
> +#include <linux/module.h>
> #include <linux/property.h>
> #include <linux/uaccess.h>
> #include <linux/slab.h>
> @@ -33,6 +34,8 @@
> #include "coresight-priv.h"
> #include "coresight-tmc.h"
>
> +static bool etr_force_sg;
> +
> void tmc_wait_for_tmcready(struct tmc_drvdata *drvdata)
> {
> /* Ensure formatter, unformatter and hardware fifo are empty */
> @@ -307,7 +310,8 @@ const struct attribute_group *coresight_tmc_groups[] = {
>
> static inline bool tmc_etr_can_use_sg(struct tmc_drvdata *drvdata)
> {
> - return fwnode_property_present(drvdata->dev->fwnode, "scatter-gather");
> + return etr_force_sg ||
> + fwnode_property_present(drvdata->dev->fwnode, "scatter-gather");
> }
>
> /* Detect and initialise the capabilities of a TMC ETR */
> @@ -482,3 +486,4 @@ static struct amba_driver tmc_driver = {
> .id_table = tmc_ids,
> };
> builtin_amba_driver(tmc_driver);
> +module_param(etr_force_sg, bool, 0);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/4] dt-bindings: rtc: update stm32-rtc documentation for st,syscfg property
From: Alexandre Belloni @ 2018-05-03 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180427025803.mn32y5xle2p6knn6@rob-hp-laptop>
Amelie,
On 26/04/2018 21:58:03-0500, Rob Herring wrote:
> On Thu, Apr 19, 2018 at 03:21:42PM +0200, Amelie Delaunay wrote:
> > RTC driver should not be aware of the PWR registers offset and bits
> > position. Furthermore, we can imagine that Disable Backup Protection (DBP)
> > relative register and bit mask could change depending on the SoC. So this
> > patch moves st,syscfg property from single pwrcfg phandle to pwrcfg
> > phandle/offset/mask triplet.
> >
> > Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> > ---
> > Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> > index a66692a..00f8b5d 100644
> > --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> > +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> > @@ -14,8 +14,10 @@ Required properties:
> > It is required only on stm32h7.
> > - interrupt-parent: phandle for the interrupt controller.
> > - interrupts: rtc alarm interrupt.
> > -- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
> > - (RTC registers) write protection.
> > +- st,syscfg: phandle/offset/mask triplet. The phandle to pwrcfg used to
> > + access control register at offset, and change the dbp (Disable Backup
> > + Protection) bit represented by the mask, mandatory to disable/enable backup
> > + domain (RTC registers) write protection.
>
> It's fine to add this, but you are breaking compatibility in the driver
> with existing DTBs by requiring these new fields.
>
I'm fine with that change but I would like confirmation that this has
been well thought. Maybe Maxime or Alexandre could give their ack.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4 0/8] EDAC drivers for Armada XP L2 and DDR
From: Chris Packham @ 2018-05-03 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525338355.17782.21.camel@pengutronix.de>
Hi Jan,
On 03/05/18 21:22, Jan L?bbe wrote:
> Hi Chris,
>
> On Fri, 2018-01-12 at 14:27 +1300, Chris Packham wrote:
>> I've found some time to address Borislav's comments (I think I've got them
>> all). The patches affected are 3/8 and 7/8. The changes are all reasonably
>> cosmetic and I can confirm with the addition of 8/8 that the (mc) EDAC
>> reporting works on Armada-38x.
>>
>> The current plan is for these to go in via the ARM tree once appropriate
>> Reviews/Acks have been given.
>
> I've finally found some time to look at this again. :)
>
> As far as I can see, Borislav has reviewed the edac bits and Rob has
> review the binding for marvell,ecc-enable. I'm not sure where it got
> stuck though. Russell wanted to merge the whole series? Or am i missing
> something?
>
Yes I was expecting it to come in via the ARM tree. It may have got lost
in the noise of the merge window. I checked a few times but I didn't
want to add to the noise.
Given that it's been a while: ping.
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Peter Rosin @ 2018-05-03 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503090648.GG12521@phenom.ffwll.local>
On 2018-05-03 11:06, Daniel Vetter wrote:
> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
>> The more natural approach would perhaps be to add an drm_bridge_add,
>> but there are several other bridges that never call drm_bridge_add.
>> Just removing the drm_bridge_remove is the easier fix.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>
> This mess is much bigger. There's 2 pairs of bridge functions:
>
> - drm_bridge_attach/detach. Those are meant to be called by the overall
> drm driver to connect/disconnect a drm_bridge.
>
> - drm_bridge_add/remove. These are supposed to be called by the bridge
> driver itself to register/unregister itself. Maybe we should rename
> them, since the same issue happens with drm_panel, with the same
> confusion.
>
> I thought someone was working on a cleanup series to fix this mess, but I
> didn't find anything.
Ok, I just spotted the imbalance and didn't really dig into what
actually happens in these error paths. Now that I have done so I
believe that the removed drm_bridge_remove calls causes NULL
dereferences if/when the error paths are triggered.
So, I don't think this can wait for some bigger cleanup.
drm_bridge_remove calls list_del_init calls __list_del_entry calls
__list_del with NULL in both prev and next since the list member
is never initialized. prev and next are dereferenced by __list_del
and you have *boom*
I recommend adding the tag
Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
so that stable picks this one up.
Cheers,
Peter
> -Daniel
>
>> ---
>> drivers/gpu/drm/sti/sti_hda.c | 1 -
>> drivers/gpu/drm/sti/sti_hdmi.c | 1 -
>> 2 files changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
>> index 67bbdb49fffc..199db13f565c 100644
>> --- a/drivers/gpu/drm/sti/sti_hda.c
>> +++ b/drivers/gpu/drm/sti/sti_hda.c
>> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
>> return 0;
>>
>> err_sysfs:
>> - drm_bridge_remove(bridge);
>> return -EINVAL;
>> }
>>
>> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
>> index 58f431102512..932724784942 100644
>> --- a/drivers/gpu/drm/sti/sti_hdmi.c
>> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
>> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
>> return 0;
>>
>> err_sysfs:
>> - drm_bridge_remove(bridge);
>> hdmi->drm_connector = NULL;
>> return -EINVAL;
>> }
>> --
>> 2.11.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* [PATCH] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Eric Anholt @ 2018-05-03 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503180945.3502-1-robh@kernel.org>
Rob Herring <robh@kernel.org> writes:
> 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.
It looks to me like we'd only return IRQ_HANDLED if we did work that
needed doing. Is this check effectively doing some interlock to make
sure that we've already started bcm2835aux_spi_transfer_one_irq() and
aren't just racing against transaction setup?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/566dc920/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: defconfig: Increase CMA size for VC4
From: Eric Anholt @ 2018-05-03 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525296700-3588-1-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> The VC4 needs more memory than the default setting (16 MB):
>
> vc4-drm soc:gpu: swiotlb: coherent allocation failed, size=16777216
> [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12.
> You may need to enable CMA or give it more memory.
> vc4-drm soc:gpu: failed to bind 3fc00000.v3d (ops vc4_v3d_ops [vc4]): -12
> vc4-drm soc:gpu: master bind failed: -12
> vc4-drm: probe of soc:gpu failed with error -12
>
> So increase the value to 32 MB and fix this issue.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
If there was a way to check how big the CMA pool is, then we could
probably have V3D disable itself when the pool was too small. It's not
like V3D rendering is going to actually *work* with just a 32mb pool to
play in.
That said, I'd also be fine with this patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/04dd6dce/attachment.sig>
^ permalink raw reply
* [PATCH 0/3] spi: meson-axg: add few enhanced features
From: Yixun Lan @ 2018-05-03 21:36 UTC (permalink / raw)
To: linux-arm-kernel
Add a few enhanced features for the SPICC controller of Meson-AXG SoC.
These patches are actually quite independent from each other, I send them
together in case to avoid the file conflicts.
Sunny Luo (3):
spi: meson-axg: support MAX 80M clock
spi: meson-axg: enhance output enable feature
spi: meson-axg: add a linear clock divider support
drivers/spi/spi-meson-spicc.c | 270 ++++++++++++++++++++++++++++------
1 file changed, 222 insertions(+), 48 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH 1/3] spi: meson-axg: support MAX 80M clock
From: Yixun Lan @ 2018-05-03 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503213645.20694-1-yixun.lan@amlogic.com>
From: Sunny Luo <sunny.luo@amlogic.com>
The SPICC controller in Meson-AXG is capable of running at 80M clock.
The ASIC IP is improved and the clock is actually running higher than
previous old SoCs.
Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/spi/spi-meson-spicc.c | 37 +++++++++++++++++++++++++++--------
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index 5c82910e3480..8489f4c9f465 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -9,11 +9,13 @@
#include <linux/bitfield.h>
#include <linux/clk.h>
+#include <linux/clk-provider.h>
#include <linux/device.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/spi/spi.h>
#include <linux/types.h>
@@ -34,7 +36,6 @@
* to have a CS go down over the full transfer
*/
-#define SPICC_MAX_FREQ 30000000
#define SPICC_MAX_BURST 128
/* Register Map */
@@ -120,6 +121,10 @@
#define SPICC_BURST_MAX 16
#define SPICC_FIFO_HALF 10
+struct meson_spicc_data {
+ unsigned int max_speed_hz;
+};
+
struct meson_spicc_device {
struct spi_master *master;
struct platform_device *pdev;
@@ -127,6 +132,7 @@ struct meson_spicc_device {
struct clk *core;
struct spi_message *message;
struct spi_transfer *xfer;
+ const struct meson_spicc_data *data;
u8 *tx_buf;
u8 *rx_buf;
unsigned int bytes_per_word;
@@ -517,6 +523,9 @@ static int meson_spicc_probe(struct platform_device *pdev)
spicc->pdev = pdev;
platform_set_drvdata(pdev, spicc);
+ spicc->data = (const struct meson_spicc_data *)
+ of_device_get_match_data(&pdev->dev);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
spicc->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(spicc->base)) {
@@ -567,11 +576,9 @@ static int meson_spicc_probe(struct platform_device *pdev)
master->unprepare_transfer_hardware = meson_spicc_unprepare_transfer;
master->transfer_one = meson_spicc_transfer_one;
- /* Setup max rate according to the Meson GX datasheet */
- if ((rate >> 2) > SPICC_MAX_FREQ)
- master->max_speed_hz = SPICC_MAX_FREQ;
- else
- master->max_speed_hz = rate >> 2;
+ /* Setup max rate according to the Meson datasheet */
+ master->max_speed_hz = min_t(unsigned int, rate >> 1,
+ spicc->data->max_speed_hz);
ret = devm_spi_register_master(&pdev->dev, master);
if (!ret)
@@ -597,9 +604,23 @@ static int meson_spicc_remove(struct platform_device *pdev)
return 0;
}
+static const struct meson_spicc_data meson_spicc_gx_data = {
+ .max_speed_hz = 30000000,
+};
+
+static const struct meson_spicc_data meson_spicc_axg_data = {
+ .max_speed_hz = 80000000,
+};
+
static const struct of_device_id meson_spicc_of_match[] = {
- { .compatible = "amlogic,meson-gx-spicc", },
- { .compatible = "amlogic,meson-axg-spicc", },
+ {
+ .compatible = "amlogic,meson-gx-spicc",
+ .data = &meson_spicc_gx_data,
+ },
+ {
+ .compatible = "amlogic,meson-axg-spicc",
+ .data = &meson_spicc_axg_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, meson_spicc_of_match);
--
2.17.0
^ permalink raw reply related
* [PATCH 2/3] spi: meson-axg: enhance output enable feature
From: Yixun Lan @ 2018-05-03 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503213645.20694-1-yixun.lan@amlogic.com>
From: Sunny Luo <sunny.luo@amlogic.com>
The SPICC controller in Meson-AXG is capable of driving the CLK/MOSI/SS
signal lines through the idle state (between two transmission operation),
which avoid the signals floating in unexpected state.
Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/spi/spi-meson-spicc.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index 8489f4c9f465..90b15f7d50dd 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -115,6 +115,13 @@
#define SPICC_DWADDR 0x24 /* Write Address of DMA */
+#define SPICC_ENH_CTL0 0x38 /* Enhanced Feature */
+#define SPICC_ENH_MOSI_OEN BIT(25)
+#define SPICC_ENH_CLK_OEN BIT(26)
+#define SPICC_ENH_CS_OEN BIT(27)
+#define SPICC_ENH_CLK_CS_DELAY_EN BIT(28)
+#define SPICC_ENH_MAIN_CLK_AO BIT(29)
+
#define writel_bits_relaxed(mask, val, addr) \
writel_relaxed((readl_relaxed(addr) & ~(mask)) | (val), addr)
@@ -123,6 +130,7 @@
struct meson_spicc_data {
unsigned int max_speed_hz;
+ bool has_oen;
};
struct meson_spicc_device {
@@ -145,6 +153,19 @@ struct meson_spicc_device {
bool is_last_burst;
};
+static void meson_spicc_oen_enable(struct meson_spicc_device *spicc)
+{
+ u32 conf;
+
+ if (!spicc->data->has_oen)
+ return;
+
+ conf = readl_relaxed(spicc->base + SPICC_ENH_CTL0) |
+ SPICC_ENH_MOSI_OEN | SPICC_ENH_CLK_OEN | SPICC_ENH_CS_OEN;
+
+ writel_relaxed(conf, spicc->base + SPICC_ENH_CTL0);
+}
+
static inline bool meson_spicc_txfull(struct meson_spicc_device *spicc)
{
return !!FIELD_GET(SPICC_TF,
@@ -453,6 +474,8 @@ static int meson_spicc_prepare_message(struct spi_master *master,
writel_bits_relaxed(BIT(24), BIT(24), spicc->base + SPICC_TESTREG);
+ meson_spicc_oen_enable(spicc);
+
return 0;
}
@@ -605,11 +628,12 @@ static int meson_spicc_remove(struct platform_device *pdev)
}
static const struct meson_spicc_data meson_spicc_gx_data = {
- .max_speed_hz = 30000000,
+ .max_speed_hz = 30000000,
};
static const struct meson_spicc_data meson_spicc_axg_data = {
- .max_speed_hz = 80000000,
+ .max_speed_hz = 80000000,
+ .has_oen = true,
};
static const struct of_device_id meson_spicc_of_match[] = {
--
2.17.0
^ permalink raw reply related
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