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

firewire: core: fix unstable I/O with Canon camcorder

2011-02-17T22:47:21+00:00

commit 6044565af458e7fa6e748bff437ecc49dea88d79 upstream.

Regression since commit 10389536742c, "firewire: core: check for 1394a
compliant IRM, fix inaccessibility of Sony camcorder":

The camcorder Canon MV5i generates lots of bus resets when asynchronous
requests are sent to it (e.g. Config ROM read requests or FCP Command
write requests) if the camcorder is not root node.  This causes drop-
outs in videos or makes the camcorder entirely inaccessible.
https://bugzilla.redhat.com/show_bug.cgi?id=633260

Fix this by allowing any Canon device, even if it is a pre-1394a IRM
like MV5i are, to remain root node (if it is at least Cycle Master
capable).  With the FireWire controller cards that I tested, MV5i always
becomes root node when plugged in and left to its own devices.

Reported-by: Ralf Lange
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix regression with Agere FW643 rev 06, disable MSI

2011-01-07T21:58:15+00:00

commit 9993e0fe0f5f29c69e79efcb271ffc9843002985 upstream.

Agere FW643 rev 06, listed as "11c1:5901 (rev 06) (prog-if 10 [OHCI])",
produced SBP-2 I/O errors since kernel 2.6.36.  Disabling MSI fixes it.

Since MSI work on Agere FW643-E (same vendor and device ID, but rev 07),
introduce a device revision field into firewire-ohci's quirks list so
that different quirks can be defined for older and newer revisions.

Reported-by: Jonathan Isom 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix regression with VIA VT6315, disable MSI

2011-01-07T21:58:15+00:00

commit af0cdf4947818becfe209610b209315578645ab4 upstream.

"VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]"
does not generate any interrupts if Message Signaled Interrupts were
enabled.  This is a regression since kernel 2.6.36 in which MSI support
was added to firewire-ohci.  Hence blacklist MSI on all VIA controllers.

Reported-by: Robin Cook 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix race in AR split packet handling

2010-12-09T21:32:47+00:00

commit a1f805e5e73a8fe166b71c6592d3837df0cd5e2e upstream.

When handling an AR buffer that has been completely filled, we assumed
that its descriptor will not be read by the controller and can be
overwritten.  However, when the last received packet happens to end at
the end of the buffer, the controller might not yet have moved on to the
next buffer and might read the branch address later.  If we overwrite
and free the page before that, the DMA context will either go dead
because of an invalid Z value, or go off into some random memory.

To fix this, ensure that the descriptor does not get overwritten by
using only the actual buffer instead of the entire page for reassembling
the split packet.  Furthermore, to avoid freeing the page too early,
move on to the next buffer only when some data in it guarantees that the
controller has moved on.

This should eliminate the remaining firewire-net problems.

Signed-off-by: Clemens Ladisch 
Tested-by: Maxim Levitsky 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix buffer overflow in AR split packet handling

2010-12-09T21:32:47+00:00

commit 85f7ffd5d2b320f73912b15fe8cef34bae297daf upstream.

When the controller had to split a received asynchronous packet into two
buffers, the driver tries to reassemble it by copying both parts into
the first page.  However, if size + rest > PAGE_SIZE, i.e., if the yet
unhandled packets before the split packet, the split packet itself, and
any received packets after the split packet are together larger than one
page, then the memory after the first page would get overwritten.

To fix this, do not try to copy the data of all unhandled packets at
once, but copy the possibly needed data every time when handling
a packet.

This gets rid of most of the infamous crashes and data corruptions when
using firewire-net.

Signed-off-by: Clemens Ladisch 
Tested-by: Maxim Levitsky 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix TI TSB82AA2 regression since 2.6.35

2010-10-17T12:09:12+00:00

Revert commit 54672386ccf36ffa21d1de8e75624af83f9b0eeb
"firewire: ohci: fix up configuration of TI chips".
It caused massive slow-down and data corruption with a TSB82AA2 based
StarTech EC1394B2 ExpressCard and FireWire 800 harddisks.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/657081
http://thread.gmane.org/gmane.linux.kernel.firewire.user/4013

The fact that some card EEPROMs do not program these enhancements may be
related to TSB81BA3 phy chip errata, if not to bugs of TSB82AA2 itself.
We could re-add these configuration steps, but only conditional on a
whitelist of cards on which these enhancements bring a proven positive
effect.

Reported-and-tested-by: Eric Shattow 
Cc: Clemens Ladisch 
Cc:  2.6.35
Signed-off-by: Stefan Richter

firewire: ohci: activate cycle timer register quirk on Ricoh chips

2010-09-08T19:25:55+00:00

The Ricoh FireWire controllers appear to have the non-atomic cycle
timer register access bug, so, activate the driver workaround by
default.

The behaviour was observed on:
Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] and
Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04).

Signed-off-by: Heikki Lindholm 
Signed-off-by: Stefan Richter

firewire: ohci: work around VIA and NEC PHY packet reception bug

2010-08-29T07:17:31+00:00

VIA VT6306, VIA VT6308, and NEC OrangeLink controllers do not write
packet event codes for received PHY packets (or perhaps write
evt_no_status, hard to tell).  Work around it by overwriting the
packet's ACK by ack_complete, so that upper layers that listen to PHY
packet reception get to see these packets.

(Also tested:  TI TSB82AA2, TI TSB43AB22/A, TI XIO2213A, Agere FW643,
JMicron JMB381 --- these do not exhibit this bug.)

Clemens proposed a quirks flag for that, IOW whitelist known misbehaving
controllers for this workaround.  Though to me it seems harmless enough
to enable for all controllers.

The log_ar_at_event() debug log will continue to show the original
status from the DMA unit.

Reported-by: Clemens Ladisch  (VT6308)
Signed-off-by: Stefan Richter

firewire: core: do not use del_timer_sync() in interrupt context

2010-08-19T18:28:25+00:00

Because we might be in interrupt context, replace del_timer_sync() with
del_timer().  If the timer is already running, we know that it will
clean up the transaction, so we do not need to do any further processing
in the normal transaction handler.

Many thanks to Yong Zhang for diagnosing this.

Reported-by: Stefan Richter 
Signed-off-by: Clemens Ladisch 
Signed-off-by: Stefan Richter

firewire: net: fix unicast reception RCODE in failure paths

2010-08-19T18:28:25+00:00

The incoming request hander fwnet_receive_packet() expects subsequent
datagram handling code to return non-zero on errors.  However, almost
none of the failure paths did so.  Fix them all.

(This error reporting is used to send and RCODE_CONFLICT_ERROR to the
sender node in such failure cases.  Two modes of failure exist:  Out of
memory, or firewire-net is unaware of any peer node to which a fragment
or an ARP packet belongs.  However, it is unclear whether a sender can
actually make use of such information.  A Linux peer apparently can't.
Maybe it should all be simplified to void functions.)

Reported-by: Julia Lawall 
Signed-off-by: Stefan Richter