On Fri, Apr 15, 2016 at 11:49 PM, Jon Masters jcm@redhat.com wrote:
On 04/15/2016 01:06 PM, Tomasz Nowicki wrote:
From the functionality point of view this series might be split into the following logic parts:
- Necessary fixes as the preparation for using driver on ARM64.
- New ECAM API and update for users of the pci-host-common API
- Use new MCFG interface and implement generic ACPI based PCI host controller driver.
- Enable above driver on ARM64
Patches has been built on top of 4.6-rc2 and can be found here: git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v6)
This has been tested on Cavium ThunderX server. Any help in reviewing and testing is very appreciated.
v5 -> v6
- dropped idea of x86 MMCONFIG code refactoring
- integrated JC's patches which introduce new ECAM API: https://lkml.org/lkml/2016/4/11/907 git: https://github.com/jchandra-brcm/linux/ (arm64-acpi-pci-v3)
- integrated Sinan's fix for releasing IO resources, see patch [06/13]
- added ACPI support for ThunderX ECAM and PEM drivers
- rebased to 4.6-rc2
JC: can you explicitly confirm that you're ok with letting Tomasz drive this? We would like to see one driver. Either that is Tomasz, or Lorenzo, or it is you. But we need to have one overall cooordinated effort to get this enablement into upstream as quickly as possible.
I have been concentrating on the ECAM code and ECAM based ACPI host controller, the rest of the code is from Tomasz original patchset.
I am not happy with the way the ACPI quirk handling is done in Tomasz's current patchset. I believe that it has to be done in a separate patchset with another set of discussions. It introduces additional complexity and mixing that discussion with the ECAM one will not help in making progress.
I hope things will be clearer when more maintainers chime in. When there is clarity on if the ECAM split is fine, I think we can look at how to drive the whole patchset forward, otherwise we are back to square one.
Some of the Enterprise folks are going to otherwise end up in a very nasty situation of supporting the previous non-upstream patches for many years, which is absolutely something we want to avoid...
Not having ACPI/PCI support upstream is a huge problem for us too...
JC.