[rft/update] r8169 changes in 2.6.x

An update of the r8169 driver is available for the 2.6.11-rc4 kernel.

Noticable changes:
- better handling of PHY as found on Acer Aspire 1524WLMi (Richard Dawe);
- fix a bug triggered when the device is brought down then up again;
- avoid a few lost/screaming interrupts;
- closed a race when a change of mtu is issued during network activity;
- fix VLAN on big-endian hosts (is someone using it apart from me ?);
- merge relevant changes from Realtek's 2.2 driver.

If it worked for you before, you should not notice anything.

Patch against 2.6.10-rc4:
- http://www.fr.zoreil.com/~romieu/misc/20050222-2.6.11-rc4-r8169.c-test.patch

Patch-script directory:
- http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc4/r8169/

Patch-script tarball:
- http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc4/r8169-blob.tar.bz2

The 2.4.x backport will be updated later this week.

As usual, success/regression reports will be welcome.

Thank you for your attention.

--
Ueimor

Francois Romieu [off-list ref] wrote:

Patch against 2.6.10-rc4:
- http://www.fr.zoreil.com/~romieu/misc/20050222-2.6.11-rc4-r8169.c-test.patch

There are already a bunch of r8169 patches in Jeff's tree.  The combination
isn't pretty:


patching file drivers/net/r8169.c
Hunk #1 FAILED at 41.
Hunk #2 FAILED at 69.
Hunk #3 FAILED at 79.
Hunk #4 succeeded at 114 (offset 7 lines).
Hunk #5 FAILED at 161.
Hunk #6 FAILED at 175.
Hunk #7 FAILED at 224.
Hunk #8 succeeded at 231 (offset 3 lines).
Hunk #9 succeeded at 248 (offset 7 lines).
Hunk #10 succeeded at 268 (offset 3 lines).
Hunk #11 succeeded at 294 (offset 7 lines).
Hunk #12 succeeded at 300 (offset 3 lines).
Hunk #13 succeeded at 391 (offset 7 lines).
Hunk #14 FAILED at 424.
Hunk #15 succeeded at 468 (offset 3 lines).
Hunk #16 succeeded at 487 (offset 7 lines).
Hunk #17 succeeded at 500 with fuzz 1 (offset 10 lines).
Hunk #18 FAILED at 732.
Hunk #19 FAILED at 767.
Hunk #20 FAILED at 1036.
Hunk #21 succeeded at 1053 with fuzz 2 (offset 19 lines).
Hunk #22 FAILED at 1093.
Hunk #23 FAILED at 1128.
Hunk #24 FAILED at 1140.
Hunk #25 succeeded at 1178 (offset 10 lines).
Hunk #26 succeeded at 1198 with fuzz 1 (offset 19 lines).
Hunk #27 succeeded at 1213 (offset 10 lines).
Hunk #28 succeeded at 1259 (offset 19 lines).
Hunk #29 succeeded at 1261 with fuzz 2 (offset 13 lines).
Hunk #30 succeeded at 1368 (offset 19 lines).
Hunk #31 FAILED at 1576.
Hunk #32 succeeded at 1600 (offset 13 lines).
Hunk #33 FAILED at 1615.
Hunk #34 succeeded at 1683 (offset 26 lines).
Hunk #35 succeeded at 1717 (offset 13 lines).
Hunk #36 FAILED at 1854.
Hunk #37 succeeded at 2042 (offset 24 lines).
Hunk #38 FAILED at 2152.
Hunk #39 succeeded at 2160 (offset 13 lines).
Hunk #40 succeeded at 2187 (offset 24 lines).
Hunk #41 succeeded at 2245 (offset 13 lines).
Hunk #42 FAILED at 2270.
Hunk #43 succeeded at 2293 with fuzz 2 (offset 24 lines).
Hunk #44 succeeded at 2314 (offset 13 lines).
Hunk #45 FAILED at 2349.
Hunk #46 succeeded at 2387 (offset 30 lines).
Hunk #47 succeeded at 2378 (offset 13 lines).
Hunk #48 FAILED at 2391.
Hunk #49 succeeded at 2445 with fuzz 2 (offset 31 lines).
20 out of 49 hunks FAILED -- saving rejects to file drivers/net/r8169.c.rej

On Tue, Feb 22, 2005 at 05:29:35PM -0800, Andrew Morton wrote:

Francois Romieu [off-list ref] wrote:

quoted

Patch against 2.6.10-rc4:
- http://www.fr.zoreil.com/~romieu/misc/20050222-2.6.11-rc4-r8169.c-test.patch

There are already a bunch of r8169 patches in Jeff's tree.  The combination
isn't pretty:

And ~5 more once I run through the 80+ patches left in my
pending-patches folder.

	Jeff

Andrew Morton [off-list ref] :

There are already a bunch of r8169 patches in Jeff's tree.  The combination
isn't pretty:

[removed by parental advisory]

I sent r8169-4{0/1/2/3/4}0 on netdev + Jeff the 22/02/2005. Jeff's netdev
(thus your tree) already had the r8169-3xx changes.

Jeff has acked r8169-4{0/1/2/3}0 on 23/02/2005. r8169-440 (PCI-ID) won't
be applied (there should be no functionnal change nor merge side-effect).

r8169-4{5/6}0 have been published only here (so far).

So you can:
- apply r8169-4{0/1/2/3/5/6}0 if you have not updated to Jeff -netdev beyond
  what is currently available through plain old patch
- apply r8169-4{5/6}0 if you are bk-synced with Jeff -netdev (assuming that
  Jeff acked after he actually pushed to its bk repo)
- do something else until I verify the above and generate a dedicated
  patchsets for your tree.

--
Ueimor

Francois Romieu [off-list ref] wrote:

- do something else until I verify the above and generate a dedicated
   patchsets for your tree.

That sounds great to me ;)

2.6.11-rc4-mm1 should be on kernel.org in an hour or so.

IRQ races during change of mtu
- NAPI poll must be enabled prior to IRQ activation or the IRQ handler
  will not know what to do with an incoming packet;
- rtl8169_down() needs to try twice to sync with the IRQ handler when
  it is not issued under !netif_running() protection.

Both changes make it safe to request a change of mtu on a live device.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>

diff -puN drivers/net/r8169.c~r8169-450 drivers/net/r8169.c

--- a/drivers/net/r8169.c~r8169-450	2005-02-23 21:35:21.112521942 +0100
+++ b/drivers/net/r8169.c	2005-02-23 21:35:21.117521120 +0100

@@ -1648,10 +1648,10 @@ static int rtl8169_change_mtu(struct net
 	if (ret < 0)
 		goto out;
 
-	rtl8169_hw_start(dev);
-
 	netif_poll_enable(dev);
 
+	rtl8169_hw_start(dev);
+
 	rtl8169_request_timer(dev);
 
 out:

@@ -2352,6 +2352,7 @@ static void rtl8169_down(struct net_devi
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
 	void __iomem *ioaddr = tp->mmio_addr;
+	unsigned int poll_locked = 0;
 
 	rtl8169_delete_timer(dev);
 

@@ -2359,6 +2360,7 @@ static void rtl8169_down(struct net_devi
 
 	flush_scheduled_work();
 
+core_down:
 	spin_lock_irq(&tp->lock);
 
 	/* Stop the chip's Tx and Rx DMA processes. */

@@ -2375,11 +2377,28 @@ static void rtl8169_down(struct net_devi
 
 	synchronize_irq(dev->irq);
 
-	netif_poll_disable(dev);
+	if (!poll_locked) {
+		netif_poll_disable(dev);
+		poll_locked++;
+	}
 
 	/* Give a racing hard_start_xmit a few cycles to complete. */
 	synchronize_kernel();
 
+	/*
+	 * And now for the 50k$ question: are IRQ disabled or not ?
+	 *
+	 * Two paths lead here:
+	 * 1) dev->close
+	 *    -> netif_running() is available to sync the current code and the
+	 *       IRQ handler. See rtl8169_interrupt for details.
+	 * 2) dev->change_mtu
+	 *    -> rtl8169_poll can not be issued again and re-enable the
+	 *       interruptions. Let's simply issue the IRQ down sequence again.
+	 */
+	if (RTL_R16(IntrMask))
+		goto core_down;
+
 	rtl8169_tx_clear(tp);
 
 	rtl8169_rx_clear(tp);

_

Factor out some code

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>

diff -puN drivers/net/r8169.c~r8169-460 drivers/net/r8169.c

--- a/drivers/net/r8169.c~r8169-460	2005-02-23 21:35:28.715271999 +0100
+++ b/drivers/net/r8169.c	2005-02-23 21:35:28.720271177 +0100

@@ -495,6 +495,13 @@ static void rtl8169_irq_mask_and_ack(voi
 	RTL_W16(IntrStatus, 0xffff);
 }
 
+static void rtl8169_asic_down(void __iomem *ioaddr)
+{
+	RTL_W8(ChipCmd, 0x00);
+	rtl8169_irq_mask_and_ack(ioaddr);
+	RTL_R16(CPlusCmd);
+}
+
 static unsigned int rtl8169_tbi_reset_pending(void __iomem *ioaddr)
 {
 	return RTL_R32(TBICSR) & TBIReset;

@@ -2260,8 +2267,10 @@ rtl8169_interrupt(int irq, void *dev_ins
 
 		handled = 1;
 
-		if (unlikely(!netif_running(dev)))
-			goto out_asic_stop;
+		if (unlikely(!netif_running(dev))) {
+			rtl8169_asic_down(ioaddr);
+			goto out;
+		}
 
 		status &= tp->intr_mask;
 		RTL_W16(IntrStatus,

@@ -2310,12 +2319,6 @@ rtl8169_interrupt(int irq, void *dev_ins
 	}
 out:
 	return IRQ_RETVAL(handled);
-
-out_asic_stop:
-	RTL_W8(ChipCmd, 0x00);
-	rtl8169_irq_mask_and_ack(ioaddr);
-	RTL_R16(CPlusCmd);
-	goto out;
 }
 
 #ifdef CONFIG_R8169_NAPI

@@ -2363,11 +2366,7 @@ static void rtl8169_down(struct net_devi
 core_down:
 	spin_lock_irq(&tp->lock);
 
-	/* Stop the chip's Tx and Rx DMA processes. */
-	RTL_W8(ChipCmd, 0x00);
-
-	/* Disable interrupts by clearing the interrupt mask. */
-	RTL_W16(IntrMask, 0x0000);
+	rtl8169_asic_down(ioaddr);
 
 	/* Update the error counts. */
 	tp->stats.rx_missed_errors += RTL_R32(RxMissed);

_