From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754597AbaGKOLk (ORCPT ); Fri, 11 Jul 2014 10:11:40 -0400 Received: from fw-tnat.austin.arm.com ([217.140.110.23]:40554 "EHLO collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753960AbaGKOLh (ORCPT ); Fri, 11 Jul 2014 10:11:37 -0400 Date: Fri, 11 Jul 2014 15:11:16 +0100 From: Catalin Marinas To: Bjorn Helgaas Cc: Liviu Dudau , linux-pci , Will Deacon , Benjamin Herrenschmidt , Arnd Bergmann , linaro-kernel , Tanmay Inamdar , Grant Likely , Sinan Kaya , Jingoo Han , Kukjin Kim , Suravee Suthikulanit , LKML , Device Tree ML , LAKML Subject: Re: [PATCH v8 6/9] pci: Introduce a domain number for pci_host_bridge. Message-ID: <20140711141115.GB16321@arm.com> References: <1404240214-9804-1-git-send-email-Liviu.Dudau@arm.com> <1404240214-9804-7-git-send-email-Liviu.Dudau@arm.com> <20140708005954.GC22939@google.com> <20140708104655.GC6501@e106497-lin.cambridge.arm.com> <20140708224847.GC4980@e106497-lin.cambridge.arm.com> <20140710094758.GA6501@e106497-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Thread-Topic: [PATCH v8 6/9] pci: Introduce a domain number for pci_host_bridge. Accept-Language: en-GB, en-US Content-Language: en-US acceptlanguage: en-GB, en-US User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 10, 2014 at 11:36:10PM +0100, Bjorn Helgaas wrote: > Most of the rest of the v7 discussion was about "Introduce a domain > number for pci_host_bridge." I think we should add arm64 using the > existing pci_scan_root_bus() and keep the domain number in the arm64 > sysdata structure like every other arch does. Isn't that feasible? > We can worry about domain unification later. I think that's what we were trying to avoid, adding an arm64-specific pci_sys_data structure (and arm64-specific API). IIUC, avoiding this would allow the host controller drivers to use the sysdata pointer for their own private data structures. Also since you can specify the domain number via DT (and in Liviu's v8 patches read by of_create_pci_host_bridge), I think it would make sense to have it stored in some generic data structures (e.g. pci_host_bridge) rather than in an arm64 private sysdata. (Liviu is thinking of an alternative API but maybe he could briefly describe it here before posting a new series) -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Fri, 11 Jul 2014 15:11:16 +0100 Subject: [PATCH v8 6/9] pci: Introduce a domain number for pci_host_bridge. In-Reply-To: References: <1404240214-9804-1-git-send-email-Liviu.Dudau@arm.com> <1404240214-9804-7-git-send-email-Liviu.Dudau@arm.com> <20140708005954.GC22939@google.com> <20140708104655.GC6501@e106497-lin.cambridge.arm.com> <20140708224847.GC4980@e106497-lin.cambridge.arm.com> <20140710094758.GA6501@e106497-lin.cambridge.arm.com> Message-ID: <20140711141115.GB16321@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jul 10, 2014 at 11:36:10PM +0100, Bjorn Helgaas wrote: > Most of the rest of the v7 discussion was about "Introduce a domain > number for pci_host_bridge." I think we should add arm64 using the > existing pci_scan_root_bus() and keep the domain number in the arm64 > sysdata structure like every other arch does. Isn't that feasible? > We can worry about domain unification later. I think that's what we were trying to avoid, adding an arm64-specific pci_sys_data structure (and arm64-specific API). IIUC, avoiding this would allow the host controller drivers to use the sysdata pointer for their own private data structures. Also since you can specify the domain number via DT (and in Liviu's v8 patches read by of_create_pci_host_bridge), I think it would make sense to have it stored in some generic data structures (e.g. pci_host_bridge) rather than in an arm64 private sysdata. (Liviu is thinking of an alternative API but maybe he could briefly describe it here before posting a new series) -- Catalin