Message ID | 1364891022-3220-1-git-send-email-hayeswang@realtek.com |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
Francois what is the status of this patch set? I see there is still some discussion about dependencies between patch #5 and #6, is that resolved? If so, should I just apply this series as-is? Thanks! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller <davem@davemloft.net> : [...] > I see there is still some discussion about dependencies between > patch #5 and #6, is that resolved? Yes. > If so, should I just apply this series as-is ? Yes. - the series is imho -stable unfriendly: whoever wants to figure what should be fed into a -stable branch will have a hard time. :o/ - the driver could had been more careful about firmware version/magic checks and firmware opcodes recycling. It's a bit late. It won't necessarily hurt. - there is a whole release cycle ahead to find problems - if any - due to the hw_start flow change. It seems sane. - the relative amount of binary like cruft is going down. I am not overflowed with enthusiasm but the gain should exceed the pain.
From: Francois Romieu <romieu@fr.zoreil.com> Date: Fri, 5 Apr 2013 01:42:29 +0200 > David Miller <davem@davemloft.net> : > [...] >> If so, should I just apply this series as-is ? > > Yes. > > - the series is imho -stable unfriendly: whoever wants to figure what > should be fed into a -stable branch will have a hard time. :o/ > - the driver could had been more careful about firmware version/magic > checks and firmware opcodes recycling. It's a bit late. It won't > necessarily hurt. > - there is a whole release cycle ahead to find problems - if any - due > to the hw_start flow change. It seems sane. > - the relative amount of binary like cruft is going down. > > I am not overflowed with enthusiasm but the gain should exceed the pain. All applied to net-next, thanks! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 28fb50a..d36aa76 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -3368,32 +3368,6 @@ static void rtl8411_hw_phy_config(struct rtl8169_private *tp) static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp) { - static const u16 mac_ocp_patch[] = { - 0xe008, 0xe01b, 0xe01d, 0xe01f, - 0xe021, 0xe023, 0xe025, 0xe027, - 0x49d2, 0xf10d, 0x766c, 0x49e2, - 0xf00a, 0x1ec0, 0x8ee1, 0xc60a, - - 0x77c0, 0x4870, 0x9fc0, 0x1ea0, - 0xc707, 0x8ee1, 0x9d6c, 0xc603, - 0xbe00, 0xb416, 0x0076, 0xe86c, - 0xc602, 0xbe00, 0x0000, 0xc602, - - 0xbe00, 0x0000, 0xc602, 0xbe00, - 0x0000, 0xc602, 0xbe00, 0x0000, - 0xc602, 0xbe00, 0x0000, 0xc602, - 0xbe00, 0x0000, 0xc602, 0xbe00, - - 0x0000, 0x0000, 0x0000, 0x0000 - }; - u32 i; - - /* Patch code for GPHY reset */ - for (i = 0; i < ARRAY_SIZE(mac_ocp_patch); i++) - r8168_mac_ocp_write(tp, 0xf800 + 2*i, mac_ocp_patch[i]); - r8168_mac_ocp_write(tp, 0xfc26, 0x8000); - r8168_mac_ocp_write(tp, 0xfc28, 0x0075); - rtl_apply_firmware(tp); if (r8168_phy_ocp_read(tp, 0xa460) & 0x0100)
Some codes are belong to binary codes and should be removed. Signed-off-by: Hayes Wang <hayeswang@realtek.com> --- drivers/net/ethernet/realtek/r8169.c | 26 -------------------------- 1 file changed, 26 deletions(-)