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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D48AEE7FF4 for ; Mon, 11 Sep 2023 08:06:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231421AbjIKIGg (ORCPT ); Mon, 11 Sep 2023 04:06:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234892AbjIKIG0 (ORCPT ); Mon, 11 Sep 2023 04:06:26 -0400 Received: from Atcsqr.andestech.com (60-248-80-70.hinet-ip.hinet.net [60.248.80.70]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CB0310F6; Mon, 11 Sep 2023 01:06:08 -0700 (PDT) Received: from mail.andestech.com (ATCPCS16.andestech.com [10.0.1.222]) by Atcsqr.andestech.com with ESMTP id 38B856Gv066313; Mon, 11 Sep 2023 16:05:06 +0800 (+08) (envelope-from peterlin@andestech.com) Received: from APC323 (10.0.12.98) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.498.0; Mon, 11 Sep 2023 16:05:03 +0800 Date: Mon, 11 Sep 2023 16:04:59 +0800 From: Yu-Chien Peter Lin To: =?utf-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= CC: , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH 2/4] irqchip/riscv-intc: Support large non-standard hwirq number Message-ID: References: <20230907021635.1002738-1-peterlin@andestech.com> <20230907021635.1002738-3-peterlin@andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.10 (2023-03-25) X-Originating-IP: [10.0.12.98] X-DNSRBL: X-MAIL: Atcsqr.andestech.com 38B856Gv066313 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 07, 2023 at 12:22:55PM +0200, Clément Léger wrote: > > > On 07/09/2023 04:16, Yu Chien Peter Lin wrote: > > Currently, the implementation of the RISC-V INTC driver uses the > > interrupt cause as hwirq and has a limitation of supporting a > > maximum of 64 hwirqs. However, according to the privileged spec, > > interrupt cause >= 16 are defined for platform use. > > > > This limitation prevents us from fully utilizing the available > > local interrupt sources. Additionally, the hwirqs used on RISC-V > > are sparse, with only interrupt numbers 1, 5 and 9 (plus Sscofpmf > > or T-Head's PMU irq) being currently used for supervisor mode. > > > > The patch switches to using irq_domain_create_tree() which > > creates the radix tree map, allowing us to handle a larger > > number of hwirqs. > > > > Signed-off-by: Yu Chien Peter Lin > > Reviewed-by: Charles Ci-Jyun Wu > > Reviewed-by: Leo Yu-Chi Liang > > > > --- > > There are 3 hwirqs of local interrupt source exceed 64 defined in > > AX45MP datasheet [1] Table 56: AX45MP-1C scause Value After Trap: > > - 256+16 Slave port ECC error interrupt (S-mode) > > - 256+17 Bus write transaction error interrupt (S-mode) > > - 256+18 Performance monitor overflow interrupt(S-mode) > > > > [1] http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf > > --- > > drivers/irqchip/irq-riscv-intc.c | 10 ++++------ > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c > > index 4adeee1bc391..76e1229c45de 100644 > > --- a/drivers/irqchip/irq-riscv-intc.c > > +++ b/drivers/irqchip/irq-riscv-intc.c > > @@ -24,8 +24,8 @@ static asmlinkage void riscv_intc_irq(struct pt_regs *regs) > > { > > unsigned long cause = regs->cause & ~CAUSE_IRQ_FLAG; > > > > - if (unlikely(cause >= BITS_PER_LONG)) > > - panic("unexpected interrupt cause"); > > + if (!irq_find_mapping(intc_domain, cause)) > > + panic("unexpected interrupt cause: %ld", cause); > > Hi Yu, > > It seems like generic_handle_domain_irq() returns -EINVAL if provided > with NULL (which will happen if the interrupt does not have a mapping > due to __irq_resolve_mapping returning NULL) so maybe it is possible to > remove this check (since __irq_resolve_mapping() is also called by > generic_handle_domain_irq()) and panic if generic_handle_domain_irq() > returns -EINVAL ? That would avoid calling __irq_resolve_mapping() twice > for really rare cases. > > Clément Hi Clément, Thanks for catching this, will fix it in the patch v2. Best regards, Peter Lin