[PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
Bjorn Helgaas
bhelgaas at google.com
Thu Dec 19 05:26:35 EST 2013
On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
> On 13-09-18 05:48 AM, Alexander Gordeev wrote:
> >
> > The last pattern makes most of sense to me and could be updated with a more
> > clear sequence - a call to (bit modified) pci_msix_table_size() followed
> > by a call to pci_enable_msix(). I think this pattern can effectively
> > supersede the currently recommended "loop" practice.
>
> The loop is still necessary, because there's a race between those two calls,
> so that pci_enable_msix() can still fail due to lack of MSIX slots.
Hi Mark,
Can you elaborate on this race? My understanding is that
pci_msix_table_size() depends only on the "Table Size" field in the MSI-X
Message Control register.
So if there's a concurrency problem here, it would have to be something
like "pci_enable_msix() may not be able to configure the requested number
of vectors because it has to allocate from a shared pool."
If that's the case, pci_msix_table_size() wouldn't be involved at all, and
the only question is how to coordinate between several drivers that each
call pci_enable_msix(). I think that would have to be resolved in some
arch hook used by the PCI core.
Maybe this is already taken care of; I just want to make sure we don't
overlook an issue here.
Bjorn
More information about the Linuxppc-dev
mailing list