Add Anbernic RG Vita-Pro

Documentation/devicetree/bindings/power/supply/sgmicro,sgm41542.yaml line 43

[Severity: Low]
Since this device acts as a battery charger, should it include an allOf block with a $ref to power-supply.yaml? Without it, standard properties like monitored-battery lack their inherited type definitions.

[ ... ]

Documentation/devicetree/bindings/power/supply/sgmicro,sgm41542.yaml line 66

[Severity: Low]
If this schema is updated to reference the core power-supply schema, does this need to be changed to unevaluatedProperties: false? Using
additionalProperties: false without inheriting the common power-supply schema causes schema validation to strictly reject any other standard power-supply properties added to the device tree node.

Documentation/devicetree/bindings/power/supply/sgmicro,sgm41542.yaml line 78

[Severity: Low]
Is it standard to place these include directives after the initial battery node? While technically valid C preprocessor syntax, DT binding conventions typically require all include directives to be placed at the very top of the examples block, prior to defining any nodes.

drivers/power/supply/sgm41542_charger.c line 263

[Severity: High]
Does this code silently apply an overvoltage condition? If 4.336V is requested, the calculation generates a reg_val of 0x0F, which as noted in the comment configures the hardware to 4.352V instead of 4.336V. Is there a way to clamp or shift this value to a safe voltage to prevent applying a higher voltage than requested?

[ ... ]

drivers/power/supply/sgm41542_charger.c line 339

[Severity: High]
Does this calculation truncate values that fall outside the 4-bit limit of the hardware mask? For instance, assigning a voltage of 5.5V to the 3.9V bucket will yield a reg_val of 16, which will be bitwise truncated to 0 when masked by SGM4154X_VINDPM_V_MASK (max value 15), applying 3.9V instead of 5.5V.

[ ... ]

drivers/power/supply/sgm41542_charger.c line 372

[Severity: Medium]
When requesting 3.8A maximum input current, does this get truncated to 600mA? Requesting 3.8A gives a reg_val of 37 (0x25), but since SGM4154X_IINDPM_I_MASK is only a 5-bit mask (0x1F), the value will be truncated during the bitwise operation (0x25 & 0x1F = 0x05), which translates to 600mA instead of the intended 3.8A.

[ ... ]

drivers/power/supply/sgm41542_charger.c line 661

[Severity: Medium]
Are negative error codes from I2C reads exposed directly as valid userspace property values here? If a function like sgm4154x_get_chrg_volt() fails, it returns an error code like -EIO, which is assigned to val->intval while sgm4154x_charger_get_property() returns 0 for success.

[ ... ]

drivers/power/supply/sgm41542_charger.c line 790

[Severity: Critical]
Can this code crash by dereferencing an uninitialized pointer?

If power_supply_get_battery_info() fails (e.g., the devicetree node is missing), bat_info remains uninitialized on the stack. The error is logged but execution continues, and the uninitialized bat_info pointer is passed to power_supply_put_battery_info() which will try to free internal structures at random memory addresses.

[ ... ]

drivers/power/supply/sgm41542_charger.c line 966

[Severity: High]
Should there be a return statement here? Execution currently falls through and registers the driver despite a hardware detection failure.

drivers/power/supply/sgm41542_charger.c line 972

[Severity: High]
Does registering the power supply here create a race condition with the workqueue initialization?

If userspace reads or modifies the sysfs properties (like setting ONLINE=1) right after the power supply is registered but before sgm_monitor_wq is allocated below, the driver will call queue_delayed_work() with a NULL workqueue, triggering a NULL pointer dereference.

drivers/power/supply/sgm41542_charger.c line 986

[Severity: Medium]
Will this leak the wake source configuration? The wake IRQ is enabled here, but there is no corresponding disable_irq_wake() call on probe error paths (such as a workqueue allocation failure below) or when the driver is unbound.

drivers/power/supply/sgm41542_charger.c line 996

[Severity: High]
Should the return value of sgm4154x_vbus_regulator_register() be checked? If the regulator subsystem returns -EPROBE_DEFER or another error code, the error is swallowed and probe succeeds, leaving the OTG regulator non-functional and breaking probe deferral.

[ ... ]

drivers/power/supply/sgm41542_charger.c line 1029

[Severity: High]
Does this missing .remove callback lead to a Use-After-Free?

Because there is no .remove callback, the sgm_delay_work delayed work is never explicitly canceled when the module is unbound. Since the work re-arms itself, the timer will fire after the sgm structure is freed. Additionally, because devres destroys resources in reverse order, the workqueue will be destroyed while the power supply is still exposed to sysfs, allowing queue_delayed_work() to be called on a freed workqueue.

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

drivers/gpu/drm/panel/panel-anbernic-td4310.c line 87

[Severity: Medium]
Does this code leave the vdd regulator and enable_gpio enabled if a DCS command fails?

If dsi_ctx.accum_err is non-zero, this returns immediately instead of jumping to the err_reset and err_enable cleanup labels.

drivers/gpu/drm/panel/panel-anbernic-td4310.c line 103

[Severity: Medium]
Is it intentional to use a hardcoded 120ms delay here instead of using the panel-specific disable_delay or unprepare_delay fields defined in the panel_info struct?

[ ... ]

drivers/gpu/drm/panel/panel-anbernic-td4310.c line 171

[Severity: High]
Could requesting this GPIO with GPIOD_OUT_HIGH drive the signal active before the vdd regulator is enabled in panel_anbernic_td4310_prepare()?

This might violate hardware power sequencing by driving control signals active while the main panel IC is unpowered.

drivers/gpu/drm/panel/panel-anbernic-td4310.c line 192

[Severity: Low]
Is devm_drm_panel_add available in the DRM subsystem?

It looks like this might cause a build failure due to an implicit function declaration.

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 43

[Severity: Medium]
Is this threshold correct? 1750 microvolts (1.75mV) is extremely low and would be highly sensitive to minor resistance or ground bounce. Was this intended to be the raw 12-bit ADC value (where 1750 represents ~769mV) rather than microvolts?

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 57

[Severity: Medium]
Does this also use a raw ADC value instead of microvolts?

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 67

[Severity: Medium]
The capacity here is configured to 8000mAh, which contradicts the 5000mAh mentioned in the commit message. An incorrect capacity can cause battery fuel gauge drivers to miscalculate the state of charge. Which value is accurate?

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 69

[Severity: Medium]
Is the constant charge current intended to be 10A? While the charger IC might have a hardware limit, 10 Amps is a 2C charge rate for a 5000mAh battery, which seems dangerously high. Was this intended to be 1A or 2A?

[ ... ]

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 1198

[Severity: Medium]
Does the eMMC node need explicit vmmc-supply and vqmmc-supply properties? Omitting these forces the MMC subsystem to fall back to dummy regulators, which triggers kernel warnings and can prevent the driver from executing necessary power cycles during error recovery.

[ ... ]

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 1226

[Severity: Medium]
How are the analog joysticks accessed from userspace? This node configures the SPI controller but does not instantiate any child devices (such as a spidev node). Without a child node, the kernel will not register a device, and no userspace interface will be created.

[ ... ]

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 1269

[Severity: Medium]
This node defines an RTL8822CS module over UART, but the commit message indicates the hardware uses an RTL8852BE combo module (which typically uses PCIe for Wi-Fi and USB for Bluetooth). Could you confirm which module is correct?

arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts line 1271

[Severity: High]
Are these GPIOs mapped correctly? The pinctrl defined earlier labels RK_PB6 as bt_reset_gpio and RK_PB5 as bt_wake_gpio. Driving the wake pin with the enable/reset logic and vice versa will leave the module in reset.