Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Unnecessarily strict DT property enforcement causes probe failure. --
--- Patch [2]: [PATCH 02/16] regulator: twl: Expose the TWL4030's REGEN signal as a regulator --- commit d13717da4f5b51bb52a516562b40db8ac7694aad Author: Grond <[email protected]> regulator: twl: Expose the TWL4030's REGEN signal as a regulator This commit exposes the TWL4030 REGEN signal as a regulator. This functionality is needed on some boards where REGEN is used to drive external regulators. > diff --git a/drivers/regulator/twl-regulator.c > b/drivers/regulator/twl-regulator.c > index 5bacfcebf59aa..d883ee8abec32 100644 > --- a/drivers/regulator/twl-regulator.c > +++ b/drivers/regulator/twl-regulator.c [ ... ] > @@ -615,6 +647,26 @@ static int twlreg_probe(struct platform_device *pdev) > case TWL4030_REG_VINTANA2: > case TWL4030_REG_VINTDIG: > c->always_on = true; > + break; > + case TWL4030_REG_REGEN: [ ... ] > + info->desc.fixed_uV = c->min_uV; > + > + ret = of_property_read_u32(pdev->dev.of_node, > "startup-delay-us", > + &info->desc.enable_time); > + if (ret) { > + dev_err(&pdev->dev, "no valid startup delay set in DT: > %d\n", ret); > + return ret; > + } [Severity: Low] This isn't a bug, but does this code need to fail the probe if the startup-delay-us property is missing? Since enable_time already defaults to 0 in the template structure, could this be treated as an optional property similar to standard fixed-regulator behavior, rather than strictly enforcing its presence and returning an error? > + > + break; > default: > break; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
