Messages in this thread | | | Subject | Re: [PATCH] driver core: Ensure proper suspend/resume ordering | From | Grygorii Strashko <> | Date | Wed, 16 Sep 2015 16:38:32 +0300 |
| |
On 09/16/2015 04:28 AM, Rafael J. Wysocki wrote: > On Tuesday, September 15, 2015 03:18:19 PM Alan Stern wrote: >> On Tue, 15 Sep 2015, Thierry Reding wrote: >> >>>> There are a few things to watch out for. Since the dpm_list gets >>>> modified during system sleep transitions, we would have to make sure >>>> that nothing gets probed during those times. In principle, that's what >>>> the "prepare" stage is meant for, but there's still a race. As long as >>>> no other kernel thread (such as the deferred probing mechanism) tries >>>> to probe a device once everything has been frozen, we should be okay. >>>> But if not, there will be trouble -- after the ->prepare callback runs, >>>> the device is no longer on the dpm_list and so we don't want this patch >>>> to put it back on that list. >>> >>> Perhaps moving to the end of the list needs to be a little smarter. That >>> is it could check whether the device has been prepared for suspension or >>> not and only move when it hasn't? >> >> Maybe. But doesn't that mean it won't solve your problem completely? >> >>> Then again, shouldn't the core even prohibit new probes once the suspend >>> has been triggered? Sounds like asking for a lot of trouble if it didn't >>> ... >> >> The core prohibits new devices from being registered. It does not >> prohibit probes of existing devices, because they currently do not >> affect the dpm_list.
Seems I missed smth, but I can't find the place in Kernel that prohibits creation of new devices during suspend.
Could someone point me on, please?
-- regards, -grygorii
| |