summaryrefslogtreecommitdiff
path: root/drivers/firewire/ohci.c
AgeCommit message (Collapse)AuthorFilesLines
2024-07-08Revert "firewire: ohci: use common macro to interpret be32 data in le32 buffer"Takashi Sakamoto1-1/+1
This reverts commit f26a38e61c03fdfacb6b596e1daf665cf4526a60, since it causes the following sparse warnings: sparse warnings: (new ones prefixed by >>) >> drivers/firewire/ohci.c:891:23: sparse: sparse: cast to restricted __be32 >> drivers/firewire/ohci.c:891:23: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:892:23: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:892:23: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:893:23: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:893:23: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:905:31: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:905:31: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:914:31: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:914:31: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:939:18: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:939:18: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:2033:23: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:2033:23: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:2037:27: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:2037:27: sparse: sparse: cast from restricted __le32 drivers/firewire/ohci.c:2038:27: sparse: sparse: cast to restricted __be32 drivers/firewire/ohci.c:2038:27: sparse: sparse: cast from restricted __le32 Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407050656.03bw1YXA-lkp@intel.com/ Link: https://lore.kernel.org/r/20240707134523.11784-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-07-04firewire: ohci: add tracepoints event for data of Self-ID DMATakashi Sakamoto1-1/+10
In 1394 OHCI, the SelfIDComplete event occurs when the hardware has finished transmitting all of the self ID packets received during the bus initialization process to the host memory by DMA. This commit adds a tracepoints event for this event to trace the timing and packet data of Self-ID DMA. It is the part of following tracepoints events helpful to debug some events at bus reset; e.g. the issue addressed at a commit d0b06dc48fb1 ("firewire: core: use long bus reset on gap count error")[1]: * firewire_ohci:irqs * firewire_ohci:self_id_complete * firewire:bus_reset_handle * firewire:self_id_sequence They would be also helpful in the problem about invocation timing of hardIRQ and process (workqueue) contexts. We can often see this kind of problem with -rt kernel[2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0b06dc48fb1 [2] https://lore.kernel.org/linux-rt-users/YAwPoaUZ1gTD5y+k@hmbx/ Link: https://lore.kernel.org/r/20240702222034.1378764-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-07-04firewire: ohci: use inline functions to operate data of self-ID DMATakashi Sakamoto1-5/+7
The code of 1394 OHCI driver includes hard-coded magic number to operate data of Self-ID DMA. This commit replaces them with the inline functions added/tested in the former commit. Link: https://lore.kernel.org/r/20240702222034.1378764-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-07-04firewire: ohci: use static function to handle endian issue on PowerPC platformTakashi Sakamoto1-12/+27
It is preferable to use static function instead of functional macro in some points. It checks type of argument, but would be optimized to embedded code instead of function calls. This commit obsoletes the functional macro with the static function. Additionally this commit refactors quirk detection to ease the later work. Link: https://lore.kernel.org/r/20240702222034.1378764-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-07-04firewire: ohci: use common macro to interpret be32 data in le32 bufferTakashi Sakamoto1-1/+1
The 1394 OHCI driver configures the hardware to transfer the data quadlets of packet via DMA after converting it to little endian, therefore the data is typed as __le32. Nevertheless some actual hardware ignores the configuration. In the case, the data in DMA buffer is aligned to big endian (__be32). For the case in big-endian machine, the driver includes the following interpretation from __le32 to u32 (host-endian = __be32): * (__force __u32)(v) In include/linux/byteorder/generic.h, be32_to_cpu() is available. It is expanded to the following expression in 'include/uapi/linux/byteorder/big_endian.h': * (__force __u32)(__be32)(x) This commit replace the ad-hoc endian interpretation with the above. Link: https://lore.kernel.org/r/20240702222034.1378764-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-06-25firewire: ohci: add tracepoints event for hardIRQ eventTakashi Sakamoto1-0/+1
1394 OHCI hardware triggers PCI interrupts to notify any events to software. Current driver for the hardware is programmed by the typical way to utilize top- and bottom- halves, thus it has a timing gap to handle the notification in softIRQ (tasklet). This commit adds a tracepoint event for the hardIRQ event. The comparison of the tracepoint event to tracepoints events in firewire subsystem is helpful to diagnose the timing gap. Link: https://lore.kernel.org/r/20240625031806.956650-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-06-25firewire: ohci: add support for Linux kernel tracepointsTakashi Sakamoto1-0/+3
The Linux Kernel Tracepoints framework is enough useful to trace the interaction between 1394 OHCI hardware and its driver. This commit adds firewire_ohci subsystem to use the framework. It is defined as the different subsystem from the existing firewire subsystem. The definition file for the existing subsystem is slightly changed so that both subsystems are available in 1394 OHCI driver. Link: https://lore.kernel.org/r/20240625031806.956650-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-06-25firewire: core: add tracepoints events for completions of packets in ↵Takashi Sakamoto1-6/+17
isochronous context It is helpful to trace completion of packets in isochronous context when the core function is requested them by both in-kernel units driver and userspace applications. This commit adds some tracepoints events for the aim. Link: https://lore.kernel.org/r/20240623220859.851685-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-06-25firewire: core: add tracepoints events for flushing completions of ↵Takashi Sakamoto1-0/+2
isochronous context It is helpful to trace the flushing completions of isochronous context when the core function is requested them by both in-kernel unit drivers and userspace applications. This commit adds some tracepoints events for the aim. Link: https://lore.kernel.org/r/20240623220859.851685-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-06-17firewire: ohci: use helper inline functions to serialize/deserialize self ID ↵Takashi Sakamoto1-24/+45
packet This commit replaces the existing implementation with the helper functions for self ID packet. Link: https://lore.kernel.org/r/20240605235155.116468-10-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-06-17firewire: ohci: use helper functions for self ID sequenceTakashi Sakamoto1-28/+49
This commit replaces the existing implementation with the helper functions for self ID sequence. Link: https://lore.kernel.org/r/20240605235155.116468-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-06-17firewire: ohci: minor code refactoring for self ID loggingTakashi Sakamoto1-14/+22
Current implementation to log self ID sequence has the rest to be refactored; e.g. moving translation-unit level variables to the dependent block. This commit is for the purpose. Link: https://lore.kernel.org/r/20240605235155.116468-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: obsolete OHCI_PARAM_DEBUG_BUSRESETS from debug module parameterTakashi Sakamoto1-8/+1
The OHCI_PARAM_DEBUG_BUSRESETS bit of debug module parameter was added at a commit a007bb857e0b ("firewire: fw-ohci: conditionally log busReset interrupts"). At the former commit, the bit becomes less meaningful, just to skip logging. This commit obsoletes it. Link: https://lore.kernel.org/r/20240501073238.72769-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: add bus-reset event for initial set of handled irqTakashi Sakamoto1-6/+5
In the former commits, the spurious interrupt events are suppressed as possible, by unset bus-reset event from the set of handled irq. The change was written with the less-intrusive style, thus it firstly works at the second time to handle the event. But it is slightly inconvenient. This commit adds the event for the initial set of irq to handle. As a result, the event can be handled even if it is the first time. The change has a benefit that the OHCI_PARAM_DEBUG_BUSRESETS bit in debug module parameter is always effective. Tested-by: Adam Goldman <adamg@pobox.com> Link: https://lore.kernel.org/r/20240501073238.72769-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: core: obsolete tcode check macros with inline functionsTakashi Sakamoto1-3/+3
This commit declares the helper functions to check tcode to obsolete the functional macros. Link: https://lore.kernel.org/r/20240428071347.409202-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace hard-coded values with common macrosTakashi Sakamoto1-4/+14
In the helper function for logging in 1394 ohci driver includes the hard-coded variables for transaction code. They can be replaced with the enumerations in UAPI header. Link: https://lore.kernel.org/r/20240428071347.409202-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace hard-coded values with inline functions for ↵Takashi Sakamoto1-15/+15
asynchronous packet header This commit replaces the hard-coded values with the common inline functions to serialize and deserialize the header of asynchronous packet. Link: https://lore.kernel.org/r/20240428071347.409202-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace local macros with common inline functions for ↵Takashi Sakamoto1-16/+8
asynchronous packet header This commit uses the common inline functions to serialize and deserialize header of asynchronous packet. Link: https://lore.kernel.org/r/20240428071347.409202-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: use pci_irq_vector() to retrieve allocated interrupt lineTakashi Sakamoto1-5/+13
The pci_irq_vector() is available to retrieve the allocated interrupt line instead of the direct access to the member of device structure. Link: https://lore.kernel.org/r/20240331135037.191479-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: obsolete usage of deprecated API for MSITakashi Sakamoto1-4/+9
The usage of the pair of pci_enable_msi() and pci_disable_msi() is deprecated. This commit uses the preferred pair of API for the purpose. The call of pci_alloc_irq_vectors() can have a subeffect to change the return value of pci_dev_msi_enabled(). Link: https://lore.kernel.org/r/20240331135037.191479-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06firewire: ohci: replace request_irq() with request_threaded_irq()Takashi Sakamoto1-4/+4
Nowadays request_irq() is a wrapper of request_threaded_irq(). The IRQ handler of 1394 ohci driver has never been optimized yet, while it is a good preparation for the future work to replace the latter. This commit replaces the former. Link: https://lore.kernel.org/r/20240331135037.191479-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-05-06Revert "firewire: ohci: use devres for requested IRQ"Takashi Sakamoto1-6/+8
This reverts commit 5a95f1ded28691e69f7d6718c5dcbc149613d431. As long as allocating any device interrupt vector for MSI, it is inconvenient to utilize managed device resources for IRQ requesting. Link: https://lore.kernel.org/r/20240331135037.191479-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-04-29firewire: ohci: fulfill timestamp for some local asynchronous transactionTakashi Sakamoto1-2/+6
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>
2024-04-06firewire: ohci: mask bus reset interrupts between ISR and bottom halfAdam Goldman1-1/+5
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>
2024-03-06firewire: ohci: prevent leak of left-over IRQ on unbindEdmund Raile1-0/+2
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>
2024-01-05firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ↵Takashi Sakamoto1-0/+51
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>
2023-06-06firewire: ohci: release buffer for AR req/resp contexts when managed ↵Takashi Sakamoto1-17/+14
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>
2023-06-06firewire: ohci: use devres for content of configuration ROMTakashi Sakamoto1-18/+9
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>
2023-06-06firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contextsTakashi Sakamoto1-15/+8
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>
2023-06-06firewire: ohci: use devres for list of isochronous contextsTakashi Sakamoto1-10/+9
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>
2023-06-06firewire: ohci: use devres for requested IRQTakashi Sakamoto1-8/+4
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>
2023-06-06firewire: ohci: use devres for misc DMA bufferTakashi Sakamoto1-10/+3
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>
2023-06-06firewire: ohci: use devres for MMIO region mappingTakashi Sakamoto1-20/+6
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>
2023-06-06firewire: ohci: use devres for PCI-related resourcesTakashi Sakamoto1-7/+3
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>
2023-06-06firewire: ohci: use devres for memory object of ohci structureTakashi Sakamoto1-16/+17
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>
2023-05-30firewire: core: use union for callback of transaction completionTakashi Sakamoto1-2/+15
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>
2021-03-17firewire: ohci: Use tasklet_disable_in_atomic() where requiredSebastian Andrzej Siewior1-2/+2
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
2020-09-25firewire-ohci: use dma_alloc_pagesChristoph Hellwig1-15/+11
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>
2020-08-24treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva1-2/+2
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>
2020-07-16treewide: Remove uninitialized_var() usageKees Cook1-7/+7
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>
2020-06-16firewire: ohci: Replace zero-length array with flexible-arrayGustavo A. R. Silva1-1/+1
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>
2019-11-13firewire: ohci: stop using get_seconds() for BUS_TIMEArnd Bergmann1-1/+1
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>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156Thomas Gleixner1-14/+1
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>
2019-04-08drivers: Remove explicit invocations of mmiowb()Will Deacon1-1/+0
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>
2018-02-03Merge tag 'firewire-updates' of ↵Linus Torvalds1-1/+7
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire updates from Stefan Richter - make JMicron JMB38x controllers work with IOMMU-equipped systems - IP-over-1394: allow user-configured MTU of up to 4096 bytes * tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire-ohci: work around oversized DMA reads on JMicron controllers firewire: net: max MTU off by one
2018-01-13firewire-ohci: work around oversized DMA reads on JMicron controllersHector Martin1-1/+7
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>
2017-10-25locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns ↵Mark Rutland1-6/+4
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>
2015-11-05firewire: ohci: propagate return code from soft_reset to probe and resumeStefan Richter1-2/+3
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>
2015-11-05firewire: ohci: fix JMicron JMB38x IT context discoveryStefan Richter1-0/+5
Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo controllers: Often or even most of the time, the controller is initialized with the message "added OHCI v1.10 device as card 0, 4 IR + 0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts (IT contexts), applications like audio output are impossible. However, OHCI-1394 demands that at least 4 IT contexts are implemented by the link layer controller, and indeed JMicron JMB38x do implement four of them. Only their IsoXmitIntMask register is unreliable at early access. With my own JMB381 single function controller I found: - I can reproduce the problem with a lower probability than Craig's. - If I put a loop around the section which clears and reads IsoXmitIntMask, then either the first or the second attempt will return the correct initial mask of 0x0000000f. I never encountered a case of needing more than a second attempt. - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet) before the first write, the subsequent read will return the correct result. - If I merely ignore a wrong read result and force the known real result, later isochronous transmit DMA usage works just fine. So let's just fix this chip bug up by the latter method. Tested with JMB381 on kernel 3.13 and 4.3. Since OHCI-1394 generally requires 4 IT contexts at a minium, this workaround is simply applied whenever the initial read of IsoXmitIntMask returns 0, regardless whether it's a JMicron chip or not. I never heard of this issue together with any other chip though. I am not 100% sure that this fix works on the OHCI-1394 part of JMB380 and JMB388 combo controllers exactly the same as on the JMB381 single- function controller, but so far I haven't had a chance to let an owner of a combo chip run a patched kernel. Strangely enough, IsoRecvIntMask is always reported correctly, even though it is probed right before IsoXmitIntMask. Reported-by: Clifford Dunn Reported-by: Craig Moore <craig.moore@qenos.com> Cc: stable@vger.kernel.org Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2015-01-22firewire: ohci: Remove unused functionRickard Strandqvist1-5/+0
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>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-22 14:00:49 +0300