>
> Realtek provided updated versions of RTL8125B rev.a and rev.b firmware.
>
> Signed-off-by: Heiner Kallweit
Signed-off-by: Chunhao Lin
> ---
> WHENCE| 4 ++--
> rtl_nic/rtl8125b-1.fw | Bin 9952 -> 10128 bytes rtl_nic/rtl8125b-2.fw | Bin
> 3264 -> 3328 bytes
> 3 files c
gt; >> Firmware file was provided by Realtek and they asked me to submit it.
> >
> > Can we get a Signed-off-by from someone at Realtek then?
> >
> Hi Hau,
>
> can you reply and add your Signed-off-by?
> I saw that all the RTL8168 firmware was submitted by Hayes Wang.
> -Original Message-
> From: Francois Romieu [mailto:rom...@fr.zoreil.com]
> Sent: Friday, February 2, 2018 7:27 AM
> To: Hau
> Cc: netdev@vger.kernel.org; nic_swsd ; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH net-next] r8169: add module param for cont
> -Original Message-
> From: Chris Chiu [mailto:c...@endlessm.com]
> Sent: Friday, February 2, 2018 10:03 AM
> To: Hau
> Cc: nic_swsd ; netdev@vger.kernel.org; Linux
> Kernel ; Linux Upstreaming Team
>
> Subject: Re: r8169 take too long to complete driver initial
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
[...]
> 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.
[...]
> > @@ -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
> -Original Message-
> From: Francois Romieu [mailto:rom...@fr.zoreil.com]
> Sent: Thursday, May 12, 2016 10:09 PM
> To: Ard Biesheuvel
> Cc: David Miller ; netdev@vger.kernel.org; Ricardo
> Salveti ; Leo Duran ; G
> Gregory ; nic_swsd ;
> Hau
> Subject: Re: [
[...]
> 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
> 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
> 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
> 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
> 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
14 matches
Mail list logo