From patchwork Tue Feb 21 02:32:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai-Heng Feng X-Patchwork-Id: 13147260 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 515D8C636D6 for ; Tue, 21 Feb 2023 02:33:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232758AbjBUCdl (ORCPT ); Mon, 20 Feb 2023 21:33:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231806AbjBUCdk (ORCPT ); Mon, 20 Feb 2023 21:33:40 -0500 Received: from smtp-relay-canonical-0.canonical.com (smtp-relay-canonical-0.canonical.com [185.125.188.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 726171024A; Mon, 20 Feb 2023 18:33:39 -0800 (PST) Received: from localhost.localdomain (unknown [10.101.196.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id C5D77400DA; Tue, 21 Feb 2023 02:33:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676946817; bh=jXActFRB2e7tUmIdxW8pUWDAQLwCu7muuixpsDg2eGI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=bkla3NDSVRSMJKGxQ0EgTPhyF9KwNUy+kcMeMfabd+tkZo0YkZXj6jBY1V+JAE8S6 VFySBuFqB4UGjrFQ/a1oS2sGQIpG0D3y1ce8DNsjDmK72BrJGKIYDRVOBTojBp5TNs eE1ycHEQ23pOcP6okGTueNDwPgVAMdmM00QSs5G1eUcZeo/0QTC6VZ3oaNHA3CCI9+ 9rADHa2w7KYo+wUrPFdfVYlV1RmwYl6cUUR0truAxUWFyv4HTmLFcXHTpwNmNSft89 whKu7fdib61D8FK6bndDnjegC94erC7cAUnor0xrVpo7224hM+WKPOuQlCelzWLgWY YPFirF4lgybbw== From: Kai-Heng Feng To: hkallweit1@gmail.com, nic_swsd@realtek.com, bhelgaas@google.com Cc: koba.ko@canonical.com, acelan.kao@canonical.com, Kai-Heng Feng , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v8 1/6] r8169: Disable ASPM L1.1 on 8168h Date: Tue, 21 Feb 2023 10:32:32 +0800 Message-Id: <20230221023237.1905536-2-kai.heng.feng@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230221023237.1905536-1-kai.heng.feng@canonical.com> References: <20230221023237.1905536-1-kai.heng.feng@canonical.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org ASPM L1/L1.1 gets enabled based on [0], but ASPM L1.1 was actually disabled too [1]. So also disable L1.1 for better compatibility. [0] https://bugs.launchpad.net/bugs/1942830 [1] https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal/commit/?id=c9b3736de48fd419d6699045d59a0dd1041da014 Signed-off-by: Kai-Heng Feng --- v8: - New patch. drivers/net/ethernet/realtek/r8169_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index 45147a1016bec..1c949822661ae 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -5224,13 +5224,13 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) /* Disable ASPM L1 as that cause random device stop working * problems as well as full system hangs for some PCIe devices users. - * Chips from RTL8168h partially have issues with L1.2, but seem - * to work fine with L1 and L1.1. + * Chips from RTL8168h partially have issues with L1.1 and L1.2, but + * seem to work fine with L1. */ if (rtl_aspm_is_safe(tp)) rc = 0; else if (tp->mac_version >= RTL_GIGA_MAC_VER_46) - rc = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1_2); + rc = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1_1 | PCIE_LINK_STATE_L1_2); else rc = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1); tp->aspm_manageable = !rc; From patchwork Tue Feb 21 02:32:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai-Heng Feng X-Patchwork-Id: 13147263 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B208BC61DA3 for ; Tue, 21 Feb 2023 02:34:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232837AbjBUCeF (ORCPT ); Mon, 20 Feb 2023 21:34:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232496AbjBUCeD (ORCPT ); Mon, 20 Feb 2023 21:34:03 -0500 Received: from smtp-relay-canonical-0.canonical.com (smtp-relay-canonical-0.canonical.com [185.125.188.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AB1C23331; Mon, 20 Feb 2023 18:33:54 -0800 (PST) Received: from localhost.localdomain (unknown [10.101.196.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id 415913F2FE; Tue, 21 Feb 2023 02:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676946833; bh=pNqvuelCqk4rJCSN7tzVgxEDAb98YmVWBtwNCRfo4Z4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=uNf09x95cMrLTpP6XZ9WWExem5w6U2SFP+ssGemxKJC56nJp4jX1/3v6MzetkZnvk 3+cHlcEY/7RvIRriNSQfkUXhl8crqnniug3Dc/GYq5MCZeCdLet5PcJ8C3/TbJFJhR j025Ju5/GMJVAMp1PueccT85hphDpPnI2zvW3oDVebvfd8Ju3Hbnw7MHMh1qH0fHmw G6y8d8G0erIbVOzxjIoqGg1wsyXqGAdF34umXfBl1a2vCOoyGxRDoIZQ0M1nYW+1p8 ogMI7ZjnbBB/Cv3e0l1THz5H2f5vTdJ7rKWUSislo/YWUbpZyXQ+p+/2jRk6gza/I+ s6K39PsRoslRQ== From: Kai-Heng Feng To: hkallweit1@gmail.com, nic_swsd@realtek.com, bhelgaas@google.com Cc: koba.ko@canonical.com, acelan.kao@canonical.com, Kai-Heng Feng , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v8 4/6] r8169: Consider chip-specific ASPM can be enabled on more cases Date: Tue, 21 Feb 2023 10:32:35 +0800 Message-Id: <20230221023237.1905536-5-kai.heng.feng@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230221023237.1905536-1-kai.heng.feng@canonical.com> References: <20230221023237.1905536-1-kai.heng.feng@canonical.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org To really enable ASPM on r8169 NICs, both standard PCIe ASPM and chip-specific ASPM have to be enabled at the same time. Before enabling ASPM at chip side, make sure the following conditions are met: 1) Use pcie_aspm_support_enabled() to check if ASPM is disabled by kernel parameter. 2) Use pcie_aspm_capable() to see if the device is capable to perform PCIe ASPM. 3) Check the return value of pci_disable_link_state(). If it's -EPERM, it means BIOS doesn't grant ASPM control to OS, and device should use the ASPM setting as is Consider ASPM is manageable when those conditions are met. While at it, disable ASPM at chip-side for TX timeout reset, since pci_disable_link_state() doesn't have any effect when OS isn't granted with ASPM control. Signed-off-by: Kai-Heng Feng --- v8: - Enable chip-side ASPM only when PCIe ASPM is already available. - Wording. v7: - No change. v6: - Unconditionally enable chip-specific ASPM. v5: - New patch. drivers/net/ethernet/realtek/r8169_main.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index 1c949822661ae..e40498dd08d17 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -2675,8 +2675,11 @@ static void rtl_disable_exit_l1(struct rtl8169_private *tp) static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable) { - /* Don't enable ASPM in the chip if OS can't control ASPM */ - if (enable && tp->aspm_manageable) { + /* Skip if PCIe ASPM isn't possible */ + if (!tp->aspm_manageable) + return; + + if (enable) { RTL_W8(tp, Config5, RTL_R8(tp, Config5) | ASPM_en); RTL_W8(tp, Config2, RTL_R8(tp, Config2) | ClkReqEn); @@ -4545,8 +4548,13 @@ static void rtl_task(struct work_struct *work) /* ASPM compatibility issues are a typical reason for tx timeouts */ ret = pci_disable_link_state(tp->pci_dev, PCIE_LINK_STATE_L1 | PCIE_LINK_STATE_L0S); + + /* OS may not be granted to control PCIe ASPM, prevent the driver from using it */ + tp->aspm_manageable = 0; + if (!ret) netdev_warn_once(tp->dev, "ASPM disabled on Tx timeout\n"); + goto reset; } @@ -5227,13 +5235,19 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) * Chips from RTL8168h partially have issues with L1.1 and L1.2, but * seem to work fine with L1. */ - if (rtl_aspm_is_safe(tp)) + if (!pcie_aspm_support_enabled() || !pcie_aspm_capable(pdev)) + rc = -EINVAL; + else if (rtl_aspm_is_safe(tp)) rc = 0; else if (tp->mac_version >= RTL_GIGA_MAC_VER_46) rc = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1_1 | PCIE_LINK_STATE_L1_2); else rc = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1); - tp->aspm_manageable = !rc; + + /* -EPERM means BIOS doesn't grant OS ASPM control, ASPM should be use + * as is. Honor it. + */ + tp->aspm_manageable = (rc == -EPERM) ? 1 : !rc; tp->dash_type = rtl_check_dash(tp); From patchwork Tue Feb 21 02:32:36 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai-Heng Feng X-Patchwork-Id: 13147264 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A636C636D6 for ; Tue, 21 Feb 2023 02:34:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232827AbjBUCe0 (ORCPT ); Mon, 20 Feb 2023 21:34:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232353AbjBUCeZ (ORCPT ); Mon, 20 Feb 2023 21:34:25 -0500 Received: from smtp-relay-canonical-0.canonical.com (smtp-relay-canonical-0.canonical.com [185.125.188.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66D421A489; Mon, 20 Feb 2023 18:34:01 -0800 (PST) Received: from localhost.localdomain (unknown [10.101.196.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id D4B9C405FF; Tue, 21 Feb 2023 02:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676946837; bh=ezbPlxDXhaV/sDJAItoixMIy3dMW2xrI6AAH/J1Y45I=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=b7MKVP8UxhA1dKb/URCZruGgXPBO5jiC12PZyrFddz6R7S2I+E+Wrhw37bI85p0U8 8KvcuygFsxcxskatGpsB4N+xpDJXCNUTXsuPktYw+PEZO7p5C4jfX4XZfmgpE2z9tr +qE20xmlry42t5rBSeSb77l13LQPlzJfZg402117qD2LmQv/4ro7G5IBSzszBWUAF3 DyB5NYw3BR8YzxkZZBqrKj6+FUmya/vNB6QR93hwP/AQlPNtUhIlyGUIVSVfyPMNe3 qSU9PKMTRdeOe7UXtysXlZC7VKdE+ivAy856P8TnGMpHRQCbzCYcHFzZNkBKdzHc7j SxF/eXILjwLBA== From: Kai-Heng Feng To: hkallweit1@gmail.com, nic_swsd@realtek.com, bhelgaas@google.com Cc: koba.ko@canonical.com, acelan.kao@canonical.com, Kai-Heng Feng , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v8 5/6] r8169: Use mutex to guard config register locking Date: Tue, 21 Feb 2023 10:32:36 +0800 Message-Id: <20230221023237.1905536-6-kai.heng.feng@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230221023237.1905536-1-kai.heng.feng@canonical.com> References: <20230221023237.1905536-1-kai.heng.feng@canonical.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org Right now r8169 doesn't have parallel access to its config register, but the next patch makes the driver access config register at anytime. So add a mutex to protect the config register from any potential race. Signed-off-by: Kai-Heng Feng --- v8: - Swap the place when using the mutex. Protect when config register is unlocked. v7: - This is a new patch. drivers/net/ethernet/realtek/r8169_main.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index e40498dd08d17..897f90b48bba6 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -613,6 +613,8 @@ struct rtl8169_private { struct work_struct work; } wk; + struct mutex config_lock; + unsigned supports_gmii:1; unsigned aspm_manageable:1; dma_addr_t counters_phys_addr; @@ -662,10 +664,12 @@ static inline struct device *tp_to_dev(struct rtl8169_private *tp) static void rtl_lock_config_regs(struct rtl8169_private *tp) { RTL_W8(tp, Cfg9346, Cfg9346_Lock); + mutex_unlock(&tp->config_lock); } static void rtl_unlock_config_regs(struct rtl8169_private *tp) { + mutex_lock(&tp->config_lock); RTL_W8(tp, Cfg9346, Cfg9346_Unlock); } @@ -5217,6 +5221,8 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) return rc; } + mutex_init(&tp->config_lock); + tp->mmio_addr = pcim_iomap_table(pdev)[region]; xid = (RTL_R32(tp, TxConfig) >> 20) & 0xfcf; From patchwork Tue Feb 21 02:32:37 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai-Heng Feng X-Patchwork-Id: 13147265 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17B27C61DA3 for ; Tue, 21 Feb 2023 02:34:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232895AbjBUCej (ORCPT ); Mon, 20 Feb 2023 21:34:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232353AbjBUCej (ORCPT ); Mon, 20 Feb 2023 21:34:39 -0500 Received: from smtp-relay-canonical-0.canonical.com (smtp-relay-canonical-0.canonical.com [185.125.188.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43AC6233FD; Mon, 20 Feb 2023 18:34:08 -0800 (PST) Received: from localhost.localdomain (unknown [10.101.196.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id 412E640640; Tue, 21 Feb 2023 02:33:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676946842; bh=Y882fDTAJIgU0c6v4mvBEAwTf+dckq3a6RQpDpIIC1Y=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=GJIQpvkU8IWOBuM8p3T1pEqUyqO+e5VSEiLRv2+AHKjEmXQX0yoNBgSfUf+XkSBsV Dz2tWOgh6ZBYm/Jeu83h5NrEb970O8gEIOe/Adn+oCzi8LynCOQgHa8SzPGRMjkWXY 5GMLV+HWvvTrZsZ8XwtztlwcyYVLEA7Zuu6eKXrmoy4j9cjew+DQy6ETk4W/CDj7tv axRvqI0zLVLuwxHiwhGIu+K8FDT60ufINboN+HXNDeYda2Cz1nZcK7B2+GGcsOXbc2 uweYudGK/o1C5+xtJIZcepLHd7cf88b094SFglIfx4vf9UDAQ6VfE9azrIQOcm7lDk Rs5mLchIdYZ2A== From: Kai-Heng Feng To: hkallweit1@gmail.com, nic_swsd@realtek.com, bhelgaas@google.com Cc: koba.ko@canonical.com, acelan.kao@canonical.com, Kai-Heng Feng , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v8 6/6] r8169: Disable ASPM while doing NAPI poll Date: Tue, 21 Feb 2023 10:32:37 +0800 Message-Id: <20230221023237.1905536-7-kai.heng.feng@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230221023237.1905536-1-kai.heng.feng@canonical.com> References: <20230221023237.1905536-1-kai.heng.feng@canonical.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org NAPI poll of Realtek NICs don't seem to perform well ASPM is enabled. The vendor driver uses a mechanism called "dynamic ASPM" to toggle ASPM based on the packet number in given time period. Instead of implementing "dynamic ASPM", use a more straightforward way by disabling ASPM during NAPI poll, as a similar approach was implemented to solve slow performance on Realtek wireless NIC, see commit 24f5e38a13b5 ("rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE"). Since NAPI poll should be handled as fast as possible, also remove the delay in rtl_hw_aspm_clkreq_enable() which was added by commit 94235460f9ea ("r8169: Align ASPM/CLKREQ setting function with vendor driver"). Signed-off-by: Kai-Heng Feng --- v8: - New patch. drivers/net/ethernet/realtek/r8169_main.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index 897f90b48bba6..4d4a802346ae3 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -2711,8 +2711,6 @@ static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable) RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn); RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en); } - - udelay(10); } static void rtl_set_fifo_size(struct rtl8169_private *tp, u16 rx_stat, @@ -4577,6 +4575,12 @@ static int rtl8169_poll(struct napi_struct *napi, int budget) struct net_device *dev = tp->dev; int work_done; + if (tp->aspm_manageable) { + rtl_unlock_config_regs(tp); + rtl_hw_aspm_clkreq_enable(tp, false); + rtl_lock_config_regs(tp); + } + rtl_tx(dev, tp, budget); work_done = rtl_rx(dev, tp, budget); @@ -4584,6 +4588,12 @@ static int rtl8169_poll(struct napi_struct *napi, int budget) if (work_done < budget && napi_complete_done(napi, work_done)) rtl_irq_enable(tp); + if (tp->aspm_manageable) { + rtl_unlock_config_regs(tp); + rtl_hw_aspm_clkreq_enable(tp, true); + rtl_lock_config_regs(tp); + } + return work_done; }