linux-kernel - Re: [RFC PATCH v3 RESEND 02/13] irqchip/riscv-intc: Allow large non-standard hwirq number

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZT9XbuxE2vlvsfYG@APC323>
Date:   Mon, 30 Oct 2023 15:12:46 +0800
From:   Yu-Chien Peter Lin <peterlin@...estech.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     <acme@...nel.org>, <adrian.hunter@...el.com>,
        <ajones@...tanamicro.com>, <alexander.shishkin@...ux.intel.com>,
        <andre.przywara@....com>, <anup@...infault.org>,
        <aou@...s.berkeley.edu>, <atishp@...shpatra.org>,
        <conor+dt@...nel.org>, <conor.dooley@...rochip.com>,
        <conor@...nel.org>, <devicetree@...r.kernel.org>,
        <dminus@...estech.com>, <evan@...osinc.com>,
        <geert+renesas@...der.be>, <guoren@...nel.org>, <heiko@...ech.de>,
        <irogers@...gle.com>, <jernej.skrabec@...il.com>,
        <jolsa@...nel.org>, <jszhang@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-perf-users@...r.kernel.org>,
        <linux-renesas-soc@...r.kernel.org>,
        <linux-riscv@...ts.infradead.org>, <linux-sunxi@...ts.linux.dev>,
        <locus84@...estech.com>, <magnus.damm@...il.com>,
        <mark.rutland@....com>, <mingo@...hat.com>, <n.shubin@...ro.com>,
        <namhyung@...nel.org>, <palmer@...belt.com>,
        <paul.walmsley@...ive.com>, <peterz@...radead.org>,
        <prabhakar.mahadev-lad.rj@...renesas.com>, <rdunlap@...radead.org>,
        <robh+dt@...nel.org>, <samuel@...lland.org>,
        <sunilvl@...tanamicro.com>, <tim609@...estech.com>,
        <uwu@...nowy.me>, <wens@...e.org>, <will@...nel.org>,
        <ycliang@...estech.com>
Subject: Re: [RFC PATCH v3 RESEND 02/13] irqchip/riscv-intc: Allow large
 non-standard hwirq number

Hi Thomas,

Thanks for the review.

On Fri, Oct 27, 2023 at 09:12:59AM +0200, Thomas Gleixner wrote:
> On Mon, Oct 23 2023 at 08:40, 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 causes >= 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
> 
> git grep "This patch" Documentation/process/

Sure, will fix.

> > creates the radix tree map, allowing us to handle a larger
> > number of hwirqs.
> 
> Who is 'us'? We are not part of the chip and please write out 'hardware
> interrupts'

OK!

> > @@ -24,10 +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");
> > -
> > -	generic_handle_domain_irq(intc_domain, cause);
> > +	if (generic_handle_domain_irq(intc_domain, cause))
> > +		pr_warn("Failed to handle interrupt (cause: %ld)\n", cause);
> 
> pr_warn_once() or at least pr_warn_ratelimited().

OK!

> >  }
> >  
> >  /*
> > @@ -117,8 +115,8 @@ 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);
> > +	intc_domain = irq_domain_create_tree(fn, &riscv_intc_domain_ops,
> > +					     NULL);
> 
> Put it into one line. Linebreaking arguments is really only required
> when the line length is exceedingly long. This one is not.

OK! will fix.

Thanks,
Peter Lin