From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753278AbbIPAgY (ORCPT ); Tue, 15 Sep 2015 20:36:24 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:62747 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751929AbbIPAgU (ORCPT ); Tue, 15 Sep 2015 20:36:20 -0400 From: "Rafael J. Wysocki" To: Alan Stern Cc: "Rafael J. Wysocki" , Thierry Reding , Greg Kroah-Hartman , "Rafael J. Wysocki" , Grygorii Strashko , Tomeu Vizoso , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List Subject: Re: [PATCH] driver core: Ensure proper suspend/resume ordering Date: Wed, 16 Sep 2015 03:04:20 +0200 Message-ID: <1709892.G7PPnhBrZV@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/4.1.0-rc5+; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, September 15, 2015 10:23:07 AM Alan Stern wrote: > On Tue, 15 Sep 2015, Rafael J. Wysocki wrote: > > > Hi Alan, > > Hi. > > > On Sat, Sep 12, 2015 at 7:40 PM, Alan Stern wrote: > > > On Sat, 12 Sep 2015, Rafael J. Wysocki wrote: > > > > > >> On Friday, September 11, 2015 03:01:14 PM Alan Stern wrote: > > > > > >> > There's also an issue about other types of dependencies. For instance, > > >> > it's conceivable that device B might be discovered and depend on device > > >> > A, even before A has been bound to a driver. (B might be discovered by > > >> > A's subsystem rather than A's driver.) In that case, moving A to the > > >> > end of the list would cause B to come before A even though B depends on > > >> > A. Of course, deferred probing already has this problem. > > >> > > >> That may actually happen for PCIe ports and devices below them AFAICS. > > >> > > >> Devices below PCIe ports are discovered by the PCI subsystem and the PCIe > > >> ports need not be probed before those devices are probed. > > > > > > Is it possible to change this? Make it so that devices below PCIe > > > ports are discovered by the port driver rather than by the PCI > > > subsystem? Or would that be far too difficult? > > > > I don't think it would be really useful. > > > > PCIe ports are PCI bridges from the resource allocation and basic > > functionality perspective, so they are handled accordingly. > > > > The PCIe port driver provides additional services (such as PME/hotplug > > interrupt handling and advanced error reporting) that aren't necessary > > for probing devices below the ports. > > > > I guess the ordering of PCIe ports probing might be changed to happen > > at the "right" time, but care needs to be taken in that case too. > > Does suspending a PCIe port do anything significant? In particular, > does it cut off normal communication with anything attached through > the port? No, it doesn't. > If it does then we better not move the port device to the end of the > dpm_list after any descendant devices have been probed. > > > >> > An easy way to check for this sort of thing would be to verify that a > > >> > device about to be probed doesn't have any children. This wouldn't > > >> > catch all the potential dependencies, but it would be a reasonable > > >> > start. > > >> > > >> That would address the PCIe ports issue. > > > > > > Well, it would _detect_ the PCIe ports issue. > > > > That's what I meant. :-) > > > > > It might also detect other things. > > > > Right. > > All right, I'll try writing a test patch to report these things. OK, thanks! Rafael