From: Jon Masters <jcm@jonmasters.org>
To: David Daney <ddaney@caviumnetworks.com>,
Jayachandran C <jchandra@broadcom.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Tomasz Nowicki <tn@semihalf.com>,
rafael@kernel.org, Arnd Bergmann <arnd@arndb.de>,
Will Deacon <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
okaya@codeaurora.org, jiang.liu@linux.intel.com,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
robert.richter@caviumnetworks.com,
Marcin Wojtas <mw@semihalf.com>,
Liviu.Dudau@arm.com, wangyijing@huawei.com,
Suravee.Suthikulpanit@amd.com, msalter@redhat.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linaro-acpi@lists.linaro.org, Jon Masters <jcm@redhat.com>
Subject: Re: [PATCH v2 2/4] PCI: Provide common functions for ECAM mapping
Date: Tue, 12 Apr 2016 00:26:25 -0400 [thread overview]
Message-ID: <570C78F1.4090701@jonmasters.org> (raw)
In-Reply-To: <570C4034.20105@caviumnetworks.com>
Hi David, JC,
On 04/11/2016 08:24 PM, David Daney wrote:
> Tested-by: David Daney <david.daney@cavium.com>
On ThunderX (please let me know the silicon pass specifics off-list)?
I'm planning to give this series a test run also on some other ARMv8
hardware and will prod a few of the other vendors to do so.
>> drivers/pci/ecam.c | 130
>> drivers/pci/ecam.h | 58 +++++++++++++++++++++++
>
> I wonder if these files should go in drivers/pci/host ... I understand
> that you still have to use them from drivers/pci/acpi though.
>
> I will let others opine on this, but could you put the contents of
> ecam.h into include/linux/pci.h along with the pci_generic_config_*()
> declarations?
>
> If you did that, the contents of ecam.c could go into
> drivers/pci/access.c...
Quoting Bjorn's original reply to the previous series:
> Some of the code that moved to drivers/acpi/pci_mcfg.c is not
> really ACPI-specific, and could potentially be used for non-ACPI
> bridges that support ECAM. I'd like to see that sort of code
> moved to a new file like drivers/pci/ecam.c.
So my guess is that this is the reasoning behind JC's file layout.
I'm curious what Lorenzo's take on things is currently. I assume this
series is now to be the official coordinated version of this effort for
upstream, following the advice of Bjorn previously, but I would like to
know if everyone is behind this plan. I've (previously) requested a
Linaro LEG meeting this week (part of our bootarch working group) to
specifically discuss the status of PCI upstreaming in order to get the
different vendors together to ensure every single one of them is
tracking the correct latest effort and doing what is needed to test/aid,
hence my ask. If this is now plan A, I'll make sure everyone is aligned
behind it and start pinging people individually for testing.
Jon.
--
Computer Architect
next prev parent reply other threads:[~2016-04-12 4:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-11 22:45 [PATCH v2 0/4] ACPI based PCI host driver with generic ECAM Jayachandran C
2016-04-11 22:45 ` [PATCH v2 1/4] arm64: Prepare to use generic ACPI PCI implementation Jayachandran C
2016-04-11 22:45 ` [PATCH v2 2/4] PCI: Provide common functions for ECAM mapping Jayachandran C
2016-04-12 0:24 ` David Daney
2016-04-12 4:26 ` Jon Masters [this message]
2016-04-12 16:44 ` Lorenzo Pieralisi
2016-04-14 5:55 ` Jon Masters
2016-04-14 10:05 ` Lorenzo Pieralisi
2016-04-14 15:40 ` Jayachandran C
2016-04-11 22:45 ` [PATCH v2 3/4] PCI: generic, thunder: update to use generic ECAM API Jayachandran C
2016-04-12 0:34 ` David Daney
2016-04-14 14:15 ` Jayachandran C
2016-04-11 22:45 ` [PATCH v2 4/4] ACPI: PCI: Add generic PCI host controller Jayachandran C
2016-04-12 1:38 ` kbuild test robot
2016-04-14 15:53 ` Sinan Kaya
2016-04-14 15:58 ` Sinan Kaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=570C78F1.4090701@jonmasters.org \
--to=jcm@jonmasters.org \
--cc=Liviu.Dudau@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=ddaney@caviumnetworks.com \
--cc=hanjun.guo@linaro.org \
--cc=helgaas@kernel.org \
--cc=jchandra@broadcom.com \
--cc=jcm@redhat.com \
--cc=jiang.liu@linux.intel.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=msalter@redhat.com \
--cc=mw@semihalf.com \
--cc=okaya@codeaurora.org \
--cc=rafael@kernel.org \
--cc=robert.richter@caviumnetworks.com \
--cc=tn@semihalf.com \
--cc=wangyijing@huawei.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).