From: Marc Zyngier <maz@kernel.org> To: Will Deacon <will@kernel.org> Cc: Hector Martin <marcan@marcan.st>, linux-arm-kernel@lists.infradead.org, Rob Herring <robh@kernel.org>, Arnd Bergmann <arnd@kernel.org>, Olof Johansson <olof@lixom.net>, Krzysztof Kozlowski <krzk@kernel.org>, Mark Kettenis <mark.kettenis@xs4all.nl>, Tony Lindgren <tony@atomide.com>, Mohamed Mediouni <mohamed.mediouni@caramail.com>, Stan Skowronek <stan@corellium.com>, Alexander Graf <graf@amazon.com>, Linus Walleij <linus.walleij@linaro.org>, Mark Rutland <mark.rutland@arm.com>, Andy Shevchenko <andy.shevchenko@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jonathan Corbet <corbet@lwn.net>, Catalin Marinas <catalin.marinas@arm.com>, Christoph Hellwig <hch@infradead.org>, "David S. Miller" <davem@davemloft.net>, devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFT PATCH v3 01/27] arm64: Cope with CPUs stuck in VHE mode Date: Wed, 24 Mar 2021 20:00:12 +0000 [thread overview] Message-ID: <875z1gs4oj.wl-maz@kernel.org> (raw) In-Reply-To: <20210324180546.GA13181@willie-the-truck> On Wed, 24 Mar 2021 18:05:46 +0000, Will Deacon <will@kernel.org> wrote: > > On Fri, Mar 05, 2021 at 06:38:36AM +0900, Hector Martin wrote: > > From: Marc Zyngier <maz@kernel.org> > > > > It seems that the CPU known as Apple M1 has the terrible habit > > of being stuck with HCR_EL2.E2H==1, in violation of the architecture. > > > > Try and work around this deplorable state of affairs by detecting > > the stuck bit early and short-circuit the nVHE dance. It is still > > unknown whether there are many more such nuggets to be found... > > > > Reported-by: Hector Martin <marcan@marcan.st> > > Signed-off-by: Marc Zyngier <maz@kernel.org> > > --- > > arch/arm64/kernel/head.S | 33 ++++++++++++++++++++++++++++++--- > > arch/arm64/kernel/hyp-stub.S | 28 ++++++++++++++++++++++++---- > > 2 files changed, 54 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > > index 66b0e0b66e31..673002b11865 100644 > > --- a/arch/arm64/kernel/head.S > > +++ b/arch/arm64/kernel/head.S > > @@ -477,14 +477,13 @@ EXPORT_SYMBOL(kimage_vaddr) > > * booted in EL1 or EL2 respectively. > > */ > > SYM_FUNC_START(init_kernel_el) > > - mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > - msr sctlr_el1, x0 > > - > > mrs x0, CurrentEL > > cmp x0, #CurrentEL_EL2 > > b.eq init_el2 > > > > SYM_INNER_LABEL(init_el1, SYM_L_LOCAL) > > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > + msr sctlr_el1, x0 > > isb > > mov_q x0, INIT_PSTATE_EL1 > > msr spsr_el1, x0 > > @@ -504,6 +503,34 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL) > > msr vbar_el2, x0 > > isb > > > > + /* > > + * Fruity CPUs seem to have HCR_EL2.E2H set to RES1, > > + * making it impossible to start in nVHE mode. Is that > > + * compliant with the architecture? Absolutely not! > > + */ > > + mrs x0, hcr_el2 > > + and x0, x0, #HCR_E2H > > + cbz x0, 1f > > + > > + /* Switching to VHE requires a sane SCTLR_EL1 as a start */ > > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > + msr_s SYS_SCTLR_EL12, x0 > > + > > + /* > > + * Force an eret into a helper "function", and let it return > > + * to our original caller... This makes sure that we have > > + * initialised the basic PSTATE state. > > + */ > > + mov x0, #INIT_PSTATE_EL2 > > + msr spsr_el1, x0 > > + adr_l x0, stick_to_vhe > > + msr elr_el1, x0 > > + eret > > + > > +1: > > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > + msr sctlr_el1, x0 > > + > > msr elr_el2, lr > > mov w0, #BOOT_CPU_MODE_EL2 > > eret > > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S > > index 5eccbd62fec8..c7601030ee82 100644 > > --- a/arch/arm64/kernel/hyp-stub.S > > +++ b/arch/arm64/kernel/hyp-stub.S > > @@ -27,12 +27,12 @@ SYM_CODE_START(__hyp_stub_vectors) > > ventry el2_fiq_invalid // FIQ EL2t > > ventry el2_error_invalid // Error EL2t > > > > - ventry el2_sync_invalid // Synchronous EL2h > > + ventry elx_sync // Synchronous EL2h > > ventry el2_irq_invalid // IRQ EL2h > > ventry el2_fiq_invalid // FIQ EL2h > > ventry el2_error_invalid // Error EL2h > > > > - ventry el1_sync // Synchronous 64-bit EL1 > > + ventry elx_sync // Synchronous 64-bit EL1 > > ventry el1_irq_invalid // IRQ 64-bit EL1 > > ventry el1_fiq_invalid // FIQ 64-bit EL1 > > ventry el1_error_invalid // Error 64-bit EL1 > > @@ -45,7 +45,7 @@ SYM_CODE_END(__hyp_stub_vectors) > > > > .align 11 > > > > -SYM_CODE_START_LOCAL(el1_sync) > > +SYM_CODE_START_LOCAL(elx_sync) > > cmp x0, #HVC_SET_VECTORS > > b.ne 1f > > msr vbar_el2, x1 > > @@ -71,7 +71,7 @@ SYM_CODE_START_LOCAL(el1_sync) > > > > 9: mov x0, xzr > > eret > > -SYM_CODE_END(el1_sync) > > +SYM_CODE_END(elx_sync) > > > > // nVHE? No way! Give me the real thing! > > SYM_CODE_START_LOCAL(mutate_to_vhe) > > @@ -243,3 +243,23 @@ SYM_FUNC_START(switch_to_vhe) > > #endif > > ret > > SYM_FUNC_END(switch_to_vhe) > > + > > +SYM_FUNC_START(stick_to_vhe) > > + /* > > + * Make sure the switch to VHE cannot fail, by overriding the > > + * override. This is hilarious. > > + */ > > + adr_l x1, id_aa64mmfr1_override > > + add x1, x1, #FTR_OVR_MASK_OFFSET > > + dc civac, x1 > > + dsb sy > > + isb > > Why do we need an ISB here? Hmmm. Probably me being paranoid and trying to come up with something for Hector to test before I had access to the HW. The DSB is more than enough to order CMO and load/store. > > + ldr x0, [x1] > > + bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) > > + str x0, [x1] > > I find it a bit bizarre doing this here, as for the primary CPU we're still > a way away from parsing the early paramaters and for secondary CPUs this > doesn't need to be done for each one. Furthermore, this same code is run > on the resume path, which can probably then race with itself. Agreed, this isn't great. > Is it possible to do it later on the boot CPU only, e.g. in > init_feature_override()? We should probably also log a warning that we're > ignoring the option because nVHE is not available. I've come up with this on top of the original patch, spitting a warning when the right conditions are met. It's pretty ugly, but hey, so is the HW this runs on. M. diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index c7601030ee82..e6fa5cdd790a 100644 --- a/arch/arm64/kernel/hyp-stub.S +++ b/arch/arm64/kernel/hyp-stub.S @@ -245,19 +245,6 @@ SYM_FUNC_START(switch_to_vhe) SYM_FUNC_END(switch_to_vhe) SYM_FUNC_START(stick_to_vhe) - /* - * Make sure the switch to VHE cannot fail, by overriding the - * override. This is hilarious. - */ - adr_l x1, id_aa64mmfr1_override - add x1, x1, #FTR_OVR_MASK_OFFSET - dc civac, x1 - dsb sy - isb - ldr x0, [x1] - bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) - str x0, [x1] - mov x0, #HVC_VHE_RESTART hvc #0 mov x0, #BOOT_CPU_MODE_EL2 diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c index 83f1c4b92095..ec07e150cf5c 100644 --- a/arch/arm64/kernel/idreg-override.c +++ b/arch/arm64/kernel/idreg-override.c @@ -195,6 +195,8 @@ static __init void parse_cmdline(void) __parse_cmdline(prop, true); } +static bool nvhe_impaired __initdata; + /* Keep checkers quiet */ void init_feature_override(void); @@ -211,9 +213,32 @@ asmlinkage void __init init_feature_override(void) parse_cmdline(); + /* + * If we ever reach this point while running VHE, we're + * guaranteed to be on one of these funky, VHE-stuck CPUs. If + * the user was trying to force nVHE on us, proceed with + * attitude adjustment. + */ + if (is_kernel_in_hyp_mode()) { + u64 mask = 0xfUL << ID_AA64MMFR1_VHE_SHIFT; + + if ((id_aa64mmfr1_override.mask & mask) && + !(id_aa64mmfr1_override.val & mask)) { + nvhe_impaired = true; + id_aa64mmfr1_override.mask &= ~mask; + } + } + for (i = 0; i < ARRAY_SIZE(regs); i++) { if (regs[i]->override) __flush_dcache_area(regs[i]->override, sizeof(*regs[i]->override)); } } + +static int __init check_feature_override(void) +{ + WARN_ON(nvhe_impaired); + return 0; +} +core_initcall(check_feature_override); -- Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Will Deacon <will@kernel.org> Cc: Hector Martin <marcan@marcan.st>, linux-arm-kernel@lists.infradead.org, Rob Herring <robh@kernel.org>, Arnd Bergmann <arnd@kernel.org>, Olof Johansson <olof@lixom.net>, Krzysztof Kozlowski <krzk@kernel.org>, Mark Kettenis <mark.kettenis@xs4all.nl>, Tony Lindgren <tony@atomide.com>, Mohamed Mediouni <mohamed.mediouni@caramail.com>, Stan Skowronek <stan@corellium.com>, Alexander Graf <graf@amazon.com>, Linus Walleij <linus.walleij@linaro.org>, Mark Rutland <mark.rutland@arm.com>, Andy Shevchenko <andy.shevchenko@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jonathan Corbet <corbet@lwn.net>, Catalin Marinas <catalin.marinas@arm.com>, Christoph Hellwig <hch@infradead.org>, "David S. Miller" <davem@davemloft.net>, devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFT PATCH v3 01/27] arm64: Cope with CPUs stuck in VHE mode Date: Wed, 24 Mar 2021 20:00:12 +0000 [thread overview] Message-ID: <875z1gs4oj.wl-maz@kernel.org> (raw) In-Reply-To: <20210324180546.GA13181@willie-the-truck> On Wed, 24 Mar 2021 18:05:46 +0000, Will Deacon <will@kernel.org> wrote: > > On Fri, Mar 05, 2021 at 06:38:36AM +0900, Hector Martin wrote: > > From: Marc Zyngier <maz@kernel.org> > > > > It seems that the CPU known as Apple M1 has the terrible habit > > of being stuck with HCR_EL2.E2H==1, in violation of the architecture. > > > > Try and work around this deplorable state of affairs by detecting > > the stuck bit early and short-circuit the nVHE dance. It is still > > unknown whether there are many more such nuggets to be found... > > > > Reported-by: Hector Martin <marcan@marcan.st> > > Signed-off-by: Marc Zyngier <maz@kernel.org> > > --- > > arch/arm64/kernel/head.S | 33 ++++++++++++++++++++++++++++++--- > > arch/arm64/kernel/hyp-stub.S | 28 ++++++++++++++++++++++++---- > > 2 files changed, 54 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > > index 66b0e0b66e31..673002b11865 100644 > > --- a/arch/arm64/kernel/head.S > > +++ b/arch/arm64/kernel/head.S > > @@ -477,14 +477,13 @@ EXPORT_SYMBOL(kimage_vaddr) > > * booted in EL1 or EL2 respectively. > > */ > > SYM_FUNC_START(init_kernel_el) > > - mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > - msr sctlr_el1, x0 > > - > > mrs x0, CurrentEL > > cmp x0, #CurrentEL_EL2 > > b.eq init_el2 > > > > SYM_INNER_LABEL(init_el1, SYM_L_LOCAL) > > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > + msr sctlr_el1, x0 > > isb > > mov_q x0, INIT_PSTATE_EL1 > > msr spsr_el1, x0 > > @@ -504,6 +503,34 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL) > > msr vbar_el2, x0 > > isb > > > > + /* > > + * Fruity CPUs seem to have HCR_EL2.E2H set to RES1, > > + * making it impossible to start in nVHE mode. Is that > > + * compliant with the architecture? Absolutely not! > > + */ > > + mrs x0, hcr_el2 > > + and x0, x0, #HCR_E2H > > + cbz x0, 1f > > + > > + /* Switching to VHE requires a sane SCTLR_EL1 as a start */ > > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > + msr_s SYS_SCTLR_EL12, x0 > > + > > + /* > > + * Force an eret into a helper "function", and let it return > > + * to our original caller... This makes sure that we have > > + * initialised the basic PSTATE state. > > + */ > > + mov x0, #INIT_PSTATE_EL2 > > + msr spsr_el1, x0 > > + adr_l x0, stick_to_vhe > > + msr elr_el1, x0 > > + eret > > + > > +1: > > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > > + msr sctlr_el1, x0 > > + > > msr elr_el2, lr > > mov w0, #BOOT_CPU_MODE_EL2 > > eret > > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S > > index 5eccbd62fec8..c7601030ee82 100644 > > --- a/arch/arm64/kernel/hyp-stub.S > > +++ b/arch/arm64/kernel/hyp-stub.S > > @@ -27,12 +27,12 @@ SYM_CODE_START(__hyp_stub_vectors) > > ventry el2_fiq_invalid // FIQ EL2t > > ventry el2_error_invalid // Error EL2t > > > > - ventry el2_sync_invalid // Synchronous EL2h > > + ventry elx_sync // Synchronous EL2h > > ventry el2_irq_invalid // IRQ EL2h > > ventry el2_fiq_invalid // FIQ EL2h > > ventry el2_error_invalid // Error EL2h > > > > - ventry el1_sync // Synchronous 64-bit EL1 > > + ventry elx_sync // Synchronous 64-bit EL1 > > ventry el1_irq_invalid // IRQ 64-bit EL1 > > ventry el1_fiq_invalid // FIQ 64-bit EL1 > > ventry el1_error_invalid // Error 64-bit EL1 > > @@ -45,7 +45,7 @@ SYM_CODE_END(__hyp_stub_vectors) > > > > .align 11 > > > > -SYM_CODE_START_LOCAL(el1_sync) > > +SYM_CODE_START_LOCAL(elx_sync) > > cmp x0, #HVC_SET_VECTORS > > b.ne 1f > > msr vbar_el2, x1 > > @@ -71,7 +71,7 @@ SYM_CODE_START_LOCAL(el1_sync) > > > > 9: mov x0, xzr > > eret > > -SYM_CODE_END(el1_sync) > > +SYM_CODE_END(elx_sync) > > > > // nVHE? No way! Give me the real thing! > > SYM_CODE_START_LOCAL(mutate_to_vhe) > > @@ -243,3 +243,23 @@ SYM_FUNC_START(switch_to_vhe) > > #endif > > ret > > SYM_FUNC_END(switch_to_vhe) > > + > > +SYM_FUNC_START(stick_to_vhe) > > + /* > > + * Make sure the switch to VHE cannot fail, by overriding the > > + * override. This is hilarious. > > + */ > > + adr_l x1, id_aa64mmfr1_override > > + add x1, x1, #FTR_OVR_MASK_OFFSET > > + dc civac, x1 > > + dsb sy > > + isb > > Why do we need an ISB here? Hmmm. Probably me being paranoid and trying to come up with something for Hector to test before I had access to the HW. The DSB is more than enough to order CMO and load/store. > > + ldr x0, [x1] > > + bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) > > + str x0, [x1] > > I find it a bit bizarre doing this here, as for the primary CPU we're still > a way away from parsing the early paramaters and for secondary CPUs this > doesn't need to be done for each one. Furthermore, this same code is run > on the resume path, which can probably then race with itself. Agreed, this isn't great. > Is it possible to do it later on the boot CPU only, e.g. in > init_feature_override()? We should probably also log a warning that we're > ignoring the option because nVHE is not available. I've come up with this on top of the original patch, spitting a warning when the right conditions are met. It's pretty ugly, but hey, so is the HW this runs on. M. diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index c7601030ee82..e6fa5cdd790a 100644 --- a/arch/arm64/kernel/hyp-stub.S +++ b/arch/arm64/kernel/hyp-stub.S @@ -245,19 +245,6 @@ SYM_FUNC_START(switch_to_vhe) SYM_FUNC_END(switch_to_vhe) SYM_FUNC_START(stick_to_vhe) - /* - * Make sure the switch to VHE cannot fail, by overriding the - * override. This is hilarious. - */ - adr_l x1, id_aa64mmfr1_override - add x1, x1, #FTR_OVR_MASK_OFFSET - dc civac, x1 - dsb sy - isb - ldr x0, [x1] - bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) - str x0, [x1] - mov x0, #HVC_VHE_RESTART hvc #0 mov x0, #BOOT_CPU_MODE_EL2 diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c index 83f1c4b92095..ec07e150cf5c 100644 --- a/arch/arm64/kernel/idreg-override.c +++ b/arch/arm64/kernel/idreg-override.c @@ -195,6 +195,8 @@ static __init void parse_cmdline(void) __parse_cmdline(prop, true); } +static bool nvhe_impaired __initdata; + /* Keep checkers quiet */ void init_feature_override(void); @@ -211,9 +213,32 @@ asmlinkage void __init init_feature_override(void) parse_cmdline(); + /* + * If we ever reach this point while running VHE, we're + * guaranteed to be on one of these funky, VHE-stuck CPUs. If + * the user was trying to force nVHE on us, proceed with + * attitude adjustment. + */ + if (is_kernel_in_hyp_mode()) { + u64 mask = 0xfUL << ID_AA64MMFR1_VHE_SHIFT; + + if ((id_aa64mmfr1_override.mask & mask) && + !(id_aa64mmfr1_override.val & mask)) { + nvhe_impaired = true; + id_aa64mmfr1_override.mask &= ~mask; + } + } + for (i = 0; i < ARRAY_SIZE(regs); i++) { if (regs[i]->override) __flush_dcache_area(regs[i]->override, sizeof(*regs[i]->override)); } } + +static int __init check_feature_override(void) +{ + WARN_ON(nvhe_impaired); + return 0; +} +core_initcall(check_feature_override); -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-24 20:01 UTC|newest] Thread overview: 275+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-04 21:38 [RFT PATCH v3 00/27] Apple M1 SoC platform bring-up Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 01/27] arm64: Cope with CPUs stuck in VHE mode Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-24 18:05 ` Will Deacon 2021-03-24 18:05 ` Will Deacon 2021-03-24 20:00 ` Marc Zyngier [this message] 2021-03-24 20:00 ` Marc Zyngier 2021-03-26 7:54 ` Hector Martin 2021-03-26 7:54 ` Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 02/27] dt-bindings: vendor-prefixes: Add apple prefix Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-08 20:26 ` Rob Herring 2021-03-08 20:26 ` Rob Herring 2021-03-04 21:38 ` [RFT PATCH v3 03/27] dt-bindings: arm: apple: Add bindings for Apple ARM platforms Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:16 ` Linus Walleij 2021-03-05 10:16 ` Linus Walleij 2021-03-08 20:27 ` Rob Herring 2021-03-08 20:27 ` Rob Herring 2021-03-04 21:38 ` [RFT PATCH v3 04/27] dt-bindings: arm: cpus: Add apple,firestorm & icestorm compatibles Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 04/27] dt-bindings: arm: cpus: Add apple, firestorm " Hector Martin 2021-03-08 20:27 ` [RFT PATCH v3 04/27] dt-bindings: arm: cpus: Add apple,firestorm " Rob Herring 2021-03-08 20:27 ` [RFT PATCH v3 04/27] dt-bindings: arm: cpus: Add apple, firestorm " Rob Herring 2021-03-04 21:38 ` [RFT PATCH v3 05/27] arm64: cputype: Add CPU implementor & types for the Apple M1 cores Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-24 18:13 ` Will Deacon 2021-03-24 18:13 ` Will Deacon 2021-03-04 21:38 ` [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: Add interrupt-names support Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 06/27] dt-bindings: timer: arm, arch_timer: " Hector Martin 2021-03-05 10:18 ` [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: " Linus Walleij 2021-03-05 10:18 ` Linus Walleij 2021-03-08 11:12 ` Marc Zyngier 2021-03-08 11:12 ` [RFT PATCH v3 06/27] dt-bindings: timer: arm, arch_timer: " Marc Zyngier 2021-03-08 17:14 ` [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: " Tony Lindgren 2021-03-08 17:14 ` Tony Lindgren 2021-03-08 20:38 ` Rob Herring 2021-03-08 20:38 ` Rob Herring 2021-03-08 22:42 ` Marc Zyngier 2021-03-08 22:42 ` [RFT PATCH v3 06/27] dt-bindings: timer: arm, arch_timer: " Marc Zyngier 2021-03-09 16:11 ` [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: " Rob Herring 2021-03-09 16:11 ` Rob Herring 2021-03-09 20:28 ` Hector Martin 2021-03-09 20:28 ` Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 07/27] arm64: arch_timer: implement support for interrupt-names Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:19 ` Linus Walleij 2021-03-05 10:19 ` Linus Walleij 2021-03-08 11:13 ` Marc Zyngier 2021-03-08 11:13 ` Marc Zyngier 2021-03-04 21:38 ` [RFT PATCH v3 08/27] asm-generic/io.h: Add a non-posted variant of ioremap() Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 14:45 ` Andy Shevchenko 2021-03-05 14:45 ` Andy Shevchenko 2021-03-05 15:19 ` Hector Martin 2021-03-05 15:19 ` Hector Martin 2021-03-08 11:20 ` Marc Zyngier 2021-03-08 11:20 ` Marc Zyngier 2021-03-24 18:12 ` Will Deacon 2021-03-24 18:12 ` Will Deacon 2021-03-24 19:09 ` Arnd Bergmann 2021-03-24 19:09 ` Arnd Bergmann 2021-03-25 14:07 ` Hector Martin 2021-03-25 14:07 ` Hector Martin 2021-03-25 14:49 ` Will Deacon 2021-03-25 14:49 ` Will Deacon 2021-03-04 21:38 ` [RFT PATCH v3 09/27] docs: driver-api: device-io: Document I/O access functions Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:22 ` Linus Walleij 2021-03-05 10:22 ` Linus Walleij 2021-03-04 21:38 ` [RFT PATCH v3 10/27] docs: driver-api: device-io: Document ioremap() variants & access funcs Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:25 ` Linus Walleij 2021-03-05 10:25 ` Linus Walleij 2021-03-05 15:09 ` Andy Shevchenko 2021-03-05 15:09 ` Andy Shevchenko 2021-03-05 15:51 ` Arnd Bergmann 2021-03-05 15:51 ` Arnd Bergmann 2021-03-09 20:29 ` Hector Martin 2021-03-09 20:29 ` Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 11/27] arm64: Implement ioremap_np() to map MMIO as nGnRnE Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-08 11:22 ` Marc Zyngier 2021-03-08 11:22 ` Marc Zyngier 2021-03-24 18:18 ` Will Deacon 2021-03-24 18:18 ` Will Deacon 2021-03-04 21:38 ` [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:28 ` Linus Walleij 2021-03-05 10:28 ` Linus Walleij 2021-03-05 15:13 ` Andy Shevchenko 2021-03-05 15:13 ` Andy Shevchenko 2021-03-05 15:55 ` Hector Martin 2021-03-05 15:55 ` Hector Martin 2021-03-05 16:08 ` Andy Shevchenko 2021-03-05 16:08 ` Andy Shevchenko 2021-03-05 16:43 ` Arnd Bergmann 2021-03-05 16:43 ` Arnd Bergmann 2021-03-05 17:19 ` Hector Martin 2021-03-05 17:19 ` Hector Martin 2021-03-05 16:05 ` Rob Herring 2021-03-05 16:05 ` Rob Herring 2021-03-05 17:39 ` Rob Herring 2021-03-05 17:39 ` Rob Herring 2021-03-05 18:18 ` Hector Martin 2021-03-05 18:18 ` Hector Martin 2021-03-05 21:17 ` Arnd Bergmann 2021-03-05 21:17 ` Arnd Bergmann 2021-03-08 15:56 ` Rob Herring 2021-03-08 15:56 ` Rob Herring 2021-03-08 20:29 ` Arnd Bergmann 2021-03-08 20:29 ` Arnd Bergmann 2021-03-08 21:13 ` Rob Herring 2021-03-08 21:13 ` Rob Herring 2021-03-08 21:56 ` Arnd Bergmann 2021-03-08 21:56 ` Arnd Bergmann 2021-03-09 15:48 ` Rob Herring 2021-03-09 15:48 ` Rob Herring 2021-03-09 20:23 ` Hector Martin 2021-03-09 20:23 ` Hector Martin 2021-03-09 22:06 ` Rob Herring 2021-03-09 22:06 ` Rob Herring 2021-03-10 8:26 ` Hector Martin 2021-03-10 8:26 ` Hector Martin 2021-03-10 17:01 ` Rob Herring 2021-03-10 17:01 ` Rob Herring 2021-03-11 9:12 ` Arnd Bergmann 2021-03-11 9:12 ` Arnd Bergmann 2021-03-11 12:11 ` Hector Martin 2021-03-11 12:11 ` Hector Martin 2021-03-11 13:35 ` Arnd Bergmann 2021-03-11 13:35 ` Arnd Bergmann 2021-03-11 16:07 ` Rob Herring 2021-03-11 16:07 ` Rob Herring 2021-03-11 16:48 ` Arnd Bergmann 2021-03-11 16:48 ` Arnd Bergmann 2021-03-11 18:10 ` Rob Herring 2021-03-11 18:10 ` Rob Herring 2021-03-12 10:20 ` Arnd Bergmann 2021-03-12 10:20 ` Arnd Bergmann 2021-03-09 11:14 ` Linus Walleij 2021-03-09 11:14 ` Linus Walleij 2021-03-09 12:41 ` Arnd Bergmann 2021-03-09 12:41 ` Arnd Bergmann 2021-03-09 15:40 ` Linus Walleij 2021-03-09 15:40 ` Linus Walleij 2021-03-04 21:38 ` [RFT PATCH v3 13/27] arm64: Add Apple vendor-specific system registers Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-24 18:38 ` Will Deacon 2021-03-24 18:38 ` Will Deacon 2021-03-24 18:59 ` Mark Rutland 2021-03-24 18:59 ` Mark Rutland 2021-03-24 19:04 ` Will Deacon 2021-03-24 19:04 ` Will Deacon 2021-03-26 6:23 ` Hector Martin 2021-03-26 6:23 ` Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 14/27] arm64: move ICH_ sysreg bits from arm-gic-v3.h to sysreg.h Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-08 11:39 ` Marc Zyngier 2021-03-08 11:39 ` Marc Zyngier 2021-03-24 18:23 ` Will Deacon 2021-03-24 18:23 ` Will Deacon 2021-03-04 21:38 ` [RFT PATCH v3 15/27] dt-bindings: interrupt-controller: Add DT bindings for apple-aic Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-08 21:16 ` Rob Herring 2021-03-08 21:16 ` Rob Herring 2021-03-04 21:38 ` [RFT PATCH v3 16/27] irqchip/apple-aic: Add support for the Apple Interrupt Controller Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 15:05 ` Andy Shevchenko 2021-03-05 15:05 ` Andy Shevchenko 2021-03-08 11:50 ` Marc Zyngier 2021-03-08 11:50 ` Marc Zyngier 2021-03-08 12:02 ` Andy Shevchenko 2021-03-08 12:02 ` Andy Shevchenko 2021-03-26 13:40 ` Hector Martin 2021-03-26 13:40 ` Hector Martin 2021-03-08 13:31 ` Marc Zyngier 2021-03-08 13:31 ` Marc Zyngier 2021-03-26 7:57 ` Hector Martin 2021-03-26 7:57 ` Hector Martin 2021-03-24 19:57 ` Will Deacon 2021-03-24 19:57 ` Will Deacon 2021-03-26 8:58 ` Hector Martin 2021-03-26 8:58 ` Hector Martin 2021-03-29 12:04 ` Will Deacon 2021-03-29 12:04 ` Will Deacon 2021-04-01 13:16 ` Hector Martin 2021-04-01 13:16 ` Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 17/27] arm64: Kconfig: Introduce CONFIG_ARCH_APPLE Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-08 15:35 ` Marc Zyngier 2021-03-08 15:35 ` Marc Zyngier 2021-03-09 20:30 ` Hector Martin 2021-03-09 20:30 ` Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 18/27] tty: serial: samsung_tty: Separate S3C64XX ops structure Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:30 ` Krzysztof Kozlowski 2021-03-05 10:30 ` Krzysztof Kozlowski 2021-03-04 21:38 ` [RFT PATCH v3 19/27] tty: serial: samsung_tty: Add ucon_mask parameter Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:34 ` Krzysztof Kozlowski 2021-03-05 10:34 ` Krzysztof Kozlowski 2021-03-04 21:38 ` [RFT PATCH v3 20/27] tty: serial: samsung_tty: Add s3c24xx_port_type Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:49 ` Krzysztof Kozlowski 2021-03-05 10:49 ` Krzysztof Kozlowski 2021-03-04 21:38 ` [RFT PATCH v3 21/27] tty: serial: samsung_tty: IRQ rework Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:51 ` Krzysztof Kozlowski 2021-03-05 10:51 ` Krzysztof Kozlowski 2021-03-05 15:17 ` Andy Shevchenko 2021-03-05 15:17 ` Andy Shevchenko 2021-03-05 16:16 ` Hector Martin 2021-03-05 16:16 ` Hector Martin 2021-03-05 16:20 ` Andy Shevchenko 2021-03-05 16:20 ` Andy Shevchenko 2021-03-05 16:29 ` Hector Martin 2021-03-05 16:29 ` Hector Martin 2021-03-07 11:34 ` Krzysztof Kozlowski 2021-03-07 11:34 ` Krzysztof Kozlowski 2021-03-07 16:01 ` Arnd Bergmann 2021-03-07 16:01 ` Arnd Bergmann 2021-03-07 19:51 ` Krzysztof Kozlowski 2021-03-07 19:51 ` Krzysztof Kozlowski 2021-03-04 21:38 ` [RFT PATCH v3 22/27] tty: serial: samsung_tty: Use devm_ioremap_resource Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:54 ` Krzysztof Kozlowski 2021-03-05 10:54 ` Krzysztof Kozlowski 2021-03-05 15:19 ` Andy Shevchenko 2021-03-05 15:19 ` Andy Shevchenko 2021-03-04 21:38 ` [RFT PATCH v3 23/27] dt-bindings: serial: samsung: Add apple,s5l-uart compatible Hector Martin 2021-03-04 21:38 ` [RFT PATCH v3 23/27] dt-bindings: serial: samsung: Add apple, s5l-uart compatible Hector Martin 2021-03-08 21:17 ` [RFT PATCH v3 23/27] dt-bindings: serial: samsung: Add apple,s5l-uart compatible Rob Herring 2021-03-08 21:17 ` Rob Herring 2021-03-04 21:38 ` [RFT PATCH v3 24/27] tty: serial: samsung_tty: Add support for Apple UARTs Hector Martin 2021-03-04 21:38 ` Hector Martin 2021-03-05 10:58 ` Krzysztof Kozlowski 2021-03-05 10:58 ` Krzysztof Kozlowski 2021-03-05 15:28 ` Andy Shevchenko 2021-03-05 15:28 ` Andy Shevchenko 2021-03-05 17:04 ` Hector Martin 2021-03-05 17:04 ` Hector Martin 2021-03-07 11:40 ` Krzysztof Kozlowski 2021-03-07 11:40 ` Krzysztof Kozlowski 2021-03-04 21:39 ` [RFT PATCH v3 25/27] tty: serial: samsung_tty: Add earlycon " Hector Martin 2021-03-04 21:39 ` Hector Martin 2021-03-05 10:55 ` Krzysztof Kozlowski 2021-03-05 10:55 ` Krzysztof Kozlowski 2021-03-10 23:11 ` Linus Walleij 2021-03-10 23:11 ` Linus Walleij 2021-03-04 21:39 ` [RFT PATCH v3 26/27] dt-bindings: display: Add apple,simple-framebuffer Hector Martin 2021-03-04 21:39 ` [RFT PATCH v3 26/27] dt-bindings: display: Add apple, simple-framebuffer Hector Martin 2021-03-08 21:18 ` [RFT PATCH v3 26/27] dt-bindings: display: Add apple,simple-framebuffer Rob Herring 2021-03-08 21:18 ` Rob Herring 2021-03-09 16:37 ` Linus Walleij 2021-03-09 16:37 ` [RFT PATCH v3 26/27] dt-bindings: display: Add apple, simple-framebuffer Linus Walleij 2021-03-09 20:35 ` [RFT PATCH v3 26/27] dt-bindings: display: Add apple,simple-framebuffer Hector Martin 2021-03-09 20:35 ` Hector Martin 2021-03-04 21:39 ` [RFT PATCH v3 27/27] arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree Hector Martin 2021-03-04 21:39 ` Hector Martin 2021-03-05 11:03 ` Krzysztof Kozlowski 2021-03-05 11:03 ` Krzysztof Kozlowski 2021-03-05 11:14 ` Hector Martin 2021-03-05 11:14 ` Hector Martin 2021-03-05 11:45 ` Krzysztof Kozlowski 2021-03-05 11:45 ` Krzysztof Kozlowski 2021-03-05 15:59 ` Mark Kettenis 2021-03-05 15:59 ` Mark Kettenis 2021-03-05 16:50 ` Hector Martin 2021-03-05 16:50 ` Hector Martin 2021-03-13 20:22 ` Konrad Dybcio 2021-04-05 5:50 ` Hector Martin 2021-04-06 7:14 ` Arnd Bergmann 2021-03-05 10:11 ` [RFT PATCH v3 00/27] Apple M1 SoC platform bring-up Hector Martin 2021-03-05 10:11 ` Hector Martin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=875z1gs4oj.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=andy.shevchenko@gmail.com \ --cc=arnd@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=graf@amazon.com \ --cc=gregkh@linuxfoundation.org \ --cc=hch@infradead.org \ --cc=krzk@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=marcan@marcan.st \ --cc=mark.kettenis@xs4all.nl \ --cc=mark.rutland@arm.com \ --cc=mohamed.mediouni@caramail.com \ --cc=olof@lixom.net \ --cc=robh@kernel.org \ --cc=stan@corellium.com \ --cc=tony@atomide.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.