Re: [PATCH v2 0/7] PCI: aardvark: improve compatibility with PCI devices

[Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>]

On Thu, Oct 05, 2017 at 01:16:17PM -0500, Bjorn Helgaas wrote:
> [+cc Lorenzo]
> 
> On Thu, Oct 05, 2017 at 05:53:10PM +0200, Thomas Petazzoni wrote:
> > Hello Bjorn,
> > 
> > On Thu, 28 Sep 2017 14:58:31 +0200, Thomas Petazzoni wrote:
> > 
> > > This patch series brings a number of fixes to the pci-aardvark driver
> > > that allows a much larger number of PCIe devices to be used.
> > 
> > I sent the initial version of this patch series almost a month ago, and
> > it consists of fixes that I would like to have in 4.14.
> 
> The general rule is that after the merge window, I merge fixes to
> things we put in during the merge window, as well as important
> regression fixes.  Most bug fixes will be queued for the next merge
> window.  I'll need some guidance on classifying these.
> 
> I think the map_irq/swizzle_irq patch should definitely be in v4.14.

Yes it is v4.14 (actually v4.13 - Fixes: tag will cover that) material,
I missed updating this host bridge while patching all ARM host controller
bridges, apologies.

Thanks,
Lorenzo

> (It looks a lot like these:
> 
>   1ee4d93d5037 PCI: xilinx-nwl: Move to struct pci_host_bridge IRQ mapping functions
>   5a3dc3c1f694 PCI: rockchip: Move to struct pci_host_bridge IRQ mapping functions
>   c62e98bdaa70 PCI: xgene: Move to struct pci_host_bridge IRQ mapping functions
>   6ab380957838 PCI: altera: Drop pci_fixup_irqs()
>   cf60374de8f6 PCI: versatile: Drop pci_fixup_irqs()
>   6982a068aa5f PCI: generic: Drop pci_fixup_irqs()
>   f7c2e69b65fe PCI: faraday: Drop pci_fixup_irqs()
>   60eca198b1ea PCI: designware: Drop pci_fixup_irqs()
>   64bcd00a7ef5 PCI: iproc: Drop pci_fixup_irqs()
>   29db991902ec PCI: rcar: Drop pci_fixup_irqs()
>   cc2eaaef63df PCI: xilinx: Drop pci_fixup_irqs()
>   dd5fcce2a7f9 PCI: tegra: Drop pci_fixup_irqs()
> 
> and I'm obsessive enough to use one of those subject lines to tie this
> patch together with those.)
> 
> Most of the rest look like they've been there since the driver was
> first merged, so they would *probably* go in the v4.15 queue.
> 
> > Is there a specific problem with those patches that explains why they
> > have been ignored? Or is it just lack of time?
> > 
> > If there is any problem with the patches, please let me know, I am of
> > course perfectly fine with reworking them as needed.
> 
> Sorry for the delay; mostly just lack of time.  I used to work pretty
> strictly first-in, first-out, but the native host bridge drivers
> consume a disproportionate share of my time compared with the generic
> code that benefits everybody, so I'm trying to figure out how to
> prioritize generic changes.  Obviously I need a solution that gives
> *some* time to the native drivers.
> 
> Bjorn