snowball/igloo-kernel.git/drivers/firewire, branch u0

Merge branches 'fixes' and 'fwnet' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6

2011-01-21T21:34:39+00:00

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: core: fix unstable I/O with Canon camcorder * 'fwnet' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: net: is not experimental anymore firewire: net: invalidate ARP entries of removed nodes

firewire: net: is not experimental anymore

2011-01-20T23:36:00+00:00

thanks to Clemens' and Maxim's fixes to firewire-ohci and -net in the last two kernel releases. Signed-off-by: Stefan Richter

firewire: net: invalidate ARP entries of removed nodes

2011-01-20T23:36:00+00:00

This makes it possible to resume communication with a node that dropped off the bus for a brief period. Otherwise communication will only be possible after ARP cache entry timeouts. Signed-off-by: Maxim Levitsky Signed-off-by: Stefan Richter (rebased)

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

2011-01-20T23:27:46+00:00

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 Cc: # 2.6.32.y and newer

firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO

2011-01-13T14:48:29+00:00

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 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 Signed-off-by: Stefan Richter

firewire: use split transaction timeout only for split transactions

2011-01-04T07:48:34+00:00

Instead of starting the split transaction timeout timer when any request is submitted, start it only when the destination's ACK_PENDING has been received. This prevents us from using a timeout that is too short, and, if the controller's AT queue is emptying very slowly, from cancelling a packet that has not yet been sent. Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter

firewire: ohci: consolidate context status flags

2011-01-04T07:48:33+00:00

"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

firewire: ohci: cache the context run bit

2011-01-04T07:48:33+00:00

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 Signed-off-by: Stefan Richter

firewire: ohci: flush AT contexts after bus reset - addendum

2011-01-04T07:48:33+00:00

Add comments - on why bus_reset_tasklet flushes AT queues, - that commit 76f73ca1b291 can possibly be reverted now. Signed-off-by: Stefan Richter Acked-by: Jarod Wilson

firewire: ohci: flush AT contexts after bus reset for OHCI 1.2

2011-01-03T21:34:48+00:00

The OHCI 1.2 (draft) specification, clause 7.2.3.3, allows and recommends that, after a bus reset, the controller does not flush all the packets in the AT queues. Therefore, the driver has to do this itself. Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter