kernel/linux.git/drivers/rpmsg, branch v6.18.21

rpmsg: core: fix race in driver_override_show() and use core helper

2026-03-04T12:20:52+00:00

[ Upstream commit 42023d4b6d2661a40ee2dcf7e1a3528a35c638ca ] The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code. Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Link: https://lore.kernel.org/r/20251202174948.12693-1-hanguidong02@gmail.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

rpmsg: glink: fix rpmsg device leak

2026-01-02T11:57:29+00:00

commit a53e356df548f6b0e82529ef3cc6070f42622189 upstream. While testing rpmsg-char interface it was noticed that duplicate sysfs entries are getting created and below warning is noticed. Reason for this is that we are leaking rpmsg device pointer, setting it null without actually unregistering device. Any further attempts to unregister fail because rpdev is NULL, resulting in a leak. Fix this by unregistering rpmsg device before removing its reference from rpmsg channel. sysfs: cannot create duplicate filename '/devices/platform/soc@0/3700000.remot eproc/remoteproc/remoteproc1/3700000.remoteproc:glink-edge/3700000.remoteproc: glink-edge.adsp_apps.-1.-1' [ 114.115347] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.16.0-rc4 #7 PREEMPT [ 114.115355] Hardware name: Qualcomm Technologies, Inc. Robotics RB3gen2 (DT) [ 114.115358] Workqueue: events qcom_glink_work [ 114.115371] Call trace:8 [ 114.115374] show_stack+0x18/0x24 (C) [ 114.115382] dump_stack_lvl+0x60/0x80 [ 114.115388] dump_stack+0x18/0x24 [ 114.115393] sysfs_warn_dup+0x64/0x80 [ 114.115402] sysfs_create_dir_ns+0xf4/0x120 [ 114.115409] kobject_add_internal+0x98/0x260 [ 114.115416] kobject_add+0x9c/0x108 [ 114.115421] device_add+0xc4/0x7a0 [ 114.115429] rpmsg_register_device+0x5c/0xb0 [ 114.115434] qcom_glink_work+0x4bc/0x820 [ 114.115438] process_one_work+0x148/0x284 [ 114.115446] worker_thread+0x2c4/0x3e0 [ 114.115452] kthread+0x12c/0x204 [ 114.115457] ret_from_fork+0x10/0x20 [ 114.115464] kobject: kobject_add_internal failed for 3700000.remoteproc: glink-edge.adsp_apps.-1.-1 with -EEXIST, don't try to register things with the same name in the same directory. [ 114.250045] rpmsg 3700000.remoteproc:glink-edge.adsp_apps.-1.-1: device_add failed: -17 Fixes: 835764ddd9af ("rpmsg: glink: Move the common glink protocol implementation to glink_native.c") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250822100043.2604794-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

rpmsg: qcom_smd: Fix fallback to qcom,ipc parse

2025-09-21T02:29:48+00:00

mbox_request_channel() returning value was changed in case of error. It uses returning value of of_parse_phandle_with_args(). It is returning with -ENOENT instead of -ENODEV when no mboxes property exists. Fixes: 24fdd5074b20 ("mailbox: use error ret code of of_parse_phandle_with_args()") Reviewed-by: Dmitry Baryshkov Reviewed-by: Stephan Gerhold Tested-by: Stephan Gerhold # msm8939 Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20250725-fix-qcom-smd-v2-1-e4e43613f874@mainlining.org Signed-off-by: Bjorn Andersson

rpmsg: Use strscpy() instead of strscpy_pad()

2025-09-21T02:29:48+00:00

kzalloc() already zero-initializes the destination buffer, making strscpy() sufficient for safely copying the name. The additional NUL- padding performed by strscpy_pad() is unnecessary. The size parameter is optional, and strscpy() automatically determines the size of the destination buffer using sizeof() when the argument is omitted. RPMSG_NAME_SIZE is equal to sizeof(rpdev->id.name) and can be removed - remove it. No functional changes intended. Signed-off-by: Thorsten Blum Link: https://lore.kernel.org/r/20250429104543.66927-2-thorsten.blum@linux.dev Signed-off-by: Bjorn Andersson

rpmsg: core: Drop dev_pm_domain_detach() call

2025-08-29T16:21:31+00:00

Starting with commit f99508074e78 ("PM: domains: Detach on device_unbind_cleanup()"), there is no longer a need to call dev_pm_domain_detach() in the bus remove function. The device_unbind_cleanup() function now handles this to avoid invoking devres cleanup handlers while the PM domain is powered off, which could otherwise lead to failures as described in the above-mentioned commit. Drop the explicit dev_pm_domain_detach() call and rely instead on the flags passed to dev_pm_domain_attach() to power off the domain. Signed-off-by: Claudiu Beznea Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/20250827101352.927542-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Mathieu Poirier

rpmsg: char: Export alias for RPMSG ID rpmsg-raw from table

2025-08-25T14:20:21+00:00

Module aliases are used by userspace to identify the correct module to load for a detected hardware. The currently supported RPMSG device IDs for this module include "rpmsg-raw", but the module alias is "rpmsg_chrdev". Use the helper macro MODULE_DEVICE_TABLE(rpmsg) to export the correct supported IDs. And while here, to keep backwards compatibility we also add the other ID "rpmsg_chrdev" so that it is also still exported as an alias. This has the side benefit of adding support for some legacy firmware which still uses the original "rpmsg_chrdev" ID. This was the ID used for this driver before it was upstreamed (as reflected by the module alias). Signed-off-by: Andrew Davis Acked-by: Hari Nagalla Tested-by: Hari Nagalla Link: https://lore.kernel.org/r/20250619205722.133827-1-afd@ti.com Signed-off-by: Mathieu Poirier

Merge tag 'rproc-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux

2025-08-01T22:02:25+00:00

Pull remoteproc updates from Bjorn Andersson: - Make the Xilinx remoteproc driver support running on only a single core, disable still unsupported remoteproc features, and stop the remoteproc on shutdown to facilitate kexec. - Conclude the renaming of the Qualcomm ADSP driver to "PAS" that was started many years ago. * tag 'rproc-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: remoteproc: xlnx: Fix kernel-doc warnings remoteproc: xlnx: Disable unsupported features remoteproc: xlnx: Add shutdown callback remoteproc: xlnx: Allow single core use in split mode dt-bindings: remoteproc: qcom,sa8775p-pas: Correct the interrupt number remoteproc: Don't use %pK through printk dt-bindings: remoteproc: qcom,sm8150-pas: Document QCS615 remoteproc remoteproc: qcom: pas: Conclude the rename from adsp

PM: domains: Add flags to specify power on attach/detach

2025-07-07T18:41:20+00:00

Calling dev_pm_domain_attach()/dev_pm_domain_detach() in bus driver probe/remove functions can affect system behavior when the drivers attached to the bus use devres-managed resources. Since devres actions may need to access device registers, calling dev_pm_domain_detach() too early, i.e., before these actions complete, can cause failures on some systems. One such example is Renesas RZ/G3S SoC-based platforms. If the device clocks are managed via PM domains, invoking dev_pm_domain_detach() in the bus driver's remove function removes the device's clocks from the PM domain, preventing any subsequent pm_runtime_resume*() calls from enabling those clocks. The second argument of dev_pm_domain_attach() specifies whether the PM domain should be powered on during attachment. Likewise, the second argument of dev_pm_domain_detach() indicates whether the domain should be powered off during detachment. Upcoming changes address the issue described above (initially for the platform bus only) by deferring the call to dev_pm_domain_detach() until after devres_release_all() in device_unbind_cleanup(). The detach_power_off field in struct dev_pm_info stores the detach power off info from the second argument of dev_pm_domain_attach(). Because there are cases where the device's PM domain power-on/off behavior must be conditional (e.g., in i2c_device_probe()), the patch introduces PD_FLAG_ATTACH_POWER_ON and PD_FLAG_DETACH_POWER_OFF flags to be passed to dev_pm_domain_attach(). Finally, dev_pm_domain_attach() and its users are updated to use the newly introduced PD_FLAG_ATTACH_POWER_ON and PD_FLAG_DETACH_POWER_OFF macros. This change is preparatory. Signed-off-by: Claudiu Beznea Reviewed-by: Mathieu Poirier Acked-by: Wolfram Sang # I2C Reviewed-by: Ulf Hansson Link: https://patch.msgid.link/20250703112708.1621607-2-claudiu.beznea.uj@bp.renesas.com [ rjw: Changelog adjustments ] Signed-off-by: Rafael J. Wysocki

remoteproc: Don't use %pK through printk

2025-06-17T13:03:24+00:00

In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20250611-restricted-pointers-remoteproc-v1-1-f059097ba663@linutronix.de Signed-off-by: Bjorn Andersson

rpmsg: qcom_smd: Fix uninitialized return variable in __qcom_smd_send()

2025-05-21T02:46:10+00:00

The "ret" variable isn't initialized if we don't enter the loop. For example, if "channel->state" is not SMD_CHANNEL_OPENED. Fixes: 33e3820dda88 ("rpmsg: smd: Use spinlock in tx path") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/aAkhvV0nSbrsef1P@stanley.mountain Signed-off-by: Bjorn Andersson