Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3533867pxj; Tue, 1 Jun 2021 07:30:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhl+D5HJz6+UzKNPcDnGv/zGr2/nKxkX/BDsESU7TZvOD84Wuum90B232Lz9kJ9zTEaZJc X-Received: by 2002:a05:6e02:1c87:: with SMTP id w7mr22751805ill.25.1622557826896; Tue, 01 Jun 2021 07:30:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622557826; cv=none; d=google.com; s=arc-20160816; b=tocnBSI7mP874HmY62LFazI5OwCj5MskWbhxvCq4D/Bp7oC6aKvHYt+Mnn9ScwZebx sa35+7ubiq7/OSargO+zUj3BEdmLQvSm/1slcJ6cKERgvtTqimBFVmC5Uf+/oukweCT5 aMSAEVTBlFLz43b5V5aWhbmrzRC41KmC2mQiMvEbj613GQr+Ng7OAnfdVvBosaMnF7xy b6cTBgOaSjgW49iVHP4OSUwvqYdaAajSR1bXVvmaZqWhMQD9ijwY/2SNgbxiqdKLBAzv Uto91Ru6MibBnNSNJcdvwGLeBIwyBi6Q6i/JuZOI29QJ377aisLhfb/Tw8xlBNT0tMVF X0aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=sEa1LDEV7tOolEdFPL2qwZEDjxR3mQTnhEGJj1+XQK8=; b=uTuh18iNgouqCFY17rKo+p1aZdTSZI5PwINNyuXd6hmpYldGvb4Rb+v8ziE9n8XeLs piUryEn5Ee34RbrI0m1Jh3H3RDN13pmcBaBrY5dRR70R3I24HRum8Ndf20TyGumkRUkg OPLqieIqMC3YtXWGoBmXPYLDxCiV3SieM/4J+ahXTKeeO+ySviw/rlXj8a1Fqsu6RTWU Wk2Wh7JNhs0wH59Z7GSnKdzwPRNMOvzu51Lu53SEwP8xD7FNtCx78thYcALNrKauP9Xb zTUN3nYWmS789Mm6C2RDnJ/uou8C5UttVge9cBbIJFz5GoLzQbUygmuzD/scU8PEZ0U2 sJgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c15si9963431iln.17.2021.06.01.07.30.12; Tue, 01 Jun 2021 07:30:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234066AbhFAOa7 (ORCPT + 99 others); Tue, 1 Jun 2021 10:30:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:49542 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233797AbhFAOa7 (ORCPT ); Tue, 1 Jun 2021 10:30:59 -0400 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 EA72261209; Tue, 1 Jun 2021 14:29:17 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] 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 1lo5ON-004puP-Ra; Tue, 01 Jun 2021 15:29:15 +0100 Date: Tue, 01 Jun 2021 15:29:14 +0100 Message-ID: <87lf7t1ww5.wl-maz@kernel.org> From: Marc Zyngier To: linux-kernel@vger.kernel.org Cc: Thomas Gleixner , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Ley Foon Tan , Chris Zankel , Max Filippov , Vineet Gupta , Thomas Bogendoerfer , Robert Jarzmik , Russell King , Krzysztof Kozlowski , Yoshinori Sato , Rich Felker , Geert Uytterhoeven , Alex Deucher , Christian =?UTF-8?B?S8O2bmln?= , David Airlie , Daniel Vetter , Rob Clark , Linus Walleij , Lee Jones , Lorenzo Pieralisi , Rob Herring , Bjorn Helgaas , Bartosz Golaszewski , kernel-team@android.com Subject: Re: [PATCH 00/39] irqdomain: Simplify interrupt handling In-Reply-To: <20210520163751.27325-1-maz@kernel.org> References: <20210520163751.27325-1-maz@kernel.org> 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") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: linux-kernel@vger.kernel.org, tglx@linutronix.de, mpe@ellerman.id.au, benh@kernel.crashing.org, paulus@samba.org, ley.foon.tan@intel.com, chris@zankel.net, jcmvbkbc@gmail.com, vgupta@synopsys.com, tsbogend@alpha.franken.de, robert.jarzmik@free.fr, linux@armlinux.org.uk, krzysztof.kozlowski@canonical.com, ysato@users.sourceforge.jp, dalias@libc.org, geert@linux-m68k.org, alexander.deucher@amd.com, christian.koenig@amd.com, airlied@linux.ie, daniel@ffwll.ch, robdclark@gmail.com, linus.walleij@linaro.org, lee.jones@linaro.org, lorenzo.pieralisi@arm.com, robh@kernel.org, bhelgaas@google.com, bgolaszewski@baylibre.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 20 May 2021 17:37:12 +0100, Marc Zyngier wrote: > > Although most device drivers only deal with an interrupt number, the > core IRQ code is mostly concerned with the irq_desc structure that > describes the full interrupt context (hierarchy, handlers, state). > > However, the low-level interrupt handling code that relies on the > irqdomain abstraction has to perform an annoying dance to eventually > get the core code to invoke interrupt handlers: the irqdomain code > converts a low-level identifier to the unique Linux interrupt number, > and the core code resolves this into an irq_desc pointer. > > Each of these two lookups ends-up parsing a radix tree (although the > irqdomain code can use a linear mapping for the smallest domains), > which is obviously one too many. Wouldn't it be nice if the irqdomain > would cache the irq_desc instead of forcing the core code to look it > up on each and every interrupt? This is what this long series is all > about. > > There is roughly 3 parts here: > > - a substantial amount of massaging for some architectures (nios, mips > and powerpc) to disentangle weird include constructs (asm/irq.h > including linux/irqdomain.h is pretty bad...) and simplify bits of > the irqdomain code > > - some rework of the irqdomain code to allow the caching of a irq_data > pointer, unify the RCU behaviour and offer new APIs. > > - Perform a bulk of conversions that turn constructs similar to > generic_handle_irq(irq_find_mapping(domain, hwirq)) into a simpler > call to generic_handle_domain_irq(domain, hwirq). Yes, this is a > mouthful. > > I've kept most of the conversions per-subsystem/per-arch in order to > keep the number of patches low (though it is debatable whether I have > succeeded). > > This ends up with a negative diffstat, so it can't be completely bad! > Given the breadth of the changes, I do expect some breakage, although > I've extensively compile-tested it and the kbuild robot has been > invaluable in helping with the coverage. Slight nudge in the direction of the cc'd arch maintainers. I'd like to take the core of this series into -next (in practice, patches #1 through to #27). Any comment on the early, arch-specific patches would be most welcome. Thanks, M. -- Without deviation from the norm, progress is not possible.