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 <st...@rowland.harvard.edu> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
