linux-toradex.git/drivers/firewire, branch v2.6.28.9

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

2009-02-12T17:50:26+00:00

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:50:26+00:00

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:50:26+00:00

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-10T11:45:34+00:00

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

firewire: fw-sbp2: another iPod mini quirk entry

2008-11-25T20:38:31+00:00

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

firewire: struct device - replace bus_id with dev_name(), dev_set_name()

2008-10-31T07:48:25+00:00

Acked-by: Greg Kroah-Hartman 
Signed-off-by: Kay Sievers 
Signed-off-by: Stefan Richter

firewire: fw-sbp2: fix races

2008-10-26T09:27:01+00:00

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

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

2008-10-26T09:27:01+00:00

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

firewire: fw-ohci: initialization failure path fixes

2008-10-26T09:27:00+00:00

Fix leaks when pci_probe fails.  Simplify error log strings.

Signed-off-by: Stefan Richter

firewire: fw-ohci: don't leak dma memory on module removal

2008-10-26T09:27:00+00:00

The transmit and receive context dma memory was not being freed on
module removal.  Neither was the config rom memory.  Fix that.

The ab->next assignment is pure paranoia.

Signed-off-by: Jay Fenlason 
Signed-off-by: Stefan Richter