RE: [PATCH net v2] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

> Nits: > > - the tp->TxDescArray test provides the required synchronization: see > rtl8169_{open/close} and their pm_runtime_{get / put}. > > - ioaddr is not really needed : tp->mmio_addr appears only once and it does > not mess the 72..80 cols limit. > > - even if the device can only be

RE: [PATCH net v4] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

> Fine with me. > > Is there any chance for the set of chipset dependent registers that are safe > to > be read when in D3 state to be documented ? > I think except registers in PCI configuration, all other registers should be read in D0 state. --Please consider the environment before

RE: [PATCH net 1/3] r8169:fix nic sometimes doesn't work after changing the mac address.

> Instead of taking the device out of suspended mode to perform the required > action, the driver is moving to a model where 1) said action may be > scheduled to a later time - or result from past time work - and 2) rpm handler > must handle a lot of pm unrelated work. > >

RE: [PATCH net] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

> Chunhao Lin : > [...] > > I add checking driver's pm runtime status in rtl8169_get_stats64() to fix > > this issue. > > Would you consider taking the device out of suspended mode during > rtl8169_get_stats64 to prevent outdated stats ? > When in runtime suspend, it mean

RE: [PATCH net] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.

[...] > Can you clarify: > - actually this patch does not care about the link at all. So when there's > link no phy reset is needed either, right ? > - does "this" in "to do this" means that > 1. phy reset prevents phy from auto speed down > 2. avoiding phy reset prevents phy from auto

RE: [PATCH net 0/3] r8169:issues fix.

> I don't agree with changes #1 and #2. > > If you are going to go to a model where every single configuration operation > is recorded in software and performed at resume time, then really do it and > fix it in the whole driver. As currently coded you are leaving lots of known > bugs in the

RE: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

do.salv...@linaro.org>; Leo Duran <leo.du...@amd.com>; G > Gregory <graeme.greg...@linaro.org>; nic_swsd <nic_s...@realtek.com>; > Hau <h...@realtek.com> > Subject: Re: [PATCH] r8169: default to 64-bit DMA on systems without memory > below 4 GB > > > O

RE: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

[...] > Nit: you may directly use "struct device *d = >pci_dev->dev;" > I will do that on my next version patch. Thanks. --Please consider the environment before printing this e-mail.

RE: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

[...] > > @@ -1852,12 +1863,17 @@ static int rtl8169_set_wol(struct net_device > *dev, struct ethtool_wolinfo *wol) > > tp->features |= RTL_FEATURE_WOL; > > else > > tp->features &= ~RTL_FEATURE_WOL; > > - __rtl8169_set_wol(tp, wol->wolopts); > > + if

RE: [PATCH net-next] r8169: add module param for control of ASPM disable

> -Original Message- > From: Francois Romieu [mailto:rom...@fr.zoreil.com] > Sent: Friday, February 2, 2018 7:27 AM > To: Hau <h...@realtek.com> > Cc: netdev@vger.kernel.org; nic_swsd <nic_s...@realtek.com>; linux- > ker...@vger.kernel.org > Subject: Re: [

RE: r8169 take too long to complete driver initialization

> -Original Message- > From: Chris Chiu [mailto:c...@endlessm.com] > Sent: Friday, February 2, 2018 10:03 AM > To: Hau <h...@realtek.com> > Cc: nic_swsd <nic_s...@realtek.com>; netdev@vger.kernel.org; Linux > Kernel <linux-ker...@vger.kernel.o

RE: r8169 take too long to complete driver initialization

Hi Chris, Could you test following patch? DECLARE_RTL_COND(rtl_ocp_tx_cond) { void __iomem *ioaddr = tp->mmio_addr; - return RTL_R8(IBISR0) & 0x02; + return RTL_R8(IBISR0) & 0x20; } static void rtl8168ep_stop_cmac(struct rtl8169_private *tp) { void __iomem