* [PATCH AUTOSEL 6.6 11/18] regulator: fan53555: add enable_time support and soft-start times
[not found] <20250624041214.84135-1-sashal@kernel.org>
@ 2025-06-24 4:12 ` Sasha Levin
0 siblings, 0 replies; only message in thread
From: Sasha Levin @ 2025-06-24 4:12 UTC (permalink / raw)
To: patches, stable
Cc: Heiko Stuebner, Mark Brown, Sasha Levin, lgirdwood, linux-kernel
From: Heiko Stuebner <heiko@sntech.de>
[ Upstream commit 8acfb165a492251a08a22a4fa6497a131e8c2609 ]
The datasheets for all the fan53555 variants (and clones using the same
interface) define so called soft start times, from enabling the regulator
until at least some percentage of the output (i.e. 92% for the rk860x
types) are available.
The regulator framework supports this with the enable_time property
but currently the fan53555 driver does not define enable_times for any
variant.
I ran into a problem with this while testing the new driver for the
Rockchip NPUs (rocket), which does runtime-pm including disabling and
enabling a rk8602 as needed. When reenabling the regulator while running
a load, fatal hangs could be observed while enabling the associated
power-domain, which the regulator supplies.
Experimentally setting the regulator to always-on, made the issue
disappear, leading to the missing delay to let power stabilize.
And as expected, setting the enable-time to a non-zero value
according to the datasheet also resolved the regulator-issue.
The datasheets in nearly all cases only specify "typical" values,
except for the fan53555 type 08. There both a typical and maximum
value are listed - 40uS apart.
For all typical values I've added 100uS to be on the safe side.
Individual details for the relevant regulators below:
- fan53526:
The datasheet for all variants lists a typical value of 150uS, so
make that 250uS with safety margin.
- fan53555:
types 08 and 18 (unsupported) are given a typical enable time of 135uS
but also a maximum of 175uS so use that value. All the other types only
have a typical time in the datasheet of 300uS, so give a bit margin by
setting it to 400uS.
- rk8600 + rk8602:
Datasheet reports a typical value of 260us, so use 360uS to be safe.
- syr82x + syr83x:
All datasheets report typical soft-start values of 300uS for these
regulators, so use 400uS.
- tcs452x:
Datasheet sadly does not report a soft-start time, so I've not set
an enable-time
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20250606190418.478633-1-heiko@sntech.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Based on my analysis of the commit message and code changes, here is my
determination:
**YES**
This commit should be backported to stable kernel trees. Here is my
extensive explanation:
## Analysis Summary
### 1. **The commit fixes a critical bug affecting system stability**
The commit message clearly describes a real-world failure scenario:
- The author encountered "fatal hangs" when enabling a power-domain
supplied by the rk8602 regulator
- The hangs occurred specifically during runtime-pm operations when re-
enabling the regulator under load
- The issue was resolved by implementing proper enable timing delays
This indicates a serious stability issue that can cause system crashes
or hangs.
### 2. **The fix is minimal and well-contained**
The code changes are limited to:
- Adding a single `enable_time` field to the `fan53555_device_info`
structure
- Setting appropriate timing values for each regulator variant based on
their datasheets
- Passing this value to the regulator framework via `rdesc->enable_time`
The changes don't introduce new features or architectural modifications
- they simply provide timing information that the regulator framework
already supports.
### 3. **The issue affects multiple widely-used regulators**
The fix applies to several regulator variants:
- fan53526 (Fairchild)
- fan53555 (Fairchild)
- rk8600/rk8602 (Rockchip)
- syr82x/syr83x (Silergy)
These are commonly used voltage regulators, particularly in ARM-based
systems and embedded devices.
### 4. **The fix follows established patterns**
Looking at the git history, many other regulator drivers have had
similar enable_time fixes added:
- `regulator: rk808: Set the enable time for LDOs`
- `regulator: max77686: Configure enable time to properly handle
regulator enable`
- `regulator: bd718x7: Add enable times`
This indicates that missing enable times is a known class of issues that
causes real problems.
### 5. **The timing values are conservative and well-researched**
The commit shows careful analysis:
- Values are based on datasheet specifications
- A safety margin of 100μS is added to typical values
- For fan53555 type 08, the maximum value (175μS) is used instead of
typical (135μS)
### 6. **Risk assessment shows low regression potential**
The changes:
- Only add delays where none existed before
- Use conservative timing values with safety margins
- Don't modify any existing behavior except to add necessary
stabilization delays
- Are confined to specific regulator driver without affecting core
framework
### 7. **The bug can cause data corruption or hardware damage**
Power domain failures during runtime-pm operations can potentially lead
to:
- Data corruption if storage devices lose power unexpectedly
- Hardware damage if voltage rails become unstable
- System instability requiring hard resets
## Conclusion
This commit meets all the criteria for stable backporting:
- Fixes an important bug (system hangs)
- Minimal, contained changes
- No new features or architectural changes
- Low risk of regression
- Affects commonly used hardware
The missing enable times can cause real-world failures, particularly in
systems using runtime power management. The fix is straightforward and
follows established patterns in the regulator subsystem.
drivers/regulator/fan53555.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/regulator/fan53555.c b/drivers/regulator/fan53555.c
index 48f312167e535..8912f5be72707 100644
--- a/drivers/regulator/fan53555.c
+++ b/drivers/regulator/fan53555.c
@@ -147,6 +147,7 @@ struct fan53555_device_info {
unsigned int slew_mask;
const unsigned int *ramp_delay_table;
unsigned int n_ramp_values;
+ unsigned int enable_time;
unsigned int slew_rate;
};
@@ -282,6 +283,7 @@ static int fan53526_voltages_setup_fairchild(struct fan53555_device_info *di)
di->slew_mask = CTL_SLEW_MASK;
di->ramp_delay_table = slew_rates;
di->n_ramp_values = ARRAY_SIZE(slew_rates);
+ di->enable_time = 250;
di->vsel_count = FAN53526_NVOLTAGES;
return 0;
@@ -296,10 +298,12 @@ static int fan53555_voltages_setup_fairchild(struct fan53555_device_info *di)
case FAN53555_CHIP_REV_00:
di->vsel_min = 600000;
di->vsel_step = 10000;
+ di->enable_time = 400;
break;
case FAN53555_CHIP_REV_13:
di->vsel_min = 800000;
di->vsel_step = 10000;
+ di->enable_time = 400;
break;
default:
dev_err(di->dev,
@@ -311,13 +315,19 @@ static int fan53555_voltages_setup_fairchild(struct fan53555_device_info *di)
case FAN53555_CHIP_ID_01:
case FAN53555_CHIP_ID_03:
case FAN53555_CHIP_ID_05:
+ di->vsel_min = 600000;
+ di->vsel_step = 10000;
+ di->enable_time = 400;
+ break;
case FAN53555_CHIP_ID_08:
di->vsel_min = 600000;
di->vsel_step = 10000;
+ di->enable_time = 175;
break;
case FAN53555_CHIP_ID_04:
di->vsel_min = 603000;
di->vsel_step = 12826;
+ di->enable_time = 400;
break;
default:
dev_err(di->dev,
@@ -350,6 +360,7 @@ static int fan53555_voltages_setup_rockchip(struct fan53555_device_info *di)
di->slew_mask = CTL_SLEW_MASK;
di->ramp_delay_table = slew_rates;
di->n_ramp_values = ARRAY_SIZE(slew_rates);
+ di->enable_time = 360;
di->vsel_count = FAN53555_NVOLTAGES;
return 0;
@@ -372,6 +383,7 @@ static int rk8602_voltages_setup_rockchip(struct fan53555_device_info *di)
di->slew_mask = CTL_SLEW_MASK;
di->ramp_delay_table = slew_rates;
di->n_ramp_values = ARRAY_SIZE(slew_rates);
+ di->enable_time = 360;
di->vsel_count = RK8602_NVOLTAGES;
return 0;
@@ -395,6 +407,7 @@ static int fan53555_voltages_setup_silergy(struct fan53555_device_info *di)
di->slew_mask = CTL_SLEW_MASK;
di->ramp_delay_table = slew_rates;
di->n_ramp_values = ARRAY_SIZE(slew_rates);
+ di->enable_time = 400;
di->vsel_count = FAN53555_NVOLTAGES;
return 0;
@@ -594,6 +607,7 @@ static int fan53555_regulator_register(struct fan53555_device_info *di,
rdesc->ramp_mask = di->slew_mask;
rdesc->ramp_delay_table = di->ramp_delay_table;
rdesc->n_ramp_values = di->n_ramp_values;
+ rdesc->enable_time = di->enable_time;
rdesc->owner = THIS_MODULE;
rdev = devm_regulator_register(di->dev, &di->desc, config);
--
2.39.5
^ permalink raw reply [flat|nested] only message in thread