#
09773bf5 |
|
29-Apr-2024 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: fulfill timestamp for some local asynchronous transaction 1394 OHCI driver generates packet data for the response subaction to the request subaction to some local registers. In the case, the driver should assign timestamp to them by itself. This commit fulfills the timestamp for the subaction. Cc: stable@vger.kernel.org Fixes: dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion") Link: https://lore.kernel.org/r/20240429084709.707473-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
752e3c53 |
|
24-Mar-2024 |
Adam Goldman <adamg@pobox.com> |
firewire: ohci: mask bus reset interrupts between ISR and bottom half In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt. Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them. irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally. This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization. irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired. As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed. Signed-off-by: Adam Goldman <adamg@pobox.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
57580166 |
|
29-Feb-2024 |
Edmund Raile <edmund.raile@proton.me> |
firewire: ohci: prevent leak of left-over IRQ on unbind Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") also removed the call to free_irq() in pci_remove(), leading to a leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove() when unbinding the driver from the device remove_proc_entry: removing non-empty directory 'irq/136', leaking at least 'firewire_ohci' Call Trace: ? remove_proc_entry+0x19c/0x1c0 ? __warn+0x81/0x130 ? remove_proc_entry+0x19c/0x1c0 ? report_bug+0x171/0x1a0 ? console_unlock+0x78/0x120 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? remove_proc_entry+0x19c/0x1c0 unregister_irq_proc+0xf4/0x120 free_desc+0x3d/0xe0 ? kfree+0x29f/0x2f0 irq_free_descs+0x47/0x70 msi_domain_free_locked.part.0+0x19d/0x1d0 msi_domain_free_irqs_all_locked+0x81/0xc0 pci_free_msi_irqs+0x12/0x40 pci_disable_msi+0x4c/0x60 pci_remove+0x9d/0xc0 [firewire_ohci 01b483699bebf9cb07a3d69df0aa2bee71db1b26] pci_device_remove+0x37/0xa0 device_release_driver_internal+0x19f/0x200 unbind_store+0xa1/0xb0 remove irq with devm_free_irq() before pci_disable_msi() also remove it in fail_msi: of pci_probe() as this would lead to an identical leak Cc: stable@vger.kernel.org Fixes: 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") Signed-off-by: Edmund Raile <edmund.raile@proton.me> Link: https://lore.kernel.org/r/20240229144723.13047-2-edmund.raile@proton.me Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
ac9184fb |
|
02-Jan-2024 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge, it appears that accesses to its 'Isochronous Cycle Timer' register (offset 0xf0 on PCI memory space) often causes unexpected system reboot in any type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not appears in the other type of machine (AMD pre-Ryzen machine, Intel machine, at least), or in the other OHCI 1394 hardware (e.g. Texas Instruments). The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion") added to v6.5 kernel. It changed 1394 OHCI driver to access to the register every time to dispatch local asynchronous transaction. However, the issue exists in older version of kernel as long as it runs in AMD Ryzen machine, since the access to the register is required to maintain bus time. It is not hard to imagine that users experience the unexpected system reboot when generating bus reset by plugging any devices in, or reading the register by time-aware application programs; e.g. audio sample processing. This commit suppresses the unexpected system reboot in the combination of hardware. It avoids the access itself. As a result, the software stack can not provide the hardware time anymore to unit drivers, userspace applications, and nodes in the same IEEE 1394 bus. It brings apparent disadvantage since time-aware application programs require it, while time-unaware applications are available again; e.g. sbp2. Cc: stable@vger.kernel.org Reported-by: Jiri Slaby <jirislaby@kernel.org> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 Reported-by: Mario Limonciello <mario.limonciello@amd.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 Reported-by: Tobias Gruetzmacher <tobias-lists@23.gs> Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/ Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973 Closes: https://bugs.launchpad.net/linux/+bug/2043905 Link: https://lore.kernel.org/r/20240102110150.244475-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
5716e58a |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: release buffer for AR req/resp contexts when managed resource is released The 1394 OHCI driver allocates several non-coherent DMA buffers for AR request and response contexts. The buffers are mapped to kernel virtual address (VMA) so that the first page locates after the last page. Even when large payload of packet is handled crossing the boundary of buffers, the driver operates continuously on VMA. No kernel API is provided for this kind of mapping, while it is possible to release the buffer when PCI device is going to be released. This commit moves the call of release helper function to the callback function of release resources. Link: https://lore.kernel.org/r/20230604054451.161076-10-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
aeaf6aa8 |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for content of configuration ROM The 1394 OHCI driver allocates DMA coherent buffer to transfer content of configuration ROM. This commit utilizes managed device resource to maintain the lifetime of buffer. Link: https://lore.kernel.org/r/20230604054451.161076-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
aa71e28d |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contexts The 1394 OHCI driver allocates DMA coherent buffer for descriptors of IT, IR, AT receive, and AT request contexts by the same way. This commit utilizes managed device resource to maintain the lifetime of buffers. Link: https://lore.kernel.org/r/20230604054451.161076-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
30d97fd7 |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for list of isochronous contexts The 1394 OHCI driver allocates the list of isochronous contexts as much as the hardware supports. This commit utilizes managed device resource to maintain the lifetime of list. Link: https://lore.kernel.org/r/20230604054451.161076-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
5a95f1de |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for requested IRQ The 1394 OHCI controller register handler to single interrupt number. This commit uses managed device resource to maintain the lifetime of requested IRQ. Link: https://lore.kernel.org/r/20230604054451.161076-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
8320442b |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for misc DMA buffer The 1394 OHCI driver allocates a DMA coherent buffer for multi-purposes. The buffer is split into three region for specific purposes; i.e. 1/4 for context descriptors of AR request and response as well as 1/2 for self ID handling. This commit uses managed device resource to maintain the lifetime of buffer. Link: https://lore.kernel.org/r/20230604054451.161076-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
086a0afb |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for MMIO region mapping The PCI framework has the convenient helper function to check and map MMIO region with managed device resource. This commit elaborates 1394 OHCI driver to use the function. Link: https://lore.kernel.org/r/20230604054451.161076-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
14f6ca5b |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for PCI-related resources The PCI framework supports managed device resource to maintain the lifetime of PCI specific resources. This commit allows 1394 OHCI driver to utilize it. Link: https://lore.kernel.org/r/20230604054451.161076-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
f86319c0 |
|
03-Jun-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: ohci: use devres for memory object of ohci structure The managed device resource (devres) framework is convenient to maintain lifetime of allocated memory object for device. This commit utilizes the framework for the object of ohci structure. The extra operation for power management is required in Apple PowerMac based machines, thus release callback is assigned to the object to call the operation. Link: https://lore.kernel.org/r/20230604054451.161076-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
dcadfd7f |
|
29-May-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
firewire: core: use union for callback of transaction completion In 1394 OHCI, the OUTPUT_LAST descriptor of Asynchronous Transmit (AT) request context has timeStamp field, in which 1394 OHCI controller record the isochronous cycle when the packet was sent for the request subaction. Additionally, for the case of split transaction in IEEE 1394, Asynchronous Receive (AT) request context is used for response subaction to finish the transaction. The trailer quadlet of descriptor in the context has timeStamp field, in which 1394 OHCI controller records the isochronous cycle when the packet arrived. Current implementation of 1394 OHCI controller driver stores values of both fields to internal structure as time stamp, while Linux FireWire subsystem provides no way to access to it. When using asynchronous transaction service provided by the subsystem, callback function is passed to kernel API. The prototype of callback function has the lack of argument for the values. This commit adds a new callback function for the purpose. It has an additional argument to point to the constant array with two elements. For backward compatibility to kernel space, a new union is also adds to wrap two different prototype of callback function. The fw_transaction structure has the union as a member and a boolean flag to express which function callback is available. The core function is changed to handle the two cases; with or without time stamp. For the error path to process transaction, the isochronous cycle is computed by current value of CYCLE_TIMER register in 1394 OHCI controller. Especially for the case of timeout of split transaction, the expected isochronous cycle is computed. Link: https://lore.kernel.org/r/20230529113406.986289-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
#
f339fc16 |
|
09-Mar-2021 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
firewire: ohci: Use tasklet_disable_in_atomic() where required tasklet_disable() is invoked in several places. Some of them are in atomic context which prevents a conversion of tasklet_disable() to a sleepable function. The atomic callchains are: ar_context_tasklet() ohci_cancel_packet() tasklet_disable() ... ohci_flush_iso_completions() tasklet_disable() The invocation of tasklet_disable() from at_context_flush() is always in preemptible context. Use tasklet_disable_in_atomic() for the two invocations in ohci_cancel_packet() and ohci_flush_iso_completions(). Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20210309084242.616379058@linutronix.de
|
#
c51a9868 |
|
01-Sep-2020 |
Christoph Hellwig <hch@lst.de> |
firewire-ohci: use dma_alloc_pages Use dma_alloc_pages to allocate DMAable pages instead of hoping that the architecture either has GFP_DMA32 or not more than 4G of memory. Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
3f649ab7 |
|
03-Jun-2020 |
Kees Cook <keescook@chromium.org> |
treewide: Remove uninitialized_var() usage Using uninitialized_var() is dangerous as it papers over real bugs[1] (or can in the future), and suppresses unrelated compiler warnings (e.g. "unused variable"). If the compiler thinks it is uninitialized, either simply initialize the variable or make compiler changes. In preparation for removing[2] the[3] macro[4], remove all remaining needless uses with the following script: git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \ xargs perl -pi -e \ 's/\buninitialized_var\(([^\)]+)\)/\1/g; s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;' drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid pathological white-space. No outstanding warnings were found building allmodconfig with GCC 9.3.0 for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64, alpha, and m68k. [1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/ [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5 Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
c38e7e21 |
|
28-May-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
firewire: ohci: Replace zero-length array with flexible-array There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
b98c7518 |
|
18-Jun-2018 |
Arnd Bergmann <arnd@arndb.de> |
firewire: ohci: stop using get_seconds() for BUS_TIME The ohci driver uses the get_seconds() function to implement the 32-bit CSR_BUS_TIME register. This was added in 2010 commit a48777e03ad5 ("firewire: add CSR BUS_TIME support"). As get_seconds() returns a 32-bit value (on 32-bit architectures), it seems like a good fit for that register, but it is also deprecated because of the y2038/y2106 overflow problem, and should be replaced throughout the kernel with either ktime_get_real_seconds() or ktime_get_seconds(). I'm using the latter here, which uses monotonic time. This has the advantage of behaving better during concurrent settimeofday() updates or leap second adjustments and won't overflow a 32-bit integer, but the downside of using CLOCK_MONOTONIC instead of CLOCK_REALTIME is that the observed values are not related to external clocks. If we instead need UTC but can live with clock jumps or overflows, then we should use ktime_get_real_seconds() instead, retaining the existing behavior. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/lkml/20180711124923.1205200-1-arnd@arndb.de/ Reviewed-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
1a59d1b8 |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1334 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fb24ea52 |
|
22-Feb-2019 |
Will Deacon <will@kernel.org> |
drivers: Remove explicit invocations of mmiowb() mmiowb() is now implied by spin_unlock() on architectures that require it, so there is no reason to call it from driver code. This patch was generated using coccinelle: @mmiowb@ @@ - mmiowb(); and invoked as: $ for d in drivers include/linux/qed sound; do \ spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation. If you've ended up bisecting to this commit, you can reintroduce the mmiowb() calls using wmb() instead, which should restore the old behaviour on all architectures other than some esoteric ia64 systems. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
18877518 |
|
03-Nov-2017 |
Hector Martin <marcan@marcan.st> |
firewire-ohci: work around oversized DMA reads on JMicron controllers 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>
|
#
6aa7de05 |
|
23-Oct-2017 |
Mark Rutland <mark.rutland@arm.com> |
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE() Please do not apply this to mainline directly, instead please re-run the coccinelle script shown below and apply its output. For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't harmful, and changing them results in churn. However, for some features, the read/write distinction is critical to correct operation. To distinguish these cases, separate read/write accessors must be used. This patch migrates (most) remaining ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following coccinelle script: ---- // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and // WRITE_ONCE() // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch virtual patch @ depends on patch @ expression E1, E2; @@ - ACCESS_ONCE(E1) = E2 + WRITE_ONCE(E1, E2) @ depends on patch @ expression E; @@ - ACCESS_ONCE(E) + READ_ONCE(E) ---- Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: davem@davemloft.net Cc: linux-arch@vger.kernel.org Cc: mpe@ellerman.id.au Cc: shuah@kernel.org Cc: snitzer@redhat.com Cc: thor.thayer@linux.intel.com Cc: tj@kernel.org Cc: viro@zeniv.linux.org.uk Cc: will.deacon@arm.com Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
a354cf00 |
|
01-Nov-2015 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: propagate return code from soft_reset to probe and resume software_reset() may fail - due to unresponsive chip with -EBUSY (-16), or - due to ejected or unseated card with -ENODEV (-19). Let the PCI probe and resume routines log the actual error code instead of hardwired -EBUSY. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
100ceb66 |
|
02-Nov-2015 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix JMicron JMB38x IT context discovery 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>
|
#
b625a825 |
|
02-Jan-2015 |
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> |
firewire: ohci: Remove unused function 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>
|
#
51b04d59 |
|
16-Nov-2014 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: replace vm_map_ram() with vmap() 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>
|
#
d584a662 |
|
23-Jul-2014 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: disable MSI for VIA VT6315 again 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>
|
#
d151f985 |
|
15-Apr-2014 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: enable MSI for VIA VT6315 rev 1, drop cycle timer quirk 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>
|
#
2fe2023a |
|
29-May-2014 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: revert to 4 GB RDMA, fix protocols using Memory Space 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>
|
#
4e857c58 |
|
17-Mar-2014 |
Peter Zijlstra <peterz@infradead.org> |
arch: Mass conversion of smp_mb__*() 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>
|
#
0ca49345 |
|
06-Mar-2014 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix probe failure with Agere/LSI controllers 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>
|
#
fcd46b34 |
|
18-Jan-2014 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: Enable remote DMA above 4 GB 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>
|
#
8bc588e0 |
|
22-Dec-2013 |
Lubomir Rintel <lkundrak@v3.sk> |
firewire: ohci: Turn remote DMA support into a module parameter 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>
|
#
db9ae8fe |
|
26-Aug-2013 |
Stephan Gatzka <stephan.gatzka@gmail.com> |
firewire: ohci: Fix deadlock at bus reset 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>
|
#
7a723c6e |
|
26-Aug-2013 |
Stephan Gatzka <stephan.gatzka@gmail.com> |
firewire: ohci: Change module_pci_driver to module_init/module_exit 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>
|
#
0dbe15f8 |
|
05-Aug-2013 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: beautify some macro definitions 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>
|
#
af53122a |
|
05-Aug-2013 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: change confusing name of a struct member 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>
|
#
0699a73a |
|
22-Jul-2013 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: fix libdc1394/FlyCap2 iso event regression 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>
|
#
6fe9efb9 |
|
27-Mar-2013 |
Peter Hurley <peter@hurleysoftware.com> |
firewire: ohci: dump_stack() for PHY regs read/write failures 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>
|
#
67672134 |
|
27-Mar-2013 |
Peter Hurley <peter@hurleysoftware.com> |
firewire: ohci: Improve bus reset error messages 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>
|
#
de97cb64 |
|
26-Mar-2013 |
Peter Hurley <peter@hurleysoftware.com> |
firewire: ohci: Alias dev_* log functions 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>
|
#
bd972688 |
|
28-Apr-2013 |
Peter Hurley <peter@hurleysoftware.com> |
firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8 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>
|
#
be8dcab9 |
|
24-Apr-2013 |
Andy Leiserson <andy@leiserson.org> |
firewire: ohci: fix VIA VT6306 video reception 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>
|
#
8db49149 |
|
27-Mar-2013 |
Peter Hurley <peter@hurleysoftware.com> |
firewire: ohci: Check LPS before register access on pci removal 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 <peter@hurleysoftware.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
247fd50b |
|
27-Mar-2013 |
Peter Hurley <peter@hurleysoftware.com> |
firewire: ohci: Fix double free_irq() 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 <mark.einon@gmail.com> 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: [<ffffffff81051c1f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff81051d16>] warn_slowpath_fmt+0x46/0x50 [<ffffffff8103fa39>] ? default_spin_lock_flags+0x9/0x10 [<ffffffff810df6b3>] __free_irq+0xa3/0x1e0 [<ffffffff810df844>] free_irq+0x54/0xc0 [<ffffffffa005a27e>] pci_remove+0x6e/0x210 [firewire_ohci] [<ffffffff8135ae7f>] pci_device_remove+0x3f/0x110 [<ffffffff8141fdbc>] __device_release_driver+0x7c/0xe0 [<ffffffff8141fe4c>] device_release_driver+0x2c/0x40 [<ffffffff8141f5f1>] bus_remove_device+0xe1/0x120 [<ffffffff8141cd1a>] device_del+0x12a/0x1c0 [<ffffffff8141cdc6>] device_unregister+0x16/0x30 [<ffffffff81354784>] pci_stop_bus_device+0x94/0xa0 [<ffffffffa0091c67>] acpiphp_disable_slot+0xb7/0x1a0 [acpiphp] [<ffffffffa0090716>] ? get_slot_status+0x46/0xc0 [acpiphp] [<ffffffffa0091d7d>] acpiphp_check_bridge.isra.15+0x2d/0xf0 [acpiphp] [<ffffffffa0092442>] _handle_hotplug_event_bridge+0x372/0x4d0 [acpiphp] [<ffffffff81390f8c>] ? acpi_os_execute_deferred+0x2f/0x34 [<ffffffff8116e22d>] ? kfree+0xed/0x110 [<ffffffff8107086a>] process_one_work+0x12a/0x420 [<ffffffffa00920d0>] ? _handle_hotplug_event_func+0x1d0/0x1d0 [acpiphp] [<ffffffff8107141e>] worker_thread+0x12e/0x2f0 [<ffffffff810712f0>] ? manage_workers.isra.26+0x200/0x200 [<ffffffff81075f13>] kthread+0x93/0xa0 [<ffffffff8168d024>] kernel_thread_helper+0x4/0x10 [<ffffffff81075e80>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8168d020>] ? gs_change+0x13/0x13 Reported-by: Mark Einon <mark.einon@gmail.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
cfb0c9d1 |
|
24-Mar-2013 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: remove unnecessary alloc/OOM messages These are redundant to log messages from the mm core. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
df7ce663 |
|
16-Mar-2013 |
Paul Bolle <pebolle@tiscali.nl> |
firewire: Remove two unneeded checks for macros The old IEEE 1394 driver stack was removed in v2.6.37. That made the checks for two Kconfig (module) macros unneeded, since they will now always evaluate to true. Remove these two checks. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
8a168ca7 |
|
28-Dec-2012 |
Masanari Iida <standby24x7@gmail.com> |
treewide: Fix typo in various drivers Correct spelling typo in printk within various drivers. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
03f94c0f |
|
19-Nov-2012 |
Bill Pemberton <wfp5p@virginia.edu> |
firewire: remove use of __devinit CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b3834be5 |
|
19-Sep-2012 |
Adam Buchbinder <adam.buchbinder@gmail.com> |
various: Fix spelling of "asynchronous" in comments. "Asynchronous" is misspelled in some comments. No code changes. Signed-off-by: Adam Buchbinder <adam.buchbinder@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
52439d60 |
|
03-Sep-2012 |
Stephan Gatzka <stephan.gatzka@gmail.com> |
firewire: ohci: get IR bit from TSB41BA3D phy In case of a self constructed selfID packet this patch correctly determines the information if the TSB41BA3D phy initiated a bus reset. Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
e18907cc |
|
13-Jun-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: initialize multiChanMode bits after reset OHCI 1.1 says: | Since the value of this bit is undefined after reset in all IR | contexts, software shall initialize this bit to zero in all contexts | whether or not active to maintain the exclusive nature of this bit. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
7baab9ac |
|
04-Jun-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: sanity-check MMIO resource pci_request_region() does not fail on resources that have not been allocated by the BIOS or by the kernel, so to avoid accessing registers that are not there, we have to check for this explicitly. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
9d60ef2b |
|
24-May-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: lazy bus time initialization The Bus_Time CSR is virtually never used, so we can avoid burning CPU in interrupt context for 1 or 3 IsochronousCycleTimer accesses every minute by not tracking the bus time until the CSR is actually accessed for the first time. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
8a8c4736 |
|
09-Apr-2012 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: omit spinlock IRQ flags where possible bus_reset_work() is only called from workqueue thread context. ohci_set_config_rom() and ohci_allocate_iso_context() perform GFP_KERNEL memory allocations, therefore they must be called with interrupts enabled. Hence these functions may disable and enable local IRQs without having to track IRQ state. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
d713dfa7 |
|
09-Apr-2012 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: correct signedness of a local variable bus_reset_work's reg is a bitfield. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
fe2af11c |
|
02-Apr-2012 |
Axel Lin <axel.lin@gmail.com> |
firewire: use module_pci_driver This patch converts the drivers in drivers/firewire/* to use module_pci_driver() macro which makes the code smaller and a bit simpler. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
9ffc93f2 |
|
28-Mar-2012 |
David Howells <dhowells@redhat.com> |
Remove all #inclusions of asm/system.h Remove all #inclusions of asm/system.h preparatory to splitting and killing it. Performed with the following command: perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *` Signed-off-by: David Howells <dhowells@redhat.com>
|
#
d1bbd209 |
|
18-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: allow explicit flushing of iso packet completions Extend the kernel and userspace APIs to allow reporting all currently completed isochronous packets, even if the next interrupt packet has not yet been reached. This is required to determine the status of the packets at the end of a paused or stopped stream, and useful for more precise synchronization of audio streams. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
18d62711 |
|
18-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: prevent dropping of completed iso packet header data The buffer for the header data of completed iso packets has a fixed size, so it is possible to configure a stream with a big interval between interrupt packets or with big headers so that this buffer would overflow. Previously, ohci.c would drop any data that would not fit, but this could make unsuspecting applications believe that fewer than the actual number of packets have completed. Instead of dropping data, add calls to flush_iso_completion() so that there are as many events as needed to report all of the data. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
910e76c6 |
|
18-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: factor out iso completion flushing code In preparation for the following patches that add more flushing, move the code for flushing accumulated header data into a common function. The timestamp of the last completed packed is passed through the context structure instead of a function parameter to allow accessing this value later outside of the handle_i?_packet functions. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
73864012 |
|
18-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: simplify iso header pointer arithmetic When storing the header data of completed iso packets, we effectively treat the buffers as arrays of quadlets. Actually declaring the pointers as u32* avoids repetitive pointer arithmetic, removes the unhelpfully named "i" variables, and thus makes the code clearer. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
90fcc898 |
|
18-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: optimize control bit checks Doing the endian conversion on the constant instead of the memory field allows the compiler to do the conversion at compile time. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
b9b5bbfd |
|
18-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: remove unused excess_bytes field Commit 6498ba04aee6 (remove unused dualbuffer IR code) overlooked a field in struct iso_context. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
32c507f7 |
|
18-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: copy_iso_headers(): make comment match the code The comment incorrectly talked about one little-endian quadlet, while there are actually two. Furthermore, the endianness of the remaining headers depends on whatever protocol is used, so don't mention them. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
0c0efbac |
|
12-Mar-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix too-early completion of IR multichannel buffers handle_ir_buffer_fill() assumed that a completed descriptor would be indicated by a non-zero transfer_status (as in most other descriptors). However, this field is written by the controller as soon as (the end of) the first packet has been written into the buffer. As a consequence, if we happen to run into such a descriptor when the interrupt handler is executed after such a packet has completed, the descriptor would be taken out of the list of active descriptors as soon as the buffer had been partially filled, so the event for the buffer being completely filled would never be sent. To fix this, handle descriptors only when they have been completely filled, i.e., when res_count == 0. (This also matches the condition that is reported by the controller with an interrupt.) Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: 2.6.36+ <stable@vger.kernel.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
cfda62ba |
|
04-Mar-2012 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: move runtime debug facility out of #ifdef CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers if CONFIG_EXPERT was set. But in hindsight, this stuff is far too useful to omit it. So get rid of two #else branches that are only going to bitrot otherwise. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
98466cc4 |
|
04-Mar-2012 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: tone down some diagnostic log messages The "skipped bus generations" message was added together with the respective fw_device retaining/ reviving code in order to see how it all works out. It did well, so don't spam the log anymore. The "register access failure" situation still needs an actual handler. But at this point it makes less sense to ask folks to send mails about it. We now have a pretty good picture of what controllers emit this and when: Texas Instruments PCIxx21 FireWire + CardBus + flash memory card controller: https://bugzilla.redhat.com/show_bug.cgi?id=608544 O2 Micro FireWire + flash memory card controller: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881688 http://marc.info/?l=linux1394-devel&m=132309283531423 http://marc.info/?l=linux1394-devel&m=132368567907469 http://marc.info/?l=linux1394-devel&m=132516165727468 http://marc.info/?l=linux1394-devel&m=133006486927699 Pinnacle Movieboard: commit 7f7e37115a8b6724f26d0637a04e1d35e3c59717 http://marc.info/?l=linux1394-devel&m=130714243325962 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
320cfa6c |
|
28-Jan-2012 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: disable MSI on Ricoh controllers The PCIe device FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller [1180:e832] (prog-if 10 [OHCI]) is unable to access attached FireWire devices when MSI is enabled but works if MSI is disabled. http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.html Hence add the "disable MSI" quirks flag for this device, or in fact for safety and simplicity for all current (R5U230, R5U231, R5U240) and future Ricoh PCIe 1394 controllers. Reported-by: Stefan Thomas <kontrapunktstefan@googlemail.com> Cc: 2.6.36+ <stable@vger.kernel.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
d1bb399a |
|
26-Jan-2012 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: add reset packet quirk for SB Audigy The Audigy's SB1394 controller is actually from Texas Instruments and has the same bus reset packet generation bug, so it needs the same quirk entry. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: 2.6.36+ <stable@vger.kernel.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
64d21720 |
|
20-Dec-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: use dev_printk API All messages are uniformly prefixed by driver name and device name now. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
a572e688 |
|
15-Oct-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix isochronous DMA synchronization Add the dma_sync_single_* calls necessary to ensure proper cache synchronization for isochronous data buffers on non-coherent architectures. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
32eaeae1 |
|
15-Oct-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: work around selfID junk due to wrong gap count If a device's firmware initiates a bus reset by setting the IBR bit in PHY register 1 without resetting the gap count field to 63 (and without having sent a PHY configuration packet beforehand), the gap count of this node will remain at the old value after the bus reset and thus be inconsistent with the gap count on all other nodes. The bus manager is supposed to detect the inconsistent gap count values in the self ID packets and correct them by issuing another bus reset. However, if the buggy device happens to be the cycle master, and if it sends a cycle start packet immediately after the bus reset (which is likely after a long bus reset), then the time between the end of the selfID phase and the start of the cycle start packet will be based on the too-small gap count value, so this gap will be too short to be detected as a subaction gap by the other nodes. This means that the cycle start packet will be assumed to be self ID data, and will be stored after the actual self ID quadlets in the self ID buffer. This garbage in the self ID buffer made firewire-core ignore all of the self ID data, and thus prevented the Linux bus manager from correcting the problem. Furthermore, because the bus reset handling was aborted completely, asynchronous transfers would be no longer handled correctly, and fw_run_transaction() would hang until the next bus reset. To fix this, make the detection of inconsistent self IDs more discriminating: If the invalid data in the self ID buffer looks like a cycle start packet, we can assume that the previous data in the buffer is correctly received self ID information, and process it normally. (We inspect only the first quadlet of the cycle start packet, because this value is different enough from any valid self ID quadlet, and many controllers do not store the cycle start packet in five quadlets because they expect self ID data to have an even number of quadlets.) This bug has been observed when a bus-powered DesktopKonnekt6 is switched off with its power button. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
a74477db |
|
26-Sep-2011 |
Stephan Gatzka <stephan@gatzka.org> |
firewire: net: Use posted writes Change memory region to ohci "middle address space". This effectively reduces the number of packets by 50%. [Stefan R.:] This eliminates 1394 ack packets and improved throughput by a few percent in some tests with an S400a connection with and without gap count optimization. Since firewire-net taxes the AR-req DMA unit of a FireWire controller much more than firewire-sbp2 (which uses the middle address space with PCI posted writes too), this commit also changes a related error printk into a ratelimited one as a precaution. Side note: The IPv4-over-1394 drivers of Mac OS X 10.4, Windows XP SP3, and the Thesycon 1394 bus driver for Windows all use the middle address space too. Signed-off-by: Stephan Gatzka <stephan@gatzka.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
b810e4ae |
|
19-Sep-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: optimize TSB41BA3D detection Takes less source code and machine code, and less runtime with PHYs other than TSB41BA3D (e.g. TSB81BA3 with device ID 0x831304 which takes one instead of six read_paged_phy_reg now). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
28897fb7 |
|
18-Sep-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: TSB41BA3D support tweaks Fix: phy_reg_mutex must be held over the write/read_phy_reg pair which gets PHY port status. Only print to the log when a TSB41BA3D was found. By far most TSB82AA2 cards have a TSB81BA3, and firewire-ohci can keep quiet about that. Shorten some strings and comments. Change some whitespace. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
25935ebe |
|
12-Sep-2011 |
Stephan Gatzka <stephan@gatzka.org> |
firewire: ohci: Add support for TSB41BA3D phy This patch implements a work around for the Texas Instruments PHY TSB41BA3D. This phy has a bug at least in combination with the TI LLCs TSB82AA2B and TSB12LV26. The selfid coming from the locally connected phy is not propagated into the selfid buffer of the OHCI (see http://www.ti.com/litv/pdf/sllz059 for details). The main idea is to construct the selfid ourselves. Signed-off-by: Stephan Gatzka <stephan@gatzka.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
2d7a36e2 |
|
25-Jul-2011 |
Stephan Gatzka <stephan@gatzka.org> |
firewire: ohci: Move code from the bus reset tasklet into a workqueue Code inside bus_reset_work may now sleep. This is a prerequisite to support a phy from Texas Instruments cleanly. The patch to support this phy will be submitted later. Signed-off-by: Stephan Gatzka <stephan@gatzka.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
f39aa30d |
|
30-Aug-2011 |
Ming Lei <ming.lei@canonical.com> |
firewire: ohci: add no MSI quirk for O2Micro controller This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 . An O2Micro PCI Express FireWire controller, "FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05)" which is a combination device together with an SDHCI controller and some sort of storage controller, misses SBP-2 status writes from an attached FireWire HDD. This problem goes away if MSI is disabled for this FireWire controller. The device reportedly does not require QUIRK_CYCLE_TIMER. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (amended changelog) Cc: <stable@kernel.org>
|
#
a01e8360 |
|
11-Aug-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix DMA unmapping in an error path If request_irq failed, we would pass wrong arguments to dma_free_coherent. https://bugzilla.redhat.com/show_bug.cgi?id=728185 Reported-by: Mads Kiilerich Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
7f7e3711 |
|
09-Jul-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: do not bind to Pinnacle cards, avert panic 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 <stefanr@s5r6.in-berlin.de> Cc: <stable@kernel.org>
|
#
9f426173 |
|
03-Jul-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: skip soft reset retries after card ejection The software reset in firewire-ohci's pci_remove does not have a great prospect of success if the card was already physically removed at this point. So let's skip the 500 ms that were spent in retries here. Also, replace a defined constant by its open-coded value. This is not a constant from a specification but an arbitrarily chosen retry limit. It was only used in this single place. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
215fa444 |
|
22-Jun-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix PHY reg access after card ejection Detect and handle ejection of FireWire CardBus cards in PHY register accesses: - The last attempt of firewire-core to reset the bus during shutdown caused a spurious "firewire_ohci: failed to write phy reg" error message in the log. Skip this message as well as the prior retry loop that needlessly took 100 milliseconds. - In the unlikely case that a PHY register was read right after card ejection, a bogus value was obtained and possibly acted upon. Instead, fail the read attempt. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
b14c369d |
|
21-Jun-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: add a comment on PHY reg access serialization Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
9ef28ccd |
|
12-Jun-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: reduce potential context_stop latency Stopping an isochronous reception DMA context takes two loop iterations in context_stop on several controllers (JMicron, NEC, VIA). But there is no extra delay necessary between these two reg_read trials; the MMIO reads themselves are slow enough. Hence bring back the behavior from before commit dd6254e5c0efe01ad255188898cb3dadf98cb56d "firewire: ohci: remove superfluous posted write flushes" on these controllers by means of an "if (i)" condition. Isochronous context stop is performed in preemptible contexts (and only rarely), hence this change is of little impact. (Besides, Agere and TI controllers always, or almost always, have the context stopped already at the first ContextControl read.) More important is asynchronous transmit context stop, which is performed while local interrupts are disabled (on the two AT DMAs in bus_reset_tasklet, i.e. after a self-ID-complete event). In my experience with several controllers, tested with a usermode AT-request transmitter as well as with FTP transmission over firewire-net, the AT contexts were luckily already stopped at the first ContextControl read, i.e. never required another MMIO read let alone mdelay. A possible explanation for this is that the controllers which I tested perhaps stop AT DMA before they perform the self-ID reception DMA. But we cannot be sure about that and should keep the interrupts-disabled busy loop as short as possible. Hence, query the ContextControl register in 1000 udelay(10) intervals instead of 10 udelay(1000) intervals. I understand from an estimation by Clemens Ladisch that stopping a busy DMA context should take microseconds or at worst tens of microseconds, not milliseconds. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
dd6254e5 |
|
16-May-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: remove superfluous posted write flushes The call to flush_writes() in context_stop() is superfluous because another register read is done immediately afterwards. The call to flush_writes() in ar_context_run() does not need to be done individually for each AR context, so move it to ohci_enable(). This also makes ohci_enable() clearer because it no longer depends on a side effect of ar_context_run() to flush its own register writes. Finally, the setting of a context's wake bit does not need to be flushed because neither the driver logic nor the API require the CPU to wait for this action. This removes the last MMIO reads from the packet queueing code paths. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
13882a82 |
|
02-May-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: optimize iso queueing by setting wake only after the last packet When queueing iso packets, the run time is dominated by the two MMIO accesses that set the DMA context's wake bit. Because most drivers submit packets in batches, we can save much time by removing all but the last wakeup. The internal kernel API is changed to require a call to fw_iso_context_queue_flush() after a batch of queued packets. The user space API does not change, so one call to FW_CDEV_IOC_QUEUE_ISO must specify multiple packets to take advantage of this optimization. In my measurements, this patch reduces the time needed to queue fifty skip packets from userspace to one sixth on a 2.5 GHz CPU, or to one third at 800 MHz. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
2e053a27 |
|
02-May-2011 |
B.J. Buchalter <bj@mhlabs.com> |
firewire: Fix for broken configrom updates in quick succession 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
|
#
0ff8fbc6 |
|
11-Apr-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: optimize find_branch_descriptor() When z==2, the condition "key == 2" is superfluous because it cannot occur without "b == 3", as a descriptor with b!=3 and key==2 would be an OUTPUT_MORE_IMMEDIATE descriptor which cannot be used alone. Also remove magic numbers and needless computations on the b field. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
da28947e |
|
11-Apr-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: avoid separate DMA mapping for small AT payloads For AT packet payloads of up to eight bytes, we have enough unused space in the DMA descriptors list so that we can put a copy of the payload there and thus avoid having to create a separate streaming DMA mapping for the payload buffer. In a CPU-bound microbenchmark that just sends 8-byte packets, bandwidth was measured to increase by 5.7 %, from 1009 KB/s to 1067 KB/s. In practice, the only performance-sensitive usage of small asynchronous packets is the SBP-2 driver's write to the ORB_POINTER register during SCSI command submission. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
ecf8328e |
|
11-Apr-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: do not start DMA contexts before link is enabled OHCI 1.1 5.7.3 not only forbids enabling or starting any DMA contexts before the linkEnable bit is set, but also explicitly warns of undefined behaviour if this order is violated. Don't violate it then. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
d838d2c0 |
|
10-Mar-2011 |
Oleg Drokin <green@linuxhacker.ru> |
firewire: ohci: Misleading kfree in ohci.c::pci_probe/remove 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>
|
#
b6258fc1 |
|
26-Feb-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: omit IntEvent.busReset check rom AT queueing 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>
|
#
44b74d90 |
|
23-Feb-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: prevent starting of iso contexts with empty queue 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>
|
#
e81cbebd |
|
16-Feb-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: prevent iso completion callbacks after context stop 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>
|
#
f117a3e3 |
|
10-Jan-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: log dead DMA contexts 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>
|
#
14271304 |
|
13-Jan-2011 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO 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>
|
#
693a50b5 |
|
01-Jan-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: consolidate context status flags "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>
|
#
386a4153 |
|
24-Dec-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: cache the context run bit 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>
|
#
78dec56d |
|
01-Jan-2011 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: flush AT contexts after bus reset - addendum 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>
|
#
82b662dc |
|
24-Dec-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: flush AT contexts after bus reset for OHCI 1.2 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 <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
dd23736e |
|
28-Nov-2010 |
Maxim Levitsky <maximlevitsky@gmail.com> |
firewire: ohci: restart iso DMA contexts on resume from low power mode Restore iso channels DMA so that iso channels could continue to work after resume from RAM/disk. Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
8662b6b0 |
|
28-Nov-2010 |
Maxim Levitsky <maximlevitsky@gmail.com> |
firewire: ohci: restore GUID on resume. Some lousy BIOSes, e.g. my Aspire 5720 BIOS forget to restore the GUID register on resume from RAM. Fix that by setting it to the last value that was read from it. Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
ec766a79 |
|
30-Nov-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: use common buffer for self IDs and AR descriptors The buffers used for the selfIDs packets and the AR request and response descriptors end up using three pages because dma_alloc_coherent() allocates at least one page per call. However, these data structures would all fit into 4 KB, so we can save space by using a common buffer for them. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
2dd5bed5 |
|
30-Nov-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: optimize iso context checks in the interrupt handler When the isochRx/isochTx bit is clear, we do not need to read the corresponding iso interrupt event register. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
5b06db16 |
|
30-Nov-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: make PHY packet header format consistent Change the header of PHY packets to be sent to include a pseudo transaction code. This makes the header consistent with that of received PHY packets, and allows at_context_queue_packet() and log_ar_at_event() to see the packet type directly instead of having to deduce it from the header length or even from the header contents. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
8327b37b |
|
30-Nov-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: properly clear posted write errors To remove the error information from the controller's queue and to allow more posted writes, the driver has to read the failed posted write address before clearing the postedWriteErr interrupt bit. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> (Stefan R:) The spec is somewhat fuzzy about the actual requirements. To err on the safe side, let's do these two read accesses. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
e597e989 |
|
30-Nov-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: flush MMIO writes in the interrupt handler Make sure that interrupt event clear bit writes are executed before the interrupt handler returns. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
c088ab30 |
|
30-Nov-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix AT context initialization error handling Add proper error handling for the context_init() calls. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
7a39d8b8 |
|
26-Nov-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: Asynchronous Reception rewrite Move the AR DMA descriptors out of the buffer pages, and map the buffer pages linearly into the kernel's address space. This allows the driver to ignore any page boundaries in the DMA data and thus to avoid any copying around of packet payloads. This fixes the bug where S800 packets that are so big (> 4080 bytes) that they can be split over three pages were not handled correctly. Due to the changed algorithm, we can now use arbitrarily many buffer pages, which improves performance because the controller can more easily unload its DMA FIFO. Furthermore, using streaming DMA mappings should improve perfomance on architectures where coherent DMA mappings are not cacheable. Even on other architectures, the caching behaviour should be improved slightly because the CPU no longer writes to the buffer pages. v2: Detect the last filled buffer page by searching the descriptor's residual count value fields in order (like in the old code), instead of going backwards through the transfer status fields; it looks as if some controllers do not set the latter correctly. v3: Fix an old resume bug that would now make the handler run into a BUG_ON, and replace that check with more useful error handling. Increase the buffer size for better performance with non-TI chips. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Maxim Levitsky writes: Works almost perfectly. I can still see RCODE_BUSY errors sometimes, not very often though. 64K here eliminates these errors completely. This is most likely due to nouveau drivers and lowest perf level I use to lower card temperature. That increases latencies too much I think. Besides that the IO is just perfect. Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
9993e0fe |
|
07-Dec-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix regression with Agere FW643 rev 06, disable MSI Agere FW643 rev 06, listed as "11c1:5901 (rev 06) (prog-if 10 [OHCI])", produced SBP-2 I/O errors since kernel 2.6.36. Disabling MSI fixes it. Since MSI work on Agere FW643-E (same vendor and device ID, but rev 07), introduce a device revision field into firewire-ohci's quirks list so that different quirks can be defined for older and newer revisions. Reported-by: Jonathan Isom <jeisom@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: <stable@kernel.org> # 2.6.36.y
|
#
af0cdf49 |
|
07-Dec-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix regression with VIA VT6315, disable MSI "VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]" does not generate any interrupts if Message Signaled Interrupts were enabled. This is a regression since kernel 2.6.36 in which MSI support was added to firewire-ohci. Hence blacklist MSI on all VIA controllers. Reported-by: Robin Cook <rcook@wyrms.net> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: <stable@kernel.org> # 2.6.36.y
|
#
693fa779 |
|
25-Oct-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix race when reading count in AR descriptor If the controller is storing a split packet and therefore changing d->res_count to zero between the two reads by the driver, we end up with an end pointer that is not at a packet boundary, and therefore overflow the buffer when handling the split packet. To fix this, read the field once, atomically. The compiler usually merges the two reads anyway, but for correctness, we have to enforce it. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
837596a6 |
|
25-Oct-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: avoid reallocation of AR buffers Freeing an AR buffer page just to allocate a new page immediately afterwards is not only a pointless effort but also dangerous because the allocation can fail, which would result in an oops later. Split ar_context_add_page() into two functions so that we can reuse the old page directly. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
a1f805e5 |
|
25-Oct-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix race in AR split packet handling When handling an AR buffer that has been completely filled, we assumed that its descriptor will not be read by the controller and can be overwritten. However, when the last received packet happens to end at the end of the buffer, the controller might not yet have moved on to the next buffer and might read the branch address later. If we overwrite and free the page before that, the DMA context will either go dead because of an invalid Z value, or go off into some random memory. To fix this, ensure that the descriptor does not get overwritten by using only the actual buffer instead of the entire page for reassembling the split packet. Furthermore, to avoid freeing the page too early, move on to the next buffer only when some data in it guarantees that the controller has moved on. This should eliminate the remaining firewire-net problems. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: 2.6.22-2.6.36 <stable@kernel.org> Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
85f7ffd5 |
|
25-Oct-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix buffer overflow in AR split packet handling When the controller had to split a received asynchronous packet into two buffers, the driver tries to reassemble it by copying both parts into the first page. However, if size + rest > PAGE_SIZE, i.e., if the yet unhandled packets before the split packet, the split packet itself, and any received packets after the split packet are together larger than one page, then the memory after the first page would get overwritten. To fix this, do not try to copy the data of all unhandled packets at once, but copy the possibly needed data every time when handling a packet. This gets rid of most of the infamous crashes and data corruptions when using firewire-net. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: 2.6.22-2.6.36 <stable@kernel.org> Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (cast PAGE_SIZE to size_t)
|
#
aa0170ff |
|
17-Oct-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix TI TSB82AA2 regression since 2.6.35 Revert commit 54672386ccf36ffa21d1de8e75624af83f9b0eeb "firewire: ohci: fix up configuration of TI chips". It caused massive slow-down and data corruption with a TSB82AA2 based StarTech EC1394B2 ExpressCard and FireWire 800 harddisks. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/657081 http://thread.gmane.org/gmane.linux.kernel.firewire.user/4013 The fact that some card EEPROMs do not program these enhancements may be related to TSB81BA3 phy chip errata, if not to bugs of TSB82AA2 itself. We could re-add these configuration steps, but only conditional on a whitelist of cards on which these enhancements bring a proven positive effect. Reported-and-tested-by: Eric Shattow <lucent@gmail.com> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@kernel.org> 2.6.35 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
970f4be8 |
|
06-Sep-2010 |
Heikki Lindholm <holin@iki.fi> |
firewire: ohci: activate cycle timer register quirk on Ricoh chips The Ricoh FireWire controllers appear to have the non-atomic cycle timer register access bug, so, activate the driver workaround by default. The behaviour was observed on: Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] and Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04). Signed-off-by: Heikki Lindholm <holin@iki.fi> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
a4dc090b |
|
28-Aug-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: work around VIA and NEC PHY packet reception bug VIA VT6306, VIA VT6308, and NEC OrangeLink controllers do not write packet event codes for received PHY packets (or perhaps write evt_no_status, hard to tell). Work around it by overwriting the packet's ACK by ack_complete, so that upper layers that listen to PHY packet reception get to see these packets. (Also tested: TI TSB82AA2, TI TSB43AB22/A, TI XIO2213A, Agere FW643, JMicron JMB381 --- these do not exhibit this bug.) Clemens proposed a quirks flag for that, IOW whitelist known misbehaving controllers for this workaround. Though to me it seems harmless enough to enable for all controllers. The log_ar_at_event() debug log will continue to show the original status from the DMA unit. Reported-by: Clemens Ladisch <clemens@ladisch.de> (VT6308) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
872e330e |
|
29-Jul-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: add isochronous multichannel reception This adds the DMA context programming and userspace ABI for multichannel reception, i.e. for listening on multiple channel numbers by means of a single DMA context. The use case is reception of more streams than there are IR DMA units offered by the link layer. This is already implemented by the older ohci1394 + ieee1394 + raw1394 stack. And as discussed recently on linux1394-devel, this feature is occasionally used in practice. The big drawbacks of this mode are that buffer layout and interrupt generation necessarily differ from single-channel reception: Headers and trailers are not stripped from packets, packets are not aligned with buffer chunks, interrupts are per buffer chunk, not per packet. These drawbacks also cause a rather hefty code footprint to support this rarely used OHCI-1394 feature. (367 lines added, among them 94 lines of added userspace ABI documentation.) This implementation enforces that a multichannel reception context may only listen to channels to which no single-channel context on the same link layer is presently listening to. OHCI-1394 would allow to overlay single-channel contexts by the multi-channel context, but this would be a departure from the present first-come-first-served policy of IR context creation. The implementation is heavily based on an earlier one by Jay Fenlason. Thanks Jay. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
e5b06c07 |
|
28-Jul-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: release channel in error path firewire-ohci keeps book of which isochronous channels are occupied by IR DMA contexts, so that there cannot be more than one context listening to a certain channel. If IR context creation failed due to an out-of-memory condition, this bookkeeping leaked a channel. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
071595eb |
|
27-Jul-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: use memory barriers to order descriptor updates When we append to a DMA program, we need to ensure that the order in which initialization of the new descriptors and update of the branch_address of the old tail descriptor, as seen by the PCI device, happen as intended. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
cc550216 |
|
18-Jul-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: cdev: add PHY pinging This extends the FW_CDEV_IOC_SEND_PHY_PACKET ioctl() for /dev/fw* to be useful for ping time measurements. One application for it would be gap count optimization in userspace that is based on ping times rather than hop count. (The latter is implemented in firewire-core itself but is not applicable to beta PHYs that act as repeater.) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
bf54e146 |
|
16-Jul-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: cdev: add PHY packet reception Add an FW_CDEV_IOC_RECEIVE_PHY_PACKETS ioctl() and FW_CDEV_EVENT_PHY_PACKET_RECEIVED poll()/read() event for /dev/fw*. This can be used to get information from remote PHYs by remote access PHY packets. This is also the 2nd half of the functionality (the receive part) to support a userspace implementation of a VersaPHY transaction layer. Safety considerations: - PHY packets are generally broadcasts, hence some kind of elevated privileges should be required of a process to be able to listen in on PHY packets. This implementation assumes that a process that is allowed to open the /dev/fw* of a local node does have this privilege. There was an inconclusive discussion about introducing POSIX capabilities as a means to check for user privileges for these kinds of operations. Other limitations: - PHY packet reception may be switched on by ioctl() but cannot be switched off again. It would be trivial to provide an off switch, but this is not worth the code. The client should simply close() the fd then, or just ignore further events. - For sake of simplicity of API and kernel-side implementation, no filter per packet content is provided. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
02d37bed |
|
08-Jul-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: core: integrate software-forced bus resets with bus management Bus resets which are triggered - by the kernel drivers after updates of the local nodes' config ROM, - by userspace software via ioctl shall be deferred until after >=2 seconds after the last bus reset. If multiple modifications of the local nodes' config ROM happen in a row, only a single bus reset should happen after them. When the local node's link goes from inactive to active or vice versa, and at the two occasions of bus resets mentioned above --- and if the current gap count differs from 63 --- the bus reset should be preceded by a PHY configuration packet that reaffirms the gap count. Otherwise a bus manager would have to reset the bus again right after that. This is necessary to promote bus stability, e.g. leave grace periods for allocations and reallocations of isochronous channels and bandwidth, SBP-2 reconnections etc.; see IEEE 1394 clause 8.2.1. This change implements all of the above by moving bus reset initiation into a delayed work (except for bus resets which are triggered by the bus manager workqueue job and are performed there immediately). It comes with a necessary addition to the card driver methods that allows to get the current gap count from PHY registers. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
0fcff4e3 |
|
12-Jun-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: rename CSR access driver methods Rather than "read a Control and Status Registers (CSR) Architecture register" I prefer to say "read a Control and Status Register". Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
c8a94ded |
|
12-Jun-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: normalize STATE_CLEAR/SET CSR access interface Push the maintenance of STATE_CLEAR/SET.abdicate down into the card driver. This way, the read/write_csr_reg driver method works uniformly across all CSR offsets. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
db3c9cc1 |
|
12-Jun-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: replace get_features card driver hook by feature variables in the fw_card struct. The hook appeared to be an unnecessary abstraction in the card driver interface. Cleaner would be to pass those feature flags as arguments to fw_card_initialize() or fw_card_add(), but the FairnessControl register is in the SCLK domain and may therefore not be accessible while Link Power Status is off, i.e. before the card->driver->enable call from fw_card_add(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
65b2742a |
|
12-Jun-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: 'add CSR_... support' addendum Add a comment on which of the conflicting NODE_IDS specifications we implement. Reduce a comment on rather irrelevant register bits that can all be looked up in the spec (or from now on in the code history). Directly include the required indirectly included bug.h. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
e91b2787 |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: allocate broadcast channel in hardware On OHCI 1.1 controllers, let the hardware allocate the broadcast channel automatically. This removes a theoretical race condition directly after a bus reset where it could be possible to read the channel allocation register with channel 31 still being unallocated. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
4ffb7a6a |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: add CSR cmstr support Implement the cmstr bit, which is required for cycle master capable nodes and tested for by the Base 1394 Test Suite. This bit allows the bus master to disable cycle start packets; there are bus master implementations that actually do this. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
a1a1132b |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: add CSR PRIORITY_BUDGET support If supported by the OHCI controller, implement the PRIORITY_BUDGET register, which is required for nodes that can use asynchronous priority arbitration. To allow the core to determine what features the lowlevel device supports, add a new card driver callback. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
27a2329f |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: add CSR BUSY_TIMEOUT support Implement the BUSY_TIMEOUT register, which is required for nodes that support retries. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
a48777e0 |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: add CSR BUS_TIME support Implement the BUS_TIME register, which is required for cycle master capable nodes and tested for by the Base 1393 Test Suite. Even when there is not yet bus master initialization support, this register allows us to work together with other bus masters. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
9ab5071c |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: add CSR CYCLE_TIME write support The specification requires that CYCLE_TIME is writable so that it can be initialized, so we better implement it. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
506f1a31 |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: add CSR NODE_IDS support The NODE_IDS register, and especially its bus_id field, is quite useless because 1394.1 requires that the bus_id field always stays 0x3ff. However, the 1394 specification requires this register on all transaction capable nodes, and the Base 1394 Test Suite tests for it, so we better implement it. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
60d32970 |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: add read_csr_reg driver callback To prepare for the following additions of more OHCI-implemented CSR registers, replace the get_cycle_time driver callback with a generic CSR register callback. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
153e3979 |
|
10-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: speed up PHY register accesses Most PHY chips, when idle, can complete a register access in the time needed for two or three PCI read transactions; bigger delays occur only when data is currently being moved over the link/PHY interface. So if we busy-wait a few times when waiting for the register access to finish, it is likely that we can finish without having to sleep. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
|
#
262444ee |
|
04-Jun-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: add MSI support This patch adds support for message-signaled interrupts. Any native PCI-Express OHCI controller should support MSI, but most are just PCI cores behind a PCI-E/PCI bridge. The only chips that are known to claim to support MSI are the Lucent/Agere/LSI FW643 and the VIA VT6315, none of which I have been able to test. Due to the high level of trust I have in the competence of these and any future chip makers, I thought it a good idea to add a disable-MSI quirk. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Tested Agere FW643 rev 07 [11c1:5901] and JMicron JMB381 [197b:2380]. Added a quirks list entry for JMB38X since it kept its count of MSI events consistently at zero. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
148c7866 |
|
05-Jun-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: do not enable interrupts without the handler On 26 Apr 2010, Clemens Ladisch wrote: > In theory, none of the interrupts should occur before the link is > enabled. In practice, I'd rather make sure to not set the master > interrupt enable bit until we have installed the interrupt handler. and proposed to move OHCI1394_masterIntEnable out of the present reg_write() into a new one before the HCControl.linkEnable reg_write(). Why not defer setting /all/ of the bits until right before linkEnable? Reviewed-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
e1393667 |
|
12-Apr-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: wait for local CSR lock access to finish Add a loop to wait for the controller to finish a locally-initiated CSR lock operation. Google shows some occurrences of the "swap not done yet" message which might indicate that some OHCI controllers are not fast enough to do the lock/swap in the time needed for one PCI access. This also correctly handles the case where the lock operation did not finish, instead of silently returning an uninitialized value. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
2608203d |
|
12-Apr-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: prevent aliasing of locally handled register addresses We must compute the offset from the CSR register base with the full 48 address bits to prevent matching with addresses whose lower 32 bits happen to be equal with one of the specially handled registers. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
5da3dac8 |
|
02-Apr-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: cleanups and fix for nonstandard build without debug facility 1) Clean up two function names: The ohci_ prefix is only used in names of fw_card_driver hooks. There were two unnecessary exceptions. 2) Replace empty macros by empty inline functions so that call parameter type checking is available in #ifndef'd builds. 3) CONFIG_FIREWIRE_OHCI_DEBUG is currently a hidden kconfig variable, hence is not going to be switched off by anybody. Still, it can be switched off but then compilation will fail in ohci_enable() at the expression param_debug & OHCI_PARAM_DEBUG_BUSRESETS. Add the necessary definitions in the nonstandard case. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
35d999b1 |
|
10-Apr-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: wait for PHY register accesses to complete Rather than having the arbitrary msleep(2) pause, let read_phy_reg() loop until the link--phy access was finished. Factor write_phy_reg() out of ohci_update_phy_reg() and of read_paged_phy_reg() and let it loop too until the link--phy access was finished. Like in the older ohci1394 driver, a timeout of 100 milliseconds is chosen. Unlike the old driver, we sleep instead of busy-wait in each waiting loop iteration. Instead of a loop, the waiting could probably also be implemented interrupt driven, but why bother. It would require up and running interrupt handling before the link was fully configured and enabled. Also modify functions a bit: Error return and value return can be combined in read_phy_reg() since the domain of values is only u8. Likewise in read_paged_phy_reg(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
54672386 |
|
01-Apr-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: fix up configuration of TI chips On TI chips (OHCI-Lynx and later), enable link enhancements features that TI recommends to be used. None of these are required for proper operation, but they are safe and nice to have. In theory, these bits should have been set by default, but in practice, some BIOS/EEPROM writers apparently do not read the datasheet, or get spooked by names like "unfair". Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
925e7a65 |
|
04-Apr-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: enable 1394a enhancements The OHCI spec says that, if the programPhyEnable bit is set, the driver is responsible for configuring the IEEE1394a enhancements within the PHY and the link consistently. So do this. Also add a quirk to allow disabling these enhancements; this is needed for the TSB12LV22 where ack accelerations are buggy (erratum b). Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
e7014dad |
|
01-Apr-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: do not clear PHY interrupt status inadvertently The interrupt status bits in PHY register 5 are cleared by writing a one bit. To avoid clearing them unadvertently, do not write them back when they were read as set, but only when they have been explicitly requested to be set. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
4a96b4fc |
|
04-Apr-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: add a function for reading PHY registers Move the register reading code from ohci_update_phy_reg() into a function which can be used separately. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
8301b91b |
|
17-Mar-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: add cycle timer quirk for the TI TSB12LV22 Among the many entries in the TSB12LV22 errata list (TI literature number SLLS312) is the following: PCI Slave reads of the Cycle Timer register may occasionally get an incorrect value. Software may be able to validate value by reading the register multiple times rapidly and evaluating for a reasonable difference. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> (untested) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added #define)
|
#
88393161 |
|
16-Mar-2010 |
Thomas Weber <swirl@gmx.li> |
Fix typos in comments [Ss]ytem => [Ss]ystem udpate => update paramters => parameters orginal => original Signed-off-by: Thomas Weber <swirl@gmx.li> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6fdb2ee2 |
|
21-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: extend initialization log message by the number of available isochronous DMA contexts and active quirks which is occasionally useful information. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
4802f16d |
|
21-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix IR/IT context mask mixup This bug was present in firewire-ohci since day one: The number of available isochronous receive DMA contexts was mixed up with that of available isochronous transmit DMA contexts. This is harmless on a few chips which offer the same number of contexts in both directions, but most chips nowadays implement only the standard minimum of 4 IR contexts, but 8 IT contexts. If a user attempted to run a lot of IR contexts at once, results with more than four were therefore unpredictable. I suppose the controller would simply refuse to start DMA of any unimplemented context. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
3e9cc2f3 |
|
21-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: add module parameter to activate quirk fixes This way, we can advise users of precompiled kernel packages to test existing quirk fixes on chips which have not been listed yet, without them having to build a kernel from source. Note, to use this feature on a machine with more than one controller, steps like these are necessary: # lspci | grep 1394 # ls /sys/bus/pci/drivers/firewire_ohci/ # echo -n "0000:03:02.0" > /sys/bus/pci/drivers/firewire_ohci/unbind # echo 2 > /sys/module/firewire_ohci/parameters/quirks # echo -n "0000:03:02.0" > /sys/bus/pci/drivers/firewire_ohci/bind # echo 0 > /sys/module/firewire_ohci/parameters/quirks The parameter can also be used to switch off quirk flags that were hardwired into firewire-ohci's quirks table. Simply specify a non-zero quirks value but without any known flags, e.g. 0x100. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
4a635593 |
|
21-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: use an ID table for quirks detection We don't have a lot of quirks to take into account (especially since dual-buffer IR is out of the picture), but still, a table-based approach is more organized than a series of if () clauses. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
ecb1cf9c |
|
21-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: reorder struct fw_ohci for better cache efficiency The config_rom struct members are only accessed during relatively infrequent self-ID-complete interrupts and only if the local config ROM was changed, while the ar_, at_, ir_, it_ members are used very frequently during I/O. Hence move the config_rom members further down. More importantly, make the huge self_id_buffer member the last one; this is only accessed in self-ID-complete interrupts. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
6498ba04 |
|
21-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: remove unused dualbuffer IR code This code was no longer used since 2.6.33, "firewire: ohci: always use packet-per-buffer mode for isochronous reception" commit 090699c0. If anybody needs this code in the future for special purposes, it can be brought back in. But it must not be re-enabled by default; drivers (kernelspace or userspace drivers) should only get this mode if they explicitly request it. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
168cf9af |
|
14-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: remove incomplete Bus_Time CSR support The current implementation of Bus_Time read access was buggy since it did not ensure that Bus_Time.second_count_hi and second_count_lo came from the same 128 seconds period. Reported-by: Håkan Johansson <f96hajo@chalmers.se> Instead of a fix, remove Bus_Time register support altogether. The spec requires all cycle master capable nodes to implement this (all Linux nodes are cycle master capable) while it also says that it "may" be initialized by the bus manager or by the IRM standing in for a bus manager. (Neither Linux' firewire-core nor ieee1394 nodemgr implement this.) Since we cannot rely on Bus_Time having been initialized by a bus manager, it is better to return an error instead of a nonsensical value on a read request to Bus_Time. Alternatively, we could fix the Bus_Time read integrity bug _and_ implement (a) cycle master's write support of the register as well as (b) bus manager's Bus_Time initialization service, i.e. preservation of the Bus_Time when the cycle master node of a bus changes. However, that would be quite some code for a feature that is unreliable to begin with and very likely unused in practice. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
4a9bde9b |
|
20-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: get_cycle_timer optimization and cleanup ohci: Break out of the retry loop if too many attempts were necessary. This may theoretically happen if the chip is fatally defective or if the get_cycle_timer ioctl was performed after a CardBus controller was ejected. Also micro-optimize the loop by re-using the last two register reads in the next iteration, remove a questionable inline keyword, and shuffle a comment around. core: ioctl_get_cycle_timer() is always called with interrupts on, therefore local_irq_save() can be replaced by local_irq_disable(). Disabled local IRQs imply disabled preemption, hence preempt_disable() can be removed. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
1c1517ef |
|
14-Feb-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: enable cycle timer fix on ALi and NEC controllers Discussed in "read_cycle_timer backwards for sub-cycle 0000, 0001", http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13704 Known bad controllers: ALi M5271, listed by lspci as M5253 [10b9:5253] NEC OrangeLink [1033:00cd] (rev 03) NEC uPD72874 [1033:00f2] (rev 01) VIA VT6306 [1106:3044] (rev 46) VIA VT6308P, listed by lspci as rev c0 Reported-by: Pieter Palmers <pieterp@joow.be> Reported-by: Håkan Johansson <f96hajo@chalmers.se> Reported-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
b677532b |
|
20-Jan-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: work around cycle timer bugs on VIA controllers VIA controllers sometimes return an inconsistent value when reading the isochronous cycle timer register. To work around this, read the register multiple times and add consistency checks. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reported-by: Pieter Palmers <pieterp@joow.be> Reported-by: Håkan Johansson <f96hajo@chalmers.se> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
7f51a100 |
|
08-Feb-2010 |
Clemens Ladisch <clemens@ladisch.de> |
firewire: ohci: retransmit isochronous transmit packets on cycle loss In isochronous transmit DMA descriptors, link the skip address pointer back to the descriptor itself. When a cycle is lost, the controller will send the packet in the next cycle, instead of terminating the entire DMA program. There are two reasons for this: * This behaviour is compatible with the old IEEE1394 stack. Old applications would not expect the DMA program to stop in this case. * Since the OHCI driver does not report any uncompleted packets, the context would stop silently; clients would not have any chance to detect and handle this error without a watchdog timer. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Pieter Palmers notes: "The reason I added this retry behavior to the old stack is because some cards now and then fail to send a packet (e.g. the o2micro card in my dell laptop). I couldn't figure out why exactly this happens, my best guess is that the card cannot fetch the payload data on time. This happens much more frequently when sending large packets, which leads me to suspect that there are some contention issues with the DMA that fills the transmit FIFO. In the old stack it was a pretty critical issue as it resulted in a freeze of the userspace application. The omission of a packet doesn't necessarily have to be an issue. E.g. in IEC61883 streams the DBC field can be used to detect discontinuities in the stream. So as long as the other side doesn't bail when no [packet] is present in a cycle, there is not really a problem. I'm not convinced though that retrying is the proper solution, but it is simple and effective for what it had to do. And I think there are no reasons not to do it this way. Userspace can still detect this by checking the cycle the descriptor was sent in." Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, comment)
|
#
7a481436 |
|
26-Jan-2010 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix crashes with TSB43AB23 on 64bit systems Unsurprisingly, Texas Instruments TSB43AB23 exhibits the same behaviour as TSB43AB22/A in dual buffer IR DMA mode: If descriptors are located at physical addresses above the 31 bit address range (2 GB), the controller will overwrite random memory. With luck, this merely prevents video reception. With only a little less luck, the machine crashes. We use the same workaround here as with TSB43AB22/A: Switch off the dual buffer capability flag and use packet-per-buffer IR DMA instead. Another possible workaround would be to limit the coherent DMA mask to 31 bits. In Linux 2.6.33, this change serves effectively only as documentation since dual buffer mode is not used for any controller anymore. But somebody might want to re-enable it in the future to make use of features of dual buffer DMA that are not available in packet-per-buffer mode. In Linux 2.6.32 and older, this update is vital for anyone with this controller, more than 2 GB RAM, a 64 bit kernel, and FireWire video or audio applications. We have at least four reports: http://bugzilla.kernel.org/show_bug.cgi?id=13808 http://marc.info/?l=linux1394-user&m=126154279004083 https://bugzilla.redhat.com/show_bug.cgi?id=552142 http://marc.info/?l=linux1394-user&m=126432246128386 Reported-by: Paul Johnson Reported-by: Ronneil Camara Reported-by: G Zornetzer Reported-by: Mark Thompson Cc: stable@kernel.org Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
a67483d2 |
|
10-Jan-2010 |
Németh Márton <nm127@freemail.hu> |
firewire: make PCI device id constant The id_table field of the struct pci_driver is constant in <linux/pci.h> so it is worth to make pci_table also constant. Found with Coccinelle. Signed-off-by: Márton Németh <nm127@freemail.hu> Cc: Julia Lawall <julia@diku.dk> Cc: cocci@diku.dk Signed-off-by: Stefan Richter stefanr@s5r6.in-berlin.de> (changelog)
|
#
090699c0 |
|
25-Dec-2009 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: always use packet-per-buffer mode for isochronous reception This is a minimal change meant for the short term: Never set the ohci->use_dualbuffer flag to true. There are two reasons to do so: - Packet-per-buffer mode and dual-buffer mode do not behave the same under certain circumstances, notably if several packets are covered by a single fw_cdev_iso_packet descriptor. http://marc.info/?l=linux1394-devel&m=124965653718313 Therefore the driver stack should not silently choose one or the other mode but should leave the choice to the high-level driver (regardless if kernel driver or userspace driver). Or simply always only offer packet-per-buffer mode, since a considerable number of controllers, even current ones, does not offer dual-buffer support. - Even under circumstances where packet-per-buffer mode and dual-buffer mode behave exactly the same --- notably when used through libraw1394, libdc1394, as well as the current two kernel drivers which use isochronous reception (firewire-net and firedtv) --- we are still faced with the problem that several OHCI 1.1 controllers have bugs in dual-buffer mode. Although it looks like we have identified most of those buggy controllers by now, we cannot be quite sure about that. So, use packet-per-buffer by default from now on. This change should be followed up by a more complete solution: Either extend the in-kernel API and the userspace ABI by a choice between the two IR modes or remove all dual-buffer related code from firewire-ohci. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
8c0c0cc2 |
|
11-Dec-2009 |
Jay Fenlason <fenlason@redhat.com> |
firewire: ohci: handle receive packets with a data length of zero Queueing to receive an ISO packet with a payload length of zero silently does nothing in dualbuffer mode, and crashes the kernel in packet-per-buffer mode. Return an error in dualbuffer mode, because the DMA controller won't let us do what we want, and work correctly in packet-per-buffer mode. Signed-off-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: stable@kernel.org
|
#
31769cef |
|
20-Nov-2009 |
Jay Fenlason <fenlason@redhat.com> |
firewire: ohci: pass correct iso xmit timestamps to core Here is the final set of patches I used to get ffado to work with the new firewire stack. With these patches, I was able to start ardour and record from and playback to my PreSonus Inspire1394 from a (mostly) Fedora 12 system. Signed-off-by: Jay Fenlason <fenlason@redhat.com> Until now, firewire-ohci exposed only the transmit cycle of the last transmitted packet at each isochronous transmit complete event. This made it impossible for FFADO (FireWire audio drivers in userspace) to synchronize audio-out streams. The fix is to store the timestamp of each packet in the iso xmit event. As a bonus, the transfer status is stored too. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
5ed1f321 |
|
16-Nov-2009 |
Jay Fenlason <fenlason@redhat.com> |
firewire: ohci: Make cycleMatch ISO transmission work Calling the START_ISO ioctl with a nonnegative cycle paramater has never worked. Last night I got around to figuring out why. Most of this patch is a big comment explaining why we enable an interrupt source then don't actually do anything when we get one. As the comment says, we should do more, but we don't have a way to tell userspace what happened. . . Signed-off-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (edited comment)
|
#
19593ffd |
|
14-Oct-2009 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: 0 may be a valid DMA address I was told that there are obscure architectures with non-coherent DMA which may DMA-map to bus address 0. We shall not use 0 as a magic number of uninitialized bus address variables. The packet->payload_length > 0 test cannot be used either (except in at_context_queue_packet) because local requests are not DMA-mapped regardless of payload_length. Hence add a state flag to struct fw_packet. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
8e85973e |
|
07-Oct-2009 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: optimize config ROM creation The config ROM image of the local node was created in CPU byte order, then a temporary big endian copy was created to compute the CRC, and finally the card driver created its own big endian copy. We now generate it in big endian byte order in the first place to avoid one byte order conversion and the temporary on-stack copy of the ROM image (1000 bytes stack usage in process context). Furthermore, two 1000 bytes memset()s are replaced by one 1000 bytes - ROM length sized memset. The trivial fw_memcpy_{from,to}_be32() helpers are now superfluous and removed. The newly added __compute_block_crc() function will be folded into fw_compute_block_crc() in a subsequent change. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
928ec5f1 |
|
06-Sep-2009 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix Self ID Count register mask (safeguard against buffer overflow) The selfIDSize field of Self ID Count is 9 bits wide, and we are only interested in the high 8 bits. Fix the mask accordingly. The previously too large mask didn't do damage though because the next few bits in the register are reserved and therefore zero with presently existing hardware. Also, check for the maximum possible self ID count of 252 (according to OHCI 1.1 clause 11.2 and IEEE 1394a-2000 clause 4.3.4.1, i.e. up to four self IDs of up to 63 nodes, even though IEEE 1394 up to edition 2008 defines only up to three self IDs per node). More than 252 self IDs would only happen if the self ID receive DMA unit malfunctioned, which would likely be caught by other self ID buffer checks. However, check it early to be sure. More than 253 quadlets would overflow the Topology Map CSR. Reported-By: PaX Team Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
4fe0badd |
|
28-Aug-2009 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix Ricoh R5C832, video reception In dual-buffer DMA mode, no video frames are ever received from R5C832 by libdc1394. Fallback to packet-per-buffer DMA works reliably. http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13393/focus=13476 Reported-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
fc383796 |
|
28-Aug-2009 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: ohci: fix Agere FW643 and multiple cameras An Agere FW643 OHCI 1.1 card works fine for video reception from one camera but fails early if receiving from two cameras. After a short while, no IR IRQ events occur and the context control register does not react anymore. This happens regardless whether both IR DMA contexts are dual-buffer or one is dual-buffer and the other packet-per-buffer. This can be worked around by disabling dual buffer DMA mode entirely. http://sourceforge.net/mailarchive/message.php?msg_name=4A7C0594.2020208%40gmail.com (Reported by Samuel Audet.) In another report (by Jonathan Cameron), an FW643 works OK with two cameras in dual buffer mode. Whether this is due to different chip revisions or different usage patterns (different video formats) is not yet clear. However, as far as the current capabilities of firewire-core's isochronous I/O interface are concerned, simply switching off dual-buffer on non-working and working FW643s alike is not a problem in practice. We only need to revisit this issue if we are going to enhance the interface, e.g. so that applications can explicitly choose modes. Reported-by: Samuel Audet <samuel.audet@gmail.com> Reported-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
#
e71d31da |
|
05-Jun-2009 |
Stefan Richter <stefanr@s5r6.in-berlin.de> |
firewire: rename source files The source files of firewire-core, firewire-ohci, firewire-sbp2, i.e. "drivers/firewire/fw-*.c" are renamed to "drivers/firewire/core-*.c", "drivers/firewire/ohci.c", "drivers/firewire/sbp2.c". The old fw- prefix was redundant to the directory name. The new core- prefix distinguishes the files according to which driver they belong to. This change comes a little late, but still before further firewire drivers are added as anticipated RSN. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|