linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: "Jayachandran C." <jchandra@broadcom.com>
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Tomasz Nowicki <tn@semihalf.com>
Subject: Re: [RFC PATCH 0/3] ACPI PCI support for arm64
Date: Fri, 4 Dec 2015 12:43:45 +0000	[thread overview]
Message-ID: <20151204124345.GA4169@red-moon> (raw)
In-Reply-To: <20151203184128.GA5890@jayachandranc.netlogicmicro.com>

On Fri, Dec 04, 2015 at 12:11:30AM +0530, Jayachandran C. wrote:
> 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 :)

Ok, maybe you have not noticed it was done on Bjorn's request to
consolidate ECAM (ie pulling that code out of x86) instead of reinventing
the wheel for arm64.

> > 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.

See above. We can't keep adding code that does the same thing as
code already in the mainline.

> > > 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.

You are suggesting adding code to parse the MCFG table, it exists today
and should be consolidated instead of adding on top of it.

> > > 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.

That patchset went through several reviews already, they just reset the
version. I agree with you it is time we got this done, with Tomasz's code,
your code or any combination thereof, please help us get this through,
thanks.

Lorenzo

      parent reply	other threads:[~2015-12-04 12:42 UTC|newest]

Thread overview: 6+ 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 ` [PATCH 1/3] arm64: pci: Add ACPI support 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 ` [PATCH 3/3] pci/host : Add a generic ACPI based host controller Jayachandran C
     [not found] ` <20151203105628.GD2110@red-moon>
2015-12-03 11:02   ` [RFC PATCH 0/3] ACPI PCI support for arm64 Lorenzo Pieralisi
     [not found]   ` <20151203184128.GA5890@jayachandranc.netlogicmicro.com>
2015-12-04 12:43     ` Lorenzo Pieralisi [this message]

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=20151204124345.GA4169@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=jchandra@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=tn@semihalf.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).