summaryrefslogtreecommitdiff
path: root/drivers/usb/host
AgeCommit message (Collapse)AuthorFilesLines
6 daysusb: xhci: fix host not responding after suspend and resumeNiklas Neronin1-0/+2
Partially revert commit e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") because the patch cleared the Interrupt Pending bit during interrupt enabling and disabling. The Interrupt Pending bit should only be cleared when the driver has handled the interrupt. Ideally, all interrupts should be handled before disabling the interrupt; consequently, no interrupt should be pending when enabling the interrupt. For this reason, keep the debug message informing if an interrupt is still pending when an interrupt is disabled. Because the Interrupt Pending bit is write-1-to-clear, writing '0' to it ensures that the state does not change. Link: https://lore.kernel.org/linux-usb/20250818231103.672ec7ed@foxbook Fixes: e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") Closes: https://bbs.archlinux.org/viewtopic.php?id=307641 cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250819125844.2042452-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 daysusb: xhci: Fix slot_id resource race conflictWeitao Wang5-23/+35
xHC controller may immediately reuse a slot_id after it's disabled, giving it to a new enumerating device before the xhci driver freed all resources related to the disabled device. In such a scenario, device-A with slot_id equal to 1 is disconnecting while device-B is enumerating, device-B will fail to enumerate in the follow sequence. 1.[device-A] send disable slot command 2.[device-B] send enable slot command 3.[device-A] disable slot command completed and wakeup waiting thread 4.[device-B] enable slot command completed with slot_id equal to 1 and wakeup waiting thread 5.[device-B] driver checks that slot_id is still in use (by device-A) in xhci_alloc_virt_device, and fail to enumerate due to this conflict 6.[device-A] xhci->devs[slot_id] set to NULL in xhci_free_virt_device To fix driver's slot_id resources conflict, clear xhci->devs[slot_id] and xhci->dcbba->dev_context_ptrs[slot_id] pointers in the interrupt context when disable slot command completes successfully. Simultaneously, adjust function xhci_free_virt_device to accurately handle device release. [minor smatch warning and commit message fix -Mathias] Cc: stable@vger.kernel.org Fixes: 7faac1953ed1 ("xhci: avoid race between disable slot command and host runtime suspend") Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250819125844.2042452-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: renesas-xhci: Fix External ROM access timeoutsMarek Vasut1-3/+4
Increase the External ROM access timeouts to prevent failures during programming of External SPI EEPROM chips. The current timeouts are too short for some SPI EEPROMs used with uPD720201 controllers. The current timeout for Chip Erase in renesas_rom_erase() is 100 ms , the current timeout for Sector Erase issued by the controller before Page Program in renesas_fw_download_image() is also 100 ms. Neither timeout is sufficient for e.g. the Macronix MX25L5121E or MX25V5126F. MX25L5121E reference manual [1] page 35 section "ERASE AND PROGRAMMING PERFORMANCE" and page 23 section "Table 8. AC CHARACTERISTICS (Temperature = 0°C to 70°C for Commercial grade, VCC = 2.7V ~ 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 2 s, and for Sector Erase it is 300 ms . MX25V5126F reference manual [2] page 47 section "13. ERASE AND PROGRAMMING PERFORMANCE (2.3V - 3.6V)" and page 42 section "Table 8. AC CHARACTERISTICS (Temperature = -40°C to 85°C for Industrial grade, VCC = 2.3V - 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 3.2 s, and for Sector Erase it is 400 ms . Update the timeouts such, that Chip Erase timeout is set to 5 seconds, and Sector Erase timeout is set to 500 ms. Such lengthy timeouts ought to be sufficient for majority of SPI EEPROM chips. [1] https://www.macronix.com/Lists/Datasheet/Attachments/8634/MX25L5121E,%203V,%20512Kb,%20v1.3.pdf [2] https://www.macronix.com/Lists/Datasheet/Attachments/8750/MX25V5126F,%202.5V,%20512Kb,%20v1.1.pdf Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Cc: stable <stable@kernel.org> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20250802225526.25431-1-marek.vasut+renesas@mailbox.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-25usb: xhci: print xhci->xhc_state when queue_command failedSu Hui1-1/+2
When encounters some errors like these: xhci_hcd 0000:4a:00.2: xHCI dying or halted, can't queue_command xhci_hcd 0000:4a:00.2: FIXME: allocate a command ring segment usb usb5-port6: couldn't allocate usb_device It's hard to know whether xhc_state is dying or halted. So it's better to print xhc_state's value which can help locate the resaon of the bug. Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20250725060117.1773770-1-suhui@nfschina.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-17usb: xhci: Set avg_trb_len = 8 for EP0 during Address Device CommandJay Chen1-0/+2
There is a subtle contradiction between sections of the xHCI 1.2 spec regarding the initialization of Input Endpoint Context fields. Section 4.8.2 ("Endpoint Context Initialization") states that all fields should be initialized to 0. However, Section 6.2.3 ("Endpoint Context", p.453) specifies that the Average TRB Length (avg_trb_len) field shall be greater than 0, and explicitly notes (p.454): "Software shall set Average TRB Length to '8' for control endpoints." Strictly setting all fields to 0 during initialization conflicts with the specific recommendation for control endpoints. In practice, setting avg_trb_len = 0 is not meaningful for the hardware/firmware, as the value is used for bandwidth calculation. Motivation: Our company is developing a custom Virtual xHC hardware platform that strictly follows the xHCI spec and its recommendations. During validation, we observed that enumeration fails and a parameter error (TRB Completion Code = 5) is reported if avg_trb_len for EP0 is not set to 8 as recommended by Section 6.2.3. This demonstrates the importance of assigning a meaningful, non-zero value to avg_trb_len, even in virtualized or emulated environments. This patch explicitly sets avg_trb_len to 8 for EP0 in xhci_setup_addressable_virt_dev(), as recommended in Section 6.2.3, to prevent potential issues with xHCI host controllers that enforce the spec strictly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220033 Signed-off-by: Jay Chen <shawn2000100@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250717073107.488599-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-17usb: xhci: Avoid showing warnings for dying controllerMario Limonciello1-2/+4
When a USB4 dock is unplugged from a system it won't respond to ring events. The PCI core handles the surprise removal event and notifies all PCI drivers. The XHCI PCI driver sets a flag that the device is being removed, and when the device stops responding a flag is also added to indicate it's dying. When that flag is set don't bother to show warnings about a missing controller. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250717073107.488599-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-17usb: xhci: Avoid showing errors during surprise removalMario Limonciello1-2/+5
When a USB4 dock is unplugged from a system it won't respond to ring events. The PCI core handles the surprise removal event and notifies all PCI drivers. The XHCI PCI driver sets a flag that the device is being removed as well. When that flag is set don't show messages in the cleanup path for marking the controller dead. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250717073107.488599-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-05Merge merge point of tag 'usb-6.16-rc5' into usb-nextGreg Kroah-Hartman8-32/+44
We need the USB fixes in here as well to build on top of for other changes that depend on them. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28xhci: dbc: Flush queued requests before stopping dbcMathias Nyman1-0/+4
Flush dbc requests when dbc is stopped and transfer rings are freed. Failure to flush them lead to leaking memory and dbc completing odd requests after resuming from suspend, leading to error messages such as: [ 95.344392] xhci_hcd 0000:00:0d.0: no matched request Cc: stable <stable@kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250627144127.3889714-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28xhci: dbctty: disable ECHO flag by defaultŁukasz Bartosik1-0/+1
When /dev/ttyDBC0 device is created then by default ECHO flag is set for the terminal device. However if data arrives from a peer before application using /dev/ttyDBC0 applies its set of terminal flags then the arriving data will be echoed which might not be desired behavior. Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: stable <stable@kernel.org> Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/stable/20250610111802.18742-1-ukaszb%40chromium.org Link: https://lore.kernel.org/r/20250627144127.3889714-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28xhci: Disable stream for xHC controller with XHCI_BROKEN_STREAMSHongyu Xie1-1/+2
Disable stream for platform xHC controller with broken stream. Fixes: 14aec589327a6 ("storage: accept some UAS devices if streams are unavailable") Cc: stable <stable@kernel.org> Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250627144127.3889714-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-28usb: xhci: quirk for data loss in ISOC transfersRaju Rangoju3-0/+30
During the High-Speed Isochronous Audio transfers, xHCI controller on certain AMD platforms experiences momentary data loss. This results in Missed Service Errors (MSE) being generated by the xHCI. The root cause of the MSE is attributed to the ISOC OUT endpoint being omitted from scheduling. This can happen when an IN endpoint with a 64ms service interval either is pre-scheduled prior to the ISOC OUT endpoint or the interval of the ISOC OUT endpoint is shorter than that of the IN endpoint. Consequently, the OUT service is neglected when an IN endpoint with a service interval exceeding 32ms is scheduled concurrently (every 64ms in this scenario). This issue is particularly seen on certain older AMD platforms. To mitigate this problem, it is recommended to adjust the service interval of the IN endpoint to not exceed 32ms (interval 8). This adjustment ensures that the OUT endpoint will not be bypassed, even if a smaller interval value is utilized. Cc: stable <stable@kernel.org> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250627144127.3889714-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-24usb: ehci: replace scnprintf() with sysfs_emit()Hendrik Hamerlinck1-12/+6
Per Documentation/filesystems/sysfs.rst, show() methods should only use sysfs_emit() or sysfs_emit_at() when formatting values to be returned to userspace. Convert the uses of scnprintf() in sysfs show() methods to sysfs_emit() and sysfs_emit_at() for better safety and consistency. Signed-off-by: Hendrik Hamerlinck <hendrik.hamerlinck@hammernet.be> Link: https://lore.kernel.org/r/20250623140950.61568-1-hendrik.hamerlinck@hammernet.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19Revert "usb: xhci: Implement xhci_handshake_check_state() helper"Roy Luo3-30/+3
This reverts commit 6ccb83d6c4972ebe6ae49de5eba051de3638362c. Commit 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state() helper") was introduced to workaround watchdog timeout issues on some platforms, allowing xhci_reset() to bail out early without waiting for the reset to complete. Skipping the xhci handshake during a reset is a dangerous move. The xhci specification explicitly states that certain registers cannot be accessed during reset in section 5.4.1 USB Command Register (USBCMD), Host Controller Reset (HCRST) field: "This bit is cleared to '0' by the Host Controller when the reset process is complete. Software cannot terminate the reset process early by writinga '0' to this bit and shall not write any xHC Operational or Runtime registers until while HCRST is '1'." This behavior causes a regression on SNPS DWC3 USB controller with dual-role capability. When the DWC3 controller exits host mode and removes xhci while a reset is still in progress, and then tries to configure its hardware for device mode, the ongoing reset leads to register access issues; specifically, all register reads returns 0. These issues extend beyond the xhci register space (which is expected during a reset) and affect the entire DWC3 IP block, causing the DWC3 device mode to malfunction. Cc: stable <stable@kernel.org> Fixes: 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state() helper") Signed-off-by: Roy Luo <royluo@google.com> Link: https://lore.kernel.org/r/20250522190912.457583-3-royluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19usb: xhci: Skip xhci_reset in xhci_resume if xhci is being removedRoy Luo1-1/+4
xhci_reset() currently returns -ENODEV if XHCI_STATE_REMOVING is set, without completing the xhci handshake, unless the reset completes exceptionally quickly. This behavior causes a regression on Synopsys DWC3 USB controllers with dual-role capabilities. Specifically, when a DWC3 controller exits host mode and removes xhci while a reset is still in progress, and then attempts to configure its hardware for device mode, the ongoing, incomplete reset leads to critical register access issues. All register reads return zero, not just within the xHCI register space (which might be expected during a reset), but across the entire DWC3 IP block. This patch addresses the issue by preventing xhci_reset() from being called in xhci_resume() and bailing out early in the reinit flow when XHCI_STATE_REMOVING is set. Cc: stable <stable@kernel.org> Fixes: 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state() helper") Suggested-by: Mathias Nyman <mathias.nyman@intel.com> Signed-off-by: Roy Luo <royluo@google.com> Link: https://lore.kernel.org/r/20250522190912.457583-2-royluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19usb: ohci-at91: Use dynamic device name for OHCI HCD creationMihai Sain1-1/+1
Use the dynamic device name instead of the hardcoded string "at91" when creating the OHCI host controller driver. This ensures that the device name is more flexible and correctly reflects the actual device in the system. This will be in sync with ehci at91 driver. Before this patch: [root@sam9x75eb ~]$ dmesg | grep usb [ 1.464487] usb usb1: Manufacturer: Linux 6.16.0-rc2 ehci_hcd [ 1.470210] usb usb1: SerialNumber: 700000.usb-ehci [ 1.595683] usb usb2: Manufacturer: Linux 6.16.0-rc2 ohci_hcd [ 1.601406] usb usb2: SerialNumber: at91 After this patch: [root@sam9x75eb ~]$ dmesg | grep usb [ 1.464487] usb usb1: Manufacturer: Linux 6.16.0-rc2 ehci_hcd [ 1.470210] usb usb1: SerialNumber: 700000.usb-ehci [ 1.595683] usb usb2: Manufacturer: Linux 6.16.0-rc2 ohci_hcd [ 1.601406] usb usb2: SerialNumber: 600000.usb-ohci Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250616061759.3384-2-mihai.sain@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19usb: fsl-mph-dr-of: Remove unnecessary NULL check before clk_disable_unprepare()Chen Ni1-2/+1
clk_disable_unprepare() already checks NULL by using IS_ERR_OR_NULL. Remove unneeded NULL check for clk here. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://lore.kernel.org/r/20250617041917.1930885-1-nichen@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19usb: ohci-spear: Remove unnecessary NULL check before clk_disable_unprepare()Chen Ni1-2/+1
clk_disable_unprepare() already checks NULL by using IS_ERR_OR_NULL. Remove unneeded NULL check for clk here. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250617042050.1930940-1-nichen@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19usb: host: xhci-plat: fix incorrect type for of_match variable in ↵Seungjin Bae1-1/+1
xhci_plat_probe() The variable `of_match` was incorrectly declared as a `bool`. It is assigned the return value of of_match_device(), which is a pointer of type `const struct of_device_id *`. Fixes: 16b7e0cccb243 ("USB: xhci-plat: fix legacy PHY double init") Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Link: https://lore.kernel.org/r/20250619055746.176112-2-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-08treewide, timers: Rename from_timer() to timer_container_of()Ingo Molnar8-10/+13
Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
2025-05-21xhci: Add missing parameter description to xhci_get_endpoint_index()Hans Zhang1-0/+1
Fix kernel-doc warning by documenting the @desc parameter: drivers/usb/host/xhci.c:1369: warning: Function parameter or struct member 'desc' not described in 'xhci_get_endpoint_index' Add detailed description of the @desc parameter and clarify the indexing logic for control endpoints vs other types. This brings the documentation in line with kernel-doc requirements while maintaining technical accuracy. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://lore.kernel.org/r/20250506033101.206180-1-18255117159@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: rename 'irq_control' to 'imod'Niklas Neronin2-12/+12
The Interrupt Register Set contains Interrupt Moderation register (IMOD). The IMOD register contains the following fields: - Bits 15:0: Interrupt Moderation Interval (IMODI) - Bits 31:16: Interrupt Moderation Counter (IMODC) In the xHCI driver, the pointer currently named 'irq_control' refers to the IMOD register. However, the name 'irq_control' does not accurately describe the register or its contents, and the xHCI specification does not use the term "irq control" or "interrupt control" for this register. To improve clarity and better align with the xHCI specification, the pointer is renamed to 'imod'. Additionally, the IMOD register fields IMODI & IMODC have their own masks, which are also renamed for consistency: * 'ER_IRQ_INTERVAL_MASK' -> 'IMODI_MASK' * 'ER_IRQ_COUNTER_MASK' -> 'IMODC_MASK' Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-23-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: rename 'irq_pending' to 'iman'Niklas Neronin3-17/+17
The Interrupt Register Set contains Interrupt Management register (IMAN). The IMAN register contains the following fields: - Bit 0: Interrupt Pending (IP) - Bit 1: Interrupt Enable (IE) - Bits 31:2: RsvdP (Reserved and Preserved) Tn the xhci driver, the pointer currently named 'irq_pending' refers to the IMAN register. However, the name "irq_pending" only describes one of the fields within the IMAN register, rather than the entire register itself. To improve clarity and better align with the xHCI specification, the pointer is renamed to 'iman'. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-22-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: cleanup IMOD register commentsNiklas Neronin1-15/+18
Patch does not contain any functional changes. Add missing macro descriptions with specific bit definitions for each data field and reordered them accordingly. Remove "HW use only" from Interrupt Moderation Counter. xHCI Specification 1.2, section 5.5.2.2, states "This counter may be directly written by software at any time to alter the interrupt rate." Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-21-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: rework Event Ring Segment Table Address maskNiklas Neronin2-3/+4
Event Ring Segment Table Base Address Register contain two fields: - Bits 5:0: RsvdP (Reserved and Preserved) - Bits 63:6: Event Ring Segment Table Base Address Currently, an inverted RsvdP mask (ERST_BASE_RSVDP) is used to extract bits 63:6. Replaces the inverted mask with a non-inverted mask, 'ERST_BASE_ADDRESS_MASK', which makes the code easier to read. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-20-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: rework Event Ring Segment Table Size maskNiklas Neronin2-4/+4
Event Ring Segment Table Size Register contain two fields: - Bits 15:0: Event Ring Segment Table Size - Bits 31:16: RsvdZ (Reserved and Zero) The current mask 'ERST_SIZE_MASK' refers to the RsvdZ bits (31:16). Change the mask to refer to bits 15:0, which are the Event Ring Segment Table Size bits. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-19-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: remove '0' write to write-1-to-clear registerNiklas Neronin4-9/+10
xHCI specification 1.2, section 5.5.2.1. Interrupt Pending bit is RW1C (Write-1-to-clear), which means that writing '0' to is has no effect and is removed. The Interrupt Pending (IP) bit is cleared at the start of interrupt handling; xhci_clear_interrupt_pending(). This could theoretically cause a new interrupt to be issued before the xhci driver reaches the interrupter disable functions. To address this, the IP bit is read after Interrupt Enable is disabled, and a debug message is issued if the IP bit is still set. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: guarantee that IMAN register is flushedNiklas Neronin2-0/+6
Add read call to guarantee that the write to the IMAN register has been flushed. xHCI specification 1.2, section 5.5.2.1, Note: "Most systems have write buffers that minimize overhead, but this may require a read operation to guarantee that the write has been flushed from the posted buffer." Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: improve Interrupt Management register macrosNiklas Neronin2-12/+10
The Interrupt Management register (IMAN), contains three fields: - Bit 0: Interrupt Pending (IP) - Bit 1: Interrupt Enable (IE) - Bits 31:2: RsvdP (Reserved and Preserved) Currently, there are multiple macros for both the IP and IE fields. Consolidates them into single mask macros for better clarity and maintainability. Comment "THIS IS BUGGY - FIXME - IP IS WRITE 1 TO CLEAR" refers to the fact that both macros 'ER_IRQ_ENABLE' and 'ER_IRQ_DISABLE' clear the IP bit by writing '0' before modifying the IE bit. However, the IP bit is actually cleared by writing '1'. To prevent any regression, this behavior has not been altered. Instead, when the IE bit is modified, the IP macro is used explicitly to highlight this "quirk". Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: set requested IMODI to the closest supported valueNiklas Neronin2-6/+6
The function configures the Interrupt Moderation Interval (IMODI) via bits 15:0 in the Interrupt Moderation Register. The IMODI value is specified in increments of 250 nanoseconds. For instance, an IMODI register value of 16 corresponds to 4000 nanoseconds, resulting in an interrupt every ~1ms. Currently, the function fails when a requested IMODI value is too large, only logging a warning message for secondary interrupters. Prevent this by automatically adjusting the IMODI value to the nearest supported value. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: cleanup xhci_mem_init()Niklas Neronin1-25/+27
Cleanup indentation, spacing and comment formats. Remove the "// " prefix from trace messages, as it is unnecessary and distracting. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: add individual allocation checks in xhci_mem_init()Niklas Neronin1-4/+11
Break up the existing multi-allocation checks into individual checks. Add missing allocation check for 'xhci->interrupters'. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: move initialization of the primary interrupterNiklas Neronin3-13/+14
Move the primary interrupter (0) initialization from xhci_mem_init() to xhci_init(). This change requires us to save the allocated interrupter somewhere before initialization. Therefore, store it in the 'interrupters' array and rework xhci_add_interrupter() to retrieve the interrupter from the array. This is part of the ongoing effort to separate allocation and initialization. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: remove error handling from xhci_add_interrupter()Niklas Neronin1-19/+8
Remove redundant error handling from xhci_add_interrupter() instead of trying to accommodate them in future changes. ======== Reasoning for the removal ======== Function xhci_add_interrupter() is invoked in two scenarios: Primary Interrupter Setup (ID 0): The maximum number of interrupters is always greater than zero, and the primary interrupter is always allocated as part of the driver's initialization process. In case of failure, the xHCI driver errors and exits. Secondary Interrupter Creation (ID >= 1): The interrupter is pre-allocated, and an empty slot is identified before invoking xhci_add_interrupter(). In both cases, the existing error handling within xhci_add_interrupter() is redundant and unnecessary. Upcoming Changes: In the subsequent commit, interrupter initialization will move from xhci_mem_init() to xhci_init(). This change is necessary to facilitate the ability to restart the xHCI driver without re-allocating memory. As a result, the allocated interrupter must be stored in the interrupters pointer array before initialization. Consequently, xhci_create_secondary_interrupter() would need to handle pointer removal for allocated 'interrupters' array upon failure, although xhci_add_interrupter() will never fail. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: move enabling of USB 3 device notificationsNiklas Neronin3-12/+18
Relocated the enabling of USB 3.0 device notifications from xhci_mem_init() to xhci_init(). Introduced xhci_set_dev_notifications() function to handle the notification settings. Simplify 'DEV_NOTE_FWAKE' masks by directly using the 'ENABLE_DEV_NOTE' value (1 << 1) instead of using the 'ENABLE_DEV_NOTE' macro. Macro 'ENABLE_DEV_NOTE' is removed. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: move doorbell array pointer assignmentNiklas Neronin3-10/+15
Move the assignment of the doorbell array pointer from xhci_mem_init() to xhci_init(). The assignment now utilizes the newly introduced xhci_set_doorbell_ptr() function. Doorbell Array Offset mask (DBOFF_MASK) is updated to directly specify its bit range as 31:2, rather than using inverted reserved bits 1:0. This change simplifies the mask representation, making it more intuitive and easier to understand. Remove the "// " prefix from trace messages, as it is unnecessary and distracting. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: move DCBAA pointer writeNiklas Neronin2-1/+3
Move the Device Context Base Address Array (DCBAA) pointer write from xhci_mem_init() to xhci_init(). This is part of the ongoing effort to separate allocation and initialization. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: refactor xhci_set_cmd_ring_deq()Niklas Neronin2-17/+19
Refactor xhci_set_cmd_ring_deq() making the code more understandable by using more descriptive constants and separating operations logically. - Remove 'CMD_RING_RSVD_BITS' the macro is misleading, the reserved bits are 5:4, yet the mask is for bits 5:0. - Introduce masks 'CMD_RING_PTR_MASK' and 'CMD_RING_CYCLE' to clearly define the bits for the Command Ring pointer and Command Ring Cycle. - Simplifying the process of setting the command ring address by separating the DMA address calculation and the Command Ring Control register (crcr) updates. - Remove the "// " prefix from trace messages, as it is unnecessary and distracting. Note: In the current implementation, the cycle bit is not cleared before applying the OR operation. Although this hasn't caused issues so far because the bit is '0' before reaching this function, the bit is now cleared before being set to prevent potential future problems and simplify the process. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: move command ring pointer writeNiklas Neronin2-27/+20
Move command ring pointer write from xhci_mem_init() to xhci_init(), and utilize the xhci_set_cmd_ring_deq() function. The xhci_set_cmd_ring_deq() function is nearly identical to the Command Ring Control register code in xhci_mem_init(). The only notable change is the use of: xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg, xhci->cmd_ring->dequeue) instead of: xhci->cmd_ring->first_seg->dma but they are effectively the same in this context. The former represents the exact position of the dequeue pointer, while the latter is the first DMA in the first segment. Before use, the dequeue pointer is at the first DMA in the first segment. The xhci_set_cmd_ring_deq() function is moved without modification, except for (long unsigned long) -> (unsigned long long) due to checkpatch.pl. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: move device slot enabling register writeNiklas Neronin2-14/+22
Refactor the setting of the Number of Device Slots Enabled field into a separate function, relocating it to xhci_init(). The xHCI driver consistently sets the number of enabled device slots to the maximum value. The new function is named to reflect this behavior. Remove the "// " prefix from trace messages, as it is unnecessary and distracting. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: relocate pre-allocation initializationNiklas Neronin2-31/+26
Move pre-allocation initialization from xhci_mem_init() to xhci_init(). This change is part of an ongoing effort to separate initialization from allocation within the xhci driver. By doing so, it will enable future patches to re-initialize xhci driver memory without the necessity of fully recreating it. Additionally, compliance mode recovery initialization has been adjusted to only occur after successful memory allocation. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: Add debugfs support for xHCI port bandwidthXu Rao5-1/+215
In many projects, you need to obtain the available bandwidth of the xhci roothub port. Refer to xhci rev1_2 and use the TRB_GET_BW command to obtain it. hardware tested: 03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 (prog-if 30 [XHCI]) Subsystem: Huawei Technologies Co., Ltd. Raven USB 3.1 Flags: bus master, fast devsel, latency 0, IRQ 30 Memory at c0300000 (64-bit, non-prefetchable) [size=1M] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/8 Maskable- 64bit+ Capabilities: [c0] MSI-X: Enable+ Count=8 Masked- Kernel driver in use: xhci_hcd test progress: 1. cd /sys/kernel/debug/usb/xhci/0000:03:00.3/port_bandwidth# ls FS_BW HS_BW SS_BW 2. test fs speed device cat FS_BW port[1] available bw: 90%. port[2] available bw: 90%. port[3] available bw: 90%. port[4] available bw: 90%. port[5] available bw: 0%. port[6] available bw: 0%. port[7] available bw: 0%. port[8] available bw: 0%. plug in fs usb audio ID 0d8c:013c cat FS_BW port[1] available bw: 76%. port[2] available bw: 76%. port[3] available bw: 76%. port[4] available bw: 76%. port[5] available bw: 0%. port[6] available bw: 0%. port[7] available bw: 0%. port[8] available bw: 0%. 3. test hs speed device cat HS_BW port[1] available bw: 79%. port[2] available bw: 79%. port[3] available bw: 79%. port[4] available bw: 79%. port[5] available bw: 0%. port[6] available bw: 0%. port[7] available bw: 0%. port[8] available bw: 0%. plug in hs usb video ID 0408:1040 cat HS_BW port[1] available bw: 39%. port[2] available bw: 39%. port[3] available bw: 39%. port[4] available bw: 39%. port[5] available bw: 0%. port[6] available bw: 0%. port[7] available bw: 0%. port[8] available bw: 0%. 4.cat SS_BW port[1] available bw: 0%. port[2] available bw: 0%. port[3] available bw: 0%. port[4] available bw: 0%. port[5] available bw: 90%. port[6] available bw: 90%. port[7] available bw: 90%. port[8] available bw: 90%. Signed-off-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-21usb: xhci: Don't log transfer ring segment list on errorsMichal Pecio1-3/+0
The error message above used to span two lines, rarely more. A recent cleanup concentrated useful information from it in one line, but then it added printing the list of all ring segments, which is even longer than before. It provides no new information in usual cases and little in unusual ones, but adds noise to the log. Drop it. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250515135621.335595-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-13Merge 6.15-rc6 into usb-nextGreg Kroah-Hartman5-14/+32
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-05xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive.Mathias Nyman2-3/+19
Event polling delay is set to 0 if there are any pending requests in either rx or tx requests lists. Checking for pending requests does not work well for "IN" transfers as the tty driver always queues requests to the list and TRBs to the ring, preparing to receive data from the host. This causes unnecessary busylooping and cpu hogging. Only set the event polling delay to 0 if there are pending tx "write" transfers, or if it was less than 10ms since last active data transfer in any direction. Cc: Łukasz Bartosik <ukaszb@chromium.org> Fixes: fb18e5bb9660 ("xhci: dbc: poll at different rate depending on data transfer activity") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250505125630.561699-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-05usb: xhci: Don't trust the EP Context cycle bit when moving HW dequeueMichal Pecio1-10/+9
VIA VL805 doesn't bother updating the EP Context cycle bit when the endpoint halts. This is seen by patching xhci_move_dequeue_past_td() to print the cycle bits of the EP Context and the TRB at hw_dequeue and then disconnecting a flash drive while reading it. Actual cycle state is random as expected, but the EP Context bit is always 1. This means that the cycle state produced by this function is wrong half the time, and then the endpoint stops working. Work around it by looking at the cycle bit of TD's end_trb instead of believing the Endpoint or Stream Context. Specifically: - rename cycle_found to hw_dequeue_found to avoid confusion - initialize new_cycle from td->end_trb instead of hw_dequeue - switch new_cycle toggling to happen after end_trb is found Now a workload which regularly stalls the device works normally for a few hours and clearly demonstrates the HW bug - the EP Context bit is not updated in a new cycle until Set TR Dequeue overwrites it: [ +0,000298] sd 10:0:0:0: [sdc] Attached SCSI disk [ +0,011758] cycle bits: TRB 1 EP Ctx 1 [ +5,947138] cycle bits: TRB 1 EP Ctx 1 [ +0,065731] cycle bits: TRB 0 EP Ctx 1 [ +0,064022] cycle bits: TRB 0 EP Ctx 0 [ +0,063297] cycle bits: TRB 0 EP Ctx 0 [ +0,069823] cycle bits: TRB 0 EP Ctx 0 [ +0,063390] cycle bits: TRB 1 EP Ctx 0 [ +0,063064] cycle bits: TRB 1 EP Ctx 1 [ +0,062293] cycle bits: TRB 1 EP Ctx 1 [ +0,066087] cycle bits: TRB 0 EP Ctx 1 [ +0,063636] cycle bits: TRB 0 EP Ctx 0 [ +0,066360] cycle bits: TRB 0 EP Ctx 0 Also tested on the buggy ASM1042 which moves EP Context dequeue to the next TRB after errors, one problem case addressed by the rework that implemented this loop. In this case hw_dequeue can be enqueue, so simply picking the cycle bit of TRB at hw_dequeue wouldn't work. Commit 5255660b208a ("xhci: add quirk for host controllers that don't update endpoint DCS") tried to solve the stale cycle problem, but it was more complex and got reverted due to a reported issue. Cc: Jonathan Bell <jonathan@raspberrypi.org> Cc: Oliver Neukum <oneukum@suse.com> Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250505125630.561699-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-01usb: uhci-platform: Make the clock really optionalAlexey Charkov1-1/+1
Device tree bindings state that the clock is optional for UHCI platform controllers, and some existing device trees don't provide those - such as those for VIA/WonderMedia devices. The driver however fails to probe now if no clock is provided, because devm_clk_get returns an error pointer in such case. Switch to devm_clk_get_optional instead, so that it could probe again on those platforms where no clocks are given. Cc: stable <stable@kernel.org> Fixes: 26c502701c52 ("usb: uhci: Add clk support to uhci-platform") Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20250425-uhci-clock-optional-v1-1-a1d462592f29@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-01usb: host: tegra: Prevent host controller crash when OTG port is usedJim Lin1-0/+3
When a USB device is connected to the OTG port, the tegra_xhci_id_work() routine transitions the PHY to host mode and calls xhci_hub_control() with the SetPortFeature command to enable port power. In certain cases, the XHCI controller may be in a low-power state when this operation occurs. If xhci_hub_control() is invoked while the controller is suspended, the PORTSC register may return 0xFFFFFFFF, indicating a read failure. This causes xhci_hc_died() to be triggered, leading to host controller shutdown. Example backtrace: [ 105.445736] Workqueue: events tegra_xhci_id_work [ 105.445747] dump_backtrace+0x0/0x1e8 [ 105.445759] xhci_hc_died.part.48+0x40/0x270 [ 105.445769] tegra_xhci_set_port_power+0xc0/0x240 [ 105.445774] tegra_xhci_id_work+0x130/0x240 To prevent this, ensure the controller is fully resumed before interacting with hardware registers by calling pm_runtime_get_sync() prior to the host mode transition and xhci_hub_control(). Fixes: f836e7843036 ("usb: xhci-tegra: Add OTG support") Cc: stable <stable@kernel.org> Signed-off-by: Jim Lin <jilin@nvidia.com> Signed-off-by: Wayne Chang <waynec@nvidia.com> Link: https://lore.kernel.org/r/20250422114001.126367-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-28Merge 6.15-rc4 into usb-nextGreg Kroah-Hartman5-35/+49
We need the USB fixes in here as well, and this resolves the following merge conflicts that were reported in linux-next: drivers/usb/chipidea/ci_hdrc_imx.c drivers/usb/host/xhci.h Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-25USB: host: omap: Do not enable by default during compile testingKrzysztof Kozlowski1-1/+1
Enabling the compile test should not cause automatic enabling of all drivers, but only allow to choose to compile them. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250417074634.81295-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-25 10:01:29 +0300