Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751956AbcCLFZH (ORCPT ); Sat, 12 Mar 2016 00:25:07 -0500 Received: from mail-oi0-f50.google.com ([209.85.218.50]:33173 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751580AbcCLFZF (ORCPT ); Sat, 12 Mar 2016 00:25:05 -0500 MIME-Version: 1.0 In-Reply-To: References: <56E26EE9.8040400@samsung.com> Date: Sat, 12 Mar 2016 14:25:04 +0900 X-Google-Sender-Auth: ZNsbAbZ6TcWRy4YXVPdqtmLtKAw Message-ID: Subject: Re: [BUG] Device unbound in a resumed state From: Krzysztof Kozlowski To: Alan Stern Cc: Ulf Hansson , Kevin Hilman , "Rafael J. Wysocki" , Len Brown , Pavel Machek , "linux-pm@vger.kernel.org" , linux-kernel , Krzysztof Kozlowski , Krzysztof Kozlowski Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1834 Lines: 58 2016-03-12 3:46 GMT+09:00 Alan Stern : > On Fri, 11 Mar 2016, Krzysztof Kozlowski wrote: > >> Hi, >> >> >> Could be related (the same?) with [0]. >> >> I have a driver (hwrng/exynos-rng) which in probe does: >> pm_runtime_set_autosuspend_delay(&pdev->dev, EXYNOS_AUTOSUSPEND_DELAY); >> pm_runtime_use_autosuspend(&pdev->dev); >> pm_runtime_enable(&pdev->dev); >> >> and in remove: >> pm_runtime_disable(&pdev->dev) > > But not pm_runtime_dont_use_autosuspend()? Ahh, that one is missing. Thanks! > > Why disable runtime PM if you want the runtime-PM methods to put the > device into a low-power state? I don't want to play with runtime PM anymore at this time. I am removing the device so I am cleaning what was done in probe. Without the pm_runtime_disable() the next probe of device will trigger error of unbalanced enable: https://lkml.org/lkml/2016/3/11/59 > >> Just before unbinding in __device_release_driver() the device is resumed >> but unfortunately not suspended later. I mean the >> __device_release_driver()->pm_runtime_put_sync() does not trigger >> runtime suspend. > > Because autosuspend is still in use at this point. > >> This leads to leaving the device in active state (e.g. clocks enabled). >> >> It does not happen after removal of autosuspend. Also runtime suspend >> happens after very fast unbind-bind. > > Overall it sounds like the system is behaving the way it is supposed > to. > > But maybe we should make pm_runtime_use_autosuspend() call > pm_runtime_mark_last_busy(), to avoid the unbind - bind - immediate > autosuspend behavior. The need of disabling autosuspend was not quite obvious to me and I did not find information about it in documentation. However now it makes sense... I'll send a patch updating the docs. Thank you for feedback! Best regards, Krzysztof