Current implementation of ohci_set_config_rom() uses a deferred
bus reset via fw_schedule_bus_reset(). If clients add multiple
unit descriptors to the config_rom in quick succession, the
deferred bus reset may not have fired before succeeding update
requests have come in. This can lead to an incorrect partial
update of the config_rom for both addition and removal of
config_rom descriptors, as the ohci_set_config_rom() routine
will return -EBUSY if a previous pending update has not been
completed yet; the requested update just gets dropped on the floor.

This patch recognizes that the "in-flight" update can be modified
until it has been processed by the bus-reset, and the locking
in the bus_reset_tasklet ensures that the update is done atomically
with respect to modifications made by ohci_set_config_rom(). The
-EBUSY error case is simply removed.

[Stefan R:  The bug always existed at least theoretically.  But it
became easy to trigger since 2.6.36 commit 02d37bed188c "firewire: core:
integrate software-forced bus resets with bus management" which
introduced long mandatory delays between janitorial bus resets.]

Signed-off-by: Benjamin Buchalter <bj@mhlabs.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (trivial style changes)
Cc: <stable@kernel.org> # 2.6.36.y and newer

It seems drivers/firewire/ohci.c is making some optimistic assumptions
about struct fw_ohci and that member "card" will always remain the first
member of the struct.
Plus it's probably going to confuse a lot of static code analyzers too.

So I wonder if there is a good reason not to free the ohci struct just
like it was allocated instead of the tricky &ohci->card way?

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>

It is perhaps just a rudiment from before mainline submission of the
driver.

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

Since commit 82b662dc4102 "flush AT contexts after bus reset for OHCI 1.2",
the driver takes care of any AT packets that were enqueued during a bus
reset phase.  The check from commit 76f73ca1b291 is therefore no longer
necessary and the MMIO read can be avoided.

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

If a misguided program tried to start an isochronous context before it
has queued any packets, the call would appear to succeed, but the
context would not actually go into the running state, and the OHCI
controller would then raise an unrecoverableError interrupt because the
first Z value is zero and thus invalid.  The driver logs such errors,
but there is no mechanism to report this back to the program.

Add an explicit check so that this error can be returned synchronously.

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

To prevent the iso packet callback from being called after
fw_iso_context_stop() has returned, make sure that the
context's tasklet has finished executing before that.

This fixes access-after-free bugs that have so far been
observed only in the upcoming snd-firewire-speakers driver,
but can theoretically also happen in the firedtv driver.

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

When a DMA context goes into the dead state (and the controller thus
stops working correctly), logging this error and the controller's error
code might be helpful for debugging.

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

PAGE_KERNEL_RO is not available on all architectures, so its use
in the new AR code broke compilation on sparc64.

Because the read-only mapping was just a debugging aid, just use
PAGE_KERNEL instead.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

James Bottomley wrote:
> On Thu, 2011-01-13 at 08:27 +0100, Clemens Ladisch wrote:
>> firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO, e.g. sparc
>>
>> PAGE_KERNEL_RO is not available on all architectures, so its use in the
>> new AR code broke compilation on sparc64.
>>
>> Because the R/O mapping is only used to catch drivers that try to write
>> to the reception buffer and not actually required for correct operation,
>> we can just use a normal PAGE_KERNEL mapping where _RO is not available.
[...]
>> +/*
>> + * For archs where PAGE_KERNEL_RO is not supported;
>> + * mapping the AR buffers readonly for the CPU is just a debugging aid.
>> + */
>> +#ifndef PAGE_KERNEL_RO
>> +#define PAGE_KERNEL_RO PAGE_KERNEL
>> +#endif
>
> This might cause interesting issues on sparc64 if it ever acquired a
> PAGE_KERNEL_RO.  Sparc64 has extern pgprot_t for it's PAGE_KERNEL types
> rather than #defines, so the #ifdef check wouldn't see this.
>
> I think either PAGE_PROT_RO becomes part of our arch API (so all
> architectures are forced to add it), or, if it's not part of the API,
> ohci isn't entitled to use it.  The latter seems simplest since you have
> no real use for write protection anyway.

Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

"firewire: ohci: restart iso DMA contexts on resume from low power mode"
added the flag struct context.active and "firewire: ohci: cache the
context run bit" added struct context.running.

These flags contain the same information; combine them.
Also, normalize whitespace in pci_resume().

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

The DMA context run control bit is entirely controlled by software, so
it is safe to cache it.  This allows the driver to avoid doing an
additional MMIO read when queueing an AT packet.

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

Add comments
  - on why bus_reset_tasklet flushes AT queues,
  - that commit 76f73ca1b291 can possibly be reverted now.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Jarod Wilson <jarod@redhat.com>