From: Dan Murphy
Date: Mon, 28 Sep 2020 09:47:24 -0500
> Hello
>
> On 9/28/20 9:46 AM, Dan Murphy wrote:
>> This adds WoL support on TI DP83869 for magic, magic secure, unicast
>> and
>> broadcast.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v5 - Fixed 0-day warning for u16
>>
>> arch/arm/co
On Mon, Sep 28, 2020 at 09:51:34AM -0500, Dan Murphy wrote:
> This adds WoL support on TI DP83869 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
Andrew
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
v5 - Fixed 0-day warning for u16, removed defconfig
drivers/net/phy/dp83869.c | 176 ++
1 file changed, 176 insertions(+)
diff --git a/drivers/
Hello
On 9/28/20 9:46 AM, Dan Murphy wrote:
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
v5 - Fixed 0-day warning for u16
arch/arm/configs/ti_sdk_omap2_debug_defconfig | 2335 +
I have to repost this patc
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
v5 - Fixed 0-day warning for u16
arch/arm/configs/ti_sdk_omap2_debug_defconfig | 2335 +
drivers/net/phy/dp83869.c | 176 ++
2 files changed, 2
Hi Dan,
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/DP83869-WoL-and-Speed-optimization/20200925-002844
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
3fc826f121d89c5aa4afd7b3408b07e0ff59466b
config: x86_64-randconfig-m001-20200925 (attached as .conf
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
v4 - Added checking error on phy_read
drivers/net/phy/dp83869.c | 176 ++
1 file changed, 176 insertions(+)
diff --git a/drivers/net/phy/dp8386
Andrew
On 9/10/20 1:02 PM, Andrew Lunn wrote:
static int dp83869_config_port_mirroring(struct phy_device *phydev)
{
struct dp83869_private *dp83869 = phydev->priv;
Overall this code looks quite similar to dp83867, is there no way to
factor this out?
Factor what out? Yes the DP83
> > > static int dp83869_config_port_mirroring(struct phy_device *phydev)
> > > {
> > > struct dp83869_private *dp83869 = phydev->priv;
> > Overall this code looks quite similar to dp83867, is there no way to
> > factor this out?
>
> Factor what out? Yes the DP83867 and DP83869 are
Jakub
Thanks for the review
On 9/5/20 1:34 PM, Jakub Kicinski wrote:
On Thu, 3 Sep 2020 06:42:58 -0500 Dan Murphy wrote:
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83869.c | 128 +++
On Thu, 3 Sep 2020 06:42:58 -0500 Dan Murphy wrote:
> This adds WoL support on TI DP83869 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/net/phy/dp83869.c | 128 ++
> 1 file changed, 128 insertions(+)
>
> diff
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83869.c | 128 ++
1 file changed, 128 insertions(+)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index 48
This adds WoL support on TI DP83869 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83869.c | 128 ++
1 file changed, 128 insertions(+)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index 48
It is necessary to manage the Wake-on-LAN clock to turn on the
appropriate blocks for MPD or CFP-based packet matching to work
otherwise we will not be able to reliably match packets during suspend.
Reported-by: Blair Prescott
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom
From:
Date: Mon, 20 Jul 2020 10:56:51 +0200
> Here is the second part of support for WoL magic-packet on the current macb
> driver. This one
> is addressing the bulk of the feature and is based on current net-next/master.
>
> MACB and GEM code must co-exist and as they don't share exactly the sa
From: Nicolas Ferre
Hi,
Here is the second part of support for WoL magic-packet on the current macb
driver. This one
is addressing the bulk of the feature and is based on current net-next/master.
MACB and GEM code must co-exist and as they don't share exactly the same
register layout, I had to
ctor Co., Ltd. Device 0123
> > > > Kernel driver in use: r8169
> > > >
> > > > On the Realtek website
> > > > (
> > > > https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e
> > > >
gt;> (
>>> https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e
>>> )
>>> it says that both wake-on-lan and remote wake-on-lan are supported.
>>> I
>>> got the wake-on-lan from my local network working, but I have
>>> prob
ess Gigabit Ethernet Controller (rev 0c)
> > Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
> > Kernel driver in use: r8169
> >
> > On the Realtek website (
> > https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e
> > ) it say
/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
> > Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
> > Kernel driver in use: r8169
> >
> > On the Realtek website
> > (
> > https://www.realtek.com/en/products/communications-network-ics/i
ess Gigabit Ethernet Controller (rev 0c)
>> Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
>> Kernel driver in use: r8169
>>
>> On the Realtek website
>> (https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e)
>> it says that
emiconductor Co., Ltd. Device 0123
> Kernel driver in use: r8169
>
> On the Realtek website
> (https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e)
> it says that both wake-on-lan and remote wake-on-lan are supported. I
> got the wake-on-lan from my loc
Co., Ltd. Device 0123
> Kernel driver in use: r8169
>
> On the Realtek website
> (https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e)
> it says that both wake-on-lan and remote wake-on-lan are
> supported. I got the wake-on-lan from my local network work
://www.realtek.com/en/products/communications-network-ics/item/rtl8168e)
it says that both wake-on-lan and remote wake-on-lan are
supported. I got the wake-on-lan from my local network working, but I have
problems getting the remote wake-on-lan to work.
When I set 'Wake-on' to 'g&
From: Nicolas Ferre
Hi,
Here is the second part of support for WoL magic-packet on the current macb
driver. This one
is addressing the bulk of the feature and is based on current net-next/master.
MACB and GEM code must co-exist and as they don't share exactly the same
register layout, I had to
From:
Date: Fri, 10 Jul 2020 14:46:40 +0200
> Here is a split series to fix WoL magic-packet on the current macb driver.
> Only
> fixes in this one based on current net/master.
Series applied, thank you.
From: Nicolas Ferre
Hi,
Here is a split series to fix WoL magic-packet on the current macb driver. Only
fixes in this one based on current net/master.
Best regards,
Nicolas
Changes in v5:
- Addressed the error code returned by phylink_ethtool_set_wol() as suggested
by Russell.
If PHY hand
Begin forwarded message:
Date: Tue, 02 Jun 2020 19:12:51 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 208033] New: r8169 wake-on-lan (WOL) works only after a manual
suspend/resume cycle
https://bugzilla.kernel.org/show_bug.cgi?id=208033
From: Fugang Duan
Enable ethernet wake-on-lan feature for imx6q/dl/qp sabresd
boards since the PHY clock is supplied by external osc.
Reviewed-by: Andrew Lunn
Signed-off-by: Fugang Duan
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm
From: Andrew Lunn Sent: Monday, May 25, 2020 9:52 PM
> On Mon, May 25, 2020 at 03:09:29PM +0800, fugang.d...@nxp.com wrote:
> > From: Fugang Duan
> >
> > Enable ethernet wake-on-lan feature for imx6q/dl/qp sabresd boards
> > since the PHY clock is supplied by
On Mon, May 25, 2020 at 03:09:29PM +0800, fugang.d...@nxp.com wrote:
> From: Fugang Duan
>
> Enable ethernet wake-on-lan feature for imx6q/dl/qp sabresd
> boards since the PHY clock is supplied by exteranl osc.
external
Reviewed-by: Andrew Lunn
Andrew
From: Fugang Duan
Enable ethernet wake-on-lan feature for imx6q/dl/qp sabresd
boards since the PHY clock is supplied by exteranl osc.
Signed-off-by: Fugang Duan
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6qdl
From: Fugang Duan
Enable ethernet wake-on-lan feature for imx6q/dl/qp sabresd
boards since the PHY clock is supplied by exteranl osc.
Signed-off-by: Fugang Duan
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6qdl
From: Nicolas Ferre
Hi,
Here is a split series to fix WoL magic-packet on the current macb driver. Only
fixes in this one based on current net/master.
Best regards,
Nicolas
Changes in v4:
- Pure bug fix series for 'net'. GEM addition and MACB update removed: will be
sent later.
Changes in
From:
Date: Mon, 4 May 2020 15:44:15 +0200
> Here is the 3rd series to fix WoL magic-packet on the current macb driver.
> I also add, in the second part of this series the feature to GEM types of IPs.
> Please tell me if they should be separated; but the two last patches cannot go
> without the 5
From: Nicolas Ferre
Hi,
Here is the 3rd series to fix WoL magic-packet on the current macb driver.
I also add, in the second part of this series the feature to GEM types of IPs.
Please tell me if they should be separated; but the two last patches cannot go
without the 5 fixes first ones.
MACB an
> > +static int dp83867_set_wol(struct phy_device *phydev,
> > + struct ethtool_wolinfo *wol)
> > +{
> > + struct net_device *ndev = phydev->attached_dev;
> > + u16 val_rxcfg, val_micr;
> > + const u8 *mac;
> > +
> > + val_rxcfg = phy_read_mmd(phydev, DP83867_DEVADDR, D
On 22.10.2019 15:06, Thomas Hämmerle wrote:
> From: Thomas Haemmerle
>
> This adds WoL support on TI DP83867 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Thomas Haemmerle
> ---
> drivers/net/phy/dp83867.c | 131
> +-
> 1 file
On Tue, Oct 22, 2019 at 01:06:35PM +, Thomas Hämmerle wrote:
> From: Thomas Haemmerle
>
> This adds WoL support on TI DP83867 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Thomas Haemmerle
Reviewed-by: Andrew Lunn
Andrew
On Tue, 22 Oct 2019 13:06:35 +, Thomas Hämmerle wrote:
> From: Thomas Haemmerle
>
> This adds WoL support on TI DP83867 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Thomas Haemmerle
Reviewed-by: Michael Tretter
> ---
> drivers/net/phy/dp83867.c | 131
> +
From: Thomas Haemmerle
This adds WoL support on TI DP83867 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Thomas Haemmerle
---
drivers/net/phy/dp83867.c | 131 +-
1 file changed, 130 insertions(+), 1 deletion(-)
diff --git a/drivers/
On Tue, Oct 22, 2019 at 11:11:07AM +, Thomas Hämmerle wrote:
> + if (wol->wolopts & WAKE_MAGICSECURE) {
> + phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RXFSOP1,
> + (wol->sopass[1] << 8) | wol->sopass[0]);
> +
From: Thomas Haemmerle
This adds WoL support on TI DP83867 for magic, magic secure, unicast and
broadcast.
Signed-off-by: Thomas Haemmerle
---
drivers/net/phy/dp83867.c | 131 +-
1 file changed, 130 insertions(+), 1 deletion(-)
diff --git a/drivers/
From: Dmitry Bezrukov
Signed-off-by: Dmitry Bezrukov
Signed-off-by: Igor Russkikh
---
drivers/net/usb/aqc111.c | 180 +++
drivers/net/usb/aqc111.h | 12 +++
2 files changed, 192 insertions(+)
diff --git a/drivers/net/usb/aqc111.c b/drivers/net/usb/aqc111.c
From: Heiner Kallweit
Date: Thu, 25 Oct 2018 18:40:19 +0200
> It was reported that WoL from S5 is broken (WoL from S3 works) and the
> analysis showed that during system shutdown the network interface was
> brought down already when the actual kernel shutdown started.
> Therefore netif_running()
It was reported that WoL from S5 is broken (WoL from S3 works) and the
analysis showed that during system shutdown the network interface was
brought down already when the actual kernel shutdown started.
Therefore netif_running() returned false and as a consequence the PHY
was suspended. Obviously W
The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.
Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet
adapters")
Signed-off-by: Florian Fainelli
---
d
On Thu, Aug 09, 2018 at 11:03:59AM -0700, Florian Fainelli wrote:
> Hi John,
>
> This patch series syncs up ethtool-copy.h to get the new definitions
> required for supporting wake-on-LAN using filters: WAKE_FILTER and
> RX_CLS_FLOW_WAKE and then updates the rxclass.c code
Hi John,
This patch series syncs up ethtool-copy.h to get the new definitions
required for supporting wake-on-LAN using filters: WAKE_FILTER and
RX_CLS_FLOW_WAKE and then updates the rxclass.c code to allow us to
specify action -2 (RX_CLS_FLOW_WAKE).
Let me know if you would like this to be done
Hi John,
This patch series syncs up ethtool-copy.h to get the new definitions
required for supporting wake-on-LAN using filters: WAKE_FILTER and
RX_CLS_FLOW_WAKE and then updates the rxclass.c code to allow us to
specify action -2 (RX_CLS_FLOW_WAKE).
Let me know if you would like this to be done
From: Florian Fainelli
Date: Tue, 7 Aug 2018 10:50:19 -0700
> This is technically a v2, but this patch series builds on your feedback
> and defines the following:
>
> - a new WAKE_* bit: WAKE_FILTER which can be enabled alongside other type
> of Wake-on-LAN to support
Define a way to specify that a flow's action is to be used for
Wake-on-LAN purposes (using -2 as an action value) and define a new
Wake-on-LAN flag: 'f' which enables the Ethernet adapter for Wake-on-LAN
using filters.
Signed-off-by: Florian Fainelli
---
ethtool-copy.h | 2 +
Hi David, John,
This is technically a v2, but this patch series builds on your feedback
and defines the following:
- a new WAKE_* bit: WAKE_FILTER which can be enabled alongside other type
of Wake-on-LAN to support waking up on a programmed filter (match + action)
- a new RX_CLS_FLOW_WAKE flow
Hi David, John,
This is technically a v2, but this patch series builds on your feedback
and defines the following:
- a new WAKE_* bit: WAKE_FILTER which can be enabled alongside other type
of Wake-on-LAN to support waking up on a programmed filter (match + action)
- a new RX_CLS_FLOW_WAKE flow
Define a way to specify that a flow's action is to be used for
Wake-on-LAN purposes (using -2 as an action value) and define a new
Wake-on-LAN flag: 'f' which enables the Ethernet adapter for Wake-on-LAN
using filters.
Signed-off-by: Florian Fainelli
---
ethtool-copy.h | 2 +
On Tue, Jul 17, 2018 at 09:28:52AM -0700, Florian Fainelli wrote:
>
>
> On 07/17/2018 09:21 AM, Andrew Lunn wrote:
> ethtool -s gphy wol f filters 0x2
> >>>
> >>> What does this 0x2 represent?
> >>
> >> 0x2 = bit 1 is set, which corresponds to the filter ID that was returned
> >> from the pr
On 07/17/2018 09:21 AM, Andrew Lunn wrote:
ethtool -s gphy wol f filters 0x2
>>>
>>> What does this 0x2 represent?
>>
>> 0x2 = bit 1 is set, which corresponds to the filter ID that was returned
>> from the previous ethtool::rxnfc command invocation. If ethtool
>> --config-nfc returned 3, th
> >> ethtool -s gphy wol f filters 0x2
> >
> > What does this 0x2 represent?
>
> 0x2 = bit 1 is set, which corresponds to the filter ID that was returned
> from the previous ethtool::rxnfc command invocation. If ethtool
> --config-nfc returned 3, then we would have used filters 0x8, etc.
It woul
On 07/17/2018 08:47 AM, Andrew Lunn wrote:
> On Tue, Jul 17, 2018 at 08:36:37AM -0700, Florian Fainelli wrote:
>> Hi all,
>>
>> This patch series adds support for allowing Wake-on-LAN to wake-up the
>> system using configurable filters. This is particular useful i
On Tue, Jul 17, 2018 at 08:36:37AM -0700, Florian Fainelli wrote:
> Hi all,
>
> This patch series adds support for allowing Wake-on-LAN to wake-up the
> system using configurable filters. This is particular useful in the context
> of Android where wake on MDNS is a requirement.
Hi all,
This patch series adds support for allowing Wake-on-LAN to wake-up the
system using configurable filters. This is particular useful in the context
of Android where wake on MDNS is a requirement.
We support this by using the bcm_sf2 Compact Field Processor (CFP) which
supports matching
On Fri, Oct 6, 2017 at 9:24 AM, Rafael J. Wysocki wrote:
>> On the other hand, the RP05 (root port) _PRW says it will wake up the
>> system via GPE09, and the _L09 handler at least has one codepath which
>> could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.
>
> Which can only h
On Fri, Oct 6, 2017 at 8:16 AM, Francois Romieu wrote:
> Daniel Drake :
> [...]
>> Also, is there a standard behaviour defined for ethernet drivers
>> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
>> if it believes the hardware is capable of it
to indicate an ethernet wakeup.
Which can only happen in the S0 system state.
> But in testing:
> - If GPE08 is enabled as a wakeup source, the system will always wake
> up as soon as it goes to sleep
What exactly do you mean by "enabled as a wakeup source"?
> - I have n
Daniel Drake :
[...]
> Also, is there a standard behaviour defined for ethernet drivers
> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
> if it believes the hardware is capable of it,
If so it isn't its designed behavior.
The r8169 driver does not enabl
could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.
But in testing:
- If GPE08 is enabled as a wakeup source, the system will always wake
up as soon as it goes to sleep
- I have never seen a wakeup on GPE09
- Disabling GPE08 and all other GPE wakeups, the system sleeps fine,
and Wake-o
;> > + /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */
>> > + priv->clk = devm_clk_get(&pdev->dev, NULL);
>> > + if (IS_ERR(priv->clk))
>> > + priv->clk = NULL;
>>
>> Can you get EPROBE_DEFER
From: Niklas Söderlund
Date: Tue, 1 Aug 2017 12:14:35 +0200
> WoL is enabled in the suspend callback by setting MagicPacket detection
> and disabling all interrupts expect MagicPacket. In the resume path the
> driver needs to reset the hardware to rearm the WoL logic, this prevents
> the driver
Supports Wake-on: g
Wake-on: d
when NIC doesn't support WoL- ethtool reports:
Supports Wake-on: d
Wake-on: d
Fixes: 14c07b1358ed ("mlx4: Wake on LAN support")
Signed-off-by: Inbar Karmy
Signed-off-by: Tariq Toukan
---
drivers/net/ether
Hello!
On 08/01/2017 01:14 PM, Niklas Söderlund wrote:
WoL is enabled in the suspend callback by setting MagicPacket detection
and disabling all interrupts expect MagicPacket. In the resume path the
driver needs to reset the hardware to rearm the WoL logic, this prevents
the driver from simply
get_wol,
+ .set_wol= ravb_set_wol,
};
static inline int ravb_hook_irq(unsigned int irq, irq_handler_t handler,
@@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev)
priv->chip_id = chip_id;
+ /* Get clock, if not found that's OK but Wak
first place this was a bug in v1.
Niklas Söderlund (2):
ravb: add wake-on-lan support via magic packet
ravb: add workaround for clock when resuming with WoL enabled
drivers/net/ethernet/renesas/ravb.h | 2 +
drivers/net/ethernet/renesas/ravb_main.c | 131 +
Hi Sergei,
Thanks for your feedback!
On 2017-07-31 22:47:12 +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 07/30/2017 05:06 PM, Niklas Söderlund wrote:
>
> > WoL is enabled in the suspend callback by setting MagicPacket detection
> > and disabling all interrupts expect MagicPacket. In the resume
Hello!
On 07/30/2017 05:06 PM, Niklas Söderlund wrote:
WoL is enabled in the suspend callback by setting MagicPacket detection
and disabling all interrupts expect MagicPacket. In the resume path the
driver needs to reset the hardware to rearm the WoL logic, this prevents
the driver from simply
@@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > priv->chip_id = chip_id;
> > > >
> > > > + /* Get clock, if not found that's OK but Wake-On-Lan is
priv->chip_id = chip_id;
> > >
> > > + /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */
> > > + priv->clk = devm_clk_get(&pdev->dev, NULL);
> > > + if (IS_ERR(priv->clk))
> > > + priv->clk = NULL;
>
Hi Andrew,
On 2017-07-30 19:07:38 +0200, Andrew Lunn wrote:
> Hi Niklas
>
> > @@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev)
> >
> > priv->chip_id = chip_id;
> >
> > + /* Get clock, if not found that's OK but Wak
Hi Niklas
> @@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev)
>
> priv->chip_id = chip_id;
>
> + /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */
> + priv->clk = devm_clk_get(&pdev->dev,
andler,
@@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev)
priv->chip_id = chip_id;
+ /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */
+ priv->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(
Hi Niklas,
On Mon, Jun 12, 2017 at 1:32 PM, Niklas Söderlund
wrote:
> On 2017-05-18 10:52:25 +0200, Geert Uytterhoeven wrote:
>> On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
>> wrote:
>> > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
>> >> On Tue, May 16, 2017 at 1:01 PM, Simon H
Hi Geert,
On 2017-05-18 10:52:25 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
> wrote:
> > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote:
> >> > Is there some way for - e.g.
On SYSTEMPORT Lite, since we have the main interrupt source in the first
cell, the second cell is the Wake-on-LAN interrupt, yet the code was not
properly updated to fetch the second cell, and instead looked at the
third and non-existing cell for Wake-on-LAN.
Fixes: 44a4524c54af ("net: syste
On Tue, May 16, 2017 at 02:16:04PM +0200, Niklas Söderlund wrote:
> Hi,
>
> On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
> > Hi Simon,
> >
> > On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote:
> > > On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven wrote:
> > >> On Tue,
Hi Niklas,
On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
wrote:
> On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
>> On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote:
>> > Is there some way for - e.g. the driver - to not enable WoL on Gen3 SoCs
>> > until the clock issues is sorte
Hi,
On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote:
> > On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund
> >> wrote:
> >> >> > Whit all this be
Hi Simon,
On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote:
> On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund
>> wrote:
>> >> > Whit all this being said I still like to withdraw this patch as I found
>> >> > another fau
On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund
> wrote:
> >> > Whit all this being said I still like to withdraw this patch as I found
> >> > another fault with it, ravb_wol_restore() will unconditionally be
Hi Niklas,
On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund
wrote:
>> > Whit all this being said I still like to withdraw this patch as I found
>> > another fault with it, ravb_wol_restore() will unconditionally be called
>> > while ravb_wol_setup() will only be called if netif_running(ndev). T
t 4:32 PM, Niklas Söderlund
> >> wrote:
> >> > On 2017-05-12 14:58:53 +0200, Niklas Söderlund wrote:
> >> >> On 2017-05-12 14:47:53 +0200, Geert Uytterhoeven wrote:
> >> >> > On Fri, May 12, 2017 at 12:27 AM, Niklas Söderlund
> >> >> >
On 2017-05-12 14:47:53 +0200, Geert Uytterhoeven wrote:
>> >> > On Fri, May 12, 2017 at 12:27 AM, Niklas Söderlund
>> >> > wrote:
>> >> > When using PSCI suspend/resume, and Wake-on-LAN cannot work due to
>> >> > PSCI firmware issues, Etherne
> >> > > suspend callback need to call clk_enable() directly to increase the
> >> > > usage count of the clock. Then when Runtime PM decreases the clock
> >> > > usage
> >> > > count it won't reach 0 and be switched off.
> >&g
t;> > > from being switched off by Runtime PM. To keep the clock alive the
>> > > suspend callback need to call clk_enable() directly to increase the
>> > > usage count of the clock. Then when Runtime PM decreases the clock usage
>> > > count it won'
by Runtime PM. To keep the clock alive the
> > > suspend callback need to call clk_enable() directly to increase the
> > > usage count of the clock. Then when Runtime PM decreases the clock usage
> > > count it won't reach 0 and be switched off.
> > >
> &g
_enable() directly to increase the
>> > usage count of the clock. Then when Runtime PM decreases the clock usage
>> > count it won't reach 0 and be switched off.
>> >
>> > Signed-off-by: Niklas Söderlund
>>
>> Thanks for your patch!
>>
>&g
time PM decreases the clock usage
> > count it won't reach 0 and be switched off.
> >
> > Signed-off-by: Niklas Söderlund
>
> Thanks for your patch!
>
> Wake-on-LAN now works for me on Salvator-X (both H3 and M3).
>
> However, after a few cycles, Ethernet s
the
> suspend callback need to call clk_enable() directly to increase the
> usage count of the clock. Then when Runtime PM decreases the clock usage
> count it won't reach 0 and be switched off.
>
> Signed-off-by: Niklas Söderlund
Thanks for your patch!
Wake-on-LAN now works
Hello!
On 05/12/2017 01:27 AM, Niklas Söderlund wrote:
WoL is enabled in the suspend callback by setting MagicPacket detection
and disabling all interrupts expect MagicPacket. In the resume path the
Except.
driver needs to reset the hardware to rearm the WoL logic, this prevents
the driv
wol= ravb_get_wol,
+ .set_wol= ravb_set_wol,
};
static inline int ravb_hook_irq(unsigned int irq, irq_handler_t handler,
@@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev)
priv->chip_id = chip_id;
+ /* G
From: Florian Fainelli
Date: Wed, 15 Mar 2017 12:57:21 -0700
> Suspending the PHY would be putting it in a low power state where it
> may no longer allow us to do Wake-on-LAN.
>
> Fixes: cc013fb48898 ("net: bcmgenet: correctly suspend and resume PHY device")
> Signed
Suspending the PHY would be putting it in a low power state where it
may no longer allow us to do Wake-on-LAN.
Fixes: cc013fb48898 ("net: bcmgenet: correctly suspend and resume PHY device")
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6
1 - 100 of 261 matches
Mail list logo
