* [PATCH v3 2/3] arm64: Increase ARCH_DMA_MINALIGN to 128
From: Catalin Marinas @ 2018-05-11 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511135547.34521-1-catalin.marinas@arm.com>
This patch increases the ARCH_DMA_MINALIGN to 128 so that it covers the
currently known Cache Writeback Granule (CTR_EL0.CWG) on arm64 and moves
the fallback in cache_line_size() from L1_CACHE_BYTES to this constant.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/cache.h | 4 ++--
arch/arm64/kernel/cpufeature.c | 9 ++-------
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 1dd2c2db0010..5df5cfe1c143 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -43,7 +43,7 @@
* cache before the transfer is done, causing old data to be seen by
* the CPU.
*/
-#define ARCH_DMA_MINALIGN L1_CACHE_BYTES
+#define ARCH_DMA_MINALIGN (128)
#ifndef __ASSEMBLY__
@@ -77,7 +77,7 @@ static inline u32 cache_type_cwg(void)
static inline int cache_line_size(void)
{
u32 cwg = cache_type_cwg();
- return cwg ? 4 << cwg : L1_CACHE_BYTES;
+ return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
}
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d67c53..fbee8c17a4e6 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1606,7 +1606,6 @@ static void __init setup_system_capabilities(void)
void __init setup_cpu_features(void)
{
u32 cwg;
- int cls;
setup_system_capabilities();
mark_const_caps_ready();
@@ -1627,13 +1626,9 @@ void __init setup_cpu_features(void)
* Check for sane CTR_EL0.CWG value.
*/
cwg = cache_type_cwg();
- cls = cache_line_size();
if (!cwg)
- pr_warn("No Cache Writeback Granule information, assuming cache line size %d\n",
- cls);
- if (L1_CACHE_BYTES < cls)
- pr_warn("L1_CACHE_BYTES smaller than the Cache Writeback Granule (%d < %d)\n",
- L1_CACHE_BYTES, cls);
+ pr_warn("No Cache Writeback Granule information, assuming %d\n",
+ ARCH_DMA_MINALIGN);
}
static bool __maybe_unused
^ permalink raw reply related
* [PATCH v3 1/3] Revert "arm64: Increase the max granular size"
From: Catalin Marinas @ 2018-05-11 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511135547.34521-1-catalin.marinas@arm.com>
This reverts commit 97303480753e48fb313dc0e15daaf11b0451cdb8.
Commit 97303480753e ("arm64: Increase the max granular size") increased
the cache line size to 128 to match Cavium ThunderX, apparently for some
performance benefit which could not be confirmed. This change, however,
has an impact on the network packet allocation in certain circumstances,
requiring slightly over a 4K page with a significant performance
degradation. The patch reverts L1_CACHE_SHIFT back to 6 (64-byte cache
line).
Cc: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/cache.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 9bbffc7a301f..1dd2c2db0010 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -33,7 +33,7 @@
#define ICACHE_POLICY_VIPT 2
#define ICACHE_POLICY_PIPT 3
-#define L1_CACHE_SHIFT 7
+#define L1_CACHE_SHIFT (6)
#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
/*
^ permalink raw reply related
* [PATCH v3 0/3] arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size)
From: Catalin Marinas @ 2018-05-11 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The previous version of this patch [1] didn't make it into 4.17 because
of the (compile-time) conflicts with the generic dma-direct.h changes.
I'm reposting it for 4.18 with some minor changes:
- phys_to_dma()/dma_to_phys() now gained underscores to match the
generic dma-direct.h implementation
- the patch is split in three to make the changes clearer to the
reviewers
If at some point in the future the generic swiotlb code gain
non-choerent DMA awareness, the last patch in the series could be
refactored. In the meantime, the simplest, non-intrusive approach is to
select ARCH_HAS_PHYS_TO_DMA on arm64 and force bounce buffering through
an arch-specific dma_capable() implementation.
Thanks,
Catalin
[1] http://lkml.kernel.org/r/20180228184720.25467-1-catalin.marinas at arm.com
Catalin Marinas (3):
Revert "arm64: Increase the max granular size"
arm64: Increase ARCH_DMA_MINALIGN to 128
arm64: Force swiotlb bounce buffering for non-coherent DMA with large
CWG
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/cache.h | 6 +++---
arch/arm64/include/asm/dma-direct.h | 43 +++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/cpufeature.c | 9 ++------
arch/arm64/mm/dma-mapping.c | 17 +++++++++++++++
arch/arm64/mm/init.c | 3 ++-
6 files changed, 68 insertions(+), 11 deletions(-)
create mode 100644 arch/arm64/include/asm/dma-direct.h
^ permalink raw reply
* [PATCH 1/2] arm64: defconfig: sync it with savedefconfig
From: Wei Xu @ 2018-05-11 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526007049-27884-1-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
On 2018/5/11 3:50, Shawn Guo wrote:
> Sync the defconfig with savedefconfig with the following commands:
>
> make defconfig
> make savedefconfig
> cp defconfig arch/arm64/configs/defconfig
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Series applied into the hisilicon defconfig tree.
Thanks!
BR,
Wei
> ---
> arch/arm64/configs/defconfig | 80 +++++++++++++++++---------------------------
> 1 file changed, 30 insertions(+), 50 deletions(-)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index ecf613761e78..af0992f2fee7 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -47,6 +47,7 @@ CONFIG_ARCH_MVEBU=y
> CONFIG_ARCH_QCOM=y
> CONFIG_ARCH_ROCKCHIP=y
> CONFIG_ARCH_SEATTLE=y
> +CONFIG_ARCH_SYNQUACER=y
> CONFIG_ARCH_RENESAS=y
> CONFIG_ARCH_R8A7795=y
> CONFIG_ARCH_R8A7796=y
> @@ -57,7 +58,6 @@ CONFIG_ARCH_R8A77995=y
> CONFIG_ARCH_STRATIX10=y
> CONFIG_ARCH_TEGRA=y
> CONFIG_ARCH_SPRD=y
> -CONFIG_ARCH_SYNQUACER=y
> CONFIG_ARCH_THUNDER=y
> CONFIG_ARCH_THUNDER2=y
> CONFIG_ARCH_UNIPHIER=y
> @@ -73,16 +73,16 @@ CONFIG_HOTPLUG_PCI_ACPI=y
> CONFIG_PCI_LAYERSCAPE=y
> CONFIG_PCI_HISI=y
> CONFIG_PCIE_QCOM=y
> -CONFIG_PCIE_KIRIN=y
> CONFIG_PCIE_ARMADA_8K=y
> +CONFIG_PCIE_KIRIN=y
> CONFIG_PCI_AARDVARK=y
> CONFIG_PCI_TEGRA=y
> CONFIG_PCIE_RCAR=y
> -CONFIG_PCIE_ROCKCHIP=m
> CONFIG_PCI_HOST_GENERIC=y
> CONFIG_PCI_XGENE=y
> CONFIG_PCI_HOST_THUNDER_PEM=y
> CONFIG_PCI_HOST_THUNDER_ECAM=y
> +CONFIG_PCIE_ROCKCHIP=m
> CONFIG_ARM64_VA_BITS_48=y
> CONFIG_SCHED_MC=y
> CONFIG_NUMA=y
> @@ -101,8 +101,6 @@ CONFIG_HIBERNATION=y
> CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
> CONFIG_ARM_CPUIDLE=y
> CONFIG_CPU_FREQ=y
> -CONFIG_CPU_FREQ_GOV_ATTR_SET=y
> -CONFIG_CPU_FREQ_GOV_COMMON=y
> CONFIG_CPU_FREQ_STAT=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> @@ -110,11 +108,11 @@ CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
> CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
> CONFIG_CPUFREQ_DT=y
> +CONFIG_ACPI_CPPC_CPUFREQ=m
> CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
> CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
> CONFIG_ARM_SCPI_CPUFREQ=y
> CONFIG_ARM_TEGRA186_CPUFREQ=y
> -CONFIG_ACPI_CPPC_CPUFREQ=m
> CONFIG_NET=y
> CONFIG_PACKET=y
> CONFIG_UNIX=y
> @@ -223,11 +221,6 @@ CONFIG_SMSC911X=y
> CONFIG_SNI_AVE=y
> CONFIG_SNI_NETSEC=y
> CONFIG_STMMAC_ETH=m
> -CONFIG_DWMAC_IPQ806X=m
> -CONFIG_DWMAC_MESON=m
> -CONFIG_DWMAC_ROCKCHIP=m
> -CONFIG_DWMAC_SUNXI=m
> -CONFIG_DWMAC_SUN8I=m
> CONFIG_MDIO_BUS_MUX_MMIOREG=y
> CONFIG_AT803X_PHY=m
> CONFIG_MARVELL_PHY=m
> @@ -251,8 +244,8 @@ CONFIG_WL18XX=m
> CONFIG_WLCORE_SDIO=m
> CONFIG_INPUT_EVDEV=y
> CONFIG_KEYBOARD_ADC=m
> -CONFIG_KEYBOARD_CROS_EC=y
> CONFIG_KEYBOARD_GPIO=y
> +CONFIG_KEYBOARD_CROS_EC=y
> CONFIG_INPUT_MISC=y
> CONFIG_INPUT_PM8941_PWRKEY=y
> CONFIG_INPUT_HISI_POWERKEY=y
> @@ -276,15 +269,12 @@ CONFIG_SERIAL_SAMSUNG=y
> CONFIG_SERIAL_SAMSUNG_CONSOLE=y
> CONFIG_SERIAL_TEGRA=y
> CONFIG_SERIAL_SH_SCI=y
> -CONFIG_SERIAL_SH_SCI_NR_UARTS=11
> -CONFIG_SERIAL_SH_SCI_CONSOLE=y
> CONFIG_SERIAL_MSM=y
> CONFIG_SERIAL_MSM_CONSOLE=y
> CONFIG_SERIAL_XILINX_PS_UART=y
> CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
> CONFIG_SERIAL_MVEBU_UART=y
> CONFIG_SERIAL_DEV_BUS=y
> -CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
> CONFIG_VIRTIO_CONSOLE=y
> CONFIG_I2C_CHARDEV=y
> CONFIG_I2C_MUX=y
> @@ -303,20 +293,20 @@ CONFIG_I2C_UNIPHIER_F=y
> CONFIG_I2C_RCAR=y
> CONFIG_I2C_CROS_EC_TUNNEL=y
> CONFIG_SPI=y
> -CONFIG_SPI_MESON_SPICC=m
> -CONFIG_SPI_MESON_SPIFC=m
> CONFIG_SPI_BCM2835=m
> CONFIG_SPI_BCM2835AUX=m
> +CONFIG_SPI_MESON_SPICC=m
> +CONFIG_SPI_MESON_SPIFC=m
> CONFIG_SPI_ORION=y
> CONFIG_SPI_PL022=y
> -CONFIG_SPI_QUP=y
> CONFIG_SPI_ROCKCHIP=y
> +CONFIG_SPI_QUP=y
> CONFIG_SPI_S3C64XX=y
> CONFIG_SPI_SPIDEV=m
> CONFIG_SPMI=y
> -CONFIG_PINCTRL_IPQ8074=y
> CONFIG_PINCTRL_SINGLE=y
> CONFIG_PINCTRL_MAX77620=y
> +CONFIG_PINCTRL_IPQ8074=y
> CONFIG_PINCTRL_MSM8916=y
> CONFIG_PINCTRL_MSM8994=y
> CONFIG_PINCTRL_MSM8996=y
> @@ -343,12 +333,12 @@ CONFIG_SENSORS_INA2XX=m
> CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
> CONFIG_CPU_THERMAL=y
> CONFIG_THERMAL_EMULATION=y
> +CONFIG_ROCKCHIP_THERMAL=m
> +CONFIG_RCAR_GEN3_THERMAL=y
> CONFIG_BRCMSTB_THERMAL=m
> CONFIG_EXYNOS_THERMAL=y
> -CONFIG_RCAR_GEN3_THERMAL=y
> -CONFIG_QCOM_TSENS=y
> -CONFIG_ROCKCHIP_THERMAL=m
> CONFIG_TEGRA_BPMP_THERMAL=m
> +CONFIG_QCOM_TSENS=y
> CONFIG_UNIPHIER_THERMAL=y
> CONFIG_WATCHDOG=y
> CONFIG_S3C2410_WATCHDOG=y
> @@ -368,9 +358,9 @@ CONFIG_MFD_MAX77620=y
> CONFIG_MFD_SPMI_PMIC=y
> CONFIG_MFD_RK808=y
> CONFIG_MFD_SEC_CORE=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_AXP20X=y
> CONFIG_REGULATOR_FAN53555=y
> -CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_GPIO=y
> CONFIG_REGULATOR_HI6421V530=y
> CONFIG_REGULATOR_HI655X=y
> @@ -380,16 +370,15 @@ CONFIG_REGULATOR_QCOM_SMD_RPM=y
> CONFIG_REGULATOR_QCOM_SPMI=y
> CONFIG_REGULATOR_RK808=y
> CONFIG_REGULATOR_S2MPS11=y
> +CONFIG_RC_CORE=m
> +CONFIG_RC_DECODERS=y
> +CONFIG_RC_DEVICES=y
> +CONFIG_IR_MESON=m
> CONFIG_MEDIA_SUPPORT=m
> CONFIG_MEDIA_CAMERA_SUPPORT=y
> CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
> CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
> CONFIG_MEDIA_CONTROLLER=y
> -CONFIG_MEDIA_RC_SUPPORT=y
> -CONFIG_RC_CORE=m
> -CONFIG_RC_DEVICES=y
> -CONFIG_RC_DECODERS=y
> -CONFIG_IR_MESON=m
> CONFIG_VIDEO_V4L2_SUBDEV_API=y
> # CONFIG_DVB_NET is not set
> CONFIG_V4L_MEM2MEM_DRIVERS=y
> @@ -414,8 +403,7 @@ CONFIG_ROCKCHIP_DW_HDMI=y
> CONFIG_ROCKCHIP_DW_MIPI_DSI=y
> CONFIG_ROCKCHIP_INNO_HDMI=y
> CONFIG_DRM_RCAR_DU=m
> -CONFIG_DRM_RCAR_LVDS=y
> -CONFIG_DRM_RCAR_VSP=y
> +CONFIG_DRM_RCAR_LVDS=m
> CONFIG_DRM_TEGRA=m
> CONFIG_DRM_PANEL_SIMPLE=m
> CONFIG_DRM_I2C_ADV7511=m
> @@ -428,7 +416,6 @@ CONFIG_FB_ARMCLCD=y
> CONFIG_BACKLIGHT_GENERIC=m
> CONFIG_BACKLIGHT_PWM=m
> CONFIG_BACKLIGHT_LP855X=m
> -CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_LOGO=y
> # CONFIG_LOGO_LINUX_MONO is not set
> # CONFIG_LOGO_LINUX_VGA16 is not set
> @@ -473,12 +460,12 @@ CONFIG_MMC_BLOCK_MINORS=32
> CONFIG_MMC_ARMMMCI=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_ACPI=y
> -CONFIG_MMC_SDHCI_F_SDH30=y
> CONFIG_MMC_SDHCI_PLTFM=y
> CONFIG_MMC_SDHCI_OF_ARASAN=y
> CONFIG_MMC_SDHCI_OF_ESDHC=y
> CONFIG_MMC_SDHCI_CADENCE=y
> CONFIG_MMC_SDHCI_TEGRA=y
> +CONFIG_MMC_SDHCI_F_SDH30=y
> CONFIG_MMC_MESON_GX=y
> CONFIG_MMC_SDHCI_MSM=y
> CONFIG_MMC_SPI=y
> @@ -495,11 +482,11 @@ CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_GPIO=y
> CONFIG_LEDS_PWM=y
> CONFIG_LEDS_SYSCON=y
> +CONFIG_LEDS_TRIGGER_DISK=y
> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> CONFIG_LEDS_TRIGGER_CPU=y
> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> CONFIG_LEDS_TRIGGER_PANIC=y
> -CONFIG_LEDS_TRIGGER_DISK=y
> CONFIG_EDAC=y
> CONFIG_EDAC_GHES=y
> CONFIG_RTC_CLASS=y
> @@ -569,7 +556,6 @@ CONFIG_ARCH_TEGRA_186_SOC=y
> CONFIG_ARCH_TEGRA_194_SOC=y
> CONFIG_EXTCON_USB_GPIO=y
> CONFIG_MEMORY=y
> -CONFIG_TEGRA_MC=y
> CONFIG_IIO=y
> CONFIG_EXYNOS_ADC=y
> CONFIG_ROCKCHIP_SARADC=m
> @@ -581,22 +567,22 @@ CONFIG_PWM_RCAR=m
> CONFIG_PWM_ROCKCHIP=y
> CONFIG_PWM_SAMSUNG=y
> CONFIG_PWM_TEGRA=m
> -CONFIG_PHY_RCAR_GEN3_USB2=y
> -CONFIG_PHY_RCAR_GEN3_USB3=m
> -CONFIG_PHY_HI6220_USB=y
> -CONFIG_PHY_QCOM_USB_HS=y
> +CONFIG_PHY_XGENE=y
> CONFIG_PHY_SUN4I_USB=y
> +CONFIG_PHY_HI6220_USB=y
> CONFIG_PHY_MVEBU_CP110_COMPHY=y
> -CONFIG_PHY_ROCKCHIP_INNO_USB2=y
> +CONFIG_PHY_QCOM_USB_HS=y
> +CONFIG_PHY_RCAR_GEN3_USB2=y
> +CONFIG_PHY_RCAR_GEN3_USB3=m
> CONFIG_PHY_ROCKCHIP_EMMC=y
> +CONFIG_PHY_ROCKCHIP_INNO_USB2=y
> CONFIG_PHY_ROCKCHIP_PCIE=m
> -CONFIG_PHY_XGENE=y
> CONFIG_PHY_TEGRA_XUSB=y
> CONFIG_QCOM_L2_PMU=y
> CONFIG_QCOM_L3_PMU=y
> -CONFIG_MESON_EFUSE=m
> CONFIG_QCOM_QFPROM=y
> CONFIG_UNIPHIER_EFUSE=y
> +CONFIG_MESON_EFUSE=m
> CONFIG_TEE=y
> CONFIG_OPTEE=y
> CONFIG_ARM_SCPI_PROTOCOL=y
> @@ -640,7 +626,6 @@ CONFIG_DEBUG_INFO=y
> CONFIG_DEBUG_FS=y
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_DEBUG_KERNEL=y
> -CONFIG_LOCKUP_DETECTOR=y
> # CONFIG_SCHED_DEBUG is not set
> # CONFIG_DEBUG_PREEMPT is not set
> # CONFIG_FTRACE is not set
> @@ -649,20 +634,15 @@ CONFIG_SECURITY=y
> CONFIG_CRYPTO_ECHAINIV=y
> CONFIG_CRYPTO_ANSI_CPRNG=y
> CONFIG_ARM64_CRYPTO=y
> -CONFIG_CRYPTO_SHA256_ARM64=m
> -CONFIG_CRYPTO_SHA512_ARM64=m
> CONFIG_CRYPTO_SHA1_ARM64_CE=y
> CONFIG_CRYPTO_SHA2_ARM64_CE=y
> +CONFIG_CRYPTO_SHA512_ARM64_CE=m
> +CONFIG_CRYPTO_SHA3_ARM64=m
> +CONFIG_CRYPTO_SM3_ARM64_CE=m
> CONFIG_CRYPTO_GHASH_ARM64_CE=y
> CONFIG_CRYPTO_CRCT10DIF_ARM64_CE=m
> CONFIG_CRYPTO_CRC32_ARM64_CE=m
> -CONFIG_CRYPTO_AES_ARM64=m
> -CONFIG_CRYPTO_AES_ARM64_CE=m
> CONFIG_CRYPTO_AES_ARM64_CE_CCM=y
> CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
> -CONFIG_CRYPTO_AES_ARM64_NEON_BLK=m
> CONFIG_CRYPTO_CHACHA20_NEON=m
> CONFIG_CRYPTO_AES_ARM64_BS=m
> -CONFIG_CRYPTO_SHA512_ARM64_CE=m
> -CONFIG_CRYPTO_SHA3_ARM64=m
> -CONFIG_CRYPTO_SM3_ARM64_CE=m
>
^ permalink raw reply
* [PATCH] [stable 4.9] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
From: Suzuki K Poulose @ 2018-05-11 13:51 UTC (permalink / raw)
To: linux-arm-kernel
commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to disable the hardware DBM feature
on the affected cores. The hardware Access Flag management features
is not affected.
The hardware DBM feature is a non-conflicting capability, i.e, the
kernel could handle cores using the feature and those without having
the features running at the same time. So this work around is detected
at early boot time, rather than delaying it until the CPUs are brought
up into the kernel with MMU turned on. This also avoids other complexities
with late CPUs turning online, with or without the hardware DBM features.
Cc: stable at vger.kernel.org # v4.9
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Note: The upstream commit is on top of a reworked capability
infrastructure for arm64 heterogeneous systems, which allows
delaying the CPU model checks. This backport is based on the
original version of the patch [0], which checks the affected
CPU models during the early boot.
[0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose at arm.com
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 14 ++++++++++++
arch/arm64/include/asm/assembler.h | 40 ++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/cputype.h | 5 +++++
arch/arm64/mm/proc.S | 5 +++++
5 files changed, 65 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index d11af52..ac9489f 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -54,6 +54,7 @@ stable kernels.
| ARM | Cortex-A57 | #852523 | N/A |
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
| ARM | Cortex-A72 | #853709 | N/A |
+| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
| ARM | MMU-500 | #841119,#826419 | N/A |
| | | | |
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 90e58bb..d0df361 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -427,6 +427,20 @@ config ARM64_ERRATUM_843419
If unsure, say Y.
+config ARM64_ERRATUM_1024718
+ bool "Cortex-A55: 1024718: Update of DBM/AP bits without break before make might result in incorrect update"
+ default y
+ help
+ This option adds work around for Arm Cortex-A55 Erratum 1024718.
+
+ Affected Cortex-A55 cores (r0p0, r0p1, r1p0) could cause incorrect
+ update of the hardware dirty bit when the DBM/AP bits are updated
+ without a break-before-make. The work around is to disable the usage
+ of hardware DBM locally on the affected cores. CPUs not affected by
+ erratum will continue to use the feature.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index e60375c..bfcfec3 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -25,6 +25,7 @@
#include <asm/asm-offsets.h>
#include <asm/cpufeature.h>
+#include <asm/cputype.h>
#include <asm/page.h>
#include <asm/pgtable-hwdef.h>
#include <asm/ptrace.h>
@@ -435,4 +436,43 @@ alternative_endif
and \phys, \pte, #(((1 << (48 - PAGE_SHIFT)) - 1) << PAGE_SHIFT)
.endm
+/*
+ * Check the MIDR_EL1 of the current CPU for a given model and a range of
+ * variant/revision. See asm/cputype.h for the macros used below.
+ *
+ * model: MIDR_CPU_MODEL of CPU
+ * rv_min: Minimum of MIDR_CPU_VAR_REV()
+ * rv_max: Maximum of MIDR_CPU_VAR_REV()
+ * res: Result register.
+ * tmp1, tmp2, tmp3: Temporary registers
+ *
+ * Corrupts: res, tmp1, tmp2, tmp3
+ * Returns: 0, if the CPU id doesn't match. Non-zero otherwise
+ */
+ .macro cpu_midr_match model, rv_min, rv_max, res, tmp1, tmp2, tmp3
+ mrs \res, midr_el1
+ mov_q \tmp1, (MIDR_REVISION_MASK | MIDR_VARIANT_MASK)
+ mov_q \tmp2, MIDR_CPU_MODEL_MASK
+ and \tmp3, \res, \tmp2 // Extract model
+ and \tmp1, \res, \tmp1 // rev & variant
+ mov_q \tmp2, \model
+ cmp \tmp3, \tmp2
+ cset \res, eq
+ cbz \res, .Ldone\@ // Model matches ?
+
+ .if (\rv_min != 0) // Skip min check if rv_min == 0
+ mov_q \tmp3, \rv_min
+ cmp \tmp1, \tmp3
+ cset \res, ge
+ .endif // \rv_min != 0
+ /* Skip rv_max check if rv_min == rv_max && rv_min != 0 */
+ .if ((\rv_min != \rv_max) || \rv_min == 0)
+ mov_q \tmp2, \rv_max
+ cmp \tmp1, \tmp2
+ cset \tmp2, le
+ and \res, \res, \tmp2
+ .endif
+.Ldone\@:
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 9ee3038..39d1db6 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -56,6 +56,9 @@
(0xf << MIDR_ARCHITECTURE_SHIFT) | \
((partnum) << MIDR_PARTNUM_SHIFT))
+#define MIDR_CPU_VAR_REV(var, rev) \
+ (((var) << MIDR_VARIANT_SHIFT) | (rev))
+
#define MIDR_CPU_MODEL_MASK (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | \
MIDR_ARCHITECTURE_MASK)
@@ -74,6 +77,7 @@
#define ARM_CPU_PART_AEM_V8 0xD0F
#define ARM_CPU_PART_FOUNDATION 0xD00
+#define ARM_CPU_PART_CORTEX_A55 0xD05
#define ARM_CPU_PART_CORTEX_A57 0xD07
#define ARM_CPU_PART_CORTEX_A72 0xD08
#define ARM_CPU_PART_CORTEX_A53 0xD03
@@ -89,6 +93,7 @@
#define BRCM_CPU_PART_VULCAN 0x516
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
+#define MIDR_CORTEX_A55 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A55)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
#define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A72)
#define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A73)
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 619da1c..66cce21 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -425,6 +425,11 @@ ENTRY(__cpu_setup)
cbz x9, 2f
cmp x9, #2
b.lt 1f
+#ifdef CONFIG_ARM64_ERRATUM_1024718
+ /* Disable hardware DBM on Cortex-A55 r0p0, r0p1 & r1p0 */
+ cpu_midr_match MIDR_CORTEX_A55, MIDR_CPU_VAR_REV(0, 0), MIDR_CPU_VAR_REV(1, 0), x1, x2, x3, x4
+ cbnz x1, 1f
+#endif
orr x10, x10, #TCR_HD // hardware Dirty flag update
1: orr x10, x10, #TCR_HA // hardware Access flag update
2:
--
2.7.4
^ permalink raw reply related
* [PATCH RESEND v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace
From: Arnaldo Carvalho de Melo @ 2018-05-11 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525924920-4381-1-git-send-email-leo.yan@linaro.org>
Em Thu, May 10, 2018 at 12:01:59PM +0800, Leo Yan escreveu:
> CoreSight doesn't allocate thread structure for unknown_thread in etm
> auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
> contain valid tid and then cs_etm__mem_access() uses unknown_thread
> instead as thread handler, this results in segmentation fault when
> thread__find_addr_map() accesses thread handler.
>
> This commit creates new thread data which is used by unknown_thread, so
> CoreSight tracing can roll back to use unknown_thread if perf data
> doesn't include valid thread info. This commit also releases thread
> data for initialization failure case and for normal auxtrace free flow.
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Thanks, applied to perf/urgent.
And please use a more descriptive, eye catching summary, something like:
perf cs-etm: Fix segfault when accessing NULL unknown_thread variable
:-)
- Arnaldo
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a77995: Add VIN4
From: Simon Horman @ 2018-05-11 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511112523.GK18974@bigcity.dyn.berto.se>
On Fri, May 11, 2018 at 01:25:23PM +0200, Niklas S?derlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-11 12:00:01 +0200, Jacopo Mondi wrote:
> > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
>
> > ---
> > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > index 82aed7e..bdf7017 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > @@ -783,6 +783,17 @@
> > };
> > };
> > };
> > +
> > + vin4: video at e6ef4000 {
> > + compatible = "renesas,vin-r8a77995";
> > + reg = <0 0xe6ef4000 0 0x1000>;
> > + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 807>;
> > + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> > + resets = <&cpg 807>;
> > + renesas,id = <4>;
> > + status = "disabled";
> > + };
> > };
Thanks, I have moved the new node to preserve sorting of nodes by bus
address and applied the result. It is as follows:
From: Jacopo Mondi <jacopo+renesas@jmondi.org>
Subject: [PATCH] arm64: dts: renesas: r8a77995: Add VIN4
Describe VIN4 interface for R-Car D3 R8A77995 SoC.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
[simon: sorted node by bus address]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index ba98865b0c9b..2506f46293e8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -610,6 +610,17 @@
status = "disabled";
};
+ vin4: video at e6ef4000 {
+ compatible = "renesas,vin-r8a77995";
+ reg = <0 0xe6ef4000 0 0x1000>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 807>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 807>;
+ renesas,id = <4>;
+ status = "disabled";
+ };
+
ohci0: usb at ee080000 {
compatible = "generic-ohci";
reg = <0 0xee080000 0 0x100>;
--
2.11.0
^ permalink raw reply related
* [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa
From: Suzuki K Poulose @ 2018-05-11 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <85e04362-05dd-c697-e9c4-ad5824e63819@gmail.com>
Marc
Thanks for looping me in. Comments below.
On 03/05/18 03:02, Jia He wrote:
> Hi Marc
>
> Thanks for the review
>
>
> On 5/2/2018 10:26 PM, Marc Zyngier Wrote:
>> [+ Suzuki]
>>
>> On 02/05/18 08:08, Jia He wrote:
>>> From: Jia He <jia.he@hxt-semitech.com>
>>>
>>> In our armv8a server (QDF2400), I noticed a WARN_ON as follows:
>>>
>>> [? 800.202850] WARNING: CPU: 33 PID: 255 at arch/arm64/kvm/../../../virt/kvm/arm/mmu.c:1670 kvm_age_hva_handler+0xcc/0xd4
>> Which kernel version is that? I don't have a WARN_ON() at this line in
>> 4.17. Do you have a reproducer?
> My running kernel version is v4.14-15, but I can reproduced it in 4.17 (start 20 guests and run memhog in the host)
> In 4.17, the warn_on is at
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/virt/kvm/arm/mmu.c#n1826
>>
>>> [? 800.213535] Modules linked in: vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm vfat fat iw_cm mlx5_ib ib_core dm_mirror dm_region_hash dm_log dm_mod crc32_ce ipmi_ssif sg nfsd
>>> [? 800.284115]? auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c mlx5_core ixgbe mlxfw devlink mdio ahci_platform libahci_platform qcom_emac libahci hdma hdma_mgmt i2c_qup
>>> [? 800.300382] CPU: 33 PID: 255 Comm: khugepaged Tainted: G??????? W?????? 4.14.36+ #6
>>> [? 800.308030] Hardware name: <snip for confidential issues>
>> Well, that's QDF2400, right? ;-)
> yes, exactly :)
>>
>>> [? 800.318717] task: ffff8017c949c000 task.stack: ffff8017c9498000
>>> [? 800.324629] PC is at kvm_age_hva_handler+0xcc/0xd4
>>> [? 800.329412] LR is at handle_hva_to_gpa+0xec/0x15c
>>> [? 800.334109] pc : [<ffff0000080b4f2c>] lr : [<ffff0000080b4838>] pstate: 20400145
>>> [? 800.341496] sp : ffff8017c949b260
>>> [? 800.344804] x29: ffff8017c949b260 x28: ffff801663e25008
>>> [? 800.350110] x27: 0000000000020000 x26: 00000001fb1a0000
>>> [? 800.355416] x25: 0000ffff605b0200 x24: 0000ffff605a0200
>>> [? 800.360722] x23: 0000000000000000 x22: 000000000000ffff
>>> [? 800.366028] x21: 00000001fb1a0000 x20: ffff8017c085a000
>>> [? 800.371334] x19: ffff801663e20008 x18: 0000000000000000
>>> [? 800.376641] x17: 0000000000000000 x16: 0000000000000000
>>> [? 800.381947] x15: 0000000000000000 x14: 3d646e655f617668
>>> [? 800.387254] x13: 2c30303230623530 x12: 36666666663d646e
>>> [? 800.392560] x11: 652c303032306135 x10: 3036666666663d74
>>> [? 800.397867] x9 : 0000000000003796 x8 : 655f6e66672c3030
>>> [? 800.403173] x7 : ffff00000859434c x6 : ffff8017f9c30cb8
>>> [? 800.408479] x5 : ffff8017f9c30cb8 x4 : ffff0000080b4e60
>>> [? 800.413786] x3 : 0000000000000000 x2 : 0000000000020000
>>> [? 800.419092] x1 : 00000001fb1a0000 x0 : 0000000020000000
>>> [? 800.424398] Call trace:
>>> [? 800.426838] Exception stack(0xffff8017c949b120 to 0xffff8017c949b260)
>>> [? 800.433272] b120: 0000000020000000 00000001fb1a0000 0000000000020000 0000000000000000
>>> [? 800.441095] b140: ffff0000080b4e60 ffff8017f9c30cb8 ffff8017f9c30cb8 ffff00000859434c
>>> [? 800.448918] b160: 655f6e66672c3030 0000000000003796 3036666666663d74 652c303032306135
>>> [? 800.456740] b180: 36666666663d646e 2c30303230623530 3d646e655f617668 0000000000000000
>>> [? 800.464563] b1a0: 0000000000000000 0000000000000000 0000000000000000 ffff801663e20008
>>> [? 800.472385] b1c0: ffff8017c085a000 00000001fb1a0000 000000000000ffff 0000000000000000
>>> [? 800.480208] b1e0: 0000ffff605a0200 0000ffff605b0200 00000001fb1a0000 0000000000020000
>>> [? 800.488030] b200: ffff801663e25008 ffff8017c949b260 ffff0000080b4838 ffff8017c949b260
>>> [? 800.495853] b220: ffff0000080b4f2c 0000000020400145 0000000000000001 ffff8017c949b2a0
>>> [? 800.503676] b240: ffffffffffffffff ffff8017c949b260 ffff8017c949b260 ffff0000080b4f2c
>>> [? 800.511498] [<ffff0000080b4f2c>] kvm_age_hva_handler+0xcc/0xd4
>>> [? 800.517324] [<ffff0000080b4838>] handle_hva_to_gpa+0xec/0x15c
>>> [? 800.523063] [<ffff0000080b6c5c>] kvm_age_hva+0x5c/0xcc
>>> [? 800.528194] [<ffff0000080a7c3c>] kvm_mmu_notifier_clear_flush_young+0x54/0x90
>>> [? 800.535324] [<ffff00000827a0e8>] __mmu_notifier_clear_flush_young+0x6c/0xa8
>>> [? 800.542279] [<ffff00000825a644>] page_referenced_one+0x1e0/0x1fc
>>> [? 800.548279] [<ffff00000827e8f8>] rmap_walk_ksm+0x124/0x1a0
>>> [? 800.553759] [<ffff00000825c974>] rmap_walk+0x94/0x98
>>> [? 800.558717] [<ffff00000825ca98>] page_referenced+0x120/0x180
>>> [? 800.564369] [<ffff000008228c58>] shrink_active_list+0x218/0x4a4
>>> [? 800.570281] [<ffff000008229470>] shrink_node_memcg+0x58c/0x6fc
>>> [? 800.576107] [<ffff0000082296c4>] shrink_node+0xe4/0x328
>>> [? 800.581325] [<ffff000008229c9c>] do_try_to_free_pages+0xe4/0x3b8
>>> [? 800.587324] [<ffff00000822a094>] try_to_free_pages+0x124/0x234
>>> [? 800.593150] [<ffff000008216aa0>] __alloc_pages_nodemask+0x564/0xf7c
>>> [? 800.599412] [<ffff000008292814>] khugepaged_alloc_page+0x38/0xb8
>>> [? 800.605411] [<ffff0000082933bc>] collapse_huge_page+0x74/0xd70
>>> [? 800.611238] [<ffff00000829470c>] khugepaged_scan_mm_slot+0x654/0xa98
>>> [? 800.617585] [<ffff000008294e0c>] khugepaged+0x2bc/0x49c
>>> [? 800.622803] [<ffff0000080ffb70>] kthread+0x124/0x150
>>> [? 800.627762] [<ffff0000080849f0>] ret_from_fork+0x10/0x1c
>>> [? 800.633066] ---[ end trace 944c130b5252fb01 ]---
>>> -------------------------------------------------------------------------
>>>
>>> The root cause might be: we can't guarantee that the parameter start and end
>>> in handle_hva_to_gpa is PAGE_SIZE aligned, let alone hva_start and hva_end.
>> So why not aligning them the first place?
> at the first place of handle_hva_to_gpa()?
> but boundary check is needed in each loop of kvm_for_each_memslot. Am I missing anything here?
>>
>>> This bug is introduced by commit 056aad67f836 ("kvm: arm/arm64: Rework gpa
>>> callback handlers")
>>>
>>> It fixes the bug by use pfn size converted.
>>>
>>> Fixes: 056aad67f836 ("kvm: arm/arm64: Rework gpa callback handlers")
>>>
>>> Signed-off-by: jia.he at hxt-semitech.com
>>> Signed-off-by: li.zhang at hxt-semitech.com
>>> ---
>>> ? virt/kvm/arm/mmu.c | 10 ++++++----
>>> ? 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>>> index 7f6a944..9dd7ae4 100644
>>> --- a/virt/kvm/arm/mmu.c
>>> +++ b/virt/kvm/arm/mmu.c
>>> @@ -1744,7 +1744,7 @@ static int handle_hva_to_gpa(struct kvm *kvm,
>>> ????? /* we only care about the pages that the guest sees */
>>> ????? kvm_for_each_memslot(memslot, slots) {
>>> ????????? unsigned long hva_start, hva_end;
>>> -??????? gfn_t gpa;
>>> +??????? gpa_t gpa, gpa_end;
>>> ????????? hva_start = max(start, memslot->userspace_addr);
>>> ????????? hva_end = min(end, memslot->userspace_addr +
>>> @@ -1753,7 +1753,9 @@ static int handle_hva_to_gpa(struct kvm *kvm,
>>> ????????????? continue;
>>> ????????? gpa = hva_to_gfn_memslot(hva_start, memslot) << PAGE_SHIFT;
>>> -??????? ret |= handler(kvm, gpa, (u64)(hva_end - hva_start), data);
>>> +??????? gpa_end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, memslot)
>>> +???????????????????????????? << PAGE_SHIFT;
>>> +??????? ret |= handler(kvm, gpa, (u64)(gpa_end - gpa), data);
>> But we're looking for the mapping in the same memslot, so the distance
>> between hva and hva_end is the same as the one between gpa and gpa_end
>> if you didn't align it.
> maybe not, sometimes hva_end-hva != gpa_end-gpa
> start=fffdc37f0200,hva_start=fffdc37f0200,end=fffdc3800200,hva_end=fffdc3800000,gpa=3ff0000,gfn_end=4000000
>
> but sometimes it is:
> start=ffff60590200,hva_start=ffff60590200,end=ffff605a0200,hva_end=ffff605a0200,gpa=1fb190000,gfn_end=1fb1b0000
>
> IMO, the unalignment is caused by the ksm stable page flag STABLE_FLAG. I will
> propose another ksm patch to fix it?
> But from handle_hva_to_gpa's point of view, arm kvm needs to void the followup
> exception, just like what powerpc andx86 have done.
As far as I can see this is triggered by someone (in this page_referenced_one via ksm?)
triggering a clear_flush_young for a page, with a non-aligned page address.
If you look at the code path, the __mmu_notifier_clear_flush_young is invoked
via 2 code paths with the "given" address.
ptep_clear_flush_young_notify(), in which case the end is set to + PAGE_SIZE
pmdp_clear_flush_young_notify(), in which case the end is set to + PMD_SIZE
We were supposed to only clear_flush_young for *the page* containing
address (start), but we do a clear_flush_young for the next page
as well, which (I think) is not something intended. So to me, it looks like, either
page_referenced_one() or its caller must align the address to the PAGE_SIZE
or PMD_SIZE depending on what it really wants to do, to avoid touching
the adjacent entries (page or block pages).
Suzuki
>
>>
>> So why not align both start and end and skip the double lookup?
>>
>>> ????? }
>>> ????? return ret;
>>> @@ -1823,7 +1825,7 @@ static int kvm_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
>>> ????? pmd_t *pmd;
>>> ????? pte_t *pte;
>>> -??? WARN_ON(size != PAGE_SIZE && size != PMD_SIZE);
>>> +??? WARN_ON((size & ~PAGE_MASK) != 0);
>>> ????? pmd = stage2_get_pmd(kvm, NULL, gpa);
>>> ????? if (!pmd || pmd_none(*pmd))??? /* Nothing there */
>>> ????????? return 0;
>>> @@ -1843,7 +1845,7 @@ static int kvm_test_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *
>>> ????? pmd_t *pmd;
>>> ????? pte_t *pte;
>>> -??? WARN_ON(size != PAGE_SIZE && size != PMD_SIZE);
>>> +??? WARN_ON((size & ~PAGE_MASK) != 0);
>>> ????? pmd = stage2_get_pmd(kvm, NULL, gpa);
>>> ????? if (!pmd || pmd_none(*pmd))??? /* Nothing there */
>>> ????????? return 0;
>>>
>> I'll let Suzuki comment on this, but I'm a bit suspicious of this patch.
> sure, more comments, more clear for the issue.
>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support
From: Simon Horman @ 2018-05-11 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526032802-14376-2-git-send-email-jacopo+renesas@jmondi.org>
On Fri, May 11, 2018 at 12:00:00PM +0200, Jacopo Mondi wrote:
> Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by
> rcar-vin driver.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [GIT PULL] firmware: scmi: fixes for v4.17 (part 2)
From: Sudeep Holla @ 2018-05-11 13:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM-SoC team,
Please pull !
Regards,
Sudeep
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-fixes-4.17
for you to fetch changes up to 31c6085562a03124d3f6a5c43dd9888ac44495a5:
firmware: arm_scmi: Use after free in scmi_create_protocol_device() (2018-05-08 18:03:47 +0100)
----------------------------------------------------------------
SCMI fix for v4.17
A single patch to ensure that the scmi device is not used for setting up
scmi handle after it's freed(fixes use after free).
----------------------------------------------------------------
Dan Carpenter (1):
firmware: arm_scmi: Use after free in scmi_create_protocol_device()
drivers/firmware/arm_scmi/driver.c | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH] [stable 4.14] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
From: Greg KH @ 2018-05-11 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526037802-13305-1-git-send-email-suzuki.poulose@arm.com>
On Fri, May 11, 2018 at 12:23:22PM +0100, Suzuki K Poulose wrote:
> commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
>
> Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> from an erratum 1024718, which causes incorrect updates when DBM/AP
> bits in a page table entry is modified without a break-before-make
> sequence. The work around is to disable the hardware DBM feature
> on the affected cores. The hardware Access Flag management features
> is not affected.
>
> The hardware DBM feature is a non-conflicting capability, i.e, the
> kernel could handle cores using the feature and those without having
> the features running at the same time. So this work around is detected
> at early boot time, rather than delaying it until the CPUs are brought
> up into the kernel with MMU turned on. This also avoids other complexities
> with late CPUs turning online, with or without the hardware DBM features.
>
> Cc: stable at vger.kernel.org # v4.14
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Note: The upstream commit is on top of a reworked capability
> infrastructure for arm64 heterogeneous systems, which allows
> delaying the CPU model checks. This backport is based on the
> original version of the patch [0], which checks the affected
> CPU models during the early boot.
>
> [0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose at arm.com
Thanks for the backport, now applied.
greg k-h
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: vexpress: use standard gpio bindings for sys_{led,mci,flash}
From: Sudeep Holla @ 2018-05-11 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKsGV8rrox2hSioASD+96ws9JLTo_DLw9nKwAgr5uZ_3g@mail.gmail.com>
On 11/05/18 13:10, Rob Herring wrote:
> On Fri, May 11, 2018 at 5:23 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Commit 2cff6dba57b7 ("ARM: dts: vexpress: fix node name unit-address presence warnings")
>> removed the unit address as there was no associated reg property in
>> these sysreg nodes.
>>
>> Also the latest DTC throws warnings for character '_' in the node names.
>>
>> Warning (node_name_chars_strict): /sysreg at 10000/sys_led: Character '_' not recommended in node name
>> Warning (node_name_chars_strict): /sysreg at 10000/sys_mci: Character '_' not recommended in node name
>> Warning (node_name_chars_strict): /sysreg at 10000/sys_flash: Character '_' not recommended in node name
>>
>> The correct way to fix this as well as the original unit-address presence
>> warnings is to use the standard gpio controller binding and specify the
>> reg properties as per the hardware as it was before.
>>
>> However note that Vexpress sysreg MFD driver will still continue to use
>> the hardcoded values for compatibility reasons.
>>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Suggested-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 11 ++++++++---
>> arch/arm/boot/dts/vexpress-v2m.dtsi | 11 ++++++++---
>> 2 files changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>> index 7b8ff5b3b912..a8586a0b957d 100644
>> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>> @@ -76,21 +76,26 @@
>> v2m_sysreg: sysreg at 10000 {
>> compatible = "arm,vexpress-sysreg";
>> reg = <0x010000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>
> You need a ranges here and below to translate from 0-0x10000 range.
>
> With that,
>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
Thanks, I have appended it with below change
Regards,
Sudeep
--
diff --git c/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
w/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index a8586a0b957d..4488c8fe213a 100644
--- c/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ w/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -78,6 +78,7 @@
reg = <0x010000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0x10000 0x1000>;
v2m_led_gpios: gpio at 8 {
compatible =
"arm,vexpress-sysreg,sys_led";
diff --git c/arch/arm/boot/dts/vexpress-v2m.dtsi
w/arch/arm/boot/dts/vexpress-v2m.dtsi
index 37ecccebd937..4db42f6326a3 100644
--- c/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ w/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -78,6 +78,7 @@
reg = <0x00000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0 0x1000>;
v2m_led_gpios: gpio at 8 {
compatible =
"arm,vexpress-sysreg,sys_led";
^ permalink raw reply related
* [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init
From: Pawel Moll @ 2018-05-11 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cee9c043-3d64-56b9-4f23-e8c8370387dd@gmail.com>
On Thu, 2018-05-10 at 01:22 +0100, Florian Fainelli wrote:
> I don't have any dog in this, but maybe if providing information to
> the
> users is so essential to having a pleasant user experience, then
> rethinking the whole way these messages are funneled is necessary
> because the kernel log + dmesg is by no means appropriate. Take a look
> at what the networking maintainers recently did with netlink extended
> ack. You used to just get an "unsupported" error, and now you know
> exactly what is wrong when extack is available. It seems to me like
> something like this is what you might want here since you want to have
> perf be as user friendly as possible.
>
> My 2 cents.
I couldn't agree more. I find the advice "check the dmesg, you may find
something there" that perf tool uses currently... well, pretty lame
(although this was exactly the reason I started dmesg-ing error details
in the first place).
One could play the "you're breaking userspace promise" card here, but
considering that the number of people actually using CCN PMU is...
small, I don't want to do this.
But so far no one was determined enough to get better error reporting
in place. I have ran out of time when I tried it 2 or 3 years ago, I
believe Kim has discussed some approaches and received pushback. Kim
would be better suited to summarize what has happened so far...
Regards
Pawe?
^ permalink raw reply
* [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init
From: Pawel Moll @ 2018-05-11 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509161120.ilnukvismwfb452g@lakrids.cambridge.arm.com>
Apologies about delay - I was away yesterday. And advance apologies
about - most likely - not participating in discussions in the next 4
weeks, but I'll be on holiday in rather remote areas.
On Wed, 2018-05-09 at 17:12 +0100, Mark Rutland wrote:
> True. I'll reword the above to:
>
> The ARM CCN PMU driver uses dev_warn() to complain about parameters
> in
> the user-provided perf_event_attr. This means that under normal
> operation (e.g. a single invocation of the perf tool), a number of
> messages warnings may be logged to dmesg.
>
> ... with that, can I take your ack?
I'm by no means enthusiastic nor happy about this change, so I'd rather
say "you won't get my NAK" (although even this wouldn't matter much, I
believe...)
Pawe?
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Lucas Stach @ 2018-05-11 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511123915.GC16141@n2100.armlinux.org.uk>
Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> > Hi,
> >
> > I need one help.
> > I am using i.MX7 Sabre board with kernel version 4.1.15
> >
> > Let's say I am interested in GPIO number: 21
> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
> > tried the below steps:
> > root at 10:~# echo 21 > /sys/class/gpio/export
> > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > root at 10:~# cat /proc/interrupts | grep 21
> > 47: 0 0 gpio-mxc 21 Edge gpiolib
> > root at 10:~# cat /sys/class/gpio/gpio21/direction
> > in
> > root at 10:~# cat /proc/irq/47/smp_affinity
> > 3
> > root at 10:~# echo 2 > /proc/irq/47/smp_affinity
> > -bash: echo: write error: Input/output error
> >
> > But I get input/output error.
> > When I debug further, found that irq_can_set_affinity is returning 0:
> > [ 0.000000] genirq: irq_can_set_affinity (0): balance: 1,
> > irq_data.chip: a81b7e48, irq_set_affinity: (null)
> > [ 0.000000] write_irq_affinity: FAIL
> >
> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
> > This change is working, but the smp_affinity setting for the new IRQ
> > is not working.
> >
> > When I try to set smp_affinity for mmc0, then it works.
> > # cat /proc/interrupts | grep mmc
> > 295: 55 0 GPCV2 22 Edge mmc0
> > 296: 0 0 GPCV2 23 Edge mmc1
> > 297: 52 0 GPCV2 24 Edge mmc2
> >
> > root at 10:~# echo 2 > /proc/irq/295/smp_affinity
> > root at 10:~#
> >
> >
> > So, I wanted to know what are the conditions for which setting
> > smp_affinity for an IRQ will work ?
> >
> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
> > Whether, irq_set_affinity_hint() will work in this case ?
>
> IRQ affinity is only supported where interrupts are _directly_ wired to
> the GIC. It's the GIC which does the interrupt steering to the CPU
> cores.
>
> Interrupts on downstream interrupt controllers (such as GPCV2) have no
> ability to be directed independently to other CPUs - the only possible
> way to change the mapping is to move _all_ interrupts on that controller,
> and any downstream chained interrupts at GIC level.
>
> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
> for the interrupt controller itself to change the affinity of the input
> interrupt.
The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
handled by forwarding the request to the GIC by
irq_chip_set_affinity_parent().
As this is handled correctly in the upstream kernel since the first
commit introducing support for the GPCv2, it seems the issue is only
present in some downstream kernel.
Regards,
Lucas
^ permalink raw reply
* [PATCH 03/20] arc: use generic dma_noncoherent_ops
From: Alexey Brodkin @ 2018-05-11 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511075945.16548-4-hch@lst.de>
Hi Christoph,
On Fri, 2018-05-11 at 09:59 +0200, Christoph Hellwig wrote:
> Switch to the generic noncoherent direct mapping implementation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arc/Kconfig | 4 +
> arch/arc/include/asm/Kbuild | 1 +
> arch/arc/include/asm/dma-mapping.h | 21 -----
> arch/arc/mm/dma.c | 141 +++--------------------------
> 4 files changed, 19 insertions(+), 148 deletions(-)
> delete mode 100644 arch/arc/include/asm/dma-mapping.h
Sorry I didn't try your proposed fix earlier - was away for a couple of days.
But that newer version with fixed lib/dma-noncoherent.c still doesn't work on ARC.
USB ECHI controller fails like that:
------------------------->8-------------------------
usb 1-1: new high-speed USB device number 2 using ehci-platform
usb 1-1: can't set config #1, error -32
------------------------->8-------------------------
Again with entire series reverted USB starts to work.
Let's wait for other arches previously affected to update on their status.
-Alexey
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Russell King - ARM Linux @ 2018-05-11 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOuPNLgbT59h=Jm5YiOCbrqFkDokJ8xutQ_OkpsFYzKazKhTHg@mail.gmail.com>
On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> Hi,
>
> I need one help.
> I am using i.MX7 Sabre board with kernel version 4.1.15
>
> Let's say I am interested in GPIO number: 21
> I wanted to set CPU affinity for particular GPIO->IRQ number, so I
> tried the below steps:
> root at 10:~# echo 21 > /sys/class/gpio/export
> root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> root at 10:~# cat /proc/interrupts | grep 21
> 47: 0 0 gpio-mxc 21 Edge gpiolib
> root at 10:~# cat /sys/class/gpio/gpio21/direction
> in
> root at 10:~# cat /proc/irq/47/smp_affinity
> 3
> root at 10:~# echo 2 > /proc/irq/47/smp_affinity
> -bash: echo: write error: Input/output error
>
> But I get input/output error.
> When I debug further, found that irq_can_set_affinity is returning 0:
> [ 0.000000] genirq: irq_can_set_affinity (0): balance: 1,
> irq_data.chip: a81b7e48, irq_set_affinity: (null)
> [ 0.000000] write_irq_affinity: FAIL
>
> I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
> This change is working, but the smp_affinity setting for the new IRQ
> is not working.
>
> When I try to set smp_affinity for mmc0, then it works.
> # cat /proc/interrupts | grep mmc
> 295: 55 0 GPCV2 22 Edge mmc0
> 296: 0 0 GPCV2 23 Edge mmc1
> 297: 52 0 GPCV2 24 Edge mmc2
>
> root at 10:~# echo 2 > /proc/irq/295/smp_affinity
> root at 10:~#
>
>
> So, I wanted to know what are the conditions for which setting
> smp_affinity for an IRQ will work ?
>
> Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
> Whether, irq_set_affinity_hint() will work in this case ?
IRQ affinity is only supported where interrupts are _directly_ wired to
the GIC. It's the GIC which does the interrupt steering to the CPU
cores.
Interrupts on downstream interrupt controllers (such as GPCV2) have no
ability to be directed independently to other CPUs - the only possible
way to change the mapping is to move _all_ interrupts on that controller,
and any downstream chained interrupts at GIC level.
Hence why Interrupt 295 has no irq_set_affinity function: there is no way
for the interrupt controller itself to change the affinity of the input
interrupt.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c
From: Andrey Konovalov @ 2018-05-11 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508151137.zguepljs3pa7xv5g@armageddon.cambridge.arm.com>
On Tue, May 8, 2018 at 5:11 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, May 02, 2018 at 07:25:17PM +0200, Andrey Konovalov wrote:
>> On Wed, May 2, 2018 at 5:36 PM, Kirill A. Shutemov
>> <kirill.shutemov@linux.intel.com> wrote:
>> > On Wed, May 02, 2018 at 02:38:42PM +0000, Andrey Konovalov wrote:
>> >> > Does having a tagged address here makes any difference? I couldn't hit a
>> >> > failure with my simple tests (LD_PRELOAD a library that randomly adds
>> >> > tags to pointers returned by malloc).
>> >>
>> >> I think you're right, follow_page_mask is only called from
>> >> __get_user_pages, which already untagged the address. I'll remove
>> >> untagging here.
>> >
>> > It also called from follow_page(). Have you covered all its callers?
>>
>> Oh, missed that, will take a look.
>>
>> Thinking about that, would it make sense to add untagging to find_vma
>> (and others) instead of trying to cover all find_vma callers?
>
> I don't think adding the untagging to find_vma() is sufficient. In many
> cases the caller does a subsequent check like 'start < vma->vm_start'
> (see sys_msync() as an example, there are a few others as well).
OK.
> What I
> did in my tests was a WARN_ON_ONCE() in find_vma() if the address is
> tagged.
So this is similar to what I did.
Do you think trying to find "all places where we cast out __user" with
static analysis as Kirill suggested is something I should pursue? Or
is this patchset is good as is as the first approximation, since we
can fix more things where untagging is needed as we discover them one
by one?
^ permalink raw reply
* [PATCH] arm64: dts: stratix10: Add QSPI support for Stratix10
From: Rob Herring @ 2018-05-11 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525985204-11525-1-git-send-email-thor.thayer@linux.intel.com>
On Thu, May 10, 2018 at 3:46 PM, <thor.thayer@linux.intel.com> wrote:
> From: Thor Thayer <thor.thayer@linux.intel.com>
>
> Add qspi_clock
> The qspi_clk frequency is updated by U-Boot before starting Linux.
> Add QSPI interface node.
> Add QSPI flash memory child node.
> Setup the QSPI memory in 2 partitions.
>
> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
> ---
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 22 +++++++++++++++
> .../boot/dts/altera/socfpga_stratix10_socdk.dts | 31 ++++++++++++++++++++++
> 2 files changed, 53 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> index e6b059378dc0..ed47dfce3ba6 100644
> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> @@ -119,6 +119,12 @@
> #clock-cells = <0>;
> compatible = "fixed-clock";
> };
> +
> + qspi_clk: qspi_clk {
s/_/-/
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <200000000>;
> + };
> };
>
> gmac0: ethernet at ff800000 {
> @@ -466,5 +472,21 @@
> interrupts = <16 4>, <48 4>;
> };
> };
> +
> + qspi: spi at ff8d2000 {
> + compatible = "cdns,qspi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xff8d2000 0x100>,
> + <0xff900000 0x100000>;
> + interrupts = <0 3 4>;
> + cdns,fifo-depth = <128>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x00000000>;
> + clocks = <&qspi_clk>;
> + bus-num = <1>;
> +
> + status = "disabled";
> + };
> };
> };
> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
> index f9b1ef12db48..60251462067a 100644
> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
> @@ -147,3 +147,34 @@
> reg = <0x68>;
> };
> };
> +
> +&qspi {
> + flash0: n25q00 at 0 {
flash at 0
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "n25q00aa";
> + reg = <0>;
> + spi-max-frequency = <50000000>;
> +
> + m25p,fast-read;
> + cdns,page-size = <256>;
> + cdns,block-size = <16>;
> + cdns,read-delay = <1>;
> + cdns,tshsl-ns = <50>;
> + cdns,tsd2d-ns = <50>;
> + cdns,tchsh-ns = <4>;
> + cdns,tslch-ns = <4>;
> +
> + partition at qspi-boot {
use a 'partitions' node to contain all the partitions.
> + label = "Boot and fpga data";
> + /* 64MB for boot and FPGA data */
> + reg = <0x0 0x4000000>;
> + };
> +
> + partition at qspi-rootfs {
> + label = "Root Filesystem - JFFS2";
> + /* 64MB for Linux jffs2 */
> + reg = <0x4000000 0x4000000>;
> + };
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328
From: Rob Herring @ 2018-05-11 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fdfcc9b-90b5-191c-37e0-c99389a4e872@t-chip.com.cn>
On Thu, May 10, 2018 at 10:45 PM, Levin Du <djw@t-chip.com.cn> wrote:
> On 2018-05-10 8:50 PM, Robin Murphy wrote:
>>
>> On 10/05/18 10:16, djw at t-chip.com.cn wrote:
>>>
>>> From: Levin Du <djw@t-chip.com.cn>
>>>
>>> Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
>>> access to the pins defined in the syscon GRF_SOC_CON10.
>>
>>
>> This is the GPIO_MUTE pin, right? The public TRM is rather vague, but
>> cross-referencing against the datasheet and schematics implies that it's the
>> "gpiomut_*" part of the GRF bit names which is most significant.
>>
>> It might be worth using a more descriptive name here, since "syscon10" is
>> pretty much meaningless at the board level.
>>
>> Robin.
>>
> Previously I though other bits might be able to reference from syscon10,
> other than GPIO_MUTE alone.
> If it is renamed to gpio-mute, then the GPIO_MUTE pin is accessed as
> `<&gpio-mute 1>`. Yet other
> bits in syscon10 can also be referenced, say, `<&gpio-mute 10>`, which is
> not good.
>
> I'd like to add a `gpio,syscon-bit` property to gpio-syscon, which overrides
> the properties
> of bit_count, data_bit_offset and dir_bit_offset in the driver. For
No. Once you are describing individual register bits, it is too low
level for DT.
> example:
>
> gpio_mute: gpio-mute {
> compatible = "rockchip,gpio-syscon";
> gpio-controller;
> #gpio-cells = <2>;
> gpio,syscon-dev = <0 0x0428 0>;
> gpio,syscon-bit = <1 1 0>;
> };
>
> That way, the mute pin is strictly specified as <&gpio_mute 0>, and
> <&gpio_mute 1> will be invalid.
> I think that is neat, and consistent with the gpio_mute name.
>
> Thanks
> Levin
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328
From: Rob Herring @ 2018-05-11 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-4-git-send-email-djw@t-chip.com.cn>
On Thu, May 10, 2018 at 4:16 AM, <djw@t-chip.com.cn> wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
> access to the pins defined in the syscon GRF_SOC_CON10.
>
> Boards using these special pins to control regulators or LEDs, can now
> utilize existing drivers like gpio-regulator and leds-gpio.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> Changes in v1:
> - Split from V0 and add to rk3328.dtsi for general use.
>
> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index b8e9da1..73a822d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -309,6 +309,12 @@
> mode-loader = <BOOT_BL_DOWNLOAD>;
> };
>
> + gpio_syscon10: gpio-syscon10 {
GPIO controller nodes should be named just 'gpio'.
> + compatible = "rockchip,gpio-syscon";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio,syscon-dev = <0 0x0428 0>;
This property is not documented and takes a phandle.
> + };
> };
>
> uart0: serial at ff110000 {
> --
> 2.7.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: vexpress: use standard gpio bindings for sys_{led, mci, flash}
From: Rob Herring @ 2018-05-11 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526034208-9690-1-git-send-email-sudeep.holla@arm.com>
On Fri, May 11, 2018 at 5:23 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Commit 2cff6dba57b7 ("ARM: dts: vexpress: fix node name unit-address presence warnings")
> removed the unit address as there was no associated reg property in
> these sysreg nodes.
>
> Also the latest DTC throws warnings for character '_' in the node names.
>
> Warning (node_name_chars_strict): /sysreg at 10000/sys_led: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /sysreg at 10000/sys_mci: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /sysreg at 10000/sys_flash: Character '_' not recommended in node name
>
> The correct way to fix this as well as the original unit-address presence
> warnings is to use the standard gpio controller binding and specify the
> reg properties as per the hardware as it was before.
>
> However note that Vexpress sysreg MFD driver will still continue to use
> the hardcoded values for compatibility reasons.
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 11 ++++++++---
> arch/arm/boot/dts/vexpress-v2m.dtsi | 11 ++++++++---
> 2 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index 7b8ff5b3b912..a8586a0b957d 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -76,21 +76,26 @@
> v2m_sysreg: sysreg at 10000 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x010000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
You need a ranges here and below to translate from 0-0x10000 range.
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
>
> - v2m_led_gpios: sys_led {
> + v2m_led_gpios: gpio at 8 {
> compatible = "arm,vexpress-sysreg,sys_led";
> + reg = <0x008 4>;
> gpio-controller;
> #gpio-cells = <2>;
> };
>
> - v2m_mmc_gpios: sys_mci {
> + v2m_mmc_gpios: gpio at 48 {
> compatible = "arm,vexpress-sysreg,sys_mci";
> + reg = <0x048 4>;
> gpio-controller;
> #gpio-cells = <2>;
> };
>
> - v2m_flash_gpios: sys_flash {
> + v2m_flash_gpios: gpio at 4c {
> compatible = "arm,vexpress-sysreg,sys_flash";
> + reg = <0x04c 4>;
> gpio-controller;
> #gpio-cells = <2>;
> };
> diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
> index 9cd5e146abd5..37ecccebd937 100644
> --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> @@ -76,21 +76,26 @@
> v2m_sysreg: sysreg at 0 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x00000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
>
> - v2m_led_gpios: sys_led {
> + v2m_led_gpios: gpio at 8 {
> compatible = "arm,vexpress-sysreg,sys_led";
> + reg = <0x008 4>;
> gpio-controller;
> #gpio-cells = <2>;
> };
>
> - v2m_mmc_gpios: sys_mci {
> + v2m_mmc_gpios: gpio at 48 {
> compatible = "arm,vexpress-sysreg,sys_mci";
> + reg = <0x048 4>;
> gpio-controller;
> #gpio-cells = <2>;
> };
>
> - v2m_flash_gpios: sys_flash {
> + v2m_flash_gpios: gpio at 4c {
> compatible = "arm,vexpress-sysreg,sys_flash";
> + reg = <0x04c 4>;
> gpio-controller;
> #gpio-cells = <2>;
> };
> --
> 2.7.4
>
^ permalink raw reply
* [GIT PULL] arm64: updates for 4.17
From: Catalin Marinas @ 2018-05-11 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADRPPNQhoXSGr4hpHaomcyamW51wT_F4fRTqZi4qtAD-jBHjxA@mail.gmail.com>
On Thu, May 10, 2018 at 11:03:18PM -0500, Yang Li wrote:
> On Wed, Apr 4, 2018 at 9:32 AM, Will Deacon <will.deacon@arm.com> wrote:
> > Please pull these arm64 updates for 4.17. Note that I've pulled in a
> > stable branch from Eric Biederman here to fulfil some siginfo dependencies,
> > so the diffstat strays slightly out of arm64 due to his changes.
> {snip}
> >
> > Catalin Marinas (1):
> > arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size)
>
> I'm wondering if we are changing the L1_CACHE_SHIFT to 6 in 4.17?
> This is causing big performance differences for us now.
We pushed it initially but there were some conflicts with the generic
dma work and we had to revert the above commit (so we are back to 7). I
plan to post it again, hopefully in time for 4.18.
--
Catalin
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Pintu Kumar @ 2018-05-11 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5af57fea.1c69fb81.885f0.2377.GMRIR@mx.google.com>
Hi,
I need one help.
I am using i.MX7 Sabre board with kernel version 4.1.15
Let's say I am interested in GPIO number: 21
I wanted to set CPU affinity for particular GPIO->IRQ number, so I
tried the below steps:
root at 10:~# echo 21 > /sys/class/gpio/export
root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
root at 10:~# cat /proc/interrupts | grep 21
47: 0 0 gpio-mxc 21 Edge gpiolib
root at 10:~# cat /sys/class/gpio/gpio21/direction
in
root at 10:~# cat /proc/irq/47/smp_affinity
3
root at 10:~# echo 2 > /proc/irq/47/smp_affinity
-bash: echo: write error: Input/output error
But I get input/output error.
When I debug further, found that irq_can_set_affinity is returning 0:
[ 0.000000] genirq: irq_can_set_affinity (0): balance: 1,
irq_data.chip: a81b7e48, irq_set_affinity: (null)
[ 0.000000] write_irq_affinity: FAIL
I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
This change is working, but the smp_affinity setting for the new IRQ
is not working.
When I try to set smp_affinity for mmc0, then it works.
# cat /proc/interrupts | grep mmc
295: 55 0 GPCV2 22 Edge mmc0
296: 0 0 GPCV2 23 Edge mmc1
297: 52 0 GPCV2 24 Edge mmc2
root at 10:~# echo 2 > /proc/irq/295/smp_affinity
root at 10:~#
So, I wanted to know what are the conditions for which setting
smp_affinity for an IRQ will work ?
Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
Whether, irq_set_affinity_hint() will work in this case ?
Thanks,
Pintu
^ permalink raw reply
* [PATCH] soc: mediatek: remove unneeded semicolon
From: Matthias Brugger @ 2018-05-11 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4b9c30335194d90072baf9373e41a21b349bc54.1525920846.git.sean.wang@mediatek.com>
On 05/10/2018 04:57 AM, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Fix up drivers/soc/mediatek/mtk-scpsys.c:255:2-3: Unneeded semicolon
> accidently being added in commit f9e2f65dd561 ("soc: mediatek: add a
> fixed wait for SRAM stable").
>
> Fixes: f9e2f65dd561 ("soc: mediatek: add a fixed wait for SRAM stable")
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
pushed to v4.17-next/soc
Thanks
> drivers/soc/mediatek/mtk-scpsys.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index 2080c8f..128e3dd 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -252,7 +252,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> if (ret < 0)
> goto err_pwr_ack;
> - };
> + }
>
> if (scpd->data->bus_prot_mask) {
> ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
>
^ 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