More fixes for 2.6.0-test9

Hi,

Here are some more minor fixes for 2.6.0-test9. These fixes do the following:
- fix oops with cardbus firewire controllers
- fix oops with usbnet devices on non-i386 platforms
- fix oops when removing the usb-storage module when using preempt.

Please pull from: bk://linuxusb.bkbits.net/gregkh-2.6

Patches will be posted as a follow-up thread for those who want to see them.

thanks,

greg k-h

 drivers/pci/quirks.c        |    2 +-
 drivers/usb/host/ehci-hcd.c |    3 +++
 drivers/usb/net/kaweth.c    |    3 +++
 drivers/usb/net/usbnet.c    |    3 +++
 drivers/usb/storage/usb.c   |   19 +++++++++++++++----
 5 files changed, 25 insertions(+), 5 deletions(-)

-----

<michael:metaparadigm.com>:
o PCI: Fix oops in quirk_via_bridge

David Brownell:
o USB: usb ignores 64bit dma

Matthew Dharm:
o USB: fix a thread-exit problem at module unload

ChangeSet 1.1418, 2003/11/07 10:04:16-08:00, [email protected]

[PATCH] PCI: Fix oops in quirk_via_bridge

I have a VIA cardbus 1394 controller which oops on insertion after an APM suspend/resume cycle (without card inserted):

bounds: 0000 [#1]
CPU:    0
EIP:    0060:[<c0300060>]    Tainted: PF
EFLAGS: 00010206

EIP is at quirk_via_bridge+0x4/0x1c
eax: 0000ffff ebx: c02982e0 ecx: d1958000 edx: 000c0010
esi: d1958000 edi: 00000001 ebp: 00000000 esp: da401ee8
ds: 007b es: 007b ss: 0068
Process pccardd (pid: 1093, threadinfo=da400000 task=da4c8780)

Stack: c019fb85 d1958000 00000001 d1958000 00000000 c019fbc2 d1958000 00000001
         c02980a0 d1958000 dfdebf14 c019d828 00000001 d1958000 00000000 dec2802c
         dfdebf00 dfdebf14 00000000 e3dfe7c7 dfdebf00 00000000 dec2802c da401f48
Call Trace:
   [<c019fb85>] pci_do_fixups+0x52/0x54
   [<c019fbc2>] pci_fixup_device+0x3b/0x49
   [<c019d828>] pci_scan_slot+0x46/0x8f
   [<e3dfe7c7>] cb_alloc+0x29/0xf7 [pcmcia_core]
   [<e3dfb9aa>] socket_insert+0x90/0x102 [pcmcia_core]
   [<e3dfbc0d>] socket_detect_change+0x54/0x7e [pcmcia_core]
   [<e3dfbdbc>] pccardd+0x185/0x1f9 [pcmcia_core]

quirk_via_bridge (which is marked device PCI_ANY_ID) triggers on my 1394 controller which vendor=VIA but is not a bridge.

Making the quirk __devinit solves the problem.

 drivers/pci/quirks.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
@@ -646,7 +646,7 @@
  
 int interrupt_line_quirk;
 
-static void __init quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_bridge(struct pci_dev *pdev)
 {
 	if(pdev->devfn == 0)
 		interrupt_line_quirk = 1;

ChangeSet 1.1419, 2003/11/07 10:07:03-08:00, [email protected]

[PATCH] USB: fix a thread-exit problem at module unload

This patch fixes a thread-exit problem when the usb-storage module is unloaded with a preemptable kernel. Please refer to the comments in the code for more detail.

 drivers/usb/storage/usb.c |   19 +++++++++++++++----
 1 files changed, 15 insertions(+), 4 deletions(-)

diff -Nru a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
@@ -417,10 +417,21 @@
 		scsi_unlock(host);
 	} /* for (;;) */
 
-	/* notify the exit routine that we're actually exiting now */
-	complete(&(us->notify));
-
-	return 0;
+	/* notify the exit routine that we're actually exiting now 
+	 *
+	 * complete()/wait_for_completion() is similar to up()/down(),
+	 * except that complete() is safe in the case where the structure
+	 * is getting deleted in a parallel mode of execution (i.e. just
+	 * after the down() -- that's necessary for the thread-shutdown
+	 * case.
+	 *
+	 * complete_and_exit() goes even further than this -- it is safe in
+	 * the case that the thread of the caller is going away (not just
+	 * the structure) -- this is necessary for the module-remove case.
+	 * This is important in preemption kernels, which transfer the flow
+	 * of execution immediately upon a complete().
+	 */
+	complete_and_exit(&(us->notify), 0);
 }	
 
 /***********************************************************************

ChangeSet 1.1420, 2003/11/07 10:19:35-08:00, [email protected]

[PATCH] USB: usb ignores 64bit dma

The dma hooks whereby EHCI can pass 64bit DMA support up the driver stack (to avoid buffer copies) turn out to broken on most architectures(*). This patch just disables them all, since it looks like those mechanisms won't get fixed before 2.6.0-final. For now it'd only matter on a few big Intel boxes anyway.

Please merge.

- Dave

(*) On x86, mips, and arm dma_supported() doesn't
even compare with the device's mask. On several other architectures (reported on ppc, alpha, and sparc64), asking that question for non-PCI devices will just BUG() -- even though all info needed to answer the question is right at hand.

 drivers/usb/host/ehci-hcd.c |    3 +++
 drivers/usb/net/kaweth.c    |    3 +++
 drivers/usb/net/usbnet.c    |    3 +++
 3 files changed, 9 insertions(+)

diff -Nru a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
@@ -426,8 +426,11 @@
 	 */
 	if (HCC_64BIT_ADDR (hcc_params)) {
 		writel (0, &ehci->regs->segment);
+#if 0
+// this is deeply broken on almost all architectures
 		if (!pci_set_dma_mask (ehci->hcd.pdev, 0xffffffffffffffffULL))
 			ehci_info (ehci, "enabled 64bit PCI DMA\n");
+#endif
 	}
 
 	/* help hc dma work well with cachelines */

diff -Nru a/drivers/usb/net/kaweth.c b/drivers/usb/net/kaweth.c
@@ -1120,8 +1120,11 @@
 
 	usb_set_intfdata(intf, kaweth);
 
+#if 0
+// dma_supported() is deeply broken on almost all architectures
 	if (dma_supported (&intf->dev, 0xffffffffffffffffULL))
 		kaweth->net->features |= NETIF_F_HIGHDMA;
+#endif
 
 	SET_NETDEV_DEV(netdev, &intf->dev);
 	if (register_netdev(netdev) != 0) {

diff -Nru a/drivers/usb/net/usbnet.c b/drivers/usb/net/usbnet.c
@@ -2972,9 +2972,12 @@
 	strcpy (net->name, "usb%d");
 	memcpy (net->dev_addr, node_id, sizeof node_id);
 
+#if 0
+// dma_supported() is deeply broken on almost all architectures
 	// possible with some EHCI controllers
 	if (dma_supported (&udev->dev, 0xffffffffffffffffULL))
 		net->features |= NETIF_F_HIGHDMA;
+#endif
 
 	net->change_mtu = usbnet_change_mtu;
 	net->get_stats = usbnet_get_stats;