linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Tomasz Nowicki <tn@semihalf.com>,
	tglx@linutronix.de, jason@lakedaemon.net, rjw@rjwysocki.net,
	lorenzo.pieralisi@arm.com, robert.richter@caviumnetworks.com,
	shijie.huang@arm.com, Suravee.Suthikulpanit@amd.com,
	hanjun.guo@linaro.org
Cc: al.stone@linaro.org, mw@semihalf.com, graeme.gregory@linaro.org,
	Catalin.Marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, ddaney.cavm@gmail.com,
	okaya@codeaurora.org
Subject: Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
Date: Wed, 13 Apr 2016 16:23:06 +0100	[thread overview]
Message-ID: <570E645A.9010600@arm.com> (raw)
In-Reply-To: <1459759975-24097-5-git-send-email-tn@semihalf.com>

On 04/04/16 09:52, Tomasz Nowicki wrote:
> IORT shows representation of IO topology for ARM based systems.
> It describes how various components are connected together on
> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
> 
> Initial support allows to:
> - register ITS MSI chip along with ITS translation ID and domain token
> - deregister ITS MSI chip based on ITS translation ID
> - find registered domain token based on ITS translation ID
> - map MSI RID based on PCI device and requester ID
> - find domain token based on PCI device and requester ID
> 
> To: Rafael J. Wysocki <rjw@rjwysocki.net>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
>  drivers/acpi/Kconfig    |   3 +
>  drivers/acpi/Makefile   |   1 +
>  drivers/acpi/iort.c     | 335 ++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/irqchip/Kconfig |   1 +
>  include/linux/iort.h    |  31 +++++
>  5 files changed, 371 insertions(+)
>  create mode 100644 drivers/acpi/iort.c
>  create mode 100644 include/linux/iort.h
> 

[...]

> +static acpi_status
> +iort_find_dev_callback(struct acpi_iort_node *node, void *context)
> +{
> +	struct acpi_iort_root_complex *pci_rc;
> +	struct device *dev = context;
> +	struct pci_bus *bus;
> +
> +	switch (node->type) {
> +	case ACPI_IORT_NODE_PCI_ROOT_COMPLEX:
> +		bus = to_pci_bus(dev);
> +		pci_rc = (struct acpi_iort_root_complex *)node->node_data;
> +
> +		/*
> +		 * It is assumed that PCI segment numbers maps one-to-one
> +		 * with root complexes. Each segment number can represent only
> +		 * one root complex.
> +		 */
> +		if (pci_rc->pci_segment_number == pci_domain_nr(bus))
> +			return AE_OK;

What guarantees that this is ever valid? As far as I know, pci_domain_nr
is completely arbitrary, and depends both on the probe order and the
phase of the moon. If you want this to be reliable, you need to allocate
the domain number from pci_segment_number.

I must be missing something. Care to shed some light on this?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2016-04-13 15:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-04  8:52 [PATCH V4 0/7] Introduce ACPI world to ITS irqchip Tomasz Nowicki
2016-04-04  8:52 ` [PATCH V4 1/7] acpi, pci: Setup MSI domain on a per-devices basis Tomasz Nowicki
2016-04-13 10:18   ` Marc Zyngier
2016-04-13 10:49     ` Tomasz Nowicki
2016-04-04  8:52 ` [PATCH V4 2/7] irqchip, GICv3, ITS: Cleanup for ITS domain initialization Tomasz Nowicki
2016-04-13 14:18   ` Marc Zyngier
2016-04-04  8:52 ` [PATCH V4 3/7] irqchip, GICv3, ITS: Refator ITS DT init code to prepare for ACPI Tomasz Nowicki
2016-04-12 10:18   ` Tomasz Nowicki
2016-04-13 15:09   ` Marc Zyngier
2016-04-04  8:52 ` [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support Tomasz Nowicki
2016-04-13 15:23   ` Marc Zyngier [this message]
2016-04-13 15:36     ` Tomasz Nowicki
2016-04-13 15:52       ` Marc Zyngier
2016-04-13 21:18         ` Sinan Kaya
2016-04-14  7:20           ` Tomasz Nowicki
2016-04-14  7:36             ` Marc Zyngier
2016-04-14 11:37               ` okaya
2016-04-14 11:48                 ` Marc Zyngier
2016-04-14  7:39         ` Tomasz Nowicki
2016-04-14  7:46           ` Marc Zyngier
2016-04-04  8:52 ` [PATCH V4 5/7] irqchip, gicv3, its: Probe ITS in the ACPI way Tomasz Nowicki
2016-04-14  9:01   ` Marc Zyngier
2016-04-04  8:52 ` [PATCH V4 6/7] its, pci, msi: Factor out code that might be reused for ACPI Tomasz Nowicki
2016-04-04  8:52 ` [PATCH V4 7/7] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization Tomasz Nowicki
2016-04-12  7:39 ` [PATCH V4 0/7] Introduce ACPI world to ITS irqchip 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=570E645A.9010600@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=al.stone@linaro.org \
    --cc=ddaney.cavm@gmail.com \
    --cc=graeme.gregory@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mw@semihalf.com \
    --cc=okaya@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=robert.richter@caviumnetworks.com \
    --cc=shijie.huang@arm.com \
    --cc=tglx@linutronix.de \
    --cc=tn@semihalf.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 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).