All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Palatin <vpalatin@chromium.org>
To: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Cc: netdev@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Douglas Anderson" <dianders@chromium.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Shunqian Zheng" <zhengsq@rock-chips.com>,
	"David Miller" <davem@davemloft.net>
Subject: Re: net: stmmac: dwmac-rk: fixes for Wake-on-Lan on RK3288
Date: Thu, 16 Jun 2016 07:51:01 -0700	[thread overview]
Message-ID: <CAP_ceTweCVNsLONayu6woxyK7p1975w-t0LU4VUjwkqp+1G13A@mail.gmail.com> (raw)
In-Reply-To: <1a9e4f56-37b0-892f-97b5-b61106e6d40b@st.com>

Hi Giuseppe,

On Thu, Jun 16, 2016 at 6:37 AM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
>
> Hi Vincent
>
>
> On 6/15/2016 7:04 PM, Vincent Palatin wrote:
>>
>> On Sun, Jun 12, 2016 at 11:46 PM, Giuseppe CAVALLARO
>> <peppe.cavallaro@st.com> wrote:
>>>
>>> On 6/11/2016 3:00 AM, Vincent Palatin wrote:
>>>>
>>>>
>>>> In order to support Wake-On-Lan when using the RK3288 integrated MAC
>>>> (with an external RGMII PHY), we need to avoid shutting down the regulator
>>>> of the external PHY when the MAC is suspended as it's currently done in
>>>> the MAC
>>>> platform code.
>>>> As a first step, create independant callbacks for suspend/resume rather
>>>> than
>>>> re-using exit/init callbacks. So the dwmac platform driver can behave
>>>> differently
>>>> on suspend where it might skip shutting the PHY and at module unloading.
>>>> Then update the dwmac-rk driver to switch off the PHY regulator only if we
>>>> are
>>>> not planning to wake up from the LAN.
>>>> Finally add the PMT interrupt to the MAC device tree configuration, so we
>>>> can
>>>> wake up the core from it when the PHY has received the magic packet.
>>>
>>>
>>>
>>> IMO these could be sent for net-next and also other glue logic
>>> files should be reworked in order to use the new API for coherence.
>>
>>
>> Given they will have the same set of functions for exit/init and
>> suspend/resume, you mean duplicating the callbacks like this :
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
>> @@ -359,6 +359,8 @@ static int sti_dwmac_probe(struct platform_device *pdev)
>>         plat_dat->bsp_priv = dwmac;
>>         plat_dat->init = sti_dwmac_init;
>>         plat_dat->exit = sti_dwmac_exit;
>> +       plat_dat->suspend = sti_dwmac_exit;
>> +       plat_dat->resume = sti_dwmac_init;
>>         plat_dat->fix_mac_speed = data->fix_retime_src;
>>
>>         ret = sti_dwmac_init(pdev, plat_dat->bsp_priv);
>>
>> Is this anyhow useful ?
>
>
> I think this is mandatory otherwise you are not guaranteeing the PM
> stuff working on the rest of the glue-logics (not only sti); because
> init/exit calls won't be called anymore.


As mentioned in the PATCH 1/3 description: "If the driver does not
provide the suspend or resume callback, we fall
back to the old behavior trying to use exit or init. [...]"
ie.
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -411,7 +411,9 @@ static int stmmac_pltfr_suspend(struct device *dev)
        struct platform_device *pdev = to_platform_device(dev);

        ret = stmmac_suspend(dev);
-       if (priv->plat->exit)
+       if (priv->plat->suspend)
+               priv->plat->suspend(pdev, priv->plat->bsp_priv);
+       else if (priv->plat->exit)
                priv->plat->exit(pdev, priv->plat->bsp_priv);

        return ret;
@@ -430,7 +432,9 @@ static int stmmac_pltfr_resume(struct device *dev)
        struct stmmac_priv *priv = netdev_priv(ndev);
        struct platform_device *pdev = to_platform_device(dev);

-       if (priv->plat->init)
+       if (priv->plat->resume)
+               priv->plat->resume(pdev, priv->plat->bsp_priv);
+       else if (priv->plat->init)
                priv->plat->init(pdev, priv->plat->bsp_priv);

        return stmmac_resume(dev);

So I was under the impression that everything should continue working
as before for drivers only providing init/exit,
by falling back on calling ->exit() if there is no suspend() callback
initialized for the PM calls.
You think that won't work ?

>
> So I kindly ask you to
> propagate the fix and send the V3.  The implementation above is ok for
> me.
>
> peppe
>

  reply	other threads:[~2016-06-16 14:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03 17:29 [PATCH] net: stmmac: dwmac-rk: keep PHY up for WoL Vincent Palatin
2016-06-06 20:45 ` Heiko Stübner
2016-06-06 21:00   ` Vincent Palatin
2016-06-07  7:23 ` Giuseppe CAVALLARO
2016-06-08 22:25   ` Vincent Palatin
2016-06-09  0:17     ` Andrew Lunn
2016-06-09 23:00       ` Vincent Palatin
2016-06-10 12:29         ` Giuseppe CAVALLARO
2016-06-11  1:00           ` net: stmmac: dwmac-rk: fixes for Wake-on-Lan on RK3288 Vincent Palatin
2016-06-11  1:00             ` [PATCH 1/3] net: stmmac: allow to split suspend/resume from init/exit callbacks Vincent Palatin
2016-06-11  1:16               ` David Miller
2016-06-11  1:00             ` [PATCH 2/3] net: stmmac: dwmac-rk: keep the PHY up for WoL Vincent Palatin
2016-06-11  1:57               ` Heiko Stuebner
2016-06-15 16:03                 ` Vincent Palatin
2016-06-15 18:32                   ` [PATCH v2 0/3] net: stmmac: dwmac-rk: fixes for Wake-on-Lan on RK3288 Vincent Palatin
2016-06-15 18:32                     ` [PATCH v2 1/3] net: stmmac: allow to split suspend/resume from init/exit callbacks Vincent Palatin
2016-06-15 18:32                     ` [PATCH v2 2/3] net: stmmac: dwmac-rk: keep the PHY up for WoL Vincent Palatin
2016-06-15 18:32                     ` [PATCH v2 3/3] ARM: dts: rockchip: add interrupt for Wake-on-Lan on RK3288 Vincent Palatin
2016-06-16 21:15                     ` [PATCH v2 0/3] net: stmmac: dwmac-rk: fixes " David Miller
2016-06-11  1:00             ` [PATCH 3/3] ARM: dts: rockchip: add interrupt " Vincent Palatin
2016-06-11  1:16             ` net: stmmac: dwmac-rk: fixes " David Miller
2016-06-13  6:46             ` Giuseppe CAVALLARO
2016-06-15 17:04               ` Vincent Palatin
2016-06-16 13:37                 ` Giuseppe CAVALLARO
2016-06-16 14:51                   ` Vincent Palatin [this message]
2016-06-17  5:38                     ` Giuseppe CAVALLARO

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAP_ceTweCVNsLONayu6woxyK7p1975w-t0LU4VUjwkqp+1G13A@mail.gmail.com \
    --to=vpalatin@chromium.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=zhengsq@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.