Preventing PM from suspending device

Preventing PM from suspending device

[Niklas Söderlund]

Hi Ulf and Linux PM,

I have a question regarding if a driver can signal to the PM core that 
it should not be suspended from its struct dev_pm_ops suspend callback.

My use-case is the sh_eth driver which I have added Wake-on-Lan support 
to, see [1]. In this driver I need to prevent the PM core to disable the 
module clock to the device if WoL is enabled. Currently I call 
clk_enable()/clk_disable() from the suspend/resume callbacks to modify 
the usage count of the clock to prevent the clock from being switched 
off by PM. This do not feel like the best solution to my problem.

Is there a more generic way to let PM know that I'm fine with the system 
being suspended and I have suspended as much as I can but I'm a wake up source 
so could please not switch of my clock and power domain?

1. https://marc.info/?l=linux-pm&m=148397620011501&w=2

-- 
Regards,
Niklas Söderlund

Re: Preventing PM from suspending device

[Ulf Hansson]

On 9 January 2017 at 18:22, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> Hi Ulf and Linux PM,
>
> I have a question regarding if a driver can signal to the PM core that
> it should not be suspended from its struct dev_pm_ops suspend callback.

No. The driver/subsystem needs to deal this.

>
> My use-case is the sh_eth driver which I have added Wake-on-Lan support
> to, see [1]. In this driver I need to prevent the PM core to disable the
> module clock to the device if WoL is enabled. Currently I call
> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
> the usage count of the clock to prevent the clock from being switched
> off by PM. This do not feel like the best solution to my problem.

I am not sure I get this. Is someone else than the driver performing
clk gateing/un-gating of the same clock?

>
> Is there a more generic way to let PM know that I'm fine with the system
> being suspended and I have suspended as much as I can but I'm a wake up source
> so could please not switch of my clock and power domain?

Seems like a quite common issue, but before we go into more details,
are you using genpd as the power domain? If not, what?

>
> 1. https://marc.info/?l=linux-pm&m=148397620011501&w=2
>
> --
> Regards,
> Niklas Söderlund

Kind regards
Uffe

Re: Preventing PM from suspending device

[Geert Uytterhoeven]

Hi Ulf,

On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 9 January 2017 at 18:22, Niklas Söderlund
> <niklas.soderlund@ragnatech.se> wrote:
>> Hi Ulf and Linux PM,
>>
>> I have a question regarding if a driver can signal to the PM core that
>> it should not be suspended from its struct dev_pm_ops suspend callback.
>
> No. The driver/subsystem needs to deal this.
>
>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
>> to, see [1]. In this driver I need to prevent the PM core to disable the
>> module clock to the device if WoL is enabled. Currently I call
>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
>> the usage count of the clock to prevent the clock from being switched
>> off by PM. This do not feel like the best solution to my problem.
>
> I am not sure I get this. Is someone else than the driver performing
> clk gateing/un-gating of the same clock?
>>
>> Is there a more generic way to let PM know that I'm fine with the system
>> being suspended and I have suspended as much as I can but I'm a wake up source
>> so could please not switch of my clock and power domain?
>
> Seems like a quite common issue, but before we go into more details,
> are you using genpd as the power domain? If not, what?

The Ethernet device is part of a PM Domain, hence it's power-managed by
genpd.
On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
suspend disable the device's module clock, the latter breaking WoL.
Calling clk_enable() from the suspend callback works around that.
On some SoCs, that PM Domain is both a clock domain and a power domain.
Calling clk_enable() from the suspend callback is not sufficient here, but
fortunately the power domain stays powered for another reason (it contains
the memory controller).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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: Preventing PM from suspending device

[Ulf Hansson]

On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 9 January 2017 at 18:22, Niklas Söderlund
>> <niklas.soderlund@ragnatech.se> wrote:
>>> Hi Ulf and Linux PM,
>>>
>>> I have a question regarding if a driver can signal to the PM core that
>>> it should not be suspended from its struct dev_pm_ops suspend callback.
>>
>> No. The driver/subsystem needs to deal this.
>>
>>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
>>> to, see [1]. In this driver I need to prevent the PM core to disable the
>>> module clock to the device if WoL is enabled. Currently I call
>>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
>>> the usage count of the clock to prevent the clock from being switched
>>> off by PM. This do not feel like the best solution to my problem.
>>
>> I am not sure I get this. Is someone else than the driver performing
>> clk gateing/un-gating of the same clock?
>>>
>>> Is there a more generic way to let PM know that I'm fine with the system
>>> being suspended and I have suspended as much as I can but I'm a wake up source
>>> so could please not switch of my clock and power domain?
>>
>> Seems like a quite common issue, but before we go into more details,
>> are you using genpd as the power domain? If not, what?
>
> The Ethernet device is part of a PM Domain, hence it's power-managed by
> genpd.
> On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
> suspend disable the device's module clock, the latter breaking WoL.
> Calling clk_enable() from the suspend callback works around that.
> On some SoCs, that PM Domain is both a clock domain and a power domain.
> Calling clk_enable() from the suspend callback is not sufficient here, but
> fortunately the power domain stays powered for another reason (it contains
> the memory controller).

Thanks for the additional information, very useful.

Allow me to think of this a little bit, before I give any further
suggestions. Indeed a very interesting use-case, well worth to think
more about! :-)

Kind regards
Uffe

Re: Preventing PM from suspending device

[Geert Uytterhoeven]

Hi Ulf,

On Thu, Jan 12, 2017 at 6:02 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> On 9 January 2017 at 18:22, Niklas Söderlund
>>> <niklas.soderlund@ragnatech.se> wrote:
>>>> Hi Ulf and Linux PM,
>>>>
>>>> I have a question regarding if a driver can signal to the PM core that
>>>> it should not be suspended from its struct dev_pm_ops suspend callback.
>>>
>>> No. The driver/subsystem needs to deal this.
>>>
>>>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
>>>> to, see [1]. In this driver I need to prevent the PM core to disable the
>>>> module clock to the device if WoL is enabled. Currently I call
>>>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
>>>> the usage count of the clock to prevent the clock from being switched
>>>> off by PM. This do not feel like the best solution to my problem.
>>>
>>> I am not sure I get this. Is someone else than the driver performing
>>> clk gateing/un-gating of the same clock?
>>>>
>>>> Is there a more generic way to let PM know that I'm fine with the system
>>>> being suspended and I have suspended as much as I can but I'm a wake up source
>>>> so could please not switch of my clock and power domain?
>>>
>>> Seems like a quite common issue, but before we go into more details,
>>> are you using genpd as the power domain? If not, what?
>>
>> The Ethernet device is part of a PM Domain, hence it's power-managed by
>> genpd.
>> On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
>> suspend disable the device's module clock, the latter breaking WoL.
>> Calling clk_enable() from the suspend callback works around that.
>> On some SoCs, that PM Domain is both a clock domain and a power domain.
>> Calling clk_enable() from the suspend callback is not sufficient here, but
>> fortunately the power domain stays powered for another reason (it contains
>> the memory controller).
>
> Thanks for the additional information, very useful.

Related commits calling clk_enable() to keep modules awake:
  - 6f46aedb9c85873b ("irqchip: renesas-irqc: Add wake-up support")
  - ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable when
    wake-up is enabled")
  - 705bc96c2c15313c ("irqchip: renesas-intc-irqpin: Add minimal runtime
    PM support")

Basically anything needed for wake-up needs to stay active, but should
not prevent the system from entering system suspend (i.e. cannot return
-EBUSY from its suspend function).

> Allow me to think of this a little bit, before I give any further
> suggestions. Indeed a very interesting use-case, well worth to think
> more about! :-)

Thanks, and happy thinking!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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: Preventing PM from suspending device

[Niklas Söderlund]

Hi Ulf,

On 2017-01-12 18:02:40 +0100, Ulf Hansson wrote:
> On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Hi Ulf,
> >
> > On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> On 9 January 2017 at 18:22, Niklas Söderlund
> >> <niklas.soderlund@ragnatech.se> wrote:
> >>> Hi Ulf and Linux PM,
> >>>
> >>> I have a question regarding if a driver can signal to the PM core that
> >>> it should not be suspended from its struct dev_pm_ops suspend callback.
> >>
> >> No. The driver/subsystem needs to deal this.
> >>
> >>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
> >>> to, see [1]. In this driver I need to prevent the PM core to disable the
> >>> module clock to the device if WoL is enabled. Currently I call
> >>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
> >>> the usage count of the clock to prevent the clock from being switched
> >>> off by PM. This do not feel like the best solution to my problem.
> >>
> >> I am not sure I get this. Is someone else than the driver performing
> >> clk gateing/un-gating of the same clock?
> >>>
> >>> Is there a more generic way to let PM know that I'm fine with the system
> >>> being suspended and I have suspended as much as I can but I'm a wake up source
> >>> so could please not switch of my clock and power domain?
> >>
> >> Seems like a quite common issue, but before we go into more details,
> >> are you using genpd as the power domain? If not, what?
> >
> > The Ethernet device is part of a PM Domain, hence it's power-managed by
> > genpd.
> > On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
> > suspend disable the device's module clock, the latter breaking WoL.
> > Calling clk_enable() from the suspend callback works around that.
> > On some SoCs, that PM Domain is both a clock domain and a power domain.
> > Calling clk_enable() from the suspend callback is not sufficient here, but
> > fortunately the power domain stays powered for another reason (it contains
> > the memory controller).
> 
> Thanks for the additional information, very useful.
> 
> Allow me to think of this a little bit, before I give any further
> suggestions. Indeed a very interesting use-case, well worth to think
> more about! :-)

I'm curious if you have had the opportunity to think about this. If not 
no rush, I'm just checking in :-)

> 
> Kind regards
> Uffe

-- 
Regards,
Niklas Söderlund

Re: Preventing PM from suspending device

[Ulf Hansson]

On 29 March 2017 at 21:28, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> Hi Ulf,
>
> On 2017-01-12 18:02:40 +0100, Ulf Hansson wrote:
>> On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > Hi Ulf,
>> >
>> > On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> >> On 9 January 2017 at 18:22, Niklas Söderlund
>> >> <niklas.soderlund@ragnatech.se> wrote:
>> >>> Hi Ulf and Linux PM,
>> >>>
>> >>> I have a question regarding if a driver can signal to the PM core that
>> >>> it should not be suspended from its struct dev_pm_ops suspend callback.
>> >>
>> >> No. The driver/subsystem needs to deal this.
>> >>
>> >>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
>> >>> to, see [1]. In this driver I need to prevent the PM core to disable the
>> >>> module clock to the device if WoL is enabled. Currently I call
>> >>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
>> >>> the usage count of the clock to prevent the clock from being switched
>> >>> off by PM. This do not feel like the best solution to my problem.
>> >>
>> >> I am not sure I get this. Is someone else than the driver performing
>> >> clk gateing/un-gating of the same clock?
>> >>>
>> >>> Is there a more generic way to let PM know that I'm fine with the system
>> >>> being suspended and I have suspended as much as I can but I'm a wake up source
>> >>> so could please not switch of my clock and power domain?
>> >>
>> >> Seems like a quite common issue, but before we go into more details,
>> >> are you using genpd as the power domain? If not, what?
>> >
>> > The Ethernet device is part of a PM Domain, hence it's power-managed by
>> > genpd.
>> > On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
>> > suspend disable the device's module clock, the latter breaking WoL.
>> > Calling clk_enable() from the suspend callback works around that.
>> > On some SoCs, that PM Domain is both a clock domain and a power domain.
>> > Calling clk_enable() from the suspend callback is not sufficient here, but
>> > fortunately the power domain stays powered for another reason (it contains
>> > the memory controller).
>>
>> Thanks for the additional information, very useful.
>>
>> Allow me to think of this a little bit, before I give any further
>> suggestions. Indeed a very interesting use-case, well worth to think
>> more about! :-)
>
> I'm curious if you have had the opportunity to think about this. If not
> no rush, I'm just checking in :-)

Yes I have! :-) It's soon reaching my top of my TODO list.

I realized that thinking isn't sufficient, I need to do some
prototyping to convince myself about the best approach.

Sorry for the delay!

Br
Uffe

Re: Preventing PM from suspending device

[Niklas Söderlund]

Hi Ulf,

On 2017-03-30 18:44:20 +0200, Ulf Hansson wrote:
> On 29 March 2017 at 21:28, Niklas Söderlund
> <niklas.soderlund@ragnatech.se> wrote:
> > Hi Ulf,
> >
> > On 2017-01-12 18:02:40 +0100, Ulf Hansson wrote:
> >> On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> > Hi Ulf,
> >> >
> >> > On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> >> On 9 January 2017 at 18:22, Niklas Söderlund
> >> >> <niklas.soderlund@ragnatech.se> wrote:
> >> >>> Hi Ulf and Linux PM,
> >> >>>
> >> >>> I have a question regarding if a driver can signal to the PM core that
> >> >>> it should not be suspended from its struct dev_pm_ops suspend callback.
> >> >>
> >> >> No. The driver/subsystem needs to deal this.
> >> >>
> >> >>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
> >> >>> to, see [1]. In this driver I need to prevent the PM core to disable the
> >> >>> module clock to the device if WoL is enabled. Currently I call
> >> >>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
> >> >>> the usage count of the clock to prevent the clock from being switched
> >> >>> off by PM. This do not feel like the best solution to my problem.
> >> >>
> >> >> I am not sure I get this. Is someone else than the driver performing
> >> >> clk gateing/un-gating of the same clock?
> >> >>>
> >> >>> Is there a more generic way to let PM know that I'm fine with the system
> >> >>> being suspended and I have suspended as much as I can but I'm a wake up source
> >> >>> so could please not switch of my clock and power domain?
> >> >>
> >> >> Seems like a quite common issue, but before we go into more details,
> >> >> are you using genpd as the power domain? If not, what?
> >> >
> >> > The Ethernet device is part of a PM Domain, hence it's power-managed by
> >> > genpd.
> >> > On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
> >> > suspend disable the device's module clock, the latter breaking WoL.
> >> > Calling clk_enable() from the suspend callback works around that.
> >> > On some SoCs, that PM Domain is both a clock domain and a power domain.
> >> > Calling clk_enable() from the suspend callback is not sufficient here, but
> >> > fortunately the power domain stays powered for another reason (it contains
> >> > the memory controller).
> >>
> >> Thanks for the additional information, very useful.
> >>
> >> Allow me to think of this a little bit, before I give any further
> >> suggestions. Indeed a very interesting use-case, well worth to think
> >> more about! :-)
> >
> > I'm curious if you have had the opportunity to think about this. If not
> > no rush, I'm just checking in :-)
> 
> Yes I have! :-) It's soon reaching my top of my TODO list.
> 
> I realized that thinking isn't sufficient, I need to do some
> prototyping to convince myself about the best approach.

That's great news :-)

> 
> Sorry for the delay!

No worries, I'm not suffering from this since I can manage the clock 
directly from the driver. And as Geert explained the device is in an 
always on power domain. I just wanted to check in so that if a different 
solution is found I can remove the explicit clock handling.

Thanks again for thinking about this.

> 
> Br
> Uffe

-- 
Regards,
Niklas Söderlund

Re: Preventing PM from suspending device

[Geert Uytterhoeven]

)Hi Niklas, Ulf,

On Thu, Mar 30, 2017 at 10:35 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> On 2017-03-30 18:44:20 +0200, Ulf Hansson wrote:
>> On 29 March 2017 at 21:28, Niklas Söderlund
>> <niklas.soderlund@ragnatech.se> wrote:
>> > On 2017-01-12 18:02:40 +0100, Ulf Hansson wrote:
>> >> On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> >> > On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> >> >> On 9 January 2017 at 18:22, Niklas Söderlund
>> >> >> <niklas.soderlund@ragnatech.se> wrote:
>> >> >>> I have a question regarding if a driver can signal to the PM core that
>> >> >>> it should not be suspended from its struct dev_pm_ops suspend callback.
>> >> >>
>> >> >> No. The driver/subsystem needs to deal this.
>> >> >>
>> >> >>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
>> >> >>> to, see [1]. In this driver I need to prevent the PM core to disable the
>> >> >>> module clock to the device if WoL is enabled. Currently I call
>> >> >>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
>> >> >>> the usage count of the clock to prevent the clock from being switched
>> >> >>> off by PM. This do not feel like the best solution to my problem.
>> >> >>
>> >> >> I am not sure I get this. Is someone else than the driver performing
>> >> >> clk gateing/un-gating of the same clock?
>> >> >>>
>> >> >>> Is there a more generic way to let PM know that I'm fine with the system
>> >> >>> being suspended and I have suspended as much as I can but I'm a wake up source
>> >> >>> so could please not switch of my clock and power domain?
>> >> >>
>> >> >> Seems like a quite common issue, but before we go into more details,
>> >> >> are you using genpd as the power domain? If not, what?
>> >> >
>> >> > The Ethernet device is part of a PM Domain, hence it's power-managed by
>> >> > genpd.
>> >> > On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
>> >> > suspend disable the device's module clock, the latter breaking WoL.
>> >> > Calling clk_enable() from the suspend callback works around that.
>> >> > On some SoCs, that PM Domain is both a clock domain and a power domain.
>> >> > Calling clk_enable() from the suspend callback is not sufficient here, but
>> >> > fortunately the power domain stays powered for another reason (it contains
>> >> > the memory controller).
>> >>
>> >> Thanks for the additional information, very useful.
>> >>
>> >> Allow me to think of this a little bit, before I give any further
>> >> suggestions. Indeed a very interesting use-case, well worth to think
>> >> more about! :-)
>> >
>> > I'm curious if you have had the opportunity to think about this. If not
>> > no rush, I'm just checking in :-)
>>
>> Yes I have! :-) It's soon reaching my top of my TODO list.
>>
>> I realized that thinking isn't sufficient, I need to do some
>> prototyping to convince myself about the best approach.
>
> That's great news :-)
>
>>
>> Sorry for the delay!
>
> No worries, I'm not suffering from this since I can manage the clock
> directly from the driver. And as Geert explained the device is in an
> always on power domain. I just wanted to check in so that if a different
> solution is found I can remove the explicit clock handling.

In case you missed it: the issue turned out to be the R-Car PM Domain
driver(s) not proving gpd_dev_ops.active_wakeup() callbacks, cfr.
"[PATCH 00/10] PM / Domain: renesas: Fix active wakeup behavior"
(https://www.spinics.net/lists/linux-renesas-soc/msg19319.html).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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: Preventing PM from suspending device

[Ulf Hansson]

On 18 October 2017 at 13:35, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> )Hi Niklas, Ulf,
>
> On Thu, Mar 30, 2017 at 10:35 PM, Niklas Söderlund
> <niklas.soderlund@ragnatech.se> wrote:
>> On 2017-03-30 18:44:20 +0200, Ulf Hansson wrote:
>>> On 29 March 2017 at 21:28, Niklas Söderlund
>>> <niklas.soderlund@ragnatech.se> wrote:
>>> > On 2017-01-12 18:02:40 +0100, Ulf Hansson wrote:
>>> >> On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> >> > On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> >> >> On 9 January 2017 at 18:22, Niklas Söderlund
>>> >> >> <niklas.soderlund@ragnatech.se> wrote:
>>> >> >>> I have a question regarding if a driver can signal to the PM core that
>>> >> >>> it should not be suspended from its struct dev_pm_ops suspend callback.
>>> >> >>
>>> >> >> No. The driver/subsystem needs to deal this.
>>> >> >>
>>> >> >>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
>>> >> >>> to, see [1]. In this driver I need to prevent the PM core to disable the
>>> >> >>> module clock to the device if WoL is enabled. Currently I call
>>> >> >>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
>>> >> >>> the usage count of the clock to prevent the clock from being switched
>>> >> >>> off by PM. This do not feel like the best solution to my problem.
>>> >> >>
>>> >> >> I am not sure I get this. Is someone else than the driver performing
>>> >> >> clk gateing/un-gating of the same clock?
>>> >> >>>
>>> >> >>> Is there a more generic way to let PM know that I'm fine with the system
>>> >> >>> being suspended and I have suspended as much as I can but I'm a wake up source
>>> >> >>> so could please not switch of my clock and power domain?
>>> >> >>
>>> >> >> Seems like a quite common issue, but before we go into more details,
>>> >> >> are you using genpd as the power domain? If not, what?
>>> >> >
>>> >> > The Ethernet device is part of a PM Domain, hence it's power-managed by
>>> >> > genpd.
>>> >> > On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
>>> >> > suspend disable the device's module clock, the latter breaking WoL.
>>> >> > Calling clk_enable() from the suspend callback works around that.
>>> >> > On some SoCs, that PM Domain is both a clock domain and a power domain.
>>> >> > Calling clk_enable() from the suspend callback is not sufficient here, but
>>> >> > fortunately the power domain stays powered for another reason (it contains
>>> >> > the memory controller).
>>> >>
>>> >> Thanks for the additional information, very useful.
>>> >>
>>> >> Allow me to think of this a little bit, before I give any further
>>> >> suggestions. Indeed a very interesting use-case, well worth to think
>>> >> more about! :-)
>>> >
>>> > I'm curious if you have had the opportunity to think about this. If not
>>> > no rush, I'm just checking in :-)
>>>
>>> Yes I have! :-) It's soon reaching my top of my TODO list.
>>>
>>> I realized that thinking isn't sufficient, I need to do some
>>> prototyping to convince myself about the best approach.
>>
>> That's great news :-)
>>
>>>
>>> Sorry for the delay!
>>
>> No worries, I'm not suffering from this since I can manage the clock
>> directly from the driver. And as Geert explained the device is in an
>> always on power domain. I just wanted to check in so that if a different
>> solution is found I can remove the explicit clock handling.
>
> In case you missed it: the issue turned out to be the R-Car PM Domain
> driver(s) not proving gpd_dev_ops.active_wakeup() callbacks, cfr.
> "[PATCH 00/10] PM / Domain: renesas: Fix active wakeup behavior"
> (https://www.spinics.net/lists/linux-renesas-soc/msg19319.html).

That works, but as a matter of fact a have a slightly different idea
on how to perhaps better solve this. Allow me a couple of days, then I
respond to you.

Kind regards
Uffe