From: Hector Martin <marcan@marcan.st> To: Marc Zyngier <maz@kernel.org> Cc: 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>, Will Deacon <will@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 15/25] irqchip/apple-aic: Add support for the Apple Interrupt Controller Date: Tue, 23 Feb 2021 04:35:03 +0900 [thread overview] Message-ID: <2862340c-e26c-2243-500f-d5060e74f088@marcan.st> (raw) In-Reply-To: <87sg5xp5ic.wl-maz@kernel.org> On 16/02/2021 03.09, Marc Zyngier wrote: > On Mon, 15 Feb 2021 12:17:03 +0000, > Hector Martin <marcan@marcan.st> wrote: >> This patch introduces basic UP irqchip support, without SMP/IPI support. > > This last comment seems outdated now. Heh, I forgot to reword this one. Thanks :) >> +config APPLE_AIC >> + bool "Apple Interrupt Controller (AIC)" >> + depends on ARM64 >> + default ARCH_APPLE >> + select IRQ_DOMAIN >> + select IRQ_DOMAIN_HIERARCHY > > arm64 selects GENERIC_IRQ_IPI, which selects IRQ_DOMAIN_HIERARCHY, > which selects IRQ_DOMAIN. So these two lines are superfluous. Ack, removing these for v3. >> + * In addition, this driver also handles FIQs, as these are routed to the same IRQ vector. These >> + * are used for Fast IPIs (TODO), the ARMv8 timer IRQs, and performance counters (TODO). >> + * > > nit: A bit of comment formatting could be helpful. Wrapped this to 80 columns for v3. >> +#include <linux/bits.h> >> +#include <linux/bitfield.h> >> +#include <linux/cpuhotplug.h> >> +#include <linux/io.h> >> +#include <linux/irqchip.h> >> +#include <linux/irqchip/arm-gic-v3.h> > > I'd rather you move the ICH_HCR_* definitions to sysreg.h rather than > including the GICv3 stuff. They are only there for historical reasons > (such as supporting KVM on 32bit systems), none of which apply anymore. Just ICH_HCR, or should I bring all of the ICH_ and ICC_ defines along with it? >> + aic_ic_write(ic, AIC_TARGET_CPU + hwirq * 4, BIT(cpu)); >> + irq_data_update_effective_affinity(d, cpumask_of(cpu)); > > It is fine to pick a single CPU out of the whole affinity set, but you > should tell the kernel that this is the case (irqd_set_single_target()). >> + >> + irq_set_status_flags(irq, IRQ_LEVEL); > > I'm definitely not keen on this override, and the trigger information > should be the one coming from the DT, which is already set for you. > It'd probably be useful to provide an irq_set_type() callback that > returns an error when fed an unsupported trigger. > >> + irq_set_noprobe(irq); > > This seems to be cargo-culted, and I don't believe this is necessary. >> +static const struct irq_domain_ops aic_irq_domain_ops = { >> + .map = aic_irq_domain_map, >> + .unmap = aic_irq_domain_unmap, >> + .xlate = aic_irq_domain_xlate, >> +}; > > You are mixing two APIs: the older OF-specific one, and the newer one > that uses fwnode_handle for hierarchical support. That's OK for older > drivers that were forcefully converted to using generic IPIs, but as > this is a brand new driver, I'd rather it consistently used the new > API. See a proposed rework at [1] (compile tested only). Applying your fixups for these, thanks! :) >> + atomic_and(~irq_bit, &aic_vipi_mask[this_cpu]); > > atomic_andnot()? > >> + >> + if (!atomic_read(&aic_vipi_mask[this_cpu])) >> + aic_ic_write(ic, AIC_IPI_MASK_SET, AIC_IPI_OTHER); > > This is odd. It means that you still perform the MMIO write if the bit > was already clear. I think this could be written as: > > u32 val; > val = atomic_fetch_andnot(irq_bit, &aic_vipi_mask[this_cpu]); > if (val && !(val & ~irq_bit)) > aic_ic_write(); > > val = atomic_fetch_or(irq_bit, &aic_vipi_mask[this_cpu]); > if (!val) > aic_ic_write(); This makes more sense to avoid the redundant MMIO writes. I need to get more familiar with all the available atomic ops... lots of useful stuff in there I didn't know about. >> + for_each_cpu(cpu, mask) { >> + if (atomic_read(&aic_vipi_mask[cpu]) & irq_bit) { >> + atomic_or(irq_bit, &aic_vipi_flag[cpu]); >> + send |= AIC_IPI_SEND_CPU(cpu); > > That's really odd. A masked IPI should be made pending, and delivered > on unmask. I think this all works because we never mask individual > IPIs, as this would otherwise drop interrupts on the floor. I wasn't really sure whether IPIs are supposed to end up pending like that; indeed if that's how it's supposed to work, then I also need logic at mask/unmask time to fire off any pending IPIs. I'll do it like that for v3. Now I wonder how other drivers do it... I'm guessing this never gets tested, since the IPI code only exercises a fraction of the irq features... >> +static void aic_handle_ipi(struct pt_regs *regs) >> +{ >> + int this_cpu = smp_processor_id(); >> + int i; >> + unsigned long firing; >> + >> + aic_ic_write(aic_irqc, AIC_IPI_ACK, AIC_IPI_OTHER); >> + >> + /* >> + * Ensure that we've received and acked the IPI before we load the vIPI >> + * flags. This pairs with the second wmb() above. >> + */ >> + mb(); > > I don't get your ordering here. > > If you are trying to order against something that has happened on > another CPU (which is pretty likely in the case of an IPI), why isn't > this a smp_mb_before_atomic() (and conversely smp_mb_after_atomic() in > aic_ipi_send_mask())? > > Although this looks to me like a good case for _acquire/_release > semantics. This is trying to order the atomic ops with the IPI IRQ itself, in particular the ACK in the preceding line. If they execute in reverse order (or more precisely if the ACK takes effect after the xchg), this happens and we lose an IPI: CPU1 CPU2 set vIPI #0 fire IPI IPI IRQ read EVENT / xchg vIPI set vIPI #1 X fire IPI | \ ACK IPI The converse race can also happen in the CPU1 path, of course, if the IPI ends up fired before the vIPI is set, hence the barrier there. What I'm not sure is how the smp_ ops order with regard to writel_relaxed. It seems like mb() is dsb(sy) and smp_mb() is dmb(ish) and the atomic versions just default to aliasing smp_mb()). An inner-sharable dmb doesn't sound like it would safely satisfy this requirement, as MMIO out to AIC is involved (and we don't know if it's in the inner sharable domain or not for these purposes). Since the MMIO is nGnRnE, I would expect that a dsb(sy) would satisfy this requirement, as then the write op really shouldn't complete until it has taken effect in AIC. >> + /* >> + * Make sure the kernel's idea of logical CPU order is the same as AIC's >> + * If we ever end up with a mismatch here, we will have to introduce >> + * a mapping table similar to what other irqchip drivers do. >> + */ >> + WARN_ON(aic_ic_read(aic_irqc, AIC_WHOAMI) != smp_processor_id()); > > This is unlikely to work as soon as you get kexec up and running. You > may not have to worry about this for some time... Ah, can kexec randomly shuffle CPUs around? The solution here is obvious, but at this point I'm more keen on punting this to a future patch instead of introducing more complexity into the initial series; gotta leave behind some bugs to fix later :) -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub
WARNING: multiple messages have this Message-ID (diff)
From: Hector Martin <marcan@marcan.st> To: Marc Zyngier <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com>, Rob Herring <robh@kernel.org>, Arnd Bergmann <arnd@kernel.org>, Tony Lindgren <tony@atomide.com>, Linus Walleij <linus.walleij@linaro.org>, linux-kernel@vger.kernel.org, Krzysztof Kozlowski <krzk@kernel.org>, devicetree@vger.kernel.org, Alexander Graf <graf@amazon.com>, Olof Johansson <olof@lixom.net>, Mohamed Mediouni <mohamed.mediouni@caramail.com>, Stan Skowronek <stan@corellium.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, Mark Kettenis <mark.kettenis@xs4all.nl> Subject: Re: [PATCH v2 15/25] irqchip/apple-aic: Add support for the Apple Interrupt Controller Date: Tue, 23 Feb 2021 04:35:03 +0900 [thread overview] Message-ID: <2862340c-e26c-2243-500f-d5060e74f088@marcan.st> (raw) In-Reply-To: <87sg5xp5ic.wl-maz@kernel.org> On 16/02/2021 03.09, Marc Zyngier wrote: > On Mon, 15 Feb 2021 12:17:03 +0000, > Hector Martin <marcan@marcan.st> wrote: >> This patch introduces basic UP irqchip support, without SMP/IPI support. > > This last comment seems outdated now. Heh, I forgot to reword this one. Thanks :) >> +config APPLE_AIC >> + bool "Apple Interrupt Controller (AIC)" >> + depends on ARM64 >> + default ARCH_APPLE >> + select IRQ_DOMAIN >> + select IRQ_DOMAIN_HIERARCHY > > arm64 selects GENERIC_IRQ_IPI, which selects IRQ_DOMAIN_HIERARCHY, > which selects IRQ_DOMAIN. So these two lines are superfluous. Ack, removing these for v3. >> + * In addition, this driver also handles FIQs, as these are routed to the same IRQ vector. These >> + * are used for Fast IPIs (TODO), the ARMv8 timer IRQs, and performance counters (TODO). >> + * > > nit: A bit of comment formatting could be helpful. Wrapped this to 80 columns for v3. >> +#include <linux/bits.h> >> +#include <linux/bitfield.h> >> +#include <linux/cpuhotplug.h> >> +#include <linux/io.h> >> +#include <linux/irqchip.h> >> +#include <linux/irqchip/arm-gic-v3.h> > > I'd rather you move the ICH_HCR_* definitions to sysreg.h rather than > including the GICv3 stuff. They are only there for historical reasons > (such as supporting KVM on 32bit systems), none of which apply anymore. Just ICH_HCR, or should I bring all of the ICH_ and ICC_ defines along with it? >> + aic_ic_write(ic, AIC_TARGET_CPU + hwirq * 4, BIT(cpu)); >> + irq_data_update_effective_affinity(d, cpumask_of(cpu)); > > It is fine to pick a single CPU out of the whole affinity set, but you > should tell the kernel that this is the case (irqd_set_single_target()). >> + >> + irq_set_status_flags(irq, IRQ_LEVEL); > > I'm definitely not keen on this override, and the trigger information > should be the one coming from the DT, which is already set for you. > It'd probably be useful to provide an irq_set_type() callback that > returns an error when fed an unsupported trigger. > >> + irq_set_noprobe(irq); > > This seems to be cargo-culted, and I don't believe this is necessary. >> +static const struct irq_domain_ops aic_irq_domain_ops = { >> + .map = aic_irq_domain_map, >> + .unmap = aic_irq_domain_unmap, >> + .xlate = aic_irq_domain_xlate, >> +}; > > You are mixing two APIs: the older OF-specific one, and the newer one > that uses fwnode_handle for hierarchical support. That's OK for older > drivers that were forcefully converted to using generic IPIs, but as > this is a brand new driver, I'd rather it consistently used the new > API. See a proposed rework at [1] (compile tested only). Applying your fixups for these, thanks! :) >> + atomic_and(~irq_bit, &aic_vipi_mask[this_cpu]); > > atomic_andnot()? > >> + >> + if (!atomic_read(&aic_vipi_mask[this_cpu])) >> + aic_ic_write(ic, AIC_IPI_MASK_SET, AIC_IPI_OTHER); > > This is odd. It means that you still perform the MMIO write if the bit > was already clear. I think this could be written as: > > u32 val; > val = atomic_fetch_andnot(irq_bit, &aic_vipi_mask[this_cpu]); > if (val && !(val & ~irq_bit)) > aic_ic_write(); > > val = atomic_fetch_or(irq_bit, &aic_vipi_mask[this_cpu]); > if (!val) > aic_ic_write(); This makes more sense to avoid the redundant MMIO writes. I need to get more familiar with all the available atomic ops... lots of useful stuff in there I didn't know about. >> + for_each_cpu(cpu, mask) { >> + if (atomic_read(&aic_vipi_mask[cpu]) & irq_bit) { >> + atomic_or(irq_bit, &aic_vipi_flag[cpu]); >> + send |= AIC_IPI_SEND_CPU(cpu); > > That's really odd. A masked IPI should be made pending, and delivered > on unmask. I think this all works because we never mask individual > IPIs, as this would otherwise drop interrupts on the floor. I wasn't really sure whether IPIs are supposed to end up pending like that; indeed if that's how it's supposed to work, then I also need logic at mask/unmask time to fire off any pending IPIs. I'll do it like that for v3. Now I wonder how other drivers do it... I'm guessing this never gets tested, since the IPI code only exercises a fraction of the irq features... >> +static void aic_handle_ipi(struct pt_regs *regs) >> +{ >> + int this_cpu = smp_processor_id(); >> + int i; >> + unsigned long firing; >> + >> + aic_ic_write(aic_irqc, AIC_IPI_ACK, AIC_IPI_OTHER); >> + >> + /* >> + * Ensure that we've received and acked the IPI before we load the vIPI >> + * flags. This pairs with the second wmb() above. >> + */ >> + mb(); > > I don't get your ordering here. > > If you are trying to order against something that has happened on > another CPU (which is pretty likely in the case of an IPI), why isn't > this a smp_mb_before_atomic() (and conversely smp_mb_after_atomic() in > aic_ipi_send_mask())? > > Although this looks to me like a good case for _acquire/_release > semantics. This is trying to order the atomic ops with the IPI IRQ itself, in particular the ACK in the preceding line. If they execute in reverse order (or more precisely if the ACK takes effect after the xchg), this happens and we lose an IPI: CPU1 CPU2 set vIPI #0 fire IPI IPI IRQ read EVENT / xchg vIPI set vIPI #1 X fire IPI | \ ACK IPI The converse race can also happen in the CPU1 path, of course, if the IPI ends up fired before the vIPI is set, hence the barrier there. What I'm not sure is how the smp_ ops order with regard to writel_relaxed. It seems like mb() is dsb(sy) and smp_mb() is dmb(ish) and the atomic versions just default to aliasing smp_mb()). An inner-sharable dmb doesn't sound like it would safely satisfy this requirement, as MMIO out to AIC is involved (and we don't know if it's in the inner sharable domain or not for these purposes). Since the MMIO is nGnRnE, I would expect that a dsb(sy) would satisfy this requirement, as then the write op really shouldn't complete until it has taken effect in AIC. >> + /* >> + * Make sure the kernel's idea of logical CPU order is the same as AIC's >> + * If we ever end up with a mismatch here, we will have to introduce >> + * a mapping table similar to what other irqchip drivers do. >> + */ >> + WARN_ON(aic_ic_read(aic_irqc, AIC_WHOAMI) != smp_processor_id()); > > This is unlikely to work as soon as you get kexec up and running. You > may not have to worry about this for some time... Ah, can kexec randomly shuffle CPUs around? The solution here is obvious, but at this point I'm more keen on punting this to a future patch instead of introducing more complexity into the initial series; gotta leave behind some bugs to fix later :) -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ 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-02-22 19:36 UTC|newest] Thread overview: 185+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-15 12:16 [PATCH v2 00/25] Apple M1 SoC platform bring-up Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 12:16 ` [PATCH v2 01/25] dt-bindings: vendor-prefixes: Add apple prefix Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 17:44 ` Krzysztof Kozlowski 2021-02-15 17:44 ` Krzysztof Kozlowski 2021-03-02 8:21 ` Linus Walleij 2021-03-02 8:21 ` Linus Walleij 2021-02-15 12:16 ` [PATCH v2 02/25] dt-bindings: arm: apple: Add bindings for Apple ARM platforms Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 17:48 ` Krzysztof Kozlowski 2021-02-15 17:48 ` Krzysztof Kozlowski 2021-02-16 14:30 ` Hector Martin 2021-02-16 14:30 ` Hector Martin 2021-02-15 12:16 ` [PATCH v2 03/25] dt-bindings: arm: cpus: Add apple,firestorm & icestorm compatibles Hector Martin 2021-02-15 12:16 ` [PATCH v2 03/25] dt-bindings: arm: cpus: Add apple, firestorm " Hector Martin 2021-02-15 12:16 ` [PATCH v2 04/25] arm64: cputype: Add CPU implementor & types for the Apple M1 cores Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 12:16 ` [PATCH v2 05/25] dt-bindings: timer: arm,arch_timer: Add interrupt-names support Hector Martin 2021-02-15 12:16 ` [PATCH v2 05/25] dt-bindings: timer: arm, arch_timer: " Hector Martin 2021-02-15 12:16 ` [PATCH v2 06/25] arm64: arch_timer: implement support for interrupt-names Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 13:28 ` Marc Zyngier 2021-02-15 13:28 ` Marc Zyngier 2021-02-15 15:13 ` Hector Martin 2021-02-15 15:13 ` Hector Martin 2021-02-15 18:23 ` Tony Lindgren 2021-02-15 18:23 ` Tony Lindgren 2021-02-16 14:33 ` Hector Martin 2021-02-16 14:33 ` Hector Martin 2021-02-15 12:16 ` [PATCH v2 07/25] arm64: cpufeature: Add a feature for FIQ support Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 12:16 ` [PATCH v2 08/25] arm64: Always keep DAIF.[IF] in sync Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-17 12:22 ` Mark Rutland 2021-02-17 12:22 ` Mark Rutland 2021-02-18 12:51 ` Hector Martin 2021-02-18 12:51 ` Hector Martin 2021-02-18 14:22 ` Mark Rutland 2021-02-18 14:22 ` Mark Rutland 2021-02-18 14:42 ` Hector Martin 2021-02-18 14:42 ` Hector Martin 2021-02-18 15:26 ` Mark Rutland 2021-02-18 15:26 ` Mark Rutland 2021-02-15 12:16 ` [PATCH v2 09/25] arm64: entry: Map the FIQ vector to IRQ on NEEDS_FIQ platforms Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-17 11:49 ` Mark Rutland 2021-02-17 11:49 ` Mark Rutland 2021-02-17 14:38 ` Marc Zyngier 2021-02-17 14:38 ` Marc Zyngier 2021-02-15 12:16 ` [PATCH v2 10/25] asm-generic/io.h: Add a non-posted variant of ioremap() Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 15:27 ` kernel test robot 2021-02-15 15:27 ` kernel test robot 2021-02-15 16:47 ` Hector Martin 2021-02-16 10:53 ` Christoph Hellwig 2021-02-16 10:53 ` Christoph Hellwig 2021-02-18 13:08 ` Hector Martin 2021-02-18 13:08 ` Hector Martin 2021-02-15 12:16 ` [PATCH v2 11/25] arm64: Implement ioremap_np() to map MMIO as nGnRnE Hector Martin 2021-02-15 12:16 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 12/25] of/address: Add infrastructure to declare MMIO as non-posted Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 13/25] arm64: Add Apple vendor-specific system registers Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 14/25] dt-bindings: interrupt-controller: Add DT bindings for apple-aic Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-16 9:41 ` Arnd Bergmann 2021-02-16 9:41 ` Arnd Bergmann 2021-02-16 11:00 ` Mark Kettenis 2021-02-16 11:00 ` Mark Kettenis 2021-02-16 11:21 ` Arnd Bergmann 2021-02-16 11:21 ` Arnd Bergmann 2021-02-16 11:45 ` Marc Zyngier 2021-02-16 11:45 ` Marc Zyngier 2021-03-02 8:47 ` Linus Walleij 2021-03-02 8:47 ` Linus Walleij 2021-02-15 12:17 ` [PATCH v2 15/25] irqchip/apple-aic: Add support for the Apple Interrupt Controller Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 18:09 ` Marc Zyngier 2021-02-15 18:09 ` Marc Zyngier 2021-02-22 19:35 ` Hector Martin [this message] 2021-02-22 19:35 ` Hector Martin 2021-02-23 17:37 ` Marc Zyngier 2021-02-23 17:37 ` Marc Zyngier 2021-02-15 12:17 ` [PATCH v2 16/25] arm64: Kconfig: Introduce CONFIG_ARCH_APPLE Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 17/25] tty: serial: samsung_tty: Separate S3C64XX ops structure Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 18:06 ` Krzysztof Kozlowski 2021-02-15 18:06 ` Krzysztof Kozlowski 2021-02-18 13:24 ` Hector Martin 2021-02-18 13:24 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 18/25] tty: serial: samsung_tty: add s3c24xx_port_type Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 18:26 ` Krzysztof Kozlowski 2021-02-15 18:26 ` Krzysztof Kozlowski 2021-02-18 13:37 ` Hector Martin 2021-02-18 13:37 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 19/25] tty: serial: samsung_tty: IRQ rework Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 18:40 ` Krzysztof Kozlowski 2021-02-15 18:40 ` Krzysztof Kozlowski 2021-02-18 13:53 ` Hector Martin 2021-02-18 13:53 ` Hector Martin 2021-02-20 19:11 ` Krzysztof Kozlowski 2021-02-20 19:11 ` Krzysztof Kozlowski 2021-02-21 13:43 ` Hector Martin 2021-02-21 13:43 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 20/25] tty: serial: samsung_tty: Use devm_ioremap_resource Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 18:51 ` Krzysztof Kozlowski 2021-02-15 18:51 ` Krzysztof Kozlowski 2021-02-18 14:01 ` Hector Martin 2021-02-18 14:01 ` Hector Martin 2021-02-20 19:13 ` Krzysztof Kozlowski 2021-02-20 19:13 ` Krzysztof Kozlowski 2021-02-20 19:17 ` Marc Zyngier 2021-02-20 19:17 ` Marc Zyngier 2021-02-21 14:38 ` Hector Martin 2021-02-21 14:38 ` Hector Martin 2021-02-21 14:59 ` Marc Zyngier 2021-02-21 14:59 ` Marc Zyngier 2021-02-21 17:09 ` Hector Martin 2021-02-21 17:09 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 21/25] dt-bindings: serial: samsung: Add apple,s5l-uart compatible Hector Martin 2021-02-15 12:17 ` [PATCH v2 21/25] dt-bindings: serial: samsung: Add apple, s5l-uart compatible Hector Martin 2021-02-15 18:53 ` [PATCH v2 21/25] dt-bindings: serial: samsung: Add apple,s5l-uart compatible Krzysztof Kozlowski 2021-02-15 18:53 ` Krzysztof Kozlowski 2021-03-02 8:31 ` Linus Walleij 2021-03-02 8:31 ` [PATCH v2 21/25] dt-bindings: serial: samsung: Add apple, s5l-uart compatible Linus Walleij 2021-02-15 12:17 ` [PATCH v2 22/25] tty: serial: samsung_tty: Add support for Apple UARTs Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 19:13 ` Krzysztof Kozlowski 2021-02-15 19:13 ` Krzysztof Kozlowski 2021-02-18 14:16 ` Hector Martin 2021-02-18 14:16 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 23/25] tty: serial: samsung_tty: Add earlycon " Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 19:17 ` Krzysztof Kozlowski 2021-02-15 19:17 ` Krzysztof Kozlowski 2021-02-16 10:18 ` Arnd Bergmann 2021-02-16 10:18 ` Arnd Bergmann 2021-02-16 10:20 ` Krzysztof Kozlowski 2021-02-16 10:20 ` Krzysztof Kozlowski 2021-02-16 10:29 ` Arnd Bergmann 2021-02-16 10:29 ` Arnd Bergmann 2021-02-16 10:50 ` Hector Martin 2021-02-16 10:50 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 24/25] dt-bindings: display: Add apple,simple-framebuffer Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 12:17 ` [PATCH v2 25/25] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree Hector Martin 2021-02-15 12:17 ` Hector Martin 2021-02-15 19:29 ` Krzysztof Kozlowski 2021-02-15 19:29 ` Krzysztof Kozlowski 2021-02-15 21:00 ` Randy Dunlap 2021-02-15 21:00 ` Randy Dunlap 2021-02-16 7:31 ` Krzysztof Kozlowski 2021-02-16 7:31 ` Krzysztof Kozlowski 2021-02-21 14:43 ` Hector Martin 2021-02-21 14:43 ` Hector Martin 2021-02-21 15:32 ` Krzysztof Kozlowski 2021-02-21 15:32 ` Krzysztof Kozlowski 2021-02-15 12:57 ` [PATCH v2 00/25] Apple M1 SoC platform bring-up Arnd Bergmann 2021-02-15 12:57 ` Arnd Bergmann 2021-02-15 13:22 ` gregkh 2021-02-15 13:22 ` gregkh 2021-02-15 15:57 ` Hector Martin 2021-02-15 15:57 ` Hector Martin 2021-02-15 16:12 ` gregkh 2021-02-15 16:12 ` gregkh 2021-02-15 16:54 ` Hector Martin 2021-02-15 16:54 ` Hector Martin 2021-02-15 17:43 ` Krzysztof Kozlowski 2021-02-15 17:43 ` Krzysztof Kozlowski 2021-02-15 19:11 ` Marc Zyngier 2021-02-15 19:11 ` Marc Zyngier [not found] ` <CAHp75Vd2ObiUJFn-kVWBx+E30my9zXVX5iUtsyRb_c4FcZEDOA@mail.gmail.com> 2021-02-23 9:11 ` Hector Martin 2021-02-23 9:11 ` Hector Martin 2021-02-18 14:36 ` Mark Rutland 2021-02-18 14:36 ` Mark Rutland 2021-02-21 15:20 ` Hector Martin 2021-02-21 15:20 ` Hector Martin 2021-02-24 15:55 ` Hector Martin 2021-02-24 15:55 ` 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=2862340c-e26c-2243-500f-d5060e74f088@marcan.st \ --to=marcan@marcan.st \ --cc=arnd@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=graf@amazon.com \ --cc=krzk@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.kettenis@xs4all.nl \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --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.