diff mbox series

[1/2] r8169: Implement dynamic ASPM mechanism

Message ID 20210803152823.515849-1-kai.heng.feng@canonical.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series [1/2] r8169: Implement dynamic ASPM mechanism | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Guessed tree name to be net-next
netdev/subject_prefix warning Target tree name not specified in the subject
netdev/cc_maintainers success CCed 5 of 5 maintainers
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 74 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link

Commit Message

Kai-Heng Feng Aug. 3, 2021, 3:28 p.m. UTC
r8169 NICs on some platforms have abysmal speed when ASPM is enabled.
Same issue can be observed with older vendor drivers.

The issue is however solved by the latest vendor driver. There's a new
mechanism, which disables r8169's internal ASPM when the NIC has
substantial network traffic, and vice versa.

So implement the same mechanism here to resolve the issue.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
 drivers/net/ethernet/realtek/r8169_main.c | 36 +++++++++++++++++++++++
 1 file changed, 36 insertions(+)

Comments

Heiner Kallweit Aug. 3, 2021, 7:57 p.m. UTC | #1
On 03.08.2021 17:28, Kai-Heng Feng wrote:
> r8169 NICs on some platforms have abysmal speed when ASPM is enabled.
> Same issue can be observed with older vendor drivers.
> 
> The issue is however solved by the latest vendor driver. There's a new

Is there any errata document from Realtek recommending this workaround?
Any prove that it solves the issues in all cases of ASPM issues we've
seen so far?
Also your heuristics logic seems to be different from the one in r8168.
The vendor driver considers also rx packets.

In addition you use this logic also for chip versions not covered by
r8168, like RTL8125. Any info from Realtek regarding these chip versions?

> mechanism, which disables r8169's internal ASPM when the NIC has
> substantial network traffic, and vice versa.
> 
10 packets per second I wouldn't call substantial traffic.
I'm afraid we may open a can of worms and may be bothered
with bug reports and complaints again.

> So implement the same mechanism here to resolve the issue.
> 
For me this risk is too high to re-enable ASPM for a lot of chip
versions w/o any official errata and workaround information.
I propose you make this change downstream, and if there are no
user complaints after some months I may consider to have something
like that in the mainline driver.

> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>  drivers/net/ethernet/realtek/r8169_main.c | 36 +++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index c7af5bc3b8af..e257d3cd885e 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -624,6 +624,10 @@ struct rtl8169_private {
>  
>  	unsigned supports_gmii:1;
>  	unsigned aspm_manageable:1;
> +	unsigned aspm_enabled:1;
> +	struct timer_list aspm_timer;
> +	u32 aspm_packet_count;
> +
>  	dma_addr_t counters_phys_addr;
>  	struct rtl8169_counters *counters;
>  	struct rtl8169_tc_offsets tc_offset;
> @@ -2671,6 +2675,8 @@ static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable)
>  		RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>  	}
>  
> +	tp->aspm_enabled = enable;
> +
>  	udelay(10);
>  }
>  
> @@ -4408,6 +4414,7 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
>  
>  	dirty_tx = tp->dirty_tx;
>  
> +	tp->aspm_packet_count += tp->cur_tx - dirty_tx;
>  	while (READ_ONCE(tp->cur_tx) != dirty_tx) {
>  		unsigned int entry = dirty_tx % NUM_TX_DESC;
>  		u32 status;
> @@ -4552,6 +4559,8 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, int budget
>  		rtl8169_mark_to_asic(desc);
>  	}
>  
> +	tp->aspm_packet_count += count;
> +
>  	return count;
>  }
>  
> @@ -4659,8 +4668,31 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
>  	return 0;
>  }
>  
> +#define ASPM_PACKET_THRESHOLD 10
> +#define ASPM_TIMER_INTERVAL 1000
> +
> +static void rtl8169_aspm_timer(struct timer_list *timer)
> +{
> +	struct rtl8169_private *tp = from_timer(tp, timer, aspm_timer);
> +	bool enable;
> +
> +	enable = tp->aspm_packet_count <= ASPM_PACKET_THRESHOLD;
> +
> +	if (tp->aspm_enabled != enable) {
> +		rtl_unlock_config_regs(tp);
> +		rtl_hw_aspm_clkreq_enable(tp, enable);
> +		rtl_lock_config_regs(tp);

All this in interrupt context w/o locking?

> +	}
> +
> +	tp->aspm_packet_count = 0;
> +
> +	mod_timer(timer, jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
> +}
> +
>  static void rtl8169_down(struct rtl8169_private *tp)
>  {
> +	del_timer_sync(&tp->aspm_timer);
> +
>  	/* Clear all task flags */
>  	bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
>  
> @@ -4687,6 +4719,10 @@ static void rtl8169_up(struct rtl8169_private *tp)
>  	rtl_reset_work(tp);
>  
>  	phy_start(tp->phydev);
> +
> +	timer_setup(&tp->aspm_timer, rtl8169_aspm_timer, 0);
> +	mod_timer(&tp->aspm_timer,
> +		  jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
>  }
>  
>  static int rtl8169_close(struct net_device *dev)
>
Kai-Heng Feng Aug. 4, 2021, 4:05 a.m. UTC | #2
On Wed, Aug 4, 2021 at 3:57 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 03.08.2021 17:28, Kai-Heng Feng wrote:
> > r8169 NICs on some platforms have abysmal speed when ASPM is enabled.
> > Same issue can be observed with older vendor drivers.
> >
> > The issue is however solved by the latest vendor driver. There's a new
>
> Is there any errata document from Realtek recommending this workaround?
> Any prove that it solves the issues in all cases of ASPM issues we've
> seen so far?

Actually I don't know. Let me ask Realtek.

> Also your heuristics logic seems to be different from the one in r8168.
> The vendor driver considers also rx packets.

rx packets are accumulated in rtl_rx().

>
> In addition you use this logic also for chip versions not covered by
> r8168, like RTL8125. Any info from Realtek regarding these chip versions?

Right, maybe 8125 doesn't need dynamic ASPM. Let me ask them...

>
> > mechanism, which disables r8169's internal ASPM when the NIC has
> > substantial network traffic, and vice versa.
> >
> 10 packets per second I wouldn't call substantial traffic.

I'll change the wording in v2.

> I'm afraid we may open a can of worms and may be bothered
> with bug reports and complaints again.

Let's hope this time it works.

>
> > So implement the same mechanism here to resolve the issue.
> >
> For me this risk is too high to re-enable ASPM for a lot of chip
> versions w/o any official errata and workaround information.
> I propose you make this change downstream, and if there are no
> user complaints after some months I may consider to have something
> like that in the mainline driver.

Sure, let's see how it works in downstream kernel first.

>
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > ---
> >  drivers/net/ethernet/realtek/r8169_main.c | 36 +++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> > index c7af5bc3b8af..e257d3cd885e 100644
> > --- a/drivers/net/ethernet/realtek/r8169_main.c
> > +++ b/drivers/net/ethernet/realtek/r8169_main.c
> > @@ -624,6 +624,10 @@ struct rtl8169_private {
> >
> >       unsigned supports_gmii:1;
> >       unsigned aspm_manageable:1;
> > +     unsigned aspm_enabled:1;
> > +     struct timer_list aspm_timer;
> > +     u32 aspm_packet_count;
> > +
> >       dma_addr_t counters_phys_addr;
> >       struct rtl8169_counters *counters;
> >       struct rtl8169_tc_offsets tc_offset;
> > @@ -2671,6 +2675,8 @@ static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable)
> >               RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
> >       }
> >
> > +     tp->aspm_enabled = enable;
> > +
> >       udelay(10);
> >  }
> >
> > @@ -4408,6 +4414,7 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
> >
> >       dirty_tx = tp->dirty_tx;
> >
> > +     tp->aspm_packet_count += tp->cur_tx - dirty_tx;
> >       while (READ_ONCE(tp->cur_tx) != dirty_tx) {
> >               unsigned int entry = dirty_tx % NUM_TX_DESC;
> >               u32 status;
> > @@ -4552,6 +4559,8 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, int budget
> >               rtl8169_mark_to_asic(desc);
> >       }
> >
> > +     tp->aspm_packet_count += count;
> > +
> >       return count;
> >  }
> >
> > @@ -4659,8 +4668,31 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
> >       return 0;
> >  }
> >
> > +#define ASPM_PACKET_THRESHOLD 10
> > +#define ASPM_TIMER_INTERVAL 1000
> > +
> > +static void rtl8169_aspm_timer(struct timer_list *timer)
> > +{
> > +     struct rtl8169_private *tp = from_timer(tp, timer, aspm_timer);
> > +     bool enable;
> > +
> > +     enable = tp->aspm_packet_count <= ASPM_PACKET_THRESHOLD;
> > +
> > +     if (tp->aspm_enabled != enable) {
> > +             rtl_unlock_config_regs(tp);
> > +             rtl_hw_aspm_clkreq_enable(tp, enable);
> > +             rtl_lock_config_regs(tp);
>
> All this in interrupt context w/o locking?

Sorry, I forgot the timer is in interrupt context.
Or is it safe to use workqueue for rtl_{,un}lock_config_regs() and
rtl_hw_aspm_clkreq_enable()?

Kai-Heng

>
> > +     }
> > +
> > +     tp->aspm_packet_count = 0;
> > +
> > +     mod_timer(timer, jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
> > +}
> > +
> >  static void rtl8169_down(struct rtl8169_private *tp)
> >  {
> > +     del_timer_sync(&tp->aspm_timer);
> > +
> >       /* Clear all task flags */
> >       bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
> >
> > @@ -4687,6 +4719,10 @@ static void rtl8169_up(struct rtl8169_private *tp)
> >       rtl_reset_work(tp);
> >
> >       phy_start(tp->phydev);
> > +
> > +     timer_setup(&tp->aspm_timer, rtl8169_aspm_timer, 0);
> > +     mod_timer(&tp->aspm_timer,
> > +               jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
> >  }
> >
> >  static int rtl8169_close(struct net_device *dev)
> >
>
Heiner Kallweit Aug. 6, 2021, 6:47 p.m. UTC | #3
On 03.08.2021 17:28, Kai-Heng Feng wrote:
> r8169 NICs on some platforms have abysmal speed when ASPM is enabled.
> Same issue can be observed with older vendor drivers.
> 
> The issue is however solved by the latest vendor driver. There's a new
> mechanism, which disables r8169's internal ASPM when the NIC has
> substantial network traffic, and vice versa.
> 
> So implement the same mechanism here to resolve the issue.
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>  drivers/net/ethernet/realtek/r8169_main.c | 36 +++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index c7af5bc3b8af..e257d3cd885e 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -624,6 +624,10 @@ struct rtl8169_private {
>  
>  	unsigned supports_gmii:1;
>  	unsigned aspm_manageable:1;
> +	unsigned aspm_enabled:1;
> +	struct timer_list aspm_timer;
> +	u32 aspm_packet_count;
> +
>  	dma_addr_t counters_phys_addr;
>  	struct rtl8169_counters *counters;
>  	struct rtl8169_tc_offsets tc_offset;
> @@ -2671,6 +2675,8 @@ static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable)
>  		RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
>  	}
>  
> +	tp->aspm_enabled = enable;
> +
>  	udelay(10);
>  }
>  
> @@ -4408,6 +4414,7 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
>  
>  	dirty_tx = tp->dirty_tx;
>  
> +	tp->aspm_packet_count += tp->cur_tx - dirty_tx;
>  	while (READ_ONCE(tp->cur_tx) != dirty_tx) {
>  		unsigned int entry = dirty_tx % NUM_TX_DESC;
>  		u32 status;
> @@ -4552,6 +4559,8 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, int budget
>  		rtl8169_mark_to_asic(desc);
>  	}
>  
> +	tp->aspm_packet_count += count;
> +
>  	return count;
>  }
>  
> @@ -4659,8 +4668,31 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
>  	return 0;
>  }
>  
> +#define ASPM_PACKET_THRESHOLD 10
> +#define ASPM_TIMER_INTERVAL 1000
> +
> +static void rtl8169_aspm_timer(struct timer_list *timer)
> +{
> +	struct rtl8169_private *tp = from_timer(tp, timer, aspm_timer);
> +	bool enable;
> +
> +	enable = tp->aspm_packet_count <= ASPM_PACKET_THRESHOLD;
> +
> +	if (tp->aspm_enabled != enable) {
> +		rtl_unlock_config_regs(tp);
> +		rtl_hw_aspm_clkreq_enable(tp, enable);
> +		rtl_lock_config_regs(tp);
> +	}
> +
> +	tp->aspm_packet_count = 0;
> +
> +	mod_timer(timer, jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
> +}
> +
>  static void rtl8169_down(struct rtl8169_private *tp)
>  {
> +	del_timer_sync(&tp->aspm_timer);
> +
>  	/* Clear all task flags */
>  	bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
>  
> @@ -4687,6 +4719,10 @@ static void rtl8169_up(struct rtl8169_private *tp)
>  	rtl_reset_work(tp);
>  
>  	phy_start(tp->phydev);
> +
> +	timer_setup(&tp->aspm_timer, rtl8169_aspm_timer, 0);
> +	mod_timer(&tp->aspm_timer,
> +		  jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
>  }
>  
>  static int rtl8169_close(struct net_device *dev)
> 

I have one more question / concern regarding this workaround:
If bigger traffic starts and results in a congestion (let's call it like that
because we don't know in detail what happens in the chip), then it may take
up to a second until ASPM gets disabled and traffic gets back to normal.
This second is good enough to prevent that the timeout watchdog fires.
However in this second supposedly traffic is very limited, if possible at all.
Means if we have a network traffic pattern with alternating quiet and busy
periods then we may see a significant impact on performance.
Is this something that you tested?
Kai-Heng Feng Aug. 9, 2021, 11:18 a.m. UTC | #4
On Sat, Aug 7, 2021 at 2:47 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 03.08.2021 17:28, Kai-Heng Feng wrote:
> > r8169 NICs on some platforms have abysmal speed when ASPM is enabled.
> > Same issue can be observed with older vendor drivers.
> >
> > The issue is however solved by the latest vendor driver. There's a new
> > mechanism, which disables r8169's internal ASPM when the NIC has
> > substantial network traffic, and vice versa.
> >
> > So implement the same mechanism here to resolve the issue.
> >
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > ---
> >  drivers/net/ethernet/realtek/r8169_main.c | 36 +++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> > index c7af5bc3b8af..e257d3cd885e 100644
> > --- a/drivers/net/ethernet/realtek/r8169_main.c
> > +++ b/drivers/net/ethernet/realtek/r8169_main.c
> > @@ -624,6 +624,10 @@ struct rtl8169_private {
> >
> >       unsigned supports_gmii:1;
> >       unsigned aspm_manageable:1;
> > +     unsigned aspm_enabled:1;
> > +     struct timer_list aspm_timer;
> > +     u32 aspm_packet_count;
> > +
> >       dma_addr_t counters_phys_addr;
> >       struct rtl8169_counters *counters;
> >       struct rtl8169_tc_offsets tc_offset;
> > @@ -2671,6 +2675,8 @@ static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable)
> >               RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
> >       }
> >
> > +     tp->aspm_enabled = enable;
> > +
> >       udelay(10);
> >  }
> >
> > @@ -4408,6 +4414,7 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
> >
> >       dirty_tx = tp->dirty_tx;
> >
> > +     tp->aspm_packet_count += tp->cur_tx - dirty_tx;
> >       while (READ_ONCE(tp->cur_tx) != dirty_tx) {
> >               unsigned int entry = dirty_tx % NUM_TX_DESC;
> >               u32 status;
> > @@ -4552,6 +4559,8 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, int budget
> >               rtl8169_mark_to_asic(desc);
> >       }
> >
> > +     tp->aspm_packet_count += count;
> > +
> >       return count;
> >  }
> >
> > @@ -4659,8 +4668,31 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
> >       return 0;
> >  }
> >
> > +#define ASPM_PACKET_THRESHOLD 10
> > +#define ASPM_TIMER_INTERVAL 1000
> > +
> > +static void rtl8169_aspm_timer(struct timer_list *timer)
> > +{
> > +     struct rtl8169_private *tp = from_timer(tp, timer, aspm_timer);
> > +     bool enable;
> > +
> > +     enable = tp->aspm_packet_count <= ASPM_PACKET_THRESHOLD;
> > +
> > +     if (tp->aspm_enabled != enable) {
> > +             rtl_unlock_config_regs(tp);
> > +             rtl_hw_aspm_clkreq_enable(tp, enable);
> > +             rtl_lock_config_regs(tp);
> > +     }
> > +
> > +     tp->aspm_packet_count = 0;
> > +
> > +     mod_timer(timer, jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
> > +}
> > +
> >  static void rtl8169_down(struct rtl8169_private *tp)
> >  {
> > +     del_timer_sync(&tp->aspm_timer);
> > +
> >       /* Clear all task flags */
> >       bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
> >
> > @@ -4687,6 +4719,10 @@ static void rtl8169_up(struct rtl8169_private *tp)
> >       rtl_reset_work(tp);
> >
> >       phy_start(tp->phydev);
> > +
> > +     timer_setup(&tp->aspm_timer, rtl8169_aspm_timer, 0);
> > +     mod_timer(&tp->aspm_timer,
> > +               jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
> >  }
> >
> >  static int rtl8169_close(struct net_device *dev)
> >
>
> I have one more question / concern regarding this workaround:
> If bigger traffic starts and results in a congestion (let's call it like that
> because we don't know in detail what happens in the chip), then it may take
> up to a second until ASPM gets disabled and traffic gets back to normal.
> This second is good enough to prevent that the timeout watchdog fires.
> However in this second supposedly traffic is very limited, if possible at all.
> Means if we have a network traffic pattern with alternating quiet and busy
> periods then we may see a significant impact on performance.
> Is this something that you tested?

No, we didn't test this scenario.
Realtek told us that dynamic ASPM is also used by Windows driver, but
I don't know the interval used by Windows driver.
For now I think it's better to stick with vendor defined value.

Kai-Heng
diff mbox series

Patch

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index c7af5bc3b8af..e257d3cd885e 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -624,6 +624,10 @@  struct rtl8169_private {
 
 	unsigned supports_gmii:1;
 	unsigned aspm_manageable:1;
+	unsigned aspm_enabled:1;
+	struct timer_list aspm_timer;
+	u32 aspm_packet_count;
+
 	dma_addr_t counters_phys_addr;
 	struct rtl8169_counters *counters;
 	struct rtl8169_tc_offsets tc_offset;
@@ -2671,6 +2675,8 @@  static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable)
 		RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
 	}
 
+	tp->aspm_enabled = enable;
+
 	udelay(10);
 }
 
@@ -4408,6 +4414,7 @@  static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
 
 	dirty_tx = tp->dirty_tx;
 
+	tp->aspm_packet_count += tp->cur_tx - dirty_tx;
 	while (READ_ONCE(tp->cur_tx) != dirty_tx) {
 		unsigned int entry = dirty_tx % NUM_TX_DESC;
 		u32 status;
@@ -4552,6 +4559,8 @@  static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, int budget
 		rtl8169_mark_to_asic(desc);
 	}
 
+	tp->aspm_packet_count += count;
+
 	return count;
 }
 
@@ -4659,8 +4668,31 @@  static int r8169_phy_connect(struct rtl8169_private *tp)
 	return 0;
 }
 
+#define ASPM_PACKET_THRESHOLD 10
+#define ASPM_TIMER_INTERVAL 1000
+
+static void rtl8169_aspm_timer(struct timer_list *timer)
+{
+	struct rtl8169_private *tp = from_timer(tp, timer, aspm_timer);
+	bool enable;
+
+	enable = tp->aspm_packet_count <= ASPM_PACKET_THRESHOLD;
+
+	if (tp->aspm_enabled != enable) {
+		rtl_unlock_config_regs(tp);
+		rtl_hw_aspm_clkreq_enable(tp, enable);
+		rtl_lock_config_regs(tp);
+	}
+
+	tp->aspm_packet_count = 0;
+
+	mod_timer(timer, jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
+}
+
 static void rtl8169_down(struct rtl8169_private *tp)
 {
+	del_timer_sync(&tp->aspm_timer);
+
 	/* Clear all task flags */
 	bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
 
@@ -4687,6 +4719,10 @@  static void rtl8169_up(struct rtl8169_private *tp)
 	rtl_reset_work(tp);
 
 	phy_start(tp->phydev);
+
+	timer_setup(&tp->aspm_timer, rtl8169_aspm_timer, 0);
+	mod_timer(&tp->aspm_timer,
+		  jiffies + msecs_to_jiffies(ASPM_TIMER_INTERVAL));
 }
 
 static int rtl8169_close(struct net_device *dev)