Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp948198pxj; Fri, 4 Jun 2021 02:11:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsn4uDnXiUd3HCeRNXiDvYNBDKGVv4GxQB+aktKhw6MLUoigSF+CZ0uGtkTuMKZqZS+6VE X-Received: by 2002:a17:906:6712:: with SMTP id a18mr564022ejp.334.1622797861852; Fri, 04 Jun 2021 02:11:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622797861; cv=none; d=google.com; s=arc-20160816; b=Vjz7uekKNtVw/mfeHmtzv/9uyvWPnXcBl9K2cBq7SoJmToLWcIA9S8BI+9g9m60g/G 3biwkzU+4fBUUM/V0VJ4V2GM/6L7BVeVuKs/44gP1Welpl0AZ0IskhXWRzXsryMnevEa yp9Lo7CCNeWWXrengZ0Ixd0Mg5YEmklJoaIne5kNuZrn9gJVSRCMoHpkHL3tpxO5iGhM LAcB0Tf91ABo5kIVUNSaEXvBa7S4lrkBdXx8mSE6+hpATCgqz8sQMuloedyspWfV41tf 9QSAZkHbQsVp9maEeE3NX6I/u4qeINDPVHVsZiCRNa24RAqZH1RMfqb616Q+/0zBVbfT FpAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=IAQHwFDolejrdoM6x/e0E1Vv5HxCw5mIB7TDT+a2OxY=; b=UYh8x11JQx8rYGCONetpVR8qj1Yxs+sQmBifAEFXFMMKZkx/Qsjir6iS0fzRcUbevq Dj+oeFEXG2Lzpq0DQidyRCDB/vU2BAqTYozfCZN7TGwj7DXTiCl5ZeLM1O4eh0z74N7A uWb0AY3a0myl6m9HDt8Ompm0FWbrw2SppcrU0o0hjZGFZOHaA5q8mbv3l4yIZacsO5q/ UtjPszm8Uf/GfU9s1KfqRwTRYffK14I0Bv0lWwz9Q43vd5m2NC/ui97NKtbzKTDv+UJC d+O4Eu9andwoBmbTwai1BvhDvFah/R1cE38zAdTnp+4/xoghAmjngd11w7VGtbh70OvM e4cQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i18si3951847edr.251.2021.06.04.02.10.36; Fri, 04 Jun 2021 02:11:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229982AbhFDJKv (ORCPT + 99 others); Fri, 4 Jun 2021 05:10:51 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:41061 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229959AbhFDJKv (ORCPT ); Fri, 4 Jun 2021 05:10:51 -0400 Received: from mail-oo1-f71.google.com ([209.85.161.71]) by youngberry.canonical.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lp5pA-0007Vy-Jl for linux-kernel@vger.kernel.org; Fri, 04 Jun 2021 09:09:04 +0000 Received: by mail-oo1-f71.google.com with SMTP id b3-20020a4ab4830000b029020d5d68e38dso4987102ooo.21 for ; Fri, 04 Jun 2021 02:09:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IAQHwFDolejrdoM6x/e0E1Vv5HxCw5mIB7TDT+a2OxY=; b=k0SiFHK8fpPK12vgAiqPtU3gA9K702VDUU0KI4kdwVqY63byLtvB9Oj+JwWOWwihdO +NN2MEdS3A4PEmrzNEX08kZ1mpE1L74zXqrtch/QFc2MVdB1m7wdRHNZ9/q2mGywwPVU XuTgGqWSSN9WYMhED2JiTXl1TAczQ3A8cnWIqbqZk1s4azUunrUqDKp7mRzBbhPICvXv 8StYZyy54n7oAu+K2suhJZfWysb4vhfa7hHJWb/0UOrM9xgjaajTpxuTVU0lXI2L9G+U pyHV8q/xCrVNn2XZIxyQLts69vMluEfEh0jn/HFHLMqsLuh9rBJHpQiZgK8xigYaY0xY O0QQ== X-Gm-Message-State: AOAM5305qPGS6yLhr4n5biaI8kIXPZaSdKUSXEAlRvIDHZs03bE+Ish6 0/zu9LMnsjiYF4P5z4yFPZTuvFhTb+NZWl1sQj8y/FINXM+q5m+Bmqt7faU7oYibK26/swlTPjI VHQ9/GOkQGPQk2HENSg1/pwDW99y7tEkNlEODZYx4vF8qazqG4Wbd4d2Emw== X-Received: by 2002:a9d:1ec6:: with SMTP id n64mr2915993otn.3.1622797743176; Fri, 04 Jun 2021 02:09:03 -0700 (PDT) X-Received: by 2002:a9d:1ec6:: with SMTP id n64mr2915967otn.3.1622797742813; Fri, 04 Jun 2021 02:09:02 -0700 (PDT) MIME-Version: 1.0 References: <20210603025414.226526-1-koba.ko@canonical.com> <3d2e7a11-92ad-db06-177b-c6602ef1acd4@gmail.com> In-Reply-To: From: Koba Ko Date: Fri, 4 Jun 2021 17:08:51 +0800 Message-ID: Subject: Re: [PATCH] r8169: introduce polling method for link change To: Heiner Kallweit Cc: "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 4, 2021 at 4:23 PM Heiner Kallweit wrote: > > On 04.06.2021 09:22, Koba Ko wrote: > > On Thu, Jun 3, 2021 at 6:00 PM Heiner Kallweit wrote: > >> > >> On 03.06.2021 04:54, Koba Ko wrote: > >>> For RTL8106E, it's a Fast-ethernet chip. > >>> If ASPM is enabled, the link chang interrupt wouldn't be triggered > >>> immediately and must wait a very long time to get link change interrupt. > >>> Even the link change interrupt isn't triggered, the phy link is already > >>> established. > >>> > >> At first please provide a full dmesg log and output of lspci -vv. > >> Do you have the firmware for the NIC loaded? Please provide "ethtool -i " > >> output. > > > > please get the logs from here, > > https://bugzilla.kernel.org/show_bug.cgi?id=213165 > > > >> Does the issue affect link-down and/or link-up detection? > >> Do you have runtime pm enabled? Then, after 10s of link-down NIC goes to > >> D3hot and link-up detection triggers a PME. > > > > Issue affect link-up. > > yes, pm runtime is enabled, but rtl8106e always stays D0 even if the > > cable isn't present. > > > Then runtime pm doesn't seem to be set to "auto". Else 10s after link loss > the chip runtime-suspends and is set to D3hot. I will check this. > > >> > >>> Introduce a polling method to watch the status of phy link and disable > >>> the link change interrupt. > >>> Also add a quirk for those realtek devices have the same issue. > >>> > >> Which are the affected chip versions? Did you check with Realtek? > >> Your patch switches to polling for all Fast Ethernet versions, > >> and that's not what we want. > > > > I don't know the exact version, only the chip name 806e(pci device id 0x8165). > > ok, Im asking Realtek to help how to identify the chip issue is observed. > > > At least your Bugzilla report refers to VER_39. PCI device id 0x8136 is shared > by all fast ethernet chip versions. > Do you know other affected chip versions apart from VER_39 ? > > In the Bugzilla report you also write the issue occurs with GBit-capable > link partners. This sounds more like an aneg problem. > The issue doesn't occur with fast ethernet link partners? Issue wouldn't be observed when the link-partner has only FE capability. > > Your bug report also includes a patch that disables L1_1 only. > Not sure how this is related because the chip version we speak about > here doesn't support L1 sub-states. I have tried to enable L0s, L1 and don't disable L1 substate, but still get the issue that interrupt can't be fired immediately but the Link status is up. > > >> > >> My suspicion would be that something is system-dependent. Else I think > >> we would have seen such a report before. > > On the mainline, the aspm is disable, so you may not observe this. > > If you enable ASPM and must wait CHIP go to power-saving mode, then > > you can observe the issue. > >> > > So what you're saying is that mainline is fine and your problem is with > a downstream kernel with re-enabled ASPM? So there's nothing broken in > mainline? In mainline you have the option to re-enable ASPM states > individually via sysfs (link subdir at pci device). If enable L1_1 on the mainline, the issue could be observed too. Thanks > > >>> Signed-off-by: Koba Ko > >>> --- > >>> drivers/net/ethernet/realtek/r8169.h | 2 + > >>> drivers/net/ethernet/realtek/r8169_main.c | 112 ++++++++++++++++++---- > >>> 2 files changed, 98 insertions(+), 16 deletions(-) > >>> > >>> diff --git a/drivers/net/ethernet/realtek/r8169.h b/drivers/net/ethernet/realtek/r8169.h > >>> index 2728df46ec41..a8c71adb1b57 100644 > >>> --- a/drivers/net/ethernet/realtek/r8169.h > >>> +++ b/drivers/net/ethernet/realtek/r8169.h > >>> @@ -11,6 +11,8 @@ > >>> #include > >>> #include > >>> > >>> +#define RTL8169_LINK_TIMEOUT (1 * HZ) > >>> + > >>> enum mac_version { > >>> /* support for ancient RTL_GIGA_MAC_VER_01 has been removed */ > >>> RTL_GIGA_MAC_VER_02, > >>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c > >>> index 2c89cde7da1e..70aacc83d641 100644 > >>> --- a/drivers/net/ethernet/realtek/r8169_main.c > >>> +++ b/drivers/net/ethernet/realtek/r8169_main.c > >>> @@ -178,6 +178,11 @@ static const struct pci_device_id rtl8169_pci_tbl[] = { > >>> > >>> MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl); > >>> > >>> +static const struct pci_device_id rtl8169_linkChg_polling_enabled[] = { > >>> + { PCI_VDEVICE(REALTEK, 0x8136), RTL_CFG_NO_GBIT }, > >>> + { 0 } > >>> +}; > >>> + > >> > >> This doesn't seem to be used. > >> > >>> enum rtl_registers { > >>> MAC0 = 0, /* Ethernet hardware address. */ > >>> MAC4 = 4, > >>> @@ -618,6 +623,7 @@ struct rtl8169_private { > >>> u16 cp_cmd; > >>> u32 irq_mask; > >>> struct clk *clk; > >>> + struct timer_list link_timer; > >>> > >>> struct { > >>> DECLARE_BITMAP(flags, RTL_FLAG_MAX); > >>> @@ -1179,6 +1185,16 @@ static void rtl8168ep_stop_cmac(struct rtl8169_private *tp) > >>> RTL_W8(tp, IBCR0, RTL_R8(tp, IBCR0) & ~0x01); > >>> } > >>> > >>> +static int rtl_link_chng_polling_quirk(struct rtl8169_private *tp) > >>> +{ > >>> + struct pci_dev *pdev = tp->pci_dev; > >>> + > >>> + if (pdev->vendor == 0x10ec && pdev->device == 0x8136 && !tp->supports_gmii) > >>> + return 1; > >>> + > >>> + return 0; > >>> +} > >>> + > >>> static void rtl8168dp_driver_start(struct rtl8169_private *tp) > >>> { > >>> r8168dp_oob_notify(tp, OOB_CMD_DRIVER_START); > >>> @@ -4608,6 +4624,75 @@ static void rtl_task(struct work_struct *work) > >>> rtnl_unlock(); > >>> } > >>> > >>> +static void r8169_phylink_handler(struct net_device *ndev) > >>> +{ > >>> + struct rtl8169_private *tp = netdev_priv(ndev); > >>> + > >>> + if (netif_carrier_ok(ndev)) { > >>> + rtl_link_chg_patch(tp); > >>> + pm_request_resume(&tp->pci_dev->dev); > >>> + } else { > >>> + pm_runtime_idle(&tp->pci_dev->dev); > >>> + } > >>> + > >>> + if (net_ratelimit()) > >>> + phy_print_status(tp->phydev); > >>> +} > >>> + > >>> +static unsigned int > >>> +rtl8169_xmii_link_ok(struct net_device *dev) > >>> +{ > >>> + struct rtl8169_private *tp = netdev_priv(dev); > >>> + unsigned int retval; > >>> + > >>> + retval = (RTL_R8(tp, PHYstatus) & LinkStatus) ? 1 : 0; > >>> + > >>> + return retval; > >>> +} > >>> + > >>> +static void > >>> +rtl8169_check_link_status(struct net_device *dev) > >>> +{ > >>> + struct rtl8169_private *tp = netdev_priv(dev); > >>> + int link_status_on; > >>> + > >>> + link_status_on = rtl8169_xmii_link_ok(dev); > >>> + > >>> + if (netif_carrier_ok(dev) == link_status_on) > >>> + return; > >>> + > >>> + phy_mac_interrupt(tp->phydev); > >>> + > >>> + r8169_phylink_handler (dev); > >>> +} > >>> + > >>> +static void rtl8169_link_timer(struct timer_list *t) > >>> +{ > >>> + struct rtl8169_private *tp = from_timer(tp, t, link_timer); > >>> + struct net_device *dev = tp->dev; > >>> + struct timer_list *timer = t; > >>> + unsigned long flags; > >> > >> flags isn't used and triggers a compiler warning. Did you even > >> compile-test your patch? > >> > >>> + > >>> + rtl8169_check_link_status(dev); > >>> + > >>> + if (timer_pending(&tp->link_timer)) > >>> + return; > >>> + > >>> + mod_timer(timer, jiffies + RTL8169_LINK_TIMEOUT); > >>> +} > >>> + > >>> +static inline void rtl8169_delete_link_timer(struct net_device *dev, struct timer_list *timer) > >>> +{ > >>> + del_timer_sync(timer); > >>> +} > >>> + > >>> +static inline void rtl8169_request_link_timer(struct net_device *dev) > >>> +{ > >>> + struct rtl8169_private *tp = netdev_priv(dev); > >>> + > >>> + timer_setup(&tp->link_timer, rtl8169_link_timer, TIMER_INIT_FLAGS); > >>> +} > >>> + > >>> static int rtl8169_poll(struct napi_struct *napi, int budget) > >>> { > >>> struct rtl8169_private *tp = container_of(napi, struct rtl8169_private, napi); > >>> @@ -4624,21 +4709,6 @@ static int rtl8169_poll(struct napi_struct *napi, int budget) > >>> return work_done; > >>> } > >>> > >>> -static void r8169_phylink_handler(struct net_device *ndev) > >>> -{ > >>> - struct rtl8169_private *tp = netdev_priv(ndev); > >>> - > >>> - if (netif_carrier_ok(ndev)) { > >>> - rtl_link_chg_patch(tp); > >>> - pm_request_resume(&tp->pci_dev->dev); > >>> - } else { > >>> - pm_runtime_idle(&tp->pci_dev->dev); > >>> - } > >>> - > >>> - if (net_ratelimit()) > >>> - phy_print_status(tp->phydev); > >>> -} > >>> - > >>> static int r8169_phy_connect(struct rtl8169_private *tp) > >>> { > >>> struct phy_device *phydev = tp->phydev; > >>> @@ -4769,6 +4839,10 @@ static int rtl_open(struct net_device *dev) > >>> goto err_free_irq; > >>> > >>> rtl8169_up(tp); > >>> + > >>> + if (rtl_link_chng_polling_quirk(tp)) > >>> + mod_timer(&tp->link_timer, jiffies + RTL8169_LINK_TIMEOUT); > >>> + > >>> rtl8169_init_counter_offsets(tp); > >>> netif_start_queue(dev); > >>> out: > >>> @@ -4991,7 +5065,10 @@ static const struct net_device_ops rtl_netdev_ops = { > >>> > >>> static void rtl_set_irq_mask(struct rtl8169_private *tp) > >>> { > >>> - tp->irq_mask = RxOK | RxErr | TxOK | TxErr | LinkChg; > >>> + tp->irq_mask = RxOK | RxErr | TxOK | TxErr; > >>> + > >>> + if (!rtl_link_chng_polling_quirk(tp)) > >>> + tp->irq_mask |= LinkChg; > >>> > >>> if (tp->mac_version <= RTL_GIGA_MAC_VER_06) > >>> tp->irq_mask |= SYSErr | RxOverflow | RxFIFOOver; > >>> @@ -5436,6 +5513,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > >>> if (pci_dev_run_wake(pdev)) > >>> pm_runtime_put_sync(&pdev->dev); > >>> > >>> + if (rtl_link_chng_polling_quirk(tp)) > >>> + rtl8169_request_link_timer(dev); > >>> + > >>> return 0; > >>> } > >>> > >>> > >> > >> All this isn't needed. If you want to switch to link status polling, > >> why don't you simply let phylib do it? PHY_MAC_INTERRUPT -> PHY_POLL > > > > Thanks for suggestions, I tried to use PHY_POLL, it could do the same > > thing that I did. > > > >> Your timer-based code most likely would have problems if runtime pm > >> is enabled. Then you try to read the link status whilst NIC is in > >> D3hot. >