Re: [patch 00/37] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-11-28 Thread Thomas Gleixner
On Sat, Nov 27 2021 at 20:39, Jason Gunthorpe wrote:
> On Sat, Nov 27, 2021 at 02:21:17AM +0100, Thomas Gleixner wrote:
>>4) Provide a function to retrieve the Linux interrupt number for a given
>>   MSI index similar to pci_irq_vector() and cleanup all open coded
>>   variants.
>
> The msi_get_virq() sure does make a big difference.. Though it does
> highlight there is some asymmetry with how platform and PCI works here
> where PCI fills some 'struct msix_entry *'. Many drivers would be
> quite happy to just call msi_get_virq() and avoid the extra memory, so
> I think the msi_get_virq() version is good.

struct msix_entry should just go away.

90+% of the use cases fill it with a linear index range 0...N and then
use the virq entry for request_irq(). So they can just use
pci_alloc_irs_vectors_affinity() and retrieve the interrupt number via
pci_irq_vector().

The few drivers which actually use it to allocate a sparse populated MSI
index, e.g. 0, 12, 14 can be converted over to alloc vector 0 and then
use the dynamic extenstion for the rest.

Thanks,

tglx
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [patch 00/37] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-11-27 Thread Jason Gunthorpe via iommu
On Sat, Nov 27, 2021 at 02:21:17AM +0100, Thomas Gleixner wrote:
> This is the second part of [PCI]MSI refactoring which aims to provide the
> ability of expanding MSI-X vectors after enabling MSI-X.
> 
> The first part of this work can be found here:
> 
> https://lore.kernel.org/r/20211126222700.862407...@linutronix.de
> 
> This second part has the following important changes:
> 
>1) Cleanup of the MSI related data in struct device
> 
>   struct device contains at the moment various MSI related parts. Some
>   of them (the irq domain pointer) cannot be moved out, but the rest
>   can be allocated on first use. This is in preparation of adding more
>   per device MSI data later on.
> 
>2) Consolidation of sysfs handling
> 
>   As a first step this moves the sysfs pointer from struct msi_desc
>   into the new per device MSI data structure where it belongs.
> 
>   Later changes will cleanup this code further, but that's not possible
>   at this point.
> 
>3) Store per device properties in the per device MSI data to avoid
>   looking up MSI descriptors and analysing their data. Cleanup all
>   related use cases.
> 
>4) Provide a function to retrieve the Linux interrupt number for a given
>   MSI index similar to pci_irq_vector() and cleanup all open coded
>   variants.

The msi_get_virq() sure does make a big difference.. Though it does
highlight there is some asymmetry with how platform and PCI works here
where PCI fills some 'struct msix_entry *'. Many drivers would be
quite happy to just call msi_get_virq() and avoid the extra memory, so
I think the msi_get_virq() version is good.

Reviewed-by: Jason Gunthorpe 

Thanks,
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [patch 00/37] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-11-27 Thread Greg Kroah-Hartman
On Sat, Nov 27, 2021 at 02:20:06AM +0100, Thomas Gleixner wrote:
> This is the second part of [PCI]MSI refactoring which aims to provide the
> ability of expanding MSI-X vectors after enabling MSI-X.
> 
> The first part of this work can be found here:
> 
> https://lore.kernel.org/r/20211126222700.862407...@linutronix.de
> 
> This second part has the following important changes:
> 
>1) Cleanup of the MSI related data in struct device
> 
>   struct device contains at the moment various MSI related parts. Some
>   of them (the irq domain pointer) cannot be moved out, but the rest
>   can be allocated on first use. This is in preparation of adding more
>   per device MSI data later on.
> 
>2) Consolidation of sysfs handling
> 
>   As a first step this moves the sysfs pointer from struct msi_desc
>   into the new per device MSI data structure where it belongs.
> 
>   Later changes will cleanup this code further, but that's not possible
>   at this point.
> 
>3) Store per device properties in the per device MSI data to avoid
>   looking up MSI descriptors and analysing their data. Cleanup all
>   related use cases.
> 
>4) Provide a function to retrieve the Linux interrupt number for a given
>   MSI index similar to pci_irq_vector() and cleanup all open coded
>   variants.
> 
> This second series is based on:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git 
> msi-v1-part-1
> 
> and also available from git:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git 
> msi-v1-part-2
> 

Instead of responding to each individual patch, I've read them all,
thanks for the cleanups, look good to me:

Reviewed-by: Greg Kroah-Hartman 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[patch 00/37] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-11-26 Thread Thomas Gleixner
This is the second part of [PCI]MSI refactoring which aims to provide the
ability of expanding MSI-X vectors after enabling MSI-X.

The first part of this work can be found here:

https://lore.kernel.org/r/20211126222700.862407...@linutronix.de

This second part has the following important changes:

   1) Cleanup of the MSI related data in struct device

  struct device contains at the moment various MSI related parts. Some
  of them (the irq domain pointer) cannot be moved out, but the rest
  can be allocated on first use. This is in preparation of adding more
  per device MSI data later on.

   2) Consolidation of sysfs handling

  As a first step this moves the sysfs pointer from struct msi_desc
  into the new per device MSI data structure where it belongs.

  Later changes will cleanup this code further, but that's not possible
  at this point.

   3) Store per device properties in the per device MSI data to avoid
  looking up MSI descriptors and analysing their data. Cleanup all
  related use cases.

   4) Provide a function to retrieve the Linux interrupt number for a given
  MSI index similar to pci_irq_vector() and cleanup all open coded
  variants.

This second series is based on:

 git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v1-part-1

and also available from git:

 git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v1-part-2

For the curious who can't wait for the next part to arrive the full series
is available via:

 git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v1-part-4

Thanks,

tglx
---
 arch/powerpc/platforms/cell/axon_msi.c  |6 
 arch/powerpc/platforms/pseries/msi.c|   38 +---
 arch/x86/kernel/apic/msi.c  |5 
 arch/x86/pci/xen.c  |8 
 drivers/base/core.c |1 
 drivers/base/platform-msi.c |  152 -
 drivers/bus/fsl-mc/dprc-driver.c|8 
 drivers/bus/fsl-mc/fsl-mc-allocator.c   |9 -
 drivers/bus/fsl-mc/fsl-mc-msi.c |   26 +--
 drivers/dma/mv_xor_v2.c |   16 -
 drivers/dma/qcom/hidma.c|   44 ++---
 drivers/dma/ti/k3-udma-private.c|6 
 drivers/dma/ti/k3-udma.c|   14 -
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |   23 --
 drivers/irqchip/irq-mbigen.c|4 
 drivers/irqchip/irq-mvebu-icu.c |   12 -
 drivers/irqchip/irq-ti-sci-inta.c   |2 
 drivers/mailbox/bcm-flexrm-mailbox.c|9 -
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c|4 
 drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c|4 
 drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c |5 
 drivers/pci/msi/irqdomain.c |   20 +-
 drivers/pci/msi/legacy.c|6 
 drivers/pci/msi/msi.c   |  118 +
 drivers/pci/xen-pcifront.c  |2 
 drivers/perf/arm_smmuv3_pmu.c   |5 
 drivers/soc/fsl/dpio/dpio-driver.c  |8 
 drivers/soc/ti/k3-ringacc.c |6 
 drivers/soc/ti/ti_sci_inta_msi.c|   22 --
 drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c  |4 
 include/linux/device.h  |   26 ++-
 include/linux/fsl/mc.h  |4 
 include/linux/msi.h |  118 +++--
 include/linux/pci.h |1 
 include/linux/soc/ti/ti_sci_inta_msi.h  |1 
 kernel/irq/msi.c|  171 +++-
 36 files changed, 463 insertions(+), 445 deletions(-)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu