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]
Date:   Fri, 27 Oct 2023 10:01:12 +0530
From:   Anup Patel <apatel@...tanamicro.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Björn Töpel <bjorn@...nel.org>,
        Anup Patel <anup@...infault.org>,
        Björn Töpel <bjorn@...osinc.com>,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        x86@...nel.org, Marc Zyngier <maz@...nel.org>
Subject: Re: [RFC PATCH] genirq/matrix: Dynamic bitmap allocation

Hi Thomas,

On Fri, Oct 27, 2023 at 4:47 AM Thomas Gleixner <tglx@...utronix.de> 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.
(https://lore.kernel.org/all/20221121135653.208611233@linutronix.de/)

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

Regards,
Anup

Powered by blists - more mailing lists