summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-11serial: max310x: uniformize clock/freq typesHugo Villeneuve
max310x_set_ref_clk() returns a 32-bits clock value, so there is no need to have parameters and intermediate values defined as long. Change clock and freq types to int. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-1-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: core: prevent division by zero by always returning non-zero baud rateHugo Villeneuve
If a device has a minimum baud rate > 9600 bauds, and a new termios baud rate of 0 (hang up) is requested, uart_get_baud_rate() will return 0. Most drivers do not check this return value and call uart_update_timeout() with this zero baud rate, which will trigger a "Division by zero in kernel" fault: stty -F /dev/ttySC0 0 Division by zero in kernel. ... Fix by returning the larger of 9600 or min for the B0 case. This now ensures that a non-zero baud rate is returned, and greatly simplifies the code. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: core: simplify clipping logic in uart_get_baud_rate()Hugo Villeneuve
Simplify the clipping logic in uart_get_baud_rate() to improve code readability. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-5-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: core: update uart_get_baud_rate() obsolete commentsHugo Villeneuve
Update obsolete comments to match the actual code. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-4-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: apbuart: remove check for zero baud rate from uart_get_baud_rate()Hugo Villeneuve
The minimum baud rate supported by this driver is 0, so even for the B0 case, uart_get_baud_rate() will return 9600, not zero. This check predates commit 16ae2a877bf4 ("serial: Fix crash if the minimum rate of the device is > 9600 baud") and is no longer necessary so remove it. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: icom: remove check for zero baud rate from uart_get_baud_rate()Hugo Villeneuve
The minimum baud rate supported by this driver is 300, so even for the B0 case, uart_get_baud_rate() will return 9600, not zero. This check predates commit 16ae2a877bf4 ("serial: Fix crash if the minimum rate of the device is > 9600 baud") and is no longer necessary so remove it. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQViken Dadhaniya
When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush. Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Cc: stable <stable@kernel.org> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260506-serial-dma-stale-tx-buf-v1-1-e3ccb360d719@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dmaShitalkumar Gandhi
lpuart_start_rx_dma() allocates sport->rx_ring.buf with kzalloc() and then maps a scatterlist via dma_map_sg(). On three subsequent error paths the function returns directly without releasing those resources: - when dma_map_sg() returns 0 (-EINVAL): ring->buf is leaked. - when dmaengine_slave_config() fails: ring->buf and the DMA mapping are leaked. - when dmaengine_prep_dma_cyclic() returns NULL: ring->buf and the DMA mapping are leaked. The sole cleanup path, lpuart_dma_rx_free(), is only reached when lpuart_dma_rx_use is set, and the caller lpuart_rx_dma_startup() clears that flag on failure of lpuart_start_rx_dma(). So these resources are permanently leaked on every failure in this function. Repeated port open/close or termios changes under error conditions will slowly consume memory and leave stale streaming DMA mappings behind. Fix it by introducing two error labels that unmap the scatterlist and free the ring buffer as appropriate. While here, replace the misleading -EFAULT (bad userspace pointer) returned when dmaengine_prep_dma_cyclic() fails with the more accurate -ENOMEM, matching how other dmaengine users in the tree treat this failure. No functional change on the success path. Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx") Cc: stable <stable@kernel.org> Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260420135903.2062024-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11mmc: davinci: avoid NULL deref of host->data in IRQ handlerStepan Ionichev
mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit "if (data != NULL)" check, but the subsequent TOUTRD ("read data timeout") and CRCWR/CRCRD ("data CRC error") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change. Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11Revert "nvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808"AlanCui4080
This reverts commit 7f991e3f9b8f044640bcb5fa8570350a68932843 ("nvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808") The incorrect implementations of SUBNQN is a known issue in a massive number of NVMe units. However, the warning "nvme nvmex: missing or invalid SUBNQN field." is usually appropriate and will not affect performance or behavior etc. That is because the support for SUBNQN is mandatory if the controller supports NVMe revision 1.2.1 or greater, and it reported itself without a SUBNQN field which breaks compliance with the specification. It should be not quirked by the Linux Kernel. Signed-off-by: Alan Cui <me@alancui.cc> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-05-11nvmet-tcp: Fix potential UAF when ddgst mismatchSagi Grimberg
Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get. Reported-by: Shivam Kumar <kumar.shivam43666@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-05-11nvme-pci: fix use-after-free in nvme_free_host_mem()Chia-Lin Kao (AceLan)
nvme_free_host_mem() frees dev->hmb_sgt via dma_free_noncontiguous() but never clears the pointer afterward. This leads to a use-after-free if nvme_free_host_mem() is called twice in the same error path. This can happen during nvme_probe() when nvme_setup_host_mem() succeeds in allocating the HMB (setting dev->hmb_sgt) but nvme_set_host_mem() fails with an I/O error: nvme_setup_host_mem() nvme_alloc_host_mem_single() -> sets dev->hmb_sgt nvme_set_host_mem() -> fails with -EIO nvme_free_host_mem() -> frees hmb_sgt, but does NOT NULL it return error nvme_probe() error path: nvme_free_host_mem() -> dev->hmb_sgt is stale, use-after-free The second call dereferences the freed sgt, causing a NULL pointer dereference in iommu_dma_free_noncontiguous() when it accesses sgt->sgl->dma_address (the backing memory has been freed and zeroed). This is reproducible on Thunderbolt-attached NVMe devices (e.g., OWC Envoy Express behind a Dell WD22TB4 dock) where the device intermittently returns I/O errors during HMB setup due to PCIe link instability. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:iommu_dma_free_noncontiguous+0x22/0x80 Call Trace: <TASK> dma_free_noncontiguous+0x3b/0x130 nvme_free_host_mem+0x30/0xf0 [nvme] nvme_probe.cold+0xcc/0x275 [nvme] local_pci_probe+0x43/0xa0 pci_device_probe+0xeea/0x290 really_probe+0xf9/0x3b0 __driver_probe_device+0x8b/0x170 driver_probe_device+0x24/0xd0 __driver_attach_async_helper+0x6b/0x110 async_run_entry_fn+0x37/0x170 process_one_work+0x1ac/0x3d0 worker_thread+0x1b8/0x360 kthread+0xf7/0x130 ret_from_fork+0x2d8/0x3a0 ret_from_fork_asm+0x1a/0x30 </TASK> Fix this by setting dev->hmb_sgt to NULL after freeing it, so the second call takes the multi-descriptor path which safely handles the already-cleaned-up state. Fixes: 63a5c7a4b4c4 ("nvme-pci: use dma_alloc_noncontigous if possible") Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-05-11nvmet-auth: Do not print DH-HMAC-CHAP secretsHannes Reinecke
From a security standpoint we should not allow to print out the DH-HMAC-CHAP secrets, but at the same time having them is useful for debugging authentication failures. So add a Kconfig option NVME_TARGET_AUTH_DEBUG to only enable debugging if explictly requested at build time. Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-05-11nvme: fix bio leak on mapping failureKeith Busch
The local bio is always NULL, so we'd leak the bio if the integrity mapping failed. Just get it directly from the request. Fixes: d0d1d522316e91f ("blk-map: provide the bdev to bio if one exists") Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-05-11nvme: make prp passthrough usage less scaryKeith Busch
The warning is a bit alarming, and it only prints for the very first non-sgl capable device that receives a passthrough command. Just log an informational message on initial discovery for every device. Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-05-11serial: qcom-geni: fix UART_RX_PAR_EN bit positionPrasanna S
UART_RX_PAR_EN is incorrectly defined as bit 3, which triggers false framing errors (S_GP_IRQ_1_EN) and causes received data to be dropped when parity is enabled and the parity bit is 0. Define UART_RX_PAR_EN as bit 4 of the SE_UART_RX_TRANS_CFG register, as specified in the reference manual. Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Cc: stable <stable@kernel.org> Signed-off-by: Prasanna S <prasanna.s@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260428-serial-bit-correct-v1-1-9131ad5b97d8@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: sh-sci: fix memory region release in error pathHongling Zeng
The sci_request_port() function uses request_mem_region() to reserve I/O memory, but in the error path when sci_remap_port() fails, it incorrectly calls release_resource() instead of release_mem_region(). This mismatch can cause resource accounting issues. Fix it by using the correct release function, consistent with sci_release_port(). Fixes: e2651647080930a1 ("serial: sh-sci: Handle port memory region reservations.") Cc: stable <stable@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202604032356.SzEjYkBC-lkp@intel.com/ Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260421065737.724187-1-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11tty: serial: pch_uart: add check for dma_alloc_coherent()Zhaoyang Yu
Add a check for dma_alloc_coherent() failure to prevent a potential NULL pointer dereference in dma_handle_rx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails. Fixes: 3c6a483275f4 ("Serial: EG20T: add PCH_UART driver") Cc: stable <stable@kernel.org> Signed-off-by: Zhaoyang Yu <2426767509@qq.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/tencent_E328416B7CFD436F6029F2DF02AD7ED89C08@qq.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: zs: Fix swapped RI/DSR modem line transition countingMaciej W. Rozycki
Fix a thinko in the status interrupt handler that has caused counters for the RI and DSR modem line transitions to be used for the other line each. Fixes: 8b4a40809e53 ("zs: move to the serial subsystem") Cc: stable <stable@kernel.org> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://patch.msgid.link/alpine.DEB.2.21.2604101747110.29980@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UARTJia Wang
The UltraRISC DP1000 UART does not provide the standard CPR register used by 8250_dw to discover port capabilities. Provide a fixed CPR value for the DP1000-specific compatible so the driver can configure the port correctly. Signed-off-by: Jia Wang <wangjia@ultrarisc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260429-ultrarisc-serial-v7-4-e475cce9e274@ultrarisc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitionsJia Wang
Replace the magic CPR value for Renesas RZ/N1 with a composition using DW_UART_CPR_* bit/field definitions and FIELD_PREP_CONST(). Introduce a helper macro to convert a FIFO size (bytes) into the CPR FIFO_MODE field value, with BUILD_BUG_ON_ZERO() checks for alignment and bounds. Use it to replace the literal FIFO_MODE values in the RZN1. Signed-off-by: Jia Wang <wangjia@ultrarisc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260429-ultrarisc-serial-v7-2-e475cce9e274@ultrarisc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: 8250_dwlib: move DesignWare register definitions to headerJia Wang
Move the DW_UART_* register offsets and CPR bit/field definitions from 8250_dwlib.c into 8250_dwlib.h so they can be shared by 8250_dw and 8250_dwlib users. Add an include guard for 8250_dwlib.h. Signed-off-by: Jia Wang <wangjia@ultrarisc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260429-ultrarisc-serial-v7-1-e475cce9e274@ultrarisc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11memstick: Constify the driver id_tableKrzysztof Kozlowski
Just like all other driver structures, the id_table should never be modified by core subsystem parts. Constify this member and actual data structures for increased code safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11mmc: host: Move MODULE_DEVICE_TABLE next to the table itselfKrzysztof Kozlowski
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it exports, because this is easier to read and verify. It also makes more sense since #ifdef for ACPI or OF could hide both of them. Most of the privers already have this correctly placed, so adjust the missing ones. No functional impact. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11wifi: ath: Fix the license markingDaniel Lezcano
The Copyright for Qualcomm changed its format and replaces the old Qualcomm Innovative Center by Qualcomm Technology Inc. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Link: https://patch.msgid.link/20260317180833.3061582-1-daniel.lezcano@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-11wifi: ath10k: drop gpio_led referenceArnd Bergmann
The driver uses a 'struct gpio_led' internally, but does not actually interact with the gpio_led driver, in particular it does not actually use gpiolib here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260428162955.614739-1-arnd@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-11wifi: ath12k: add channel 177 to the 5 GHz channel listYingying Tang
Add support for 5 GHz channel 177 with a center frequency of 5885 MHz and Operating Class 125 per IEEE Std 802.11-2024 Table E-4. Channels 169, 173, and 177 are in the 5.9 GHz band and must be disabled when 5.9 GHz service bit is not supported. The 5.9 GHz band is only permitted for WLAN operation under FCC regulations. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260415063857.2462256-1-yintang@qti.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-11serial: Replace driver usage of UPF_CONS_FLOWJohn Ogness
Rather than using the UPF_CONS_FLOW bit of uart_port.flags to track the user configuration of console flow control, use the newly added uart_port.cons_flow (via its getter/setter functions). A coccinelle script was used to perform the search/replace. Note1: The sh-sci driver is blindly copying platform data configuration flags to uart_port.flags. Thus UPF_CONS_FLOW could get set for uart_port.flags. A follow-up commit will address this. Note2: The samsung_tty driver is using UPF_CONS_FLOW as a platform data configuration flag. However, the driver explicitly checks for this configuration flag and thus setting UPF_CONS_FLOW in uart_port.flags is avoided. Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20260506121606.5805-3-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11mmc: renesas_sdhi: add R-Car M3Le compatibility stringMarek Vasut
Add support for the SD Card/MMC Interface in the Renesas R-Car M3Le (R8A779MD) SoC. R19UH0260EJ0100 Rev.1.00 , Dec 25, 2025 Notes 7.70. indicates that HS400 mode is not supported. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11serial: sh-sci: Remove plat_sci_port.flagsGeert Uytterhoeven
The last setter of p->flags was removed in commit 37744feebc086908 ("sh: remove sh5 support") in v5.8. Link: https://lore.kernel.org/CAMuHMdXs94k3-7YD-yO7p2=+u8waYGAz8mpP5LDbMf3szt4V-w@mail.gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20260506124643.128021-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: jsm: Drop unused driver_data assigment and redundant zerosUwe Kleine-König (The Capable Hub)
The driver doesn't use the driver_data field, so drop the assigment together with the then redundant zero assigment for .class and .class_mask. Also drop the zero in the list terminator. While at it also use PCI_VDEVICE() to allow dropping "PCI_VENDOR_ID_". Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260505084749.2304121-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: 8250_pci: Consistently define pci_device_ids using named initializersUwe Kleine-König (The Capable Hub)
... and PCI device helpers. The various struct pci_device_id were defined using a mixture of initialization by position and by name. Some use the PCI device helpers (like PCI_DEVICE and PCI_DEVICE_SUB) and others don't. Consistently use named initializers, drop assignments of 0 by position for .class and .class_mask and use the PCI device helpers. Also use consistent line-breaks and positioning for opening and closing curly braces. The secret plan is to make struct pci_device_id::driver_data an anonymous union (similar to https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/) and that requires named initializers. But it's also a nice cleanup on its own. This patch doesn't change the compiled result; this was verified using an allmodconfig with several things disabled that make reproducible builds harder on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260428144033.1037617-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11tty: synclink_gt: remove broken driverEthan Nelson-Moore
The synclink_gt driver was marked as broken in commit 426263d5fb40 ("tty: synclink_gt: mark as BROKEN") in July 2023 because it had severe structural problems and there had been no evidence of users since 2016. Since then, no meaningful improvements have been made to the driver, and it is unlikely that will ever happen due to the lack of interest. Drop the driver and references to it in comments and documentation. include/uapi/linux/synclink.h is also removed. The only use of this header I have found is the linux-raw-sys Rust crate. It generates bindings for all UAPI headers, but has a hardcoded list of headers and ioctls, including this one, so that does not indicate that anyone is using it. I have sent a pull request to remove the include and ioctl definitions for this header (see the link below). Link: https://github.com/sunfishcode/linux-raw-sys/pull/185 Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20260504031519.18877-1-enelsonmoore@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: 8250_port: recognize UPIO_AUManuel Lauss
My MIPS Alchemy systems generate the following warning during probe of the 8250 driver: WARNING: drivers/tty/serial/8250/8250_port.c:462 at set_io_from_upio+0xfc/0x124, CPU#0: swapper/0/1 Unsupported UART type 4 [...] [<80521d40>] set_io_from_upio+0xfc/0x124 [<80521dfc>] serial8250_set_defaults+0x94/0xe0 [<80520fb4>] serial8250_register_8250_port+0x288/0x51c [<805214ec>] serial8250_probe+0x160/0x1e8 [<8053b5f0>] platform_probe+0x64/0x90 The least invasive fix is to recognize UPIO_AU (type 4) in set_io_from_upio() and do nothing, since all parameters have already been set up in 8250_rt288x.c::au_platform_setup(). Run-tested on Alchemy Au1300 platform. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com> Link: https://patch.msgid.link/20260430135822.905035-1-manuel.lauss@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: mxs-auart: replace hardcoded 1 with predefined macro ↵Nikola Z. Ivanov
GPIO_LINE_DIRECTION_IN The GPIO_LINE_DIRECTION_* definitions have just recently been exposed to gpio consumers.h by breaking them out in a separate defs.h file. Use this to validate the gpio direction instead of the hard-coded literal. Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com> Link: https://patch.msgid.link/20260426214250.781151-1-zlatistiv@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: 8250_mtk: Add ACPI supportZhiyong Tao
Add ACPI support to 8250_mtk driver. This makes it possible to use UART on ARM-based desktops with EDK2 UEFI firmware. Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com> Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com> Link: https://patch.msgid.link/20260423062345.2473300-2-zhiyong.tao@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11mmc: core: Fix host controller programming for fixed driver typeKamal Dasu
When using the fixed-emmc-driver-type device tree property, the MMC core correctly selects the driver strength for the card but fails to program the host controller accordingly. This causes a mismatch where the card uses the specified driver type while the host controller defaults to Type B (since ios->drv_type remains zero). Split the driver type programming logic to handle both fixed and dynamic driver type selection paths. For fixed driver types, program the host controller with the selected drive_strength value. For dynamic selection, use the existing drv_type as before. This ensures both the eMMC device and host controller use matching driver strengths, preventing potential signal integrity issues. Fixes: 6186d06c519e ("mmc: parse new binding for eMMC fixed driver type") Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11drm/i915: Consolidate the intel_plane_(un)pin_fb() implementationsVille Syrjälä
Currently i915 and xe each implement their own versions of intel_plane_(un)pin(). Now that we have the fb_pin parent interface we can consolidate this to a single implementation. The result is a mixture of the i915 and xe implementations. The reuse_vma() hack comes from xe (and i915 doesn't implement that part of the parent interface, and the pin_params are taken from i915 since the platforms supported by i915 need more things. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-17-ville.syrjala@linux.intel.com
2026-05-11drm/xe: Use xe_fb_pin_ggtt_pin() for the initial FB pinVille Syrjälä
Use xe_fb_pin_ggtt_pin() instead of intel_fb_pin_to_ggtt() for the initial FB pin. We want to get rid of intel_fb_pin_to_ggtt() and just use the new fb_pin parent interface. This still isn't quite the final solution since we bypass the actual parent interface and call the implementation directly. But sorting that out will require more cleanup to the initial FB code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-16-ville.syrjala@linux.intel.com
2026-05-11drm/i915/fbdev: Use intel_parent_fb_pin_ggtt_(un)pin()Ville Syrjälä
Replace the intel_fb_pin_to_ggtt() and intel_fb_unpin_vma() with the new abstract parent interface (intel_parent_fb_pin_ggtt_(un)pin()). xe no longer needs intel_fb_unpin_vma(), and in i915 it now becomes and internal function to i915_fb_pin. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-15-ville.syrjala@linux.intel.com
2026-05-11drm/i915: Introduce the main fb_pin parent interfaceVille Syrjälä
Introduce the main part of the new fb_pin parent interface: - intel_parent_fb_pin_ggtt_(un)pin() - intel_parent_fb_pin_dpt_(un)pin() - intel_parent_fb_pin_reuse_vma() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-14-ville.syrjala@linux.intel.com
2026-05-11drm/xe: Restructure reuse_vma()Ville Syrjälä
Restructure reuse_vma() into a form that doesn't need the plane state structs, and rename the result to xe_fb_pin_reuse_vma(). This will become the new fb_pin parent interface. v2: Fix memcmp() arguments Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-13-ville.syrjala@linux.intel.com
2026-05-11drm/xe: Introduce xe_fb_pin_ggtt_(un)pin()Ville Syrjälä
Extract the inner DPT parts of intel_plane_(un)pin() into the xe_fb_pin_ggtt_(un)pin(). These will become part of the new fb_pin parent interface. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-12-ville.syrjala@linux.intel.com
2026-05-11drm/xe: Introduce xe_fb_pin_dpt_(un)pin()Ville Syrjälä
Extract the inner DPT parts of intel_plane_(un)pin() into the xe_fb_pin_dpt_(un)pin(). These will become part of the new fb_pin parent interface. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-11-ville.syrjala@linux.intel.com
2026-05-11drm/xe: Reorganize intel_plane_pin_fb() a bitVille Syrjälä
Move most of the plane state stuff out from the inner parts of intel_plane_pin_fb(). The plan is to take those inner parts and abstract them into the new fb_pin parent interface, and we don't want any plane_state stuff there. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-10-ville.syrjala@linux.intel.com
2026-05-11drm/xe: Kill the fbdev vma reuse hackVille Syrjälä
This fbdev vma reuse hacks is a massive layering violation. It really does not belong in the fb pinning code. And it's in the way of properly abstracting this stuff, so kill it. I don't think this hack even does anything useful because the normal view will just use bo->ggtt_node when present, and the fbdev bo will be permanenly pinned with xe_bo_create_pin_map_at_novm() which does set up bo->ggtt_node. So we should never end up rebuilding the PTEs for the fbdev bo, even without the reuse hack. v2: Pimp the commit message a a bit (Jani) v3: Also nuke intel_fbdev_vma_pointer() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-9-ville.syrjala@linux.intel.com
2026-05-11drm/xe: Move the FORCE_WC assert into __xe_pin_fb_vma()Ville Syrjälä
No need to bother the higher level pinning code with the FORCE_WC assert. Move it into the lower level function. This also introduces the check to intel_fb_pin_to_ggtt(), which (for the moment) is still used for the fbdev bo setup. But this is all display stuff we're talking about here so having the check is correct everywhere. v2: Pimp the commit message a bit (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-8-ville.syrjala@linux.intel.com
2026-05-11drm/i915: Introduce i915_fb_pin_ggtt_(un)pin()Ville Syrjälä
Extract the inner DPT parts of intel_plane_(un)pin() into the i915_fb_pin_ggtt_(un)pin(). These will become part of the new fb_pin parent interface. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-7-ville.syrjala@linux.intel.com
2026-05-11drm/i915: Introduce i915_fb_pin_dpt_(un)pin()Ville Syrjälä
Extract the inner DPT parts of intel_plane_(un)pin() into the i915_fb_pin_dpt_(un)pin(). These will become part of the new fb_pin parent interface. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-6-ville.syrjala@linux.intel.com
2026-05-11drm/i915: Reorganize intel_plane_pin_fb() a bitVille Syrjälä
Move most of the plane state stuff out from the inner parts of intel_plane_pin_fb(). The plan is to take those inner parts and abstract them into the new fb_pin parent interface, and we don't want any plane_state stuff there. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-5-ville.syrjala@linux.intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-06 06:19:32 +0000