* [PATCH] ARM: dts: imx51-zii-rdu1: Do not specify "power-gpio" for hpa1
From: Fabio Estevam @ 2018-12-06 23:41 UTC (permalink / raw)
To: shawnguo
Cc: andrew.smirnov, Fabio Estevam, linux-arm-kernel, cphealy, l.stach
From: Andrey Smirnov <andrew.smirnov@gmail.com>
TPA6130A2 SD pin on RDU1 is not really controlled by SoC and instead
is only meant to notify the system that audio was "muted" by external
actors. To accommodate that, drop "power-gpio" property of hpa1 node as
well as specify a name for that GPIO so that userspace can access it.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index 28e9dca..a8220f0 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -478,6 +478,15 @@
};
&gpio1 {
+ gpio-line-names = "", "", "", "",
+ "", "", "", "",
+ "", "hp-amp-shutdown-b", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
unused-sd3-wp-gpio {
/*
* See pinctrl_esdhc1 below for more details on this
@@ -496,9 +505,6 @@
hpa1: amp@60 {
compatible = "ti,tpa6130a2";
reg = <0x60>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ampgpio>;
- power-gpio = <&gpio1 9 GPIO_ACTIVE_HIGH>;
Vdd-supply = <®_3p3v>;
};
@@ -672,7 +678,10 @@
};
&iomuxc {
- pinctrl_ampgpio: ampgpiogrp {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
fsl,pins = <
MX51_PAD_GPIO1_9__GPIO1_9 0x5e
>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 18/34] dt-bindings: arm: Convert FSL board/soc bindings to json-schema
From: Rob Herring @ 2018-12-06 23:33 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Kumar Gala, ARM-SoC Maintainers,
Sean Hudson, Frank Rowand, linux-kernel@vger.kernel.org,
Grant Likely, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20181206023140.GZ3987@dragon>
On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Mon, Dec 03, 2018 at 03:32:07PM -0600, Rob Herring wrote:
> > Convert Freescale SoC bindings to DT schema format using json-schema.
> >
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > .../devicetree/bindings/arm/armadeus.txt | 6 -
> > Documentation/devicetree/bindings/arm/bhf.txt | 6 -
> > .../bindings/arm/compulab-boards.txt | 25 --
> > Documentation/devicetree/bindings/arm/fsl.txt | 229 ------------------
> > .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++++++++++
>
> Rob,
>
> I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my
> tree, so please send it via your tree.
What about:
c386f362957b dt-bindings: Add compatible string for LS1028A-QDS
3671cd57de06 dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding
>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
From: Jolly Shah @ 2018-12-06 23:08 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Nava kishore Manne, linux-kernel@vger.kernel.org, Rajan Vaja,
Michal Simek, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181205222032.GA810@bogus>
Hi Rob,
> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Wednesday, December 05, 2018 2:21 PM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: mark.rutland@arm.com; devicetree@vger.kernel.org; Nava kishore Manne
> <navam@xilinx.com>; linux-kernel@vger.kernel.org; Rajan Vaja
> <RAJANV@xilinx.com>; Michal Simek <michals@xilinx.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
>
> On Wed, Dec 05, 2018 at 08:29:36PM +0000, Jolly Shah wrote:
> > Hi Rob,
> >
> > Thanks for the review. Please find my responses inline.
>
> You need to fix your mail client to wrap lines.
Thanks I will.
>
> > Thanks,
> > Jolly Shah
> >
> > > -----Original Message-----
> > > From: Rob Herring [mailto:robh@kernel.org]
> > > Sent: Tuesday, December 04, 2018 2:06 PM
> > > To: Jolly Shah <JOLLYS@xilinx.com>
> > > Cc: mark.rutland@arm.com; Michal Simek <michals@xilinx.com>; Rajan Vaja
> > > <RAJANV@xilinx.com>; Nava kishore Manne <navam@xilinx.com>; linux-
> arm-
> > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > devicetree@vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com>
> > > Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP
> core
> > >
> > > On Fri, Nov 16, 2018 at 03:56:50PM -0800, Jolly Shah wrote:
> > > > Base firmware node and clock child node binding are part of mainline
> kernel.
> > > This patchset adds documentation to describe rest of the firmware child
> node
> > > bindings.
> > > > Complete firmware DT node example is shown below for ease of
> > > understanding:
> > >
> > > Shouldn't there be a fpga mgr node too? Called pcap IIRC.
> > >
> > [Jolly] As you suggested, we only added child nodes if the
> > sub-functions have their own resources (clks, irqs, etc.). FPGA doesn't
> > have any resources so not added . Firmware driver would still register
> > it as mfd device to instantiate the driver.
>
> Okay, but won't their need to be child devices for
There are no fpga child devices. Should it be moved out?
>
>
> >
> > > >
> > > > firmware {
> > > > zynqmp_firmware: zynqmp-firmware {
> > > > compatible = "xlnx,zynqmp-firmware";
> > > > method = "smc";
> > > > #power-domain-cells = <1>;
> > > > #reset-cells = <1>;
> > > >
> > > > zynqmp_clk: clock-controller {
> > > > #clock-cells = <1>;
> > > > compatible = "xlnx,zynqmp-clk";
> > > > clocks = <&pss_ref_clk>, <&video_clk>,
> > > <&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>;
> > > > clock-names = "pss_ref_clk", "video_clk",
> > > "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
> > > > };
> > > >
> > > > zynqmp_power: zynqmp-power {
> > > > compatible = "xlnx,zynqmp-power";
> > > > interrupts = <0 35 4>;
> > > > };
> > > >
> > > > nvmem_firmware {
> > > > compatible = "xlnx,zynqmp-nvmem-fw";
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > >
> > > > /* Data cells */
> > > > soc_revision: soc_revision {
> > > > reg = <0x0 0x4>;
> > > > };
> > > > };
> > > >
> > > > afi0: afi0 {
> > > > compatible = "xlnx,afi-fpga";
> > > > config-afi = <0 2>, <1 1>, <2 1>;
> > > > };
> > > >
> > > > qspi: spi@ff0f0000 {
> > >
> > > Why is this under firmware node?
> > [Jolly] Qspi is a user of eemi API provided by firmware node to
> > perform privileged register writes. Alternatively, we can keep such
> > user nodes outside of firmware node and keep nodes which firmware is
> > provider for like clock, reset, pins and power.
> > Please suggest.
>
> Child nodes of the firmware should be providers, not consumers (of the
> firmware). If you had a firmware interface to that provided a SPI
> interface, then it would be here. But just having a special mechanism to
> access the registers.
Ok got it. So will move it out.
>
> > >
> > > > compatible = "xlnx,zynqmp-qspi-1.0";
>
> If this same block works with unprivileged accesses, then you will need
> some way to distinguish that.
>
> > > > clock-names = "ref_clk", "pclk";
> > > > clocks = <&misc_clk &misc_clk>;
> > > > interrupts = <0 15 4>;
> > > > interrupt-parent = <&gic>;
> > > > num-cs = <1>;
> > > > reg = <0x0 0xff0f0000 0x1000>,<0x0 0xc0000000
> > > 0x8000000>;
> > > > };
> > > >
> > > > serdes: zynqmp_phy@fd400000 {
> > >
> > > And this?
> >
> > [Jolly] Same as above.
> >
> > >
> > > > compatible = "xlnx,zynqmp-psgtr";
> > > > status = "okay";
> > > > reg = <0x0 0xfd400000 0x0 0x40000>, <0x0 0xfd3d0000
> > > 0x0 0x1000>,
> > > > <0x0 0xff5e0000 0x0 0x1000>;
> > > > reg-names = "serdes", "siou", "lpd";
> > > >
> > > > lane0: lane@0 {
> > > > #phy-cells = <4>;
> > > > };
> > > > lane1: lane@1 {
> > > > #phy-cells = <4>;
> > > > };
> > > > lane2: lane@2 {
> > > > #phy-cells = <4>;
> > > > };
> > > > lane3: lane@3 {
> > > > #phy-cells = <4>;
> > > > };
> > > > };
> > > >
> > > > pinctrl_uart1_default: uart1-default {
> > >
> > > This goes under a pinctrl node.
> > [Jolly] Pincontrol node is not added as it doesn't have any
> > resources. As I understand, you suggest to still add pincontrol node
> > and this under pincontrol node.
>
> These nodes are resources, so yes you should have a child here.
Got it. Will add pinctrl node along with below resources.
> >
> > >
> > > > mux {
> > > > groups = "uart0_4_grp";
> > > > function = "uart0";
> > > > };
> > > >
> > > > conf {
> > > > groups = "uart0_4_grp";
> > > > slew-rate = <SLEW_RATE_SLOW>;
> > > > io-standard = <IO_STANDARD_LVCMOS18>;
> > > > };
> > > >
> > > > conf-rx {
> > > > pins = "MIO18";
> > > > bias-high-impedance;
> > > > };
> > > >
> > > > conf-tx {
> > > > pins = "MIO19";
> > > > bias-disable;
> > > > schmitt-cmos = <PIN_INPUT_TYPE_CMOS>;
> > > > };
> > > > };
> > > > zynqmp-r5-remoteproc@0 {
> > >
> > > Wrong unit-address and this doesn't belong here.
> > [Jolly] Again as it is one of the user of firmware APIs, its kept
> > here. Alternatively, we can keep such user nodes outside of firmware
> > node and keep nodes which firmware is provider for like clock, reset,
> > pins and power.
> > Please suggest.
>
> Yes, it should be outside this.
Ok.
>
> > >
> > > > compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
> > >
> > > 'remoteproc' is what the h/w block is called?
> >
> > [Jolly] The hw block is called rpu.
>
> Then call it that in the DT.
Ok.
Thanks,
Jolly Shah
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V5 6/7] arm64: mm: introduce 52-bit userspace support
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
On arm64 there is optional support for a 52-bit virtual address space.
To exploit this one has to be running with a 64KB page size and be
running on hardware that supports this.
For an arm64 kernel supporting a 48 bit VA with a 64KB page size,
some changes are needed to support a 52-bit userspace:
* TCR_EL1.T0SZ needs to be 12 instead of 16,
* TASK_SIZE needs to reflect the new size.
This patch implements the above when the support for 52-bit VAs is
detected at early boot time.
On arm64 userspace addresses translation is controlled by TTBR0_EL1. As
well as userspace, TTBR0_EL1 controls:
* The identity mapping,
* EFI runtime code.
It is possible to run a kernel with an identity mapping that has a
larger VA size than userspace (and for this case __cpu_set_tcr_t0sz()
would set TCR_EL1.T0SZ as appropriate). However, when the conditions for
52-bit userspace are met; it is possible to keep TCR_EL1.T0SZ fixed at
12. Thus in this patch, the TCR_EL1.T0SZ size changing logic is
disabled.
Signed-off-by: Steve Capper <steve.capper@arm.com>
---
Changed in V5, extra dependency for 52-bit support:
ARM64_PAN || !ARM64_SW_TTBR0_PAN
Changed in V4, pgd_index logic removed as we offset ttbr1 instead
---
arch/arm64/Kconfig | 4 ++++
arch/arm64/include/asm/assembler.h | 7 +++----
arch/arm64/include/asm/mmu_context.h | 3 +++
arch/arm64/include/asm/processor.h | 14 +++++++++-----
arch/arm64/kernel/head.S | 13 +++++++++++++
arch/arm64/mm/fault.c | 2 +-
arch/arm64/mm/mmu.c | 1 +
arch/arm64/mm/proc.S | 10 +++++++++-
8 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 787d7850e064..6a93d5bc7f76 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -709,6 +709,10 @@ config ARM64_PA_BITS_52
endchoice
+config ARM64_52BIT_VA
+ def_bool y
+ depends on ARM64_VA_BITS_48 && ARM64_64K_PAGES && (ARM64_PAN || !ARM64_SW_TTBR0_PAN)
+
config ARM64_PA_BITS
int
default 48 if ARM64_PA_BITS_48
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index e2fe378d2a63..243ec4f0c00f 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -342,11 +342,10 @@ alternative_endif
.endm
/*
- * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map
+ * tcr_set_t0sz - update TCR.T0SZ so that we can load the ID map
*/
- .macro tcr_set_idmap_t0sz, valreg, tmpreg
- ldr_l \tmpreg, idmap_t0sz
- bfi \valreg, \tmpreg, #TCR_T0SZ_OFFSET, #TCR_TxSZ_WIDTH
+ .macro tcr_set_t0sz, valreg, t0sz
+ bfi \valreg, \t0sz, #TCR_T0SZ_OFFSET, #TCR_TxSZ_WIDTH
.endm
/*
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 1e58bf58c22b..b125fafc611b 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -72,6 +72,9 @@ extern u64 idmap_ptrs_per_pgd;
static inline bool __cpu_uses_extended_idmap(void)
{
+ if (IS_ENABLED(CONFIG_ARM64_52BIT_VA))
+ return false;
+
return unlikely(idmap_t0sz != TCR_T0SZ(VA_BITS));
}
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index fe95fd8b065e..b363fc705be4 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -19,11 +19,12 @@
#ifndef __ASM_PROCESSOR_H
#define __ASM_PROCESSOR_H
-#define TASK_SIZE_64 (UL(1) << VA_BITS)
-
-#define KERNEL_DS UL(-1)
-#define USER_DS (TASK_SIZE_64 - 1)
-
+#define KERNEL_DS UL(-1)
+#ifdef CONFIG_ARM64_52BIT_VA
+#define USER_DS ((UL(1) << 52) - 1)
+#else
+#define USER_DS ((UL(1) << VA_BITS) - 1)
+#endif /* CONFIG_ARM64_52IT_VA */
#ifndef __ASSEMBLY__
#ifdef __KERNEL__
@@ -48,6 +49,9 @@
#define DEFAULT_MAP_WINDOW_64 (UL(1) << VA_BITS)
+extern u64 vabits_user;
+#define TASK_SIZE_64 (UL(1) << vabits_user)
+
#ifdef CONFIG_COMPAT
#define TASK_SIZE_32 UL(0x100000000)
#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 58fcc1edd852..c229d9cfe9bf 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -318,6 +318,19 @@ __create_page_tables:
adrp x0, idmap_pg_dir
adrp x3, __idmap_text_start // __pa(__idmap_text_start)
+#ifdef CONFIG_ARM64_52BIT_VA
+ mrs_s x6, SYS_ID_AA64MMFR2_EL1
+ and x6, x6, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
+ mov x5, #52
+ cbnz x6, 1f
+#endif
+ mov x5, #VA_BITS
+1:
+ adr_l x6, vabits_user
+ str x5, [x6]
+ dmb sy
+ dc ivac, x6 // Invalidate potentially stale cache line
+
/*
* VA_BITS may be too small to allow for an ID mapping to be created
* that covers system RAM if that is located sufficiently high in the
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 7d9571f4ae3d..5fe6d2e40e9b 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -160,7 +160,7 @@ void show_pte(unsigned long addr)
pr_alert("%s pgtable: %luk pages, %u-bit VAs, pgdp = %p\n",
mm == &init_mm ? "swapper" : "user", PAGE_SIZE / SZ_1K,
- VA_BITS, mm->pgd);
+ mm == &init_mm ? VA_BITS : (int) vabits_user, mm->pgd);
pgdp = pgd_offset(mm, addr);
pgd = READ_ONCE(*pgdp);
pr_alert("[%016lx] pgd=%016llx", addr, pgd_val(pgd));
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 394b8d554def..f8fc393143ea 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -52,6 +52,7 @@
u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
+u64 vabits_user __ro_after_init;
u64 kimage_voffset __ro_after_init;
EXPORT_SYMBOL(kimage_voffset);
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 2db1c491d45d..0cf86b17714c 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -450,7 +450,15 @@ ENTRY(__cpu_setup)
ldr x10, =TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \
TCR_TG_FLAGS | TCR_KASLR_FLAGS | TCR_ASID16 | \
TCR_TBI0 | TCR_A1
- tcr_set_idmap_t0sz x10, x9
+
+#ifdef CONFIG_ARM64_52BIT_VA
+ ldr_l x9, vabits_user
+ sub x9, xzr, x9
+ add x9, x9, #64
+#else
+ ldr_l x9, idmap_t0sz
+#endif
+ tcr_set_t0sz x10, x9
/*
* Set the IPS bits in TCR_EL1.
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
For cases where there is a mismatch in ARMv8.2-LVA support between CPUs
we have to be careful in allowing secondary CPUs to boot if 52-bit
virtual addresses have already been enabled on the boot CPU.
This patch adds code to the secondary startup path. If the boot CPU has
enabled 52-bit VAs then ID_AA64MMFR2_EL1 is checked to see if the
secondary can also enable 52-bit support. If not, the secondary is
prevented from booting and an error message is displayed indicating why.
Technically this patch could be implemented using the cpufeature code
when considering 52-bit userspace support. However, we employ low level
checks here as the cpufeature code won't be able to run if we have
mismatched 52-bit kernel va support.
Signed-off-by: Steve Capper <steve.capper@arm.com>
---
Patch is new in V5 of the series
---
arch/arm64/kernel/head.S | 26 ++++++++++++++++++++++++++
arch/arm64/kernel/smp.c | 5 +++++
2 files changed, 31 insertions(+)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index f60081be9a1b..58fcc1edd852 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -707,6 +707,7 @@ secondary_startup:
/*
* Common entry point for secondary CPUs.
*/
+ bl __cpu_secondary_check52bitva
bl __cpu_setup // initialise processor
adrp x1, swapper_pg_dir
bl __enable_mmu
@@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
ret
ENDPROC(__enable_mmu)
+ENTRY(__cpu_secondary_check52bitva)
+#ifdef CONFIG_ARM64_52BIT_VA
+ ldr_l x0, vabits_user
+ cmp x0, #52
+ b.ne 2f
+
+ mrs_s x0, SYS_ID_AA64MMFR2_EL1
+ and x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
+ cbnz x0, 2f
+
+ adr_l x0, va52mismatch
+ mov w1, #1
+ strb w1, [x0]
+ dmb sy
+ dc ivac, x0 // Invalidate potentially stale cache line
+
+ update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x0, x1
+1: wfe
+ wfi
+ b 1b
+
+#endif
+2: ret
+ENDPROC(__cpu_secondary_check52bitva)
+
__no_granule_support:
/* Indicate that this CPU can't boot and is stuck in the kernel */
update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x1, x2
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 96b8f2f51ab2..e15b0b64d4d0 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -108,6 +108,7 @@ static int boot_secondary(unsigned int cpu, struct task_struct *idle)
}
static DECLARE_COMPLETION(cpu_running);
+bool va52mismatch __ro_after_init;
int __cpu_up(unsigned int cpu, struct task_struct *idle)
{
@@ -137,6 +138,10 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
if (!cpu_online(cpu)) {
pr_crit("CPU%u: failed to come online\n", cpu);
+
+ if (IS_ENABLED(CONFIG_ARM64_52BIT_VA) && va52mismatch)
+ pr_crit("CPU%u: does not support 52-bit VAs\n", cpu);
+
ret = -EIO;
}
} else {
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 4/7] arm64: mm: Offset TTBR1 to allow 52-bit PTRS_PER_PGD
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
Enabling 52-bit VAs on arm64 requires that the PGD table expands from 64
entries (for the 48-bit case) to 1024 entries. This quantity,
PTRS_PER_PGD is used as follows to compute which PGD entry corresponds
to a given virtual address, addr:
pgd_index(addr) -> (addr >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1)
Userspace addresses are prefixed by 0's, so for a 48-bit userspace
address, uva, the following is true:
(uva >> PGDIR_SHIFT) & (1024 - 1) == (uva >> PGDIR_SHIFT) & (64 - 1)
In other words, a 48-bit userspace address will have the same pgd_index
when using PTRS_PER_PGD = 64 and 1024.
Kernel addresses are prefixed by 1's so, given a 48-bit kernel address,
kva, we have the following inequality:
(kva >> PGDIR_SHIFT) & (1024 - 1) != (kva >> PGDIR_SHIFT) & (64 - 1)
In other words a 48-bit kernel virtual address will have a different
pgd_index when using PTRS_PER_PGD = 64 and 1024.
If, however, we note that:
kva = 0xFFFF << 48 + lower (where lower[63:48] == 0b)
and, PGDIR_SHIFT = 42 (as we are dealing with 64KB PAGE_SIZE)
We can consider:
(kva >> PGDIR_SHIFT) & (1024 - 1) - (kva >> PGDIR_SHIFT) & (64 - 1)
= (0xFFFF << 6) & 0x3FF - (0xFFFF << 6) & 0x3F // "lower" cancels out
= 0x3C0
In other words, one can switch PTRS_PER_PGD to the 52-bit value globally
provided that they increment ttbr1_el1 by 0x3C0 * 8 = 0x1E00 bytes when
running with 48-bit kernel VAs (TCR_EL1.T1SZ = 16).
For kernel configuration where 52-bit userspace VAs are possible, this
patch offsets ttbr1_el1 and sets PTRS_PER_PGD corresponding to the
52-bit value.
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Steve Capper <steve.capper@arm.com>
---
Changed in V5, removed ttbr1 save/restore logic for software PAN as
hardware PAN is a mandatory ARMv8.1 feature anyway. The logic to enable
52-bit VAs has also been changed to depend on
ARM64_PAN || !ARM64_SW_TTBR0_PAN
(in a later patch)
This patch is new in V4 of the series
---
arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
arch/arm64/include/asm/pgtable-hwdef.h | 9 +++++++++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/hibernate-asm.S | 1 +
arch/arm64/mm/proc.S | 4 ++++
5 files changed, 38 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 6142402c2eb4..e2fe378d2a63 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -515,6 +515,29 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU
mrs \rd, sp_el0
.endm
+/*
+ * Offset ttbr1 to allow for 48-bit kernel VAs set with 52-bit PTRS_PER_PGD.
+ * orr is used as it can cover the immediate value (and is idempotent).
+ * In future this may be nop'ed out when dealing with 52-bit kernel VAs.
+ * ttbr: Value of ttbr to set, modified.
+ */
+ .macro offset_ttbr1, ttbr
+#ifdef CONFIG_ARM64_52BIT_VA
+ orr \ttbr, \ttbr, #TTBR1_BADDR_4852_OFFSET
+#endif
+ .endm
+
+/*
+ * Perform the reverse of offset_ttbr1.
+ * bic is used as it can cover the immediate value and, in future, won't need
+ * to be nop'ed out when dealing with 52-bit kernel VAs.
+ */
+ .macro restore_ttbr1, ttbr
+#ifdef CONFIG_ARM64_52BIT_VA
+ bic \ttbr, \ttbr, #TTBR1_BADDR_4852_OFFSET
+#endif
+ .endm
+
/*
* Arrange a physical address in a TTBR register, taking care of 52-bit
* addresses.
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index 1d7d8da2ef9b..4a29c7e03ae4 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -80,7 +80,11 @@
#define PGDIR_SHIFT ARM64_HW_PGTABLE_LEVEL_SHIFT(4 - CONFIG_PGTABLE_LEVELS)
#define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT)
#define PGDIR_MASK (~(PGDIR_SIZE-1))
+#ifdef CONFIG_ARM64_52BIT_VA
+#define PTRS_PER_PGD (1 << (52 - PGDIR_SHIFT))
+#else
#define PTRS_PER_PGD (1 << (VA_BITS - PGDIR_SHIFT))
+#endif
/*
* Section address mask and size definitions.
@@ -306,4 +310,9 @@
#define TTBR_BADDR_MASK_52 (((UL(1) << 46) - 1) << 2)
#endif
+#ifdef CONFIG_ARM64_52BIT_VA
+#define TTBR1_BADDR_4852_OFFSET (((UL(1) << (52 - PGDIR_SHIFT)) - \
+ (UL(1) << (48 - PGDIR_SHIFT))) * 8)
+#endif
+
#endif
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 4471f570a295..f60081be9a1b 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -769,6 +769,7 @@ ENTRY(__enable_mmu)
phys_to_ttbr x1, x1
phys_to_ttbr x2, x2
msr ttbr0_el1, x2 // load TTBR0
+ offset_ttbr1 x1
msr ttbr1_el1, x1 // load TTBR1
isb
msr sctlr_el1, x0
diff --git a/arch/arm64/kernel/hibernate-asm.S b/arch/arm64/kernel/hibernate-asm.S
index dd14ab8c9f72..fe36d85c60bd 100644
--- a/arch/arm64/kernel/hibernate-asm.S
+++ b/arch/arm64/kernel/hibernate-asm.S
@@ -40,6 +40,7 @@
tlbi vmalle1
dsb nsh
phys_to_ttbr \tmp, \page_table
+ offset_ttbr1 \tmp
msr ttbr1_el1, \tmp
isb
.endm
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 2c75b0b903ae..2db1c491d45d 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -182,6 +182,7 @@ ENDPROC(cpu_do_switch_mm)
.macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
adrp \tmp1, empty_zero_page
phys_to_ttbr \tmp2, \tmp1
+ offset_ttbr1 \tmp2
msr ttbr1_el1, \tmp2
isb
tlbi vmalle1
@@ -200,6 +201,7 @@ ENTRY(idmap_cpu_replace_ttbr1)
__idmap_cpu_set_reserved_ttbr1 x1, x3
+ offset_ttbr1 x0
msr ttbr1_el1, x0
isb
@@ -254,6 +256,7 @@ ENTRY(idmap_kpti_install_ng_mappings)
pte .req x16
mrs swapper_ttb, ttbr1_el1
+ restore_ttbr1 swapper_ttb
adr flag_ptr, __idmap_kpti_flag
cbnz cpu, __idmap_kpti_secondary
@@ -373,6 +376,7 @@ __idmap_kpti_secondary:
cbnz w18, 1b
/* All done, act like nothing happened */
+ offset_ttbr1 swapper_ttb
msr ttbr1_el1, swapper_ttb
isb
ret
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 7/7] arm64: mm: Allow forcing all userspace addresses to 52-bit
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
On arm64 52-bit VAs are provided to userspace when a hint is supplied to
mmap. This helps maintain compatibility with software that expects at
most 48-bit VAs to be returned.
In order to help identify software that has 48-bit VA assumptions, this
patch allows one to compile a kernel where 52-bit VAs are returned by
default on HW that supports it.
This feature is intended to be for development systems only.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/Kconfig | 13 +++++++++++++
arch/arm64/include/asm/elf.h | 4 ++++
arch/arm64/include/asm/processor.h | 9 ++++++++-
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6a93d5bc7f76..12658f05bb41 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1165,6 +1165,19 @@ config ARM64_CNP
at runtime, and does not affect PEs that do not implement
this feature.
+config ARM64_FORCE_52BIT
+ bool "Force 52-bit virtual addresses for userspace"
+ depends on ARM64_52BIT_VA && EXPERT
+ help
+ For systems with 52-bit userspace VAs enabled, the kernel will attempt
+ to maintain compatibility with older software by providing 48-bit VAs
+ unless a hint is supplied to mmap.
+
+ This configuration option disables the 48-bit compatibility logic, and
+ forces all userspace addresses to be 52-bit on HW that supports it. One
+ should only enable this configuration option for stress testing userspace
+ memory management code. If unsure say N here.
+
endmenu
config ARM64_SVE
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index bc9bd9e77d9d..6adc1a90e7e6 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -117,7 +117,11 @@
* 64-bit, this is above 4GB to leave the entire 32-bit address
* space open for things that want to use the area for 32-bit pointers.
*/
+#ifdef CONFIG_ARM64_FORCE_52BIT
+#define ELF_ET_DYN_BASE (2 * TASK_SIZE_64 / 3)
+#else
#define ELF_ET_DYN_BASE (2 * DEFAULT_MAP_WINDOW_64 / 3)
+#endif /* CONFIG_ARM64_FORCE_52BIT */
#ifndef __ASSEMBLY__
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index b363fc705be4..9abd91570b5b 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -65,8 +65,13 @@ extern u64 vabits_user;
#define DEFAULT_MAP_WINDOW DEFAULT_MAP_WINDOW_64
#endif /* CONFIG_COMPAT */
-#define TASK_UNMAPPED_BASE (PAGE_ALIGN(DEFAULT_MAP_WINDOW / 4))
+#ifdef CONFIG_ARM64_FORCE_52BIT
+#define STACK_TOP_MAX TASK_SIZE_64
+#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
+#else
#define STACK_TOP_MAX DEFAULT_MAP_WINDOW_64
+#define TASK_UNMAPPED_BASE (PAGE_ALIGN(DEFAULT_MAP_WINDOW / 4))
+#endif /* CONFIG_ARM64_FORCE_52BIT */
#ifdef CONFIG_COMPAT
#define AARCH32_VECTORS_BASE 0xffff0000
@@ -76,12 +81,14 @@ extern u64 vabits_user;
#define STACK_TOP STACK_TOP_MAX
#endif /* CONFIG_COMPAT */
+#ifndef CONFIG_ARM64_FORCE_52BIT
#define arch_get_mmap_end(addr) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
DEFAULT_MAP_WINDOW)
#define arch_get_mmap_base(addr, base) ((addr > DEFAULT_MAP_WINDOW) ? \
base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
base)
+#endif /* CONFIG_ARM64_FORCE_52BIT */
extern phys_addr_t arm64_dma_phys_limit;
#define ARCH_LOW_ADDRESS_LIMIT (arm64_dma_phys_limit - 1)
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 2/7] arm64: mm: Introduce DEFAULT_MAP_WINDOW
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
We wish to introduce a 52-bit virtual address space for userspace but
maintain compatibility with software that assumes the maximum VA space
size is 48 bit.
In order to achieve this, on 52-bit VA systems, we make mmap behave as
if it were running on a 48-bit VA system (unless userspace explicitly
requests a VA where addr[51:48] != 0).
On a system running a 52-bit userspace we need TASK_SIZE to represent
the 52-bit limit as it is used in various places to distinguish between
kernelspace and userspace addresses.
Thus we need a new limit for mmap, stack, ELF loader and EFI (which uses
TTBR0) to represent the non-extended VA space.
This patch introduces DEFAULT_MAP_WINDOW and DEFAULT_MAP_WINDOW_64 and
switches the appropriate logic to use that instead of TASK_SIZE.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
Changed in V3: corrections to allow COMPAT 32-bit EL0 mode to work
---
arch/arm64/include/asm/elf.h | 2 +-
arch/arm64/include/asm/processor.h | 10 ++++++++--
arch/arm64/mm/init.c | 2 +-
drivers/firmware/efi/arm-runtime.c | 2 +-
drivers/firmware/efi/libstub/arm-stub.c | 2 +-
5 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 433b9554c6a1..bc9bd9e77d9d 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -117,7 +117,7 @@
* 64-bit, this is above 4GB to leave the entire 32-bit address
* space open for things that want to use the area for 32-bit pointers.
*/
-#define ELF_ET_DYN_BASE (2 * TASK_SIZE_64 / 3)
+#define ELF_ET_DYN_BASE (2 * DEFAULT_MAP_WINDOW_64 / 3)
#ifndef __ASSEMBLY__
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 3e2091708b8e..50586ca6bacb 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -45,19 +45,25 @@
* TASK_SIZE - the maximum size of a user space task.
* TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
*/
+
+#define DEFAULT_MAP_WINDOW_64 (UL(1) << VA_BITS)
+
#ifdef CONFIG_COMPAT
#define TASK_SIZE_32 UL(0x100000000)
#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)
#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)
+#define DEFAULT_MAP_WINDOW (test_thread_flag(TIF_32BIT) ? \
+ TASK_SIZE_32 : DEFAULT_MAP_WINDOW_64)
#else
#define TASK_SIZE TASK_SIZE_64
+#define DEFAULT_MAP_WINDOW DEFAULT_MAP_WINDOW_64
#endif /* CONFIG_COMPAT */
-#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
+#define TASK_UNMAPPED_BASE (PAGE_ALIGN(DEFAULT_MAP_WINDOW / 4))
+#define STACK_TOP_MAX DEFAULT_MAP_WINDOW_64
-#define STACK_TOP_MAX TASK_SIZE_64
#ifdef CONFIG_COMPAT
#define AARCH32_VECTORS_BASE 0xffff0000
#define STACK_TOP (test_thread_flag(TIF_32BIT) ? \
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9d9582cac6c4..7239c103be06 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -609,7 +609,7 @@ void __init mem_init(void)
* detected at build time already.
*/
#ifdef CONFIG_COMPAT
- BUILD_BUG_ON(TASK_SIZE_32 > TASK_SIZE_64);
+ BUILD_BUG_ON(TASK_SIZE_32 > DEFAULT_MAP_WINDOW_64);
#endif
#ifdef CONFIG_SPARSEMEM_VMEMMAP
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 922cfb813109..952cec5b611a 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -38,7 +38,7 @@ static struct ptdump_info efi_ptdump_info = {
.mm = &efi_mm,
.markers = (struct addr_marker[]){
{ 0, "UEFI runtime start" },
- { TASK_SIZE_64, "UEFI runtime end" }
+ { DEFAULT_MAP_WINDOW_64, "UEFI runtime end" }
},
.base_addr = 0,
};
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 30ac0c975f8a..d1ec7136e3e1 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -33,7 +33,7 @@
#define EFI_RT_VIRTUAL_SIZE SZ_512M
#ifdef CONFIG_ARM64
-# define EFI_RT_VIRTUAL_LIMIT TASK_SIZE_64
+# define EFI_RT_VIRTUAL_LIMIT DEFAULT_MAP_WINDOW_64
#else
# define EFI_RT_VIRTUAL_LIMIT TASK_SIZE
#endif
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 3/7] arm64: mm: Define arch_get_mmap_end, arch_get_mmap_base
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
Now that we have DEFAULT_MAP_WINDOW defined, we can arch_get_mmap_end
and arch_get_mmap_base helpers to allow for high addresses in mmap.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/processor.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 50586ca6bacb..fe95fd8b065e 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -72,6 +72,13 @@
#define STACK_TOP STACK_TOP_MAX
#endif /* CONFIG_COMPAT */
+#define arch_get_mmap_end(addr) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
+ DEFAULT_MAP_WINDOW)
+
+#define arch_get_mmap_base(addr, base) ((addr > DEFAULT_MAP_WINDOW) ? \
+ base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
+ base)
+
extern phys_addr_t arm64_dma_phys_limit;
#define ARCH_LOW_ADDRESS_LIMIT (arm64_dma_phys_limit - 1)
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 1/7] mm: mmap: Allow for "high" userspace addresses
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm, Andrew Morton
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
This patch adds support for "high" userspace addresses that are
optionally supported on the system and have to be requested via a hint
mechanism ("high" addr parameter to mmap).
Architectures such as powerpc and x86 achieve this by making changes to
their architectural versions of arch_get_unmapped_* functions. However,
on arm64 we use the generic versions of these functions.
Rather than duplicate the generic arch_get_unmapped_* implementations
for arm64, this patch instead introduces two architectural helper macros
and applies them to arch_get_unmapped_*:
arch_get_mmap_end(addr) - get mmap upper limit depending on addr hint
arch_get_mmap_base(addr, base) - get mmap_base depending on addr hint
If these macros are not defined in architectural code then they default
to (TASK_SIZE) and (base) so should not introduce any behavioural
changes to architectures that do not define them.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
Changed in V4, added Catalin's reviewed by
Changed in V3, commit log cleared up, explanation given for why core
code change over just architectural change
---
mm/mmap.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 6c04292e16a7..7bb64381e77c 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2066,6 +2066,15 @@ unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info)
return gap_end;
}
+
+#ifndef arch_get_mmap_end
+#define arch_get_mmap_end(addr) (TASK_SIZE)
+#endif
+
+#ifndef arch_get_mmap_base
+#define arch_get_mmap_base(addr, base) (base)
+#endif
+
/* Get an address range which is currently unmapped.
* For shmat() with addr=0.
*
@@ -2085,8 +2094,9 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma, *prev;
struct vm_unmapped_area_info info;
+ const unsigned long mmap_end = arch_get_mmap_end(addr);
- if (len > TASK_SIZE - mmap_min_addr)
+ if (len > mmap_end - mmap_min_addr)
return -ENOMEM;
if (flags & MAP_FIXED)
@@ -2095,7 +2105,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
if (addr) {
addr = PAGE_ALIGN(addr);
vma = find_vma_prev(mm, addr, &prev);
- if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
+ if (mmap_end - len >= addr && addr >= mmap_min_addr &&
(!vma || addr + len <= vm_start_gap(vma)) &&
(!prev || addr >= vm_end_gap(prev)))
return addr;
@@ -2104,7 +2114,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.flags = 0;
info.length = len;
info.low_limit = mm->mmap_base;
- info.high_limit = TASK_SIZE;
+ info.high_limit = mmap_end;
info.align_mask = 0;
return vm_unmapped_area(&info);
}
@@ -2124,9 +2134,10 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
struct mm_struct *mm = current->mm;
unsigned long addr = addr0;
struct vm_unmapped_area_info info;
+ const unsigned long mmap_end = arch_get_mmap_end(addr);
/* requested length too big for entire address space */
- if (len > TASK_SIZE - mmap_min_addr)
+ if (len > mmap_end - mmap_min_addr)
return -ENOMEM;
if (flags & MAP_FIXED)
@@ -2136,7 +2147,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
if (addr) {
addr = PAGE_ALIGN(addr);
vma = find_vma_prev(mm, addr, &prev);
- if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
+ if (mmap_end - len >= addr && addr >= mmap_min_addr &&
(!vma || addr + len <= vm_start_gap(vma)) &&
(!prev || addr >= vm_end_gap(prev)))
return addr;
@@ -2145,7 +2156,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
- info.high_limit = mm->mmap_base;
+ info.high_limit = arch_get_mmap_base(addr, mm->mmap_base);
info.align_mask = 0;
addr = vm_unmapped_area(&info);
@@ -2159,7 +2170,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
VM_BUG_ON(addr != -ENOMEM);
info.flags = 0;
info.low_limit = TASK_UNMAPPED_BASE;
- info.high_limit = TASK_SIZE;
+ info.high_limit = mmap_end;
addr = vm_unmapped_area(&info);
}
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 0/7] 52-bit userspace VAs
From: Steve Capper @ 2018-12-06 22:50 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel
Cc: ard.biesheuvel, suzuki.poulose, catalin.marinas, Steve Capper,
will.deacon, jcm
This patch series brings support for 52-bit userspace VAs to systems that
have ARMv8.2-LVA and are running with a 48-bit VA_BITS and a 64KB
PAGE_SIZE.
If no hardware support is present, the kernel runs with a 48-bit VA space
for userspace.
Userspace can exploit this feature by providing an address hint to mmap
where addr[51:48] != 0. Otherwise all the VA mappings will behave in the
same way as a 48-bit VA system (this is to maintain compatibility with
software that assumes the maximum VA size on arm64 is 48-bit).
This patch series applies to 4.20-rc1.
Testing was in a model with Trusted Firmware and UEFI for boot.
Changed in V5, ttbr1 offsetting code simplified. Extra patch added to
check for VA space support mismatch between CPUs.
Changed in V4, pgd_index changes dropped in favour of offsetting the
ttbr1. This is performed in a new patch, #4.
Changed in V3, COMPAT fixes added (and tested with 32-bit userspace code).
Extra patch added to allow forcing all userspace allocations to come from
52-bits (to allow for debugging and testing).
The major change to V2 of the series is that mm/mmap.c is altered in the
first patch of the series (rather than copied over to arch/arm64).
Steve Capper (7):
mm: mmap: Allow for "high" userspace addresses
arm64: mm: Introduce DEFAULT_MAP_WINDOW
arm64: mm: Define arch_get_mmap_end, arch_get_mmap_base
arm64: mm: Offset TTBR1 to allow 52-bit PTRS_PER_PGD
arm64: mm: Prevent mismatched 52-bit VA support
arm64: mm: introduce 52-bit userspace support
arm64: mm: Allow forcing all userspace addresses to 52-bit
arch/arm64/Kconfig | 17 +++++++++++
arch/arm64/include/asm/assembler.h | 30 ++++++++++++++++---
arch/arm64/include/asm/elf.h | 4 +++
arch/arm64/include/asm/mmu_context.h | 3 ++
arch/arm64/include/asm/pgtable-hwdef.h | 9 ++++++
arch/arm64/include/asm/processor.h | 36 ++++++++++++++++++----
arch/arm64/kernel/head.S | 40 +++++++++++++++++++++++++
arch/arm64/kernel/hibernate-asm.S | 1 +
arch/arm64/kernel/smp.c | 5 ++++
arch/arm64/mm/fault.c | 2 +-
arch/arm64/mm/init.c | 2 +-
arch/arm64/mm/mmu.c | 1 +
arch/arm64/mm/proc.S | 14 ++++++++-
drivers/firmware/efi/arm-runtime.c | 2 +-
drivers/firmware/efi/libstub/arm-stub.c | 2 +-
mm/mmap.c | 25 +++++++++++-----
16 files changed, 171 insertions(+), 22 deletions(-)
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] media: rockchip vpu: remove some unused vars
From: Ezequiel Garcia @ 2018-12-06 22:39 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: devel, Heiko Stuebner, Greg Kroah-Hartman, Mauro Carvalho Chehab,
linux-rockchip, Hans Verkuil, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <10b532d7f12ef0718028a3ecb4f00974ebd80c4c.1544054436.git.mchehab+samsung@kernel.org>
On Wed, 2018-12-05 at 19:01 -0500, Mauro Carvalho Chehab wrote:
> As complained by gcc:
>
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In function 'rk3288_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10: warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~~~~~~~~~~~~~
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10: warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^~~~~~~~~~~~~
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In function 'rk3399_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10: warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~~~~~~~~~~~~~
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10: warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^~~~~~~~~~~~~
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 'rockchip_vpu_queue_setup':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning: variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
> ^~~~~~~
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 'rockchip_vpu_buf_prepare':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning: variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
> ^~~~~~~
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Ezequiel Garcia <ezequiel@collabora.com>
Thanks!
> ---
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -----
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -----
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 6 ------
> 3 files changed, 16 deletions(-)
>
> diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> index e27c10855de5..5282236d1bb1 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> @@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(&luma_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> index 5f75e4d11d76..dbc86d95fe3b 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> @@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(&luma_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> index 038a7136d5d1..ab0fb2053620 100644
> --- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> @@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
> struct device *alloc_devs[])
> {
> struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
> - const struct rockchip_vpu_fmt *vpu_fmt;
> struct v4l2_pix_format_mplane *pixfmt;
> int i;
>
> switch (vq->type) {
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - vpu_fmt = ctx->vpu_dst_fmt;
> pixfmt = &ctx->dst_fmt;
> break;
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - vpu_fmt = ctx->vpu_src_fmt;
> pixfmt = &ctx->src_fmt;
> break;
> default:
> @@ -557,7 +554,6 @@ static int rockchip_vpu_buf_prepare(struct vb2_buffer *vb)
> struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
> struct vb2_queue *vq = vb->vb2_queue;
> struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
> - const struct rockchip_vpu_fmt *vpu_fmt;
> struct v4l2_pix_format_mplane *pixfmt;
> unsigned int sz;
> int ret = 0;
> @@ -565,11 +561,9 @@ static int rockchip_vpu_buf_prepare(struct vb2_buffer *vb)
>
> switch (vq->type) {
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - vpu_fmt = ctx->vpu_dst_fmt;
> pixfmt = &ctx->dst_fmt;
> break;
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - vpu_fmt = ctx->vpu_src_fmt;
> pixfmt = &ctx->src_fmt;
>
> if (vbuf->field == V4L2_FIELD_ANY)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 30/34] dt-bindings: arm: Convert Tegra board/soc bindings to json-schema
From: Rob Herring @ 2018-12-06 22:38 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Kumar Gala, ARM-SoC Maintainers,
Sean Hudson, Frank Rowand, linux-kernel@vger.kernel.org,
Jon Hunter, Grant Likely, linux-tegra, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20181204085022.GB25962@ulmo>
On Tue, Dec 4, 2018 at 2:50 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Mon, Dec 03, 2018 at 03:32:19PM -0600, Rob Herring wrote:
> > Convert Tegra SoC bindings to DT schema format using json-schema.
> >
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: Jonathan Hunter <jonathanh@nvidia.com>
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-tegra@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > .../devicetree/bindings/arm/tegra.txt | 65 -----------
> > .../devicetree/bindings/arm/tegra.yaml | 101 ++++++++++++++++++
> > 2 files changed, 101 insertions(+), 65 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt
> > deleted file mode 100644
> > index c59b15f64346..000000000000
> > --- a/Documentation/devicetree/bindings/arm/tegra.txt
> > +++ /dev/null
> > @@ -1,65 +0,0 @@
> > -NVIDIA Tegra device tree bindings
> > --------------------------------------------
> > -
> > -SoCs
> > --------------------------------------------
> > -
> > -Each device tree must specify which Tegra SoC it uses, using one of the
> > -following compatible values:
> > -
> > - nvidia,tegra20
> > - nvidia,tegra30
> > - nvidia,tegra114
> > - nvidia,tegra124
> > - nvidia,tegra132
> > - nvidia,tegra210
> > - nvidia,tegra186
> > - nvidia,tegra194
> > -
> > -Boards
> > --------------------------------------------
> > -
> > -Each device tree must specify which one or more of the following
> > -board-specific compatible values:
> > -
> > - ad,medcom-wide
> > - ad,plutux
> > - ad,tamonten
> > - ad,tec
> > - compal,paz00
> > - compulab,trimslice
> > - nvidia,beaver
> > - nvidia,cardhu
> > - nvidia,cardhu-a02
> > - nvidia,cardhu-a04
> > - nvidia,dalmore
> > - nvidia,harmony
> > - nvidia,jetson-tk1
> > - nvidia,norrin
> > - nvidia,p2371-0000
> > - nvidia,p2371-2180
> > - nvidia,p2571
> > - nvidia,p2771-0000
> > - nvidia,p2972-0000
> > - nvidia,roth
> > - nvidia,seaboard
> > - nvidia,tn7
> > - nvidia,ventana
> > - toradex,apalis_t30
> > - toradex,apalis_t30-eval
> > - toradex,apalis_t30-v1.1
> > - toradex,apalis_t30-v1.1-eval
> > - toradex,apalis-tk1
> > - toradex,apalis-tk1-eval
> > - toradex,apalis-tk1-v1.2
> > - toradex,apalis-tk1-v1.2-eval
> > - toradex,colibri_t20
> > - toradex,colibri_t20-eval-v3
> > - toradex,colibri_t20-iris
> > - toradex,colibri_t30
> > - toradex,colibri_t30-eval-v3
> > -
> > -Trusted Foundations
> > --------------------------------------------
> > -Tegra supports the Trusted Foundation secure monitor. See the
> > -"tlm,trusted-foundations" binding's documentation for more details.
> > diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
> > new file mode 100644
> > index 000000000000..66493892ffc1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml
> > @@ -0,0 +1,101 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/tegra.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>
> Could you explain what these are? They give 404, so I assume they are
> more like placeholders and not actually used?
Please read the documentation in patch 2. They are used, but aren't live URLs.
> > +
> > +title: NVIDIA Tegra device tree bindings
> > +
> > +maintainers:
> > + - Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > + - Peter De Schrijver <pdeschrijver@nvidia.com>
>
> Not sure how you got that list, but probably from git history. I think
> it makes sense to replace Marcel and Peter with Jon and myself.
Will do.
> Other than that, looks fine to me. Some of the enumerations below look
> somewhat hard to parse, but I suspect that it will become second nature
> in no time.
We can add descriptions and/or comments if that helps. I didn't add
them if not already there.
> Acked-by: Thierry Reding <treding@nvidia.com>
Thanks.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: dmapool regression in next
From: Stephen Rothwell @ 2018-12-06 22:10 UTC (permalink / raw)
To: Tony Lindgren
Cc: john.garry, linux, Krzysztof Kozlowski, linux-kernel,
andy.shevchenko, hch, Matthew Wilcox, akpm, linux-omap,
Robin Murphy, Tony Battersby, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20181206163315.GL6707@atomide.com>
[-- Attachment #1.1: Type: text/plain, Size: 2363 bytes --]
Hi all,
On Thu, 6 Dec 2018 08:33:15 -0800 Tony Lindgren <tony@atomide.com> wrote:
>
> * Tony Battersby <tonyb@cybernetics.com> [181206 16:13]:
> > On 12/6/18 10:51 AM, Robin Murphy wrote:
> > >> Here is the prototype:
> > >>
> > >> void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma);
> > >>
> > >> With the old code, the 'dma' value had to be correct for use with
> > >> pool_find_page(), or else you would get an error. If the 'vaddr' value
> > >> was incorrect, it would corrupt the dmapool freelist, but you wouldn't
> > >> get an error unless DMAPOOL_DEBUG was enabled.
> > >>
> > >> With my patch applied, 'vaddr' has to be correct for virt_to_page(). My
> > >> code also checks that 'dma' is consistent with 'vaddr' even if
> > >> DMAPOOL_DEBUG is disabled, since the check is fast and it will prevent
> > >> problems like this in the future.
> > > Unfortunately that logic has a fatal flaw - DMA pools are backed by
> > > dma_alloc_coherent(), and there is absolutely no guarantee that the
> > > memory dma_alloc_coherent() returns is backed by a struct page at all.
> > > Even if it is, there is still absolutely no guarantee that the vaddr
> > > value it returns is valid for virt_to_page() - on many systems it will
> > > be in vmalloc or some architecture-specific region of address space.
> > >
> > > The problem is not that these drivers are buggy (they're not - the arch
> > > code is returning a vmalloc()ed non-cacheable remap in the first place),
> > > it's that 26abe88e830d is fundamentally unworkable and needs reverting.
> > > Apparently the original patches managed not to catch my eye as something
> > > I needed to review, sorry about that :(
> > >
> > > Robin.
> > >
> > Thanks for the info; the inner workings of the vm system are a bit out
> > of my area of expertise. My first version of the patch series used a
> > different method that didn't rely on virt_to_page(); I will go back to
> > that version, clean it up, and resubmit when I have time.
> >
> > Andrew, please revert all 9 patches. I will resubmit the set when I
> > have a workable solution.
>
> OK sounds good to me. I can test the new set easily when available
> if you Cc me on them.
I have removed those patches from linux-next for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 7/9] ARM: shmobile: Move SoC Kconfig symbols to drivers/soc/renesas/
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
For consistency with arm64, where vendors have a single Kconfig symbol
in arch/arm64/Kconfig.platforms.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 126 -----------------------------------
drivers/soc/renesas/Kconfig | 148 ++++++++++++++++++++++++++++++++++++++---
2 files changed, 139 insertions(+), 135 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 70c6f557f8cd..9b798c9dffe4 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -4,31 +4,6 @@ config PM_RMOBILE
select PM
select PM_GENERIC_DOMAINS
-config ARCH_RCAR_GEN1
- bool
- select PM
- select PM_GENERIC_DOMAINS
- select RENESAS_INTC_IRQPIN
- select SYS_SUPPORTS_SH_TMU
-
-config ARCH_RCAR_GEN2
- bool
- select HAVE_ARM_ARCH_TIMER
- select PM
- select PM_GENERIC_DOMAINS
- select RENESAS_IRQC
- select SYS_SUPPORTS_SH_CMT
-
-config ARCH_RMOBILE
- bool
- select PM_RMOBILE
- select SYS_SUPPORTS_SH_CMT
- select SYS_SUPPORTS_SH_TMU
-
-config ARCH_RZN1
- bool
- select ARM_AMBA
-
menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
@@ -38,104 +13,3 @@ menuconfig ARCH_RENESAS
select PINCTRL
select SOC_BUS
select ZONE_DMA if ARM_LPAE
-
-if ARCH_RENESAS
-
-#comment "Renesas ARM SoCs System Type"
-
-config ARCH_EMEV2
- bool "Emma Mobile EV2"
- select HAVE_ARM_SCU if SMP
- select SYS_SUPPORTS_EM_STI
-
-config ARCH_R7S72100
- bool "RZ/A1H (R7S72100)"
- select PM
- select PM_GENERIC_DOMAINS
- select SYS_SUPPORTS_SH_MTU2
- select RENESAS_OSTM
-
-config ARCH_R7S9210
- bool "RZ/A2 (R7S9210)"
- select PM
- select PM_GENERIC_DOMAINS
- select RENESAS_OSTM
-
-config ARCH_R8A73A4
- bool "R-Mobile APE6 (R8A73A40)"
- select ARCH_RMOBILE
- select ARM_ERRATA_798181 if SMP
- select HAVE_ARM_ARCH_TIMER
- select RENESAS_IRQC
-
-config ARCH_R8A7740
- bool "R-Mobile A1 (R8A77400)"
- select ARCH_RMOBILE
- select RENESAS_INTC_IRQPIN
-
-config ARCH_R8A7743
- bool "RZ/G1M (R8A77430)"
- select ARCH_RCAR_GEN2
- select ARM_ERRATA_798181 if SMP
-
-config ARCH_R8A7744
- bool "RZ/G1N (R8A77440)"
- select ARCH_RCAR_GEN2
- select ARM_ERRATA_798181 if SMP
-
-config ARCH_R8A7745
- bool "RZ/G1E (R8A77450)"
- select ARCH_RCAR_GEN2
-
-config ARCH_R8A77470
- bool "RZ/G1C (R8A77470)"
- select ARCH_RCAR_GEN2
-
-config ARCH_R8A7778
- bool "R-Car M1A (R8A77781)"
- select ARCH_RCAR_GEN1
-
-config ARCH_R8A7779
- bool "R-Car H1 (R8A77790)"
- select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if SMP
- select ARCH_RCAR_GEN1
-
-config ARCH_R8A7790
- bool "R-Car H2 (R8A77900)"
- select ARCH_RCAR_GEN2
- select ARM_ERRATA_798181 if SMP
- select I2C
-
-config ARCH_R8A7791
- bool "R-Car M2-W (R8A77910)"
- select ARCH_RCAR_GEN2
- select ARM_ERRATA_798181 if SMP
- select I2C
-
-config ARCH_R8A7792
- bool "R-Car V2H (R8A77920)"
- select ARCH_RCAR_GEN2
- select ARM_ERRATA_798181 if SMP
-
-config ARCH_R8A7793
- bool "R-Car M2-N (R8A7793)"
- select ARCH_RCAR_GEN2
- select ARM_ERRATA_798181 if SMP
- select I2C
-
-config ARCH_R8A7794
- bool "R-Car E2 (R8A77940)"
- select ARCH_RCAR_GEN2
-
-config ARCH_R9A06G032
- bool "RZ/N1D (R9A06G032)"
- select ARCH_RZN1
-
-config ARCH_SH73A0
- bool "SH-Mobile AG5 (R8A73A00)"
- select ARCH_RMOBILE
- select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if SMP
- select RENESAS_INTC_IRQPIN
-endif
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 2f5bc5a6ae2b..fe7f58616cdd 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -3,18 +3,26 @@ config SOC_RENESAS
bool "Renesas SoC driver support" if COMPILE_TEST && !ARCH_RENESAS
default y if ARCH_RENESAS
select SOC_BUS
- select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2
- select SYSC_R8A7743 if ARCH_R8A7743 || ARCH_R8A7744
- select SYSC_R8A7745 if ARCH_R8A7745
- select SYSC_R8A77470 if ARCH_R8A77470
- select SYSC_R8A7779 if ARCH_R8A7779
- select SYSC_R8A7790 if ARCH_R8A7790
- select SYSC_R8A7791 if ARCH_R8A7791 || ARCH_R8A7793
- select SYSC_R8A7792 if ARCH_R8A7792
- select SYSC_R8A7794 if ARCH_R8A7794
if SOC_RENESAS
+config ARCH_RCAR_GEN1
+ bool
+ select PM
+ select PM_GENERIC_DOMAINS
+ select RENESAS_INTC_IRQPIN
+ select RST_RCAR
+ select SYS_SUPPORTS_SH_TMU
+
+config ARCH_RCAR_GEN2
+ bool
+ select HAVE_ARM_ARCH_TIMER
+ select PM
+ select PM_GENERIC_DOMAINS
+ select RENESAS_IRQC
+ select RST_RCAR
+ select SYS_SUPPORTS_SH_CMT
+
config ARCH_RCAR_GEN3
bool
select PM
@@ -24,6 +32,128 @@ config ARCH_RCAR_GEN3
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
+config ARCH_RMOBILE
+ bool
+ select PM_RMOBILE
+ select SYS_SUPPORTS_SH_CMT
+ select SYS_SUPPORTS_SH_TMU
+
+config ARCH_RZN1
+ bool
+ select ARM_AMBA
+
+if ARM
+
+#comment "Renesas ARM SoCs System Type"
+
+config ARCH_EMEV2
+ bool "Emma Mobile EV2"
+ select HAVE_ARM_SCU if SMP
+ select SYS_SUPPORTS_EM_STI
+
+config ARCH_R7S72100
+ bool "RZ/A1H (R7S72100)"
+ select PM
+ select PM_GENERIC_DOMAINS
+ select SYS_SUPPORTS_SH_MTU2
+ select RENESAS_OSTM
+
+config ARCH_R7S9210
+ bool "RZ/A2 (R7S9210)"
+ select PM
+ select PM_GENERIC_DOMAINS
+ select RENESAS_OSTM
+
+config ARCH_R8A73A4
+ bool "R-Mobile APE6 (R8A73A40)"
+ select ARCH_RMOBILE
+ select ARM_ERRATA_798181 if SMP
+ select HAVE_ARM_ARCH_TIMER
+ select RENESAS_IRQC
+
+config ARCH_R8A7740
+ bool "R-Mobile A1 (R8A77400)"
+ select ARCH_RMOBILE
+ select RENESAS_INTC_IRQPIN
+
+config ARCH_R8A7743
+ bool "RZ/G1M (R8A77430)"
+ select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
+ select SYSC_R8A7743
+
+config ARCH_R8A7744
+ bool "RZ/G1N (R8A77440)"
+ select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
+ select SYSC_R8A7743
+
+config ARCH_R8A7745
+ bool "RZ/G1E (R8A77450)"
+ select ARCH_RCAR_GEN2
+ select SYSC_R8A7745
+
+config ARCH_R8A77470
+ bool "RZ/G1C (R8A77470)"
+ select ARCH_RCAR_GEN2
+ select SYSC_R8A77470
+
+config ARCH_R8A7778
+ bool "R-Car M1A (R8A77781)"
+ select ARCH_RCAR_GEN1
+
+config ARCH_R8A7779
+ bool "R-Car H1 (R8A77790)"
+ select ARCH_RCAR_GEN1
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if SMP
+ select SYSC_R8A7779
+
+config ARCH_R8A7790
+ bool "R-Car H2 (R8A77900)"
+ select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
+ select I2C
+ select SYSC_R8A7790
+
+config ARCH_R8A7791
+ bool "R-Car M2-W (R8A77910)"
+ select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
+ select I2C
+ select SYSC_R8A7791
+
+config ARCH_R8A7792
+ bool "R-Car V2H (R8A77920)"
+ select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
+ select SYSC_R8A7792
+
+config ARCH_R8A7793
+ bool "R-Car M2-N (R8A7793)"
+ select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
+ select I2C
+ select SYSC_R8A7791
+
+config ARCH_R8A7794
+ bool "R-Car E2 (R8A77940)"
+ select ARCH_RCAR_GEN2
+ select SYSC_R8A7794
+
+config ARCH_R9A06G032
+ bool "RZ/N1D (R9A06G032)"
+ select ARCH_RZN1
+
+config ARCH_SH73A0
+ bool "SH-Mobile AG5 (R8A73A00)"
+ select ARCH_RMOBILE
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if SMP
+ select RENESAS_INTC_IRQPIN
+
+endif # ARM
+
if ARM64
config ARCH_R8A774A1
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 9/9] ARM: shmobile: R-Mobile: Move pm-rmobile to drivers/soc/renesas/
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
The pm-rmobile driver is really a driver for the System Controller
(SYSC) found in R-Mobile SoCs. An equivalent driver for R-Car SoCs is
already located under drivers/soc/renesas/.
Hence move the pm-rmobile driver from arch/arm/mach-shmobile/ to
drivers/soc/renesas/, and rename it to rmobile-sysc.
Enable compile-testing on non-ARM and non-R-Mobile SoCs.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 5 -----
arch/arm/mach-shmobile/Makefile | 1 -
drivers/soc/renesas/Kconfig | 7 ++++++-
drivers/soc/renesas/Makefile | 1 +
.../pm-rmobile.c => drivers/soc/renesas/rmobile-sysc.c | 0
5 files changed, 7 insertions(+), 7 deletions(-)
rename arch/arm/mach-shmobile/pm-rmobile.c => drivers/soc/renesas/rmobile-sysc.c (100%)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 9b798c9dffe4..3683d6f10973 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -1,9 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-config PM_RMOBILE
- bool
- select PM
- select PM_GENERIC_DOMAINS
-
menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 5591646cb9bb..f7bf17b7abae 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -35,7 +35,6 @@ smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
# PM objects
obj-$(CONFIG_SUSPEND) += suspend.o
-obj-$(CONFIG_PM_RMOBILE) += pm-rmobile.o
obj-$(CONFIG_ARCH_RCAR_GEN2) += pm-rcar-gen2.o
# Framework support
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index fe7f58616cdd..4d8012e1205c 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -34,9 +34,11 @@ config ARCH_RCAR_GEN3
config ARCH_RMOBILE
bool
- select PM_RMOBILE
+ select PM
+ select PM_GENERIC_DOMAINS
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
+ select SYSC_RMOBILE
config ARCH_RZN1
bool
@@ -297,4 +299,7 @@ config RST_RCAR
config SYSC_RCAR
bool "R-Car System Controller support" if COMPILE_TEST
+config SYSC_RMOBILE
+ bool "R-Mobile System Controller support" if COMPILE_TEST
+
endif # SOC_RENESAS
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 3bdd7dbc38a9..00764d5a60b3 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -27,3 +27,4 @@ endif
# Family
obj-$(CONFIG_RST_RCAR) += rcar-rst.o
obj-$(CONFIG_SYSC_RCAR) += rcar-sysc.o
+obj-$(CONFIG_SYSC_RMOBILE) += rmobile-sysc.o
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c b/drivers/soc/renesas/rmobile-sysc.c
similarity index 100%
rename from arch/arm/mach-shmobile/pm-rmobile.c
rename to drivers/soc/renesas/rmobile-sysc.c
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 8/9] ARM: shmobile: R-Mobile: Clean up struct rmobile_pm_domain
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Commit 59b89af1d5551c12 ("ARM: shmobile: sh7372: Remove Legacy C
SoC code") removed the last user of the rmobile_pm_domain.resume()
callback.
Commit 44d88c754e57a6d9 ("ARM: shmobile: Remove legacy SoC code
for R-Mobile A1") removed the last user of the rmobile_pm_domain.no_debug
flag and of the "pm-rmobile.h" header file (outside the actual driver).
Hence remove no longer used rmobile_pm_domain members, and absorb the
header file into the driver.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/pm-rmobile.c | 37 ++++++++++++++++++-------------------
arch/arm/mach-shmobile/pm-rmobile.h | 22 ----------------------
2 files changed, 18 insertions(+), 41 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/pm-rmobile.h
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c b/arch/arm/mach-shmobile/pm-rmobile.c
index c6a11b5ec6db..421ae1c887d8 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -18,12 +18,11 @@
#include <linux/platform_device.h>
#include <linux/pm.h>
#include <linux/pm_clock.h>
+#include <linux/pm_domain.h>
#include <linux/slab.h>
#include <asm/io.h>
-#include "pm-rmobile.h"
-
/* SYSC */
#define SPDCR 0x08 /* SYS Power Down Control Register */
#define SWUCR 0x14 /* SYS Wakeup Control Register */
@@ -32,6 +31,14 @@
#define PSTR_RETRIES 100
#define PSTR_DELAY_US 10
+struct rmobile_pm_domain {
+ struct generic_pm_domain genpd;
+ struct dev_power_governor *gov;
+ int (*suspend)(void);
+ void __iomem *base;
+ unsigned int bit_shift;
+};
+
static inline
struct rmobile_pm_domain *to_rmobile_pd(struct generic_pm_domain *d)
{
@@ -65,16 +72,13 @@ static int rmobile_pd_power_down(struct generic_pm_domain *genpd)
}
}
- if (!rmobile_pd->no_debug)
- pr_debug("%s: Power off, 0x%08x -> PSTR = 0x%08x\n",
- genpd->name, mask,
- __raw_readl(rmobile_pd->base + PSTR));
+ pr_debug("%s: Power off, 0x%08x -> PSTR = 0x%08x\n", genpd->name, mask,
+ __raw_readl(rmobile_pd->base + PSTR));
return 0;
}
-static int __rmobile_pd_power_up(struct rmobile_pm_domain *rmobile_pd,
- bool do_resume)
+static int __rmobile_pd_power_up(struct rmobile_pm_domain *rmobile_pd)
{
unsigned int mask;
unsigned int retry_count;
@@ -85,7 +89,7 @@ static int __rmobile_pd_power_up(struct rmobile_pm_domain *rmobile_pd,
mask = BIT(rmobile_pd->bit_shift);
if (__raw_readl(rmobile_pd->base + PSTR) & mask)
- goto out;
+ return ret;
__raw_writel(mask, rmobile_pd->base + SWUCR);
@@ -100,21 +104,16 @@ static int __rmobile_pd_power_up(struct rmobile_pm_domain *rmobile_pd,
if (!retry_count)
ret = -EIO;
- if (!rmobile_pd->no_debug)
- pr_debug("%s: Power on, 0x%08x -> PSTR = 0x%08x\n",
- rmobile_pd->genpd.name, mask,
- __raw_readl(rmobile_pd->base + PSTR));
-
-out:
- if (ret == 0 && rmobile_pd->resume && do_resume)
- rmobile_pd->resume();
+ pr_debug("%s: Power on, 0x%08x -> PSTR = 0x%08x\n",
+ rmobile_pd->genpd.name, mask,
+ __raw_readl(rmobile_pd->base + PSTR));
return ret;
}
static int rmobile_pd_power_up(struct generic_pm_domain *genpd)
{
- return __rmobile_pd_power_up(to_rmobile_pd(genpd), true);
+ return __rmobile_pd_power_up(to_rmobile_pd(genpd));
}
static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
@@ -127,7 +126,7 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
genpd->power_on = rmobile_pd_power_up;
genpd->attach_dev = cpg_mstp_attach_dev;
genpd->detach_dev = cpg_mstp_detach_dev;
- __rmobile_pd_power_up(rmobile_pd, false);
+ __rmobile_pd_power_up(rmobile_pd);
pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
}
diff --git a/arch/arm/mach-shmobile/pm-rmobile.h b/arch/arm/mach-shmobile/pm-rmobile.h
deleted file mode 100644
index 69f839259b09..000000000000
--- a/arch/arm/mach-shmobile/pm-rmobile.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0
- *
- * Copyright (C) 2012 Renesas Solutions Corp.
- *
- * Kuninori Morimoto <morimoto.kuninori@renesas.com>
- */
-#ifndef PM_RMOBILE_H
-#define PM_RMOBILE_H
-
-#include <linux/pm_domain.h>
-
-struct rmobile_pm_domain {
- struct generic_pm_domain genpd;
- struct dev_power_governor *gov;
- int (*suspend)(void);
- void (*resume)(void);
- void __iomem *base;
- unsigned int bit_shift;
- bool no_debug;
-};
-
-#endif /* PM_RMOBILE_H */
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 6/9] arm64: renesas: Move SoC Kconfig symbols to drivers/soc/renesas/
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
arch/arm64/Kconfig.platforms has SoC-specific Kconfig symbols for
Renesas SoCs, while other vendors have only a single Kconfig symbol.
Increase consistency with other vendors by moving the SoC-specific
Kconfig symbols to drivers/soc/renesas/Kconfig.
Increase consistency with R-Car Gen1 and Gen2 SoCs on arm32 by
introducing a family-specific Kconfig symbol for R-Car Gen3
(ARCH_RCAR_GEN3), which enables family-specific hardware features.
While so far only a single family (R-Car Gen3 and derivatives) of
Renesas arm64 SoCs is supported by Linux, this will make it easier
to add support for other SoC families later.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/Kconfig.platforms | 59 -----------------------------
drivers/soc/renesas/Kconfig | 90 +++++++++++++++++++++++++++++++++++++-------
2 files changed, 77 insertions(+), 72 deletions(-)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 2eb02734ae45..28f052185eb6 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -159,69 +159,10 @@ config ARCH_RENESAS
bool "Renesas SoC Platforms"
select GPIOLIB
select PINCTRL
- select PM
- select PM_GENERIC_DOMAINS
- select RENESAS_IRQC
select SOC_BUS
- select SYS_SUPPORTS_SH_CMT
- select SYS_SUPPORTS_SH_TMU
help
This enables support for the ARMv8 based Renesas SoCs.
-config ARCH_R8A774A1
- bool "Renesas RZ/G2M SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas RZ/G2M SoC.
-
-config ARCH_R8A774C0
- bool "Renesas RZ/G2E SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas RZ/G2E SoC.
-
-config ARCH_R8A7795
- bool "Renesas R-Car H3 SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas R-Car H3 SoC.
-
-config ARCH_R8A7796
- bool "Renesas R-Car M3-W SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas R-Car M3-W SoC.
-
-config ARCH_R8A77965
- bool "Renesas R-Car M3-N SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas R-Car M3-N SoC.
-
-config ARCH_R8A77970
- bool "Renesas R-Car V3M SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas R-Car V3M SoC.
-
-config ARCH_R8A77980
- bool "Renesas R-Car V3H SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas R-Car V3H SoC.
-
-config ARCH_R8A77990
- bool "Renesas R-Car E3 SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas R-Car E3 SoC.
-
-config ARCH_R8A77995
- bool "Renesas R-Car D3 SoC Platform"
- depends on ARCH_RENESAS
- help
- This enables support for the Renesas R-Car D3 SoC.
-
config ARCH_ROCKCHIP
bool "Rockchip Platforms"
select ARCH_HAS_RESET_CONTROLLER
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 407f02c80e8b..2f5bc5a6ae2b 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -3,30 +3,94 @@ config SOC_RENESAS
bool "Renesas SoC driver support" if COMPILE_TEST && !ARCH_RENESAS
default y if ARCH_RENESAS
select SOC_BUS
- select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2 || \
- ARCH_R8A774A1 || ARCH_R8A774C0 || ARCH_R8A7795 || \
- ARCH_R8A7796 || ARCH_R8A77965 || ARCH_R8A77970 || \
- ARCH_R8A77980 || ARCH_R8A77990 || ARCH_R8A77995
+ select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2
select SYSC_R8A7743 if ARCH_R8A7743 || ARCH_R8A7744
select SYSC_R8A7745 if ARCH_R8A7745
select SYSC_R8A77470 if ARCH_R8A77470
- select SYSC_R8A774A1 if ARCH_R8A774A1
- select SYSC_R8A774C0 if ARCH_R8A774C0
select SYSC_R8A7779 if ARCH_R8A7779
select SYSC_R8A7790 if ARCH_R8A7790
select SYSC_R8A7791 if ARCH_R8A7791 || ARCH_R8A7793
select SYSC_R8A7792 if ARCH_R8A7792
select SYSC_R8A7794 if ARCH_R8A7794
- select SYSC_R8A7795 if ARCH_R8A7795
- select SYSC_R8A7796 if ARCH_R8A7796
- select SYSC_R8A77965 if ARCH_R8A77965
- select SYSC_R8A77970 if ARCH_R8A77970
- select SYSC_R8A77980 if ARCH_R8A77980
- select SYSC_R8A77990 if ARCH_R8A77990
- select SYSC_R8A77995 if ARCH_R8A77995
if SOC_RENESAS
+config ARCH_RCAR_GEN3
+ bool
+ select PM
+ select PM_GENERIC_DOMAINS
+ select RENESAS_IRQC
+ select RST_RCAR
+ select SYS_SUPPORTS_SH_CMT
+ select SYS_SUPPORTS_SH_TMU
+
+if ARM64
+
+config ARCH_R8A774A1
+ bool "Renesas RZ/G2M SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A774A1
+ help
+ This enables support for the Renesas RZ/G2M SoC.
+
+config ARCH_R8A774C0
+ bool "Renesas RZ/G2E SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A774C0
+ help
+ This enables support for the Renesas RZ/G2E SoC.
+
+config ARCH_R8A7795
+ bool "Renesas R-Car H3 SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A7795
+ help
+ This enables support for the Renesas R-Car H3 SoC.
+
+config ARCH_R8A7796
+ bool "Renesas R-Car M3-W SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A7796
+ help
+ This enables support for the Renesas R-Car M3-W SoC.
+
+config ARCH_R8A77965
+ bool "Renesas R-Car M3-N SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A77965
+ help
+ This enables support for the Renesas R-Car M3-N SoC.
+
+config ARCH_R8A77970
+ bool "Renesas R-Car V3M SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A77970
+ help
+ This enables support for the Renesas R-Car V3M SoC.
+
+config ARCH_R8A77980
+ bool "Renesas R-Car V3H SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A77980
+ help
+ This enables support for the Renesas R-Car V3H SoC.
+
+config ARCH_R8A77990
+ bool "Renesas R-Car E3 SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A77990
+ help
+ This enables support for the Renesas R-Car E3 SoC.
+
+config ARCH_R8A77995
+ bool "Renesas R-Car D3 SoC Platform"
+ select ARCH_RCAR_GEN3
+ select SYSC_R8A77995
+ help
+ This enables support for the Renesas R-Car D3 SoC.
+
+endif # ARM64
+
# SoC
config SYSC_R8A7743
bool "RZ/G1M System Controller support" if COMPILE_TEST
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/9] ARM: shmobile: Hide ARCH_RZN1 to improve consistency
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Unlike all other family-specific Kconfig symbols for Renesas ARM SoCs,
ARCH_RZN1 is user-visible. As this symbol is already selected by the
SoC-specific ARCH_R9A06G032 symbol, there is no need for that.
Hide ARCH_RZN1 from the user, and move it up, where all other
family-specific Kconfig symbols live. Drop the select of CPU_V7, as
this is already implied by the dependency of ARCH_RENESAS on
ARCH_MULTI_V7.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index a35eb5913dfd..70c6f557f8cd 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -25,6 +25,10 @@ config ARCH_RMOBILE
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
+config ARCH_RZN1
+ bool
+ select ARM_AMBA
+
menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
@@ -128,11 +132,6 @@ config ARCH_R9A06G032
bool "RZ/N1D (R9A06G032)"
select ARCH_RZN1
-config ARCH_RZN1
- bool "RZ/N1 (R9A06G0xx) Family"
- select ARM_AMBA
- select CPU_V7
-
config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/9] ARM: shmobile: Restrict TWD support to SoCs that have it
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Currently support for the ARM Timer and Watchdog Unit is included
unconditionally, while only some Renesas multicore Cortex-A9 SoCs have
a TWD.
This decreases kernel image size by ca. 2 KiB on SoCs without a TWD.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 32f8297d993a..a35eb5913dfd 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -30,7 +30,6 @@ menuconfig ARCH_RENESAS
depends on ARCH_MULTI_V7 && MMU
select ARM_GIC
select GPIOLIB
- select HAVE_ARM_TWD if SMP
select NO_IOPORT_MAP
select PINCTRL
select SOC_BUS
@@ -95,6 +94,7 @@ config ARCH_R8A7778
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if SMP
select ARCH_RCAR_GEN1
config ARCH_R8A7790
@@ -137,5 +137,6 @@ config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if SMP
select RENESAS_INTC_IRQPIN
endif
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/9] arm64: renesas: Enable GPIOLIB to allow GPIO driver selection
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Takeshi Kihara, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
The R-Car GPIO driver cannot be enabled when Renesas SoC's ARCH configs
(ARCH_RENESAS, ARCH_R8A7795, ARCH_R8A7796 and ARCH_R8A77965) are enabled
only.
As GPIOs are a critical resource for proper operation on Renesas
platforms, this patch selects GPIOLIB, just like is done for other SoC
vendors, and on Renesas arm32 SoCs.
Reported-by: Alexandru Gheorghe <Alexandru_Gheorghe@mentor.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Improve patch description]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 51bc479334a4..2eb02734ae45 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -157,6 +157,7 @@ config ARCH_REALTEK
config ARCH_RENESAS
bool "Renesas SoC Platforms"
+ select GPIOLIB
select PINCTRL
select PM
select PM_GENERIC_DOMAINS
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL] Renesas ARM Based SoC Updates for v4.21
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: arm
Cc: Arnd Bergmann, Kevin Hilman, Magnus Damm, linux-renesas-soc,
Olof Johansson, Simon Horman, linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC updates for v4.21.
Usually I separate SoC changes for ARM and arm64 into separate branches.
On this occasion I have applied them to a single branch and pull request.
The reason for this is that moving SoC Konfig symbols for both ARM and
arm64 creates a dependency and a combined branch is a clean way to resolve
this.
If separate branches are required then I propose deferring the movement
of ARM (but not arm64) SoC Kconfig symbols to v4.22.
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.21
for you to fetch changes up to 2ed29e15e4b2500ae78de658a18f4482e7ac288b:
ARM: shmobile: R-Mobile: Move pm-rmobile to drivers/soc/renesas/ (2018-11-30 11:29:11 +0100)
----------------------------------------------------------------
Renesas ARM Based SoC Updates for v4.21
* pm-rmobile driver
- Move to drivers/soc/renesas/
- Clean up struct rmobile_pm_domain
* Renesas SoC Kconfig Symbols
- Move symbols for ARM and SoCs to drivers/soc/renesas/
- Hide ARCH_RZN1 to improve consistency
* SH-Mobile AG5 (sh73a0) SoC: Remove obsolete inclusion of <asm/smp_twd.h>
* Restrict TWD and SCU to Renesas ARM based SoCs where they are present
* Enable GPIOLIB on Renesas arm64 based SoCs to allow GPIO driver selection
----------------------------------------------------------------
Geert Uytterhoeven (8):
ARM: shmobile: Restrict SCU support to SoCs that have it
ARM: shmobile: Restrict TWD support to SoCs that have it
ARM: shmobile: sh73a0: Remove obsolete inclusion of <asm/smp_twd.h>
ARM: shmobile: Hide ARCH_RZN1 to improve consistency
arm64: renesas: Move SoC Kconfig symbols to drivers/soc/renesas/
ARM: shmobile: Move SoC Kconfig symbols to drivers/soc/renesas/
ARM: shmobile: R-Mobile: Clean up struct rmobile_pm_domain
ARM: shmobile: R-Mobile: Move pm-rmobile to drivers/soc/renesas/
Takeshi Kihara (1):
arm64: renesas: Enable GPIOLIB to allow GPIO driver selection
arch/arm/mach-shmobile/Kconfig | 129 -----------
arch/arm/mach-shmobile/Makefile | 1 -
arch/arm/mach-shmobile/pm-rmobile.h | 22 --
arch/arm/mach-shmobile/smp-sh73a0.c | 1 -
arch/arm64/Kconfig.platforms | 60 +----
drivers/soc/renesas/Kconfig | 241 +++++++++++++++++++--
drivers/soc/renesas/Makefile | 1 +
.../soc/renesas/rmobile-sysc.c | 37 ++--
8 files changed, 240 insertions(+), 252 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/pm-rmobile.h
rename arch/arm/mach-shmobile/pm-rmobile.c => drivers/soc/renesas/rmobile-sysc.c (93%)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: OMAP4430 SDP with KS8851: very slow networking
From: Tony Lindgren @ 2018-12-06 22:14 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: netdev, linux-omap, linux-arm-kernel
In-Reply-To: <20181206180806.GV6920@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [181206 18:08]:
> reverted, the problem is still there. Revert:
>
> ec0daae685b2 ("gpio: omap: Add level wakeup handling for omap4 based SoCs")
>
> on top, and networking returns to normal. So it appears to be this
> last commit causing the issue.
>
> With that and b764a5863fd8 applied, it still misbehaves. Then, poking
> at the OMAP4_GPIO_IRQWAKEN0 register, changing it from 0 to 4 with
> devmem2 restores normal behaviour - ping times are normal and NFS is
> happy.
>
> # devmem2 0x48055044 w 4
OK thanks.
> Given that this GPIO device is not runtime suspended, and is
> permanently active (which is what I think we expect, given that it
> has an IRQ claimed against it) does the hardware still attempt to
> idle the GPIO block - if so, could that be why we need to program
> the wakeup register, so the GPIO block signals that it's active?
Yes we now idle non-irq GPIOs only from CPU_CLUSTER_PM_ENTER
as the selected cpuidle state triggers the domain transitions
with WFI. And that's why runtime_suspended_time does not increase
for a GPIO instance with IRQs.
I can reproduce the long ping latencies on duovero smsc connected
to gpio_44, I'll try to debug it more.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/9] ARM: shmobile: Restrict SCU support to SoCs that have it
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Currently support for the ARM Cortex-A9 Snoop Control Unit is included
unconditionally, while only Renesas multicore Cortex-A9 SoCs have this
kind of SCU.
This decreases kernel image size by ca. 300 bytes on SoCs without such
an SCU.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index b100c26a858f..32f8297d993a 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -30,7 +30,6 @@ menuconfig ARCH_RENESAS
depends on ARCH_MULTI_V7 && MMU
select ARM_GIC
select GPIOLIB
- select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select NO_IOPORT_MAP
select PINCTRL
@@ -43,6 +42,7 @@ if ARCH_RENESAS
config ARCH_EMEV2
bool "Emma Mobile EV2"
+ select HAVE_ARM_SCU if SMP
select SYS_SUPPORTS_EM_STI
config ARCH_R7S72100
@@ -94,6 +94,7 @@ config ARCH_R8A7778
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
+ select HAVE_ARM_SCU if SMP
select ARCH_RCAR_GEN1
config ARCH_R8A7790
@@ -135,5 +136,6 @@ config ARCH_RZN1
config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
+ select HAVE_ARM_SCU if SMP
select RENESAS_INTC_IRQPIN
endif
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/9] ARM: shmobile: sh73a0: Remove obsolete inclusion of <asm/smp_twd.h>
From: Simon Horman @ 2018-12-06 21:59 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <cover.1544132474.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
As of commit 9a9863987bf7307f ("ARM: shmobile: Remove legacy SoC code
for SH-Mobile AG5"), this header file is no longer used.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/smp-sh73a0.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
index 9bc543faba96..0403aa8629dd 100644
--- a/arch/arm/mach-shmobile/smp-sh73a0.c
+++ b/arch/arm/mach-shmobile/smp-sh73a0.c
@@ -12,7 +12,6 @@
#include <linux/delay.h>
#include <asm/smp_plat.h>
-#include <asm/smp_twd.h>
#include "common.h"
#include "sh73a0.h"
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox