All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Tomasz Nowicki <tn@semihalf.com>
Cc: arnd@arndb.de, will.deacon@arm.com, catalin.marinas@arm.com,
	rafael@kernel.org, hanjun.guo@linaro.org,
	Lorenzo.Pieralisi@arm.com, okaya@codeaurora.org,
	jchandra@broadcom.com, robert.richter@caviumnetworks.com,
	mw@semihalf.com, Liviu.Dudau@arm.com, ddaney@caviumnetworks.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,
	jcm@redhat.com, andrea.gallo@linaro.org, dhdang@apm.com,
	jeremy.linton@arm.com, liudongdong3@huawei.com,
	cov@codeaurora.org
Subject: Re: [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller
Date: Tue, 22 Nov 2016 17:13:21 -0600	[thread overview]
Message-ID: <20161122231321.GA20246@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <1465588519-11334-12-git-send-email-tn@semihalf.com>

Hi Tomasz,

On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
> Implement pci_acpi_scan_root and other arch-specific call so that ARM64
> can start using ACPI to setup and enumerate PCI buses.
> 
> Prior to buses enumeration the pci_acpi_scan_root() implementation looks
> for configuration space start address (obtained through ACPI _CBA method or
> MCFG interface). If succeed, it uses ECAM library to create new mapping.
> Then it attaches generic ECAM ops (pci_generic_ecam_ops) which are used
> for accessing configuration space later on.
> ...

> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> +	.release_info = pci_acpi_generic_release_info,
> +};
> +
> +/* Interface called from ACPI code to setup PCI host controller */
>  struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>  {
> -	/* TODO: Should be revisited when implementing PCI on ACPI */
> -	return NULL;
> +	int node = acpi_get_node(root->device->handle);
> +	struct acpi_pci_generic_root_info *ri;
> +	struct pci_bus *bus, *child;
> +
> +	ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> +	if (!ri)
> +		return NULL;
> +
> +	ri->cfg = pci_acpi_setup_ecam_mapping(root);
> +	if (!ri->cfg) {
> +		kfree(ri);
> +		return NULL;
> +	}
> +
> +	acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;

This has already been merged, but this isn't right, is it?  We're
writing a host controller-specific pointer into the single system-wide
acpi_pci_root_ops, then passing it on to acpi_pci_root_create().

Today, I think ri->cfg->ops->pci_ops is always &pci_generic_ecam_ops,
from this path:

  ri->cfg = pci_acpi_setup_ecam_mapping
    cfg = pci_ecam_create(..., &pci_generic_ecam_ops)
      cfg = kzalloc(...)
      cfg->ops = ops             # &pci_generic_ecam_ops

But we're about to merge the ECAM quirks series, which will mean it
may not be &pci_generic_ecam_ops.  Even apart from the ECAM quirks, we
should avoid this pattern of putting device-specific info in a single
shared structure because it's too difficult to verify that it's
correct.

> +	bus = acpi_pci_root_create(root, &acpi_pci_root_ops, &ri->common,
> +				   ri->cfg);

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Tomasz Nowicki <tn@semihalf.com>
Cc: rafael@kernel.org, linux-pci@vger.kernel.org,
	will.deacon@arm.com, okaya@codeaurora.org, wangyijing@huawei.com,
	andrea.gallo@linaro.org, Lorenzo.Pieralisi@arm.com,
	linaro-acpi@lists.linaro.org, ddaney@caviumnetworks.com,
	linux-acpi@vger.kernel.org, robert.richter@caviumnetworks.com,
	liudongdong3@huawei.com, catalin.marinas@arm.com,
	Liviu.Dudau@arm.com, arnd@arndb.de, jcm@redhat.com,
	msalter@redhat.com, cov@codeaurora.org, mw@semihalf.com,
	linux-arm-kernel@lists.infradead.org, jchandra@broadcom.com,
	dhdang@apm.com, linux-kernel@vger.kernel.org,
	jeremy.linton@arm.com, hanjun.guo@linaro.org,
	Suravee.Suthikulpanit@amd.com
Subject: Re: [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller
Date: Tue, 22 Nov 2016 17:13:21 -0600	[thread overview]
Message-ID: <20161122231321.GA20246@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <1465588519-11334-12-git-send-email-tn@semihalf.com>

Hi Tomasz,

On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
> Implement pci_acpi_scan_root and other arch-specific call so that ARM64
> can start using ACPI to setup and enumerate PCI buses.
> 
> Prior to buses enumeration the pci_acpi_scan_root() implementation looks
> for configuration space start address (obtained through ACPI _CBA method or
> MCFG interface). If succeed, it uses ECAM library to create new mapping.
> Then it attaches generic ECAM ops (pci_generic_ecam_ops) which are used
> for accessing configuration space later on.
> ...

> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> +	.release_info = pci_acpi_generic_release_info,
> +};
> +
> +/* Interface called from ACPI code to setup PCI host controller */
>  struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>  {
> -	/* TODO: Should be revisited when implementing PCI on ACPI */
> -	return NULL;
> +	int node = acpi_get_node(root->device->handle);
> +	struct acpi_pci_generic_root_info *ri;
> +	struct pci_bus *bus, *child;
> +
> +	ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> +	if (!ri)
> +		return NULL;
> +
> +	ri->cfg = pci_acpi_setup_ecam_mapping(root);
> +	if (!ri->cfg) {
> +		kfree(ri);
> +		return NULL;
> +	}
> +
> +	acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;

This has already been merged, but this isn't right, is it?  We're
writing a host controller-specific pointer into the single system-wide
acpi_pci_root_ops, then passing it on to acpi_pci_root_create().

Today, I think ri->cfg->ops->pci_ops is always &pci_generic_ecam_ops,
from this path:

  ri->cfg = pci_acpi_setup_ecam_mapping
    cfg = pci_ecam_create(..., &pci_generic_ecam_ops)
      cfg = kzalloc(...)
      cfg->ops = ops             # &pci_generic_ecam_ops

But we're about to merge the ECAM quirks series, which will mean it
may not be &pci_generic_ecam_ops.  Even apart from the ECAM quirks, we
should avoid this pattern of putting device-specific info in a single
shared structure because it's too difficult to verify that it's
correct.

> +	bus = acpi_pci_root_create(root, &acpi_pci_root_ops, &ri->common,
> +				   ri->cfg);

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller
Date: Tue, 22 Nov 2016 17:13:21 -0600	[thread overview]
Message-ID: <20161122231321.GA20246@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <1465588519-11334-12-git-send-email-tn@semihalf.com>

Hi Tomasz,

On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
> Implement pci_acpi_scan_root and other arch-specific call so that ARM64
> can start using ACPI to setup and enumerate PCI buses.
> 
> Prior to buses enumeration the pci_acpi_scan_root() implementation looks
> for configuration space start address (obtained through ACPI _CBA method or
> MCFG interface). If succeed, it uses ECAM library to create new mapping.
> Then it attaches generic ECAM ops (pci_generic_ecam_ops) which are used
> for accessing configuration space later on.
> ...

> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> +	.release_info = pci_acpi_generic_release_info,
> +};
> +
> +/* Interface called from ACPI code to setup PCI host controller */
>  struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>  {
> -	/* TODO: Should be revisited when implementing PCI on ACPI */
> -	return NULL;
> +	int node = acpi_get_node(root->device->handle);
> +	struct acpi_pci_generic_root_info *ri;
> +	struct pci_bus *bus, *child;
> +
> +	ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> +	if (!ri)
> +		return NULL;
> +
> +	ri->cfg = pci_acpi_setup_ecam_mapping(root);
> +	if (!ri->cfg) {
> +		kfree(ri);
> +		return NULL;
> +	}
> +
> +	acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;

This has already been merged, but this isn't right, is it?  We're
writing a host controller-specific pointer into the single system-wide
acpi_pci_root_ops, then passing it on to acpi_pci_root_create().

Today, I think ri->cfg->ops->pci_ops is always &pci_generic_ecam_ops,
from this path:

  ri->cfg = pci_acpi_setup_ecam_mapping
    cfg = pci_ecam_create(..., &pci_generic_ecam_ops)
      cfg = kzalloc(...)
      cfg->ops = ops             # &pci_generic_ecam_ops

But we're about to merge the ECAM quirks series, which will mean it
may not be &pci_generic_ecam_ops.  Even apart from the ECAM quirks, we
should avoid this pattern of putting device-specific info in a single
shared structure because it's too difficult to verify that it's
correct.

> +	bus = acpi_pci_root_create(root, &acpi_pci_root_ops, &ri->common,
> +				   ri->cfg);

Bjorn

  reply	other threads:[~2016-11-22 23:13 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-10 19:55 [PATCH V9 00/11] Support for ARM64 ACPI based PCI host controller Tomasz Nowicki
2016-06-10 19:55 ` Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 01/11] PCI/ECAM: Move ecam.h to linux/include/pci-ecam.h Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 02/11] PCI/ECAM: Add parent device field to pci_config_window Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 03/11] PCI: Add new function to unmap IO resources Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 04/11] ACPI/PCI: Support IO resources when parsing PCI host bridge resources Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 05/11] ACPI/PCI: Add generic MCFG table handling Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 23:25   ` Bjorn Helgaas
2016-06-10 23:25     ` Bjorn Helgaas
2016-06-10 19:55 ` [PATCH V9 06/11] PCI: Refactor generic bus domain assignment Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 20:50   ` Lorenzo Pieralisi
2016-06-10 20:50     ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 07/11] PCI: Factor DT specific pci_bus_find_domain_nr() code out Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 20:51   ` Lorenzo Pieralisi
2016-06-10 20:51     ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 08/11] ARM64/PCI: Add ACPI hook to assign domain number Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 23:36   ` Bjorn Helgaas
2016-06-10 23:36     ` Bjorn Helgaas
2016-06-13 10:00     ` Tomasz Nowicki
2016-06-13 10:00       ` Tomasz Nowicki
2016-06-13 10:40     ` Lorenzo Pieralisi
2016-06-13 10:40       ` Lorenzo Pieralisi
2016-06-13 15:56       ` Liviu.Dudau
2016-06-13 15:56         ` Liviu.Dudau at arm.com
2016-06-13 20:01       ` Duc Dang
2016-07-05  4:36         ` Duc Dang
2016-06-13 20:01         ` Duc Dang
2016-06-14  9:30         ` Lorenzo Pieralisi
2016-06-14  9:30           ` Lorenzo Pieralisi
2016-06-14  9:30           ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 10/11] ARM64/PCI: Implement ACPI low-level calls to access PCI_Config region from AML Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-06-10 20:54   ` Lorenzo Pieralisi
2016-06-10 20:54     ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller Tomasz Nowicki
2016-06-10 19:55   ` Tomasz Nowicki
2016-11-22 23:13   ` Bjorn Helgaas [this message]
2016-11-22 23:13     ` Bjorn Helgaas
2016-11-22 23:13     ` Bjorn Helgaas
2016-11-23 11:21     ` Tomasz Nowicki
2016-11-23 11:21       ` Tomasz Nowicki
2016-11-23 18:22       ` Bjorn Helgaas
2016-11-23 18:22         ` Bjorn Helgaas
2016-11-24 11:10         ` Tomasz Nowicki
2016-11-24 11:10           ` Tomasz Nowicki
2016-06-10 23:41 ` [PATCH V9 00/11] Support for ARM64 " Bjorn Helgaas
2016-06-10 23:41   ` Bjorn Helgaas
2016-06-10 23:50   ` Jon Masters
2016-06-10 23:50     ` Jon Masters
2016-06-10 23:50     ` Jon Masters
2016-06-10 23:58   ` [Linaro-acpi] " Jon Masters
2016-06-10 23:58     ` Jon Masters
2016-06-11  9:51   ` Tomasz Nowicki
2016-06-11  9:51     ` Tomasz Nowicki

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=20161122231321.GA20246@bhelgaas-glaptop.roam.corp.google.com \
    --to=helgaas@kernel.org \
    --cc=Liviu.Dudau@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=andrea.gallo@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=cov@codeaurora.org \
    --cc=ddaney@caviumnetworks.com \
    --cc=dhdang@apm.com \
    --cc=hanjun.guo@linaro.org \
    --cc=jchandra@broadcom.com \
    --cc=jcm@redhat.com \
    --cc=jeremy.linton@arm.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=liudongdong3@huawei.com \
    --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 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.