lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bee22b7-ed4c-43d1-9bf2-d8397b5e01e5@gmail.com>
Date: Mon, 1 Dec 2025 21:15:42 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: René Rebe <rene@...ctco.de>, netdev@...r.kernel.org
Cc: nic_swsd@...ltek.com
Subject: Re: [PATCH] r8169: fix RTL8117 Wake-on-Lan in DASH mode

On 12/1/2025 8:17 PM, René Rebe wrote:
> Wake-on-Lan does currently not work in DASH mode, e.g. the ASUS Pro WS
> X570-ACE with RTL8168fp/RTL8117.
> 
> Fix by not returning early in rtl_prepare_power_down when dash_enabled.
Good

> While this fixes WOL, it still kills the OOB RTL8117 remote management
> BMC connection. Fix by not calling rtl8168_driver_stop if wol is enabled.
> 
You mean remote management whilst system is powered down and waiting
for a WoL packet? Note that link speed is reduced to a minimum then,
and DMA is disabled. Who would drive the MAC?
Realtek doesn't provide any chip documentation, therefore it's hard to
say what is expected from the MAC driver in DASH case.

> While at it, enable wake on magic packet by default, like most other
> Linux drivers do.
> 
It's by intent that WoL is disabled per default. Most users don't use WoL
and would suffer from higher power consumption if system is suspended
or powered down.
Which benefit would you see if WoL would be enabled by default
(in DASH and non-DASH case)?

> Signed-off-by: René Rebe <rene@...ctco.de>

Your patch apparently is meant to be a fix. Therefore please add Fixes
tag and address to net tree.
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.rst
And please add all netdev maintainers when re-submitting.
scripts/get_maintainer.pl provides all needed info.

> ---
> 
> There is still another issue that should be fixed: the dirver init
> kills the OOB BMC connection until if up, too. We also should probaly
> not even conditionalize rtl8168_driver_stop on wol_enabled as the BMC
> should always be accessible. IMHO even on module unload.
> 
> ---
>  drivers/net/ethernet/realtek/r8169_main.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index 853aabedb128..e2f9b9027fe2 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -2669,9 +2669,6 @@ static void rtl_wol_enable_rx(struct rtl8169_private *tp)
>  
>  static void rtl_prepare_power_down(struct rtl8169_private *tp)
>  {
> -	if (tp->dash_enabled)
> -		return;
> -
>  	if (tp->mac_version == RTL_GIGA_MAC_VER_32 ||
>  	    tp->mac_version == RTL_GIGA_MAC_VER_33)
>  		rtl_ephy_write(tp, 0x19, 0xff64);
> @@ -4807,7 +4804,7 @@ static void rtl8169_down(struct rtl8169_private *tp)
>  	rtl_disable_exit_l1(tp);
>  	rtl_prepare_power_down(tp);
>  
> -	if (tp->dash_type != RTL_DASH_NONE)
> +	if (tp->dash_type != RTL_DASH_NONE && !tp->saved_wolopts)
>  		rtl8168_driver_stop(tp);
>  }
>  
> @@ -5406,6 +5403,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>  	tp->pci_dev = pdev;
>  	tp->supports_gmii = ent->driver_data == RTL_CFG_NO_GBIT ? 0 : 1;
>  	tp->ocp_base = OCP_STD_PHY_BASE;
> +	tp->saved_wolopts = WAKE_MAGIC;
>  
>  	raw_spin_lock_init(&tp->mac_ocp_lock);
>  	mutex_init(&tp->led_lock);
> @@ -5565,6 +5563,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>  	if (rc)
>  		return rc;
>  
> +	if (tp->saved_wolopts)
> +		__rtl8169_set_wol(tp, tp->saved_wolopts);
> +
>  	rc = register_netdev(dev);
>  	if (rc)
>  		return rc;


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ