| 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
| ||
|
Date: Wed, 16 Mar 2022 11:34:19 +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 20:24 +0100, Heiner Kallweit wrote:
> On 15.03.2022 15:19, Yanko Kaneti wrote:
> > 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)
> >
>
> Thanks for your efforts. We can not omit the phy_.. calls in the non-DASH case,
> therefore could you please test the following (replacing the first attempt)?
>
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index 67014eb76..33f5c5698 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -1397,8 +1397,11 @@ 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;
> + }
> }
>
> static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> @@ -4938,6 +4941,9 @@ static int rtl8169_runtime_idle(struct device *device)
> {
> struct rtl8169_private *tp = dev_get_drvdata(device);
>
> + if (tp->dash_type != RTL_DASH_NONE)
> + return -EBUSY;
> +
> if (!netif_running(tp->dev) || !netif_carrier_ok(tp->dev))
> pm_schedule_suspend(device, 10000);
>
> @@ -4978,7 +4984,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);
>
> @@ -5449,7 +5456,12 @@ 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);
> + } else {
> + rtl_set_d3_pll_down(tp, false);
> + dev->wol_enabled = 1;
> + }
>
> jumbo_max = rtl_jumbo_max(tp);
> if (jumbo_max)
Thanks Heiner, that does it!
The link survives both rmmod and shutdown.
Now if only someone could figure out how to trick the realtek DASH
firmware web interface to keep managing the power state after the OS is
booted. Being able to reset a stuck system is the minimum I would think.
Anyone at Realtek that can help here?
Powered by blists - more mailing lists