[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1806241513260.8650@nanos.tec.linutronix.de>
Date: Sun, 24 Jun 2018 15:15:25 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Palmer Dabbelt <palmer@...ive.com>
cc: linux@...linux.org.uk, catalin.marinas@....com,
will.deacon@....com, jonas@...thpole.se,
stefan.kristiansson@...nalahti.fi, shorne@...il.com,
jason@...edaemon.net, marc.zyngier@....com, arnd@...db.de,
keescook@...omium.org, vladimir.murzin@....com,
nicolas.pitre@...aro.org, jinb.park7@...il.com,
yamada.masahiro@...ionext.com, alexandre.belloni@...tlin.com,
gregkh@...uxfoundation.org, pombredanne@...b.com,
kstewart@...uxfoundation.org, jhogan@...nel.org,
mark.rutland@....com, ard.biesheuvel@...aro.org,
james.morse@....com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, openrisc@...ts.librecores.org
Subject: Re: Finish the GENERIC_IRQ_MULTI_HANDLER conversion
On Thu, 21 Jun 2018, Palmer Dabbelt wrote:
> A while ago I sent a patch set that adds a GENERIC_IRQ_MULTI_HANDLER,
> which is an exact copy of the existing IRQ_MULTI_HANDLER support in the
> arm port, which is being used unconditionally by arm64 and openrisc.
> GENERIC_IRQ_MULTI_HANDLER is currently being used by the RISC-V port. I
> managed to make a few mistakes in my original patch set and as a result
> my conversion of the other architectures of GENERIC_IRQ_MULTI_HANDLER
> was dropped.
>
> This patch set finishes up my original patch set by converting arm,
> arm64, and openrisc over to the new GENERIC_IRQ_MULTI_HANDLER support
> and then removing MULTI_IRQ_HANDLER as it's obselete.
>
> At the time I wrote this I gave it fairly extensive build testing, but
> went I recently rebased it I just tested the full patch set on arm,
> arm64, and openrisc defconfigs.
>
> Various flavors of this patch set have bounced around a few times
> before, but I'm calling this a whole new patch set as it builds on top
> of what was merged.
I'll take the whole pile through tip irq/core which probably makes the most
sense unless there are any objections from architecture maintainers.
Thanks,
tglx
Powered by blists - more mailing lists