[PATCH v5 3/3] irqchip/plic: add support for UltraRISC DP1000 PLIC
Thomas Gleixner
tglx at linutronix.de
Thu Oct 16 10:53:26 PDT 2025
On Thu, Oct 16 2025 at 12:52, Charles Mirabile wrote:
> On Thu, Oct 16, 2025 at 12:12 PM Thomas Gleixner <tglx at 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 :)
More information about the linux-riscv
mailing list