linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.
Date: Fri, 13 May 2016 11:32:50 +0100	[thread overview]
Message-ID: <20160513103239.GA17873@red-moon> (raw)
In-Reply-To: <CAJZ5v0jOAOWLNab0vMOVyciwOhtkuPdqZt3wkFbprq+PkEQNVg@mail.gmail.com>

On Thu, May 12, 2016 at 01:27:23PM +0200, Rafael J. Wysocki wrote:
> On Thu, May 12, 2016 at 12:43 PM, Jayachandran C <jchandra@broadcom.com> wrote:
> > On Thu, May 12, 2016 at 4:13 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> On Wed, May 11, 2016 at 10:30:51PM +0200, Rafael J. Wysocki wrote:
> >>> On Wed, May 11, 2016 at 12:11 PM, Lorenzo Pieralisi
> >>> <lorenzo.pieralisi@arm.com> wrote:
> >>> > On Tue, May 10, 2016 at 08:37:00PM +0200, Rafael J. Wysocki wrote:
> >>> >> On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki <tn@semihalf.com> wrote:
> 
> [cut]
> 
> >
> > If we are moving the ACPI/PCI code from drivers/acpi to
> > arch/arm64/ , there is an issue in having the header file
> > ecam.h in drivers/pci
> >
> > The current include of "../pci/ecam.h" is slightly ugly (Arnd
> > and David had already noted this), but including the driver
> > header from arch code would be even worse.
> >
> > I can either merge ecam.h into include/linux/pci.h
> > or move it to a new file include/linux/pci-ecam.h, any
> > suggestion on which is preferable?
> 
> My preference would be pci-ecam.h as we did a similar thing for
> pci-dma.h, for example, but basically this is up to Bjorn.

A word of caution for all interested parties, what we may move
to arch/arm64 (if Catalin and Will are ok with that) here is content
of drivers/acpi/pci_root_generic.c, not drivers/acpi/pci_mcfg.c (and
definitely not the MCFG quirks handling that is coming up next on top
of this series).

I just wanted to make sure we understand that MCFG quirks handling
like eg:

https://lkml.org/lkml/2016/4/28/790

that is coming up following this series has no chance whatsoever to
be handled within arch/arm64, it is just not going to happen.

Maybe I am jumping the gun, I just want to make sure that everyone is
aware that moving part of this series to arch/arm64 has implications,
(and that's why I said that moving part of this code to arch/arm64 is
not as simple as it looks) it may be ok to have an ACPI PCI
implementation that is arch/arm64 specific (mostly for IO space and PCI
resources assignment handling that unfortunately is not uniform across
X86, IA64 and ARM64), but MCFG quirks and related platform code stay out
of arch/arm64 I guess we are all aware of that, just wanted to make
sure :)

Lorenzo

  reply	other threads:[~2016-05-13 10:32 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10 15:19 [PATCH V7 00/11] Support for generic ACPI based PCI host controller Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 01/11] PCI: Provide common functions for ECAM mapping Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 02/11] PCI: generic, thunder: update to use generic ECAM API Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code Tomasz Nowicki
2016-05-10 17:59   ` Rafael J. Wysocki
2016-05-11  7:36     ` Tomasz Nowicki
2016-05-11 11:01       ` Arnd Bergmann
2016-05-10 15:19 ` [PATCH V7 04/11] pci: Add new function to unmap IO resources Tomasz Nowicki
2016-05-23  8:28   ` Jayachandran C
2016-05-10 15:19 ` [PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources Tomasz Nowicki
2016-05-10 18:20   ` Rafael J. Wysocki
2016-05-11  7:39     ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 06/11] pci, acpi: Provide a way to assign bus domain number Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment Tomasz Nowicki
2016-05-10 18:37   ` Rafael J. Wysocki
2016-05-10 18:43     ` Rafael J. Wysocki
2016-05-11 10:11     ` Lorenzo Pieralisi
2016-05-11 20:30       ` Rafael J. Wysocki
2016-05-11 22:43         ` Bjorn Helgaas
2016-05-12 10:01           ` Lorenzo Pieralisi
2016-05-12 10:43           ` Jayachandran C
2016-05-12 11:27             ` Rafael J. Wysocki
2016-05-13 10:32               ` Lorenzo Pieralisi [this message]
2016-05-12 10:50           ` Tomasz Nowicki
2016-05-12 12:08             ` Bjorn Helgaas
2016-05-17  3:11   ` Dongdong Liu
2016-05-17 13:44     ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Tomasz Nowicki
2016-05-10 17:54   ` Rafael J. Wysocki
2016-05-10 18:18   ` Rafael J. Wysocki
2016-05-13 11:25   ` Jayachandran C
2016-05-13 11:31     ` Rafael J. Wysocki
2016-05-13 11:42       ` Tomasz Nowicki
2016-05-14  9:07   ` Jayachandran C
2016-05-23 11:34     ` Tomasz Nowicki
2016-05-19 16:56   ` Matthias Brugger
2016-05-10 15:19 ` [PATCH V7 09/11] arm64, pci, acpi: ACPI support for legacy IRQs parsing and consolidation with DT code Tomasz Nowicki
2016-05-10 15:20 ` [PATCH V7 10/11] arm64, pci, acpi: Provide ACPI-specific prerequisites for PCI bus enumeration Tomasz Nowicki
2016-05-10 15:20 ` [PATCH V7 11/11] arm64, pci, acpi: Start using ACPI based PCI host controller driver for ARM64 Tomasz Nowicki
2016-05-11 10:41 ` [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni
2016-05-11 11:08   ` Tomasz Nowicki
2016-05-11 12:53     ` Gabriele Paoloni
2016-05-20  4:41     ` Jon Masters
2016-05-20  7:37       ` Ard Biesheuvel
2016-05-20  8:01         ` Jon Masters
2016-05-20  8:28           ` Ard Biesheuvel
2016-05-20  8:40             ` Gabriele Paoloni
2016-05-20  9:14               ` Ard Biesheuvel
2016-05-23 10:56                 ` Lorenzo Pieralisi
2016-05-23 15:16                   ` Gabriele Paoloni
2016-05-23 23:39                     ` Bjorn Helgaas
2016-05-24  1:11                       ` Jon Masters
2016-05-24  1:48                         ` Jon Masters
2016-05-24 14:33                         ` Gabriele Paoloni
2016-05-24  7:23                       ` Gabriele Paoloni
2016-05-24 14:38                         ` Jon Masters
2016-05-24 17:24                       ` Lorenzo Pieralisi
2016-05-24 17:35                         ` Jon Masters
2016-05-24 19:00                         ` Bjorn Helgaas
2016-05-26  9:58                           ` Gabriele Paoloni
2016-05-25  6:31                         ` Gabriele Paoloni
2016-05-24  4:20                   ` Jon Masters
2016-05-20  8:11         ` Gabriele Paoloni
2016-05-20  8:24           ` Jon Masters
2016-05-13  2:55 ` Duc Dang
2016-05-19 18:18 ` Jeremy Linton
2016-05-20  7:46 ` Jon Masters
2016-05-23 11:25 ` Dongdong Liu
2016-05-23 15:36 ` 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=20160513103239.GA17873@red-moon \
    --to=lorenzo.pieralisi@arm.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 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).