linux-kernel - Re: [BUG] Device unbound in a resumed state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 12 Mar 2016 14:25:04 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Ulf Hansson <ulf.hansson@...aro.org>,
	Kevin Hilman <khilman@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Krzysztof Kozlowski <k.kozlowski.k@...il.com>
Subject: Re: [BUG] Device unbound in a resumed state

2016-03-12 3:46 GMT+09:00 Alan Stern <stern@...land.harvard.edu>:
> 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