Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5315950pxb; Wed, 26 Jan 2022 09:15:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJyZKVu/InI+/DR7MKAfXdcsRS6Spk5Yeuqd3pVhmPIt+qRci9IgzI0QilDZ9g+SjfZ7DLLi X-Received: by 2002:a17:907:160d:: with SMTP id hb13mr9815244ejc.609.1643217351069; Wed, 26 Jan 2022 09:15:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643217351; cv=none; d=google.com; s=arc-20160816; b=aXeqdcivKh8ttQ+XL13zBj011CmDkvoBterAK5MrqzbCx7FcDJGQK/Qe4rkea0K8CQ JTMl7e8JUC70qgHCnO1YLDgHzDakXDQndIcNWxMYY4U2QLg7f7Z8bmmZQXlQ8R3smd+x ovcjk1NEY2hZszipBzXDQ3dRRWDPCr/Fr/3vnZSM7tCpisky1zgQomjWpMMZAFQEic/D GpZ9TstAY+N+e0G+6TYQWiUBauUdP/DxflQRRQZpTUZfsgUxcdXUt1gplyBn/zYHitdO NCbyCNGHO0ZVn9Pb3H4v/l/W+8OxfDml/NKElj3kkQFZ/8uNUgx7uX+KRkE2QuZRlMYm i3vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=pBMdlXBwnvmmPNUewfDMh0H5M/2d+zAT6/3Iwl0rMhQ=; b=t/pGPZmfVJqv97BY9cxYUTbtMzp/WNDA41HmCiwvIuHNf3ehdmYlVYoZXPNXBMnisW tQP240Ean5uqbTRTuW4eYQztdW5UOUu01ioZxvdNctkUXRh+vpdMwBrB3BW4tSmLCVd/ X34czGgLPm42VU/NpWuICVAXhxrB4xgbdc0KwHyhonbkVcn0OTtht8vv6gvTLRYBKXJt cEGl6AYFx5jqVSKSyPFH1EVmNxen6mbSlb13GPoW0kC2u4cJdPQSFI8kcPBeJpOLnfHC uxKAqe20OoMxTsS9AknnfhCq/lsAc8NczHqWUD3/mvrbkJ6ynWlgsdRUF7ZhGx7mpGeH yrEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=2hkCjLJX; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u8si12165628eds.8.2022.01.26.09.15.24; Wed, 26 Jan 2022 09:15:51 -0800 (PST) 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; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=2hkCjLJX; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236952AbiAZDRK (ORCPT + 99 others); Tue, 25 Jan 2022 22:17:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230339AbiAZDRJ (ORCPT ); Tue, 25 Jan 2022 22:17:09 -0500 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3892C06161C for ; Tue, 25 Jan 2022 19:17:08 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id c23so7620114wrb.5 for ; Tue, 25 Jan 2022 19:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainfault-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pBMdlXBwnvmmPNUewfDMh0H5M/2d+zAT6/3Iwl0rMhQ=; b=2hkCjLJXNAlhQ1LUkJt6pNjDvtjs2OnmxqENbtatgOTh31p8z+9Mqv0niYVwX/l8pk ClUB570vDbOr8k+Hx/Wv50Q3w8GihVLYUXdu+K/erHBbDgrId+MwHePcdsI5oxQelBYk f3QyqP/p8SIgane+7W7yUZJB5V5R28ZWAhfXrR5CihS0gmQIaBEZguge6Rb9RNaQpxbK eS8k3FKGThIhtR0JXPdSDOPVmHz6h+XMI8NOQQ5bhcn4hJBRxbTQOMTN/P0aGOFl500p 3hEq88NaviARy1N5+PY122QI+rKZ+PVwRH/cospStOzCn0Itee/z7g6P6Emn2HpJbfR+ fkcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pBMdlXBwnvmmPNUewfDMh0H5M/2d+zAT6/3Iwl0rMhQ=; b=mBsQom3HLdXRpDtZov0XZ66CERwvPCgSrIxk6YmZjNxltuJSDD/3oY3kbmgxILO1Qw XxC0sFB+StKAPlLLgsDB1S4ONEq2PNlArtmOmr2Q2EUiDjujje0d4bJuOmUc/rZqKYW5 VySVetUrC66Z48kSTOdom9FS8G7Ovbgwm3aPqJVhLhRLmN9BqAOVMM+7nIF+v1xuffOs aZGmv+OlVLnNTPh619c+vmSiXDbwe64NSpLuC8XKunZc4An1WhfXgSDu2eBip14rqoLM DxkXEgRzVCqd+4hZI98nQmM3EhdCdicYo8HKD9Fh14uaXj9fVS8rY06AOHfcpmgfJzjK UW4w== X-Gm-Message-State: AOAM530QApDDUdsPcEZ8kw1Hlnvaqwqghj/7yRqYf1KeCMCt+eqPYNyP DJ29DIgSvMz/gclHH9hfKx3PMfbzrB8Fq8YiHM14mQ== X-Received: by 2002:a5d:584e:: with SMTP id i14mr20897127wrf.690.1643167027245; Tue, 25 Jan 2022 19:17:07 -0800 (PST) MIME-Version: 1.0 References: <20220125054217.383482-1-apatel@ventanamicro.com> <20220125054217.383482-3-apatel@ventanamicro.com> <87lez37k8h.wl-maz@kernel.org> In-Reply-To: <87lez37k8h.wl-maz@kernel.org> From: Anup Patel Date: Wed, 26 Jan 2022 08:46:55 +0530 Message-ID: Subject: Re: [PATCH 2/6] irqchip/riscv-intc: Set intc domain as the default host To: Marc Zyngier Cc: Anup Patel , Palmer Dabbelt , Paul Walmsley , Thomas Gleixner , Daniel Lezcano , Rob Herring , Atish Patra , Alistair Francis , linux-riscv , "linux-kernel@vger.kernel.org List" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 25, 2022 at 11:47 PM Marc Zyngier wrote: > > On Tue, 25 Jan 2022 05:42:13 +0000, > Anup Patel wrote: > > > > We have quite a few RISC-V drivers (such as RISC-V SBI IPI driver, > > RISC-V timer driver, RISC-V PMU driver, etc) which do not have a > > dedicated DT/ACPI fwnode. This patch makes intc domain as the default > > host so that these drivers can directly create local interrupt mapping > > using standardized local interrupt numbers > > > > Signed-off-by: Anup Patel > > --- > > drivers/clocksource/timer-riscv.c | 17 +---------------- > > drivers/irqchip/irq-riscv-intc.c | 9 +++++++++ > > 2 files changed, 10 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c > > index 1767f8bf2013..dd6916ae6365 100644 > > --- a/drivers/clocksource/timer-riscv.c > > +++ b/drivers/clocksource/timer-riscv.c > > @@ -102,8 +102,6 @@ static irqreturn_t riscv_timer_interrupt(int irq, void *dev_id) > > static int __init riscv_timer_init_dt(struct device_node *n) > > { > > int cpuid, hartid, error; > > - struct device_node *child; > > - struct irq_domain *domain; > > > > hartid = riscv_of_processor_hartid(n); > > if (hartid < 0) { > > @@ -121,20 +119,7 @@ static int __init riscv_timer_init_dt(struct device_node *n) > > if (cpuid != smp_processor_id()) > > return 0; > > > > - domain = NULL; > > - child = of_get_compatible_child(n, "riscv,cpu-intc"); > > - if (!child) { > > - pr_err("Failed to find INTC node [%pOF]\n", n); > > - return -ENODEV; > > - } > > - domain = irq_find_host(child); > > - of_node_put(child); > > - if (!domain) { > > - pr_err("Failed to find IRQ domain for node [%pOF]\n", n); > > - return -ENODEV; > > - } > > - > > - riscv_clock_event_irq = irq_create_mapping(domain, RV_IRQ_TIMER); > > + riscv_clock_event_irq = irq_create_mapping(NULL, RV_IRQ_TIMER); > > if (!riscv_clock_event_irq) { > > pr_err("Failed to map timer interrupt for node [%pOF]\n", n); > > return -ENODEV; > > diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c > > index b65bd8878d4f..9f0a7a8a5c4d 100644 > > --- a/drivers/irqchip/irq-riscv-intc.c > > +++ b/drivers/irqchip/irq-riscv-intc.c > > @@ -125,6 +125,15 @@ static int __init riscv_intc_init(struct device_node *node, > > return rc; > > } > > > > + /* > > + * Make INTC as the default domain which will allow drivers > > + * not having dedicated DT/ACPI fwnode (such as RISC-V SBI IPI > > + * driver, RISC-V timer driver, RISC-V PMU driver, etc) can > > + * directly create local interrupt mapping using standardized > > + * local interrupt numbers. > > + */ > > + irq_set_default_host(intc_domain); > > No, please. This really is a bad idea. This sort of catch-all have > constantly proven to be a nuisance, because they discard all the > topology information. Eventually, you realise that you need to know > where this is coming from, but it really is too late. > > I'd rather you *synthesise* a fwnode (like ACPI does) rather then do > this. In absence of INTC as the default domain, currently we have various drivers looking up INTC irq_domain from DT (or ACPI). This is quite a bit of duplicate code across various drivers. How about having a irq_domain lookup routine (riscv_intc_find_irq_domain()) exported by the RISC-V INTC driver or arch/riscv ? OR Do you have an alternative suggestion ? Regards, Anup > > M. > > -- > Without deviation from the norm, progress is not possible.