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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87h5vy20o9.ffs@tglx>
Date: Thu, 16 Oct 2025 19:53:26 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Charles Mirabile <cmirabil@...hat.com>
Cc: Lucas Zampieri <lzampier@...hat.com>, linux-kernel@...r.kernel.org, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>,
 Samuel Holland <samuel.holland@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti
 <alex@...ti.fr>, Vivian Wang <dramforever@...e.com>,
 devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org, Zhang
 Xincheng <zhangxincheng@...rarisc.com>
Subject: Re: [PATCH v5 3/3] irqchip/plic: add support for UltraRISC DP1000 PLIC

On Thu, Oct 16 2025 at 12:52, Charles Mirabile wrote:
> On Thu, Oct 16, 2025 at 12:12 PM Thomas Gleixner <tglx@...utronix.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 :)