From: jchandra@broadcom.com (Jayachandran C.)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/3] ACPI PCI support for arm64
Date: Fri, 4 Dec 2015 00:11:30 +0530 [thread overview]
Message-ID: <20151203184128.GA5890@jayachandranc.netlogicmicro.com> (raw)
In-Reply-To: <20151203105628.GD2110@red-moon>
On Thu, Dec 03, 2015 at 10:56:28AM +0000, Lorenzo Pieralisi wrote:
> [CC'ing Tomasz]
>
> On Thu, Dec 03, 2015 at 03:54:43AM +0530, Jayachandran C wrote:
> > This is a very simple and generic implementation of a PCI host controller
> > based on ACPI. This approach does not pull in the MMCONFIG and ECAM code
> > from x86.
>
> Why ? Tomasz's patchset does not move MMCONFIG and ECAM code to the generic
> PCI layer for fun,
Honestly, Lorenzo, I can see that it was not fun :)
> it is generic code and should be shared by all
> architectures and most importantly we should not add more churn on
> top of it which would complicate consolidation even further.
There is no need for such a common/generic infrastructure to
walk thru a simple table. In my opinion, trying to do this added
a lot of complexity into what should be a very simple patchset.
The x86 code has to deal with a lot more fw/hw issues and I fail
to see why that mess should be brought into the a new architecture.
> > It is important for us to have a working ACPI based PCI host controller
> > implementation for arm64, so I thought I would post this as a simple
> > and less disruptive alternative.
>
> It is important for everyone but that's not a reason granting shortcuts.
I am suggesting a simpler (and maybe better) implementation, which
is much easier to review and merge - not a shortcut.
> > This is tested with arm64 QEMU and OVMF. Comments are very welcome.
>
> Tomasz's patch went through several review cycles, please help review
> it and test it, that's my comment.
>
> A new version should be posted soon, previous version here:
>
> https://lkml.org/lkml/2015/10/27/504
It seems to be v1, I did not see any ACKs from maintainers either -
sorry if I am missing something here.
JC.
next prev parent reply other threads:[~2015-12-03 18:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-02 22:24 [RFC PATCH 0/3] ACPI PCI support for arm64 Jayachandran C
2015-12-02 22:24 ` Jayachandran C
2015-12-02 22:24 ` [PATCH 1/3] arm64: pci: Add ACPI support Jayachandran C
2015-12-02 22:24 ` Jayachandran C
2015-12-02 22:24 ` [PATCH 2/3] pci: Handle NULL parent in pci_bus_assign_domain_nr Jayachandran C
2015-12-02 22:24 ` Jayachandran C
2015-12-02 22:24 ` [PATCH 3/3] pci/host : Add a generic ACPI based host controller Jayachandran C
2015-12-02 22:24 ` Jayachandran C
[not found] ` <20151203105628.GD2110@red-moon>
2015-12-03 11:02 ` [RFC PATCH 0/3] ACPI PCI support for arm64 Lorenzo Pieralisi
2015-12-03 11:02 ` Lorenzo Pieralisi
2015-12-03 18:41 ` Jayachandran C. [this message]
2015-12-04 12:43 ` Lorenzo Pieralisi
2015-12-04 12:43 ` Lorenzo Pieralisi
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=20151203184128.GA5890@jayachandranc.netlogicmicro.com \
--to=jchandra@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.