Re: [RFC PATCH] PCI: remove access to pci_[enable|disable]_msi() for drivers

[Greg KH]

On Tue, Jun 07, 2005 at 10:41:12PM +0200, Arjan van de Ven wrote:
> On Tue, 2005-06-07 at 09:10 -0700, Greg KH wrote:
> > On Tue, Jun 07, 2005 at 09:31:39AM +0200, Arjan van de Ven wrote:
> > > 
> > > > > * What if the driver writer does not want MSI enabled for their
> > > > >   hardware (even though there is an MSI capabilities entry)?  Reasons
> > > > >   include: overhead involved in initiating the MSI; no support in some
> > > > >   versions of firmware (QLogic hardware).
> > > > 
> > > > Yes, a very good point.  I guess I should keep the pci_enable_msi() and
> > > > pci_disable_msi() functions exported for this reason.
> > > > 
> > > 
> > > well... only pci_disable_msi() is needed for this ;)
> > 
> > I thought so too, until I looked at the IB driver :(
> > 
> > The issue is, if pci_enable_msix() fails, we want to fall back to MSI,
> > so you need to call pci_enable_msi() for that (after calling
> > pci_disable_msi() before calling pci_enable_msix(), what a mess...)
> 
> if the core enables msi.. shouldn't the core also do msix ?

Damm, I knew someone was going to say that :)

Yeah, problem is, the driver provides the msix entries for the core to
fill in.  I could just move that to the pci structure itself if no one
minds, and just use the max number of entries as the default.

Hm, or does it really help for the driver to specify different numbers
of msi-x vectors?

Roland, any ideas here?  You seem to be the only one who has actually
used the msix code so far.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/