Hello, On Thu, 5 Oct 2017 13:16:17 -0500, Bjorn Helgaas wrote: > 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. > (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.) Fine, I'll adjust the commit title to be "PCI: aardvark: Move to struct pci_host_bridge IRQ mapping functions". I also find it nice when commit titles are very consistent, so I can only agree with your obsessiveness on this! > 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. I agree that the other patches do not fix regressions but bugs. So it's really up to you as to what you consider a "fix". The Aardvark driver in its current form leaves a lot of PCIe devices unusable, and we get bug reports about this. But admittedly, such PCIe devices have never worked with Aardvark. > 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. No problem. I do understand that reviewing all of those native drivers takes a significant amount of time. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
