From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BDC47C433F5 for ; Sat, 23 Oct 2021 16:08:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8049060551 for ; Sat, 23 Oct 2021 16:08:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8049060551 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JPAfBK0f7l3C+xqzF+rxLrqytIlx/QkzHljXfqNYNug=; b=VZxpTvMYqkdOay lJ3Afvf14SKYZIiXNarLYnExagNHJXqdqA4OsU88iXiClrSlWXqNSBKiT/DAi3hv2K2MggJck4c63 yAKFA6tFaAfkcAabw919tAwO4GA+t3+VDwaAA2o+6045EXXxg7WR9pqyxK6QOpTvkitAW28CVm6/y huxHQUDwFnVtnFmrrafEU04a41TWVsLpaUczwrxoNzXfdoaMYPfW0jWHxIlGCgm7O6qfSgdEUxZVB yMwlIS7NdFxnSn28mKFlSlhkLJETPwHbDB6GVXp9EoPEexmoiBysd3FS4xFyUgaQuy/MSGTfDkaBB 1yJjCdnqs/ywuLIcTPew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1meJXz-00CviO-Vq; Sat, 23 Oct 2021 16:07:04 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1meJXw-00Cvhg-P0 for linux-arm-kernel@lists.infradead.org; Sat, 23 Oct 2021 16:07:02 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 709236101D; Sat, 23 Oct 2021 16:07:00 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1meJXu-00169Q-6q; Sat, 23 Oct 2021 17:06:58 +0100 Date: Sat, 23 Oct 2021 17:06:57 +0100 Message-ID: <87h7d7bu8u.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, aou@eecs.berkeley.edu, catalin.marinas@arm.com, deanbo422@gmail.com, green.hu@gmail.com, guoren@kernel.org, jonas@southpole.se, kernelfans@gmail.com, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, nickhu@andestech.com, palmer@dabbelt.com, paulmck@kernel.org, paul.walmsley@sifive.com, peterz@infradead.org, shorne@gmail.com, stefan.kristiansson@saunalahti.fi, torvalds@linux-foundation.org, tsbogend@alpha.franken.de, vgupta@kernel.org, will@kernel.org Subject: Re: [PATCH 00/15] irq: remove handle_domain_{irq,nmi}() In-Reply-To: <20211022151007.GD86184@C02TD0UTHF1T.local> References: <20211021180236.37428-1-mark.rutland@arm.com> <87k0i5b91c.wl-maz@kernel.org> <20211022151007.GD86184@C02TD0UTHF1T.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: mark.rutland@arm.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, aou@eecs.berkeley.edu, catalin.marinas@arm.com, deanbo422@gmail.com, green.hu@gmail.com, guoren@kernel.org, jonas@southpole.se, kernelfans@gmail.com, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, nickhu@andestech.com, palmer@dabbelt.com, paulmck@kernel.org, paul.walmsley@sifive.com, peterz@infradead.org, shorne@gmail.com, stefan.kristiansson@saunalahti.fi, torvalds@linux-foundation.org, tsbogend@alpha.franken.de, vgupta@kernel.org, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211023_090700_884416_4F860B97 X-CRM114-Status: GOOD ( 35.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 22 Oct 2021 16:10:07 +0100, Mark Rutland wrote: > > On Fri, Oct 22, 2021 at 12:20:31PM +0100, Marc Zyngier wrote: > > Hi Mark, > > > > On Thu, 21 Oct 2021 19:02:21 +0100, > > Mark Rutland wrote: > > > > > > The handle_domain_{irq,nmi}() functions were oringally intended as a > > > convenience, but recent rework to entry code across the kernel tree has > > > demonstrated that they cause more pain than they're worth and prevent > > > architectures from being able to write robust entry code. > > > > > > This series reworks the irq code to remove them, handling the necessary > > > entry work consistently in entry code (be it architectural or generic). > > > > [...] > > > > Thanks for going through the pain of putting this together. The > > couple of nits I mentioned notwithstanding: > > > > Reviewed-by: Marc Zyngier > > Thanks! > > I've pushed out an updated version to my irq/handle-domain-irq branch > on kernel.org: > > git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git > > That has two new patches you suggested: > > * irq: mips: simplify bcm6345_l1_irq_handle() > * irq: unexport handle_irq_desc() > > ... which I did not add your Reviewed-by to in case the commit messages > are garbage or something like that. I quickly eyeballed the patches, and they look OK to me. Feel free to add my RB tag to them. > > > It'd be good to work out a merging strategy once this has seen a bit > > of testing. > > Conflict-wise, this merges near perfectly against next-20212022 aside > from a trivial conflict against arch/riscv/Kconfig: > > | [mark@lakrids:~/src/linux]% git merge irq/handle-domain-irq > | Auto-merging arch/riscv/kernel/entry.S > | Auto-merging arch/riscv/Kconfig > | CONFLICT (content): Merge conflict in arch/riscv/Kconfig > | Auto-merging arch/nds32/Kconfig > | Auto-merging arch/mips/Kconfig > | Auto-merging arch/csky/Kconfig > | Auto-merging arch/arm64/Kconfig > | Auto-merging arch/arm/mach-s3c/irq-s3c24xx.c > | Auto-merging arch/arm/kernel/entry-armv.S > | Auto-merging arch/arm/Kconfig > | Auto-merging arch/arc/Kconfig > | Automatic merge failed; fix conflicts and then commit the result. > | [mark@lakrids:~/src/linux]% git diff > | diff --cc arch/riscv/Kconfig > | index 77a088d0a7e9,353e28f5f849..000000000000 > | --- a/arch/riscv/Kconfig > | +++ b/arch/riscv/Kconfig > | @@@ -62,8 -62,6 +62,11 @@@ config RISC > | select GENERIC_SCHED_CLOCK > | select GENERIC_SMP_IDLE_THREAD > | select GENERIC_TIME_VSYSCALL if MMU && 64BIT > | ++<<<<<<< HEAD > | + select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO > | + select HANDLE_DOMAIN_IRQ > | ++======= > | ++>>>>>>> irq/handle-domain-irq > | select HAVE_ARCH_AUDITSYSCALL > | select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL > | select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL > > ... where the resolution is: > > | diff --cc arch/riscv/Kconfig > | index 77a088d0a7e9,353e28f5f849..000000000000 > | --- a/arch/riscv/Kconfig > | +++ b/arch/riscv/Kconfig > | @@@ -62,8 -62,6 +62,7 @@@ config RISC > | select GENERIC_SCHED_CLOCK > | select GENERIC_SMP_IDLE_THREAD > | select GENERIC_TIME_VSYSCALL if MMU && 64BIT > | + select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO > | - select HANDLE_DOMAIN_IRQ > | select HAVE_ARCH_AUDITSYSCALL > | select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL > | select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL > > ... so I reckon we're not set for major pain there unless something new > appears in arch code in the next few days. > > If we can get this onto a branch for linux-next ASAP, and if Linus is > happy with this having come together a little late, maybe we could queue > this in tip for v5.16, perhaps after -rc1 to let this soak, or waiting > to apply the final patch to make it easier to revert the arch changes if > needed? I'm happy to route it via the irqchip tree (and ultimately tip) if nobody objects (which also means getting Acks from the arch maintainers). The branch would thus see a bit of -next before being sent to Linus. > I'd like to avoid sitting on this for an entire cycle if possible. +1. M. -- 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