From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756161AbbCLTfW (ORCPT ); Thu, 12 Mar 2015 15:35:22 -0400 Received: from mail-oi0-f54.google.com ([209.85.218.54]:38061 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755597AbbCLTfO (ORCPT ); Thu, 12 Mar 2015 15:35:14 -0400 Date: Thu, 12 Mar 2015 14:35:05 -0500 From: Bjorn Helgaas To: Yijing Wang Cc: Jiang Liu , linux-pci@vger.kernel.org, Yinghai Lu , linux-kernel@vger.kernel.org, Marc Zyngier , linux-arm-kernel@lists.infradead.org, Russell King , x86@kernel.org, Thomas Gleixner , Benjamin Herrenschmidt , Rusty Russell , Tony Luck , linux-ia64@vger.kernel.org, "David S. Miller" , Guan Xuetao , linux-alpha@vger.kernel.org, linux-m68k@vger.kernel.org, Liviu Dudau , Arnd Bergmann , Geert Uytterhoeven , Konrad Rzeszutek Wilk , xen-devel@lists.xenproject.org Subject: Re: [PATCH v6 04/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented() Message-ID: <20150312193505.GB7346@google.com> References: <1425868467-9667-1-git-send-email-wangyijing@huawei.com> <1425868467-9667-5-git-send-email-wangyijing@huawei.com> <20150311223211.GB1082@google.com> <55017CA5.2010502@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55017CA5.2010502@huawei.com> 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, Mar 12, 2015 at 07:46:45PM +0800, Yijing Wang wrote: > >> struct pci_bus *b; > >> + LIST_HEAD(resources); > >> struct pcifront_sd *sd = NULL; > >> struct pci_bus_entry *bus_entry = NULL; > >> int err = 0; > >> @@ -470,17 +472,21 @@ static int pcifront_scan_root(struct pcifront_device *pdev, > >> err = -ENOMEM; > >> goto err_out; > >> } > >> + pci_add_resource(&resources, &ioport_resource); > >> + pci_add_resource(&resources, &iomem_resource); > >> + pci_add_resource(&resources, &busn_resource); > > > > Since I don't want to export busn_resource, you might have to allocate your > > own struct resource for it here. And, of course, figure out the details of > > which PCI domain you're in and whether you need to share one struct > > resource across several host bridges in the same domain. > > Allocate its own resource here is ok for me, as I mentioned in previous reply, > so do we still need to add additional info to figure out which domain own the bus resource ? That's up to the caller. Only the platform knows which bridges it wants to have in the same domain. In principle, every host bridge could be in its own domain, since each bridge is the root of a unique PCI hierarchy. But some platforms have firmware that assumes otherwise. I have no idea what xen assumes. > >> pcifront_init_sd(sd, domain, bus, pdev); > >> > >> pci_lock_rescan_remove(); > >> > >> - b = pci_scan_bus_parented(&pdev->xdev->dev, bus, > >> - &pcifront_bus_ops, sd); > >> + b = pci_scan_root_bus(&pdev->xdev->dev, bus, > >> + &pcifront_bus_ops, sd, &resources); > >> if (!b) { > >> dev_err(&pdev->xdev->dev, > >> "Error creating PCI Frontend Bus!\n"); > >> err = -ENOMEM; > >> pci_unlock_rescan_remove(); > >> + pci_free_resource_list(&resources); > >> goto err_out; > >> } > >> > >> @@ -488,7 +494,7 @@ static int pcifront_scan_root(struct pcifront_device *pdev, > >> > >> list_add(&bus_entry->list, &pdev->root_buses); > >> > >> - /* pci_scan_bus_parented skips devices which do not have a have > >> + /* pci_scan_root_bus skips devices which do not have a > >> * devfn==0. The pcifront_scan_bus enumerates all devfn. */ > >> err = pcifront_scan_bus(pdev, domain, bus, b); > >> > >> -- > >> 1.7.1 > >> > >> -- > >> 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 > > > > . > > > > > -- > Thanks! > Yijing > > -- > 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