diff options
author | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2012-07-05 14:04:44 +0100 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2012-07-16 18:05:45 -0700 |
commit | 8153584e3fdf78753bf653d5f583b6ecb86e5e70 (patch) | |
tree | 34c5cc5b62d52ea9957919f938446f23161c2eb4 /include/linux/device.h | |
parent | 5a7689fd5b4f2094e7a32beae67f290f8619b042 (diff) | |
download | linux-stable-8153584e3fdf78753bf653d5f583b6ecb86e5e70.tar.gz linux-stable-8153584e3fdf78753bf653d5f583b6ecb86e5e70.tar.bz2 linux-stable-8153584e3fdf78753bf653d5f583b6ecb86e5e70.zip |
driver core: Move deferred devices to the end of dpm_list before probing
When deferred probe was originally added the idea was that devices which
defer their probes would move themselves to the end of dpm_list in order
to try to keep the assumptions that we're making about the list being in
roughly the order things should be suspended correct. However this hasn't
been what's been happening and doing it requires a lot of duplicated code
to do the moves.
Instead take a simple, brute force solution and have the deferred probe
code push devices to the end of dpm_list before it retries the probe. This
does mean we lock the dpm_list a bit more often but it's very simple and
the code shouldn't be a fast path. We do the move with the deferred mutex
dropped since doing things with fewer locks held simultaneously seems like
a good idea.
This approach was most recently suggested by Grant Likely.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'include/linux/device.h')
0 files changed, 0 insertions, 0 deletions