On Tue, 11 Jun 2019 18:29:49 +0100,
Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>
> On 11/06/2019 17:59, Lorenzo Pieralisi wrote:
> > On Fri, Apr 12, 2019 at 08:35:36AM +0000, Z.q. Hou wrote:
> >> From: Hou Zhiqiang <Zhiqiang.Hou@xxxxxxx>
> >>
> >> The current code does not support multiple MSIs, so remove
> >> the corresponding flag from the msi_domain_info structure.
> >
> > Please explain me what's the problem before removing multi MSI
> > support.
>
> The reason seems to be the following code in the allocator:
>
> WARN_ON(nr_irqs != 1);
> mutex_lock(&msi->lock);
>
> bit = find_first_zero_bit(msi->msi_irq_in_use, msi->num_of_vectors);
> if (bit >= msi->num_of_vectors) {
> mutex_unlock(&msi->lock);
> return -ENOSPC;
> }
>
> set_bit(bit, msi->msi_irq_in_use);
>
> So instead of fixing the allocator, the author prefers disabling
> the feature. I'm not sure whether that is an acceptable outcome...
Actually, there is a much deeper issue, and the compose_msi_msg
callback gives a clue:
phys_addr_t addr = pcie->pcie_reg_base + (data->hwirq * sizeof(int));
This thing is using a separate target address per MSI, which is the
killer argument. Bad hardware...
Thanks,
M.
--
Jazz is not dead, it just smells funny.
