[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <571130BB.9030508@redhat.com>
Date: Fri, 15 Apr 2016 14:19:39 -0400
From: Jon Masters <jcm@...hat.com>
To: Tomasz Nowicki <tn@...ihalf.com>, helgaas@...nel.org,
arnd@...db.de, will.deacon@....com, catalin.marinas@....com,
rafael@...nel.org, hanjun.guo@...aro.org,
Lorenzo.Pieralisi@....com, okaya@...eaurora.org,
jiang.liu@...ux.intel.com, jchandra@...adcom.com
Cc: robert.richter@...iumnetworks.com, mw@...ihalf.com,
Liviu.Dudau@....com, ddaney@...iumnetworks.com,
wangyijing@...wei.com, Suravee.Suthikulpanit@....com,
msalter@...hat.com, linux-pci@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, linaro-acpi@...ts.linaro.org
Subject: Re: [PATCH V6 00/13] Support for generic ACPI based PCI host
controller
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:
> 1. Necessary fixes as the preparation for using driver on ARM64.
> 2. New ECAM API and update for users of the pci-host-common API
> 3. Use new MCFG interface and implement generic ACPI based PCI host controller driver.
> 4. Enable above driver on ARM64
>
> Patches has been built on top of 4.6-rc2 and can be found here:
> git@...hub.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.
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...
Jon.
Powered by blists - more mailing lists