summaryrefslogtreecommitdiff
path: root/drivers/firewire (unfollow)
Commit message (Collapse)Author
2021-04-07firewire: nosy: Fix a use-after-free bug in nosy_ioctl()Zheyu Ma
[ Upstream commit 829933ef05a951c8ff140e814656d73e74915faf ] For each device, the nosy driver allocates a pcilynx structure. A use-after-free might happen in the following scenario: 1. Open nosy device for the first time and call ioctl with command NOSY_IOC_START, then a new client A will be malloced and added to doubly linked list. 2. Open nosy device for the second time and call ioctl with command NOSY_IOC_START, then a new client B will be malloced and added to doubly linked list. 3. Call ioctl with command NOSY_IOC_START for client A, then client A will be readded to the doubly linked list. Now the doubly linked list is messed up. 4. Close the first nosy device and nosy_release will be called. In nosy_release, client A will be unlinked and freed. 5. Close the second nosy device, and client A will be referenced, resulting in UAF. The root cause of this bug is that the element in the doubly linked list is reentered into the list. Fix this bug by adding a check before inserting a client. If a client is already in the linked list, don't insert it. The following KASAN report reveals it: BUG: KASAN: use-after-free in nosy_release+0x1ea/0x210 Write of size 8 at addr ffff888102ad7360 by task poc CPU: 3 PID: 337 Comm: poc Not tainted 5.12.0-rc5+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: nosy_release+0x1ea/0x210 __fput+0x1e2/0x840 task_work_run+0xe8/0x180 exit_to_user_mode_prepare+0x114/0x120 syscall_exit_to_user_mode+0x1d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 337: nosy_open+0x154/0x4d0 misc_open+0x2ec/0x410 chrdev_open+0x20d/0x5a0 do_dentry_open+0x40f/0xe80 path_openat+0x1cf9/0x37b0 do_filp_open+0x16d/0x390 do_sys_openat2+0x11d/0x360 __x64_sys_open+0xfd/0x1a0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 337: kfree+0x8f/0x210 nosy_release+0x158/0x210 __fput+0x1e2/0x840 task_work_run+0xe8/0x180 exit_to_user_mode_prepare+0x114/0x120 syscall_exit_to_user_mode+0x1d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff888102ad7300 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 96 bytes inside of 128-byte region [ffff888102ad7300, ffff888102ad7380) [ Modified to use 'list_empty()' inside proper lock - Linus ] Link: https://lore.kernel.org/lkml/1617433116-5930-1-git-send-email-zheyuma97@gmail.com/ Reported-and-tested-by: 马哲宇 (Zheyu Ma) <zheyuma97@gmail.com> Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-12net: add annotations on hh->hh_len lockless accessesEric Dumazet
[ Upstream commit c305c6ae79e2ce20c22660ceda94f0d86d639a82 ] KCSAN reported a data-race [1] While we can use READ_ONCE() on the read sides, we need to make sure hh->hh_len is written last. [1] BUG: KCSAN: data-race in eth_header_cache / neigh_resolve_output write to 0xffff8880b9dedcb8 of 4 bytes by task 29760 on cpu 0: eth_header_cache+0xa9/0xd0 net/ethernet/eth.c:247 neigh_hh_init net/core/neighbour.c:1463 [inline] neigh_resolve_output net/core/neighbour.c:1480 [inline] neigh_resolve_output+0x415/0x470 net/core/neighbour.c:1470 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] NF_HOOK include/linux/netfilter.h:305 [inline] ndisc_send_skb+0x459/0x5f0 net/ipv6/ndisc.c:505 ndisc_send_ns+0x207/0x430 net/ipv6/ndisc.c:647 rt6_probe_deferred+0x98/0xf0 net/ipv6/route.c:615 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269 worker_thread+0xa0/0x800 kernel/workqueue.c:2415 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 read to 0xffff8880b9dedcb8 of 4 bytes by task 29572 on cpu 1: neigh_resolve_output net/core/neighbour.c:1479 [inline] neigh_resolve_output+0x113/0x470 net/core/neighbour.c:1470 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] NF_HOOK include/linux/netfilter.h:305 [inline] ndisc_send_skb+0x459/0x5f0 net/ipv6/ndisc.c:505 ndisc_send_ns+0x207/0x430 net/ipv6/ndisc.c:647 rt6_probe_deferred+0x98/0xf0 net/ipv6/route.c:615 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269 worker_thread+0xa0/0x800 kernel/workqueue.c:2415 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 29572 Comm: kworker/1:4 Not tainted 5.4.0-rc6+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events rt6_probe_deferred Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-05-30firewire-ohci: work around oversized DMA reads on JMicron controllersHector Martin
[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ] At least some JMicron controllers issue buggy oversized DMA reads when fetching context descriptors, always fetching 0x20 bytes at once for descriptors which are only 0x10 bytes long. This is often harmless, but can cause page faults on modern systems with IOMMUs: DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read This works around the problem by always leaving 0x10 padding bytes at the end of descriptor buffer pages, which should be harmless to do unconditionally for controllers in case others have the same behavior. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10firewire: net: fix fragmented datagram_size off-by-oneStefan Richter
commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream. RFC 2734 defines the datagram_size field in fragment encapsulation headers thus: datagram_size: The encoded size of the entire IP datagram. The value of datagram_size [...] SHALL be one less than the value of Total Length in the datagram's IP header (see STD 5, RFC 791). Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got this field with a -/+1 offset: ether1394_tx() /* transmit */ ether1394_encapsulate_prep() hdr->ff.dg_size = dg_size - 1; ether1394_data_handler() /* receive */ if (hdr->common.lf == ETH1394_HDR_LF_FF) dg_size = hdr->ff.dg_size + 1; else dg_size = hdr->sf.dg_size + 1; Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500 byte sized datagrams in fragments with datagram_size=1499 if link fragmentation is required. Only firewire-net sets and gets datagram_size without this offset. The result is lacking interoperability of firewire-net with OS X, Windows XP, and presumably Linux' eth1394. (I did not test with the latter.) For example, FTP data transfers to a Linux firewire-net box with max_rec smaller than the 1500 bytes MTU - from OS X fail entirely, - from Win XP start out with a bunch of fragmented datagrams which time out, then continue with unfragmented datagrams because Win XP temporarily reduces the MTU to 576 bytes. So let's fix firewire-net's datagram_size accessors. Note that firewire-net thereby loses interoperability with unpatched firewire-net, but only if link fragmentation is employed. (This happens with large broadcast datagrams, and with large datagrams on several FireWire CardBus cards with smaller max_rec than equivalent PCI cards, and it can be worked around by setting a small enough MTU.) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10firewire: net: guard against rx buffer overflowsStefan Richter
commit 667121ace9dbafb368618dbabcf07901c962ddac upstream. The IP-over-1394 driver firewire-net lacked input validation when handling incoming fragmented datagrams. A maliciously formed fragment with a respectively large datagram_offset would cause a memcpy past the datagram buffer. So, drop any packets carrying a fragment with offset + length larger than datagram_size. In addition, ensure that - GASP header, unfragmented encapsulation header, or fragment encapsulation header actually exists before we access it, - the encapsulated datagram or fragment is of nonzero size. Reported-by: Eyal Itkin <eyal.itkin@gmail.com> Reviewed-by: Eyal Itkin <eyal.itkin@gmail.com> Fixes: CVE 2016-8633 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-06mm, page_alloc: distinguish between being unable to sleep, unwilling to ↵Mel Gorman
sleep and avoiding waking kswapd __GFP_WAIT has been used to identify atomic context in callers that hold spinlocks or are in interrupts. They are expected to be high priority and have access one of two watermarks lower than "min" which can be referred to as the "atomic reserve". __GFP_HIGH users get access to the first lower watermark and can be called the "high priority reserve". Over time, callers had a requirement to not block when fallback options were available. Some have abused __GFP_WAIT leading to a situation where an optimisitic allocation with a fallback option can access atomic reserves. This patch uses __GFP_ATOMIC to identify callers that are truely atomic, cannot sleep and have no alternative. High priority users continue to use __GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and are willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify callers that want to wake kswapd for background reclaim. __GFP_WAIT is redefined as a caller that is willing to enter direct reclaim and wake kswapd for background reclaim. This patch then converts a number of sites o __GFP_ATOMIC is used by callers that are high priority and have memory pools for those requests. GFP_ATOMIC uses this flag. o Callers that have a limited mempool to guarantee forward progress clear __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall into this category where kswapd will still be woken but atomic reserves are not used as there is a one-entry mempool to guarantee progress. o Callers that are checking if they are non-blocking should use the helper gfpflags_allow_blocking() where possible. This is because checking for __GFP_WAIT as was done historically now can trigger false positives. Some exceptions like dm-crypt.c exist where the code intent is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to flag manipulations. o Callers that built their own GFP flags instead of starting with GFP_KERNEL and friends now also need to specify __GFP_KSWAPD_RECLAIM. The first key hazard to watch out for is callers that removed __GFP_WAIT and was depending on access to atomic reserves for inconspicuous reasons. In some cases it may be appropriate for them to use __GFP_HIGH. The second key hazard is callers that assembled their own combination of GFP flags instead of starting with something like GFP_KERNEL. They may now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless if it's missed in most cases as other activity will wake kswapd. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes <rientjes@google.com> Cc: Vitaly Wool <vitalywool@gmail.com> Cc: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-11-05firewire: ohci: fix JMicron JMB38x IT context discoveryStefan Richter
Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo controllers: Often or even most of the time, the controller is initialized with the message "added OHCI v1.10 device as card 0, 4 IR + 0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts (IT contexts), applications like audio output are impossible. However, OHCI-1394 demands that at least 4 IT contexts are implemented by the link layer controller, and indeed JMicron JMB38x do implement four of them. Only their IsoXmitIntMask register is unreliable at early access. With my own JMB381 single function controller I found: - I can reproduce the problem with a lower probability than Craig's. - If I put a loop around the section which clears and reads IsoXmitIntMask, then either the first or the second attempt will return the correct initial mask of 0x0000000f. I never encountered a case of needing more than a second attempt. - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet) before the first write, the subsequent read will return the correct result. - If I merely ignore a wrong read result and force the known real result, later isochronous transmit DMA usage works just fine. So let's just fix this chip bug up by the latter method. Tested with JMB381 on kernel 3.13 and 4.3. Since OHCI-1394 generally requires 4 IT contexts at a minium, this workaround is simply applied whenever the initial read of IsoXmitIntMask returns 0, regardless whether it's a JMicron chip or not. I never heard of this issue together with any other chip though. I am not 100% sure that this fix works on the OHCI-1394 part of JMB380 and JMB388 combo controllers exactly the same as on the JMB381 single- function controller, but so far I haven't had a chance to let an owner of a combo chip run a patched kernel. Strangely enough, IsoRecvIntMask is always reported correctly, even though it is probed right before IsoXmitIntMask. Reported-by: Clifford Dunn Reported-by: Craig Moore <craig.moore@qenos.com> Cc: stable@vger.kernel.org Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2015-05-31scsi: Do not set cmd_per_lun to 1 in the host templateHannes Reinecke
'0' is now used as the default cmd_per_lun value, so there's no need to explicitly set it to '1' in the host template. Signed-off-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <JBottomley@Odin.com>
2015-03-02net: Kill dev_rebuild_headerEric W. Biederman
Now that there are no more users kill dev_rebuild_header and all of it's implementations. This is long overdue. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-02firewire: core: use correct vendor/model IDsClemens Ladisch
The kernel was using the vendor ID 0xd00d1e, which was inherited from the old ieee1394 driver stack. However, this ID was not registered, and invalid. Instead, use the vendor/model IDs that are now officially assigned to the kernel: https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments [stefanr: - The vendor ID 001f11 is Openmoko, Inc.'s identifier, registered at IEEE Registration Authority. - The range of model IDs 023900...0239ff are the Linux kernel 1394 subsystem's identifiers, registered at Openmoko. - Model ID 023901 is picked by the subsystem developers as firewire-core's model ID.] Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2015-01-31firewire: sbp2: remove redundant check for bidi commandStefan Richter
[Bart van Asche:] SCSI core never sets cmd->sc_data_direction to DMA_BIDIRECTIONAL; scsi_bidi_cmnd(cmd) should be used instead to test for a bidirectional command. [Christoph Hellwig:] Bidirectional commands won't ever be queued anyway, unless a LLD or transport driver sets QUEUE_FLAG_BIDI. So, simply remove the respective queuecommand check in the SBP-2 transport driver. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2015-01-22firewire: ohci: Remove unused functionRickard Strandqvist
Remove the function ar_prev_buffer_index() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-12-10firewire: sbp2: replace card lock by target lockStefan Richter
firewire-core uses fw_card.lock to protect topology data and transaction data. firewire-sbp2 uses fw_card.lock for entirely unrelated purposes. Introduce a sbp2_target.lock to firewire-sbp2 and replace all fw_card.lock uses in the driver. fw_card.lock is now entirely private to firewire-core. This has no immediate advantage apart from making it clear in the code that firewire-sbp2 does not interact with the core via the core lock. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-12-10firewire: sbp2: replace some spin_lock_irqsave by spin_lock_irqStefan Richter
Users of card->lock Calling context ------------------------------------------------------------------------ sbp2_status_write AR-req handler, tasklet complete_transaction AR-resp or AT-req handler, tasklet sbp2_send_orb among else scsi host .queuecommand, which may be called in some sort of atomic context sbp2_cancel_orbs sbp2_send_management_orb/ sbp2_{login,reconnect,remove}, worklet or process sbp2_scsi_abort, scsi eh thread sbp2_allow_block sbp2_login, worklet sbp2_conditionally_block among else complete_command_orb, tasklet sbp2_conditionally_unblock sbp2_{login,reconnect}, worklet sbp2_unblock sbp2_{login,remove}, worklet or process Drop the IRQ flags saving from sbp2_cancel_orbs, sbp2_conditionally_unblock, and sbp2_unblock. It was already omitted in sbp2_allow_block. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-12-10firewire: sbp2: protect a reference counter properlyStefan Richter
The assertion in the comment in sbp2_allow_block() is no longer true. Or maybe it never was true. At least now, the sole caller of sbp2_allow_block(), sbp2_login, can run concurrently to one of sbp2_unblock()'s callers, sbp2_remove. sbp2_login is performed by sbp2_logical_unit.work. sbp2_remove is performed by fw_device.work. sbp2_remove cancels sbp2_logical_unit.work, but only after it called sbp2_unblock. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-12-10firewire: core: document fw_csr_string's truncation of long stringsStefan Richter
fw_csr_string() truncates and terminates target strings like strlcpy() does. Unlike strlcpy(), it returns the target strlen, not the source strlen, hence users of fw_csr_string() are unable to detect truncation. Point this behavior out in the kerneldoc comment. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2014-11-19firewire: ohci: replace vm_map_ram() with vmap()Clemens Ladisch
vm_map_ram() is intended for short-lived objects, so using it for the AR buffers could fragment address space, especially on a 32-bit machine. For an allocation that lives as long as the device, vmap() is the better choice. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-11-14firewire: cdev: prevent kernel stack leaking into ioctl argumentsStefan Richter
Found by the UC-KLEE tool: A user could supply less input to firewire-cdev ioctls than write- or write/read-type ioctl handlers expect. The handlers used data from uninitialized kernel stack then. This could partially leak back to the user if the kernel subsequently generated fw_cdev_event_'s (to be read from the firewire-cdev fd) which notably would contain the _u64 closure field which many of the ioctl argument structures contain. The fact that the handlers would act on random garbage input is a lesser issue since all handlers must check their input anyway. The fix simply always null-initializes the entire ioctl argument buffer regardless of the actual length of expected user input. That is, a runtime overhead of memset(..., 40) is added to each firewirew-cdev ioctl() call. [Comment from Clemens Ladisch: This part of the stack is most likely to be already in the cache.] Remarks: - There was never any leak from kernel stack to the ioctl output buffer itself. IOW, it was not possible to read kernel stack by a read-type or write/read-type ioctl alone; the leak could at most happen in combination with read()ing subsequent event data. - The actual expected minimum user input of each ioctl from include/uapi/linux/firewire-cdev.h is, in bytes: [0x00] = 32, [0x05] = 4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16, [0x01] = 36, [0x06] = 20, [0x0b] = 4, [0x10] = 20, [0x15] = 20, [0x02] = 20, [0x07] = 4, [0x0c] = 0, [0x11] = 0, [0x16] = 8, [0x03] = 4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12, [0x04] = 20, [0x09] = 24, [0x0e] = 4, [0x13] = 40, [0x18] = 4. Reported-by: David Ramos <daramos@stanford.edu> Cc: <stable@vger.kernel.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-07-23firewire: ohci: disable MSI for VIA VT6315 againStefan Richter
Revert half of commit d151f9854f21: If isochronous I/O is attempted with packets larget than 1 kByte, VIA VT6315 rev 01 immediately stops to generate any interrupts if MSI are used. Fix this by going back to legacy interrupts. [Thread "Isochronous streaming with VT6315 OHCI", http://marc.info/?t=139049641500003] With smaller packets, the loss of IRQs happens too but only very rarely --- rarely eneough that it was not yet possible for me to determine whether QUIRK_NO_MSI is an actual fix for this rare variation of this chip bug. I am keeping QUIRK_CYCLE_TIMER off of VT6315 rev >= 1 because this has been verified by myself with certainty. On the other hand, I am also keeping QUIRK_CYCLE_TIMER on for VT6315 rev 0 because I don't know at this time whether this revision accesses Cycle Timer non-atomically like most of the other VIA OHCIs are known to do. Reported-by: Rémy Bruno <remy-fw@remy.trinnov.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-07-15net: set name_assign_type in alloc_netdev()Tom Gundersen
Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert all users to pass NET_NAME_UNKNOWN. Coccinelle patch: @@ expression sizeof_priv, name, setup, txqs, rxqs, count; @@ ( -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs) +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs) | -alloc_netdev_mq(sizeof_priv, name, setup, count) +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count) | -alloc_netdev(sizeof_priv, name, setup) +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup) ) v9: move comments here from the wrong commit Signed-off-by: Tom Gundersen <teg@jklm.no> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-13firewire: IEEE 1394 (FireWire) support should depend on HAS_DMAGeert Uytterhoeven
Commit b3d681a4fc108f9653bbb44e4f4e72db2b8a5734 ("firewire: Use COMPILE_TEST for build testing") added COMPILE_TEST as an alternative dependency for the purpose of build testing the firewire core. However, this bypasses all other implicit dependencies assumed by PCI, like HAS_DMA. If NO_DMA=y: drivers/built-in.o: In function `fw_iso_buffer_destroy': (.text+0x36a096): undefined reference to `dma_unmap_page' drivers/built-in.o: In function `fw_iso_buffer_map_dma': (.text+0x36a164): undefined reference to `dma_map_page' drivers/built-in.o: In function `fw_iso_buffer_map_dma': (.text+0x36a172): undefined reference to `dma_mapping_error' drivers/built-in.o: In function `sbp2_send_management_orb': sbp2.c:(.text+0x36c6b4): undefined reference to `dma_map_single' sbp2.c:(.text+0x36c6c8): undefined reference to `dma_mapping_error' sbp2.c:(.text+0x36c772): undefined reference to `dma_map_single' sbp2.c:(.text+0x36c786): undefined reference to `dma_mapping_error' sbp2.c:(.text+0x36c854): undefined reference to `dma_unmap_single' sbp2.c:(.text+0x36c872): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `sbp2_map_scatterlist': sbp2.c:(.text+0x36ccbc): undefined reference to `scsi_dma_map' sbp2.c:(.text+0x36cd36): undefined reference to `dma_map_single' sbp2.c:(.text+0x36cd4e): undefined reference to `dma_mapping_error' sbp2.c:(.text+0x36cd84): undefined reference to `scsi_dma_unmap' drivers/built-in.o: In function `sbp2_unmap_scatterlist': sbp2.c:(.text+0x36cda6): undefined reference to `scsi_dma_unmap' sbp2.c:(.text+0x36cdc6): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `complete_command_orb': sbp2.c:(.text+0x36d6ac): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `sbp2_scsi_queuecommand': sbp2.c:(.text+0x36d8e0): undefined reference to `dma_map_single' sbp2.c:(.text+0x36d8f6): undefined reference to `dma_mapping_error' Add an explicit dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-06-12firewire: Use ktime_get_ts()Thomas Gleixner
do_posix_clock_monotonic_gettime() is a leftover from the initial posix timer implementation which maps to ktime_get_ts() Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Link: http://lkml.kernel.org/r/20140611234607.351283464@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-05-29firewire: ohci: enable MSI for VIA VT6315 rev 1, drop cycle timer quirkStefan Richter
Commit af0cdf494781 "firewire: ohci: fix regression with VIA VT6315, disable MSI" acted upon a report against VT6315 rev 0: http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02301.html $ lspci -nn VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] I now got a card with $ lspci -nn VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] (rev 01) and this works fine with MSI enabled. Second, I tested this VT6315 rev 1 without CYCLE_TIMER quirk flag using http://me.in-berlin.de/~s5r6/linux1394/utils/test_cycle_time_v20100125.c and found that this chip does in fact access the cycle timer atomically. Things I can't test because I don't have the hardware: - whether VT6315 rev 0 really needs QUIRK_CYCLE_TIMER, - whether the VT6320 PCI device needs QUIRK_CYCLE_TIMER, - whether the VT6325 and VT6330 PCIe devices need QUIRK_CYCLE_TIMER and QUIRK_NO_MSI. Hence, just add a whitelist entry specifically for VT6315 rev >= 1 without any quirk flags. Before this entry we need an extra entry to catch VT6315 rev <= 0 due to how our ID matching logic works. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-05-29firewire: revert to 4 GB RDMA, fix protocols using Memory SpaceStefan Richter
Undo a feature introduced in v3.14 by commit fcd46b34425d "firewire: Enable remote DMA above 4 GB". That change raised the minimum address at which protocol drivers and user programs can register for request reception from 0x0001'0000'0000 to 0x8000'0000'0000. It turned out that at least one vendor-specific protocol exists which uses lower addresses: https://bugzilla.kernel.org/show_bug.cgi?id=76921 For the time being, revert most of commit fcd46b34425d so that affected protocols work like with kernel v3.13 and before. Just keep the valid documentation parts from the regressing commit, and the ability to identify controllers which could be programmed to accept >32 bit physical DMA addresses. The rest of fcd46b34425d should probably be brought back as an optional instead of default feature. Reported-by: Fabien Spindler <fabien.spindler@inria.fr> Cc: <stable@vger.kernel.org> # 3.14+ Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-05-26ALSA: firewire/bebob: Add a workaround for M-Audio special Firewire seriesTakashi Sakamoto
In post commit, a quirk of this firmware about transactions is reported. This commit apply a workaround for this quirk. They often fail transactions due to gap_count mismatch. This state is changed by generating bus reset. The fw_schedule_bus_reset() is an exported symbol in firewire-core. But there are no header for public. This commit moves its prototype from drivers/firewire/core.h to include/linux/firewire.h. This mismatch still affects bus management before generating this bus reset. It still takes a time to call driver's probe() because transactions are still often failed. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-05-17firewire: Use COMPILE_TEST for build testingJean Delvare
Stop using BROKEN as an alternative dependency for the purpose of build testing the firewire core. The newly introduced COMPILE_TEST is better suited for that purpose. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-05-12firewire: net: fix NULL derefencing in fwnet_probe()Daeseok Youn
"dev" and "net" are NULL when alloc_netdev() is failed. So just unlock and return an error. Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-04-18arch: Mass conversion of smp_mb__*()Peter Zijlstra
Mostly scripted conversion of the smp_mb__* barriers. Signed-off-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-arch@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-03-07firewire: don't use PREPARE_DELAYED_WORKTejun Heo
PREPARE_[DELAYED_]WORK() are being phased out. They have few users and a nasty surprise in terms of reentrancy guarantee as workqueue considers work items to be different if they don't have the same work function. firewire core-device and sbp2 have been been multiplexing work items with multiple work functions. Introduce fw_device_workfn() and sbp2_lu_workfn() which invoke fw_device->workfn and sbp2_logical_unit->workfn respectively and always use the two functions as the work functions and update the users to set the ->workfn fields instead of overriding work functions using PREPARE_DELAYED_WORK(). This fixes a variety of possible regressions since a2c1c57be8d9 "workqueue: consider work function when searching for busy work items" due to which fw_workqueue lost its required non-reentrancy property. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: linux1394-devel@lists.sourceforge.net Cc: stable@vger.kernel.org # v3.9+ Cc: stable@vger.kernel.org # v3.8.2+ Cc: stable@vger.kernel.org # v3.4.60+ Cc: stable@vger.kernel.org # v3.2.40+
2014-03-06firewire: ohci: fix probe failure with Agere/LSI controllersStefan Richter
Since commit bd972688eb24 "firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8", there is a high chance that firewire-ohci fails to initialize LSI née Agere controllers. https://bugzilla.kernel.org/show_bug.cgi?id=65151 Peter Hurley points out the reason: IEEE 1394a:2000 clause 5A.1 (or IEEE 1394:2008 clause 17.2.1) say: "The PHY shall insure that no more than 10 ms elapse from the reassertion of LPS until the interface is reset. The link shall not assert LReq until the reset is complete." In other words, the link needs to give the PHY at least 10 ms to get the interface operational. With just the msleep(1) in bd972688eb24, the first read_phy_reg() during ohci_enable() may happen before the phy-link interface reset was finished, and fail. Due to the high variability of msleep(n) with small n, this failure was not fully reproducible, and not apparent at all with low CONFIG_HZ setting. On the other hand, Peter can no longer reproduce the issue with FW643 rev8. The read phy reg failures that happened back then may have had an unrelated cause. So, just revert bd972688eb24, except for the valid comment on TSB82AA2 cards. Reported-by: Mikhail Gavrilov Reported-by: Jay Fenlason <fenlason@redhat.com> Reported-by: Clemens Ladisch <clemens@ladisch.de> Reported-by: Peter Hurley <peter@hurleysoftware.com> Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-02-28firewire: net: fix use after freeStefan Richter
Commit 8408dc1c14c1 "firewire: net: use dev_printk API" introduced a use-after-free in a failure path. fwnet_transmit_packet_failed(ptask) may free ptask, then the dev_err() call dereferenced it. The fix is straightforward; simply reorder the two calls. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@vger.kernel.org # v3.4+ Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-01-20firewire: Enable remote DMA above 4 GBStefan Richter
This makes all of a machine's memory accessible to remote debugging via FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link layer controllers. This requires actual support by the controller. The only ones currently known to support it are Agere/LSI FW643. Most if not all other OHCI-1394 controllers do not implement the optional Physical Upper Bound register. With them, RDMA will continue to be limited to the lowermost 4 GB. firewire-ohci's startup message in the kernel log is augmented to tell whether the controller does expose more than 4 GB to RDMA. While OHCI-1394 allows for a maximum Physical Upper Bound of 0xffff'0000'0000 (near 256 TB), this implementation sets it to 0x8000'0000'0000 (128 TB) in order to avoid interference with applications that require interrupt-served asynchronous request reception at respectively low addresses. Note, this change does not switch remote DMA on. It only increases the range of remote access to all memory (instead of just 4 GB) whenever remote DMA was switched on by other means. The latter is achieved by setting firewire-ohci's remote_dma parameter, or if the physical DMA filter is opened through firewire-sbp2. Derived from patch "firewire: Enable physical DMA above 4GB" by Peter Hurley <peter@hurleysoftware.com> from March 27, 2013. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-01-12firewire: ohci: Turn remote DMA support into a module parameterLubomir Rintel
This makes it possible to debug kernel over FireWire without the need to recompile it. [Stefan R: changed description from "...0" to "...N"] Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-12-15firewire: sbp2: bring back WRITE SAME supportStefan Richter
Commit 54b2b50c20a6 "[SCSI] Disable WRITE SAME for RAID and virtual host adapter drivers" disabled WRITE SAME support for all SBP-2 attached targets. But as described in the changelog of commit b0ea5f19d3d8 "firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES", it is not required to blacklist WRITE SAME. Bring the feature back by reverting the sbp2.c hunk of commit 54b2b50c20a6. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: stable@kernel.org
2013-11-29[SCSI] Disable WRITE SAME for RAID and virtual host adapter driversMartin K. Petersen
Some host adapters do not pass commands through to the target disk directly. Instead they provide an emulated target which may or may not accurately report its capabilities. In some cases the physical device characteristics are reported even when the host adapter is processing commands on the device's behalf. This can lead to adapter firmware hangs or excessive I/O errors. This patch disables WRITE SAME for devices connected to host adapters that provide an emulated target. Driver writers can disable WRITE SAME by setting the no_write_same flag in the host adapter template. [jejb: fix up rejections due to eh_deadline patch] Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Cc: stable@kernel.org Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2013-11-15tree-wide: use reinit_completion instead of INIT_COMPLETIONWolfram Sang
Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. [akpm@linux-foundation.org: linux-next resyncs] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-08-29firewire: ohci: Fix deadlock at bus resetStephan Gatzka
Put bus_reset_work into its own workqueue. By doing this, forward progress of bus_reset_work() is guaranteed if the work is switched over to a rescuer thread. Switching work to a rescuer thread happens if a new worker thread could not be allocated in certain time (MAYDAY_INITIAL_TIMEOUT, typically 10 ms). This might not be possible under high memory pressure or even on a heavily loaded embedded system running a slow serial console. The former deadlock occured in the following situation: The rescuer thread ran fw_device_init->read_config_rom->read_rom->fw_run_transaction. fw_run_transaction blocked waiting for the completion object. This completion object would have been completed in bus_reset_work, but this work was never executed in the rescuer thread due to its strictly sequential behaviour. [Stefan R.: Removed WQ_NON_REENTRANT flag from allocation because it is no longer needed in current kernels. Add it back if you backport to kernels older than 3.7, i.e. one which does not contain dbf2576e37da "workqueue: make all workqueues non-reentrant". Swapped order of destroy_workqueue and pci_unregister_driver.] Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-08-29firewire: ohci: Change module_pci_driver to module_init/module_exitStephan Gatzka
This is a prerequisite to allocate a per driver self_id workqueue. This reverts the ohci.c part of patch fe2af11c220c7bb3a67f7aec0594811e5c59e019. Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-08-19firewire: ohci: beautify some macro definitionsStefan Richter
a) Sort device IDs by vendor -- device -- revision. b) Write quirk flags in hexadecimal. This affects the user-visible output of "modinfo firewire-ohci". Since more flags have been added recently, it is now easier to cope with them in hexadecimal represen- tation. Besides, the device-specific combination of quirk flags is shown in hexadecimal in the kernel log too. (And firewire-sbp2 presents its own quirk flags in modinfo as hexadecimals as well.) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-08-19firewire: ohci: change confusing name of a struct memberStefan Richter
We have got struct descriptor *descriptors; dma_addr_t descriptors_bus; dma_addr_t buffer_bus; struct descriptor buffer[0]; void *misc_buffer; dma_addr_t misc_buffer_bus; __be32 *config_rom; dma_addr_t config_rom_bus; __be32 *next_config_rom; dma_addr_t next_config_rom_bus; But then we have got __le32 *self_id_cpu; dma_addr_t self_id_bus; Better apply the pattern of xyz vs. xyz_bus to self_id vs. self_id_bus as well. The _cpu suffix looks particularly weird in conversions from little endian to CPU endian. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-07-30firewire: core: typecast from gfp_t to bool more safelyStefan Richter
An idr related patch introduced the following sparse warning: drivers/firewire/core-cdev.c:488:33: warning: incorrect type in initializer (different base types) drivers/firewire/core-cdev.c:488:33: expected bool [unsigned] [usertype] preload drivers/firewire/core-cdev.c:488:33: got restricted gfp_t So let's convert from gfp_t bitfield to Boolean explicitly and safely. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-07-30firewire: WQ_NON_REENTRANT is meaningless and going awayTejun Heo
dbf2576e37 ("workqueue: make all workqueues non-reentrant") made WQ_NON_REENTRANT no-op and the flag is going away. Remove its usages. This patch doesn't introduce any behavior changes. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-07-27firewire: fix libdc1394/FlyCap2 iso event regressionClemens Ladisch
Commit 18d627113b83 (firewire: prevent dropping of completed iso packet header data) was intended to be an obvious bug fix, but libdc1394 and FlyCap2 depend on the old behaviour by ignoring all returned information and thus not noticing that not all packets have been received yet. The result was that the video frame buffers would be saved before they contained the correct data. Reintroduce the old behaviour for old clients. Tested-by: Stepan Salenikovich <stepan.salenikovich@gmail.com> Tested-by: Josep Bosch <jep250@gmail.com> Cc: <stable@vger.kernel.org> # 3.4+ Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-06-09firewire: remove support of fw_driver.driver.probe and .remove methodsStefan Richter
After all IEEE 1394 high-level drivers being converted to bus-specific .probe/.remove methods, remove support of the obsolete generic methods. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-06-09firewire: introduce fw_driver.probe and .remove methodsStefan Richter
FireWire upper layer drivers are converted from generic struct driver.probe() and .remove() to bus-specific struct fw_driver.probe() and .remove(). The new .probe() adds a const struct ieee1394_device_id *id argument, indicating the entry in the driver's device identifiers table which matched the fw_unit to be probed. This new argument is used by the snd-firewire-speakers driver to look up device-specific parameters and methods. There is at least one other FireWire audio driver currently in development in which this will be useful too. The new .remove() drops the unused error return code. Although all in-tree drivers are being converted to the new methods, support for the old methods is left in place in this commit. This allows public developer trees to merge this commit and then move to the new fw_driver methods. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Clemens Ladisch <clemens@ladisch.de> (for sound/firewire/) Cc: Peter Hurley <peter@hurleysoftware.com> (for drivers/staging/fwserial/)
2013-04-30firewire: ohci: dump_stack() for PHY regs read/write failuresPeter Hurley
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 <peter@hurleysoftware.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-04-30firewire: ohci: Improve bus reset error messagesPeter Hurley
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 <peter@hurleysoftware.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-04-30firewire: ohci: Alias dev_* log functionsPeter Hurley
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 <peter@hurleysoftware.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-04-30firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8Peter Hurley
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] [<ffffffff8105468f>] warn_slowpath_common+0x7f/0xc0 [ 4.576168] [<ffffffff81054786>] warn_slowpath_fmt+0x46/0x50 [ 4.576178] [<ffffffffa00caca3>] read_phy_reg+0x93/0xe0 [firewire_ohci] [ 4.576188] [<ffffffffa00cae19>] ohci_read_phy_reg+0x39/0x60 [firewire_ohci] [ 4.576203] [<ffffffffa00731ff>] fw_send_phy_config+0xbf/0xe0 [firewire_core] [ 4.576214] [<ffffffffa006b2d6>] br_work+0x46/0xb0 [firewire_core] [ 4.576225] [<ffffffff81071e0c>] process_one_work+0x13c/0x500 [ 4.576238] [<ffffffffa006b290>] ? fw_card_initialize+0x180/0x180 [firewire_core] [ 4.576248] [<ffffffff810737ed>] worker_thread+0x16d/0x470 [ 4.576257] [<ffffffff81073680>] ? busy_worker_rebind_fn+0x100/0x100 [ 4.576266] [<ffffffff8107d160>] kthread+0xc0/0xd0 [ 4.576275] [<ffffffff816a0000>] ? pcpu_dump_alloc_info+0x1cb/0x2c4 [ 4.576284] [<ffffffff8107d0a0>] ? kthread_create_on_node+0x130/0x130 [ 4.576297] [<ffffffff816b2f6c>] ret_from_fork+0x7c/0xb0 [ 4.576305] [<ffffffff8107d0a0>] ? 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 <tim@insipid.org.uk> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2013-04-28firewire: ohci: fix VIA VT6306 video receptionAndy Leiserson
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 <andy@leiserson.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-24 01:27:40 +0000