linux/drivers/firewire, branch v2.6.27.60

firewire: ohci: handle receive packets with a data length of zero

2009-12-18T21:30:43Z

commit 8c0c0cc2d9f4c523fde04bdfe41e4380dec8ee54 upstream. Queueing to receive an ISO packet with a payload length of zero silently does nothing in dualbuffer mode, and crashes the kernel in packet-per-buffer mode. Return an error in dualbuffer mode, because the DMA controller won't let us do what we want, and work correctly in packet-per-buffer mode. Signed-off-by: Jay Fenlason Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: sbp2: add support for disks >2 TB (and 16 bytes long CDBs)

2009-08-16T21:27:00Z

Commit af2719415a5ceae06f2a6d33e78b555e64697fc8 upstream. Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: sbp2: add workarounds for 2nd and 3rd generation iPods

2009-02-12T17:31:05Z

Commit c8c4707cf7ca8ff7dcc1653447e48cb3de0bf114 upstream. According to https://bugs.launchpad.net/bugs/294391 - 3rd generation iPods need the "fix capacity" workaround after all (apparently they crash after the last sector was accessed), - 2nd generation iPods need the "128 kB maximum request size" workaround. Alas both iPod generations feature the same model ID in the config ROM, hence we can only define a shared quirks list entry for them. Luckily the fix capacity workaround did not show a negative effect in Jarod's tests with 2nd gen. iPod. A side note: Apple computers in target mode (or at least an x86 Mac mini) don't have firmware_version and model_id, hence none of the iPod quirks list entries is active for them. Tested-by: Jarod Wilson Acked-by: Jarod Wilson Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: sbp2: fix DMA mapping leak on the failure path

2009-02-12T17:31:05Z

Commit 5e2125677fd72d36396cc537466e07ffcbbd4b2b upstream. Reported-by: FUJITA Tomonori who also provided a first version of the fix. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others

2009-02-12T17:31:04Z

Commit 8b7b6afaa84708d08139daa08538ca3e56c351f1 upstream. Camcorders have a tendency to fail read requests to their config ROM and write request to their FCP command register with ack_busy_X. This has become a problem with newer kernels and especially Panasonic camcorders, causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently logs "send oops"; kino reports loss of AV/C control. I suspect that lower CPU scheduling latencies in newer kernels made this issue more prominent now. According to https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 this can be fixed by configuring the FireWire controller for more hardware retries for request transmission; these retries are evidently more successful than libavc1394's own retry loop (typically 3 tries on top of hardware retries). Presumably the same issue has been reported at https://bugzilla.redhat.com/show_bug.cgi?id=449252 and https://bugzilla.redhat.com/show_bug.cgi?id=477279 . In a quick test with a JVC camcorder (which didn't malfunction like the reported camcorders), this change decreased the number of ack_busy_X from 16 in three runs of dvgrab to 4 in three runs of the same capture duration. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: fw-ohci: fix IOMMU resource exhaustion

2008-12-18T17:13:38Z

commit 1d1dc5e83f3299c108a4e44d58cc4bfef48c876a upstream. There is a DMA map/ unmap imbalance whenever a block write request packet is sent and then dequeued with ohci_cancel_packet. The latter may happen frequently if the AR resp tasklet is executed before the AT req tasklet for the same transaction. Add the missing dma_unmap_single. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=475156 Reported-by: Emmanuel Kowalski Tested-by: Emmanuel Kowalski Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: fw-sbp2: another iPod mini quirk entry

2008-12-05T18:55:25Z

commit 031bb27c4bf77c2f60b3f3dea8cce63ef0d1fba9 upstream. Add another model ID of a broken firmware to prevent early I/O errors by acesses at the end of the disk. Reported at linux1394-user, http://marc.info/?t=122670842900002 Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: fw-sbp2: fix races

2008-11-07T03:05:45Z

Same as commit cd1f70fdb4823c97328a1f151f328eb36fafd579 upstream 1: There is a small race between queue_delayed_work() and its corresponding kref_get(). Do the kref_get first, and _put it again if the queue_delayed_work() failed, so there is no chance of the kref going to zero while the work is scheduled. 2: An SBP2_LOGOUT_REQUEST could be sent out with a login_id full of garbage. Initialize it to an invalid value so we can tell if we ever got a valid login_id. 3: The node ID and generation may have changed but the new values may not yet have been recorded in lu and tgt when the final logout is attempted. Use the latest values from the device in sbp2_release_target(). Signed-off-by: Jay Fenlason Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: fw-sbp2: delay first login to avoid retries

2008-11-07T03:05:45Z

commit 0dcfeb7e3c8695c5aa3677dda8efb9bef2e7e64d upstream This optimizes firewire-sbp2's device probe for the case that the local node and the SBP-2 node were discovered at the same time. In this case, fw-core's bus management work and fw-sbp2's login and SCSI probe work are scheduled in parallel (in the globally shared workqueue and in fw-sbp2's workqueue, respectively). The bus reset from fw-core may then disturb and extremely delay the login and SCSI probe because the latter fails with several command timeouts and retries and has to be retried from scratch. We avoid this particular situation of sbp2_login() and fw_card_bm_work() running in parallel by delaying the first sbp2_login() a little bit. This is meant to be a short-term fix for https://bugzilla.redhat.com/show_bug.cgi?id=466679. In the long run, the SCSI probe, i.e. fw-sbp2's call of __scsi_add_device(), should be parallelized with sbp2_reconnect(). Problem reported and fix tested and confirmed by Alex Kanavin. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: fix struct fw_node memory leak

2008-11-07T03:05:44Z

commit 77e557191701afa55ae7320d42ad6458a2ad292e upstream With the bus_resets patch applied, it is easy to see this memory leak by repeatedly resetting the firewire bus while running slabtop in another window. Just watch kmalloc-32 grow and grow... Signed-off-by: Jay Fenlason Signed-off-by: Stefan Richter