[PATCH AUTOSEL 6.15 10/20] genirq/irq_sim: Initialize work context pointers properly

[PATCH AUTOSEL 6.15 10/20] genirq/irq_sim: Initialize work context pointers properly

[Sasha Levin]

From: Gyeyoung Baek <gye976@gmail.com>

[ Upstream commit 8a2277a3c9e4cc5398f80821afe7ecbe9bdf2819 ]

Initialize `ops` member's pointers properly by using kzalloc() instead of
kmalloc() when allocating the simulation work context. Otherwise the
pointers contain random content leading to invalid dereferencing.

Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250612124827.63259-1-gye976@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

**YES**

This commit should be backported to stable kernel trees, specifically to
the v6.11 stable series and any newer stable branches.

## Detailed Explanation:

### 1. **Critical Bug Fix**
The commit fixes a serious uninitialized memory bug. The code change
from `kmalloc()` to `kzalloc()` is critical because:

```c
// Before (buggy):
struct irq_sim_work_ctx *work_ctx __free(kfree) =
    kmalloc(sizeof(*work_ctx), GFP_KERNEL);

// After (fixed):
struct irq_sim_work_ctx *work_ctx __free(kfree) =
    kzalloc(sizeof(*work_ctx), GFP_KERNEL);
```

### 2. **The Bug Impact**
The `irq_sim_work_ctx` structure contains an `ops` member with function
pointers:
- `ops.irq_sim_irq_requested`
- `ops.irq_sim_irq_released`

When `irq_domain_create_sim_full()` is called with `ops=NULL` (which
happens when using the older `irq_domain_create_sim()` API), these
pointers are left uninitialized with random memory content.

### 3. **Potential Consequences**
The uninitialized pointers are checked in:
- `irq_sim_request_resources()`: `if
  (work_ctx->ops.irq_sim_irq_requested)`
- `irq_sim_release_resources()`: `if
  (work_ctx->ops.irq_sim_irq_released)`

If these random values are non-zero, the kernel will attempt to call
garbage function pointers, leading to:
- **Kernel crashes/panics**
- **Security vulnerabilities** (jumping to arbitrary memory)
- **Unpredictable behavior**

### 4. **Simple and Safe Fix**
The fix is minimal (changing one function call) with no side effects:
- `kzalloc()` guarantees all fields are zero-initialized
- This ensures function pointers are NULL when not explicitly set
- No performance impact (negligible difference for a one-time
  allocation)

### 5. **Affected Versions**
Based on my repository analysis:
- The bug was introduced in v6.11-rc1 (commit 011f583781fa)
- Only kernels v6.11 and newer are affected
- The fix should be backported to v6.11.y stable series

### 6. **Missing Fixes Tag**
The commit should have included:
```
Fixes: 011f583781fa ("genirq/irq_sim: add an extended irq_sim
initializer")
```

This is a textbook example of a commit that meets stable backport
criteria:
- Fixes a real bug that can cause crashes
- Small, contained change
- No new features or architectural changes
- Clear bugfix with minimal regression risk

 kernel/irq/irq_sim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
index 1a3d483548e2f..ae4c9cbd1b4b9 100644
--- a/kernel/irq/irq_sim.c
+++ b/kernel/irq/irq_sim.c
@@ -202,7 +202,7 @@ struct irq_domain *irq_domain_create_sim_full(struct fwnode_handle *fwnode,
 					      void *data)
 {
 	struct irq_sim_work_ctx *work_ctx __free(kfree) =
-				kmalloc(sizeof(*work_ctx), GFP_KERNEL);
+				kzalloc(sizeof(*work_ctx), GFP_KERNEL);
 
 	if (!work_ctx)
 		return ERR_PTR(-ENOMEM);
-- 
2.39.5

[PATCH AUTOSEL 6.15 13/20] regulator: fan53555: add enable_time support and soft-start times

[Sasha Levin]

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 bd9447dac5967..c282236959b18 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