Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using `device_set_node()` on an already-registered platform device destructively overwrites its primary firmware node and introduces dangling pointer/use-after-free risks.
--
--- Patch [7]: [PATCH v2 07/11] regulator: wm831x: support software node in platform data ---
commit 41eed35e80fd0a1bdad7b80c52433a74629a0ec0
Author: Dmitry Torokhov [off-list ref]
regulator: wm831x: support software node in platform data
This commit allows passing a software node via platform data to the
wm831x buckv regulators. It attempts to read DVS configuration from the
software node if it is present, falling back to legacy platform data.
quoted hunk ↗ jump to hunk
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -332,14 +333,26 @@ static void wm831x_buckv_dvs_init(struct platform_device *pdev,
struct wm831x *wm831x = dcdc->wm831x;
int ret;
u16 ctrl;
+ int dvs_control_src;
+ u32 val;
if (!pdata)
return;
+ if (pdata->swnode) {
+ struct fwnode_handle *fwnode = software_node_fwnode(pdata->swnode);
+
+ if (fwnode)
+ device_set_node(&pdev->dev, fwnode);
[Severity: High]
Does overwriting the primary firmware node here with device_set_node()
safely manage the device lifecycle?
Calling device_set_node() on an already-registered platform device destructively
overwrites its primary fwnode, clearing any Device Tree or ACPI bindings
established by the MFD core. It also bypasses the correct API for secondary
nodes (device_add_software_node()).
If a later step in wm831x_buckv_probe() fails and the driver unwinds, the
modified pdev->dev.fwnode is never restored. This leaves a dangling pointer
to the unrefcounted software node.
Should this code use device_add_software_node() instead?
+ }
+
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-samsung-kp-v2-0-3c6ed4c9b3b6@gmail.com?part=7