Re: [PATCH v5 3/3] irqchip/plic: add support for UltraRISC DP1000 PLIC

From: Thomas Gleixner <tglx@linutronix.de>
To: Charles Mirabile <cmirabil@redhat.com>
Cc: Lucas Zampieri <lzampier@redhat.com>,
	linux-kernel@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Samuel Holland <samuel.holland@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Vivian Wang <dramforever@live.com>,
	devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
	Zhang Xincheng <zhangxincheng@ultrarisc.com>
Subject: Re: [PATCH v5 3/3] irqchip/plic: add support for UltraRISC DP1000 PLIC
Date: Thu, 16 Oct 2025 19:53:26 +0200	[thread overview]
Message-ID: <87h5vy20o9.ffs@tglx> (raw)
In-Reply-To: <CABe3_aH3YE9wWonH1j09-eCarhzhhRReNAOwmEMs5YjkOvvoiQ@mail.gmail.com>

On Thu, Oct 16 2025 at 12:52, Charles Mirabile wrote:
> On Thu, Oct 16, 2025 at 12:12 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> >>         bit = ffs(pending) - 1;
>> >>         handler->enabled_clear[group] |= BIT(bit);
>> >>         for (int i = 0; i < nr_irq_groups; i++)
>> >>                 writel_relaxed(handler->enabled_clear[i], enable + i * sizeof(u32));
>> >>         handler->enabled_clear[group] = 0;
>> >>
>> >> No?
>> >
>> > Sure that would also work, but why are we using ffs (slow) only to
>> > shift the result back to make a new mask when (x & -x) is faster and
>> > skips the intermediate step delivering immediately the mask of the
>> > lowest bit.
>>
>> Because I did not spend time thinking about it.
>
> Sorry, did you mean "because I had not considered the original
> approach carefully enough" or "because this other approach, while
> slower, is more self evidently correct."

I did not think about x & -x :)

>> It's a pointer in struct plic_handler (or whatever it's named) and you
>> can allocate it when the quirk is required. The pointer is definitely
>> not a burden for anyone else.
>
> This I still don't understand how this is particuarly helpful. Since
> we are doing mmio, this is going to be an explicit loop and not a
> memcpy. The code is branchless in either case (set equal for the check
> of i against j negate and and with mask before loading into the mmio).

Fair enough. I did not think in RISC ASM :)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv