]> git.baikalelectronics.ru Git - kernel.git/commit
PCI/MSI: Return -ENOSPC from pci_alloc_irq_vectors_affinity()
authorMing Lei <ming.lei@redhat.com>
Tue, 15 Jan 2019 23:31:29 +0000 (17:31 -0600)
committerBjorn Helgaas <bhelgaas@google.com>
Tue, 15 Jan 2019 23:31:29 +0000 (17:31 -0600)
commitd561fb2c3b0e25076f67f230337d43af1e7f834c
tree9ddd3f770241252842fb9e40cbad8a65645824fc
parentd10b99662f79d2b0aff7cb3d7d26ba750425b4b6
PCI/MSI: Return -ENOSPC from pci_alloc_irq_vectors_affinity()

The API of pci_alloc_irq_vectors_affinity() says it returns -ENOSPC if
fewer than @min_vecs interrupt vectors are available for @dev.

However, if a device supports MSI-X but not MSI and a caller requests
@min_vecs that can't be satisfied by MSI-X, we previously returned -EINVAL
(from the failed attempt to enable MSI), not -ENOSPC.

When -ENOSPC is returned, callers may reduce the number IRQs they request
and try again.  Most callers can use the @min_vecs and @max_vecs
parameters to avoid this retry loop, but that doesn't work when using IRQ
affinity "nr_sets" because rebalancing the sets is driver-specific.

This return value bug has been present since pci_alloc_irq_vectors() was
added in v4.10 by 453878a5cb0c ("PCI: Provide sensible IRQ vector
alloc/free routines"), but it wasn't an issue because @min_vecs/@max_vecs
removed the need for callers to iteratively reduce the number of IRQs
requested and retry the allocation, so they didn't need to distinguish
-ENOSPC from -EINVAL.

In v5.0, 05586d58ada7 ("genirq/affinity: Add support for allocating
interrupt sets") added IRQ sets to the interface, which reintroduced the
need to check for -ENOSPC and possibly reduce the number of IRQs requested
and retry the allocation.

Signed-off-by: Ming Lei <ming.lei@redhat.com>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Christoph Hellwig <hch@lst.de>
drivers/pci/msi.c