summaryrefslogtreecommitdiff
path: root/drivers/Makefile
diff options
context:
space:
mode:
authorJarod Wilson <jwilson@redhat.com>2008-04-07 20:32:33 (GMT)
committerStefan Richter <stefanr@s5r6.in-berlin.de>2008-04-18 15:55:35 (GMT)
commit76f73ca1b291a8d014ff0d2d802c817404dd9887 (patch)
treeffd21353249da5febbe5518d9f8eed6b886b5dbf /drivers/Makefile
parent75f7832e3b032c6e4a83c14b58341abd9f2d81ef (diff)
downloadlinux-fsl-qoriq-76f73ca1b291a8d014ff0d2d802c817404dd9887.tar.xz
firewire: fw-ohci: don't append to AT context when it's not active
I finally tracked down the issues with this JMicron PCI-e card in my possession to a failure to comply with section 7.2.3.2 of the OHCI 1.1 specification (thanks to Kristian for the pointer to illustrate that it is indeed a flaw in this card, not the driver). The controller should simply flush the packets we've appended to its AT queue if a bus reset occurs before they've been transmitted and we'll try again, but something goes wrong and the controller winds up hung. However, we can avoid the problem by simply checking if the IntEvent.busReset register had been set before we try appending to the AT context. When busReset is set, the AT context is completely halted until busReset is cleared, so there's no point in appending AT packets until the register is cleared. So at_context_queue_packet() now checks for busReset being set, and bails with an RCODE_GENERATION packet ack, which results in us trying to append the packet again after recognizing the fact there has been a bus reset, and clearing busReset. Signed-off-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Diffstat (limited to 'drivers/Makefile')
0 files changed, 0 insertions, 0 deletions