From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller
Date: Thu, 16 Jun 2016 18:48:56 +0100 [thread overview]
Message-ID: <20160616174856.GB32388@red-moon> (raw)
In-Reply-To: <1466004851-10214-2-git-send-email-cov@codeaurora.org>
On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
> From: Tomasz Nowicki <tn@semihalf.com>
>
> pci_generic_ecam_ops is used by default. Since there are platforms
> which have non-compliant ECAM space we need to overwrite these
> accessors prior to PCI buses enumeration. In order to do that
> we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
> we can use proper PCI config space accessors and bus_shift.
>
> pci_generic_ecam_ops is still used for platforms free from quirks.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> arch/arm64/kernel/pci.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 94cd43c..a891bda 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
> struct pci_config_window *cfg;
> struct resource cfgres;
> unsigned int bsz;
> + struct pci_ecam_ops *ops;
>
> /* Use address from _CBA if present, otherwise lookup MCFG */
> if (!root->mcfg_addr)
> @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
> return NULL;
> }
>
> - bsz = 1 << pci_generic_ecam_ops.bus_shift;
> + ops = pci_mcfg_get_ops(root);
> + bsz = 1 << ops->bus_shift;
> cfgres.start = root->mcfg_addr + bus_res->start * bsz;
> cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
> cfgres.flags = IORESOURCE_MEM;
> - cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res,
> - &pci_generic_ecam_ops);
> + cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res, ops);
Arnd pointed this out already, I think that's the only pending question
here.
pci_ecam_create() maps ECAM space for config regions retrieved from
the MCFG, which are *supposed* to be ECAM compliant.
Do we think that's *always* correct/safe regardless of the kind
of quirk we are currently fixing up ?
Or we do think that configuration space regions should come from
a different resource declared in the ACPI namespace if the regions
are not MCFG/ECAM compliant (ie config space is not defined through
MCFG at all - possibly through a _CRS method for a vendor specific
_HID under the PNP0A03 node ?)
It might even be a choice we do not have anymore, but I think it
is important to make a decision and proceed accordingly.
Comments appreciated.
Thanks,
Lorenzo
> if (IS_ERR(cfg)) {
> dev_err(&root->device->dev, "%04x:%pR error %ld mapping ECAM\n",
> seg, bus_res, PTR_ERR(cfg));
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Christopher Covington <cov@codeaurora.org>
Cc: Tomasz Nowicki <tn@semihalf.com>, Duc Dang <dhdang@apm.com>,
Dongdong Liu <liudongdong3@huawei.com>,
Sinan Kaya <okaya@codeaurora.org>,
Jeff Hugo <jhugo@codeaurora.org>,
Gabriele Paoloni <gabriele.paoloni@huawei.com>,
Jon Masters <jcm@redhat.com>, Mark Salter <msalter@redhat.com>,
Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>,
Jayachandran C <jchandra@broadcom.com>,
David Daney <ddaney@caviumnetworks.com>,
Robert Richter <robert.richter@caviumnetworks.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller
Date: Thu, 16 Jun 2016 18:48:56 +0100 [thread overview]
Message-ID: <20160616174856.GB32388@red-moon> (raw)
In-Reply-To: <1466004851-10214-2-git-send-email-cov@codeaurora.org>
On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
> From: Tomasz Nowicki <tn@semihalf.com>
>
> pci_generic_ecam_ops is used by default. Since there are platforms
> which have non-compliant ECAM space we need to overwrite these
> accessors prior to PCI buses enumeration. In order to do that
> we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
> we can use proper PCI config space accessors and bus_shift.
>
> pci_generic_ecam_ops is still used for platforms free from quirks.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> arch/arm64/kernel/pci.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 94cd43c..a891bda 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
> struct pci_config_window *cfg;
> struct resource cfgres;
> unsigned int bsz;
> + struct pci_ecam_ops *ops;
>
> /* Use address from _CBA if present, otherwise lookup MCFG */
> if (!root->mcfg_addr)
> @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
> return NULL;
> }
>
> - bsz = 1 << pci_generic_ecam_ops.bus_shift;
> + ops = pci_mcfg_get_ops(root);
> + bsz = 1 << ops->bus_shift;
> cfgres.start = root->mcfg_addr + bus_res->start * bsz;
> cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
> cfgres.flags = IORESOURCE_MEM;
> - cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res,
> - &pci_generic_ecam_ops);
> + cfg = pci_ecam_create(&root->device->dev, &cfgres, bus_res, ops);
Arnd pointed this out already, I think that's the only pending question
here.
pci_ecam_create() maps ECAM space for config regions retrieved from
the MCFG, which are *supposed* to be ECAM compliant.
Do we think that's *always* correct/safe regardless of the kind
of quirk we are currently fixing up ?
Or we do think that configuration space regions should come from
a different resource declared in the ACPI namespace if the regions
are not MCFG/ECAM compliant (ie config space is not defined through
MCFG at all - possibly through a _CRS method for a vendor specific
_HID under the PNP0A03 node ?)
It might even be a choice we do not have anymore, but I think it
is important to make a decision and proceed accordingly.
Comments appreciated.
Thanks,
Lorenzo
> if (IS_ERR(cfg)) {
> dev_err(&root->device->dev, "%04x:%pR error %ld mapping ECAM\n",
> seg, bus_res, PTR_ERR(cfg));
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
next prev parent reply other threads:[~2016-06-16 17:48 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 15:34 [RFC PATCH v3 1/2] ACPI/PCI: Check platform specific ECAM quirks Christopher Covington
2016-06-15 15:34 ` Christopher Covington
2016-06-15 15:34 ` [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller Christopher Covington
2016-06-15 15:34 ` Christopher Covington
2016-06-16 17:48 ` Lorenzo Pieralisi [this message]
2016-06-16 17:48 ` Lorenzo Pieralisi
2016-06-17 8:01 ` Gabriele Paoloni
2016-06-17 8:01 ` Gabriele Paoloni
2016-06-17 14:13 ` Christopher Covington
2016-06-17 14:13 ` Christopher Covington
2016-06-16 17:10 ` [RFC PATCH v3 1/2] ACPI/PCI: Check platform specific ECAM quirks Lorenzo Pieralisi
2016-06-16 17:10 ` Lorenzo Pieralisi
2016-06-20 17:16 ` Lorenzo Pieralisi
2016-06-20 17:16 ` Lorenzo Pieralisi
2016-06-20 17:16 ` Lorenzo Pieralisi
2016-06-20 17:16 ` Lorenzo Pieralisi
2016-06-21 8:37 ` Ard Biesheuvel
2016-06-21 8:37 ` Ard Biesheuvel
2016-06-21 8:37 ` Ard Biesheuvel
2016-06-21 8:37 ` Ard Biesheuvel
-- strict thread matches above, loose matches on Subject: below --
2016-06-17 21:37 [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller Duc Dang
2016-06-20 9:42 ` Lorenzo Pieralisi
2016-06-20 9:42 ` Lorenzo Pieralisi
2016-06-20 17:17 ` Christopher Covington
2016-06-20 17:17 ` Christopher Covington
2016-06-20 19:12 ` Duc Dang
2016-06-20 19:12 ` Duc Dang
2016-06-21 8:42 ` Duc Dang
2016-06-21 8:42 ` Duc Dang
2016-06-21 9:26 ` Lorenzo Pieralisi
2016-06-21 9:26 ` Lorenzo Pieralisi
2016-06-21 9:29 ` Duc Dang
2016-06-21 9:29 ` Duc Dang
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=20160616174856.GB32388@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 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.