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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id CC008C636CC for ; Tue, 31 Jan 2023 09:11:28 +0000 (UTC) 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ssegc3OiGglXoeJO2GgPsccHt8w0eJ792NoSU190oyw=; b=mcnkz/ihsjjwFp eFB2aMhAVKD+16XsRf2T5wMt7FQgjI9JHPgpwtcGV6SOHDnJ2qPwPWosidsIkGGRtNhxai4pH6esn Xzj5qDGDp4O6iF6d7VaFA63zMGgoYtjMCMUwDuGruXwJ8Bc/1rNx6v++8unpAy3njtN4BYfFGFVsJ SCfkaUKJbhYrOU+N/rguymqHKapm+qukK2ysy8Re6aYJ856p/9WOUOyXIHTyhFkKU/OvyVLYNJfjq WP/1u24Ahis0kugbwVDIpevY4Vn/01dC1Fx3E/jzGyLZmKsmh01TopKaMQ7RgtjaLQoyM1CJfdoVA +XdakUglluOMnjaHFDRg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMmff-006vIz-47; Tue, 31 Jan 2023 09:11:19 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMmfZ-006vFH-8X for linux-riscv@lists.infradead.org; Tue, 31 Jan 2023 09:11:16 +0000 Received: by mail-pg1-x535.google.com with SMTP id e10so9567669pgc.9 for ; Tue, 31 Jan 2023 01:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+G7LKm94Gh8IveRXkVxzmqetNifcC6zGcwfVmKZiIxU=; b=eqXSbhCEC9s02q8nHxUEus2+H/2Y0rvRKIp9bmt9yZfTuOssg1+p7nndjt2NON5wIW 0/xDxXb9svWhNEqPLB2Rkr2XW12YJIgZLHJUxwc0oD+YaTcloroWP2GQkUwK+y+rcFij yzwEDLuRbzZv/qbhS6M4i67X+ja+AFpECod3dAEHZNGXfwqFJdUtRuZEqhVKkIh/jbTc u5WZQInCjtsSmScQ182N0Rn8PUceGOmZ46ulxNvHkMWH9xtNpDxiA8fFGaKzebqxW9LB KgY3T9Sy1JDPUittTemk7HZycvL7LywHjj+jk2cmQYG6Qc22WgvPMX58TH4Hixxm7rrQ 6aJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+G7LKm94Gh8IveRXkVxzmqetNifcC6zGcwfVmKZiIxU=; b=43hLejbhhrL1WAs3ZoMYwmhQ6Ixwmn7cSFIoLvROtsKMpO5EybfREpweWmNm40kiLR SGPbrQ8jl42sbRcUJxXRLcb+6T3tHtJipw7UEcBrnmNH6DAzLy7/ruL93+XHQp7xpX+U U97q5Xyue60hgOECkdTp4fyUDJeZqK/JTnsfcG/D05ifg6hbRRacLXG2W8gE9/PI6nLy i166tiUyokdPWqxXVLWrsxarENs7PLiDqg0wPVQBOCHG9cqWb/KoZcGpGGbLelf3G63+ n/nt4vyvL4vH2PBleJ1oPGcC/KAAv8DbPc5GR9/vrTZmYxJeT8yYTT1tt5w8/mVoLCHk mKFw== X-Gm-Message-State: AO0yUKVUOGyOmP9uNRBfV1HvW81h46E8jNhoLTUwIrTT0iytf8l9fgNC 9UlubD9W+m581ocAMrnh+WASCQ== X-Google-Smtp-Source: AK7set9Wno7a0XYRFhzJYb6jckFGgD3MgmlKDmdJYnMg7BAjHupX6GqxvIMpR9adRETeVxpQn4ox6A== X-Received: by 2002:a05:6a00:1483:b0:592:61a5:40 with SMTP id v3-20020a056a00148300b0059261a50040mr15751149pfu.16.1675156269503; Tue, 31 Jan 2023 01:11:09 -0800 (PST) Received: from sunil-laptop ([49.206.9.96]) by smtp.gmail.com with ESMTPSA id bt26-20020a056a00439a00b0058a7bacd31fsm6540587pfb.32.2023.01.31.01.11.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Jan 2023 01:11:09 -0800 (PST) Date: Tue, 31 Jan 2023 14:41:00 +0530 From: Sunil V L To: Jessica Clarke Cc: Palmer Dabbelt , Albert Ou , "Rafael J . Wysocki" , Len Brown , Thomas Gleixner , Marc Zyngier , Daniel Lezcano , Jonathan Corbet , Anup Patel , linux-doc@vger.kernel.org, Atish Patra , Linux Kernel Mailing List , linux-acpi@vger.kernel.org, linux-riscv@lists.infradead.org, Andrew Jones Subject: Re: [PATCH 11/24] RISC-V: ACPI: irqchip/riscv-intc: Add ACPI support Message-ID: References: <20230130182225.2471414-1-sunilvl@ventanamicro.com> <20230130182225.2471414-12-sunilvl@ventanamicro.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230131_011113_337590_35658418 X-CRM114-Status: GOOD ( 30.09 ) X-BeenThere: linux-riscv@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-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org Hi Jessica, On Mon, Jan 30, 2023 at 11:38:49PM +0000, Jessica Clarke wrote: > On 30 Jan 2023, at 18:22, Sunil V L wrote: > > > > Add support for initializing the RISC-V INTC driver on ACPI based > > platforms. > > > > Signed-off-by: Sunil V L > > --- > > drivers/irqchip/irq-riscv-intc.c | 79 +++++++++++++++++++++++++++----- > > 1 file changed, 67 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c > > index f229e3e66387..044ec92fcba7 100644 > > --- a/drivers/irqchip/irq-riscv-intc.c > > +++ b/drivers/irqchip/irq-riscv-intc.c > > @@ -6,6 +6,7 @@ > > */ > > > > #define pr_fmt(fmt) "riscv-intc: " fmt > > +#include > > #include > > #include > > #include > > @@ -112,6 +113,30 @@ static struct fwnode_handle *riscv_intc_hwnode(void) > > return intc_domain->fwnode; > > } > > > > +static int __init riscv_intc_init_common(struct fwnode_handle *fn) > > +{ > > + int rc; > > + > > + intc_domain = irq_domain_create_linear(fn, BITS_PER_LONG, > > + &riscv_intc_domain_ops, NULL); > > + if (!intc_domain) { > > + pr_err("unable to add IRQ domain\n"); > > + return -ENXIO; > > + } > > + > > + rc = set_handle_irq(&riscv_intc_irq); > > + if (rc) { > > + pr_err("failed to set irq handler\n"); > > + return rc; > > + } > > + > > + riscv_set_intc_hwnode_fn(riscv_intc_hwnode); > > + > > + pr_info("%d local interrupts mapped\n", BITS_PER_LONG); > > + > > + return 0; > > +} > > + > > static int __init riscv_intc_init(struct device_node *node, > > struct device_node *parent) > > { > > @@ -133,24 +158,54 @@ static int __init riscv_intc_init(struct device_node *node, > > if (riscv_hartid_to_cpuid(hartid) != smp_processor_id()) > > return 0; > > > > - intc_domain = irq_domain_add_linear(node, BITS_PER_LONG, > > - &riscv_intc_domain_ops, NULL); > > - if (!intc_domain) { > > - pr_err("unable to add IRQ domain\n"); > > - return -ENXIO; > > - } > > - > > - rc = set_handle_irq(&riscv_intc_irq); > > + rc = riscv_intc_init_common(of_node_to_fwnode(node)); > > if (rc) { > > - pr_err("failed to set irq handler\n"); > > + pr_err("failed to initialize INTC\n"); > > return rc; > > } > > > > - riscv_set_intc_hwnode_fn(riscv_intc_hwnode); > > + return 0; > > +} > > > > - pr_info("%d local interrupts mapped\n", BITS_PER_LONG); > > +IRQCHIP_DECLARE(riscv, "riscv,cpu-intc", riscv_intc_init); > > + > > +#ifdef CONFIG_ACPI > > + > > +static int __init > > +riscv_intc_acpi_init(union acpi_subtable_headers *header, > > + const unsigned long end) > > +{ > > + int rc; > > + struct fwnode_handle *fn; > > + struct acpi_madt_rintc *rintc; > > + > > + rintc = (struct acpi_madt_rintc *)header; > > + > > + /* > > + * The ACPI MADT will have one INTC for each CPU (or HART) > > + * so riscv_intc_acpi_init() function will be called once > > + * for each INTC. We only need to do INTC initialization > > + * for the INTC belonging to the boot CPU (or boot HART). > > + */ > > + if (riscv_hartid_to_cpuid(rintc->hart_id) != smp_processor_id()) > > + return 0; > > Why are we carrying forward this mess to ACPI? The DT bindings are > awful and a complete pain to deal with, as evidenced by how both Linux > and FreeBSD have to go out of their way to do special things to only > look at one of the many copies of the same thing. > Local interrupt controller structures are per-cpu in any architecture. So, there will be multiple such structures. It is upto the OS to choose one of them. What is the issue here? The RISC-V DT code is selecting the one which is corresponding to the boot cpu. While in ACPI we can choose any one, I think it is better to follow the DT code to keep it similar and boot cpu is always guaranteed to be available. Thanks! Sunil _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv