summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-11-21usb: xhci: replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Switch to using system_percpu_wq because system_wq is going away as part of a workqueue restructuring. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: Don't unchain link TRBs on quirky HCsMichal Pecio
Some old HCs ignore transfer ring link TRBs whose chain bit is unset. This breaks endpoint operation and sometimes makes it execute other ring's TDs, which may corrupt their buffers or cause unwanted device action. We avoid this by chaining all link TRBs on affected rings. Fix an omission which allows them to be unchained by cancelling TDs. The patch was tested by reproducing this condition on an isochronous endpoint (non-power-of-two TDs are sometimes split not to cross 64K) and printing link TRBs in trb_to_noop() on good and buggy HCs. Actual hardware malfunction is rare since it requires Missed Service Error shortly before the unchained link TRB, at least on NEC and AMD. I have never seen it after commit bb0ba4cb1065 ("usb: xhci: Apply the link chain quirk on NEC isoc endpoints"), but it's Russian roulette and I can't test all affected hosts and workloads. Fairly often MSEs happen after cancellation because the endpoint was stopped. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: Assume that endpoints halt as specifiedMichal Pecio
xHCI 4.8.3 recommends that software should simply assume endpoints to halt after certain events, without looking at the Endpoint Context for confirmation, because HCs may be slow to update that. While no cases of such "slowness" appear to be known, different problem exists on AMD Promontory chipsets: they may halt and generate a transfer event, but fail to ever update the Endpoint Context at all, at least not until some command is queued and fails with Context State Error. This is easily triggered by disconnecting D- of a full speed serial device. Possibly similar bug in non-AMD hardware has been reported to linux-usb. In such case, failed TD is given back without erasing from the ring and endpoint isn't reset. If some URB is unlinked later, Stop Endpoint fails and its handler resets the endpoint. On next submission it will restart on the stale TD. Outcome is UAF on success, or another halt on error and then Dequeue doesn't move and URBs are stuck. Unlinking and resubmitting the URBs causes unlimited ring expansion if the situation repeats. This can be solved by ignoring Endpoint Context State and trusting that endpoints halt when required, except one known case in ancient hardware. The check for "Already resolving halted ep" becomes redundant, because for these completion codes we now jump to xhci_handle_halted_endpoint() which deals with pending EP_HALTED internally. Link: https://lore.kernel.org/linux-usb/20250311234139.0e73e138@foxbook/ Link: https://lore.kernel.org/linux-usb/20250918055527.4157212-1-zhangjinpeng@kylinos.cn/ Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: implement USB Port Register Set structNiklas Neronin
Previously, each port's 'addr' field pointed to the base of the Host Controller USB Port Register Set, and specific registers were accessed using macros such as (port->addr + PORTPMSC). This patch replaces the raw '__le32 __iomem *addr' pointer with a typed 'struct xhci_port_regs __iomem *port_reg' pointer. With this change, individual registers can be accessed directly through the structure fields: Before: port->addr port->addr + PORTPMSC port->addr + PORTLI port->addr + PORTHLPMC After: port->port_reg->portsc port->port_reg->portpmsc port->port_reg->portli port->port_reg->porthlpmc This improves code readability and makes register access more intuitive by using named struct members instead of pointer arithmetic and macros. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: add USB Port Register Set structNiklas Neronin
Introduce a new struct for the Host Controller USB Port Register Set to enhance readability and maintainability. The Host Controller Operational Registers (struct 'xhci_op_regs') span from offset 0x0 to 0x3FF and consist of fixed fields. Following these fixed fields are the Host Controller USB Port Register Sets, which are dynamic and repeat from 1 to MaxPorts, as defined by HCSPARAMS1. Currently, the struct 'xhci_op_regs' includes: __le32 port_status_base; The first PORTSC __le32 port_power_base; The first PORTPMSC __le32 port_link_base; The first PORTLI __le32 reserved5; The first PORTHLPMC, not reserved __le32 reserved6[NUM_PORT_REGS*254]; Port registers 2 to MaxPorts Replace this with the simpler: struct xhci_port_regs port_regs[]; Port registers 1 to MaxPorts Host Controller USB Port Register Set: | Offset | Mnemonic | Register Name -------------------------------------------------------------------------- | 0x0 | PORTSC | Port Status and Control | 0x4 | PORTPMSC | Port Power Management Status and Control | 0x8 | PORTLI | Port Link Info | 0xC | PORTHLPMC | Port Hardware LPM Control Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: add helper to read PORTSC registerNiklas Neronin
Add a dedicated helper function to read the USB Port Status and Control (PORTSC) register. This complements xhci_portsc_writel() and improves code clarity by providing a clear counterpart for reading the register. Suggested-by: Peter Chen <peter.chen@kernel.org> Reviewed-by: Peter Chen <peter.chen@kerne.org> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: add tracing for PORTSC register writesNiklas Neronin
Introduce a dedicated write function for the USB Port Register Set (PORTSC) that includes tracing capabilities for values written to the PORTSC register. This enhancement minimizes code duplication and improves debugging. The PORTSC register is part of the Host Controller USB Port Register Set, comprising 4 x 32-bit registers. As the first register, PORTSC is accessed directly via 'port->addr'. Future commits will introduce a dedicated Port register struct to further streamline access. By adding the xhci_portsc_writel() function prior to these changes, we significantly reduce the number of same line modifications required. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: rework xhci_decode_portsc()Niklas Neronin
Rework xhci_decode_portsc(), which is used for PORTSC tracing, to make the output more compact and general. The function now first prints the multi-bit fields (port speed and link state), followed by the abbreviated names of each individual bit as defined in the xHCI specification. This reduces message length and makes the output easier to read. This change prepares for upcoming patches that will trace all PORTSC writes, requiring the same decoding logic to handle both reads and writes. This is particularly important for Read-Write-1-to-Clear (RW1C) bits, where the semantics differ between read and write operations. For example, when reading the Port Enabled bit, a set bit means the port is enabled; when writing, a set bit indicates the port is being disabled. The decoder now also includes the following fields: Port Link State Write Strobe (LWS) Device Removable (DR) Warm Port Reset (WPR) ==== Examples Traces ==== Before: 0x00201201 Powered Connected Disabled Link:U0 PortSpeed:4 Change: PRC Wake: 0x0a0002a0 Powered Not-connected Disabled Link:RxDetect PortSpeed:0 \ Change: Wake: WCE WOE After: 0x00201201 Speed=4 Link=U0 CCS PP PRC 0x0a0002a0 Speed=0 Link=RxDetect PP WCE WOE Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21xhci: simplify and rework trb_in_td()Mathias Nyman
The trb_in_td() checking is quite complex, especially when checking for TRBs in ranges that can span several segments. Simplify the search by creating a position index for each TRB on the ring, and just compare the position indexes. Add a more generic dma_in_range() helper that checks if a trb dma address is in the range between a start and end trb and call it from trb_in_td() Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21xhci: Add helper to find trb from its dma addressMathias Nyman
Add a xhci_dma_to_trb() helper, and use it to find the transfer TRB early in handle_tx_event() based on the dma address found in the event TRB. With this helper we can avoid using 'ep_seg' transfer TRB segment variable as both a a boolean to indicate if the transfer TRB is part of the next queued TD, and to actually find the transfer TRB based on ep_seg and ep_trb_dma. This is a first step in reworking and cleaning up trb_in_td() and handle_tx_event() Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: limit run_graceperiod for only usb 3.0 devicesHongyu Xie
run_graceperiod blocks usb 2.0 devices from auto suspending after xhci_start for 500ms. Log shows: [ 13.387170] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.387177] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.387182] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.387188] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.387191] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.387193] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.387296] hub_event:5779: hub 3-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.393343] handle_port_status:2034: xhci-hcd PNP0D10:02: handle_port_status: starting usb5 port polling. [ 13.393353] xhci_hub_control:1271: xhci-hcd PNP0D10:02: Get port status 5-1 read: 0x206e1, return 0x10101 [ 13.400047] hub_suspend:3903: hub 3-0:1.0: hub_suspend [ 13.403077] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.403080] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.403085] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.403087] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.403090] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.403093] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.403095] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.405002] handle_port_status:1913: xhci-hcd PNP0D10:04: Port change event, 9-1, id 1, portsc: 0x6e1 [ 13.405016] hub_activate:1169: usb usb5-port1: status 0101 change 0001 [ 13.405026] xhci_clear_port_change_bit:658: xhci-hcd PNP0D10:02: clear port1 connect change, portsc: 0x6e1 [ 13.413275] hcd_bus_suspend:2250: usb usb3: bus auto-suspend, wakeup 1 [ 13.419081] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.419086] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.419095] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.419100] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.419106] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.419110] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.419112] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.420455] handle_port_status:2034: xhci-hcd PNP0D10:04: handle_port_status: starting usb9 port polling. [ 13.420493] handle_port_status:1913: xhci-hcd PNP0D10:05: Port change event, 10-1, id 1, portsc: 0x6e1 [ 13.425332] hcd_bus_suspend:2279: usb usb3: suspend raced with wakeup event [ 13.431931] handle_port_status:2034: xhci-hcd PNP0D10:05: handle_port_status: starting usb10 port polling. [ 13.435080] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.435084] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.435092] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.435096] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.435102] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.435106] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event usb7 and other usb 2.0 root hub were rapidly toggling between suspend and resume states. More, "suspend raced with wakeup event" confuses people. So, limit run_graceperiod for only usb 3.0 devices Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci-mtk: correct most kernel-doc problems in xhci-mtk.hRandy Dunlap
Correct the kernel-doc notation in xhck-mtk.h to avoid most kernel-doc warnings. Summary of changes: - don't use /** to begin comments that are not in kernel-doc format - add missing "struct mu3h_sch_tt" kernel-doc line - convert several "struct mu3h_...:" to using " - " to separate the struct name from its short description - add a missing @speed: struct member description Warning messages that are fixed: xhci-mtk.h:25: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * To simplify scheduler algorithm, set a upper limit for ESIT, xhci-mtk.h:25: warning: missing initial short description on line: * To simplify scheduler algorithm, set a upper limit for ESIT, Warning: drivers/usb/host/xhci-mtk.h:36 Cannot find identifier on line: * @fs_bus_bw_out: save bandwidth used by FS/LS OUT eps in each uframes Warning: drivers/usb/host/xhci-mtk.h:37 Cannot find identifier on line: * @fs_bus_bw_in: save bandwidth used by FS/LS IN eps in each uframes Warning: drivers/usb/host/xhci-mtk.h:38 Cannot find identifier on line: * @ls_bus_bw: save bandwidth used by LS eps in each uframes Warning: drivers/usb/host/xhci-mtk.h:39 Cannot find identifier on line: * @fs_frame_bw: save bandwidth used by FS/LS eps in each FS frames Warning: drivers/usb/host/xhci-mtk.h:40 Cannot find identifier on line: * @in_ss_cnt: the count of Start-Split for IN eps Warning: drivers/usb/host/xhci-mtk.h:41 Cannot find identifier on line: * @ep_list: Endpoints using this TT Warning: drivers/usb/host/xhci-mtk.h:42 Cannot find identifier on line: */ Warning: drivers/usb/host/xhci-mtk.h:43 Cannot find identifier on line: struct mu3h_sch_tt { Warning: drivers/usb/host/xhci-mtk.h:44 Cannot find identifier on line: u16 fs_bus_bw_out[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:45 Cannot find identifier on line: u16 fs_bus_bw_in[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:46 Cannot find identifier on line: u8 ls_bus_bw[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:47 Cannot find identifier on line: u16 fs_frame_bw[XHCI_MTK_FRAMES_CNT]; Warning: drivers/usb/host/xhci-mtk.h:48 Cannot find identifier on line: u8 in_ss_cnt[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:49 Cannot find identifier on line: struct list_head ep_list; Warning: drivers/usb/host/xhci-mtk.h:50 Cannot find identifier on line: }; Warning: drivers/usb/host/xhci-mtk.h:51 Cannot find identifier on line: Warning: drivers/usb/host/xhci-mtk.h:52 Cannot find identifier on line: /** Warning: drivers/usb/host/xhci-mtk.h:121 struct member 'speed' not described in 'mu3h_sch_ep_info' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251104070216.907540-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21dmaengine: fsl-edma: configure tcd attr with separate src and dst settingsHan Xu
Set the edma tcd transfer attribution settings for the src and dst based on their respective dma_addr values, to remove the previous 32-byte alignment limitation in the EDMA memcpy function. Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251119163255.502070-1-han.xu@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: st_fdma: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251120164907.28007-1-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: bcm2835: enable compile testingJohan Hovold
There seems to be nothing preventing the driver from being compile tested so enable that for wider build coverage. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251120115016.8967-1-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: tegra210-adma: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20251120114524.8431-10-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: sprd: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251120114524.8431-9-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: mmp_tdma: drop unnecessary OF node check in removeJohan Hovold
The driver does not support anything but OF probe since commit 3b0f4a54f247 ("dma:mmp_tdma: get sram pool through device tree"). Commit a67ba97dfb30 ("dmaengine: Use device_get_match_data()") later removed most remnants of platform probing except for an unnecessary OF node check in remove(). Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251120114524.8431-8-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: mmp_tdma: drop unused module aliasJohan Hovold
The driver does not support anything but OF probe since commit 3b0f4a54f247 ("dma:mmp_tdma: get sram pool through device tree") so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251120114524.8431-7-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: k3dma: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251120114524.8431-6-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: fsl-qdma: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251120114524.8431-5-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: fsl-edma: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251120114524.8431-4-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: dw: drop unused module aliasJohan Hovold
The driver does not support anything but OF and ACPI probe since commit b3757413b91e ("dmaengine: dw: platform: Use struct dw_dma_chip_pdata") so drop the unused platform module alias along with the now unnecessary driver name define. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251120114524.8431-3-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: bcm2835: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probe so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251120114524.8431-2-johan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: at_hdmac: add COMPILE_TEST supportRosen Penev
Allows the buildbot to detect potential issues with the code on various platforms. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org> Link: https://patch.msgid.link/20251106022405.85604-3-rosenp@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21dmaengine: at_hdmac: fix formats under 64-bitRosen Penev
size_t formats under 32-bit evaluate to the same thing and GCC does not warn against it. Not the case with 64-bit. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org> Link: https://patch.msgid.link/20251106022405.85604-2-rosenp@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-21mfd: qnap-mcu: Hook up the EEPROM sub-deviceHeiko Stuebner
Add the qnap-mcu-eeprom platform-driver as sub-device for the MCU. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251103232942.410386-3-heiko@sntech.de Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-21dm-verity: fix unreliable memory allocationMikulas Patocka
GFP_NOWAIT allocation may fail anytime. It needs to be changed to GFP_NOIO. There's no need to handle an error because mempool_alloc with GFP_NOIO can't fail. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: Eric Biggers <ebiggers@kernel.org>
2025-11-21tty: synclink_gt: Fix namespace collision and startup() section placement ↵Josh Poimboeuf
with -ffunction-sections When compiled with -ffunction-sections (e.g., for LTO, livepatch, dead code elimination, AutoFDO, or Propeller), the startup() function gets compiled into the .text.startup section (or in some cases .text.startup.constprop.0 or .text.startup.isra.0). However, the .text.startup and .text.startup.* sections are also used by the compiler for __attribute__((constructor)) code. This naming conflict causes the vmlinux linker script to wrongly place startup() function code in .init.text, which gets freed during boot. Some builds have a mix of objects, both with and without -ffunctions-sections, so it's not possible for the linker script to disambiguate with #ifdef CONFIG_FUNCTION_SECTIONS or similar. This means that "startup" unfortunately needs to be prohibited as a function name. Rename startup() to startup_hw(). For consistency, also rename its shutdown() counterpart to shutdown_hw(). Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/f0ee750f35c878172cc09916a0724b74e62eadc2.1763669451.git.jpoimboe@kernel.org
2025-11-21tty: amiserial: Fix namespace collision and startup() section placement with ↵Josh Poimboeuf
-ffunction-sections When compiled with -ffunction-sections (e.g., for LTO, livepatch, dead code elimination, AutoFDO, or Propeller), the startup() function gets compiled into the .text.startup section (or in some cases .text.startup.constprop.0 or .text.startup.isra.0). However, the .text.startup and .text.startup.* sections are also used by the compiler for __attribute__((constructor)) code. This naming conflict causes the vmlinux linker script to wrongly place startup() function code in .init.text, which gets freed during boot. Some builds have a mix of objects, both with and without -ffunctions-sections, so it's not possible for the linker script to disambiguate with #ifdef CONFIG_FUNCTION_SECTIONS or similar. This means that "startup" unfortunately needs to be prohibited as a function name. Rename startup() to rs_startup(). For consistency, also rename its shutdown() counterpart to rs_shutdown(). Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/9e56afff5268b0b12b99a8aa9bf244d6ebdcdf47.1763669451.git.jpoimboe@kernel.org
2025-11-21media: atomisp: gc2235: Fix namespace collision and startup() section ↵Josh Poimboeuf
placement with -ffunction-sections When compiled with -ffunction-sections (e.g., for LTO, livepatch, dead code elimination, AutoFDO, or Propeller), the startup() function gets compiled into the .text.startup section (or in some cases .text.startup.constprop.0 or .text.startup.isra.0). However, the .text.startup and .text.startup.* sections are also used by the compiler for __attribute__((constructor)) code. This naming conflict causes the vmlinux linker script to wrongly place startup() function code in .init.text, which gets freed during boot. Some builds have a mix of objects, both with and without -ffunctions-sections, so it's not possible for the linker script to disambiguate with #ifdef CONFIG_FUNCTION_SECTIONS or similar. This means that "startup" unfortunately needs to be prohibited as a function name. Rename startup() to gc2235_startup(). Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/d28103a6edf7beceb5e3c6fa24e49dbad1350389.1763669451.git.jpoimboe@kernel.org
2025-11-21serial: icom: Fix namespace collision and startup() section placement with ↵Josh Poimboeuf
-ffunction-sections When compiled with -ffunction-sections (e.g., for LTO, livepatch, dead code elimination, AutoFDO, or Propeller), the startup() function gets compiled into the .text.startup section (or in some cases .text.startup.constprop.0 or .text.startup.isra.0). However, the .text.startup and .text.startup.* sections are also used by the compiler for __attribute__((constructor)) code. This naming conflict causes the vmlinux linker script to wrongly place startup() function code in .init.text, which gets freed during boot. Some builds have a mix of objects, both with and without -ffunctions-sections, so it's not possible for the linker script to disambiguate with #ifdef CONFIG_FUNCTION_SECTIONS or similar. This means that "startup" unfortunately needs to be prohibited as a function name. Rename startup() to icom_startup(). For consistency, also rename its shutdown() counterpart to icom_shutdown(). Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/1aee9ef69f9d40405676712b34f0c397706e7023.1763669451.git.jpoimboe@kernel.org
2025-11-21Merge tag 'mediatek-drm-next-20251120' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20251120 1. Fix probe resource leaks 2. Add support for MT8195/88 HDMIv2 and DDCv2 3. Fix CCORR mtk_ctm_s31_32_to_s1_n function issue 4. Fix device node reference leak in mtk_dp_dt_parse() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20251119233202.10034-1-chunkuang.hu@kernel.org
2025-11-21docs: efi: add CPER functions to driver-apiMauro Carvalho Chehab
There are two kernel-doc like descriptions at cper, which is used by other parts of cper and on ghes driver. They both have kernel-doc like descriptions. Change the tags for them to be actual kernel-doc tags and add them to the driver-api documentaion at the UEFI section. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specsMauro Carvalho Chehab
Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor was defined simply as: Type at byte offset 4: - Cache error - TLB Error - Bus Error - Micro-architectural Error All other values are reserved Yet, there was no information about how this would be encoded. Spec 2.9A errata corrected it by defining: - Bit 1 - Cache Error - Bit 2 - TLB Error - Bit 3 - Bus Error - Bit 4 - Micro-architectural Error All other values are reserved That actually aligns with the values already defined on older versions at N.2.4.1. Generic Processor Error Section. Spec 2.10 also preserve the same encoding as 2.9A. Adjust CPER and GHES handling code for both generic and ARM processors to properly handle UEFI 2.9A and 2.10 encoding. Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-information Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21efi/cper: Add a new helper function to print bitmasksMauro Carvalho Chehab
Add a helper function to print a string with names associated to each bit field. A typical example is: const char * const bits[] = { "bit 3 name", "bit 4 name", "bit 5 name", }; char str[120]; unsigned int bitmask = BIT(3) | BIT(5); #define MASK GENMASK(5,3) cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask), bits, ARRAY_SIZE(bits)); The above code fills string "str" with "bit 3 name|bit 5 name". Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21efi/cper: Adjust infopfx size to accept an extra spaceMauro Carvalho Chehab
Compiling with W=1 with werror enabled produces an error: drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’: drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^ drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As the logic there adds an space at the end of infopx buffer. Add an extra space to avoid such warning. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21RAS: Report all ARM processor CPER information to userspaceJason Tian
The ARM processor CPER record was added in UEFI v2.6 and remained unchanged up to v2.10. Yet, the original arm_event trace code added by e9279e83ad1f ("trace, ras: add ARM processor error trace event") is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not exporting any information from tables N.17 to N.29 of the record. This is not enough for the user to be able to figure out what has exactly happened or to take appropriate action. According to the UEFI v2.9 specification chapter N2.4.4, the ARM processor error section includes: - several (ERR_INFO_NUM) ARM processor error information structures (Tables N.17 to N.20); - several (CONTEXT_INFO_NUM) ARM processor context information structures (Tables N.21 to N.29); - several vendor specific error information structures. The size is given by Section Length minus the size of the other fields. In addition, it also exports two fields that are parsed by the GHES driver when firmware reports it, e.g.: - error severity - CPU logical index Report all of these information to userspace via a the ARM tracepoint so that userspace can properly record the error and take decisions related to CPU core isolation according to error severity and other info. The updated ARM trace event now contains the following fields: ====================================== ============================= UEFI field on table N.16 ARM Processor trace fields ====================================== ============================= Validation handled when filling data for affinity MPIDR and running state. ERR_INFO_NUM pei_len CONTEXT_INFO_NUM ctx_len Section Length indirectly reported by pei_len, ctx_len and oem_len Error affinity level affinity MPIDR_EL1 mpidr MIDR_EL1 midr Running State running_state PSCI State psci_state Processor Error Information Structure pei_err - count at pei_len Processor Context ctx_err- count at ctx_len Vendor Specific Error Info oem - count at oem_len ====================================== ============================= It should be noted that decoding of tables N.17 to N.29, if needed, will be handled in userspace. That gives more flexibility, as there won't be any need to flood the kernel with micro-architecture specific error decoding. Also, decoding the other fields require a complex logic, and should be done for each of the several values inside the record field. So, let userspace daemons like rasdaemon decode them, parsing such tables and having vendor-specific micro-architecture-specific decoders. [mchehab: modified description, solved merge conflicts and fixed coding style] Signed-off-by: Jason Tian <jason@os.amperecomputing.com> Co-developed-by: Shengwei Luo <luoshengwei@huawei.com> Signed-off-by: Shengwei Luo <luoshengwei@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com> # rebased Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Shiju Jose <shiju.jose@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event") Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21Merge tag 'drm-xe-fixes-2025-11-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix out-of-bounds access with BIT() (Shuicheng Lin) - Fix kunit test checking wrong condition (Matt Roper) - Drop duplicate kconfig select (Shuicheng Lin) - Fix guc2host irq handler with MSI-X (Venkata Ramana Nayana) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/uadbrmftcud3wg32c6tje7mmfcr7wgmpnkzxwubk6fletahje2@coek2ciunkvz
2025-11-21Merge tag 'amd-drm-fixes-6.18-2025-11-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.18-2025-11-20: amdgpu: - DTBCLK gating fix - EDID fetching retry improvements - HDMI HPD debounce filtering - DCN 2.0 cursor fix - DP MST PBN fix - VPE fix - GC 11 fix - PRT fix - MMIO remap page fix - SR-IOV fix radeon: - Fence deadlock fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251120164110.1077973-1-alexander.deucher@amd.com
2025-11-21drm/gem: Use vmemdup_array_user in drm_gem_objects_lookupTvrtko Ursulin
Use a helper to shrink the code and separate the user and kernel slabs for better security. While at it lets remove the useless debug message. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251112092732.23584-1-tvrtko.ursulin@igalia.com
2025-11-21Merge tag 'drm-misc-fixes-2025-11-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: atomic: - Return error codes on failed blob creation for planes nouveau: - Fix memory leak tegra: - Fix device ref counting - Fix pid ref counting - Revert booting on Pixel C Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251120151308.GA589436@linux.fritz.box
2025-11-21drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()Sanjay Yadav
In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping metrics_lock. Since this lock protects the lifetime of oa_config, an attacker could guess the id and call xe_oa_remove_config_ioctl() with perfect timing, freeing oa_config before we dereference it, leading to a potential use-after-free. Fix this by caching the id in a local variable while holding the lock. v2: (Matt A) - Dropped mutex_unlock(&oa->metrics_lock) ordering change from xe_oa_remove_config_ioctl() Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6614 Fixes: cdf02fe1a94a7 ("drm/xe/oa/uapi: Add/remove OA config perf ops") Cc: <stable@vger.kernel.org> # v6.11+ Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251118114859.3379952-2-sanjay.kumar.yadav@intel.com (cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Check for fence error on VRAM save/restoreMichał Winiarski
The code incorrectly assumes that the VRAM save/restore fence is valid. Fix it by checking for error. Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251114122339.1791026-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 78ff838a8ab78b3cd438e382ff5204b93db3237e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Drop the VF VRAM BO reference on successful restoreMichał Winiarski
The reference is only dropped on error. Fix it by adding the missing xe_bo_put(). Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Reported-by: Adam Miszczak <adam.miszczak@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251114100713.1776073-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit dab751b4240f0f0eadea81f93ff0b439379bc6ae) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Fix kernel-doc warning in migration_save_consumeMichał Winiarski
The kernel-doc for xe_sriov_pf_migration_save_consume() contained multiple "Return:" sections, causing a warning. Fix it by removing the extra line. Fixes: 67df4a5cbc583 ("drm/xe/pf: Add data structures and handlers for migration rings") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251114134030.1795947-1-michal.winiarski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 562b0f254d8b1515a1c8d2a650f940d4f719300e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21wifi: rtl8xxxu: Enable 40 MHz width by defaultBitterblue Smith
40 MHz support is hidden behind the ht40_2g module parameter with this comment: /* * Some APs will negotiate HT20_40 in a noisy environment leading * to miserable performance. Rather than defaulting to this, only * enable it if explicitly requested at module load time. */ This parameter was added in commit 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)"). Back then rtl8xxxu only supported RTL8723AU and the RTL8192CU family. It's entirely possible the miserable performance was due to mistakes in the channel switching function, which were fixed in a previous patch. Delete the ht40_2g module parameter. If someone still needs to disable 40 MHz support, cfg80211 has the module parameter cfg80211_disable_40mhz_24ghz. That works too. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4f053103-adfd-4ead-acb3-ef69127a4bab@gmail.com
2025-11-21wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FUBitterblue Smith
The other chips report the RX channel width in the RX descriptor, but this one doesn't. Get the RX channel width from the PHY status. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1c6c1fd4-92f6-4327-a24e-f0747ab21819@gmail.com
2025-11-21wifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BUBitterblue Smith
rtl8xxxu_gen2_config_channel() was missing the subchannel setting. This function is used by RTL8192EU and RTL8723BU. This change seems to make no difference in my testing on channel 13 with either chip. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/a5de8d39-45c1-4667-ab4c-7109de6eb13d@gmail.com
2025-11-21wifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz widthBitterblue Smith
Set the required fields in the TX descriptor to allow these chips to transmit with 40 MHz channel width when the access point supports it. Tested only with RTL8192CU, but these settings are identical for RTL8723AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/30d95228-69b2-48f9-8854-c98d2408c4d3@gmail.com
generated by cgit v1.2.3 (git 2.0.4) at 2026-01-09 21:33:29 +0000