[PATCH AUTOSEL 6.19-6.12] media: mt9m114: Avoid a reset low spike during probe()

[Sasha Levin <sashal@kernel.org>]

From: Hans de Goede <johannes.goede@oss.qualcomm.com>

[ Upstream commit 84359d0a5e3afce5e3e3b6562efadff690614d5b ]

mt9m114_probe() requests the reset GPIO in output low state:

	sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);

and then almost immediately afterwards calls mt9m114_power_on() which does:

		gpiod_set_value(sensor->reset, 1);
		fsleep(duration);
		gpiod_set_value(sensor->reset, 0);

which means that if the reset pin was high before this code runs that
it will very briefly be driven low because of passing GPIOD_OUT_LOW when
requesting the GPIO only to be driven high again possibly directly after
that. Such a very brief driving low of the reset pin may put the chip in
a confused state.

Request the GPIO in high (reset the chip) state instead to avoid this,
turning the initial gpiod_set_value() in mt9m114_power_on() into a no-op.
and the fsleep() ensures that it will stay high long enough to properly
reset the chip.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of mt9m114 Reset GPIO Spike Fix

### Commit Message Analysis

The commit describes a hardware initialization ordering issue in the
mt9m114 camera sensor driver. During `probe()`, the reset GPIO is
requested in `GPIOD_OUT_LOW` (deasserted) state, but then
`mt9m114_power_on()` immediately drives it high (asserted/reset),
sleeps, then drives it low (deasserted). If the reset pin was already
high before probe, this creates a brief low spike that could put the
chip in a "confused state."

The fix changes `GPIOD_OUT_LOW` to `GPIOD_OUT_HIGH` so the GPIO starts
in the reset-asserted state, making the first
`gpiod_set_value(sensor->reset, 1)` in `mt9m114_power_on()` a no-op, and
the subsequent sleep ensures proper reset timing.

### Code Change Analysis

The change is a single-line modification:
```c
- sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+ sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
```

This is an extremely minimal, surgical change. It changes the initial
state of the reset GPIO from low (deasserted) to high (asserted/in-
reset), which avoids a brief glitch that could leave the sensor in a bad
state.

### Bug Classification

This is a **hardware initialization bug fix**. The brief low spike on
the reset pin is a real hardware issue that can cause the mt9m114 sensor
to enter an undefined state during probe. This can manifest as:
- Sensor failing to initialize properly
- Unreliable camera operation
- Potentially different behavior depending on the prior state of the
  GPIO (non-deterministic)

### Scope and Risk Assessment

- **Lines changed**: 1 (single token change: `GPIOD_OUT_LOW` →
  `GPIOD_OUT_HIGH`)
- **Files changed**: 1 (`drivers/media/i2c/mt9m114.c`)
- **Risk**: Very low. The change is logically sound — since
  `mt9m114_power_on()` immediately asserts reset (high), starting in the
  high state eliminates the transient glitch without changing the
  overall reset sequence.
- **Subsystem**: Media/camera driver (i2c sensor driver)

### Stability Indicators

- **Reviewed-by**: Laurent Pinchart (well-known media subsystem
  maintainer)
- **Multiple sign-offs**: Hans de Goede, Sakari Ailus, Hans Verkuil (all
  experienced media/kernel developers)
- The logic is straightforward and obviously correct

### User Impact

Users with the mt9m114 camera sensor could experience unreliable
initialization. This is a real hardware issue — the reset pin glitch
depends on the prior GPIO state, making it potentially intermittent and
hard to debug. The fix ensures deterministic, correct behavior.

### Dependency Check

The change is self-contained. It modifies a single GPIO request flag and
doesn't depend on any other commits. The mt9m114 driver has been in the
kernel for a while, so it exists in stable trees.

### Risk vs. Benefit

- **Benefit**: Fixes a real hardware initialization issue that can cause
  unreliable sensor operation
- **Risk**: Essentially zero — the change is a single constant that
  aligns the initial GPIO state with what `mt9m114_power_on()` expects
- **Trade-off**: Strongly favorable for backporting

### Concerns

This is a minor driver fix for a specific camera sensor. While the user
base may not be huge, the fix is trivially correct, has essentially zero
regression risk, and fixes a genuine hardware issue. It meets all stable
kernel criteria:
1. Obviously correct and reviewed by multiple experts
2. Fixes a real bug (hardware reset glitch)
3. Important for affected users (unreliable device initialization)
4. Extremely small and contained (1 line)
5. No new features or APIs

**YES**

 drivers/media/i2c/mt9m114.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c
index 51ebbe7ae9969..554f25071cca6 100644
--- a/drivers/media/i2c/mt9m114.c
+++ b/drivers/media/i2c/mt9m114.c
@@ -2434,7 +2434,7 @@ static int mt9m114_probe(struct i2c_client *client)
 		goto error_ep_free;
 	}
 
-	sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+	sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
 	if (IS_ERR(sensor->reset)) {
 		ret = PTR_ERR(sensor->reset);
 		dev_err_probe(dev, ret, "Failed to get reset GPIO\n");
-- 
2.51.0