Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5477071pxb; Wed, 26 Jan 2022 12:58:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJzcMKAcBl/+ChcIRlnHPUdEGPcJzX+wR5XnpHv41Ryjo8R9pNkUbQFOp1v27zKUVRaPy9MD X-Received: by 2002:a05:6a00:1828:: with SMTP id y40mr230139pfa.15.1643230703555; Wed, 26 Jan 2022 12:58:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643230703; cv=none; d=google.com; s=arc-20160816; b=kkmL9bwvfwVL2T5E028XzqRG9bgvGiz/qg7dNlBK1Fk/FgYWI8hbXOwjcfW4+0Jm8w iPL5SBqOYL6mRoax+QiUVMnAYb8d1/uluPFYTpwi9KiSUxsNtBUOsXkWKJX9+WdoZG8n Ph6qLK20oXwFh2oPHYyuoPhDrFdxBoaekfb2rbQR9cgk7EVKxZ+O8j9LnTHVXKysYiiq h5pYi25rRKijLmzCEB5SzBQ/kTw2NKe3UD5Fyp4Rxqg63hVrhLveWyjgPUcQ08POjvgm ths8m93v5nvkVz9F7FAmRDbgX2xCUqprWcKJn1ctOug3GZSXV8p8cb9kesR3ld6wOLm/ DtVw== 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=xq4i7DaguI8skryThxdNyfbFk29T5RJk2Ad5MDxqB7I=; b=nTULeRB6s2TCLtpGs06MEdgX8XArez6lpbAV/ETuo/u+jn82H8ZOeMCsyfut6Vz0z6 QfkQb/p53ILvCK+175IHWaCdRTmwxemPUFSzNxF1fBuGmN6UsIvN7fbD26dKWCzrR92i cl5K0xjJzMOIuhEMqiCY5lY2si2J5Q6V4sNoduWa4ZOchd/vFsKavMLtyRkI7jwTW3as k02twbSxtd8uMQeDac/9c1PQgAoVQk+nmzQ/SqsRYE/w8nSt/moWkZSALkexg3Vo6Ta+ kvvocNha+7z/MtZ13Y3anWhkwIZgyT8Rxhk4btYE1nEm0q0BfdysoJPP9Wh5gcdYKEId oDwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=milU7saK; 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 207si268713pgb.834.2022.01.26.12.58.11; Wed, 26 Jan 2022 12:58:23 -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=@ventanamicro.com header.s=google header.b=milU7saK; 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 S239687AbiAZKMp (ORCPT + 99 others); Wed, 26 Jan 2022 05:12:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229501AbiAZKMj (ORCPT ); Wed, 26 Jan 2022 05:12:39 -0500 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1CB7C06161C for ; Wed, 26 Jan 2022 02:12:38 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id 23so69779096ybf.7 for ; Wed, 26 Jan 2022 02:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xq4i7DaguI8skryThxdNyfbFk29T5RJk2Ad5MDxqB7I=; b=milU7saKVSeEnF8Dd701ScG1KT6mxQszuXSl/LP/kq5bhLWsfITbUDXTUxAJHrzKrK cgWMcSNz/HW3fUrikdI+A5l+P9z4SVf2GY7bQF6/h+yYibdr0PtfwbWS/odr0oBRq9iJ BcSOt6CdZAscRBAPKJG61k2Jd91eJ9Bq5f4cuJLuGxpYsd9nonrWE0PlhFQTwgxrSaSF Zdm8hU7F3iix02FigaL0oYpDOQd+xck9KlxciRQP1wZH4tZnlzOKzjKiRD7jpkuAU9MO j9GaNJ4LS3GKP8iLiw5ZjrT2AT93QtnZSGxncvk3uBeAKesugfh8/bV6JQdEuWy4qSEk 71Mw== 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=xq4i7DaguI8skryThxdNyfbFk29T5RJk2Ad5MDxqB7I=; b=sZ2+cCtbgmzTIeukHD/aBvzUXcLbPQbZMPXGZw0MthNWkM3i92mVwr2jfl8eXJGQhJ ORTERgzrPm5/vFJFAuWPlhxCw3nMg7R6czJVdLIH1+1bZUFapJyO2/kCk9mrtC6B5OZB lGIlnU3rEUN01ZphYQXftXJZ2Fe6kTQR7El7dcBBCfFr0QGqRtmgxB5gUiggzNqebKvJ HCcVK4t6cfyMMh3KsfK4TXLDoA/S0tRUJwClynugbIKHMm3j5w3LwBRGuc2V4VzWJ3jH 4MHYkCnwryldaF7tR9I44ygxNptdjTBcXf12znaCqmOsBrwzEEIVUUds0yn+Lv2MGq8b lJ4A== X-Gm-Message-State: AOAM532ptqWr1woD/aiae6lYV49Wz9Q7D+WWkk6LZeUpPfCPHXlC3Izh gnaSN9T1sUISUIGVbcFv/eM+OtWy/MEXO0fXe7IK0A== X-Received: by 2002:a25:cb47:: with SMTP id b68mr34928976ybg.397.1643191957973; Wed, 26 Jan 2022 02:12:37 -0800 (PST) MIME-Version: 1.0 References: <20220125054217.383482-1-apatel@ventanamicro.com> <20220125054217.383482-3-apatel@ventanamicro.com> <87lez37k8h.wl-maz@kernel.org> <87ilu67tvw.wl-maz@kernel.org> In-Reply-To: <87ilu67tvw.wl-maz@kernel.org> From: Anup Patel Date: Wed, 26 Jan 2022 15:42:25 +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 Wed, Jan 26, 2022 at 2:31 PM Marc Zyngier wrote: > > On Wed, 26 Jan 2022 03:16:55 +0000, > Anup Patel wrote: > > > > 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 ? > > But *why* don't you provide an interrupt controller node for DT? I > really don't think that's outlandish to require. Historically, all RISC-V SBI related drivers never had any DT/ACPI node because we can always query/discover the SBI functionality at runtime. The mechanism to query/discover SBI IPI, Timer and PMU is through SBI base functions. Also, local interrupts used by these drivers are specified by the RISC-V specification. This means having a DT/ACPI node for these drivers doesn't provide any info. We will be having KVM RISC-V AIA support in future which will not have a DT/ACPI node as well because this can be discovered as a CPU capability and the local interrupt to be used is specified by the RISC-V hypervisor specification. > > For ACPI, we already have an interface that allows a fwnode to be > registered (acpi_set_irq_model) and interrupts mapped > (acpi_register_gsi). The ACPI specification being proposed for RISC-V does not have any details for SBI IPI, Timer, and PMU for the same reasons mentioned above. > > You should already have all the required tools you need. Are you okay if arch/riscv exports riscv_intc_find_irq_domain() ? OR Maybe export riscv_intc_find_irq_domain() from INTC driver ? Regards, Anup > > M. > > -- > Without deviation from the norm, progress is not possible.