From: David Daney

Sent: 27 March 2017 18:31
On 03/27/2017 10:11 AM, Christoph Hellwig wrote:

quoted

On Mon, Mar 27, 2017 at 09:59:35AM -0700, David Daney wrote:

quoted

On 03/27/2017 01:29 AM, Christoph Hellwig wrote:

quoted

Unused now that all callers switched to pci_alloc_irq_vectors.

And you are aware that the ThunderX GPIO driver that I am attempting to
merge uses this interface.

If this patch gets merged, should I ask to revert it when the GPIO driver
goes in?

No.  You should not use pci_enable_msix in your new driver as I told
you before.

quoted

You offer no solution for drivers that would benefit from using a sparse
sub set of the available MSI-X vectors.

Use pci_enable_msix_{exact,range} for now, as I told you before.

That still results in twice as many MSI-X being provisioned than are needed.

For drivers that use a contiguous range of MSI-X, your suggestion is
usable, but for others you are forcing resources to be wasted.  For what
end?

There are also drivers that only need some interrupts after a specific
device is opened, and could free them when closed.

This could even be network devices with lots of queues, or a driver
realising that the workload is high and per-cpu interrupts make sense.

So any real change to the interface should allow drivers to allocate
and free individual MSI-X vectors.

I remember a lot of discussions when pci_enable_msix_range() was added,
but almost nothing about this change.

	David