Patchwork [v2,net-next,1/8] r8169: Remove firmware code

login
register
mail settings
Submitter hayeswang
Date April 2, 2013, 8:23 a.m.
Message ID <1364891022-3220-1-git-send-email-hayeswang@realtek.com>
Download mbox | patch
Permalink /patch/232922/
State Accepted
Delegated to: David Miller
Headers show

Comments

hayeswang - April 2, 2013, 8:23 a.m.
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(-)
David Miller - April 4, 2013, 9:47 p.m.
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
fran├žois romieu - April 4, 2013, 11:42 p.m.
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.
David Miller - April 7, 2013, 8:45 p.m.
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

Patch

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)