Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753849Ab3F0NAK (ORCPT ); Thu, 27 Jun 2013 09:00:10 -0400 Received: from mga09.intel.com ([134.134.136.24]:31694 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753510Ab3F0NAF (ORCPT ); Thu, 27 Jun 2013 09:00:05 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,952,1363158000"; d="scan'208";a="336374200" Date: Thu, 27 Jun 2013 16:04:04 +0300 From: Mika Westerberg To: Yinghai Lu Cc: Greg Kroah-Hartman , Bjorn Helgaas , "Rafael J. Wysocki" , Jesse Barnes , John Ronciak , Miles J Penner , Bruce Allan , "Kirill A. Shutemov" , Heikki Krogerus , Linux Kernel Mailing List , "linux-pci@vger.kernel.org" , the arch/x86 maintainers Subject: Re: [PATCH 2/6] PCI: acpiphp: enable_device(): rescan even if no new devices on slot Message-ID: <20130627130404.GU9294@intel.com> References: <1372177330-28013-1-git-send-email-mika.westerberg@linux.intel.com> <1372177330-28013-3-git-send-email-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo 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 Content-Length: 3552 Lines: 78 On Wed, Jun 26, 2013 at 06:20:24PM -0700, Yinghai Lu wrote: > On Tue, Jun 25, 2013 at 9:22 AM, Mika Westerberg > wrote: > > From: "Kirill A. Shutemov" > > > > pci_scan_slot() returns number of new devices connected *directly* > > connected to the slot. Current enable_device() checks the return value > > and stops if it doesn't see a new device. > > > > In Thunderbolt chaining case the new device can be deeper in hierarchy, so > > do the rescan anyway. > > > > Because of that we must make sure that pcibios_resource_survey_bus() and > > check_hotplug_bridge() get called only for a just found bus and not the > > ones already added to the system. Failure to do so will lead to resource > > conflicts. > > > > Signed-off-by: Kirill A. Shutemov > > Signed-off-by: Mika Westerberg > > --- > > drivers/pci/hotplug/acpiphp_glue.c | 18 +++++++----------- > > 1 file changed, 7 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c > > index b983e29..80a6ea1 100644 > > --- a/drivers/pci/hotplug/acpiphp_glue.c > > +++ b/drivers/pci/hotplug/acpiphp_glue.c > > @@ -685,18 +685,13 @@ static int __ref enable_device(struct acpiphp_slot *slot) > > struct pci_dev *dev; > > struct pci_bus *bus = slot->bridge->pci_bus; > > struct acpiphp_func *func; > > - int num, max, pass; > > + int max, pass; > > LIST_HEAD(add_list); > > > > list_for_each_entry(func, &slot->funcs, sibling) > > acpiphp_bus_add(func); > > > > - num = pci_scan_slot(bus, PCI_DEVFN(slot->device, 0)); > > - if (num == 0) { > > - /* Maybe only part of funcs are added. */ > > - dbg("No new device found\n"); > > - goto err_exit; > > - } > > + pci_scan_slot(bus, PCI_DEVFN(slot->device, 0)); > > > > max = acpiphp_max_busnr(bus); > > for (pass = 0; pass < 2; pass++) { > > @@ -707,8 +702,11 @@ static int __ref enable_device(struct acpiphp_slot *slot) > > dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) { > > max = pci_scan_bridge(bus, dev, max, pass); > > if (pass && dev->subordinate) { > > - check_hotplug_bridge(slot, dev); > > - pcibios_resource_survey_bus(dev->subordinate); > > + if (!dev->subordinate->is_added) { > > + check_hotplug_bridge(slot, dev); > > + pcibios_resource_survey_bus( > > + dev->subordinate); > > + } > > No, > this change will totally disable calling > check_hotplug_bridge/pcibios_resource_survey_bus() > > as pci_scan_bridge/pci_scan_child_bus will set dev->subordinate->is_added... > > Please note: recently is_added setting is moved early before > pci_bus_add_devices... OK, thanks. We will handle this in pcibios_resource_survey_bus() instead as suggested by Bjorn. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/