Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] arm64: dts: qcom: sm6350-lena: duplicate qcom-pon device from pmk8350.dtsi --
commit ab0852d01a0d63b999b8519d90b2ed3ef4a0420c Author: erebion <[email protected]> arm64: dts: qcom: sm6350-lena: Enable PMK8350 This commit includes pmk8350.dtsi and configures and enables the PMK8350 ADC, thermal monitor, and RTC nodes on the Sony Xperia 10 III. > diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts > b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts > index 61e191133cb4f..246a290e44f77 100644 > --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts > +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts > @@ -8,7 +8,11 @@ > #define PM7250B_SID 2 > #define PM7250B_SID1 3 > > +/* PMK8350 (in reality a PMK8003) is configured to use SID6 instead of 0 */ > +#define PMK8350_SID 6 > + > #include <dt-bindings/firmware/qcom,scm.h> > +#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h> > #include <dt-bindings/leds/common.h> > #include <dt-bindings/pinctrl/qcom,pmic-gpio.h> > #include <dt-bindings/regulator/qcom,rpmh-regulator.h> > @@ -16,6 +20,7 @@ > #include "pm6150l.dtsi" > #include "pm6350.dtsi" > #include "pm7250b.dtsi" > +#include "pmk8350.dtsi" [Severity: Medium] Does including pmk8350.dtsi alongside pm6350.dtsi without disabling or deleting pmk8350_pon cause a probe conflict between two active qcom-pon instances? In arch/arm64/boot/dts/qcom/pm6350.dtsi, pm6350_pon is already enabled as the primary PON device hosting reboot modes, pm6350_pwrkey, and pm6350_resin: arch/arm64/boot/dts/qcom/pm6350.dtsi: pm6350_pon: pon@800 { compatible = "qcom,pm8998-pon"; reg = <0x800>; mode-bootloader = <0x2>; mode-recovery = <0x1>; In arch/arm64/boot/dts/qcom/pmk8350.dtsi, pmk8350_pon (and a root /reboot-mode nvmem-reboot-mode node) is also enabled by default: arch/arm64/boot/dts/qcom/pmk8350.dtsi: pmk8350_pon: pon@1300 { compatible = "qcom,pmk8350-pon"; reg = <0x1300>, <0x800>; reg-names = "hlos", "pbs"; Both qcom,pm8998-pon and qcom,pmk8350-pon match qcom_pon_id_table with reason_shift = GEN2_REASON_SHIFT in drivers/power/reset/qcom-pon.c: qcom_pon_probe() { ... if (reason_shift != NO_REASON_SHIFT) { pon->reboot_mode.dev = &pdev->dev; pon->reason_shift = reason_shift; pon->reboot_mode.write = qcom_pon_reboot_mode_write; error = devm_reboot_mode_register(&pdev->dev, &pon->reboot_mode); if (error) { dev_err(&pdev->dev, "can't register reboot mode\n"); return error; } } platform_set_drvdata(pdev, pon); return devm_of_platform_populate(&pdev->dev); } In drivers/power/reset/reboot-mode.c, devm_reboot_mode_register() -> reboot_mode_register() -> reboot_mode_create_device() registers a sysfs class device named after reboot->dev->driver->name ("qcom-pon"): reboot_mode_create_device() { ... priv->reboot_mode_device = device_create(&reboot_mode_class, NULL, 0, (void *)priv, "%s", reboot->dev->driver->name); ... } reboot_mode_register() { ... ret = reboot_mode_create_device(reboot); if (ret) goto error; return 0; error: kfree(info); reboot_mode_unregister(reboot); return ret; } When the second qcom-pon instance probes, device_create() fails with -EEXIST and triggers a sysfs duplicate filename warning, and the error path in reboot_mode_register() calls reboot_mode_unregister(), which looks up "qcom-pon" by driver name via class_find_device(), unregisters the first instance's sysfs device, and leaks the struct device reference returned by class_find_device(). In addition, if pmk8350_pon probes before pm6350_pon, qcom_pon_probe() for pm6350_pon returns an error before reaching devm_of_platform_populate(), preventing pm6350_pwrkey and pm6350_resin from being populated. Should pmk8350_pon (and the root /reboot-mode node from pmk8350.dtsi) be disabled or deleted in sm6350-sony-xperia-lena-pdx213.dts? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8
