From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751304AbcDMPXN (ORCPT <rfc822;w@1wt.eu>);
	Wed, 13 Apr 2016 11:23:13 -0400
Received: from foss.arm.com ([217.140.101.70]:35470 "EHLO foss.arm.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751104AbcDMPXL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 13 Apr 2016 11:23:11 -0400
Subject: Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT)
 initial support.
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
References: <1459759975-24097-1-git-send-email-tn@semihalf.com>
 <1459759975-24097-5-git-send-email-tn@semihalf.com>
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
From: Marc Zyngier <marc.zyngier@arm.com>
Organization: ARM Ltd
Message-ID: <570E645A.9010600@arm.com>
Date: Wed, 13 Apr 2016 16:23:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Icedove/38.7.0
MIME-Version: 1.0
In-Reply-To: <1459759975-24097-5-git-send-email-tn@semihalf.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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