Re: [PATCH v6 1/8] regulator: core: Add "enable and wait" functions
From: sashiko-bot@kernel.org
Date: 2026-09-01 08:03:36
Also in:
linux-devicetree
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Mismatched timebase used for `last_off` initialization, which breaks `off_on_delay` semantics. -- commit 4cf0bd57fa8e1cfa65a0e290c2b4a44f43cb23db Author: Chen-Yu Tsai [off-list ref] regulator: core: Add "enable and wait" functions In device power sequencing and initialization use cases, it is common for the driver to enable the regulator and then wait for a certain period of time to pass before continuing. In cases where the regulator supply is always on, or has been turned on or left on by another consumer, the driver could shorten the delay or skip it altogether, provided that enough time has already passed since the regulator was actually turned on.
quoted hunk ↗ jump to hunk
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 6a4008f387b5e..d7a193a3bcb28 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -3061,6 +3108,8 @@ static int _regulator_do_enable(struct regulator_dev *rdev) fsleep(delay); } + rdev->last_on = ktime_get_boottime(); + trace_regulator_enable_complete(rdev_get_name(rdev)); return 0;
[Severity: High] This isn't a bug introduced by this patch, but since you are working with timestamps in this function, could this timebase mismatch break off_on_delay semantics? In set_machine_constraints(), last_off is initialized with the monotonic clock: rdev->last_off = ktime_get(); But earlier in _regulator_do_enable(), the remaining delay is calculated using the boottime clock: ktime_t end = ktime_add_us(rdev->last_off, rdev->desc->off_on_delay); s64 remaining = ktime_us_delta(end, ktime_get_boottime()); Because ktime_get_boottime() includes suspend time and ktime_get() does not, the required delay is bypassed entirely if the system has accumulated suspend time greater than the off_on_delay. Will this lead to hardware sequence violations and incorrect functional behavior unconditionally for any regulator with an off_on_delay registered after the system has been suspended (such as via hotplug or module load)? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260901074930.764550-1-wenst@chromium.org?part=1