* LDM/STM alignment fixups on arm64
From: Russell King - ARM Linux @ 2017-04-19 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58F704D6.6000301@codeaurora.org>
On Wed, Apr 19, 2017 at 12:03:58PM +0530, Srinivas Ramana wrote:
> Hi,
>
> While understanding how the alignment are handled on arm and arm64, we came
> across the fixups for LDM/LDRD/STM on arm where as these fixups are not
> present on arm64.
>
> There may be some specific reason why these fixups are not ported to arm64.
> Can you please help us understand this?
>
> With this difference in how kernel handles 32-bit apps on arm and arm64,
> there can be apps which are working without abort on arm, but fail on arm64
> (SIGBUS). We have tried to get some history on web, but not successful.
>
> If this is indeed missing on arm64, do you see any issue if its ported (does
> it fail any guidance)?
Do you have an application that fails because of this? Your email makes
it sound very theoretical.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v3 6/7] ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
From: Arnd Bergmann @ 2017-04-19 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1489137839-549-7-git-send-email-vladimir.murzin@arm.com>
On Fri, Mar 10, 2017 at 10:23 AM, Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
> Now, we have dedicated non-cacheable region for consistent DMA
> operations. However, that region can still be marked as bufferable by
> MPU, so it'd be safer to have barriers by default.
>
> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Tested-by: Andras Szemzo <sza@esh.hu>
> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm/mm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index d731f28..7dd46ae 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1050,7 +1050,7 @@ config ARM_L1_CACHE_SHIFT
>
> config ARM_DMA_MEM_BUFFERABLE
> bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !CPU_V7
> - default y if CPU_V6 || CPU_V6K || CPU_V7
> + default y if CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M
> help
> Historically, the kernel has used strongly ordered mappings to
> provide DMA coherent memory. With the advent of ARMv7, mapping
The patch doesn't seem to match the description: I would have expected
this to be user-selectable on CPU_V7M as we do on V6, but it is enabled
unconditionally.
Can you either modify the description to explain why we now need this on
all ARMv7M, or add a '|| CPU_V7M' for the 'bool' line to make it optional?
Would it be better to leave the default as disabled on CPU_V7M and
require users to enable it manually? That way we don't regress the
performance of readl/writel on platforms that don't need this.
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: vexpress: fix few unit address format warnings
From: Liviu Dudau @ 2017-04-19 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492537507-7783-1-git-send-email-sudeep.holla@arm.com>
On Tue, Apr 18, 2017 at 06:45:07PM +0100, Sudeep Holla wrote:
> This patch fixes the following set of warnings on vexpress platforms:
>
> sysreg at 010000 simple-bus unit address format error, expected "10000"
> sysctl at 020000 simple-bus unit address format error, expected "20000"
> i2c at 030000 simple-bus unit address format error, expected "30000"
> aaci at 040000 simple-bus unit address format error, expected "40000"
> mmci at 050000 simple-bus unit address format error, expected "50000"
> kmi at 060000 simple-bus unit address format error, expected "60000"
> kmi at 070000 simple-bus unit address format error, expected "70000"
> uart at 090000 simple-bus unit address format error, expected "90000"
> uart at 0a0000 simple-bus unit address format error, expected "a0000"
> uart at 0b0000 simple-bus unit address format error, expected "b0000"
> uart at 0c0000 simple-bus unit address format error, expected "c0000"
> wdt at 0f0000 simple-bus unit address format error, expected "f0000"
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 24 ++++++++++++------------
> arch/arm/boot/dts/vexpress-v2m.dtsi | 24 ++++++++++++------------
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 18 +++++++++---------
> arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca9.dts | 2 +-
> 6 files changed, 36 insertions(+), 36 deletions(-)
>
> Hi,
>
> I observed few warning in linux-next due to the enhanced DTC checks
> introduced with DTC upgrade in linux-next. The patch fixes few warnings
All changes look sensible to me in order to fix the warnings, but I feel like
letting out a minor rant from me: the fact that DTC now complains about leading
zeros in what is usually a numeric field is silly. I find it easier to parse numbers
that have the same width. Also, now the reg property doesn't match the @<number>
part if you grep for it.
Best regards,
Liviu
>
> Regards,
> Sudeep
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index 3086efacd00e..35714ff6f467 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -71,7 +71,7 @@
> #size-cells = <1>;
> ranges = <0 3 0 0x200000>;
>
> - v2m_sysreg: sysreg at 010000 {
> + v2m_sysreg: sysreg at 10000 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x010000 0x1000>;
>
> @@ -94,7 +94,7 @@
> };
> };
>
> - v2m_sysctl: sysctl at 020000 {
> + v2m_sysctl: sysctl at 20000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x020000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
> @@ -106,7 +106,7 @@
> };
>
> /* PCI-E I2C bus */
> - v2m_i2c_pcie: i2c at 030000 {
> + v2m_i2c_pcie: i2c at 30000 {
> compatible = "arm,versatile-i2c";
> reg = <0x030000 0x1000>;
>
> @@ -119,7 +119,7 @@
> };
> };
>
> - aaci at 040000 {
> + aaci at 40000 {
> compatible = "arm,pl041", "arm,primecell";
> reg = <0x040000 0x1000>;
> interrupts = <11>;
> @@ -127,7 +127,7 @@
> clock-names = "apb_pclk";
> };
>
> - mmci at 050000 {
> + mmci at 50000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x050000 0x1000>;
> interrupts = <9 10>;
> @@ -139,7 +139,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi at 060000 {
> + kmi at 60000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x060000 0x1000>;
> interrupts = <12>;
> @@ -147,7 +147,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi at 070000 {
> + kmi at 70000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x070000 0x1000>;
> interrupts = <13>;
> @@ -155,7 +155,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - v2m_serial0: uart at 090000 {
> + v2m_serial0: uart at 90000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x090000 0x1000>;
> interrupts = <5>;
> @@ -163,7 +163,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial1: uart at 0a0000 {
> + v2m_serial1: uart at a0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0a0000 0x1000>;
> interrupts = <6>;
> @@ -171,7 +171,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial2: uart at 0b0000 {
> + v2m_serial2: uart at b0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0b0000 0x1000>;
> interrupts = <7>;
> @@ -179,7 +179,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial3: uart at 0c0000 {
> + v2m_serial3: uart at c0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0c0000 0x1000>;
> interrupts = <8>;
> @@ -187,7 +187,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - wdt at 0f0000 {
> + wdt at f0000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f0000 0x1000>;
> interrupts = <0>;
> diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
> index c6393d3f1719..1b6f6393be93 100644
> --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> @@ -70,7 +70,7 @@
> #size-cells = <1>;
> ranges = <0 7 0 0x20000>;
>
> - v2m_sysreg: sysreg at 00000 {
> + v2m_sysreg: sysreg at 0 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x00000 0x1000>;
>
> @@ -93,7 +93,7 @@
> };
> };
>
> - v2m_sysctl: sysctl at 01000 {
> + v2m_sysctl: sysctl at 1000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x01000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
> @@ -105,7 +105,7 @@
> };
>
> /* PCI-E I2C bus */
> - v2m_i2c_pcie: i2c at 02000 {
> + v2m_i2c_pcie: i2c at 2000 {
> compatible = "arm,versatile-i2c";
> reg = <0x02000 0x1000>;
>
> @@ -118,7 +118,7 @@
> };
> };
>
> - aaci at 04000 {
> + aaci at 4000 {
> compatible = "arm,pl041", "arm,primecell";
> reg = <0x04000 0x1000>;
> interrupts = <11>;
> @@ -126,7 +126,7 @@
> clock-names = "apb_pclk";
> };
>
> - mmci at 05000 {
> + mmci at 5000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x05000 0x1000>;
> interrupts = <9 10>;
> @@ -138,7 +138,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi at 06000 {
> + kmi at 6000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x06000 0x1000>;
> interrupts = <12>;
> @@ -146,7 +146,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi at 07000 {
> + kmi at 7000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x07000 0x1000>;
> interrupts = <13>;
> @@ -154,7 +154,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - v2m_serial0: uart at 09000 {
> + v2m_serial0: uart at 9000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x09000 0x1000>;
> interrupts = <5>;
> @@ -162,7 +162,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial1: uart at 0a000 {
> + v2m_serial1: uart at a000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0a000 0x1000>;
> interrupts = <6>;
> @@ -170,7 +170,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial2: uart at 0b000 {
> + v2m_serial2: uart at b000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0b000 0x1000>;
> interrupts = <7>;
> @@ -178,7 +178,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial3: uart at 0c000 {
> + v2m_serial3: uart at c000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0c000 0x1000>;
> interrupts = <8>;
> @@ -186,7 +186,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - wdt at 0f000 {
> + wdt at f000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f000 0x1000>;
> interrupts = <0>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 15f4fd3f4695..0c8de0ca73ee 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -220,7 +220,7 @@
> };
> };
>
> - smb at 08000000 {
> + smb at 8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index bd107c5a0226..65ecf206388c 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> @@ -385,7 +385,7 @@
> };
> };
>
> - etb at 0,20010000 {
> + etb at 20010000 {
> compatible = "arm,coresight-etb10", "arm,primecell";
> reg = <0 0x20010000 0 0x1000>;
>
> @@ -399,7 +399,7 @@
> };
> };
>
> - tpiu at 0,20030000 {
> + tpiu at 20030000 {
> compatible = "arm,coresight-tpiu", "arm,primecell";
> reg = <0 0x20030000 0 0x1000>;
>
> @@ -449,7 +449,7 @@
> };
> };
>
> - funnel at 0,20040000 {
> + funnel at 20040000 {
> compatible = "arm,coresight-funnel", "arm,primecell";
> reg = <0 0x20040000 0 0x1000>;
>
> @@ -513,7 +513,7 @@
> };
> };
>
> - ptm at 0,2201c000 {
> + ptm at 2201c000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2201c000 0 0x1000>;
>
> @@ -527,7 +527,7 @@
> };
> };
>
> - ptm at 0,2201d000 {
> + ptm at 2201d000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2201d000 0 0x1000>;
>
> @@ -541,7 +541,7 @@
> };
> };
>
> - etm at 0,2203c000 {
> + etm at 2203c000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203c000 0 0x1000>;
>
> @@ -555,7 +555,7 @@
> };
> };
>
> - etm at 0,2203d000 {
> + etm at 2203d000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203d000 0 0x1000>;
>
> @@ -569,7 +569,7 @@
> };
> };
>
> - etm at 0,2203e000 {
> + etm at 2203e000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203e000 0 0x1000>;
>
> @@ -583,7 +583,7 @@
> };
> };
>
> - smb at 08000000 {
> + smb at 8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> index 1acecaf4b13d..6e69b8e6c1a7 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> @@ -190,7 +190,7 @@
> };
> };
>
> - smb at 08000000 {
> + smb at 8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> index b608a03ee02f..c9305b58afc2 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -300,7 +300,7 @@
> };
> };
>
> - smb at 04000000 {
> + smb at 4000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH 1/2] arm64: dts: juno: fix few unit address format warnings
From: Liviu Dudau @ 2017-04-19 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492538279-16405-1-git-send-email-sudeep.holla@arm.com>
On Tue, Apr 18, 2017 at 06:57:58PM +0100, Sudeep Holla wrote:
> This patch fixes the following set of warnings on juno.
>
> smb at 08000000 unit name should not have leading 0s
> sysctl at 020000 simple-bus unit address format error, expected "20000"
> apbregs at 010000 simple-bus unit address format error, expected "10000"
> mmci at 050000 simple-bus unit address format error, expected "50000"
> kmi at 060000 simple-bus unit address format error, expected "60000"
> kmi at 070000 simple-bus unit address format error, expected "70000"
> wdt at 0f0000 simple-bus unit address format error, expected "f0000"
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Thanks!
Liviu
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++++++------
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index 8ffaff2043d0..bfe7d683a42e 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -699,7 +699,7 @@
> <0x00000008 0x80000000 0x1 0x80000000>;
> };
>
> - smb at 08000000 {
> + smb at 8000000 {
> compatible = "simple-bus";
> #address-cells = <2>;
> #size-cells = <1>;
> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> index 098601657f82..2ac43221ddb6 100644
> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> @@ -137,7 +137,7 @@
> #size-cells = <1>;
> ranges = <0 3 0 0x200000>;
>
> - v2m_sysctl: sysctl at 020000 {
> + v2m_sysctl: sysctl at 20000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x020000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&mb_clk24mhz>;
> @@ -148,7 +148,7 @@
> assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
> };
>
> - apbregs at 010000 {
> + apbregs at 10000 {
> compatible = "syscon", "simple-mfd";
> reg = <0x010000 0x1000>;
>
> @@ -216,7 +216,7 @@
> };
> };
>
> - mmci at 050000 {
> + mmci at 50000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x050000 0x1000>;
> interrupts = <5>;
> @@ -228,7 +228,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi at 060000 {
> + kmi at 60000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x060000 0x1000>;
> interrupts = <8>;
> @@ -236,7 +236,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi at 070000 {
> + kmi at 70000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x070000 0x1000>;
> interrupts = <8>;
> @@ -244,7 +244,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - wdt at 0f0000 {
> + wdt at f0000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f0000 0x10000>;
> interrupts = <7>;
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH 1/2] KVM: arm/arm64: vgic-v3: De-optimize VMCR save/restore when emulating a GICv2
From: Christoffer Dall @ 2017-04-19 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170410091944.19963-2-marc.zyngier@arm.com>
On Mon, Apr 10, 2017 at 10:19:43AM +0100, Marc Zyngier wrote:
> When emulating a GICv2-on-GICv3, special care must be taken to only
> save/restore VMCR_EL2 when ICC_SRE_EL1.SRE is cleared. Otherwise,
> all Group-0 interrupts end-up being delivered as FIQ, which is
> probably not what the guest expects, as demonstrated here with
> an unhappy EFI:
>
> FIQ Exception at 0x000000013BD21CC4
>
> This means that we cannot perform the load/put trick when dealing
> with VMCR_EL2 (because the host has SRE set), and we have to deal
> with it in the world-switch.
>
> Fortunately, this is not the most common case (modern guests should
> be able to deal with GICv3 directly), and the performance is not worse
> than what it was before the VMCR optimization.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/hyp/vgic-v3-sr.c | 8 ++++++--
> virt/kvm/arm/vgic/vgic.c | 26 ++++++++++++++++++++------
> 2 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
> index 3d0b1ddb6929..91922c1eddc8 100644
> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
> @@ -128,8 +128,10 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
> * Make sure stores to the GIC via the memory mapped interface
> * are now visible to the system register interface.
> */
> - if (!cpu_if->vgic_sre)
> + if (!cpu_if->vgic_sre) {
> dsb(st);
> + cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2);
> + }
>
> if (used_lrs) {
> int i;
> @@ -205,11 +207,13 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
> * delivered as a FIQ to the guest, with potentially fatal
> * consequences. So we must make sure that ICC_SRE_EL1 has
> * been actually programmed with the value we want before
> - * starting to mess with the rest of the GIC.
> + * starting to mess with the rest of the GIC, and VMCR_EL2 in
> + * particular.
> */
> if (!cpu_if->vgic_sre) {
> write_gicreg(0, ICC_SRE_EL1);
> isb();
> + write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
> }
>
> val = read_gicreg(ICH_VTR_EL2);
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index 3d0979c30721..32205f2ba6ff 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
> @@ -667,10 +667,20 @@ void kvm_vgic_load(struct kvm_vcpu *vcpu)
> if (unlikely(!vgic_initialized(vcpu->kvm)))
> return;
>
> - if (kvm_vgic_global_state.type == VGIC_V2)
> + if (kvm_vgic_global_state.type == VGIC_V2) {
> vgic_v2_load(vcpu);
> - else
> - vgic_v3_load(vcpu);
> + } else {
> + struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
> +
> + /*
> + * If dealing with a GICv2 emulation on GICv3,
> + * VMCR_EL2.VFIQen is dependent on ICC_SRE_EL1.SRE,
> + * and we have to perform the VMCR_EL2 save/restore in
> + * the world switch.
> + */
> + if (likely(cpu_if->vgic_sre))
> + vgic_v3_load(vcpu);
I wonder if this conditional should really be inside vgic_v3_load
instead?
> + }
> }
>
> void kvm_vgic_put(struct kvm_vcpu *vcpu)
> @@ -678,10 +688,14 @@ void kvm_vgic_put(struct kvm_vcpu *vcpu)
> if (unlikely(!vgic_initialized(vcpu->kvm)))
> return;
>
> - if (kvm_vgic_global_state.type == VGIC_V2)
> + if (kvm_vgic_global_state.type == VGIC_V2) {
> vgic_v2_put(vcpu);
> - else
> - vgic_v3_put(vcpu);
> + } else {
> + struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
> +
> + if (likely(cpu_if->vgic_sre))
> + vgic_v3_put(vcpu);
And same here?
> + }
> }
>
> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
> --
> 2.11.0
>
Otherwise looks good.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 2/2] KVM: arm/arm64: vgic-v3: Fix off-by-one LR access
From: Christoffer Dall @ 2017-04-19 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170410091944.19963-3-marc.zyngier@arm.com>
On Mon, Apr 10, 2017 at 10:19:44AM +0100, Marc Zyngier wrote:
> When iterating over the used LRs, be careful not to try to access
> an unused LR, or even an unimplemented one if you're unlucky...
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/hyp/vgic-v3-sr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
> index 91922c1eddc8..bce6037cf01d 100644
> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
> @@ -143,7 +143,7 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
> val = read_gicreg(ICH_VTR_EL2);
> nr_pri_bits = vtr_to_nr_pri_bits(val);
>
> - for (i = 0; i <= used_lrs; i++) {
> + for (i = 0; i < used_lrs; i++) {
> if (cpu_if->vgic_elrsr & (1 << i))
> cpu_if->vgic_lr[i] &= ~ICH_LR_STATE;
> else
> --
> 2.11.0
>
Whoops, thanks for fixing my stupid mistake:
Reviewed-by: Christoffer Dall <cdall@linaro.org>
^ permalink raw reply
* [PATCH v3 5/7] ARM: NOMMU: Introduce dma operations for noMMU
From: Arnd Bergmann @ 2017-04-19 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1489137839-549-6-git-send-email-vladimir.murzin@arm.com>
On Fri, Mar 10, 2017 at 10:23 AM, Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
> R/M classes of cpus can have memory covered by MPU which in turn might
> configure RAM as Normal i.e. bufferable and cacheable. It breaks
> dma_alloc_coherent() and friends, since data can stuck in caches now
> or be buffered.
>
> This patch factors out DMA support for NOMMU configuration into
> separate entity which provides dedicated dma_ops. We have to handle
> there several cases:
> - configurations with MMU/MPU setup
> - configurations without MMU/MPU setup
> - special case for M-class, since caches and MPU there are optional
>
> In general we rely on default DMA area for coherent allocations or/and
> per-device memory reserves suitable for coherent DMA, so if such
> regions are set coherent allocations go from there.
>
> In case MPU/MPU was not setup we fallback to normal page allocator for
> DMA memory allocation.
>
> In case we run M-class cpus, for configuration without cache support
> (like Cortex-M3/M4) dma operations are forced to be coherent and wired
> with dma-noop (such decision is made based on cacheid global
> variable); however, if caches are detected there and no DMA coherent
> region is given (either default or per-device), dma is disallowed even
> MPU is not set - it is because M-class implement system memory map
> which defines part of address space as Normal memory.
>
> Reported-by: Alexandre Torgue <alexandre.torgue@st.com>
> Reported-by: Andras Szemzo <sza@esh.hu>
> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Tested-by: Andras Szemzo <sza@esh.hu>
> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
I thought I found a couple of problems with this, but after reading more
carefully I was wrong about all of them and I think the code is doing
exactly the right thing. I also like the way this is split out into a separate
set of dma_map_ops to simplify the normal MMU case.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* atmel-hlcdc-display-controller atmel-hlcdc-dc: No connectors reported connected with modes
From: Ross McCormack @ 2017-04-19 10:22 UTC (permalink / raw)
To: linux-arm-kernel
I just tried to display the Linux Tux Logo at bootup of the SAM5D, but it won't show up. My display is 800x480, kernel version is 4.9.20. Appart from the display/drm stack the kernel works like a charm. I narrowed the problem down to this error:
atmel-hlcdc-display-controller atmel-hlcdc-dc: failed to create HLCDC outputs: -517
atmel-hlcdc-display-controller atmel-hlcdc-dc: failed to initialize mode setting
atmel-hlcdc-display-controller atmel-hlcdc-dc: No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48
atmel-hlcdc-display-controller atmel-hlcdc-dc: fb0: frame buffer device
Now I tried video=Unknown-1:800x480-16 as suggested on [1] but it still shows the error.
What's the problem here? Is it a driver issue with the display?
[1] http://www.at91.com/linux4sam/bin/view/Linux4SAM/UsingAtmelDRMDriver
^ permalink raw reply
* [PATCH 1/2] KVM: arm/arm64: vgic-v3: De-optimize VMCR save/restore when emulating a GICv2
From: Marc Zyngier @ 2017-04-19 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419100809.GA4104@cbox>
On 19/04/17 11:08, Christoffer Dall wrote:
> On Mon, Apr 10, 2017 at 10:19:43AM +0100, Marc Zyngier wrote:
>> When emulating a GICv2-on-GICv3, special care must be taken to only
>> save/restore VMCR_EL2 when ICC_SRE_EL1.SRE is cleared. Otherwise,
>> all Group-0 interrupts end-up being delivered as FIQ, which is
>> probably not what the guest expects, as demonstrated here with
>> an unhappy EFI:
>>
>> FIQ Exception at 0x000000013BD21CC4
>>
>> This means that we cannot perform the load/put trick when dealing
>> with VMCR_EL2 (because the host has SRE set), and we have to deal
>> with it in the world-switch.
>>
>> Fortunately, this is not the most common case (modern guests should
>> be able to deal with GICv3 directly), and the performance is not worse
>> than what it was before the VMCR optimization.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> virt/kvm/arm/hyp/vgic-v3-sr.c | 8 ++++++--
>> virt/kvm/arm/vgic/vgic.c | 26 ++++++++++++++++++++------
>> 2 files changed, 26 insertions(+), 8 deletions(-)
>>
>> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
>> index 3d0b1ddb6929..91922c1eddc8 100644
>> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
>> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
>> @@ -128,8 +128,10 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>> * Make sure stores to the GIC via the memory mapped interface
>> * are now visible to the system register interface.
>> */
>> - if (!cpu_if->vgic_sre)
>> + if (!cpu_if->vgic_sre) {
>> dsb(st);
>> + cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2);
>> + }
>>
>> if (used_lrs) {
>> int i;
>> @@ -205,11 +207,13 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>> * delivered as a FIQ to the guest, with potentially fatal
>> * consequences. So we must make sure that ICC_SRE_EL1 has
>> * been actually programmed with the value we want before
>> - * starting to mess with the rest of the GIC.
>> + * starting to mess with the rest of the GIC, and VMCR_EL2 in
>> + * particular.
>> */
>> if (!cpu_if->vgic_sre) {
>> write_gicreg(0, ICC_SRE_EL1);
>> isb();
>> + write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
>> }
>>
>> val = read_gicreg(ICH_VTR_EL2);
>> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
>> index 3d0979c30721..32205f2ba6ff 100644
>> --- a/virt/kvm/arm/vgic/vgic.c
>> +++ b/virt/kvm/arm/vgic/vgic.c
>> @@ -667,10 +667,20 @@ void kvm_vgic_load(struct kvm_vcpu *vcpu)
>> if (unlikely(!vgic_initialized(vcpu->kvm)))
>> return;
>>
>> - if (kvm_vgic_global_state.type == VGIC_V2)
>> + if (kvm_vgic_global_state.type == VGIC_V2) {
>> vgic_v2_load(vcpu);
>> - else
>> - vgic_v3_load(vcpu);
>> + } else {
>> + struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>> +
>> + /*
>> + * If dealing with a GICv2 emulation on GICv3,
>> + * VMCR_EL2.VFIQen is dependent on ICC_SRE_EL1.SRE,
>> + * and we have to perform the VMCR_EL2 save/restore in
>> + * the world switch.
>> + */
>> + if (likely(cpu_if->vgic_sre))
>> + vgic_v3_load(vcpu);
>
> I wonder if this conditional should really be inside vgic_v3_load
> instead?
That's a good point. It will keep the wart out of the main vgic code and
make it an "implementation detail".
>
>> + }
>> }
>>
>> void kvm_vgic_put(struct kvm_vcpu *vcpu)
>> @@ -678,10 +688,14 @@ void kvm_vgic_put(struct kvm_vcpu *vcpu)
>> if (unlikely(!vgic_initialized(vcpu->kvm)))
>> return;
>>
>> - if (kvm_vgic_global_state.type == VGIC_V2)
>> + if (kvm_vgic_global_state.type == VGIC_V2) {
>> vgic_v2_put(vcpu);
>> - else
>> - vgic_v3_put(vcpu);
>> + } else {
>> + struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>> +
>> + if (likely(cpu_if->vgic_sre))
>> + vgic_v3_put(vcpu);
>
> And same here?
>
>> + }
>> }
>>
>> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
>> --
>> 2.11.0
>>
>
> Otherwise looks good.
Thanks. I'll respin this patch shortly.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: Catalin Marinas @ 2017-04-19 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA_wH1dDbcjEEBaLX0q8pfWsfYUGGL-zOC4MuxySqa=uvA@mail.gmail.com>
On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
> On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
> >> From: Dong Bo <dongbo4@huawei.com>
> >>
> >> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
> >> the flag is propagated to its child processes, even the elf
> >> files are marked as not requiring executable stack. It may
> >> cause superfluous operations on some arch, e.g.
> >> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
> >> also marked as PROT_EXEC.
>
> > That's affecting most architectures with a risk of ABI breakage. We
> > could do it on arm64 only, though I'm not yet clear on the ABI
> > implications (at a first look, there shouldn't be any).
>
> Is there a reason why it isn't just straightforwardly a bug
> (which we could fix) to make READ_IMPLIES_EXEC propagate to
> child processes?
While I agree that it looks like a bug, if there are user programs
relying on such bug we call it "ABI". On arm64, I don't think there is
anything relying on inheriting READ_IMPLIES_EXEC but I wouldn't change
the compat task handling without the corresponding change in arch/arm.
> AFAICT this should be per-process: just because
> init happens not to have been (re)compiled to permit non-executable
> stacks doesn't mean every process on the system needs to have
> an executable stack.
I think this also affects the heap if brk(2) is used (via
VM_DATA_DEFAULT_FLAGS though I guess malloc mostly uses mmap these
days).
> Behaviour shouldn't be variable across architectures either, I would
> hope.
The behaviour has already been variable for a long time. Even on x86,
AFAICT x86_32 differs from x86_64 in this respect.
Anyway, the patch should be posted to linux-arch for a cross-arch
discussion.
--
Catalin
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: Peter Maydell @ 2017-04-19 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419103313.GA3238@e104818-lin.cambridge.arm.com>
On 19 April 2017 at 11:33, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
>>
>> > That's affecting most architectures with a risk of ABI breakage. We
>> > could do it on arm64 only, though I'm not yet clear on the ABI
>> > implications (at a first look, there shouldn't be any).
>>
>> Is there a reason why it isn't just straightforwardly a bug
>> (which we could fix) to make READ_IMPLIES_EXEC propagate to
>> child processes?
>
> While I agree that it looks like a bug, if there are user programs
> relying on such bug we call it "ABI".
Can there be any? Such a program would behave differently
depending on how the program that spawned it happened to
have been compiled, and for instance could break when
the OS happened to have its init binary updated even if
the kernel didn't change.
>> Behaviour shouldn't be variable across architectures either, I would
>> hope.
>
> The behaviour has already been variable for a long time. Even on x86,
> AFAICT x86_32 differs from x86_64 in this respect.
That also sounds like a bug to me.
> Anyway, the patch should be posted to linux-arch for a cross-arch
> discussion.
Agreed -- there may be something I'm missing, since it looks
like this behaviour of inheriting READ_IMPLIES_EXEC has always
been there.
thanks
-- PMM
^ permalink raw reply
* [PATCH] [media] mtk-vcodec: avoid warnings because of empty macros
From: Mauro Carvalho Chehab @ 2017-04-19 10:56 UTC (permalink / raw)
To: linux-arm-kernel
Remove those gcc warnings:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
^
By adding braces.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 12480837ff2e..237e144c194f 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -66,15 +66,15 @@ extern bool mtk_vcodec_dbg;
#else
-#define mtk_v4l2_debug(level, fmt, args...)
-#define mtk_v4l2_err(fmt, args...)
-#define mtk_v4l2_debug_enter()
-#define mtk_v4l2_debug_leave()
+#define mtk_v4l2_debug(level, fmt, args...) {}
+#define mtk_v4l2_err(fmt, args...) {}
+#define mtk_v4l2_debug_enter() {}
+#define mtk_v4l2_debug_leave() {}
-#define mtk_vcodec_debug(h, fmt, args...)
-#define mtk_vcodec_err(h, fmt, args...)
-#define mtk_vcodec_debug_enter(h)
-#define mtk_vcodec_debug_leave(h)
+#define mtk_vcodec_debug(h, fmt, args...) {}
+#define mtk_vcodec_err(h, fmt, args...) {}
+#define mtk_vcodec_debug_enter(h) {}
+#define mtk_vcodec_debug_leave(h) {}
#endif
--
2.9.3
^ permalink raw reply related
* [PATCH] media: mtk-vcodec: remove informative log
From: Mauro Carvalho Chehab @ 2017-04-19 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491390599.32502.1.camel@mtksdaap41>
Em Wed, 5 Apr 2017 19:09:59 +0800
Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
> On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > Driver is stable. Remove DEBUG definition from driver.
> >
> > There are debug message in /var/log/messages if DEBUG is defined,
> > such as:
> > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > [MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
> > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> >
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> Acked-by:Tiffany Lin <Tiffany.lin@mediatek.com>
>
> > ---
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > index 7d55975..1248083 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> > extern int mtk_v4l2_dbg_level;
> > extern bool mtk_vcodec_dbg;
> >
> > -#define DEBUG 1
> >
> > #if defined(DEBUG)
> >
After this patch, building the Kernel with W=1 now shows warnings:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
^
I wrote a patch fixing it, as this is really a trivial issue.
Yet, after that, this one still remains:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 'mtk_vdec_pic_info_update':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
int ret;
^~~
Shouldn't be mtk_vdec_pic_info_update() returning an error code?
Also, IMHO, at least errors should be shown at dmesg.
Thanks,
Mauro
^ permalink raw reply
* [PATCH v4 3/6] mfd: exynos-lpass: Remove pad retention control
From: Marek Szyprowski @ 2017-04-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411120231.hivtn6c7to4z2gu6@dell>
Hi Lee,
On 2017-04-11 14:02, Lee Jones wrote:
> On Thu, 23 Mar 2017, Marek Szyprowski wrote:
>
>> Pad retention should be controlled from pin control driver, so remove it
>> from Exynos LPASS driver. After this change, no more access to PMU regmap
>> is needed, so remove also the code for handling PMU regmap.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>> ---
>> .../bindings/mfd/samsung,exynos5433-lpass.txt | 2 --
>> drivers/mfd/exynos-lpass.c | 17 -----------------
>> include/linux/mfd/syscon/exynos5-pmu.h | 3 ---
>> 3 files changed, 22 deletions(-)
> Applied, thanks.
When can I expect this (and the remaining patches from this patchset) to
appear
in your -next branch?
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [Query] Enabling parent device clock from resume_noirq
From: Kishon Vijay Abraham I @ 2017-04-19 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c6e91e4-35fa-2fde-7915-fb922ec22567@ti.com>
Hi,
On Wednesday 19 April 2017 01:35 AM, Grygorii Strashko wrote:
> + linux-pm
>
> On 04/18/2017 01:07 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> resume_noirq callbacks are used in PCIe core to restore PCI state (this
>> accesses PCI module). So the clocks of PCI module has to be enabled before
>> resume_noirq.
>>
>> The clocks for the PCI module in DRA7xx is provided by PIPE3 PHY device which
>> in turn gets it's clock from OCP2SCP device. During resume_noirq callbacks,
>> pm_runtime is disabled, so pm_runtime_get_sync is ineffective. However
>> pm_runtime can be enabled using pm_runtime_force_resume. Now the problem is
>> adding pm_runtime_force_resume() in resume_noirq callback of pci-dra7xx driver
>> will enable only the pm_runtime of PCI device but not PIPE3 PHY or OCP2SCP.
>> Adding pm_runtime_force_resume() in resume_noirq callback of PIPE3 PHY driver
>> or OCP2SCP driver will not help if the resume_noirq callbacks in PIP3PHY driver
>> and OCP2SCP driver are invoked after the resume_noirq of pci-dra7xx driver.
>>
>> How to enable the pm_runtime of parent devices in resume_noirq callback? Does
>> existing pm_runtime framework has support for that?
>>
>
> Most probably you've hit the issue described in [1].
> In general, if pci-dra7xx is consumer of PIPE3 PHY device and
> PIPE3 PHY device is child of OCP2SCP then suspend/resume order should be
> - pci-dra7xx
> - PIPE3 PHY
> - OCP2SCP
> and resume
> - OCP2SCP
> - PIPE3 PHY
> - pci-dra7xx
> and in this case pm_runtime_force_x() might work.
>
> Hence, approach [1] was not accepted (personally I still like it) and
> "Functional dependencies tracking support" was introduced instead by commit 9ed9895 [2]
> you can try it.
>
> But, as per code, I'm not sure that Functional dependencies properly tracked in
> pm_runtime_force_x() functions.
>
> PS: you can try to reorder device's nodes in DT and place PCI node after "ocp2scp" :P
reordering helps ;-) I'll try the functional dependencies.
Thanks for the hint :-)
Cheers
Kishon
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: vgic-v3: De-optimize VMCR save/restore when emulating a GICv2
From: Marc Zyngier @ 2017-04-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
When emulating a GICv2-on-GICv3, special care must be taken to only
save/restore VMCR_EL2 when ICC_SRE_EL1.SRE is cleared. Otherwise,
all Group-0 interrupts end-up being delivered as FIQ, which is
probably not what the guest expects, as demonstrated here with
an unhappy EFI:
FIQ Exception at 0x000000013BD21CC4
This means that we cannot perform the load/put trick when dealing
with VMCR_EL2 (because the host has SRE set), and we have to deal
with it in the world-switch.
Fortunately, this is not the most common case (modern guests should
be able to deal with GICv3 directly), and the performance is not worse
than what it was before the VMCR optimization.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
* From v1:
- Move vgic_sre testing from vgic_{load,put} to vgic_v3_{load,put}
virt/kvm/arm/hyp/vgic-v3-sr.c | 8 ++++++--
virt/kvm/arm/vgic/vgic-v3.c | 11 +++++++++--
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
index 3d0b1ddb6929..91922c1eddc8 100644
--- a/virt/kvm/arm/hyp/vgic-v3-sr.c
+++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
@@ -128,8 +128,10 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
* Make sure stores to the GIC via the memory mapped interface
* are now visible to the system register interface.
*/
- if (!cpu_if->vgic_sre)
+ if (!cpu_if->vgic_sre) {
dsb(st);
+ cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2);
+ }
if (used_lrs) {
int i;
@@ -205,11 +207,13 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
* delivered as a FIQ to the guest, with potentially fatal
* consequences. So we must make sure that ICC_SRE_EL1 has
* been actually programmed with the value we want before
- * starting to mess with the rest of the GIC.
+ * starting to mess with the rest of the GIC, and VMCR_EL2 in
+ * particular.
*/
if (!cpu_if->vgic_sre) {
write_gicreg(0, ICC_SRE_EL1);
isb();
+ write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
}
val = read_gicreg(ICH_VTR_EL2);
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index bc7010db9f4d..df1503650300 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -373,12 +373,19 @@ void vgic_v3_load(struct kvm_vcpu *vcpu)
{
struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
- kvm_call_hyp(__vgic_v3_write_vmcr, cpu_if->vgic_vmcr);
+ /*
+ * If dealing with a GICv2 emulation on GICv3, VMCR_EL2.VFIQen
+ * is dependent on ICC_SRE_EL1.SRE, and we have to perform the
+ * VMCR_EL2 save/restore in the world switch.
+ */
+ if (likely(cpu_if->vgic_sre))
+ kvm_call_hyp(__vgic_v3_write_vmcr, cpu_if->vgic_vmcr);
}
void vgic_v3_put(struct kvm_vcpu *vcpu)
{
struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
- cpu_if->vgic_vmcr = kvm_call_hyp(__vgic_v3_read_vmcr);
+ if (likely(cpu_if->vgic_sre))
+ cpu_if->vgic_vmcr = kvm_call_hyp(__vgic_v3_read_vmcr);
}
--
2.11.0
^ permalink raw reply related
* [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
From: Mason @ 2017-04-19 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37cd6172-b04e-fcad-18fc-4fbb26cc611b@arm.com>
On 12/04/2017 11:59, Marc Zyngier wrote:
> And that's *wrong*. I've repeatedly said that you only need to deal with
> *your* irqchip. End of story. Nowhere else. Please leave the MSI irqchip
> alone, it is very unlikely that you have to provide anything at all to it.
Hello Marc,
I am hoping you can help me pinpoint what's missing in my code,
to have it behave the way you describe.
As you have stated, I have *two* struct irq_chip:
one is mine (tango_chip), the other not_mine (msi_chip).
static struct irq_chip tango_chip = {
.name = "TANGO IRQ_CHIP",
.irq_compose_msi_msg = tango_compose_msi_msg,
.irq_set_affinity = tango_set_affinity,
.irq_ack = tango_ack,
.irq_mask = tango_mask,
.irq_unmask = tango_unmask,
};
static struct irq_chip msi_chip = {
.name = "NOT MY IRQ_CHIP",
.irq_ack = not_mine_ack,
.irq_mask = not_mine_mask,
.irq_unmask = not_mine_unmask,
};
A struct msi_domain_info links to the msi_chip.
static struct msi_domain_info msi_dom_info = {
.flags = MSI_FLAG_PCI_MSIX | MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,
.chip = &msi_chip,
};
irq_dom = irq_domain_create_linear(fwnode, MSI_COUNT, &irq_dom_ops, pcie);
msi_dom = pci_msi_create_irq_domain(fwnode, &msi_dom_info, irq_dom);
I believe irq_dom and tango_chip are tied together by:
irq_domain_set_info(dom, virq, pos, &tango_chip, pcie, handle_edge_irq, NULL, NULL);
My biggest problem is that tango_unmask() is never called.
Here is the log of function calls as they happen on my system:
[ 0.361586] TANGO irq_chip=c0d10a00 MSI irq_chip=c0d10aa8
[ 0.361595] IRQ_DOM=cf9db300 MSI_DOM=cf9b5080
[ 0.363214] find_free_msi: dom=cf9db300 virq=30 hwirq=0 chip=c0d10a00 cdata=cfb0a410
[ 0.363314] [<c0316e54>] (tango_irq_domain_alloc) from [<c0163468>] (msi_domain_alloc+0x68/0x128)
[ 0.363543] ENTER tango_compose_msi_msg
[ 0.363552] TANGO IRQ_CHIP: irq_data=cfaf4180 irq=30 hwirq=0 chip=c0d10a00 dom=cf9db300 pdata= (null) cdata=cfb0a410
[ 0.363609] [<c0316ca4>] (tango_compose_msi_msg) from [<c015f654>] (irq_chip_compose_msi_msg+0x48/0x58)
[ 0.363928] ENTER not_mine_unmask
[ 0.363943] NOT MY IRQ_CHIP: irq_data=cf940110 irq=30 hwirq=0 chip=c0d10aa8 dom=cf9b5080 pdata=cfaf4180 cdata= (null)
[ 0.364012] [<c0316c48>] (not_mine_unmask) from [<c015edc0>] (irq_enable+0x30/0x44)
[ 2.475111] find_free_msi: dom=cf9db300 virq=34 hwirq=1 chip=c0d10a00 cdata=cfb0a410
[ 2.516895] [<c0316e54>] (tango_irq_domain_alloc) from [<c0163468>] (msi_domain_alloc+0x68/0x128)
[ 2.686593] find_free_msi: dom=cf9db300 virq=35 hwirq=2 chip=c0d10a00 cdata=cfb0a410
[ 2.728334] [<c0316e54>] (tango_irq_domain_alloc) from [<c0163468>] (msi_domain_alloc+0x68/0x128)
[ 2.897946] find_free_msi: dom=cf9db300 virq=36 hwirq=3 chip=c0d10a00 cdata=cfb0a410
[ 2.939680] [<c0316e54>] (tango_irq_domain_alloc) from [<c0163468>] (msi_domain_alloc+0x68/0x128)
[ 3.109254] ENTER tango_compose_msi_msg
[ 3.114603] TANGO IRQ_CHIP: irq_data=cfb4b500 irq=34 hwirq=1 chip=c0d10a00 dom=cf9db300 pdata= (null) cdata=cfb0a410
[ 3.160621] [<c0316ca4>] (tango_compose_msi_msg) from [<c015f654>] (irq_chip_compose_msi_msg+0x48/0x58)
[ 3.340161] ENTER tango_compose_msi_msg
[ 3.345507] TANGO IRQ_CHIP: irq_data=cfb4b440 irq=35 hwirq=2 chip=c0d10a00 dom=cf9db300 pdata= (null) cdata=cfb0a410
[ 3.391522] [<c0316ca4>] (tango_compose_msi_msg) from [<c015f654>] (irq_chip_compose_msi_msg+0x48/0x58)
[ 3.571148] ENTER tango_compose_msi_msg
[ 3.576503] TANGO IRQ_CHIP: irq_data=cfb4b380 irq=36 hwirq=3 chip=c0d10a00 dom=cf9db300 pdata= (null) cdata=cfb0a410
[ 3.631966] [<c015f654>] (irq_chip_compose_msi_msg) from [<c016362c>] (msi_domain_activate+0x18/0x40)
[ 3.802121] ENTER not_mine_unmask
[ 3.806937] NOT MY IRQ_CHIP: irq_data=cf95c210 irq=34 hwirq=524288 chip=c0d10aa8 dom=cf9b5080 pdata=cfb4b500 cdata= (null)
[ 3.852943] [<c0316c48>] (not_mine_unmask) from [<c015edc0>] (irq_enable+0x30/0x44)
[ 3.998596] ENTER not_mine_unmask
[ 4.003410] NOT MY IRQ_CHIP: irq_data=cf95c010 irq=35 hwirq=524289 chip=c0d10aa8 dom=cf9b5080 pdata=cfb4b440 cdata= (null)
[ 4.049415] [<c0316c48>] (not_mine_unmask) from [<c015edc0>] (irq_enable+0x30/0x44)
[ 4.195055] ENTER not_mine_unmask
[ 4.199870] NOT MY IRQ_CHIP: irq_data=cf97cf10 irq=36 hwirq=524290 chip=c0d10aa8 dom=cf9b5080 pdata=cfb4b380 cdata= (null)
[ 4.245874] [<c0316c48>] (not_mine_unmask) from [<c015edc0>] (irq_enable+0x30/0x44)
It's driving me nuts. Do you know what might be wrong?
Regards.
^ permalink raw reply
* [arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top"
From: Mark Rutland @ 2017-04-19 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8499425b-2b92-5b1f-a89f-6e7cd443232f@redhat.com>
Hi,
Ard, this sseems to be a nomap issue. Please see below.
Xiaojun, for some reason, the first message in this thread didn't seem
to make it to LAKML (or to me). In future could you please Cc me for
emails regarding perf on arm/arm64?
On Wed, Apr 19, 2017 at 09:44:56AM +0530, Pratyush Anand wrote:
> On Saturday 15 April 2017 02:18 PM, Tan Xiaojun wrote:
> >My test server is Hisilicon D03/D05 (arm64).
> >Kernel source code is 4.11-rc6 (up to date) and config (as an attachment in the end) is generated by defconfig.
> >(Old version does not seem to have this problem. Linux-4.1 is fine and other versions I have not tested yet.)
>
> I tested with mustang(ARM64) and 4.11-rc6 and could not reproduce it.
>
> >When I do "perf top" and annotate a random kernel symbol (like vsnprintf or others), the system report an OOPS below:
> >(The probability of occurrence is very high, almost every time.)
> >
> >$ perf top
> >
> >Annotate vsnprintf ---- choose it
> >Zoom into perf(7066) thread
> >Zoom into the Kernel DSO
> >Browse map details
> >Run scripts for samples of thread [perf]
> >Run scripts for samples of symbol [vsnprintf]
> >Run scripts for all samples
> >Exit
Was perf built from the same v4.11-rc6 source tree, or was this an older
perf binary?
With a perf tool built from v4.11-rc6, even with CAP_SYS_RAWIO, I see perf top
complaining that it it cannot annotate the symbol due to a lack of a vmlinux
file. I can't seem to convince it to use /proc/kcore.
However, I can reproduce the issue by other means:
# cat /proc/kcore > /dev/null
[ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000
[ 4544.991995] pgd = ffff80096745f000
[ 4544.995369] [ffff804392800000] *pgd=0000000000000000
[ 4545.000297] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 4545.005815] Modules linked in:
[ 4545.008843] CPU: 1 PID: 8976 Comm: cat Not tainted 4.11.0-rc6 #1
[ 4545.014790] Hardware name: ARM Juno development board (r1) (DT)
[ 4545.020653] task: ffff8009753fdb00 task.stack: ffff80097533c000
[ 4545.026520] PC is at __memcpy+0x100/0x180
[ 4545.030491] LR is at vread+0x144/0x280
[ 4545.034202] pc : [<ffff0000083a1000>] lr : [<ffff0000081c126c>] pstate: 20000145
[ 4545.041530] sp : ffff80097533fcb0
[ 4545.044811] x29: ffff80097533fcb0 x28: ffff800962d24000
[ 4545.050074] x27: 0000000000001000 x26: ffff8009753fdb00
[ 4545.055337] x25: ffff000008200000 x24: ffff800977801380
[ 4545.060600] x23: ffff8009753fdb00 x22: ffff800962d24000
[ 4545.065863] x21: 0000000000001000 x20: ffff000008200000
[ 4545.071125] x19: 0000000000001000 x18: 0000ffffefa323c0
[ 4545.076387] x17: 0000ffffa9c87440 x16: ffff0000081fdfd0
[ 4545.081649] x15: 0000ffffa9d01588 x14: 72a77346b2407be7
[ 4545.086911] x13: 5299400690000000 x12: b0000001f9001a79
[ 4545.092173] x11: 97fc098d91042260 x10: 0000000000000000
[ 4545.097435] x9 : 0000000000000000 x8 : 9110626091260021
[ 4545.102698] x7 : 0000000000001000 x6 : ffff800962d24000
[ 4545.107960] x5 : ffff8009778013b0 x4 : 0000000000000000
[ 4545.113222] x3 : 0400000000000001 x2 : 0000000000000f80
[ 4545.118484] x1 : ffff804392800000 x0 : ffff800962d24000
[ 4545.123745]
[ 4545.125220] Process cat (pid: 8976, stack limit = 0xffff80097533c000)
[ 4545.131598] Stack: (0xffff80097533fcb0 to 0xffff800975340000)
[ 4545.137289] fca0: ffff80097533fd30 ffff000008270f64
[ 4545.145049] fcc0: 000000000000e000 000000003956f000 ffff000008f950d0 ffff80097533feb8
[ 4545.152809] fce0: 0000000000002000 ffff8009753fdb00 ffff800962d24000 ffff000008e8d3d8
[ 4545.160568] fd00: 0000000000001000 ffff000008200000 0000000000001000 ffff800962d24000
[ 4545.168327] fd20: 0000000000001000 ffff000008e884a0 ffff80097533fdb0 ffff00000826340c
[ 4545.176086] fd40: ffff800976bf2800 fffffffffffffffb 000000003956d000 ffff80097533feb8
[ 4545.183846] fd60: 0000000060000000 0000000000000015 0000000000000124 000000000000003f
[ 4545.191605] fd80: ffff000008962000 ffff8009753fdb00 ffff8009753fdb00 ffff8009753fdb00
[ 4545.199364] fda0: 0000000300000124 0000000000002000 ffff80097533fdd0 ffff0000081fb83c
[ 4545.207123] fdc0: 0000000000010000 ffff80097514f900 ffff80097533fe50 ffff0000081fcb28
[ 4545.214883] fde0: 0000000000010000 ffff80097514f900 0000000000000000 0000000000000000
[ 4545.222642] fe00: ffff80097533fe30 ffff0000081fca1c ffff80097514f900 0000000000000000
[ 4545.230401] fe20: 000000003956d000 ffff80097533feb8 ffff80097533fe50 ffff0000081fcb04
[ 4545.238160] fe40: 0000000000010000 ffff80097514f900 ffff80097533fe80 ffff0000081fe014
[ 4545.245919] fe60: ffff80097514f900 ffff80097514f900 000000003956d000 0000000000010000
[ 4545.253678] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800977146000
[ 4545.261438] fea0: ffffffffffffffff 0000ffffa9c8745c 0000000000000124 0000000008202000
[ 4545.269197] fec0: 0000000000000003 000000003956d000 0000000000010000 0000000000000000
[ 4545.276956] fee0: 0000000000011011 0000000000000001 0000000000000011 0000000000000002
[ 4545.284715] ff00: 000000000000003f 1f3c201f7372686b 00000000ffffffff 0000000000000030
[ 4545.292474] ff20: 0000000000000038 0000000000000000 0000ffffa9bcca94 0000ffffa9d01588
[ 4545.300233] ff40: 0000000000000000 0000ffffa9c87440 0000ffffefa323c0 0000000000010000
[ 4545.307993] ff60: 000000000041a310 000000003956d000 0000000000000003 000000007fffe000
[ 4545.315751] ff80: 00000000004088d0 0000000000010000 0000000000000000 0000000000000000
[ 4545.323511] ffa0: 0000000000010000 0000ffffefa32690 0000000000404dcc 0000ffffefa32690
[ 4545.331270] ffc0: 0000ffffa9c8745c 0000000060000000 0000000000000003 000000000000003f
[ 4545.339029] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4545.346786] Call trace:
[ 4545.349207] Exception stack(0xffff80097533fae0 to 0xffff80097533fc10)
[ 4545.355586] fae0: 0000000000001000 0001000000000000 ffff80097533fcb0 ffff0000083a1000
[ 4545.363345] fb00: 000000003957c000 ffff80097533fc00 0000000020000145 0000000000000025
[ 4545.371105] fb20: ffff800962d24000 ffff000008e8d3d8 0000000000001000 ffff8009753fdb00
[ 4545.378864] fb40: 0000000000000000 0000000000000002 ffff80097533fd30 ffff000008082604
[ 4545.386623] fb60: 0000000000001000 0001000000000000 ffff80097533fd30 ffff0000083a0a90
[ 4545.394382] fb80: ffff800962d24000 ffff804392800000 0000000000000f80 0400000000000001
[ 4545.402140] fba0: 0000000000000000 ffff8009778013b0 ffff800962d24000 0000000000001000
[ 4545.409899] fbc0: 9110626091260021 0000000000000000 0000000000000000 97fc098d91042260
[ 4545.417658] fbe0: b0000001f9001a79 5299400690000000 72a77346b2407be7 0000ffffa9d01588
[ 4545.425416] fc00: ffff0000081fdfd0 0000ffffa9c87440
[ 4545.430248] [<ffff0000083a1000>] __memcpy+0x100/0x180
[ 4545.435253] [<ffff000008270f64>] read_kcore+0x21c/0x3b0
[ 4545.440429] [<ffff00000826340c>] proc_reg_read+0x64/0x90
[ 4545.445691] [<ffff0000081fb83c>] __vfs_read+0x1c/0x108
[ 4545.450779] [<ffff0000081fcb28>] vfs_read+0x80/0x130
[ 4545.455696] [<ffff0000081fe014>] SyS_read+0x44/0xa0
[ 4545.460528] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[ 4545.465790] Code: d503201f d503201f d503201f d503201f (a8c12027)
[ 4545.471852] ---[ end trace 4d1897f94759f461 ]---
[ 4545.476435] note: cat[8976] exited with preempt_count 2
So the call flow is:
read_core() // finds the address is vmalloc or module
-> vread()
--> aligned_vread()
In aligned_vread(), we vmalloc_to_page() the address, and find a page.
We then try to kmap_atomic() that. The generic kmap_atomic() returns the
linear map alias of the address.
However, it appears that the page is nomap'd memory, and the linear
alias doesn't exist. Thus memcpy explodes when trying to access that
address.
I've verified that with:
----
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0b05762..d7f48e0 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -9,6 +9,7 @@
*/
#include <linux/vmalloc.h>
+#include <linux/memblock.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/highmem.h>
@@ -1978,6 +1979,8 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
{
struct page *p;
int copied = 0;
+ phys_addr_t phys;
+ bool nomap;
while (count) {
unsigned long offset, length;
@@ -2000,6 +2003,14 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
* function description)
*/
void *map = kmap_atomic(p);
+
+ phys = page_to_phys(p);
+ nomap = !memblock_is_map_memory(phys);
+
+ pr_info("HARK: %s kmap'd %pa (%s memory) @ %p\n",
+ __func__, &phys, (nomap ? "nomap" : "map"),
+ map);
+
memcpy(buf, map + offset, length);
kunmap_atomic(map);
} else
----
# cat /proc/kcore > /dev/null
... which eventually results in:
[ 47.360980] HARK: aligned_vread kmap'd 0x000003e290005000 (nomap memory) @ ffff83e210005000
[ 47.369297] Unable to handle kernel paging request at virtual address ffff83e210005000
I'm not sure what we should do here.
I'm not immediately sure what the nomap region is. I'm using UEFI && DT,
so I guess it's not ACPI tables.
I can try to dump more info later.
Thanks,
Mark.
^ permalink raw reply related
* [PATCH v3 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Joerg Roedel @ 2017-04-19 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21ea43fb-0d3d-88e2-12ee-4a114e9d8459@arm.com>
On Tue, Apr 18, 2017 at 01:51:35PM +0100, Vladimir Murzin wrote:
> FYI, nothing has changed since last "ping" - Andr?s and Alexandre are still
> dependant on this series to safely enable DMA on their platforms. It is really
> scary that these patches do not move forward even though they are supposed to
> fix the real issue :(
That's probably because you didn't include all relevant people in this
post. I think patches the patches for dma-noop.c should go through
Andrew Morton.
Joerg
^ permalink raw reply
* [PATCH] Revert "arm64: Increase the max granular size"
From: Catalin Marinas @ 2017-04-19 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+sq2Ccf9K=to7rFAmWqWe-oXqNOGhZ+UQKui+ea+rSkR2pcbg@mail.gmail.com>
On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote:
> On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote:
> >> >> >> Do you have an explanation on the performance variation when
> >> >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network stack
> >> >> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
> >> >> >> non-coherent DMA?).
> >> >> >
> >> >> > network stack use SKB_DATA_ALIGN to align.
> >> >> > ---
> >> >> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
> >> >> > ~(SMP_CACHE_BYTES - 1))
> >> >> >
> >> >> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
> >> >> > ---
> >> >> > I think this is the reason of performance regression.
> >> >> >
> >> >>
> >> >> Yes this is the reason for performance regression. Due to increases L1 cache alignment the
> >> >> object is coming from next kmalloc slab and skb->truesize is changing from 2304 bytes to
> >> >> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of less send buffers.
> >>
> >> With what traffic did you check 'skb->truesize' ? Increase from
> >> 2304 to 4352 bytes doesn't seem to be real. I checked with ICMP
> >> pkts with maximum size possible with 1500byte MTU and I don't see
> >> such a bump. If the bump is observed with Iperf sending TCP packets
> >> then I suggest to check if TSO is playing a part over here.
> >
> > I haven't checked truesize but I added some printks to __alloc_skb() (on
> > a Juno platform) and the size argument to this function is 1720 on many
> > occasions. With sizeof(struct skb_shared_info) of 320, the actual data
> > allocation is exactly 2048 when using 64 byte L1_CACHE_SIZE. With a
> > 128 byte cache size, it goes slightly over 2K, hence the 4K slab
> > allocation.
>
> Understood but still in my opinion this '4K slab allocation' cannot be
> considered as an issue with cache line size, there are many network
> drivers out there which do receive buffer or page recycling to
> minimize (sometimes almost to zero) the cost of buffer allocation.
The slab allocation shouldn't make much difference (unless you are
running on a memory constrained system) but I don't understand how
skb->truesize (which is almost half unused) affects the sk_wmem_alloc
and its interaction with other bits in the network stack (e.g.
tcp_limit_output_bytes).
However, I do think it's worth investigating further to fully understand
the issue.
> >The 1720 figure surprised me a bit as well since I was
> > expecting something close to 1500.
> >
> > The thing that worries me is that skb->data may be used as a buffer to
> > DMA into. If that's the case, skb_shared_info is wrongly aligned based
> > on SMP_CACHE_BYTES only and can lead to corruption on a non-DMA-coherent
> > platform. It should really be ARCH_DMA_MINALIGN.
>
> I didn't get this, if you see __alloc_skb()
>
> 229 size = SKB_DATA_ALIGN(size);
> 230 size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>
> both DMA buffer and skb_shared_info are aligned to a cacheline separately,
> considering 128byte alignment guarantees 64byte alignment as well, how
> will this lead to corruption ?
It's the other way around: you align only to 64 byte while running on a
platform with 128 byte cache lines and non-coherent DMA.
> And if platform is non-DMA-coherent then again it's the driver which
> should take of coherency by using appropriate map/unmap APIs and
> should avoid any cacheline sharing btw DMA buffer and skb_shared_info.
The problem is that the streaming DMA API can only work correctly on
cacheline-aligned buffers (because of the cache invalidation it performs
for DMA ops; even with clean&invalidate, the operation isn't always safe
if a cacheline is shared between DMA and CPU buffers). In the skb case,
we could have the data potentially sharing the last addresses of a DMA
buffer with struct skb_shared_info.
We may be able to get away with SKB_DATA_ALIGN not using
ARCH_DMA_MINALIGN *if* skb_shared_info is *not* written before or during
an inbound DMA transfer (though such tricks are arch specific).
> > IIUC, the Cavium platform has coherent DMA, so it shouldn't be an issue
> > if we go back to 64 byte cache lines.
>
> Yes, Cavium platform is DMA coherent and there is no issue with reverting back
> to 64byte cachelines. But do we want to do this because some platform has a
> performance issue and this is an easy way to solve it. IMHO there seems
> to be many ways to solve performance degradation within the driver itself, and
> if those doesn't work then probably it makes sense to revert this.
My initial thought was to revert the change because it was causing a
significant performance regression on certain SoC. But given that it
took over a year for people to follow up, it doesn't seem too urgent, so
we should rather try to understand the issue and potential side effects
of moving back to a 64 byte cache line.
--
Catalin
^ permalink raw reply
* [GIT PULL] STi DT update for v4.12 round 1
From: Olof Johansson @ 2017-04-19 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cea82671-d127-d207-0dc5-c60bff321c3f@st.com>
On Wed, Mar 29, 2017 at 03:18:07PM +0000, Patrice CHOTARD wrote:
> Hi Arnd, Kevin, Olof
>
> PLease consider this first round of STi dts update for v4.12 :
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git
> sti-dt-for-v4.12-round1
>
> for you to fetch changes up to 6eb0d80d1df364bbb31d869e66063ca239912cbf:
>
> ARM: dts: STiH407-family: update rproc node names to avoid conflict
> (2017-03-29 17:07:14 +0200)
Merged, apologies for the long delay here.
-Olof
^ permalink raw reply
* [GIT PULL] firmware: scpi: updates for v4.12
From: Olof Johansson @ 2017-04-19 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bebdfb55-7704-716a-d00e-585be848af74@arm.com>
On Fri, Mar 31, 2017 at 06:02:56PM +0100, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> ---
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git
> tags/scpi-update-4.12
>
> for you to fetch changes up to c511fa3f35e30982445fae2946f4aade3f42203d:
>
> firmware: arm_scpi: reinit completion instead of full
> init_completion() (2017-03-31 11:00:23 +0100)
Merged now, thanks!
-Olof
^ permalink raw reply
* [PATCH] multi_v7_defconfig: make Rockchip usb2-phy built-in
From: Olof Johansson @ 2017-04-19 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170403102212.6802-1-heiko@sntech.de>
On Mon, Apr 03, 2017 at 12:22:12PM +0200, Heiko Stuebner wrote:
> The phy is necessary for the dwc2 controllers driving the usb ports
> on all arm32 Rockchip socs. Both the dwc2 as well as usb downstream
> drivers (mass-storage as well as usb networking) are already built-in,
> so only the phy is missing to allow booting from usb-devices without
> to much hassle.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Ideally to be applied directly to some armsoc defconfig branch.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] STM32 DT changes for v4.12 #1
From: Olof Johansson @ 2017-04-19 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4673f77a-d9e8-d8e1-8a1c-54837daeeca4@st.com>
On Mon, Apr 03, 2017 at 07:21:07PM +0200, Alexandre Torgue wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider this first round of STM32 DT updates for v4.12:
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> tags/stm32-dt-for-v4.12-1
>
> for you to fetch changes up to 21b825e404f0bb1b09d2c67edc019a43eee291cd:
>
> dt-bindings: Document the STM32 USB OTG DWC2 core binding (2017-04-03
> 10:28:25 +0200)
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] STM32 SOC changes for v4.12 #1
From: Olof Johansson @ 2017-04-19 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7b21384-ec29-c39f-97a8-579ca8d16bc2@st.com>
On Mon, Apr 03, 2017 at 07:23:33PM +0200, Alexandre Torgue wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider this first round of STM32 SOC updates for v4.12:
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> tags/stm32-soc-for-v4.12-1
>
> for you to fetch changes up to c6ed0f31ce3e1c5729d1c8f81a2a94ab881506a6:
>
> ARM: stm32: Add a new SOC - STM32H743 (2017-03-24 11:37:24 +0100)
Merged, thanks.
-Olof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox