kernel/drivers/firewire, branch linux-2.6.39.y

firewire: ohci: do not bind to Pinnacle cards, avert panic

2011-08-03T19:42:29Z

commit 7f7e37115a8b6724f26d0637a04e1d35e3c59717 upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2011-05-04T21:21:39Z

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: Fix for broken configrom updates in quick succession

firewire: Fix for broken configrom updates in quick succession

2011-05-02T20:55:22Z

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 Signed-off-by: Stefan Richter (trivial style changes) Cc: # 2.6.36.y and newer

Fix common misspellings

2011-03-31T14:26:23Z

Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6

2011-03-21T17:05:22Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: core: ignore link-active bit of new nodes, fix device recognition firewire: sbp2: revert obsolete 'fix stall with "Unsolicited response"' firewire: core: increase default SPLIT_TIMEOUT value firewire: ohci: Misleading kfree in ohci.c::pci_probe/remove firewire: ohci: omit IntEvent.busReset check rom AT queueing firewire: ohci: prevent starting of iso contexts with empty queue firewire: ohci: prevent iso completion callbacks after context stop firewire: core: rename some variables firewire: nosy: should work on Power Mac G4 PCI too firewire: core: fix card->reset_jiffies overflow firewire: cdev: remove unneeded reference firewire: cdev: always wait for outbound transactions to complete firewire: cdev: remove unneeded idr_find() from complete_transaction() firewire: ohci: log dead DMA contexts

firewire: core: ignore link-active bit of new nodes, fix device recognition

2011-03-20T15:45:25Z

Like the older ieee1394 core driver, firewire-core skipped scanning of any new node whose PHY sent a self ID without "link active" bit. If a device had this bit off mistakenly, it meant that it was inaccessible to kernel drivers with the old IEEE 1394 driver stack but could still be accessed by userspace drivers through the raw1394 interface. But with firewire-core, userspace drivers don't get to see such buggy devices anymore. This is effectively a driver regression since this device bug is otherwise harmless. We now attempt to scan all devices, even repeaters that don't have a link or powered-down devices that have everything but their PHY shut down when plugged in. This results in futile repeated scanning attempts in case of such devices that really don't have an active link, but this doesn't hurt since recent workqueue infrastructure lets us run more concurrent scanning jobs than we can shake a stick at. This should fix accessibility of Focusrite Saffire PRO 26 I/O: http://sourceforge.net/mailarchive/forum.php?thread_name=20110314215622.5c751bb0%40stein&forum_name=ffado-user Signed-off-by: Stefan Richter

firewire: sbp2: revert obsolete 'fix stall with "Unsolicited response"'

2011-03-20T15:45:24Z

Now that firewire-core sets the local node's SPLIT_TIMEOUT to 2 seconds per default, commit a481e97d3cdc40b9d58271675bd4f0abb79d4872 is no longer required. Signed-off-by: Stefan Richter

firewire: core: increase default SPLIT_TIMEOUT value

2011-03-20T15:45:24Z

The SPLIT_TIMEOUT mechanism is intended to detect requests that somehow got lost. However, when the timeout value is too low, transactions that could have been completed successfully will be cancelled. Furthermore, there are chips whose firmwares ignore the configured split timeout and send late split response; known examples are the DM1x00 (BeBoB), TCD22x0 (DICE), and some OXUF936QSE firmwares. This patch changes the default timeout to two seconds, which happens to be the default on other OSes, too. Actual lost requests are extremely rare, so there should be no practical downside to increasing the split timeout even on devices that work correctly. Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter

ALSA: add LaCie FireWire Speakers/Griffin FireWave Surround driver

2011-03-15T07:42:22Z

Add a driver for two playback-only FireWire devices based on the OXFW970 chip. v2: better AMDTP API abstraction; fix fw_unit leak; small fixes v3: cache the iPCR value v4: FireWave constraints; fix fw_device reference counting; fix PCR caching; small changes and fixes v5: volume/mute support; fix crashing due to pcm stop races v6: fix build; one-channel volume for LaCie v7: use signed values to make volume (range checks) work; fix function block IDs for volume/mute; always use channel 0 for LaCie volume Signed-off-by: Clemens Ladisch Acked-by: Stefan Richter Tested-by: Jay Fenlason Signed-off-by: Takashi Iwai

firewire: ohci: Misleading kfree in ohci.c::pci_probe/remove

2011-03-14T22:30:57Z

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 It is perhaps just a rudiment from before mainline submission of the driver. Signed-off-by: Stefan Richter