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: net...@vger.kernel.org; nic_swsd <nic_s...@realtek.com>; linux- > ker...@vger.kernel.org > Subject: Re: [

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 > Cc: net...@vger.kernel.org; nic_swsd ; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH net-next] r8169: add module param for cont

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>; net...@vger.kernel.org; Linux > Kernel <linux-kernel@vger.kernel.o

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 > Cc: nic_swsd ; net...@vger.kernel.org; Linux > Kernel ; Linux Upstreaming Team > > Subject: Re: r8169 take too long to complete driver initial

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

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

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.

[...] > 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 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] 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] 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 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 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 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 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 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 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 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] 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: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 there is no traffic

RE: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy parameter

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Friday, January 09, 2015 12:09 PM > To: david.lai...@aculab.com > Cc: Hau; net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org > Subject: Re: [PATCH net-next 07/11] r8169:update

RE: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy parameter

-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Friday, January 09, 2015 12:09 PM To: david.lai...@aculab.com Cc: Hau; net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy

RE: [PATCH net-next 0/9] r8169:update hardware ephy parameter

> From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, December 10, 2014 7:36 AM > To: Hau > Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org > Subject: Re: [PATCH net-next 0/9] r8169:update hardware ephy parameter > > From: Chunhao Lin > D

RE: [PATCH net-next 0/9] r8169:update hardware ephy parameter

From: David Miller [mailto:da...@davemloft.net] Sent: Wednesday, December 10, 2014 7:36 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 0/9] r8169:update hardware ephy parameter From: Chunhao Lin h...@realtek.com Date: Wed, 10 Dec

RE: [PATCH v2 net-next] r8169:add support for RTL8168EP

> -Original Message- > From: Francois Romieu [mailto:rom...@fr.zoreil.com] > Sent: Tuesday, October 07, 2014 6:13 AM > To: Hau > Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2 net-next] r8169:add support for

RE: [PATCH v2 net-next] r8169:add support for RTL8168EP

> -Original Message- > From: Francois Romieu [mailto:rom...@fr.zoreil.com] > Sent: Saturday, October 04, 2014 4:33 AM > To: Hau > Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2 net-next] r8169:add support for RTL8168EP

RE: [PATCH v2 net-next] r8169:add support for RTL8168EP

-Original Message- From: Francois Romieu [mailto:rom...@fr.zoreil.com] Sent: Tuesday, October 07, 2014 6:13 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 net-next] r8169:add support for RTL8168EP Hau h...@realtek.com

RE: [PATCH v2 net-next] r8169:add support for RTL8168EP

-Original Message- From: Francois Romieu [mailto:rom...@fr.zoreil.com] Sent: Saturday, October 04, 2014 4:33 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 net-next] r8169:add support for RTL8168EP Chun-Hao Lin h

RE: [PATCH v2 net-next 01/10] r8169:change uppercase numbertolowercase nubmer

I will do that next time. Thanks. -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Thursday, October 02, 2014 3:35 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 net-next 01/10] r8169:change uppercase number

RE: [PATCH v2 net-next 01/10] r8169:change uppercase numbertolowercase nubmer

I will do that next time. Thanks. -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Thursday, October 02, 2014 3:35 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 net-next 01/10] r8169:change uppercase number

RE: [PATCH net-next] r8169:add support for RTL8168EP

I will spilt this patch and submit again. Thanks, Hau -Original Message- From: Francois Romieu [mailto:rom...@fr.zoreil.com] Sent: Sunday, September 28, 2014 4:39 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] r8169:add

RE: [PATCH net-next] r8169:add support for RTL8168EP

I will spilt this patch and submit again. Thanks, Hau -Original Message- From: Francois Romieu [mailto:rom...@fr.zoreil.com] Sent: Sunday, September 28, 2014 4:39 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] r8169:add

Memory maps

Dear freinds: I have following questions about memory maps. I appreciate any suggestion. Q. (1)When a process is running, how can I get the range of data, stack, and code segments, say the stack segment is from address 0x. to 0x. so do data segments and code segments?

Memory maps

Dear freinds: I have following questions about memory maps. I appreciate any suggestion. Q. (1)When a process is running, how can I get the range of data, stack, and code segments, say the stack segment is from address 0x. to 0x. so do data segments and code segments?

code region

Dear friends: I have a question about memory protection. I appreciate any suggestion. Thank you so much. Given a virtual address, how can we know whether this address contains an executable code? If there is a method that can be used to answer the above question, is there any

code region

Dear friends: I have a question about memory protection. I appreciate any suggestion. Thank you so much. Given a virtual address, how can we know whether this address contains an executable code? If there is a method that can be used to answer the above question, is there any