Re: [RFC PATCH v4 01/16] iommu/arm-smmu-v3: Discover RME support and realm IRQ topology

[Jason Gunthorpe]

On Tue, Sep 01, 2026 at 02:16:10PM +0530, Aneesh Kumar K.V wrote:
> +static struct irq_domain *arm_smmu_get_wired_irq_domain(struct arm_smmu_device *smmu)
> +{
> +	int irqs[] = {
> +		smmu->combined_irq,
> +		smmu->evtq.q.irq,
> +		smmu->gerr_irq,
> +		smmu->priq.q.irq,
> +	};
> +	struct irq_domain *domain = NULL;
> +	struct irq_data *irq_data;
> +	unsigned int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(irqs); i++) {
> +		if (irqs[i] <= 0)
> +			continue;
> +
> +		irq_data = irq_get_irq_data(irqs[i]);
> +		if (!irq_data || !irq_data->domain)
> +			return ERR_PTR(-EINVAL);
> +
> +		if (domain && domain != irq_data->domain)
> +			return ERR_PTR(-EINVAL);
> +
> +		domain = irq_data->domain;
> +	}
> +
> +	return domain ?: ERR_PTR(-ENXIO);

I'm not excited to see code like this in a driver. Please put a helper
function someplace else to translate whatever the RMM value is into a
normal linux irq number?

But this feels wrong to me, interrupts need to come through the FW
side, ACPI or DT. Having RMM pass the value outside that
infrastructure is going to be painful. None of this is trusted, why is
it working like this vs just adding more interrupt lines to the FW
description?

A naked integer is not enough to describe an interrupt in the system,
and guessing that it is connected to other interrupts in the psmmu
seems like an uncomfortable leap to me.

Jason