Re: Make set_handle_irq and handle_arch_irq generic, v3
On Fri, 09 Mar 2018 15:00:56 PST (-0800), t...@linutronix.de wrote: On Fri, 9 Mar 2018, Palmer Dabbelt wrote: On Fri, 09 Mar 2018 02:20:12 PST (-0800), t...@linutronix.de wrote: > This looks sensible. We have two options for getting this merged: > > 1) I'll take the whole lot through tip/irq/core > > 2) I'll apply patch 1/N to a special branch in tip. That branch will > contain > only this commit on top of 4.16-rc4 and can be pulled by the relevant > architecture maintainers, so they can apply their architecture specific > patches. Option 1 seems like the lowest overhead, as that way we don't need to sequence the patches between multiple trees. If all the other arch maintianers are OK with it then that works for me. Ok, I wait for someone to yell NO until tuesday. If that doesn't happen I pick it up. The 0-day robot found a new build warning on openrisc. I was plannning on submitting a v4 with this fix in it diff --git a/arch/openrisc/include/asm/irq.h b/arch/openrisc/include/asm/irq.h index d9eee0a2b7b4..eb612b1865d2 100644 --- a/arch/openrisc/include/asm/irq.h +++ b/arch/openrisc/include/asm/irq.h @@ -24,6 +24,4 @@ #define NO_IRQ (-1) -extern void set_handle_irq(void (*handle_irq)(struct pt_regs *)); - #endif /* __ASM_OPENRISC_IRQ_H__ */ I can submit a v4, or you can just grab it from Just reply on the v3 openrisc patch with a v4 and I grab it from there. OK, I just did -- sorry it took a while, I had to prepare for the ELC hackathon.
Re: Make set_handle_irq and handle_arch_irq generic, v3
On Fri, 9 Mar 2018, Palmer Dabbelt wrote: > On Fri, 09 Mar 2018 02:20:12 PST (-0800), t...@linutronix.de wrote: > > This looks sensible. We have two options for getting this merged: > > > > 1) I'll take the whole lot through tip/irq/core > > > > 2) I'll apply patch 1/N to a special branch in tip. That branch will > > contain > > only this commit on top of 4.16-rc4 and can be pulled by the relevant > > architecture maintainers, so they can apply their architecture specific > > patches. > > Option 1 seems like the lowest overhead, as that way we don't need to sequence > the patches between multiple trees. If all the other arch maintianers are OK > with it then that works for me. Ok, I wait for someone to yell NO until tuesday. If that doesn't happen I pick it up. > The 0-day robot found a new build warning on openrisc. I was plannning > on submitting a v4 with this fix in it > >diff --git a/arch/openrisc/include/asm/irq.h > b/arch/openrisc/include/asm/irq.h >index d9eee0a2b7b4..eb612b1865d2 100644 >--- a/arch/openrisc/include/asm/irq.h >+++ b/arch/openrisc/include/asm/irq.h >@@ -24,6 +24,4 @@ >#define NO_IRQ (-1) > -extern void set_handle_irq(void (*handle_irq)(struct pt_regs *)); >- > #endif /* __ASM_OPENRISC_IRQ_H__ */ > > I can submit a v4, or you can just grab it from Just reply on the v3 openrisc patch with a v4 and I grab it from there. Thanks, tglx
Re: Make set_handle_irq and handle_arch_irq generic, v3
On Fri, 09 Mar 2018 02:20:12 PST (-0800), t...@linutronix.de wrote: On Wed, 7 Mar 2018, Palmer Dabbelt wrote: This is my third version of this patch set, but the original cover letter is still the most relevant description I can come up with. This patch set has been sitting around for a while, but it got a bit lost in the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point for interrupt handling) to our first-level interrupt controller. While this isn't completely crazy (as the first-level interrupt controller is specified by the ISA), it is a bit awkward. This patch set decouples our trap handler from our first-level IRQ chip driver by copying what a handful of other architectures are doing. This does add an additional load to the interrupt handling path, but there's a handful of performance problems in there that I've been meaning to look at so I don't mind adding another one for now. The advantage is that our irqchip driver is decoupled from our arch port, at least at compile time. I've build tested this with defconfigs on all the modified architectures after both patch 1 and 5. I've left the old acks in for the later patches as the patch set has changed very little since I last submitted it. This looks sensible. We have two options for getting this merged: 1) I'll take the whole lot through tip/irq/core 2) I'll apply patch 1/N to a special branch in tip. That branch will contain only this commit on top of 4.16-rc4 and can be pulled by the relevant architecture maintainers, so they can apply their architecture specific patches. Option 1 seems like the lowest overhead, as that way we don't need to sequence the patches between multiple trees. If all the other arch maintianers are OK with it then that works for me. The 0-day robot found a new build warning on openrisc. I was plannning on submitting a v4 with this fix in it diff --git a/arch/openrisc/include/asm/irq.h b/arch/openrisc/include/asm/irq.h index d9eee0a2b7b4..eb612b1865d2 100644 --- a/arch/openrisc/include/asm/irq.h +++ b/arch/openrisc/include/asm/irq.h @@ -24,6 +24,4 @@ #define NO_IRQ (-1) -extern void set_handle_irq(void (*handle_irq)(struct pt_regs *)); - #endif /* __ASM_OPENRISC_IRQ_H__ */ I can submit a v4, or you can just grab it from https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=review-irq-1-cleanup Thanks!
Re: Make set_handle_irq and handle_arch_irq generic, v3
On Wed, 7 Mar 2018, Palmer Dabbelt wrote: > This is my third version of this patch set, but the original cover > letter is still the most relevant description I can come up with. > > This patch set has been sitting around for a while, but it got a bit lost > in the shuffle. In RISC-V land we currently couple do_IRQ (the C entry > point for interrupt handling) to our first-level interrupt controller. > While this isn't completely crazy (as the first-level interrupt controller > is specified by the ISA), it is a bit awkward. > > This patch set decouples our trap handler from our first-level IRQ chip > driver by copying what a handful of other architectures are doing. This > does add an additional load to the interrupt handling path, but there's a > handful of performance problems in there that I've been meaning to look at > so I don't mind adding another one for now. The advantage is that our > irqchip driver is decoupled from our arch port, at least at compile time. > > I've build tested this with defconfigs on all the modified architectures > after both patch 1 and 5. I've left the old acks in for the later > patches as the patch set has changed very little since I last submitted > it. This looks sensible. We have two options for getting this merged: 1) I'll take the whole lot through tip/irq/core 2) I'll apply patch 1/N to a special branch in tip. That branch will contain only this commit on top of 4.16-rc4 and can be pulled by the relevant architecture maintainers, so they can apply their architecture specific patches. Please let me know how you want to proceed. Thanks, tglx
Make set_handle_irq and handle_arch_irq generic, v3
This is my third version of this patch set, but the original cover letter is still the most relevant description I can come up with. This patch set has been sitting around for a while, but it got a bit lost in the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point for interrupt handling) to our first-level interrupt controller. While this isn't completely crazy (as the first-level interrupt controller is specified by the ISA), it is a bit awkward. This patch set decouples our trap handler from our first-level IRQ chip driver by copying what a handful of other architectures are doing. This does add an additional load to the interrupt handling path, but there's a handful of performance problems in there that I've been meaning to look at so I don't mind adding another one for now. The advantage is that our irqchip driver is decoupled from our arch port, at least at compile time. I've build tested this with defconfigs on all the modified architectures after both patch 1 and 5. I've left the old acks in for the later patches as the patch set has changed very little since I last submitted it. Changes since v2: * This is now called CONFIG_GENERIC_IRQ_MULTI_HANDLER instead of MULTI_IRQ_HANDLER. * Rather than converting the ARM code to generic code, this adds new generic code (based on the ARM implementation) and then provides separate patches to convert each architecture over to use CONFIG_GENERIC_IRQ_MULTI_HANDLER. Changes since v1: * I based this on arm instead of arm64, which means we guard the selection of these routines with CONFIG_MULTI_IRQ_HANDLER. * The changes are in kernel/irq/handle.c and include/linux/irq.h instead of lib. * I've converted the arm, arm64, and openrisc ports to use the generic versions of these routines. [PATCH v3 1/5] irq: Add CONFIG_GENERIC_IRQ_MULTI_HANDLER [PATCH v3 2/5] RISC-V: Move to the new GENERIC_IRQ_MULTI_HANDLER [PATCH v3 3/5] arm: Convert to GENERIC_IRQ_MULTI_HANDLER [PATCH v3 4/5] arm64: Use the new GENERIC_IRQ_MULTI_HANDLER [PATCH v3 5/5] openrisc: Use the new GENERIC_IRQ_MULTI_HANDLER
