Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Logan Gunthorpe <[email protected]>
---
drivers/pci/pcie/portdrv_core.c | 4 ++--
drivers/pci/switch/switchtec.c | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 50a9522ab07d..2a38a918ba12 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -105,7 +105,7 @@ static int pcie_port_enable_irq_vec(struct pci_dev *dev, int *irqs, int mask)
/* Allocate the maximum possible number of MSI/MSI-X vectors */
nr_entries = pci_alloc_irq_vectors(dev, 1, PCIE_PORT_MAX_MSI_ENTRIES,
- PCI_IRQ_MSIX | PCI_IRQ_MSI);
+ PCI_IRQ_MSI_TYPES);
if (nr_entries < 0)
return nr_entries;
@@ -131,7 +131,7 @@ static int pcie_port_enable_irq_vec(struct pci_dev *dev, int *irqs, int mask)
pci_free_irq_vectors(dev);
nr_entries = pci_alloc_irq_vectors(dev, nvec, nvec,
- PCI_IRQ_MSIX | PCI_IRQ_MSI);
+ PCI_IRQ_MSI_TYPES);
if (nr_entries < 0)
return nr_entries;
}
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 850cfeb74608..0ab17a71fe63 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1442,8 +1442,7 @@ static int switchtec_init_isr(struct switchtec_dev *stdev)
nirqs = 4;
nvecs = pci_alloc_irq_vectors(stdev->pdev, 1, nirqs,
- PCI_IRQ_MSIX | PCI_IRQ_MSI |
- PCI_IRQ_VIRTUAL);
+ PCI_IRQ_MSI_TYPES | PCI_IRQ_VIRTUAL);
if (nvecs < 0)
return nvecs;
--
2.17.2
On Tue, Jun 09, 2020 at 11:16:46AM +0200, Piotr Stankiewicz wrote:
> Seeing as there is shorthand available to use when asking for any type
> of interrupt, or any type of message signalled interrupt, leverage it.
>
> Signed-off-by: Piotr Stankiewicz <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> Reviewed-by: Logan Gunthorpe <[email protected]>
The patch actually adding PCI_IRQ_MSI_TYPES still didn't show up on
linux-pci.
But from the person who added PCI_IRQ_*:
NAK to the whole concept of PCI_IRQ_MSI_TYPES, I think this just makes
the code a lot more confusing. Especially with the new IMS interrupt
type, which really is a MSI-like interrupt but certainly shouldn't be
added to this mask.
> -----Original Message-----
> From: Christoph Hellwig <[email protected]>
> Sent: Tuesday, June 9, 2020 5:51 PM
>
> On Tue, Jun 09, 2020 at 11:16:46AM +0200, Piotr Stankiewicz wrote:
> > Seeing as there is shorthand available to use when asking for any type
> > of interrupt, or any type of message signalled interrupt, leverage it.
> >
> > Signed-off-by: Piotr Stankiewicz <[email protected]>
> > Reviewed-by: Andy Shevchenko <[email protected]>
> > Reviewed-by: Logan Gunthorpe <[email protected]>
>
> The patch actually adding PCI_IRQ_MSI_TYPES still didn't show up on linux-pci.
>
I'm not sure why it didn't get delivered. I just resent it, for sake of completeness.
> But from the person who added PCI_IRQ_*:
>
> NAK to the whole concept of PCI_IRQ_MSI_TYPES, I think this just makes the
> code a lot more confusing. Especially with the new IMS interrupt type, which
> really is a MSI-like interrupt but certainly shouldn't be added to this mask.
On 2020-06-09 9:51 a.m., Christoph Hellwig wrote:
> On Tue, Jun 09, 2020 at 11:16:46AM +0200, Piotr Stankiewicz wrote:
>> Seeing as there is shorthand available to use when asking for any type
>> of interrupt, or any type of message signalled interrupt, leverage it.
>>
>> Signed-off-by: Piotr Stankiewicz <[email protected]>
>> Reviewed-by: Andy Shevchenko <[email protected]>
>> Reviewed-by: Logan Gunthorpe <[email protected]>
>
> The patch actually adding PCI_IRQ_MSI_TYPES still didn't show up on
> linux-pci.
>
> But from the person who added PCI_IRQ_*:
>
> NAK to the whole concept of PCI_IRQ_MSI_TYPES, I think this just makes
> the code a lot more confusing. Especially with the new IMS interrupt
> type, which really is a MSI-like interrupt but certainly shouldn't be
> added to this mask.
Yes, after cleaning up the first patch to not require the long messy
conditional, this change doesn't seems like a win. I agree we should
drop these patches.
Logan