linux/drivers/firewire, branch v2.6.25

firewire: fw-ohci: plug dma memory leak in AR handler

2008-03-27T20:01:14Z

There's an ugly little memory leak in firewire-ohci's ar_context_tasklet(), where we're not freeing up some of the memory we use for each ar_buffer, due to a moving pointer. The problem has been there for a while, but didn't get noticed until after converting the AR routines over to use coherent DMA and I started running into I/O stall- outs with the following message output repeatedly to the console: PCI-DMA: Out of IOMMU space for 53248 bytes at device 0000:04:09.0 Plugging this leak is definitely necessary, but unfortunately, isn't the entire answer to my problem, it only increases the amount of I/O that I can do before hitting the problem. Still working on tracking down the root cause.. Signed-off-by: Jarod Wilson Signed-off-by: Stefan Richter

firewire: fix panic in handle_at_packet

2008-03-20T17:13:05Z

This fixes a use-after-free bug in the handling of split transactions. The AT DMA handler of the request was occasionally executed after the AR DMA handler of the response. The AT DMA handler then accessed an already freed packet. Reported by Johannes Berg. http://bugzilla.kernel.org/show_bug.cgi?id=9617 Signed-off-by: Stefan Richter Tested-by: Johannes Berg Signed-off-by: Jarod Wilson

firewire: fw-ohci: shut up false compiler warning on PPC32

2008-03-13T23:57:00Z

Shut up "may be used uninitialised in this function" warnings due to PPC32's implementation of dma_alloc_coherent(). Signed-off-by: Stefan Richter

firewire: fw-ohci: use dma_alloc_coherent for ar_buffer

2008-03-13T23:57:00Z

Currently, we do nothing to guarantee we have a consistent DMA buffer for asynchronous receive packets. Rather than doing several sync's following a dma_map_single() to get consistent buffers, just switch to using dma_alloc_coherent(). Resolves constant buffer failures on my own x86_64 laptop w/4GB of RAM and likely to fix a number of other failures witnessed on x86_64 systems with 4GB of RAM or more. Signed-off-by: Jarod Wilson Signed-off-by: Stefan Richter

firewire: fw-sbp2: fix for SYM13FW500 bridge (Datafab disk)

2008-03-13T23:56:59Z

Fix I/O errors due to SYM13FW500's inability to handle larger request sizes. Reported by Piergiorgio Sartor in https://bugzilla.redhat.com/show_bug.cgi?id=436879 Signed-off-by: Stefan Richter Signed-off-by: Jarod Wilson

firewire: update Kconfig help text

2008-03-13T23:56:59Z

Remove some less necessary information, point out that video1394 and dv1394 should be blacklisted along with ohci1394. Signed-off-by: Stefan Richter

firewire: warn on fatal condition in topology code

2008-03-13T23:56:59Z

If this ever happens to anybody, we want to have it in his log. Signed-off-by: Stefan Richter

firewire: fw-sbp2: set single-phase retry_limit

2008-03-13T23:56:59Z

Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT register. Per the 1394-1995 specification, the retry_limt portion of the register should be set to 0x0 initially, and set on the target by a logged in initiator (i.e., a Linux host w/firewire controller(s)). Well, as it turns out, lots of devices these days have actually moved on to starting to implement SBP-3 compliance, which says that retry_limit should default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops). Prior to this change, the firewire driver stack didn't touch retry_limit, and any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable to retransmit when the host returned an ack_busy_X, which resulted in stalled out I/O, eventually causing the SCSI layer to give up and offline the device. The simple fix is for us to set retry_limit to 0xf in the register for all devices (which actually matches what the old ieee1394 stack did). Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip would routinely encounter buffer I/O errors and wind up offlined by the SCSI layer. With this change, I've encountered zero I/O failures moving tens of GB of data around. Signed-off-by: Jarod Wilson Signed-off-by: Stefan Richter

firewire: fw-ohci: Apple UniNorth 1st generation support

2008-03-13T23:56:59Z

Mostly copied from ohci1394.c. Necessary for some older Macs, e.g. PowerBook G3 Pismo and early PowerBook G4 Titanium. Signed-off-by: Stefan Richter

firewire: fw-ohci: PPC PMac platform code

2008-03-13T23:56:58Z

Copied from ohci1394.c. This code is necessary to prevent machine check exceptions when reloading or resuming the driver. Tested on a 1st generation PowerBook G4 Titanium, which also needs the pci_probe() hunk. Signed-off-by: Stefan Richter I was able to reproduce the system exception on resume with a 3rd-gen Titanium PowerBook G4 667, and this patch does let the system resume successfully now. Not quite clear if there was possibly an updated version coming using pci_enable_device() instead of the pair of pmac_call_feature() calls, but either way, this is a definite must-have, at least for older ppc macs -- my Aluminum PowerBook G4/1.67 suspends and resumes without this patch just fine. Signed-off-by: Jarod Wilson Acked-by: Benjamin Herrenschmidt