aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2025-03-06usb: xhci: Unify duplicate inc_enq() codeMichal Pecio1-75/+55
Extract a block of code copied from inc_enq() into a separate function and call it from inc_enq() and the other function which used this code. Remove the pointless 'next' variable which only aliases ring->enqueue. Note: I don't know if any 0.95 xHC ever reached series production, but "AMD 0.96 host" appears to be the "Llano" family APU. Example dmesg at https://linux-hardware.org/?probe=79d5cfd4fd&log=dmesg pci 0000:00:10.0: [1022:7812] type 00 class 0x0c0330 hcc params 0x014042c3 hci version 0x96 quirks 0x0000000000000608 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/20250306144954.3507700-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: Apply the link chain quirk on NEC isoc endpointsMichal Pecio1-2/+11
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment: [ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000] It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000. [ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000. [ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2 It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain. Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board. [ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set. The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times. No negative side effects seen in UVC recording and UAC playback with a few devices at full speed, high speed and SuperSpeed. The problem doesn't reproduce on the newer Renesas uPD720201/uPD720202 and on old Etron EJ168 and VIA VL805 (but the VL805 has other bug). [shorten line length of log snippets in commit messge -Mathias] Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250306144954.3507700-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06xhci: Prevent early endpoint restart when handling STALL errors.Mathias Nyman3-3/+13
Ensure that an endpoint halted due to device STALL is not restarted before a Clear_Feature(ENDPOINT_HALT) request is sent to the device. The host side of the endpoint may otherwise be started early by the 'Set TR Deq' command completion handler which is called if dequeue is moved past a cancelled or halted TD. Prevent this with a new flag set for bulk and interrupt endpoints when a Stall Error is received. Clear it in hcd->endpoint_reset() which is called after Clear_Feature(ENDPOINT_HALT) is sent. Also add a debug message if a class driver queues a new URB after the STALL. Note that class driver might not be aware of the STALL yet when it submits the URB as URBs are given back in BH. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250306144954.3507700-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: move debug capabilities from trb_in_td() to handle_tx_event()Niklas Neronin1-21/+17
Function trb_in_td() currently includes debug capabilities that are triggered when its debug argument is set to true. The only consumer of these debug capabilities is handle_tx_event(), which calls trb_in_td() twice, once for its primary functionality and a second time solely for debugging purposes if the first call returns 'NULL'. This approach is inefficient and can lead to confusion, as trb_in_td() executes the same code with identical arguments twice, differing only in the debug output during the second execution. To enhance clarity and efficiency, move the debug capabilities out of trb_in_td() and integrates them directly into handle_tx_event(). This change reduces the argument count of trb_in_td() and ensures that debug steps are executed only when necessary, streamlining the function's operation. 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/20250306144954.3507700-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: refactor trb_in_td() to be staticNiklas Neronin2-63/+61
Relocate trb_in_td() and marks it as static, as it's exclusively utilized in xhci-ring.c. This adjustment lays the groundwork for future rework of the function. The function's logic remains unchanged; only its access specifier is altered to static and a redundant "else" is removed on line 325 (due to checkpatch.pl complaining). 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/20250306144954.3507700-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: set page size to the xHCI-supported sizeNiklas Neronin2-20/+22
The current xHCI driver does not validate whether a page size of 4096 bytes is supported. Address the issue by setting the page size to the value supported by the xHCI controller, as read from the Page Size register. In the event of an unexpected value; default to a 4K page size. Additionally, this commit removes unnecessary debug messages and instead prints the supported and used page size once. The xHCI controller supports page sizes of (2^{(n+12)}) bytes, where 'n' is the Page Size Bit. Only one page size is supported, with a maximum page size of 128 KB. 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/20250306144954.3507700-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: correct debug message page size calculationNiklas Neronin1-3/+3
The ffs() function returns the index of the first set bit, starting from 1. If no bits are set, it returns zero. This behavior causes an off-by-one page size in the debug message, as the page size calculation [1] is zero-based, while ffs() is one-based. Fix this by subtracting one from the result of ffs(). Note that since variable 'val' is unsigned, subtracting one from zero will result in the maximum unsigned integer value. Consequently, the condition 'if (val < 16)' will still function correctly. [1], Page size: (2^(n+12)), where 'n' is the set page size bit. Fixes: 81720ec5320c ("usb: host: xhci: use ffs() in xhci_mem_init()") 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/20250306144954.3507700-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: Skip only one TD on Ring Underrun/OverrunMichal Pecio1-1/+14
If skipping is deferred to events other than Missed Service Error itsef, it means we are running on an xHCI 1.0 host and don't know how many TDs were missed until we reach some ordinary transfer completion event. And in case of ring xrun, we can't know where the xrun happened either. If we skip all pending TDs, we may prematurely give back TDs added after the xrun had occurred, risking data loss or buffer UAF by the xHC. If we skip none, a driver may become confused and stop working when all its URBs are missed and appear to be "in flight" forever. Skip exactly one TD on each xrun event - the first one that was missed, as we can now be sure that the HC has finished processing it. Provided that one more TD is queued before any subsequent doorbell ring, it will become safe to skip another TD by the time we get an xrun again. 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/20250306144954.3507700-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: Expedite skipping missed isoch TDs on modern HCsMichal Pecio1-4/+10
xHCI spec rev. 1.0 allowed the TRB pointer of Missed Service events to be NULL. Having no idea which of the queued TDs were missed and which are waiting, we can only set a flag to skip missed TDs later. But HCs are also allowed to give us pointer to the last missed TRB, and this became mandatory in spec rev. 1.1 and later. Use this pointer, if available, to immediately skip all missed TDs. This reduces latency and risk of skipping-related bugs, because we can now leave the skip flag cleared for future events. Handle Missed Service Error events as 'error mid TD', if applicable, because rev. 1.0 spec excplicitly says so in notes to 4.10.3.2 and later revs in 4.10.3.2 and 4.11.2.5.2. Notes to 4.9.1 seem to apply. Tested on ASM1142 and ASM3142 v1.1 xHCs which provide TRB pointers. Tested on AMD, Etron, Renesas v1.0 xHCs which provide TRB pointers. Tested on NEC v0.96 and VIA v1.0 xHCs which send a NULL pointer. Change inspired by a discussion about realtime USB audio. Link: https://lore.kernel.org/linux-usb/76e1a191-020d-4a76-97f6-237f9bd0ede0@gmx.net/T/ 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/20250306144954.3507700-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: Fix isochronous Ring Underrun/Overrun event handlingMichal Pecio1-6/+14
The TRB pointer of these events points at enqueue at the time of error occurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time we are handling the event, a new TD may be queued at this ring position. I can trigger this race by rising interrupt moderation to increase IRQ handling delay. Similar delay may occur naturally due to system load. If this ever happens after a Missed Service Error, missed TDs will be skipped and the new TD processed as if it matched the event. It could be given back prematurely, risking data loss or buffer UAF by the xHC. Don't complete TDs on xrun events and don't warn if queued TDs don't match the event's TRB pointer, which can be NULL or a link/no-op TRB. Don't warn if there are no queued TDs at all. Now that it's safe, also handle xrun events if the skip flag is clear. This ensures completion of any TD stuck in 'error mid TD' state right before the xrun event, which could happen if a driver submits a finite number of URBs to a buggy HC and then an error occurs on the last TD. 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/20250306144954.3507700-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: Complete 'error mid TD' transfers when handling Missed ServiceMichal Pecio1-1/+5
Missed Service Error after an error mid TD means that the failed TD has already been passed by the xHC without acknowledgment of the final TRB, a known hardware bug. So don't wait any more and give back the TD. Reproduced on NEC uPD720200 under conditions of ludicrously bad USB link quality, confirmed to behave as expected using dynamic debug. 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/20250306144954.3507700-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: Don't skip on Stopped - Length InvalidMichal Pecio1-0/+4
Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped") in v6.11, the driver didn't skip missed isochronous TDs when handling Stoppend and Stopped - Length Invalid events. Instead, it erroneously cleared the skip flag, which would cause the ring to get stuck, as future events won't match the missed TD which is never removed from the queue until it's cancelled. This buggy logic seems to have been in place substantially unchanged since the 3.x series over 10 years ago, which probably speaks first and foremost about relative rarity of this case in normal usage, but by the spec I see no reason why it shouldn't be possible. After d56b0b2ab142, TDs are immediately skipped when handling those Stopped events. This poses a potential problem in case of Stopped - Length Invalid, which occurs either on completed TDs (likely already given back) or Link and No-Op TRBs. Such event won't be recognized as matching any TD (unless it's the rare Link TRB inside a TD) and will result in skipping all pending TDs, giving them back possibly before they are done, risking isoc data loss and maybe UAF by HW. As a compromise, don't skip and don't clear the skip flag on this kind of event. Then the next event will skip missed TDs. A downside of not handling Stopped - Length Invalid on a Link inside a TD is that if the TD is cancelled, its actual length will not be updated to account for TRBs (silently) completed before the TD was stopped. I had no luck producing this sequence of completion events so there is no compelling demonstration of any resulting disaster. It may be a very rare, obscure condition. The sole motivation for this patch is that if such unlikely event does occur, I'd rather risk reporting a cancelled partially done isoc frame as empty than gamble with UAF. This will be fixed more properly by looking at Stopped event's TRB pointer when making skipping decisions, but such rework is unlikely to be backported to v6.12, which will stay around for a few years. Fixes: d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped") Cc: stable@vger.kernel.org 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/20250306144954.3507700-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06usb: xhci: remove redundant update_ring_for_set_deq_completion() functionNiklas Neronin1-39/+2
The function is a remnant from a previous implementation and is now redundant. There is no longer a need to search for the dequeue pointer, as both the TRB and segment dequeue pointers are saved within 'queued_deq_seg' and 'queued_deq_ptr'. 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/20250306144954.3507700-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06xhci: show correct U1 and U2 timeout values in debug messagesMathias Nyman1-4/+4
U2 value is encoded in 256 microsecond intervals, show in microseconds. U1 value is in microseconds. debug message incorrectly showed "ms" Unwrap debug messages while we anyway modify them. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250306144954.3507700-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: dwc3: exynos: add support for exynos7870Kaustabh Chakraborty1-0/+9
Exynos7870 devices have a DWC3 compatible USB 2.0 controller. Add support in the driver by: - Adding its own compatible string, "samsung,exynos7870-dwusb3". - Adding three USBDRD clocks named "bus_early", "ref", and "ctrl", to be controlled by the driver. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250301-exynos7870-usb-v3-2-f01697165d19@disroot.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03dt-bindings: usb: samsung,exynos-dwc3: add exynos7870 supportKaustabh Chakraborty1-1/+27
Document compatible string for Exynos7870 DWC3-compatible USB 2.0 driver. The devicetree node requires three clocks, named "bus_early", "ref", and "ctrl". Unlike other variants, Exynos7870's USB controller requires a single 3.0V regulator. Assert that the other 1.0V regulator requirement is enforced on variants individually other than Exynos7870's. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250301-exynos7870-usb-v3-1-f01697165d19@disroot.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03dt-bindings: usb: dwc3: Add support for rk3562Kever Yang1-0/+19
The USB dwc3 core on Rockchip's RK3562 is the same as the one already included in generic snps,dwc3. Extend the binding accordingly to allow compatible = "rockchip,rk3562-dwc3", "snps,dwc3"; There are 4 clocks with different name sequency, add schema for it. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250227111913.2344207-10-kever.yang@rock-chips.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: shuttle_usbat: Use const for constant arrayJonathan Neuschäfer1-1/+1
This array is only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-9-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: sddr55: Use const for constant arraysJonathan Neuschäfer1-2/+2
These arrays are only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-8-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: sddr09: Use const for constant arraysJonathan Neuschäfer1-7/+7
The nand_flash_ids, inquiry_response, and mode_page_01 arrays are only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-7-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: realtek_cr: Use const for constant arraysJonathan Neuschäfer1-3/+3
These arrays are only read, never modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-6-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: initializers: Use const for constant arrayJonathan Neuschäfer1-1/+1
init_string is only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-5-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: datafab: Use const for constant arraysJonathan Neuschäfer1-7/+7
These arrays are only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-4-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: alauda: Use const for card ID arrayJonathan Neuschäfer1-4/+4
The alauda_card_ids array is only read, and not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-3-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: transport: Use const for constant arrayJonathan Neuschäfer1-1/+1
This array is only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-2-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: jumpshot: Use const for constant arraysJonathan Neuschäfer1-5/+5
These arrays are not modified. Make them const. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-1-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03ucsi_ccg: Don't show non-functional attributesMario Limonciello1-6/+19
If no fw_build is recognized for the controller there is no point to exposing the `do_flash` attribute. Add an is_visible callback to the attribute group and check for that fw_build member to hide when not applicable. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250221054137.1631765-3-superm1@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03ucsi_ccg: Don't show failed to get FW build information errorMario Limonciello1-3/+2
The error `failed to get FW build information` is added for what looks to be for misdetection of the device property firmware-name. If the property is missing (such as on non-nvidia HW) this error shows up. Move the error into the scope of the property parser for "firmware-name" to avoid showing errors on systems without the firmware-name property. Fixes: 5c9ae5a87573d ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250221054137.1631765-2-superm1@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: chipidea: imx: fix some typoXu Yang1-5/+5
bootlader -> bootloader set_wakeup failed -> hsic_set_clk failed Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20250225062843.3930041-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03dt-bindings: usb: generic-xhci: Allow dma-coherentRob Herring (Arm)1-0/+2
Some platforms like Marvell are cache coherent, so allow the "dma-coherent" property. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250226214231.3745400-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: ulpi: Remove unused otg_ulpi_createDr. David Alan Gilbert2-32/+0
otg_ulpi_create() has been unused since 2022's commit 8ca79aaad8be ("ARM: pxa: remove unused pxa3xx-ulpi") Remove it. The devm_ variant is still used. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250223160602.91916-1-linux@treblig.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03dt-bindings: usb: richtek,rt1711h: Add missing vbus power supplyAngeloGioacchino Del Regno1-0/+3
The RichTek RT1711H and RT1719 chips do have a vbus pin that is used for attach/detach detection (respectively, pin A1 and 11): allow a vbus-supply phandle for that. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250219140143.104037-1-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: core: replace usb_sndaddr0pipe macro with usb_sndctrlpipeStefan Eichenberger1-3/+1
The usb_sndaddr0pipe macro is only used in the hub_set_address function. Replace it with usb_sndctrlpipe which provides the same functionality but would also consider the endpoint device number. If the device has not been initialised, it is safe to use usb_sndctrlpipe in this context because udev->devnum is set to 0. Therefore, this change does not affect behaviour, but reduces code complexity by reusing the existing macro. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250219083745.10406-1-eichest@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-21USB: core: Add eUSB2 descriptor and parsing in USB coreKannappan R3-8/+66
Add support for the 'eUSB2 Isochronous Endpoint Companion Descriptor' introduced in the recent USB 2.0 specification 'USB 2.0 Double Isochronous IN Bandwidth' ECN. It allows embedded USB2 (eUSB2) devices to report and use higher bandwidths for isochronous IN transfers in order to support higher camera resolutions on the lid of laptops and tablets with minimal change to the USB2 protocol. The motivation for expanding USB 2.0 is further clarified in an additional Embedded USB2 version 2.0 (eUSB2v2) supplement to the USB 2.0 specification. It points out this is optimized for performance, power and cost by using the USB 2.0 low-voltage, power efficient PHY and half-duplex link for the asymmetric camera bandwidth needs, avoiding the costly and complex full-duplex USB 3.x symmetric link and gigabit receivers. eUSB2 devices that support the higher isochronous IN bandwidth and the new descriptor can be identified by their device descriptor bcdUSB value of 0x0220 Co-developed-by: Amardeep Rai <amardeep.rai@intel.com> Signed-off-by: Amardeep Rai <amardeep.rai@intel.com> Signed-off-by: Kannappan R <r.kannappan@intel.com> Co-developed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250220141339.1939448-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19dt-bindings: usb: samsung,exynos-dwc3 Add exynos990 compatibleIgor Belwon1-6/+10
Add a compatible for the exynos990-dwusb3 node. It's compatible with the exynos850 variant when using the highspeed mode. Signed-off-by: Igor Belwon <igor.belwon@mentallysanemainliners.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250217-exynos990-bindings-usb3-v2-1-3b3f0809f4fb@mentallysanemainliners.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix configuration error handlingJohan Hovold1-10/+26
Propagate errors to the consumers when configuring the retimer so that they can act on any failures as intended, for example: ps883x_retimer 2-0008: failed to write conn_status_0: -5 pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to setup retimer to DP: -5 Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218152933.22992-4-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix missing accessibility checkJohan Hovold1-0/+11
Make sure that the retimer is accessible before registering to avoid having later consumer calls fail to configure it, something which, for example, can lead to a hotplugged display not being recognised: [drm:msm_dp_panel_read_sink_caps [msm]] *ERROR* read dpcd failed -110 Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218152933.22992-3-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix registration raceJohan Hovold1-15/+16
Make sure that the retimer is fully setup before registering it to avoid having consumers try to access it while it is being reset. Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218152933.22992-2-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix probe error handlingJohan Hovold1-2/+3
Fix the probe error handling to avoid unbalanced clock disable or leaving regulators on after probe failure. Note that the active-low reset pin should also be asserted to avoid leaking current after disabling the regulators. Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218082243.9318-1-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: dwc2: Implement recovery after PM domain offStefan Wahren3-0/+41
According to the dt-bindings there are some platforms, which have a dedicated USB power domain for DWC2 IP core supply. If the power domain is switched off during system suspend then all USB register will lose their settings. Use GUSBCFG_TOUTCAL as a canary to detect that the power domain has been powered off during suspend. Since the GOTGCTL_CURMODE_HOST doesn't match on all platform with the current mode, additionally backup GINTSTS. This works reliable to decide which registers should be restored. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250217134132.36786-4-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: dwc2: Refactor backup/restore of registersStefan Wahren3-101/+121
The DWC2 runtime PM code reuses similar patterns to backup and restore the registers. So consolidate them in USB mode specific variants. This also has the advantage it is reusable for further PM improvements. Special care is taken for DCFG register during device mode restore. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20250217134132.36786-3-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: dwc2: gadget: Introduce register restore flagsStefan Wahren2-7/+11
dwc2_restore_device_registers() use a single boolean to decide about the register restoring behavior. So replace this with a flags parameter, which can be extended later. No functional change intended. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20250217134132.36786-2-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19docs: Fix typo in usb/CREDITSSuraj Patil1-1/+1
Correct 'Implementors' to 'Implementers'. Signed-off-by: Suraj Patil <surajpatil522@gmail.com> Link: https://lore.kernel.org/r/20250216001609.106616-2-surajpatil522@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19USB: docs: Fix typo in aspeed-lpc.yamlSuraj Patil1-1/+1
Correct 'Tehchnology' to 'Technology' in the copyright line. Signed-off-by: Suraj Patil <surajpatil522@gmail.com> Link: https://lore.kernel.org/r/20250216001609.106616-1-surajpatil522@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19dt-bindings: usb: usb-device: Replace free-form 'reg' with constraintsKrzysztof Kozlowski1-2/+4
Replace free-form text of 'reg' property with proper constraints so incorrect values can be actually reported. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250214114235.49476-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: misc: onboard_dev: add vdda support for Microchip USB2514Catalin Popescu1-1/+8
This hub is powered by digital and analog 3V3 power rails, so provide the possibility to use different regulators for digital (vdd) and analog (vdda) power rails. Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Link: https://lore.kernel.org/r/20250213094338.1611389-3-catalin.popescu@leica-geosystems.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19dt-bindings: usb: microchip,usb2514: add support for USB2512/USB2513Catalin Popescu1-5/+11
Extend support to Microchip hubs USB2512 & USB2513 which are identical to USB2514 but offer less downstream ports (i.e. respectively 2 and 3 ports). Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250213094338.1611389-2-catalin.popescu@leica-geosystems.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19dt-bindings: usb: microchip,usb2514: add support for vddaCatalin Popescu1-3/+16
Microchip hub USB2514 has one 3V3 digital power supply and one 3V3 analog power supply. Add support for analog power supply vdda. Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250213094338.1611389-1-catalin.popescu@leica-geosystems.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-16Linux 6.14-rc3Linus Torvalds1-1/+1
2025-02-15ring-buffer: Update pages_touched to reflect persistent buffer contentSteven Rostedt1-0/+5
The pages_touched field represents the number of subbuffers in the ring buffer that have content that can be read. This is used in accounting of "dirty_pages" and "buffer_percent" to allow the user to wait for the buffer to be filled to a certain amount before it reads the buffer in blocking mode. The persistent buffer never updated this value so it was set to zero, and this accounting would take it as it had no content. This would cause user space to wait for content even though there's enough content in the ring buffer that satisfies the buffer_percent. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Vincent Donnefort <vdonnefort@google.com> Link: https://lore.kernel.org/20250214123512.0631436e@gandalf.local.home Fixes: 5f3b6e839f3ce ("ring-buffer: Validate boot range memory events") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>