summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-17staging: rtl8723bs: Rename camelcase enum value dot11AuthAlgrthm_AutoDalvin-Ehinoma Noah Aiguobas5-7/+7
Rename enum value dot11AuthAlgrthm_Auto to dot11_auth_algrthm_auto to fix checkpatch.pl CamelCase finding. Signed-off-by: Dalvin-Ehinoma Noah Aiguobas <fliegbert2@gmail.com> Link: https://patch.msgid.link/20260710162017.5660-4-fliegbert2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17staging: rtl8723bs: Rename camelcase enum value dot11AuthAlgrthm_OpenDalvin-Ehinoma Noah Aiguobas7-11/+11
Rename enum value dot11AuthAlgrthm_Open to dot11_auth_algrthm_open in enum to fix checkpatch.pl CamelCase finding. Signed-off-by: Dalvin-Ehinoma Noah Aiguobas <fliegbert2@gmail.com> Link: https://patch.msgid.link/20260710162017.5660-3-fliegbert2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17staging: rtl8723bs: Rename camelcase enum value dot11AuthAlgrthm_8021XDalvin-Ehinoma Noah Aiguobas10-22/+22
Rename enum value dot11AuthAlgrthm_8021X to dot11_auth_algrthm_8021x to fix the checkpatch.pl CamelCase finding. Signed-off-by: Dalvin-Ehinoma Noah Aiguobas <fliegbert2@gmail.com> Link: https://patch.msgid.link/20260710162017.5660-2-fliegbert2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17dmaengine: dw-edma: Enable HDMA 64R/W ChannelsDevendra K Verma7-28/+49
As per 'Designware Cores PCI Express Controller Databook', Section 7.1 - Overview, HDMA supports 64 Read and 64 Write channels. Current controller driver supports up to 8 read and write channels only. In order to utilize all the channels the controller driver need to have the channel related structs and variables as per the number of channels supported by IP. Following changes are made to enable 64 Read / 64 Write channel support: o Defined HDMA specific macros to reflect the channel count. o The count of ll_regions and dt_regions in dw_edma_chip and dw_edma_pcie_data shall be in accordance to number of read and write channels. o In dw_edma_probe() configure the channels as per the channels of the IP used. o Changed mask types to u64 for higher channel counts. Signed-off-by: Devendra K Verma <devendra.verma@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713064854.4065262-1-devverma@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-17UDF symlink pathComponent header OOB readDavid Lee1-0/+2
udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: David Lee <david.lee@trailofbits.com> Assisted-by: Codex:gpt-5.5 Link: https://patch.msgid.link/20260717104722.41446-1-david.lee@trailofbits.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-17net: mana: Add debug knob to skip TX timeout recovery resetAditya Garg2-0/+17
Add a per-port debugfs boolean "tx_timeout_skip_reset" that, when enabled, makes mana_tx_timeout() log the TX timeout and return without queueing the per-port detach/attach recovery work. This is a debug-only aid for bringup and qualification: skipping the recovery reset keeps the device and queue state intact so a TX timeout can be correlated with hardware telemetry. The knob defaults to false, so production recovery behaviour is unchanged. Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710132229.2851441-1-gargaditya@linux.microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=nWeiming Shi1-0/+3
On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does. Fixes: 196cfebf8972 ("net/mpls: Handle kernel side filtering of route dumps") Assisted-by: Claude:claude-opus-4-8 Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260711114958.1009619-3-bestswngs@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17llc: fix SAP refcount leak when creating incoming socketsXuanqiang Luo1-1/+0
llc_sap_add_socket() takes a SAP reference for each socket added to a SAP, and llc_sap_remove_socket() releases it. llc_create_incoming_sock() takes an additional SAP reference after adding the child socket. This extra reference was balanced by an explicit llc_sap_put() in llc_ui_release() until commit 3100aa9d74db ("llc: fix SAP reference counting w.r.t. socket handling") removed that put. The corresponding hold in the accept path was left behind. When such a child socket is removed, only the reference taken by llc_sap_add_socket() is released. The extra reference keeps the SAP alive after its last socket is removed. Remove the obsolete hold. Fixes: 3100aa9d74db ("llc: fix SAP reference counting w.r.t. socket handling") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Link: https://patch.msgid.link/20260712130343.518797-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17selftests: netconsole: only restore MAC when it changed on resumeAndre Carvalho1-1/+2
The "mac" bind mode reactivation downs the interface, restores the saved MAC and renames it to trigger a target resume. This assumes the recreated interface comes back with a different MAC, which is true under MACAddressPolicy=none (as on the Netdev CI) but not when MACs are persistent. In the persistent case netconsole resumes the target on its own, and the down/restore/rename flow instead drops it and fails the test. Guard the block on the MAC having actually changed so the test passes under both policies. Fixes: 6ecc08329bab ("selftests: netconsole: validate target resume") Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Closes: https://lore.kernel.org/netdev/f398373e-2cb4-4649-a491-9763df94d98b@kernel.org/ Signed-off-by: Andre Carvalho <asantostc@gmail.com> Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netcons-mac-reload-v1-1-3fb1bcc70b4a@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17serial: sc16is7xx: implement gpio get_direction() callbackHugo Villeneuve1-0/+12
It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable <stable@kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260716210813.2582826-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR ↵Jiangshan Yi1-5/+9
platforms Commit b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks. Fixes: b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") Cc: stable <stable@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn> Link: https://patch.msgid.link/20260715073546.1875083-1-yijiangshan@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17fuse: publish io-uring queues with release semanticsJoanne Koong1-9/+11
fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it. WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The queue must be published with smp_store_release() so the field initialization is guaranteed to happen before. Readers in paths where the read may happen concurrently with the store need to use READ_ONCE() because any race involving a plain access is undefined. Fixes: 24fe962c86f5 ("fuse: {io-uring} Handle SQEs - register commands") Cc: stable@vger.kernel.org Reviewed-by: Bernd Schubert <bernd@bsbernd.com> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2026-07-17fuse: use release/acquire for fch->initializedJoanne Koong3-10/+11
fuse_chan_set_initialized() sets values for the connection state and then sets fch->initialized to true, but lockless readers read fch->initialized and if true, go to read the connection state values, without using any barriers. There are a few instances where this happens (fuse_uring_cmd() before dispatching register / commit-and-fetch cmds, fuse_dev_do_wriite() for handling notify retrieves, etc). To make this as simple as possible, use release/acquire semantics for writing/reading fch->initialized. Add the missing read barriers. This is not marked for stable as these are not realistically reachable on a well-behaved server, and buggy/malicious servers who trigger this path fail benignly rather than crash or deadlock the kernel. Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2026-07-17fuse: fix missing barrier when checking io-uring readinessJoanne Koong1-4/+7
fuse_block_alloc() reads fch->initialized and then fch->io_uring. fch->io_uring is set before fch->initialized, ordered by the smp_wmb() in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching read barrier between the two loads. This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents. Add an smp_rmb() barrier to pair with the smp_wmb() in fuse_chan_set_initialized() to prevent this. Fixes: 3393ff964e0f ("fuse: block request allocation until io-uring init is complete") Cc: stable@vger.kernel.org Reviewed-by: Bernd Schubert <bernd@bsbernd.com> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2026-07-17tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64Karl Mehltretter1-1/+1
hvc_dcc drives the JTAG DCC via the ARMv6/v7 CP14 debug registers (mrc/mcr p14, 0, rX, c0, c1/c5, 0 in asm/dcc.h). That encoding is undefined on older ARM cores, and also on ARMv7-M, but HVC_DCC only depends on ARM, so it can be enabled on e.g. ARM926 (ARCH_MULTI_V5), where hvc_dcc_console_init() runs __dcc_putchar() at boot and takes an undefined-instruction trap before the console is up: Internal error: Oops - undefined instruction: 0 [#1] ARM PC is at hvc_dcc_check+0x50/0x8c hvc_dcc_check from hvc_dcc_console_init+0x18/0x48 hvc_dcc_console_init from console_init+0x58/0x170 Kernel panic - not syncing: Fatal exception Restrict HVC_DCC to the CPUs where that encoding is valid: the CPU_V6 || CPU_V6K || CPU_V7 set that arch/arm/include/debug/icedcc.S guards it with, plus ARM64. Fixes: 16c63f8ea49c ("drivers: char: hvc: add arm JTAG DCC console support") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260717071616.91423-1-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17dt-bindings: serial: snps-dw-apb-uart: Add RV1106 compatibleSimon Glass1-0/+1
Add the compatible for the UARTs of the Rockchip RV1106, which are compatible with the Synopsys DesignWare APB UART. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260714132035.v2.1.c1d92213393f49330ec14d0c670a802181b4fcbf@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17serial: qcom_geni: Add panic notifier to stop UART on panicPraveen Talari1-0/+23
When a VM crashes with an active UART DMA transfer in progress, the SMMU raises context faults as the DMA engine continues to access IOVAs that are invalidated when the VM's memory context is torn down. These faults can affect other VMs sharing the same SMMU instance and obscure the root cause of the crash. Additionally, a stuck TX transfer on the panic console UART can cause the panic handler to stall, dropping the panic output. Register a panic notifier to stop TX and RX. The notifier does not take the port lock, since panic can be entered with the lock already held by the interrupted context, and there is no safe way to detect that here; instead, the device's runtime PM status is checked first so that TX/RX are only stopped while the hardware is still clocked and accessible, and the register accesses are skipped entirely once the device is runtime suspended. Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Link: https://patch.msgid.link/20260715-add_shutdown_and_panic_notifier_serial-v1-2-23e3787c7109@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17serial: qcom_geni: Add shutdown callback to quiesce hardware on rebootPraveen Talari1-0/+13
During system reboot, an active UART DMA transfer can leave the GENI Serial Engine in an indeterminate state. On VM-based platforms, if a DMA transfer is in progress when the VM is shut down, the SMMU can raise context faults as the DMA engine continues to access IOVAs that have already been invalidated during VM teardown. Add a shutdown callback to stop TX and RX and bring the hardware to idle before the system resets, preventing both hardware state corruption on reboot and SMMU faults during VM shutdown. The port lock is not taken here since shutdown runs from process context with the device already quiesced from the UART core's perspective; instead, the runtime PM status is checked so that TX/RX are only stopped while clocks and resources are still active, avoiding any register access once the device is runtime suspended. Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Link: https://patch.msgid.link/20260715-add_shutdown_and_panic_notifier_serial-v1-1-23e3787c7109@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17serial: qcom-geni: Add tracepoints for Qualcomm GENI serial driverPraveen Talari1-4/+23
Add tracing to the Qualcomm GENI serial driver to improve runtime observability. Trace hooks are added at key points including termios and clock configuration, manual control get/set, interrupt handling, and data TX/RX paths. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Link: https://patch.msgid.link/20260710-add-tracepoints-for-qcom-geni-serial-v6-2-2bb6b6836dfd@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17serial: core: display 32 for MEM32 and MEM32BE UPIO typesHugo Villeneuve1-1/+1
Displaying "32be" is wrong for UPIO_MEM32. Fix and simplify by displaying "32" for MEM32 and MEM32BE UPIO types. Fixes: 86305190f307 ("serial: uniformize serial port I/O infos display") Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260716211216.2583291-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17serial: 8250: fix compile error with hub6_match_port() when compiled as a moduleHugo Villeneuve1-1/+2
With CONFIG_SERIAL_8250_HUB6=m, we have the following compile error: ../drivers/tty/serial/8250/8250_hub6.c:46:6: error: redefinition of 'hub6_match_port' Fix hub6_match_port() prototype definition by using IS_REACHABLE() to support both built-in and module values, and substitute empty prototype otherwise. Fixes: 3d406299d8829 ("serial: 8250_hub6: add hub6_match_port()") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607150717.2YxVdWpX-lkp@intel.com/ Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260715153707.4181828-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17Revert "serial: qcom-geni: remove .pm callback, use runtime PM in ↵Greg Kroah-Hartman1-18/+19
startup/shutdown" This reverts commit 3d71f8d7eeb374d0eb84c64c6ffd68bdcc0d42d4. It causes lots of build problems both in linux-next and reported by the 0-day bot. Reported-by: Mark Brown <broonie@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Praveen Talari <praveen.talari@oss.qualcomm.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607110008.JQ2vBeKC-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202607150830.LsNxeVYw-lkp@intel.com/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17net: airoha: add preliminary support to configure tx hw QoS queue during ↵Lorenzo Bianconi1-4/+6
flowtable offloading Add the plumbing to program the AIROHA_FOE_QID field in the PPE FOE entry with a per-flow priority value during flowtable offload. This allows the hardware to steer offloaded flows to a specific QoS queue on the egress QDMA block for traffic forwarded between two interfaces via hardware acceleration, bypassing the kernel forwarding path. The priority parameter is currently always zero because netfilter does not yet provide a mechanism to pass the skb priority field to the flowtable offload driver. Once that support is added in the netfilter subsystem, the driver will be able to extract the priority from the flow rule and map it to the appropriate hardware queue. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260703-airoha-hw-qos-queue-stub-v1-1-ef253ffdd093@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DASiddaraju DH1-0/+6
Add comment to clarify the physical media 10000baseCR follows. 10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD. It has no autonegotiation, no link training, and no mandatory FEC. The industry standard for this media type is SFF-8431 Appendix-E Direct Attach cable, also known as 10G_SFI_DA. Link: https://lore.kernel.org/r/SN7PR11MB69003D33489DB1D6B17EF72A9AF52@SN7PR11MB6900.namprd11.prod.outlook.com Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260703100537.1109838-1-siddaraju.dh@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17MIPS: BCM47XX: Convert buttons to software nodesDmitry Torokhov1-186/+254
Convert the legacy gpio-keys platform device on BCM47XX boards to use software nodes/properties. This allows us to describe the GPIO keys and their GPIO bindings using software nodes, so that support for platform data can eventually be removed from the gpio-keys driver. Detect the active bus type (BCMA or SSB) and reference the corresponding GPIO controller's software node (bcma_gpio_swnode or ssb_gpio_swnode) in the button properties. Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17ssb: gpio: Add and register software node for GPIO controllerDmitry Torokhov2-7/+43
We want to convert the legacy gpio-keys platform device on BCM47XX boards to use software nodes. To do this properly and allow referencing the GPIO controller by address rather than relying on name-based matching (which is being removed from the gpiolib core), we need to associate the GPIO controller with a software node. Introduce ssb_gpio_swnode, register it, and associate it with the gpio_chip. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17bcma: gpio: Add and register software node for GPIO controllerDmitry Torokhov2-6/+39
We want to convert the legacy gpio-keys platform device on BCM47XX boards to use software nodes. To do this properly and allow referencing the GPIO controller by address rather than relying on name-based matching (which is being removed from the gpiolib core), we need to associate the GPIO controller with a software node. Introduce bcma_gpio_swnode, register it if the device does not already have a firmware node, and associate it with the gpio_chip. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: ip22-gio: Drop #include of <linux/mod_devicetable.h>Uwe Kleine-König (The Capable Hub)1-1/+0
That header doesn't use any device id provided by <linux/mod_devicetable.h>. Also the users of <asm/gio_device.h> (i.e. arch/mips/sgi-ip22/ip22-gio.c and drivers/video/console/newport_con.c) don't use any of them and they compile fine in a mips allmodconfig. So drop the unused include that only yields unnecessary recompilations when a device id struct changes. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17bnxt_en: Handle partially initialized auxiliary devicesRuoyu Wang1-19/+20
bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 194fad5b2781 ("bnxt_en: Refactor bnxt_rdma_aux_device_init/uninit functions") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260711163716.3996929-1-ruoyuw560@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17MIPS: TXX9: Clean up txx9_iocled_init()Geert Uytterhoeven3-11/+6
The sole caller already uses dynamic GPIO base allocation, so drop support for static allocation. While at it, drop the no longer used "lowactive" parameter. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: Convert gpio_txx9 to dynamic GPIO base allocationGeert Uytterhoeven3-7/+5
Static allocation of GPIO base is deprecated, use dynamic allocation. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: Drop GPIOLIB_LEGACY selectGeert Uytterhoeven1-1/+0
TXx has been converted away from the old-style gpiolib interfaces. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: Use GPIO lookup table for iocled LEDsGeert Uytterhoeven1-2/+12
Convert iocled LED description from legacy GPIO numbers to GPIO descriptors using a GPIO lookup table. For now, just ignore the "lowactive" parameter, and force GPIO_ACTIVE_LOW, as that is what the sole caller wants. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: Reduce TXX9_IOCLED_MAXLEDS to 3Geert Uytterhoeven1-1/+1
The number of available GPIOs and LEDs on the TXx9 IOC FPGA depends on the platform. Since commit 455481fc9a807798 ("MIPS: Remove TX39XX support"), the only remaining platform (rbtx4927) supports just three. Hence reduce the maximum number, to reduce allocation size. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: rbtx4927: Use GPIO lookup table for TXx9 LEDsGeert Uytterhoeven1-3/+16
Convert TXx9 LED description from legacy GPIO numbers to GPIO descriptors using a GPIO lookup table. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: rbtx4927: Use GPIO lookup table for SIO DTRGeert Uytterhoeven1-3/+13
Convert SIO DTR handling from legacy GPIO calls to GPIO descriptors using a GPIO lookup table. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: Remove txx9_7segled_*() forward declarationsGeert Uytterhoeven1-5/+0
The actual implementation was removed in commit 5a8df9281b052ff3 ("MIPS: TXX9: Remove rbtx4939 board support"). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: TXX9: Remove tx4938_spi_init() and txx9_spi_init()Geert Uytterhoeven4-25/+0
The last user of tx4938_spi_init() was removed in commit 21d638ef9483d8cf ("MIPS: TXX9: Remove rbtx4938 board support"). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17MIPS: kernel: proc: Use two seq_putc() calls in show_cpuinfo()Markus Elfring1-2/+2
Single line breaks should occasionally be put into a sequence. Thus use the corresponding function “seq_putc”. The source code was transformed by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17media: chips-media: wave5: Resume device before setting EOS flagJackson Lee1-0/+19
Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run(). Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: chips-media: wave5: Fix pipeline stall when queuing failsJackson Lee1-1/+4
The Wave5 decoder calls v4l2_m2m_job_finish() immediately in device_run() after submitting frames to firmware. When the firmware completes those frames and the queue drains to zero, finish_decode() has no active M2M job to finish, so v4l2_m2m_schedule_next_job() is never called and the decoder stalls. Call v4l2_m2m_try_schedule() in finish_decode() when the firmware queue empties to ensure the framework always schedules the next device_run(). Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queuedJackson Lee1-1/+11
Decoder instances sharing a VPU also share one v4l2_m2m job slot, released when the running context calls v4l2_m2m_job_finish(). While draining, device_run() defers job_finish() once EOS is sent (sent_eos), expecting a later finish_decode() (from a DEC_PIC completion IRQ) to release the slot. But the m2m core checks job_ready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finish_decode() has already moved the instance to STOP and sent EOS. device_run() then runs in STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no finish_decode(), and the shared slot is leaked, stalling every instance. With several v4l2h264dec instances in parallel, GStreamer hangs at EOS. Track whether the run actually queued a DEC_PIC (cmd_issued) and defer job_finish() only then. Otherwise finish the job immediately Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: chips-media: wave5: Add timeout while stop_streamingJackson Lee2-7/+10
When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: chips-media: wave5: avoid skipping device_run while VPU has workJackson Lee1-3/+7
The decoder stalls because empty_queue is set to true even when the m2m context still has pending commands. As a result, device_run is never invoked, the m2m source queue fills up, and userspace (e.g. Chromium) can no longer queue new bitstream buffers to the V4L2 driver. Fix this by querying the VPU queue status via DEC_GET_QUEUE_STATUS before deciding whether to skip device_run. Only skip when the VPU's instance_queue_count equals the number of ready source buffers in the v4l2-m2m context, which indicates that there is genuinely no new work to perform. Otherwise, proceed with issuing a decode command so that the VPU can continue draining its internal queue. Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: chips-media: wave5: Set inst->std during default format initializationJackson Lee1-2/+4
When the encoder is opened, wave5_set_default_format() sets up the default capture format (e.g. H.264) but does not initialize inst->std. As a result, inst->std remains zero, which does not match any valid encoder codec. If STREAMON is called before the user explicitly calls S_FMT on the capture queue — as v4l2-compliance does in testBlockingDQBuf — the codec/product check in wave5_vpu_enc_init_seq() fails with "Unsupported encoder-codec & product combination" because inst->std is neither W_HEVC_ENC nor W_AVC_ENC, returning -EOPNOTSUPP. Fix this by setting inst->std via wave5_to_vpu_std() in wave5_set_default_format(), so that the codec type is always consistent with the default capture pixel format from the moment the instance is opened. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: chips-media: wave5: Guard bit depth check with initial_info_obtainedJackson Lee1-1/+2
When CAPTURE STREAMON is called before the VPU has completed sequence initialization (initial_info_obtained == false), the initial_info fields contain uninitialized data. The driver checks luma_bitdepth and rejects anything other than 8-bit, so garbage values (e.g. 15) cause STREAMON to fail spuriously. This is reproducible with the following multi-threaded test scenario: 1. Allocate 2 CAPTURE buffers. 2. Call STREAMON on the CAPTURE queue. 3. Call DQBUF, which blocks waiting for a decoded frame. 4. A second thread calls STREAMOFF on the CAPTURE queue. 5. The blocked DQBUF should be released, allowing graceful termination. At step 2, STREAMON reads uninitialized luma_bitdepth and rejects the stream, causing the test to fail. Fix this by checking initial_info_obtained before accessing the bit depth fields, so the validation is only performed when the sequence info has actually been parsed by the VPU. Fixes: 035371c9e509 ("media: chips-media: wave5: Fix timeout while testing 10bit hevc fluster") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: cedrus: fix memory leak in cedrus_init_ctrls()Dawei Feng1-1/+3
In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed. Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_commonChristian Hewitt1-2/+2
When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format. Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: platform: hantro_drv: Add missing media_entity_cleanup()Biren Pandya1-3/+9
The media_entity_pads_init() (or media_entity_init()) function initializes the media entity, but the driver forgets to call media_entity_cleanup() in the error paths and remove function. Add the missing calls to fix the API violation and prevent potential future memory leaks. Signed-off-by: Biren Pandya <birenpandya@gmail.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-17media: amphion: Remove obsolete frame_count check in venc_start_sessionMing Qian1-2/+0
The dev_err() log warning about no input when starting was originally meaningful when min_queued_buffers was set, as it indicated an abnormal condition. However, since commit 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") removed the min_queued_buffers assignment, having frame_count == 0 at start is a normal condition. Remove this misleading log that no longer serves any purpose. Fixes: 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-10-01 19:38:22 +0000