Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Geert Uytterhoeven]

Hi Ulf,

On Wed, Jun 29, 2016 at 7:30 PM, Ulf Hansson  wrote:
> On 28 June 2016 at 18:26, Geert Uytterhoeven  wrote:
>> This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on
>
> Thanks for reporting!
>
>> sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller 
>> is a
>> child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
>> simple-pm-bus, cfr.
>>
>> arch/arm/boot/dts/r8a73a4-ape6evm.dts
>> arch/arm/boot/dts/r8a73a4.dtsi
>> arch/arm/boot/dts/sh73a0-kzm9g.dts
>> arch/arm/boot/dts/sh73a0.dtsi
>>
>> During resume, the bus clock is not enabled, causing an imprecise abort
>> when accessing the Ethernet controller's registers. With some debug code
>> added:
>
> I was looking into this in some more detail.
>
> As you are stating that Ethernet device is a child device to the local
> bus device, I would have expected that the pm_runtime_get_sync()
> invoked during ->probe() in the Ethernet driver should cause its
> parent device (the bus device) to be "forced" resumed.
>
> That's because the pm_runtime_get_sync() should trigger an increased
> usage count of the parent device. Later, when
> pm_runtime_force_resume() validates the count for the bus device, it
> should be 2 and thus it should lead to that it decides to *not* defer
> the resume of the device. Apparently this isn't happening for some
> reason...
>
> Perhaps there's a pm_suspend_ignore_children() set for the parent?
> Or perhaps the parent/child relationship isn't set up correctly?

No, ignore_children = 0. I've dumped all fields from the bus' prepare
callback I had added for Kevin's test:

PM: Suspending system (mem)
simple-pm-bus fec1.bus: simple_pm_bus_prepare
can_wakeup = 0
async_suspend = 0
is_prepared = 0
is_suspended = 0
is_noirq_suspended = 0
is_late_suspended = 0
early_init = 1
direct_complete = 0
wakeup_path = 0
syscore = 0
no_pm_callbacks = 0
timer_expires = 0
usage_count = 1
child_count = 1
disable_depth = 0
idle_notification = 0
request_pending = 0
deferred_resume = 0
run_wake = 0
runtime_auto = 1
ignore_children = 0
no_callbacks = 0
irq_safe = 0
use_autosuspend = 0
timer_autosuspends = 0
memalloc_noio = 1
request = 0
runtime_status = 0
runtime_error = 0
autosuspend_delay = 0
last_busy = 429493
active_jiffies = 0
suspended_jiffies = 430
accounting_timestamp = 429493
PM: suspend of devices complete after 4.394 msecs

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Geert Uytterhoeven]

Hi Kevin,

On Fri, Jul 1, 2016 at 12:40 AM, Kevin Hilman  wrote:
> Geert Uytterhoeven  writes:
>> On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson  wrote:
>>> When the pm_runtime_force_suspend|resume() helpers were invented, we still
>>> had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options.
>>>
>>> To make sure these helpers worked for all combinations and without
>>> introducing too much of complexity, the device was always resumed in
>>> pm_runtime_force_resume().
>>>
>>> More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was
>>> unset, we needed to resume the device as the subsystem/driver couldn't
>>> rely on using runtime PM to do it.
>>>
>>> As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it
>>> removed this combination, of using CONFIG_PM_SLEEP without the earlier
>>> CONFIG_PM_RUNTIME.
>>>
>>> For this reason we can now rely on the subsystem/driver to use runtime PM
>>> to resume the device, instead of forcing that to be done in all cases. In
>>> other words, let's defer this to a later point when it's actually needed.
>>>
>>> Signed-off-by: Ulf Hansson 
>>> ---
>>>  drivers/base/power/runtime.c | 11 +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
>>> index 09e4eb1..1db7b46 100644
>>> --- a/drivers/base/power/runtime.c
>>> +++ b/drivers/base/power/runtime.c
>>> @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev)
>>> if (!pm_runtime_status_suspended(dev))
>>> goto out;
>>>
>>> +   /*
>>> +* The PM core increases the runtime PM usage count in the system PM
>>> +* prepare phase. If the count is greather than 1 at this point, 
>>> someone
>>> +* else has also increased it. In that case, invoke the runtime 
>>> resume
>>> +* callback for the device as that is likely what is expected. In 
>>> other
>>> +* case we trust the subsystem/driver to runtime resume the device 
>>> when
>>> +* it's actually needed.
>>> +*/
>>> +   if (atomic_read(>power.usage_count) < 2)
>>> +   goto out;
>>> +
>>> ret = pm_runtime_set_active(dev);
>>> if (ret)
>>> goto out;
>>
>> This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on
>> sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller 
>> is a
>> child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
>> simple-pm-bus, cfr.
>>
>> arch/arm/boot/dts/r8a73a4-ape6evm.dts
>> arch/arm/boot/dts/r8a73a4.dtsi
>> arch/arm/boot/dts/sh73a0-kzm9g.dts
>> arch/arm/boot/dts/sh73a0.dtsi
>>
>> During resume, the bus clock is not enabled, causing an imprecise abort
>> when accessing the Ethernet controller's registers.
>
> I have a hunch (without too much digging) that this may be an odd
> interaction with the direct_complete stuff since the simple-pm-bus has
> no callbacks.
>
> For kicks, could you add something like the hack below (untested) which
> will avoid the direct_complete path, and at least help indicate if
> that path is worth investigating further.

Thanks!
()
> diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
> index c5eb46cbf388..63b95fb21510 100644
> --- a/drivers/bus/simple-pm-bus.c
> +++ b/drivers/bus/simple-pm-bus.c
> @@ -36,6 +36,15 @@ static int simple_pm_bus_remove(struct platform_device 
> *pdev)
> return 0;
>  }
>
> +static int simple_pm_bus_prepare(struct device *dev)
> +{
> +   return pm_generic_prepare(dev);

This causes an infinite loop, as pm_generic_prepare just calls
dev->driver->pm->prepare(dev);

> +}
> +
> +static const struct dev_pm_ops simple_pm_bus_ops = {
> +   .prepare = simple_pm_bus_prepare,
> +};
> +
>  static const struct of_device_id simple_pm_bus_of_match[] = {
> { .compatible = "simple-pm-bus", },
> { /* sentinel */ }
> @@ -48,6 +57,7 @@ static struct platform_driver simple_pm_bus_driver = {
> .driver = {
> .name = "simple-pm-bus",
> .of_match_table = simple_pm_bus_of_match,
> +   .pm = _pm_bus_ops,
> },
>  };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Kevin Hilman]

Hi Geert,

Geert Uytterhoeven  writes:

> Hi Ulf, Rafael,
>
> On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson  wrote:
>> When the pm_runtime_force_suspend|resume() helpers were invented, we still
>> had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options.
>>
>> To make sure these helpers worked for all combinations and without
>> introducing too much of complexity, the device was always resumed in
>> pm_runtime_force_resume().
>>
>> More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was
>> unset, we needed to resume the device as the subsystem/driver couldn't
>> rely on using runtime PM to do it.
>>
>> As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it
>> removed this combination, of using CONFIG_PM_SLEEP without the earlier
>> CONFIG_PM_RUNTIME.
>>
>> For this reason we can now rely on the subsystem/driver to use runtime PM
>> to resume the device, instead of forcing that to be done in all cases. In
>> other words, let's defer this to a later point when it's actually needed.
>>
>> Signed-off-by: Ulf Hansson 
>> ---
>>  drivers/base/power/runtime.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
>> index 09e4eb1..1db7b46 100644
>> --- a/drivers/base/power/runtime.c
>> +++ b/drivers/base/power/runtime.c
>> @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev)
>> if (!pm_runtime_status_suspended(dev))
>> goto out;
>>
>> +   /*
>> +* The PM core increases the runtime PM usage count in the system PM
>> +* prepare phase. If the count is greather than 1 at this point, 
>> someone
>> +* else has also increased it. In that case, invoke the runtime 
>> resume
>> +* callback for the device as that is likely what is expected. In 
>> other
>> +* case we trust the subsystem/driver to runtime resume the device 
>> when
>> +* it's actually needed.
>> +*/
>> +   if (atomic_read(>power.usage_count) < 2)
>> +   goto out;
>> +
>> ret = pm_runtime_set_active(dev);
>> if (ret)
>> goto out;
>
> This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on
> sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller is 
> a
> child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
> simple-pm-bus, cfr.
>
> arch/arm/boot/dts/r8a73a4-ape6evm.dts
> arch/arm/boot/dts/r8a73a4.dtsi
> arch/arm/boot/dts/sh73a0-kzm9g.dts
> arch/arm/boot/dts/sh73a0.dtsi
>
> During resume, the bus clock is not enabled, causing an imprecise abort
> when accessing the Ethernet controller's registers.

I have a hunch (without too much digging) that this may be an odd
interaction with the direct_complete stuff since the simple-pm-bus has
no callbacks.

For kicks, could you add something like the hack below (untested) which
will avoid the direct_complete path, and at least help indicate if
that path is worth investigating further.

Thanks,

Kevin

diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
index c5eb46cbf388..63b95fb21510 100644
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -36,6 +36,15 @@ static int simple_pm_bus_remove(struct platform_device *pdev)
return 0;
 }
 
+static int simple_pm_bus_prepare(struct device *dev)
+{
+   return pm_generic_prepare(dev);
+}
+
+static const struct dev_pm_ops simple_pm_bus_ops = {
+   .prepare = simple_pm_bus_prepare,
+};
+
 static const struct of_device_id simple_pm_bus_of_match[] = {
{ .compatible = "simple-pm-bus", },
{ /* sentinel */ }
@@ -48,6 +57,7 @@ static struct platform_driver simple_pm_bus_driver = {
.driver = {
.name = "simple-pm-bus",
.of_match_table = simple_pm_bus_of_match,
+   .pm = _pm_bus_ops,
},
 };
 

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Ulf Hansson]

On 28 June 2016 at 18:26, Geert Uytterhoeven  wrote:
> Hi Ulf, Rafael,
>
> On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson  wrote:
>> When the pm_runtime_force_suspend|resume() helpers were invented, we still
>> had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options.
>>
>> To make sure these helpers worked for all combinations and without
>> introducing too much of complexity, the device was always resumed in
>> pm_runtime_force_resume().
>>
>> More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was
>> unset, we needed to resume the device as the subsystem/driver couldn't
>> rely on using runtime PM to do it.
>>
>> As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it
>> removed this combination, of using CONFIG_PM_SLEEP without the earlier
>> CONFIG_PM_RUNTIME.
>>
>> For this reason we can now rely on the subsystem/driver to use runtime PM
>> to resume the device, instead of forcing that to be done in all cases. In
>> other words, let's defer this to a later point when it's actually needed.
>>
>> Signed-off-by: Ulf Hansson 
>> ---
>>  drivers/base/power/runtime.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
>> index 09e4eb1..1db7b46 100644
>> --- a/drivers/base/power/runtime.c
>> +++ b/drivers/base/power/runtime.c
>> @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev)
>> if (!pm_runtime_status_suspended(dev))
>> goto out;
>>
>> +   /*
>> +* The PM core increases the runtime PM usage count in the system PM
>> +* prepare phase. If the count is greather than 1 at this point, 
>> someone
>> +* else has also increased it. In that case, invoke the runtime 
>> resume
>> +* callback for the device as that is likely what is expected. In 
>> other
>> +* case we trust the subsystem/driver to runtime resume the device 
>> when
>> +* it's actually needed.
>> +*/
>> +   if (atomic_read(>power.usage_count) < 2)
>> +   goto out;
>> +
>> ret = pm_runtime_set_active(dev);
>> if (ret)
>> goto out;
>
> This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on

Thanks for reporting!

> sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller is 
> a
> child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
> simple-pm-bus, cfr.
>
> arch/arm/boot/dts/r8a73a4-ape6evm.dts
> arch/arm/boot/dts/r8a73a4.dtsi
> arch/arm/boot/dts/sh73a0-kzm9g.dts
> arch/arm/boot/dts/sh73a0.dtsi
>
> During resume, the bus clock is not enabled, causing an imprecise abort
> when accessing the Ethernet controller's registers. With some debug code
> added:

I was looking into this in some more detail.

As you are stating that Ethernet device is a child device to the local
bus device, I would have expected that the pm_runtime_get_sync()
invoked during ->probe() in the Ethernet driver should cause its
parent device (the bus device) to be "forced" resumed.

That's because the pm_runtime_get_sync() should trigger an increased
usage count of the parent device. Later, when
pm_runtime_force_resume() validates the count for the bus device, it
should be 2 and thus it should lead to that it decides to *not* defer
the resume of the device. Apparently this isn't happening for some
reason...

Perhaps there's a pm_suspend_ignore_children() set for the parent?
Or perhaps the parent/child relationship isn't set up correctly?

>
> PM: Syncing filesystems ... done.
> PM: Preparing system for sleep (mem)
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> Double checking all user space processes after OOM killer
> disable... (elapsed 0.000 seconds)
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> PM: Suspending system (mem)
> smsc911x: smsc911x_suspend
> simple-pm-bus fec1.bus: simple_pm_bus_suspend
> PM: suspend of devices complete after 21.484 msecs
> PM: suspend devices took 0.030 seconds
> PM: late suspend of devices complete after 0.488 msecs
> cpg_div6_clock_disable: zb
> rmobile_pd_power_down: a3sp
> PM: noirq suspend of devices complete after 8.300 msecs
> Disabling non-boot CPUs ...
> CPU1: shutdown
>
> PM: early resume of devices complete after 0.488 msecs
> simple-pm-bus fec1.bus: simple_pm_bus_resume
> smsc911x: smsc911x_resume
> Unhandled fault: imprecise external abort (0x1406) at 0xb6f40068
> pgd = deedc000
> [b6f40068] *pgd=5f774831, *pte=4087659f, *ppte=40876e7e
> Internal error: : 1406 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1062 Comm: s2ram Not tainted
> 4.7.0-rc5-kzm9g-00391-g8f5105e9303a-dirty #765
> Hardware name: Generic SH73A0 (Flattened Device Tree)
> task: dedc0840 

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Rafael J. Wysocki]

On Tuesday, June 28, 2016 06:26:36 PM Geert Uytterhoeven wrote:
> Hi Ulf, Rafael,
> 
> On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson  wrote:
> > When the pm_runtime_force_suspend|resume() helpers were invented, we still
> > had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options.
> >
> > To make sure these helpers worked for all combinations and without
> > introducing too much of complexity, the device was always resumed in
> > pm_runtime_force_resume().
> >
> > More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was
> > unset, we needed to resume the device as the subsystem/driver couldn't
> > rely on using runtime PM to do it.
> >
> > As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it
> > removed this combination, of using CONFIG_PM_SLEEP without the earlier
> > CONFIG_PM_RUNTIME.
> >
> > For this reason we can now rely on the subsystem/driver to use runtime PM
> > to resume the device, instead of forcing that to be done in all cases. In
> > other words, let's defer this to a later point when it's actually needed.
> >
> > Signed-off-by: Ulf Hansson 
> > ---
> >  drivers/base/power/runtime.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 09e4eb1..1db7b46 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev)
> > if (!pm_runtime_status_suspended(dev))
> > goto out;
> >
> > +   /*
> > +* The PM core increases the runtime PM usage count in the system PM
> > +* prepare phase. If the count is greather than 1 at this point, 
> > someone
> > +* else has also increased it. In that case, invoke the runtime 
> > resume
> > +* callback for the device as that is likely what is expected. In 
> > other
> > +* case we trust the subsystem/driver to runtime resume the device 
> > when
> > +* it's actually needed.
> > +*/
> > +   if (atomic_read(>power.usage_count) < 2)
> > +   goto out;
> > +
> > ret = pm_runtime_set_active(dev);
> > if (ret)
> > goto out;
> 
> This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on
> sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller is 
> a
> child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
> simple-pm-bus, cfr.
> 
> arch/arm/boot/dts/r8a73a4-ape6evm.dts
> arch/arm/boot/dts/r8a73a4.dtsi
> arch/arm/boot/dts/sh73a0-kzm9g.dts
> arch/arm/boot/dts/sh73a0.dtsi
> 
> During resume, the bus clock is not enabled, causing an imprecise abort
> when accessing the Ethernet controller's registers. With some debug code
> added:
> 
> PM: Syncing filesystems ... done.
> PM: Preparing system for sleep (mem)
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> Double checking all user space processes after OOM killer
> disable... (elapsed 0.000 seconds)
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> PM: Suspending system (mem)
> smsc911x: smsc911x_suspend
> simple-pm-bus fec1.bus: simple_pm_bus_suspend
> PM: suspend of devices complete after 21.484 msecs
> PM: suspend devices took 0.030 seconds
> PM: late suspend of devices complete after 0.488 msecs
> cpg_div6_clock_disable: zb
> rmobile_pd_power_down: a3sp
> PM: noirq suspend of devices complete after 8.300 msecs
> Disabling non-boot CPUs ...
> CPU1: shutdown
> 
> PM: early resume of devices complete after 0.488 msecs
> simple-pm-bus fec1.bus: simple_pm_bus_resume
> smsc911x: smsc911x_resume
> Unhandled fault: imprecise external abort (0x1406) at 0xb6f40068
> pgd = deedc000
> [b6f40068] *pgd=5f774831, *pte=4087659f, *ppte=40876e7e
> Internal error: : 1406 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1062 Comm: s2ram Not tainted
> 4.7.0-rc5-kzm9g-00391-g8f5105e9303a-dirty #765
> Hardware name: Generic SH73A0 (Flattened Device Tree)
> task: dedc0840 ti: deee6000 task.ti: deee6000
> PC is at __smsc911x_reg_read+0x1c/0x60
> LR is at smsc911x_resume+0x78/0xd0
> 
> After reverting this patch, resume succeeds again, as the zb clock is enabled
> first:
> 
> PM: Syncing filesystems ... done.
> PM: Preparing system for sleep (mem)
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> Double checking all user space processes after OOM killer
> disable... (elapsed 0.000 seconds)
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> PM: Suspending system (mem)
> smsc911x: smsc911x_suspend
> simple-pm-bus fec1.bus: simple_pm_bus_suspend
> PM: suspend of devices complete after 22.460 msecs
> PM: suspend devices 

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Geert Uytterhoeven]

Hi Ulf, Rafael,

On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson  wrote:
> When the pm_runtime_force_suspend|resume() helpers were invented, we still
> had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options.
>
> To make sure these helpers worked for all combinations and without
> introducing too much of complexity, the device was always resumed in
> pm_runtime_force_resume().
>
> More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was
> unset, we needed to resume the device as the subsystem/driver couldn't
> rely on using runtime PM to do it.
>
> As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it
> removed this combination, of using CONFIG_PM_SLEEP without the earlier
> CONFIG_PM_RUNTIME.
>
> For this reason we can now rely on the subsystem/driver to use runtime PM
> to resume the device, instead of forcing that to be done in all cases. In
> other words, let's defer this to a later point when it's actually needed.
>
> Signed-off-by: Ulf Hansson 
> ---
>  drivers/base/power/runtime.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 09e4eb1..1db7b46 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev)
> if (!pm_runtime_status_suspended(dev))
> goto out;
>
> +   /*
> +* The PM core increases the runtime PM usage count in the system PM
> +* prepare phase. If the count is greather than 1 at this point, 
> someone
> +* else has also increased it. In that case, invoke the runtime resume
> +* callback for the device as that is likely what is expected. In 
> other
> +* case we trust the subsystem/driver to runtime resume the device 
> when
> +* it's actually needed.
> +*/
> +   if (atomic_read(>power.usage_count) < 2)
> +   goto out;
> +
> ret = pm_runtime_set_active(dev);
> if (ret)
> goto out;

This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on
sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller is a
child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
simple-pm-bus, cfr.

arch/arm/boot/dts/r8a73a4-ape6evm.dts
arch/arm/boot/dts/r8a73a4.dtsi
arch/arm/boot/dts/sh73a0-kzm9g.dts
arch/arm/boot/dts/sh73a0.dtsi

During resume, the bus clock is not enabled, causing an imprecise abort
when accessing the Ethernet controller's registers. With some debug code
added:

PM: Syncing filesystems ... done.
PM: Preparing system for sleep (mem)
Freezing user space processes ... (elapsed 0.001 seconds) done.
Double checking all user space processes after OOM killer
disable... (elapsed 0.000 seconds)
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: Suspending system (mem)
smsc911x: smsc911x_suspend
simple-pm-bus fec1.bus: simple_pm_bus_suspend
PM: suspend of devices complete after 21.484 msecs
PM: suspend devices took 0.030 seconds
PM: late suspend of devices complete after 0.488 msecs
cpg_div6_clock_disable: zb
rmobile_pd_power_down: a3sp
PM: noirq suspend of devices complete after 8.300 msecs
Disabling non-boot CPUs ...
CPU1: shutdown

PM: early resume of devices complete after 0.488 msecs
simple-pm-bus fec1.bus: simple_pm_bus_resume
smsc911x: smsc911x_resume
Unhandled fault: imprecise external abort (0x1406) at 0xb6f40068
pgd = deedc000
[b6f40068] *pgd=5f774831, *pte=4087659f, *ppte=40876e7e
Internal error: : 1406 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1062 Comm: s2ram Not tainted
4.7.0-rc5-kzm9g-00391-g8f5105e9303a-dirty #765
Hardware name: Generic SH73A0 (Flattened Device Tree)
task: dedc0840 ti: deee6000 task.ti: deee6000
PC is at __smsc911x_reg_read+0x1c/0x60
LR is at smsc911x_resume+0x78/0xd0

After reverting this patch, resume succeeds again, as the zb clock is enabled
first:

PM: Syncing filesystems ... done.
PM: Preparing system for sleep (mem)
Freezing user space processes ... (elapsed 0.001 seconds) done.
Double checking all user space processes after OOM killer
disable... (elapsed 0.000 seconds)
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: Suspending system (mem)
smsc911x: smsc911x_suspend
simple-pm-bus fec1.bus: simple_pm_bus_suspend
PM: suspend of devices complete after 22.460 msecs
PM: suspend devices took 0.030 seconds
PM: late suspend of devices complete after 0.488 msecs
cpg_div6_clock_disable: zb
rmobile_pd_power_down: a3sp
PM: noirq suspend of devices complete after 8.300 msecs
Disabling non-boot CPUs ...
CPU1: shutdown

Enabling non-boot CPUs ...
CPU1 is up