Re: [PATCH RFC 0/2] irqchip/ls-scfg-msi: add multi-MSI support
From: Frank Li
Date: Thu Aug 20 2026 - 12:09:21 EST
On Thu, Jul 16, 2026 at 12:14:59PM +0200, Alexander Wilhelm wrote:
> This series enables multi-MSI (nr_irqs > 1) allocation on the Layerscape
> SCFG MSI controller so PCI endpoints that request contiguous MSI vector
> blocks (for example ath12k, which asks for 16 vectors: 3 MHI + 5 CE + 8 DP)
> no longer fall back to single-MSI operation with all interrupts multiplexed
> onto one CPU.
>
> The first patch is a preparation refactor: switch the hwirq bookkeeping
> from find_first_zero_bit() / __set_bit() to bitmap_find_free_region() /
> bitmap_release_region(), release the region on iommu_dma_prepare_msi()
> error, and loop irq_domain_set_info() over nr_irqs. For the current
> single-MSI case (order 0) this is functionally equivalent; the only
> externally visible change is -ENOMEM instead of -ENOSPC on exhaustion.
>
> The second patch enables MSI_FLAG_MULTI_PCI_MSI on the parent domain, drops
> the WARN_ON(nr_irqs != 1) guard, and statically pins each MSIR's chained
> parent IRQ to its matching CPU in no-affinity mode. That pinning is
> required because affinity mode only releases every (1 << ibs_shift)-th
> hwirq and cannot satisfy aligned power-of-two allocations of size > 1;
> users of multi-MSI must therefore boot with lsmsi=no-affinity.
what's happen if not set "lsmsi=no-affinity" at boot?
Please add imx@xxxxxxxxxxxxxxx
Add Ioana Ciornei, who have more layerscape knowledge.
Frank
>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@xxxxxxxxxxxx>
> ---
> Alexander Wilhelm (2):
> irqchip/ls-scfg-msi: refactor allocation to bitmap_find_free_region()
> irqchip/ls-scfg-msi: enable multi-MSI allocation
>
> drivers/irqchip/irq-ls-scfg-msi.c | 45 +++++++++++++++++++++++----------------
> 1 file changed, 27 insertions(+), 18 deletions(-)
> ---
> base-commit: 37e2f878a7a660a216cc7a60459995fefd150f25
> change-id: 20260716-irqchip-ls-scfg-msi-add-multi-msi-support-5e7538460704
>
> Best regards,
> --
> Alexander Wilhelm <alexander.wilhelm@xxxxxxxxxxxx>
>