mbox series

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

Message ID 20170928125838.11887-1-thomas.petazzoni@free-electrons.com
Headers show
Series PCI: aardvark: improve compatibility with PCI devices | expand

Message

Thomas Petazzoni Sept. 28, 2017, 12:58 p.m. UTC 
Hello,

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.

It fixes kernel bug
https://bugzilla.kernel.org/show_bug.cgi?id=196339, and has been
tested with an IGB NIC and a Marvell SATA PCIe card, which were not
working previously.

They should be taken for the 4.14 cycle, as they are all bug fixes.

Changes since v1:
 - Rebased on top of v4.14-rc2, in order to resolve a minor conflict
   with another patch merged in the mean time.

Thanks a lot!

Thomas

Evan Wang (1):
  PCI: aardvark: fix PCIe max read request size setting

Thomas Petazzoni (1):
  PCI: aardvark: define IRQ related hooks in pci_host_bridge

Victor Gu (5):
  PCI: aardvark: fix logic in PCI configuration read/write functions
  PCI: aardvark: set PIO_ADDR_LS correctly in advk_pcie_rd_conf()
  PCI: aardvark: set host and device to the same MAX payload size
  PCI: aardvark: use isr1 instead of isr0 interrupt in legacy irq mode
  PCI: aardvark: disable LOS state by default

 drivers/pci/host/pci-aardvark.c | 116 +++++++++++++++++++++++++++++++---------
 1 file changed, 92 insertions(+), 24 deletions(-)

Comments

Thomas Petazzoni Oct. 5, 2017, 3:53 p.m. UTC | #1 
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.

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.

Thanks a lot,

Thomas
Bjorn Helgaas Oct. 5, 2017, 6:16 p.m. UTC | #2 
[+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.
(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
Thomas Petazzoni Oct. 5, 2017, 7:35 p.m. UTC | #3 
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
Lorenzo Pieralisi Oct. 6, 2017, 8:47 a.m. UTC | #4 
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