[...]
> > @@ -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 (pm_runtime_act
[...]
> Nit: you may directly use "struct device *d = &tp->pci_dev->dev;"
>
I will do that on my next version patch.
Thanks.
--Please consider the environment before printing this e-mail.
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 *io
> 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
> -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
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
> -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
> -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
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
> 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 on
> 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.
>
> rtl8169_ethtool_ops.{ge
> 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 au
> 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 pri
[...]
> 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 speed
> 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 drive
> -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
> -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
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 exce
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?
19 matches
Mail list logo
