[RFC PATCH 0/3] net: macb: Wake-on-Lan magic packet fixes

[RFC PATCH 0/3] net: macb: Wake-on-Lan magic packet fixes

[nicolas.ferre]

From: Nicolas Ferre <nicolas.ferre@microchip.com>

Hi,
Here are some of my early patches in order to fix WoL magic-packet on the
current macb driver.
Addition of this feature to GEM types of IPs is yet to come. I would like to
have your feedback on these little patches first so that I can continue
investigating the addition of GEM WoL magic-packet.

Harini, I know that you have patches for GEM in order to integrate WoL ARP
mode [1]. I'll try to integrate some of your work but would need that this feature
is better integrated in current code. For instance, the choice of "magic
packet" or "ARP" should be done by ethtool options and DT properties. For
matching with mainline users, MACB and GEM code must co-exist.
The use of dumb buffers for RX seems also fairly platform specific and we would
need to think more about it.

[1]:
https://github.com/Xilinx/linux-xlnx/commit/e9648006e8d9132db2594e50e700af362b3c9226#diff-41909d180431659ccc1229aa30fd4e5a
https://github.com/Xilinx/linux-xlnx/commit/60a21c686f7e4e50489ae04b9bb1980b145e52ef

Nicolas Ferre (3):
  net: macb: fix wakeup test in runtime suspend/resume routines
  net: macb: mark device wake capable when "magic-packet" property
    present
  net: macb: fix macb_get/set_wol() when moving to phylink

 drivers/net/ethernet/cadence/macb_main.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

-- 
2.20.1

[RFC PATCH 1/3] net: macb: fix wakeup test in runtime suspend/resume routines

[nicolas.ferre]

From: Nicolas Ferre <nicolas.ferre@microchip.com>

Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
&bp->dev->dev.parent.

It's preventing the trigger of a spurious interrupt in case the
Wake-on-Lan feature is used.

Fixes: bc1109d04c39 ("net: macb: Add pm runtime support")
Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Harini Katakam <harini.katakam@xilinx.com>
Cc: Rafal Ozieblo <rafalo@cadence.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
 drivers/net/ethernet/cadence/macb_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a0e8c5bbabc0..d1b4d6b6d7c8 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4616,7 +4616,7 @@ static int __maybe_unused macb_runtime_suspend(struct device *dev)
 	struct net_device *netdev = dev_get_drvdata(dev);
 	struct macb *bp = netdev_priv(netdev);
 
-	if (!(device_may_wakeup(&bp->dev->dev))) {
+	if (!(device_may_wakeup(dev))) {
 		clk_disable_unprepare(bp->tx_clk);
 		clk_disable_unprepare(bp->hclk);
 		clk_disable_unprepare(bp->pclk);
@@ -4632,7 +4632,7 @@ static int __maybe_unused macb_runtime_resume(struct device *dev)
 	struct net_device *netdev = dev_get_drvdata(dev);
 	struct macb *bp = netdev_priv(netdev);
 
-	if (!(device_may_wakeup(&bp->dev->dev))) {
+	if (!(device_may_wakeup(dev))) {
 		clk_prepare_enable(bp->pclk);
 		clk_prepare_enable(bp->hclk);
 		clk_prepare_enable(bp->tx_clk);
-- 
2.20.1

[RFC PATCH 2/3] net: macb: mark device wake capable when "magic-packet" property present

[nicolas.ferre]

From: Nicolas Ferre <nicolas.ferre@microchip.com>

Change the way the "magic-packet" DT property is handled in the
macb_probe() function, matching DT binding documentation.
Now we mark the device as "wakeup capable" instead of calling the
device_init_wakeup() function that would enable the wakeup source.

For Ethernet WoL, enabling the wakeup_source is done by
using ethtool and associated macb_set_wol() function that
already calls device_set_wakeup_enable() for this purpose.

That would reduce power consumption by cutting more clocks if
"magic-packet" property is set but WoL is not configured by ethtool.

Fixes: 3e2a5e153906 ("net: macb: add wake-on-lan support via magic packet")
Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Harini Katakam <harini.katakam@xilinx.com>
Cc: Rafal Ozieblo <rafalo@cadence.com>
Cc: Sergio Prado <sergio.prado@e-labworks.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
 drivers/net/ethernet/cadence/macb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index d1b4d6b6d7c8..629660d9f17e 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4384,7 +4384,7 @@ static int macb_probe(struct platform_device *pdev)
 	bp->wol = 0;
 	if (of_get_property(np, "magic-packet", NULL))
 		bp->wol |= MACB_WOL_HAS_MAGIC_PACKET;
-	device_init_wakeup(&pdev->dev, bp->wol & MACB_WOL_HAS_MAGIC_PACKET);
+	device_set_wakeup_capable(&pdev->dev, bp->wol & MACB_WOL_HAS_MAGIC_PACKET);
 
 	spin_lock_init(&bp->lock);
 
-- 
2.20.1

[RFC PATCH 3/3] net: macb: fix macb_get/set_wol() when moving to phylink

[nicolas.ferre]

From: Nicolas Ferre <nicolas.ferre@microchip.com>

Keep previous function goals and integrate phylink actions to them.

phylink_ethtool_get_wol() is not enough to figure out if Ethernet driver
supports Wake-on-Lan.
Initialization of "supported" and "wolopts" members is done in phylink
function, no need to keep them in calling function.

phylink_ethtool_set_wol() return value is not enough to determine
if WoL is enabled for the calling Ethernet driver. Call if first
but don't rely on its return value as most of simple PHY drivers
don't implement a set_wol() function.

Fixes: 7897b071ac3b ("net: macb: convert to phylink")
Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Harini Katakam <harini.katakam@xilinx.com>
Cc: Rafal Ozieblo <rafalo@cadence.com>
Cc: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
 drivers/net/ethernet/cadence/macb_main.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 629660d9f17e..b17a33c60cd4 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2813,21 +2813,23 @@ static void macb_get_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
 {
 	struct macb *bp = netdev_priv(netdev);
 
-	wol->supported = 0;
-	wol->wolopts = 0;
-
-	if (bp->wol & MACB_WOL_HAS_MAGIC_PACKET)
+	if (bp->wol & MACB_WOL_HAS_MAGIC_PACKET) {
 		phylink_ethtool_get_wol(bp->phylink, wol);
+		wol->supported |= WAKE_MAGIC;
+
+		if (bp->wol & MACB_WOL_ENABLED)
+			wol->wolopts |= WAKE_MAGIC;
+	}
 }
 
 static int macb_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
 {
 	struct macb *bp = netdev_priv(netdev);
-	int ret;
 
-	ret = phylink_ethtool_set_wol(bp->phylink, wol);
-	if (!ret)
-		return 0;
+	/* Pass the order to phylink layer.
+	 * Don't test return value as set_wol() is often not supported.
+	 */
+	phylink_ethtool_set_wol(bp->phylink, wol);
 
 	if (!(bp->wol & MACB_WOL_HAS_MAGIC_PACKET) ||
 	    (wol->wolopts & ~WAKE_MAGIC))
-- 
2.20.1

Re: [RFC PATCH 0/3] net: macb: Wake-on-Lan magic packet fixes

[Harini Katakam]

Hi Nicolas,

On Fri, Apr 3, 2020 at 6:45 PM <nicolas.ferre@microchip.com> wrote:
>
> From: Nicolas Ferre <nicolas.ferre@microchip.com>
>
> Hi,
> Here are some of my early patches in order to fix WoL magic-packet on the
> current macb driver.
> Addition of this feature to GEM types of IPs is yet to come. I would like to
> have your feedback on these little patches first so that I can continue
> investigating the addition of GEM WoL magic-packet.
>
> Harini, I know that you have patches for GEM in order to integrate WoL ARP
> mode [1]. I'll try to integrate some of your work but would need that this feature
> is better integrated in current code. For instance, the choice of "magic
> packet" or "ARP" should be done by ethtool options and DT properties. For
> matching with mainline users, MACB and GEM code must co-exist.

Agree. I'll try to test this series and get back to you next week.

> The use of dumb buffers for RX seems also fairly platform specific and we would
> need to think more about it.

I know that the IP versions from r1p10 have a mechanism to disable DMA queues
(bit 0 of the queue pointer register) which is cleaner. But for
earlier IP versions,
I remember discussing with Cadence and there is no way to keep RX
enabled for WOL
with RX DMA disabled. I'm afraid that means there should be a bare
minimum memory
region with a dummy descriptor if you do not want to process the
packets. That memory
should also be accessible while the rest of the system is powered
down. Please let me
know if you think of any other solution.

Regards,
Harini

Re: [RFC PATCH 0/3] net: macb: Wake-on-Lan magic packet fixes

[Nicolas Ferre]

Hi Harini,

On 03/04/2020 at 15:36, Harini Katakam wrote:
> Hi Nicolas,
> 
> On Fri, Apr 3, 2020 at 6:45 PM <nicolas.ferre@microchip.com> wrote:
>>
>> From: Nicolas Ferre <nicolas.ferre@microchip.com>
>>
>> Hi,
>> Here are some of my early patches in order to fix WoL magic-packet on the
>> current macb driver.
>> Addition of this feature to GEM types of IPs is yet to come. I would like to
>> have your feedback on these little patches first so that I can continue
>> investigating the addition of GEM WoL magic-packet.
>>
>> Harini, I know that you have patches for GEM in order to integrate WoL ARP
>> mode [1]. I'll try to integrate some of your work but would need that this feature
>> is better integrated in current code. For instance, the choice of "magic
>> packet" or "ARP" should be done by ethtool options and DT properties. For
>> matching with mainline users, MACB and GEM code must co-exist.
> 
> Agree. I'll try to test this series and get back to you next week.
> 
>> The use of dumb buffers for RX seems also fairly platform specific and we would
>> need to think more about it.
> 
> I know that the IP versions from r1p10 have a mechanism to disable DMA queues
> (bit 0 of the queue pointer register) which is cleaner. But for
> earlier IP versions,

Which IP name are you referring to? GEM, GEM-GXL? What is the value of 
register 0xFC then?

> I remember discussing with Cadence and there is no way to keep RX
> enabled for WOL
> with RX DMA disabled. I'm afraid that means there should be a bare
> minimum memory
> region with a dummy descriptor if you do not want to process the
> packets. That memory
> should also be accessible while the rest of the system is powered
> down. Please let me

Very interesting information Harini, thanks a lot for having shared it.

My GEM IP has 0xFC at value: 0x00020203. But I don't see a way to keep 
DMA queues disabled by using the famous bit that you mention above.

> know if you think of any other solution.

I'm trying all this right now. I keep you posted.

Thanks and best regards,
   Nicolas


-- 
Nicolas Ferre

Re: [RFC PATCH 0/3] net: macb: Wake-on-Lan magic packet fixes

[Harini Katakam]

Hi Nicolas,

On Mon, Apr 6, 2020 at 7:56 PM Nicolas Ferre
<nicolas.ferre@microchip.com> wrote:
>
> Hi Harini,
>
> On 03/04/2020 at 15:36, Harini Katakam wrote:
> > Hi Nicolas,
> >
> > On Fri, Apr 3, 2020 at 6:45 PM <nicolas.ferre@microchip.com> wrote:
> >>
> >> From: Nicolas Ferre <nicolas.ferre@microchip.com>
<snip>
> >
> > I know that the IP versions from r1p10 have a mechanism to disable DMA queues
> > (bit 0 of the queue pointer register) which is cleaner. But for
> > earlier IP versions,
>
> Which IP name are you referring to? GEM, GEM-GXL? What is the value of
> register 0xFC then?

GEM_GXL

>
> > I remember discussing with Cadence and there is no way to keep RX
> > enabled for WOL
> > with RX DMA disabled. I'm afraid that means there should be a bare
> > minimum memory
> > region with a dummy descriptor if you do not want to process the
> > packets. That memory
> > should also be accessible while the rest of the system is powered
> > down. Please let me
>
> Very interesting information Harini, thanks a lot for having shared it.
>
> My GEM IP has 0xFC at value: 0x00020203. But I don't see a way to keep
> DMA queues disabled by using the famous bit that you mention above.

Yeah, it is not possible in this revision. This is part of the GEM_GXL r1p10 or
higher I think. I can't be sure of all the possible variations of the
revision reg
because the scheme changed at some point but it looks like this:
0x00070100
bits 27:16 (module_ID), bits16:0 (module_revision); they could increase.

Regards,
Harini