diff options
author | Stefan Richter <stefanr@s5r6.in-berlin.de> | 2010-08-28 14:21:26 +0200 |
---|---|---|
committer | Stefan Richter <stefanr@s5r6.in-berlin.de> | 2010-08-29 09:17:31 +0200 |
commit | a4dc090b6cb445257d2a8e44f85395ced6d1ed3e (patch) | |
tree | 1cba172819b1395237adb69e34dfa469a63dbb68 | |
parent | 2222bcb76790f4f61f39ec1514946a7593b07e02 (diff) |
firewire: ohci: work around VIA and NEC PHY packet reception bug
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 <clemens@ladisch.de> (VT6308)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-rw-r--r-- | drivers/firewire/ohci.c | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 7f03540cabe..be29b0bb247 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -694,7 +694,15 @@ static __le32 *handle_ar_packet(struct ar_context *ctx, __le32 *buffer) log_ar_at_event('R', p.speed, p.header, evt); /* - * The OHCI bus reset handler synthesizes a phy packet with + * Several controllers, notably from NEC and VIA, forget to + * write ack_complete status at PHY packet reception. + */ + if (evt == OHCI1394_evt_no_status && + (p.header[0] & 0xff) == (OHCI1394_phy_tcode << 4)) + p.ack = ACK_COMPLETE; + + /* + * The OHCI bus reset handler synthesizes a PHY packet with * the new generation number when a bus reset happens (see * section 8.4.2.3). This helps us determine when a request * was received and make sure we send the response in the same |