kernel/linux.git/drivers/firewire/ohci.c, branch v6.6.131

firewire: ohci: fulfill timestamp for some local asynchronous transaction

2024-05-17T10:02:30+00:00

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

firewire: ohci: mask bus reset interrupts between ISR and bottom half

2024-05-17T10:02:13+00:00

[ Upstream commit 752e3c53de0fa3b7d817a83050b6699b8e9c6ec9 ] 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 Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin

firewire: ohci: prevent leak of left-over IRQ on unbind

2024-04-03T13:28:41+00:00

commit 575801663c7dc38f826212b39e3b91a4a8661c33 upstream. 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 Link: https://lore.kernel.org/r/20240229144723.13047-2-edmund.raile@proton.me Signed-off-by: Takashi Sakamoto Signed-off-by: Greg Kroah-Hartman

firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards

2024-01-10T16:17:00+00:00

commit ac9184fbb8478dab4a0724b279f94956b69be827 upstream. 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 Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 Reported-by: Mario Limonciello Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 Reported-by: Tobias Gruetzmacher 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 Signed-off-by: Greg Kroah-Hartman

firewire: ohci: release buffer for AR req/resp contexts when managed resource is released

2023-06-05T22:54:24+00:00

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

firewire: ohci: use devres for content of configuration ROM

2023-06-05T22:54:23+00:00

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

firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contexts

2023-06-05T22:54:23+00:00

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

firewire: ohci: use devres for list of isochronous contexts

2023-06-05T22:54:23+00:00

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

firewire: ohci: use devres for requested IRQ

2023-06-05T22:54:23+00:00

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

firewire: ohci: use devres for misc DMA buffer

2023-06-05T22:54:23+00:00

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