Re: [PATCH] driver core: Ensure proper suspend/resume ordering

From: Rafael J. Wysocki
Date: Tue Sep 15 2015 - 20:36:27 EST


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 <stern@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/