From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Subject: Re: [PATCH v6 04/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented() Date: Thu, 12 Mar 2015 14:35:05 -0500 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 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=XEoUuLiDLBPRT4CsFenIT4kyzI+FF/TKSWC16jjRgXo=; b=Grh/U2ZD1Zbm7ZT2jXwu2YhgCxnSxNvMWDhehwtnTa4BFOWbLas9Gyt5h5Cv+EA7M6 KjN7MfHdOtgyPdunSBx/oln+s2ZnHy7oVTWHrbuJC5yr6gXID+ZMiqlRcgxOKHmQUBxE wINVshDo0onhLVbNbehls3ALX/ewOh792mIctFDeaNuz5QAzc39d0KMVRz6R8QXeHYCx Eq6hY29YBNFvKbGfNIirau5N07II3Mn2PqlJMMUNp3RWykJTKU6KSE4y4RGHWqlHCeA7 FO3BvVpApA75SkX8x/ZB8Jv9mZCpWxNuzfqiGxNRuiQ4IOqO2bd3tYVNlxBn4fZntYpA vtdQ== Content-Disposition: inline In-Reply-To: <55017CA5.2010502@huawei.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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@lists.linux-m68k.org, Liviu Dudau , Arnd Bergmann , Geert Uytterhoeven , Konrad Rzeszutek Wilk , xen-devel@lists.xenproject.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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Date: Thu, 12 Mar 2015 19:35:05 +0000 Subject: Re: [PATCH v6 04/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented() Message-Id: <20150312193505.GB7346@google.com> List-Id: 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> In-Reply-To: <55017CA5.2010502@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: bhelgaas@google.com (Bjorn Helgaas) Date: Thu, 12 Mar 2015 14:35:05 -0500 Subject: [PATCH v6 04/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented() In-Reply-To: <55017CA5.2010502@huawei.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> Message-ID: <20150312193505.GB7346@google.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 at 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 at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html 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