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]
Date:   Fri, 27 Oct 2023 10:01:12 +0530
From:   Anup Patel <>
To:     Thomas Gleixner <>
Cc:     Björn Töpel <>,
        Anup Patel <>,
        Björn Töpel <>,,,, Marc Zyngier <>
Subject: Re: [RFC PATCH] genirq/matrix: Dynamic bitmap allocation

Hi Thomas,

On Fri, Oct 27, 2023 at 4:47 AM Thomas Gleixner <> wrote:
> On Thu, Oct 26 2023 at 19:26, Björn Töpel wrote:
> > Note that the per-device domain support is already upstream, it's only
> > the ARM cleanups that are not.
> >
> > IOW, there's no need to wait for the ARM cleanups. :-)
> Correct. The &*@^@#%$ delayed ARM link was only meant as a reference on
> how this is implemented and obviously as a reminder to the ARM folks to
> get this finally done...
> The main point is not to introduce new users of this failed programming
> model and instead make them use the more future proof implementation
> right away - which of course might to turn out to be completely wrong
> 5-10 years from now :)

We have three types of MSIs on RISC-V platforms:
1) PCI MSIs (handled by the IMSIC driver of the RISC-V AIA series)
2) Platform MSIs (handled by the IMSIC driver of the RISC-V AIA series)
3) Wired IRQs converted to platform MSIs (aka wired-to-MSI bridge, which
    is handled by APLIC driver of the RISC-V AIA series)

The RISC-V AIA series needs the generic IRQ framework changes
related to #2 and #3 (above) from your series hence my suggestion
to rebase on your series.

Is there a way to have your genirq changes merged before all ARM
drivers have been moved to the new programming model ?
Any other way to deal with this dependency ?


Powered by blists - more mailing lists