List of patches that Jo-Philipp groveled out of git.

Signed-off-by: Philip Prindeville <phil...@redfish-solutions.com>
Index: target/linux/x86/patches-3.2/902-8139cp_config_rx_mode.patch
===================================================================
--- target/linux/x86/patches-3.2/902-8139cp_config_rx_mode.patch        
(revision 0)
+++ target/linux/x86/patches-3.2/902-8139cp_config_rx_mode.patch        
(revision 0)
@@ -0,0 +1,50 @@
+From f872b237c1750221932e715da2552225afe4a95c Mon Sep 17 00:00:00 2001
+From: Jason Wang <jasow...@redhat.com>
+Date: Fri, 30 Dec 2011 23:44:42 +0000
+Subject: [PATCH] 8139cp: properly config rx mode after resuming
+
+Rx mode should be reset after resming, so unconditionally updating rx
+mode rather than conditionally updating based on the value we
+remembered, otherwise unexpected value may be used by the nic after
+resuming.
+
+btw. I find and test this when debugging guest hibernation in qemu, as
+I did not have a 8139cp card in hand, this patch is untested in a
+physical 8139cp card, plase review it carefully.
+
+Signed-off-by: Jason Wang <jasow...@redhat.com>
+Signed-off-by: David S. Miller <da...@davemloft.net>
+---
+ drivers/net/ethernet/realtek/8139cp.c |    9 +++------
+ 1 files changed, 3 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/net/ethernet/realtek/8139cp.c 
b/drivers/net/ethernet/realtek/8139cp.c
+index 886e6be..cc6b391 100644
+--- a/drivers/net/ethernet/realtek/8139cp.c
++++ b/drivers/net/ethernet/realtek/8139cp.c
+@@ -859,7 +859,6 @@ static void __cp_set_rx_mode (struct net_device *dev)
+       struct cp_private *cp = netdev_priv(dev);
+       u32 mc_filter[2];       /* Multicast hash filter */
+       int rx_mode;
+-      u32 tmp;
+ 
+       /* Note: do not reorder, GCC is clever about common statements. */
+       if (dev->flags & IFF_PROMISC) {
+@@ -886,11 +885,9 @@ static void __cp_set_rx_mode (struct net_device *dev)
+       }
+ 
+       /* We can safely update without stopping the chip. */
+-      tmp = cp_rx_config | rx_mode;
+-      if (cp->rx_config != tmp) {
+-              cpw32_f (RxConfig, tmp);
+-              cp->rx_config = tmp;
+-      }
++      cp->rx_config = cp_rx_config | rx_mode;
++      cpw32_f(RxConfig, cp->rx_config);
++
+       cpw32_f (MAR0 + 0, mc_filter[0]);
+       cpw32_f (MAR0 + 4, mc_filter[1]);
+ }
+-- 
+1.7.6.5
+
Index: target/linux/x86/patches-3.2/901-8139cp_eeprom_delay.patch
===================================================================
--- target/linux/x86/patches-3.2/901-8139cp_eeprom_delay.patch  (revision 0)
+++ target/linux/x86/patches-3.2/901-8139cp_eeprom_delay.patch  (revision 0)
@@ -0,0 +1,44 @@
+From 7d03f5a48e4d90854275b06433626243b3b3db17 Mon Sep 17 00:00:00 2001
+From: Jason Wang <jasow...@redhat.com>
+Date: Fri, 30 Dec 2011 23:44:33 +0000
+Subject: [PATCH] 8139cp/8139too: do not read into reserved registers
+
+delay_eeprom() use long read for Cfg9346 register(offset 0x50) which may read
+into the area of reserved register(offset 0x53). Use byte read instead.
+
+Signed-off-by: Jason Wang <jasow...@redhat.com>
+Signed-off-by: David S. Miller <da...@davemloft.net>
+---
+ drivers/net/ethernet/realtek/8139cp.c  |    2 +-
+ drivers/net/ethernet/realtek/8139too.c |    2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/realtek/8139cp.c 
b/drivers/net/ethernet/realtek/8139cp.c
+index 87cff10..886e6be 100644
+--- a/drivers/net/ethernet/realtek/8139cp.c
++++ b/drivers/net/ethernet/realtek/8139cp.c
+@@ -1589,7 +1589,7 @@ static int cp_set_mac_address(struct net_device *dev, 
void *p)
+    No extra delay is needed with 33Mhz PCI, but 66Mhz may change this.
+  */
+ 
+-#define eeprom_delay()        readl(ee_addr)
++#define eeprom_delay()        readb(ee_addr)
+ 
+ /* The EEPROM commands include the alway-set leading bit. */
+ #define EE_EXTEND_CMD (4)
+diff --git a/drivers/net/ethernet/realtek/8139too.c 
b/drivers/net/ethernet/realtek/8139too.c
+index d9c7227..a8779be 100644
+--- a/drivers/net/ethernet/realtek/8139too.c
++++ b/drivers/net/ethernet/realtek/8139too.c
+@@ -1122,7 +1122,7 @@ static void __devexit rtl8139_remove_one (struct pci_dev 
*pdev)
+    No extra delay is needed with 33Mhz PCI, but 66Mhz may change this.
+  */
+ 
+-#define eeprom_delay()        (void)RTL_R32(Cfg9346)
++#define eeprom_delay()        (void)RTL_R8(Cfg9346)
+ 
+ /* The EEPROM commands include the alway-set leading bit. */
+ #define EE_WRITE_CMD  (5)
+-- 
+1.7.6.5
+
Index: target/linux/x86/patches-3.2/900-8139cp_napi_gro_flush.patch
===================================================================
--- target/linux/x86/patches-3.2/900-8139cp_napi_gro_flush.patch        
(revision 0)
+++ target/linux/x86/patches-3.2/900-8139cp_napi_gro_flush.patch        
(revision 0)
@@ -0,0 +1,30 @@
+From b189e810619a676e6b931a942a3e8387f3d39c21 Mon Sep 17 00:00:00 2001
+From: =?utf8?q?fran=C3=A7ois=20romieu?= <rom...@fr.zoreil.com>
+Date: Sun, 8 Jan 2012 13:41:33 +0000
+Subject: [PATCH] 8139cp: fix missing napi_gro_flush.
+
+The driver uses __napi_complete and napi_gro_receive. Without it, the
+driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete.
+
+Signed-off-by: Francois Romieu <rom...@fr.zoreil.com>
+Tested-by: Marin Glibic <zhil...@gmail.com>
+Signed-off-by: David S. Miller <da...@davemloft.net>
+---
+ drivers/net/ethernet/realtek/8139cp.c |    1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+diff --git a/drivers/net/ethernet/realtek/8139cp.c 
b/drivers/net/ethernet/realtek/8139cp.c
+index cc6b391..abc7907 100644
+--- a/drivers/net/ethernet/realtek/8139cp.c
++++ b/drivers/net/ethernet/realtek/8139cp.c
+@@ -563,6 +563,7 @@ rx_next:
+               if (cpr16(IntrStatus) & cp_rx_intr_mask)
+                       goto rx_status_loop;
+ 
++              napi_gro_flush(napi);
+               spin_lock_irqsave(&cp->lock, flags);
+               __napi_complete(napi);
+               cpw16_f(IntrMask, cp_intr_mask);
+-- 
+1.7.6.5
+
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to