This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 .

An O2Micro PCI Express FireWire controller,
"FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05)"
which is a combination device together with an SDHCI controller and some
sort of storage controller, misses SBP-2 status writes from an attached
FireWire HDD.  This problem goes away if MSI is disabled for this
FireWire controller.

The device reportedly does not require QUIRK_CYCLE_TIMER.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (amended changelog)
Cc: <stable@kernel.org>

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: ohci: fix DMA unmapping in an error path
  firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases

If request_irq failed, we would pass wrong arguments to
dma_free_coherent.  https://bugzilla.redhat.com/show_bug.cgi?id=728185

Reported-by: Mads Kiilerich
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: document the sysfs ABIs
  firewire: cdev: ABI documentation enhancements
  firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing
  firewire: cdev: return -ENOTTY for unimplemented ioctls, not -EINVAL
  firewire: ohci: skip soft reset retries after card ejection
  firewire: ohci: fix PHY reg access after card ejection
  firewire: ohci: add a comment on PHY reg access serialization
  firewire: ohci: reduce potential context_stop latency
  firewire: ohci: remove superfluous posted write flushes
  firewire: net: replacing deprecated __attribute__((packed)) with __packed

When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a
"Register access failure" is logged and an interrupt storm or a kernel
panic happens.  https://bugzilla.kernel.org/show_bug.cgi?id=36622

Until this is sorted out (if that is going to succeed at all), let's
just prevent firewire-ohci from touching these devices.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>

The software reset in firewire-ohci's pci_remove does not have a great
prospect of success if the card was already physically removed at this
point.  So let's skip the 500 ms that were spent in retries here.

Also, replace a defined constant by its open-coded value.  This is not a
constant from a specification but an arbitrarily chosen retry limit.  It
was only used in this single place.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Detect and handle ejection of FireWire CardBus cards in PHY register
accesses:

  - The last attempt of firewire-core to reset the bus during shutdown
    caused a spurious "firewire_ohci: failed to write phy reg" error
    message in the log.  Skip this message as well as the prior retry
    loop that needlessly took 100 milliseconds.

  - In the unlikely case that a PHY register was read right after card
    ejection, a bogus value was obtained and possibly acted upon.
    Instead, fail the read attempt.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Stopping an isochronous reception DMA context takes two loop iterations
in context_stop on several controllers (JMicron, NEC, VIA).  But there
is no extra delay necessary between these two reg_read trials; the MMIO
reads themselves are slow enough.  Hence bring back the behavior from
before commit dd6254e5c0efe01ad255188898cb3dadf98cb56d "firewire: ohci:
remove superfluous posted write flushes" on these controllers by means
of an "if (i)" condition.

Isochronous context stop is performed in preemptible contexts (and only
rarely), hence this change is of little impact.  (Besides, Agere and TI
controllers always, or almost always, have the context stopped already
at the first ContextControl read.)

More important is asynchronous transmit context stop, which is performed
while local interrupts are disabled (on the two AT DMAs in
bus_reset_tasklet, i.e. after a self-ID-complete event).  In my
experience with several controllers, tested with a usermode AT-request
transmitter as well as with FTP transmission over firewire-net, the AT
contexts were luckily already stopped at the first ContextControl read,
i.e. never required another MMIO read let alone mdelay.  A possible
explanation for this is that the controllers which I tested perhaps stop
AT DMA before they perform the self-ID reception DMA.

But we cannot be sure about that and should keep the interrupts-disabled
busy loop as short as possible.  Hence, query the ContextControl
register in 1000 udelay(10) intervals instead of 10 udelay(1000)
intervals.  I understand from an estimation by Clemens Ladisch that
stopping a busy DMA context should take microseconds or at worst tens of
microseconds, not milliseconds.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

The call to flush_writes() in context_stop() is superfluous because
another register read is done immediately afterwards.

The call to flush_writes() in ar_context_run() does not need to be done
individually for each AR context, so move it to ohci_enable().  This
also makes ohci_enable() clearer because it no longer depends on a side
effect of ar_context_run() to flush its own register writes.

Finally, the setting of a context's wake bit does not need to be flushed
because neither the driver logic nor the API require the CPU to wait for
this action.  This removes the last MMIO reads from the packet queueing
code paths.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>