linux-kernel - Re: [RESEND][PATCH v2] i2c: designwear: Fix clk warning on suspend/resume

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]

Message-ID: <4d9af49e-99a4-1647-bbbb-3f146b991209@linux.intel.com>
Date:   Thu, 30 Mar 2017 15:39:37 +0300
From:   Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Wolfram Sang <wsa@...-dreams.de>, linux-i2c@...r.kernel.org
Subject: Re: [RESEND][PATCH v2] i2c: designwear: Fix clk warning on
 suspend/resume

Hi

On 03/30/2017 06:26 AM, John Stultz wrote:
> On my HiKey board, I'm seeing clk warnings on suspend/resume,
> which seem to be caused by runtime pm suspending the device,
> then the same suspend hook being called again on suspend time.
>
> This patch fixes this by setting the SYSTEM_SLEEP_PM_OPS to
> using pm_runtime_force_suspend and  pm_runtime_force_resume.
>
> Cc: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
> Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@...ux.intel.com>
> Cc: Wolfram Sang <wsa@...-dreams.de>
> Cc: linux-i2c@...r.kernel.org
> Suggested-by: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
> Signed-off-by: John Stultz <john.stultz@...aro.org>
> ---
> v2: Switch to suggested fix by Jarkko.
> ---
>  drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 79c4b4e..286447c 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -382,7 +382,7 @@ static int dw_i2c_plat_resume(struct device *dev)
>  static const struct dev_pm_ops dw_i2c_dev_pm_ops = {
>  	.prepare = dw_i2c_plat_prepare,
>  	.complete = dw_i2c_plat_complete,
> -	SET_SYSTEM_SLEEP_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume)
> +	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
>  	SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL)

We cannot do this since it will break our platforms that use the 
drivers/acpi/acpi_lpss.c power domain. Reason why it fails the 
pm_runtime_force_suspend() forces acpi_lpss to power down too early 
before suspend_late state where context is expected to be saved during 
system suspend.

acpi_lpss.c power domain
.suspend = acpi_subsys_suspend
-> pm_runtime_resume
    -> acpi_lpss_runtime_resume
       -> pm_generic_runtime_resume
          -> dw_i2c_plat_resume
-> pm_generic_suspend
    -> pm_runtime_force_suspend
       -> goes through __rpm_get_callback which selects domain ops
          -> acpi_lpss_runtime_suspend (context save + power down)
             -> pm_generic_runtime_suspend
                -> dw_i2c_plat_suspend
...
.suspend_late = acpi_lpss_suspend_late
-> acpi_lpss is already power gated here due acpi_lpss_runtime_suspend() 
done during suspend phase and context save will save just 0xFFs and 
resume restores wrong context.

I managed to found a use case where I'm able to trigger 
dw_i2c_plat_suspend() callback twice during suspend. Quite deep dive to 
PM core, lot of debugging and end result is a trivial patch that just 
checks is i2c-designware runtime suspended in its suspend/resume 
callbacks... This feels somewhat boilerplate and I figured also an 
alternative solution to PM core.

I just sent that patch out and I Cc'ed both you and Rafael so he can 
comment is this the right thing to do in driver or should it be fixed in 
the PM core.

-- 
Jarkko