user/sven/linux.git/drivers/rpmsg/rpmsg_core.c, branch next/master

rpmsg: Constify buffer passed to send API

2026-04-06T14:37:51Z

The rpmsg_send(), rpmsg_sendto() and other variants of sending interfaces should only send the passed data, without modifying its contents, so mark pointer 'data' as pointer to const. All users of this interface already follow this approach, so only the function declarations have to be updated. Acked-by: Mathieu Poirier Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260317-rpmsg-send-const-v3-3-4d7fd27f037f@oss.qualcomm.com Signed-off-by: Bjorn Andersson

drivers: rpmsg: class_destroy() is deprecated

2026-03-09T14:33:28Z

The class_destroy() function documents that: Note, the pointer to be destroyed must have been created with a call to class_create(). However, class_create() is deprecated. rpmsg already uses class_register() but the class_destroy() calls should also be replaced with class_unregister(). Link: https://lore.kernel.org/all/2023040244-duffel-pushpin-f738@gregkh/ Signed-off-by: Jori Koolstra Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20260308140850.1138376-1-jkoolstra@xs4all.nl Signed-off-by: Mathieu Poirier

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

2025-12-15T01:37:49Z

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

rpmsg: core: Drop dev_pm_domain_detach() call

2025-08-29T16:21:31Z

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

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

2025-07-07T18:41:20Z

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

rpmsg: core: Remove deadcode

2025-05-06T17:11:45Z

rpmsg_send_offchannel() and rpmsg_trysend_offchannel() have been unused since they were added in 2011's commit bcabbccabffe ("rpmsg: add virtio-based remote processor messaging bus") Remove them and associated docs. Signed-off-by: Dr. David Alan Gilbert Acked-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20250429234600.301083-2-linux@treblig.org Signed-off-by: Mathieu Poirier

driver core: Constify API device_find_child() and adapt for various usages

2025-01-03T10:19:35Z

Constify the following API: struct device *device_find_child(struct device *dev, void *data, int (*match)(struct device *dev, void *data)); To : struct device *device_find_child(struct device *dev, const void *data, device_match_t match); typedef int (*device_match_t)(struct device *dev, const void *data); with the following reasons: - Protect caller's match data @*data which is for comparison and lookup and the API does not actually need to modify @*data. - Make the API's parameters (@match)() and @data have the same type as all of other device finding APIs (bus|class|driver)_find_device(). - All kinds of existing device match functions can be directly taken as the API's argument, they were exported by driver core. Constify the API and adapt for various existing usages. BTW, various subsystem changes are squashed into this commit to meet 'git bisect' requirement, and this commit has the minimal and simplest changes to complement squashing shortcoming, and that may bring extra code improvement. Reviewed-by: Alison Schofield Reviewed-by: Takashi Sakamoto Acked-by: Uwe Kleine-König # for drivers/pwm Signed-off-by: Zijun Hu Reviewed-by: Jonathan Cameron Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20241224-const_dfc_done-v5-4-6623037414d4@quicinc.com Signed-off-by: Greg Kroah-Hartman

driver core: have match() callback in struct bus_type take a const *

2024-07-03T13:16:54Z

In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki Reviewed-by: Alex Elder Acked-by: Sumit Garg Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman

rpmsg: core: Make rpmsg_class constant

2024-03-26T17:25:13Z

Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the rpmsg_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman Suggested-by: Greg Kroah-Hartman Signed-off-by: Ricardo B. Marliere Link: https://lore.kernel.org/r/20240305-class_cleanup-remoteproc-v1-1-19373374e003@marliere.net Signed-off-by: Mathieu Poirier

rpmsg: core: Make rpmsg_bus const

2024-02-05T20:43:22Z

Now that the driver core can properly handle constant struct bus_type, move the rpmsg_bus variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman Suggested-by: Greg Kroah-Hartman Signed-off-by: Ricardo B. Marliere Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20240204-bus_cleanup-rpmsg-v1-1-1703508c23b7@marliere.net Signed-off-by: Mathieu Poirier