On Mon, 17 Jun 2024 15:15:44 +0100, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Mon, Jun 17 2024 at 16:02, Thomas Gleixner wrote: > > On Mon, Jun 17 2024 at 14:03, Marc Zyngier wrote: > >> Patch 9/24 rewrites the mbigen driver. Which has nothing to do with > >> what the gic-v3-mbi code does. They are different blocks, and the sole > >> machine that has the mbigen IP doesn't have any gic-v3-mbi support. > >> All they have in common are 3 random letters. > >> > >> What you are doing here is to kill any support for *devices* that need > >> to signal level-triggered MSIs in that driver, and nothing to do with > >> wire-MSI translation. > >> > >> So what replaces it? > > > > Hrm. I must have misread this mess. Let me stare some more. > > Ok. Found my old notes. > > AFAICT _all_ users of platform_device_msi_init_and_alloc_irqs(): > > ufs_qcom_config_esi() > smmu_pmu_setup_msi() > flexrm_mbox_probe() > arm_smmu_setup_msis() > hidma_request_msi() > mv_xor_v2_probe() > > just install their special MSI write callback. I don't see any of those > setting up LEVEL triggered MSIs. > > But then I'm might be missing something. If so can you point me please > to the usage instance which actually uses level signaled MSI? Good question. I'm pretty sure we had *something* at some point that used it, or that was planning on using it. I even vividly remember who was asking for this. But either that never really made it upstream, or they decided to move away from the kernel setting the MSI up and relied on firmware for that (which is fine as long as the device isn't behind an IOMMU). In the end, it begs the question of what we want to do with this feature. I don't think it is a big deal to keep it around, but maybe we should plan for it to be retired. That's independent of this series, IMO. Thanks, M. -- Without deviation from the norm, progress is not possible.
