linux/drivers/firewire, branch v3.10.2

Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394

2013-05-09T17:11:48Z

Pull firewure updates from Stefan Richter: - fix controller removal when controller is in suspended state - fix video reception on VIA VT6306 with gstreamer, MythTV, and maybe dv4l - fix a startup issue with Agere/LSI FW643-e2 - error logging improvements and other small updates * tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: dump_stack() for PHY regs read/write failures firewire: ohci: Improve bus reset error messages firewire: ohci: Alias dev_* log functions firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8 firewire: ohci: fix VIA VT6306 video reception firewire: ohci: Check LPS before register access on pci removal firewire: ohci: Fix double free_irq() firewire: remove unnecessary alloc/OOM messages firewire: sbp2: replace BUG_ON by WARN_ON firewire: core: remove an always false test firewire: Remove two unneeded checks for macros

firewire: ohci: dump_stack() for PHY regs read/write failures

2013-04-30T18:30:16Z

A stack trace is an invaluable tool in determining the basis and cause of PHY regs read/write failures. Include PHY reg addr (and value for writes) in the diagnostic. [Stefan R: changed whitespace] Signed-off-by: Peter Hurley Signed-off-by: Stefan Richter

firewire: ohci: Improve bus reset error messages

2013-04-30T18:30:16Z

Many of the error messages possible from bus_reset_work() do not contain enough information to distinguish which error condition occurred nor enough information to evaluate the error afterwards. Differentiate all error conditions in bus_reset_work(); add additional information to make error diagnosis possible. [Stefan R: fixed self-ID endian conversion] Signed-off-by: Peter Hurley Signed-off-by: Stefan Richter

firewire: ohci: Alias dev_* log functions

2013-04-30T18:30:16Z

Convert dev_xxxx(ohci->card.device, ...) log functions to ohci_xxxx(ohci, ...). [Stefan R: Peter argues that this increases readability of the code.] [Stefan R: changed whitespace] Signed-off-by: Peter Hurley Signed-off-by: Stefan Richter

firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8

2013-04-30T18:30:15Z

With the LSI FW643 rev 8 [1], the first commanded bus reset at the conclusion of ohci_enable() has been observed to fail with the following messages: [ 4.884015] firewire_ohci 0000:01:00.0: failed to read phy reg .... [ 5.684012] firewire_ohci 0000:01:00.0: failed to read phy reg With drivers/firewire/ohci.c instrumented, the error condition [2] indicates the PHY arbitration state machine has timed out prior to enabling PHY LCtrl. Furthermore, instrumenting ohci_enable() shows that LPS has been enabled within 1 ms. Test LPS latching every 1 ms rather than every 50ms. [1] lspci -v 01:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08) (prog-if 10 [OHCI]) Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller Flags: bus master, fast devsel, latency 0, IRQ 92 Memory at fbeff000 (64-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 3 Capabilities: [4c] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [60] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [170] Device Serial Number 08-14-43-82-00-00-41-fc Kernel driver in use: firewire_ohci Kernel modules: firewire-ohci [2] instrumented WARNING in read_phy_reg() [ 4.576010] ------------[ cut here ]------------ [ 4.576035] WARNING: at ./drivers/firewire/ohci.c:570 read_phy_reg+0x93/0xe0 [firewire_ohci]() [ 4.576050] Hardware name: Precision WorkStation T5400 [ 4.576058] failed to read phy reg:1 (phy(5) @ config enhance:19) [ 4.576068] Modules linked in: hid_logitech_dj hid_generic(+) usbhid <...snip...> [ 4.576140] Pid: 61, comm: kworker/2:1 Not tainted 3.8.0-2+fwtest-xeon #2+fwtest [ 4.576149] Call Trace: [ 4.576160] [] warn_slowpath_common+0x7f/0xc0 [ 4.576168] [] warn_slowpath_fmt+0x46/0x50 [ 4.576178] [] read_phy_reg+0x93/0xe0 [firewire_ohci] [ 4.576188] [] ohci_read_phy_reg+0x39/0x60 [firewire_ohci] [ 4.576203] [] fw_send_phy_config+0xbf/0xe0 [firewire_core] [ 4.576214] [] br_work+0x46/0xb0 [firewire_core] [ 4.576225] [] process_one_work+0x13c/0x500 [ 4.576238] [] ? fw_card_initialize+0x180/0x180 [firewire_core] [ 4.576248] [] worker_thread+0x16d/0x470 [ 4.576257] [] ? busy_worker_rebind_fn+0x100/0x100 [ 4.576266] [] kthread+0xc0/0xd0 [ 4.576275] [] ? pcpu_dump_alloc_info+0x1cb/0x2c4 [ 4.576284] [] ? kthread_create_on_node+0x130/0x130 [ 4.576297] [] ret_from_fork+0x7c/0xb0 [ 4.576305] [] ? kthread_create_on_node+0x130/0x130 [ 4.576313] ---[ end trace cbc940994b300302 ]--- [Stefan R: Peter also reports a change of behavior with LSI FW323. Before the patch, there would often occur a lock transaction failure during firewire-core startup: [ 6.056022] firewire_core 0000:07:06.0: BM lock failed (timeout), making local node (ffc0) root This failure no longer happens after the patch, without an obvious reason for the failure or the fix.] [Stefan R: Added quirk flag, quirk table entry, and comment.] Reported-by: Tim Jordan Signed-off-by: Peter Hurley Signed-off-by: Stefan Richter

firewire: ohci: fix VIA VT6306 video reception

2013-04-28T21:36:44Z

Add quirk for VT6306 wake bit behavior. VT6306 seems to reread the wrong descriptor when the wake bit is written. work around by putting a copy of the branch address in the first descriptor of the block. [Stefan R: This fixes the known broken video reception via gstreamer on VIA VT6306. 100% repeatable testcase: $ gst-launch-0.10 dv1394src \! dvdemux \! dvdec \! xvimagesink with a camcorder or other DV source connected. Likewise for MPEG2-TS reception via gstreamer, e.g. from TV settop boxes. Perhaps this also fixes dv4l on VT6306, but this is as yet untested. Kino, dvgrab or FFADO had not been affected by this chip quirk. Additional comments from Andy:] I've looked into some problems with the wake bit on a vt6306 family chip (1106:3044, rev 46). I used this firewire card in a mythtv setup (ISO receive MPEG2 stream) with Debian 2.6.32 kernels for ~2 years without problems. Since upgrading to 3.2, I've been having problems with the input stream freezing -- input data stops until I restart mythtv (I expect closing and reopening the device would be sufficient). This happens infrequently, maybe one out of 20 recordings. I eventually determined that the problem is more likely to occur if the system is loaded. I isolated the kernel version as the triggering SW factor and then specifically the change from dualbuffer back to packet-per-buffer DMA mode. The possibility that the controller does not properly respond to the wake bit was suggested in https://bugzilla.redhat.com/show_bug.cgi?id=415841, but not proven. Based on the fact that dualbuffer mode worked while packet-per-buffer has trouble, I guessed that upon seeing the wake bit written, the vt6306 controller only checks the branch address in the first descriptor of the block, even if that is not the correct place to look (because the block has multiple descriptors). This theory seems to be correct. When the ISO reception is hung, I am able to resume it by manually writing the branch address to the first descriptor in the block, and then writing the wake bit. I've had luck so far with the attached patch, so I'm including it. It's probably not a complete solution -- I haven't tested transmit modes to see whether they have a similar issue. I doubt that the quirk test is any cheaper than just writing the extra branch address in all cases, but it does reduce the risk of breaking other hardware. [Stefan R: omitted QUIRK_NO_MSI from VT6306 quirks table entry, changed whitespace] Signed-off-by: Andy Leiserson Signed-off-by: Stefan Richter

firewire: ohci: Check LPS before register access on pci removal

2013-04-28T21:36:44Z

A pci device can be removed while in its suspended state. If the ohci host controller is suspended, the PHY is also in low-power mode and LPS is disabled. If LPS is disabled, most of the host registers aren't accessible, including IntMaskClear. Furthermore, access to these registers when LPS is disabled can cause hard lockups on some hardware. Since interrupts are already disabled in this mode, further action is unnecessary. Test LPS before attempting to write IntMaskClear to disable interrupts. [Stefan R: whitespace changes] Signed-off-by: Peter Hurley Signed-off-by: Stefan Richter

firewire: ohci: Fix double free_irq()

2013-04-28T21:36:44Z

A pci device can be removed while in its suspended state. Because the ohci driver freed the irq to suspend, free_irq() is called twice; once from pci_remove() and again from pci_suspend(), which issues the warning below [1]. Rather than allocate the irq in the .enable() path, move the allocation to .probe(). Consequently, the irq is not reallocated upon pci_resume() and thus is not freed upon pci_suspend(). [1] Warning reported by Mark Einon when suspending an MSI MS-1727 GT740 laptop on Ubuntu 3.5.0-22-generic WARNING: at ./kernel/irq/manage.c:1198 __free_irq+0xa3/0x1e0() Hardware name: MS-1727 Trying to free already-free IRQ 16 Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables <...snip...> Pid: 4, comm: kworker/0:0 Tainted: P O 3.5.0-22-generic #34-Ubuntu Call Trace: [] warn_slowpath_common+0x7f/0xc0 [] warn_slowpath_fmt+0x46/0x50 [] ? default_spin_lock_flags+0x9/0x10 [] __free_irq+0xa3/0x1e0 [] free_irq+0x54/0xc0 [] pci_remove+0x6e/0x210 [firewire_ohci] [] pci_device_remove+0x3f/0x110 [] __device_release_driver+0x7c/0xe0 [] device_release_driver+0x2c/0x40 [] bus_remove_device+0xe1/0x120 [] device_del+0x12a/0x1c0 [] device_unregister+0x16/0x30 [] pci_stop_bus_device+0x94/0xa0 [] acpiphp_disable_slot+0xb7/0x1a0 [acpiphp] [] ? get_slot_status+0x46/0xc0 [acpiphp] [] acpiphp_check_bridge.isra.15+0x2d/0xf0 [acpiphp] [] _handle_hotplug_event_bridge+0x372/0x4d0 [acpiphp] [] ? acpi_os_execute_deferred+0x2f/0x34 [] ? kfree+0xed/0x110 [] process_one_work+0x12a/0x420 [] ? _handle_hotplug_event_func+0x1d0/0x1d0 [acpiphp] [] worker_thread+0x12e/0x2f0 [] ? manage_workers.isra.26+0x200/0x200 [] kthread+0x93/0xa0 [] kernel_thread_helper+0x4/0x10 [] ? kthread_freezable_should_stop+0x70/0x70 [] ? gs_change+0x13/0x13 Reported-by: Mark Einon Signed-off-by: Peter Hurley Signed-off-by: Stefan Richter

firewire: remove unnecessary alloc/OOM messages

2013-04-28T21:36:44Z

These are redundant to log messages from the mm core. Signed-off-by: Stefan Richter

firewire: sbp2: replace BUG_ON by WARN_ON

2013-04-28T21:36:44Z

No need to crash and burn if S/G element sizes cannot be set to our liking; just leave a message in the log. Signed-off-by: Stefan Richter