lkml.org 
[lkml]   [2020]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH AUTOSEL 4.19 70/87] driver core: Reorder devices on successful probe
    Date
    From: Thierry Reding <treding@nvidia.com>

    [ Upstream commit 5b6164d3465fcc13b5679c860c452963443172a7 ]

    Device drivers usually depend on the fact that the devices that they
    control are suspended in the same order that they were probed in. In
    most cases this is already guaranteed via deferred probe.

    However, there's one case where this can still break: if a device is
    instantiated before a dependency (for example if it appears before the
    dependency in device tree) but gets probed only after the dependency is
    probed. Instantiation order would cause the dependency to get probed
    later, in which case probe of the original device would be deferred and
    the suspend/resume queue would get reordered properly. However, if the
    dependency is provided by a built-in driver and the device depending on
    that driver is controlled by a loadable module, which may only get
    loaded after the root filesystem has become available, we can be faced
    with a situation where the probe order ends up being different from the
    suspend/resume order.

    One example where this happens is on Tegra186, where the ACONNECT is
    listed very early in device tree (sorted by unit-address) and depends on
    BPMP (listed very late because it has no unit-address) for power domains
    and clocks/resets. If the ACONNECT driver is built-in, there is no
    problem because it will be probed before BPMP, causing a probe deferral
    and that in turn reorders the suspend/resume queue. However, if built as
    a module, it will end up being probed after BPMP, and therefore not
    result in a probe deferral, and therefore the suspend/resume queue will
    stay in the instantiation order. This in turn causes problems because
    ACONNECT will be resumed before BPMP, which will result in a hang
    because the ACONNECT's power domain cannot be powered on as long as the
    BPMP is still suspended.

    Fix this by always reordering devices on successful probe. This ensures
    that the suspend/resume queue is always in probe order and hence meets
    the natural expectations of drivers vs. their dependencies.

    Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
    Acked-by: Rafael. J. Wysocki <rafael@kernel.org>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20201203175756.1405564-1-thierry.reding@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    ---
    drivers/base/dd.c | 7 +++++++
    1 file changed, 7 insertions(+)

    diff --git a/drivers/base/dd.c b/drivers/base/dd.c
    index 4ba9231a6be80..bbb2f72819184 100644
    --- a/drivers/base/dd.c
    +++ b/drivers/base/dd.c
    @@ -334,6 +334,13 @@ static void driver_bound(struct device *dev)

    device_pm_check_callbacks(dev);

    + /*
    + * Reorder successfully probed devices to the end of the device list.
    + * This ensures that suspend/resume order matches probe order, which
    + * is usually what drivers rely on.
    + */
    + device_pm_move_to_tail(dev);
    +
    /*
    * Make sure the device is no longer in one of the deferred lists and
    * kick off retrying all pending devices
    --
    2.27.0
    \
     
     \ /
      Last update: 2020-12-23 03:43    [W:2.260 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site