From patchwork Thu Oct 30 20:03:51 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 5200251 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 72C669F30B for ; Thu, 30 Oct 2014 20:04:45 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7E30120253 for ; Thu, 30 Oct 2014 20:04:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B23020173 for ; Thu, 30 Oct 2014 20:04:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932513AbaJ3UEm (ORCPT ); Thu, 30 Oct 2014 16:04:42 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:57180 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932072AbaJ3UEm (ORCPT ); Thu, 30 Oct 2014 16:04:42 -0400 Received: from wuerfel.localnet ([134.3.133.35]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0M5UF6-1XzEoN0goK-00xe7j; Thu, 30 Oct 2014 21:03:55 +0100 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Jason Gunthorpe , Phil Edworthy , Lorenzo Pieralisi , Russell King , "linux-pci@vger.kernel.org" , Jingoo Han , Liviu Dudau , Krzysztof Halasa , Mohit Kumar , Bjorn Helgaas Subject: Re: [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain Date: Thu, 30 Oct 2014 21:03:51 +0100 Message-ID: <2033107.209JbeZvkg@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20141030193538.GK26820@obsidianresearch.com> References: <1414669490-1217-1-git-send-email-lorenzo.pieralisi@arm.com> <3532414.9PZuBnKWYz@wuerfel> <20141030193538.GK26820@obsidianresearch.com> MIME-Version: 1.0 X-Provags-ID: V03:K0:3mBOeBBiacjkaV9Iawxn+eDO9xtv4nQp8KR1P8u1JL7eqJ2muTF B/WyxxKzb6wTP1XjbfAkpF8e3Yrw2t3StrFOyfvKrwTI6piW6KFpJXVg27z8RL6DpUXSOYo KwpQfavYmnDvQkwpBtJ3vEI/WXdT8fGLzv70mHoAdDXEOYjEhq55JHG6D77DKb363LDTuaR FJpqGBCNi9EolAEmv77BQ== X-UI-Out-Filterresults: notjunk:1; Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thursday 30 October 2014 13:35:38 Jason Gunthorpe wrote: > On Thu, Oct 30, 2014 at 08:21:40PM +0100, Arnd Bergmann wrote: > > > > So how does mvebu now allocate a unique domain number per mvebu_pcie? > > > > I believe the answer to that is that the mvebu PCIe driver currently only > > supports one domain, and it will have the unique number '0', which is the > > default. > > It is like most of the the other new drivers, each mvebu_pcie_probe > expects to create a new domain with a unique bus number set for that > platform_device. AFAIK everything is uniq'd to the struct mcebu_pcie, > so there is nothing precluding the driver from being instantiated > twice. > > Indeed, the way mvebu hardware works you could actually create a DT > that assigned some ports to one domain and some other ports to a > different domain, using two platform_devices. All that was missing > from the driver was to increment the domain number. Right, makes sense. > I think Lorenzo's patches improve this, at least it appears that > unique domain numbers are now being assigned, I'm not sure - I'm a > little confused how we can safely blindly apply the new domain logic > without the driver opt'ing in.... I think it will just work: the host driver should not care about the particular domain number, it just needs to be unique, which the core now ensures. > I thought older PCI platforms tended to call pci_common_init for each > physical PCI bus, and we don't want them to suddenly have non-zero > domain numbers?? Only cns3xxx calls pci_common_init with fixed domain numbers, and Lorenzo's patch 1/2 changes it. All other drivers fall into one of three categories: a) there is only ever one host bridge b) There are multiple host bridges, but they are all in the same domain, and the driver calls pci_common_init() once to initialize them all, and pci_common_init calls back into the driver with the hw_pci->setup() function passing the instance number. c) The driver calls pci_common_init_dev() for each new host bridge and assigns a new domain every time but never has more than one host bridge per domain. a) and b) are not impacted by this patch, while c) becomes simpler. BTW, pci-mvebu is currently the only driver using c) with pci_common_init rather than pci_common_init_dev. We should probably apply this trivial patch to make it more consistent: Arnd --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c index b1315e197ffb..efe4bd370b37 100644 --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -825,7 +825,7 @@ static void mvebu_pcie_enable(struct mvebu_pcie *pcie) hw.align_resource = mvebu_pcie_align_resource; hw.add_bus = mvebu_pcie_add_bus; - pci_common_init(&hw); + pci_common_init_dev(&pcie->pdev.dev, &hw); } /*