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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5606063c65f9b67e036497c24fa8c527ebd24fae.camel@declera.com>
Date:   Tue, 15 Mar 2022 16:19:06 +0200
From:   Yanko Kaneti <yaneti@...lera.com>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Nicfae <Nicfae@...ltek.com>,
        Kevin_cheng <kevin_cheng@...ltek.com>
Subject: Re: r8169: rtl8168ep_driver_stop disables the DASH port

On Tue, 2022-03-15 at 12:25 +0200, Yanko Kaneti wrote:
> On Tue, 2022-03-15 at 11:40 +0200, Yanko Kaneti wrote:
> > On Mon, 2022-03-14 at 22:24 +0100, Heiner Kallweit wrote:
> > > On 14.03.2022 15:05, Yanko Kaneti wrote:
> > > > On Mon, 2022-03-14 at 01:00 +0000, Kevin_cheng wrote:
> > > > Hello Kevin,
> > > > 
> > > > > Thanks for your email. Linux DASH requires specific driver and client
> > > > > tool. It depends on the manufacturer’s requirement. You need to
> > > > > contact ASRock to make sure they support Linux DASH and have verified
> > > > > it.
> > > > 
> > > > Thanks for the answer but its not much help for me.
> > > > I am not going to use a driver that's not in mainline.
> > > > 
> > > > I wasn't really expecting full DASH support but that at least
> > > > r8169/linux does not prevent the limied DASH web interface functionality
> > > > from working.
> > > > 
> > > > Currently this is not the case on this board with the current BIOS:
> > > >  - Once the kernel is loaded the DASH web interface power management
> > > > (reset, hard off) no longer works
> > > >  - Normal shutdown or r8169 module unload actually disconnects the phy.
> > > >  
> > > > It would be nice if DASH basics worked without being broken/supported by
> > > > the OS.
> > > > 
> > > > Regards
> > > > Yanko
> > > > 
> > > > > 
> > > > > Best Regards
> > > > > Kevin Cheng
> > > > > Technical Support Dept.
> > > > > Realtek Semiconductor Corp.
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Yanko Kaneti <yaneti@...lera.com> 
> > > > > Sent: Friday, March 11, 2022 9:12 PM
> > > > > To: Heiner Kallweit <hkallweit1@...il.com>; nic_swsd
> > > > > <nic_swsd@...ltek.com>
> > > > > Cc: netdev <netdev@...r.kernel.org>
> > > > > Subject: r8169: rtl8168ep_driver_stop disables the DASH port
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > Testing DASH on a ASRock A520M-HDVP/DASH, which has a RTL8111/8168 EP
> > > > > chip. DASH is enabled and seems to work on BIOS/firmware level.
> > > > > 
> > > > > It seems that r8169's cleanup/exit in rtl8168ep_driver_stop manages to
> > > > > actually stop the LAN port, hence cutting the system remote
> > > > > management.
> > > > > 
> > > > > This is evident on plain shutdown or rmmod r8169.
> > > > > If one does a hardware reset or echo "b" > /proc/sysrq-trigger  the
> > > > > cleanup doesn't happen and the DASH firmware remains in working order
> > > > > and the LAN port remains up.
> > > > > 
> > > > > A520M-HDVP/DASH BIOS ver 1.70
> > > > > Reatlek fw:
> > > > >  Firmware Version:               3.0.0.20200423
> > > > >  Version String:         20200428.1200000113
> > > > >  
> > > > > I have no idea if its possible or how to update the realtek firmware,
> > > > > preferably from Linux.
> > > > > 
> > > > > Various other DASH functionality seems to not work but basic working
> > > > > power managements is really a deal breaker for the whole thing.
> > > > > 
> > > > > 
> > > > > Regards
> > > > > Yanko
> > > > > ------Please consider the environment before printing this e-mail.
> > > > 
> > > 
> > > Realtek doesn't provide any public datasheets, therefore it's hard to say
> > > how DASH is handled in the chip.
> > > However there are few places left where the PHY may be suspended w/o
> > > checking for DASH. Can you try the following?
> > > 
> > > 
> > > diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> > > index 67014eb76..95788ce7a 100644
> > > --- a/drivers/net/ethernet/realtek/r8169_main.c
> > > +++ b/drivers/net/ethernet/realtek/r8169_main.c
> > > @@ -1397,8 +1397,13 @@ static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
> > >  	rtl_lock_config_regs(tp);
> > >  
> > >  	device_set_wakeup_enable(tp_to_dev(tp), wolopts);
> > > -	rtl_set_d3_pll_down(tp, !wolopts);
> > > -	tp->dev->wol_enabled = wolopts ? 1 : 0;
> > > +	if (tp->dash_type == RTL_DASH_NONE) {
> > > +		rtl_set_d3_pll_down(tp, !wolopts);
> > > +		tp->dev->wol_enabled = wolopts ? 1 : 0;
> > > +	} else {
> > > +		/* keep PHY from suspending if DASH is enabled */
> > > +		tp->dev->wol_enabled = 1;
> > > +	}
> > >  }
> > >  
> > >  static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> > > @@ -4672,7 +4677,7 @@ static void r8169_phylink_handler(struct net_device *ndev)
> > >  	if (netif_carrier_ok(ndev)) {
> > >  		rtl_link_chg_patch(tp);
> > >  		pm_request_resume(&tp->pci_dev->dev);
> > > -	} else {
> > > +	} else if (tp->dash_type == RTL_DASH_NONE) {
> > >  		pm_runtime_idle(&tp->pci_dev->dev);
> > >  	}
> > >  
> > > @@ -4978,7 +4983,8 @@ static void rtl_shutdown(struct pci_dev *pdev)
> > >  	/* Restore original MAC address */
> > >  	rtl_rar_set(tp, tp->dev->perm_addr);
> > >  
> > > -	if (system_state == SYSTEM_POWER_OFF) {
> > > +	if (system_state == SYSTEM_POWER_OFF &&
> > > +	    tp->dash_type == RTL_DASH_NONE) {
> > >  		if (tp->saved_wolopts)
> > >  			rtl_wol_shutdown_quirk(tp);
> > >  
> > 
> > Thanks Heiner. 
> > So I tried this over linus tip from today and unfortunately it doesn't
> > help the shutdown or rmmod. 
> > With the couple more additions below I can get it to stay up on rmmod  ,
> > but still after that , shutdown still brings it down. Perhaps that
> > leaves all to the BIOS/realtek firmware..
> > 
> > 
> > diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> > index 19e2621e0645..d5d85a44be3e 100644
> > --- a/drivers/net/ethernet/realtek/r8169_main.c
> > +++ b/drivers/net/ethernet/realtek/r8169_main.c
> > @@ -4675,7 +4680,8 @@ static void rtl8169_down(struct rtl8169_private *tp)
> >         /* Clear all task flags */
> >         bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
> >  
> > -       phy_stop(tp->phydev);
> > +       if (tp->dash_type == RTL_DASH_NONE)
> > +               phy_stop(tp->phydev);
> >  
> >         rtl8169_update_counters(tp);
> >  
> > @@ -4715,7 +4721,8 @@ static int rtl8169_close(struct net_device *dev)
> >  
> >         free_irq(tp->irq, tp);
> >  
> > -       phy_disconnect(tp->phydev);
> > +       if (tp->dash_type == RTL_DASH_NONE)
> > +               phy_disconnect(tp->phydev);
> >  
> >         dma_free_coherent(&pdev->dev, R8169_RX_RING_BYTES, tp->RxDescArray,
> >                           tp->RxPhyAddr);
> > 
> 
> Some additional data points:
> 
> - with r8169 blacklisted the link survives shutdown
> 
> - even with r8169 blacklisted the DASH web interface stops being able to
> control power/off/reset
> 
> - with rtl8168_driver_start/stop commented followed by rmmod r8169 and
> link still up  it still goes down on shutdown

After some random poking I managed to keep the link up after shutdown. 
All the previous bits plus this init tweak:

@@ -5409,7 +5417,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
        /* configure chip for default features */
        rtl8169_set_features(dev, dev->features);
 
-       rtl_set_d3_pll_down(tp, true);
+       if (tp->dash_type == RTL_DASH_NONE)
+               rtl_set_d3_pll_down(tp, true);
 
        jumbo_max = rtl_jumbo_max(tp);
        if (jumbo_max)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ