From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753761AbbIPNio (ORCPT ); Wed, 16 Sep 2015 09:38:44 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:57409 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752633AbbIPNim (ORCPT ); Wed, 16 Sep 2015 09:38:42 -0400 Subject: Re: [PATCH] driver core: Ensure proper suspend/resume ordering To: "Rafael J. Wysocki" , Alan Stern References: <1475011.GNmxQvg88W@vostro.rjw.lan> CC: Thierry Reding , Greg Kroah-Hartman , "Rafael J. Wysocki" , Tomeu Vizoso , , From: Grygorii Strashko Message-ID: <55F970D8.1090205@ti.com> Date: Wed, 16 Sep 2015 16:38:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1475011.GNmxQvg88W@vostro.rjw.lan> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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