| Message ID | 2927655.Y1qg3UnIrE@aspire.rjw.lan (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
Hi, On Tuesday 10 July 2018 05:05 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Commit 52cdbdd49853 (driver core: correct device's shutdown order) > introduced a regression by breaking device shutdown on some systems. > > Namely, the devices_kset_move_last() call in really_probe() added by > that commit is a mistake as it may cause parents to follow children > in the devices_kset list which then causes shutdown to fail. For > example, if a device has children before really_probe() is called > for it (which is not uncommon), that call will cause it to be > reordered after the children in the devices_kset list and the > ordering of that list will not reflect the correct device shutdown > order any more. > > Also it causes the devices_kset list to be constantly reordered > until all drivers have been probed which is totally pointless > overhead in the majority of cases and it only covers an issue > with system shutdown, while system-wide suspend/resume potentially > has the same issue on the affected platforms (which is not covered). > > For that reason, revert the really_probe() modifications made by > commit 52cdbdd49853 which unfortunately will expose the shutdown > issue the problematic commit attempted to fix (and which will have > to be addressed differently and correctly in the future). > > The other code changes made by commit 52cdbdd49853 are useful and > they need not be reverted. > > Fixes: 52cdbdd49853 (driver core: correct device's shutdown order) > Link: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/ > Reported-by: Pingfan Liu <kernelfans@gmail.com> > Tested-by: Pingfan Liu <kernelfans@gmail.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- This issue because of which 52cdbdd49853 (driver core: correct device's shutdown order) was added is not present from 4.18, since dra7 started using sdhci-omap.c driver which doesn't disable regulator during shutdown. (The original issue was present in omap_hsmmc driver). When sdhci-omap driver is modified to disable regulator during shutdown, something like device_link_add() can be added in _regulator_get(). Since this doesn't reintroduce the problem that was solved by 52cdbdd49853, this can be safely merged. Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Thanks Kishon
Hi, On Tue, Jul 10, 2018 at 2:22 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote: > Hi, > > On Tuesday 10 July 2018 05:05 PM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> Commit 52cdbdd49853 (driver core: correct device's shutdown order) >> introduced a regression by breaking device shutdown on some systems. >> >> Namely, the devices_kset_move_last() call in really_probe() added by >> that commit is a mistake as it may cause parents to follow children >> in the devices_kset list which then causes shutdown to fail. For >> example, if a device has children before really_probe() is called >> for it (which is not uncommon), that call will cause it to be >> reordered after the children in the devices_kset list and the >> ordering of that list will not reflect the correct device shutdown >> order any more. >> >> Also it causes the devices_kset list to be constantly reordered >> until all drivers have been probed which is totally pointless >> overhead in the majority of cases and it only covers an issue >> with system shutdown, while system-wide suspend/resume potentially >> has the same issue on the affected platforms (which is not covered). >> >> For that reason, revert the really_probe() modifications made by >> commit 52cdbdd49853 which unfortunately will expose the shutdown >> issue the problematic commit attempted to fix (and which will have >> to be addressed differently and correctly in the future). >> >> The other code changes made by commit 52cdbdd49853 are useful and >> they need not be reverted. >> >> Fixes: 52cdbdd49853 (driver core: correct device's shutdown order) >> Link: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/ >> Reported-by: Pingfan Liu <kernelfans@gmail.com> >> Tested-by: Pingfan Liu <kernelfans@gmail.com> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> --- > > This issue because of which 52cdbdd49853 (driver core: correct device's > shutdown order) was added is not present from 4.18, since dra7 started using > sdhci-omap.c driver which doesn't disable regulator during shutdown. (The > original issue was present in omap_hsmmc driver). > > When sdhci-omap driver is modified to disable regulator during shutdown, > something like device_link_add() can be added in _regulator_get(). > > Since this doesn't reintroduce the problem that was solved by 52cdbdd49853, > this can be safely merged. This is very useful information, let me add it to the patch changelog. > Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Thank you!
Index: linux-pm/drivers/base/dd.c =================================================================== --- linux-pm.orig/drivers/base/dd.c +++ linux-pm/drivers/base/dd.c @@ -434,14 +434,6 @@ re_probe: goto probe_failed; } - /* - * Ensure devices are listed in devices_kset in correct order - * It's important to move Dev to the end of devices_kset before - * calling .probe, because it could be recursive and parent Dev - * should always go first - */ - devices_kset_move_last(dev); - if (dev->bus->probe) { ret = dev->bus->probe(dev); if (ret)