PCI: aardvark: improve compatibility with PCI devices
Get series with b4
b4 am 20171006084705.GA8754@red-moonVersions newest first
- v2 Latest0 of 7 patches 0 repliesNew
Patches in v2 No applies recorded yet
None of the 7 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH v2 0/7] PCI: aardvark: improve compatibility with PCI devices
Quoted 13 lines · Bjorn Helgaas
[+cc Lorenzo]
Quoted 9 lines · Thomas Petazzoni
Hello Bjorn,
Quoted 2 lines · Thomas Petazzoni
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.
Quoted 6 lines
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
Quoted 35 lines
(It looks a lot like these:
1ee4d93d5037PCI: xilinx-nwl: Move to structpci_host_bridgeIRQ mapping functions5a3dc3c1f694PCI: rockchip: Move to structpci_host_bridgeIRQ mapping functionsc62e98bdaa70PCI: xgene: Move to structpci_host_bridgeIRQ mapping functions6ab380957838PCI: altera: Droppci_fixup_irqs()
cf60374de8f6PCI: versatile: Droppci_fixup_irqs()
6982a068aa5fPCI: generic: Droppci_fixup_irqs()
f7c2e69b65fePCI: faraday: Droppci_fixup_irqs()
60eca198b1eaPCI: designware: Droppci_fixup_irqs()
64bcd00a7ef5PCI: iproc: Droppci_fixup_irqs()
29db991902ecPCI: rcar: Droppci_fixup_irqs()
cc2eaaef63dfPCI: xilinx: Droppci_fixup_irqs()
dd5fcce2a7f9PCI: tegra: Droppci_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.
Quoted 5 lines
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