[PATCH AUTOSEL 6.19-6.12] media: mt9m114: Return -EPROBE_DEFER if no endpoint is found

[Sasha Levin <sashal@kernel.org>]

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

[ Upstream commit 437e1f6a960035166495a5117aacbc596115eeb6 ]

With IPU# bridges, endpoints may only be created when the IPU bridge is
initialized. This may happen after the sensor driver's first probe().

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: Return -EPROBE_DEFER if no endpoint is found

### Commit Message Analysis

The commit changes the mt9m114 camera sensor driver to return
`-EPROBE_DEFER` instead of `-EINVAL` when no fwnode graph endpoint is
found during probe. The rationale is that on ACPI systems (specifically
with IPU bridges), the fwnode graph endpoints may not yet exist at the
time the sensor driver first probes — they are created later when the
IPU bridge driver initializes.

### Code Change Analysis

The change is small and focused:

1. **Old behavior**: When `fwnode_graph_get_next_endpoint()` returns
   NULL, the driver logs an error and returns `-EINVAL`, causing
   permanent probe failure.

2. **New behavior**: When no endpoint is found, return `-EPROBE_DEFER`
   (via `dev_err_probe()`), which tells the driver core to retry probing
   later. A comment explains this is needed because on ACPI systems, the
   bridge driver that creates the fwnode graph may not have probed yet.

3. The `dev_err()` is replaced with `dev_err_probe()`, which is the
   standard kernel pattern for deferred probing — it only logs at debug
   level for `-EPROBE_DEFER` (avoiding log spam) and at error level for
   other errors.

### Bug Classification

This fixes a **real probe ordering bug** on ACPI-based systems. Without
this fix, the mt9m114 sensor driver will permanently fail to probe on
systems where the IPU bridge hasn't initialized yet at the time of the
first probe attempt. This is a **race condition** between driver
initialization order — the sensor driver needs endpoints that the bridge
driver creates, but there's no guaranteed ordering.

This is a common pattern in the kernel — many drivers have been updated
to return `-EPROBE_DEFER` for exactly this kind of dependency issue.
It's a well-understood fix.

### Scope and Risk Assessment

- **Lines changed**: ~15 lines (very small)
- **Files affected**: 1 file (`drivers/media/i2c/mt9m114.c`)
- **Risk**: Very low. The change only affects the case where no endpoint
  is found. If an endpoint IS found, behavior is unchanged. The worst
  case is that on systems where no endpoint will ever appear, the driver
  will defer indefinitely rather than failing immediately — but this is
  standard kernel behavior for deferred probing, and the driver core
  handles this gracefully.

### User Impact

Users with mt9m114 camera sensors on ACPI-based systems (e.g., Intel
platforms with IPU bridges) would find the camera doesn't work at all
without this fix. The sensor driver would fail to probe permanently.
This is a real-world issue affecting actual hardware functionality.

### Review and Testing

- **Reviewed-by: Laurent Pinchart** — well-known media subsystem
  maintainer
- **Signed-off-by**: Hans de Goede (Qualcomm/known kernel developer),
  Sakari Ailus (Intel, media maintainer), Hans Verkuil (media subsystem
  maintainer)

The patch has strong review credentials from multiple experienced media
subsystem developers.

### Stable Criteria Check

1. **Obviously correct and tested**: Yes — standard `-EPROBE_DEFER`
   pattern, reviewed by multiple maintainers
2. **Fixes a real bug**: Yes — sensor driver fails to probe on ACPI
   systems with IPU bridges
3. **Important issue**: Moderate — camera hardware doesn't work without
   this fix on affected systems
4. **Small and contained**: Yes — ~15 lines in a single file
5. **No new features**: Correct — this is a bug fix for probe ordering
6. **Applies cleanly**: Should apply cleanly as it's a self-contained
   change

### Dependency Check

Let me verify if the mt9m114 driver exists in older stable trees and if
there are any dependencies.

The `dev_err_probe()` function has been available since kernel 5.10, so
this should be backportable to any stable tree that has the mt9m114
driver. The mt9m114 driver was added relatively recently (v6.x era), so
the backport scope may be limited to recent stable trees, but that
doesn't affect the decision.

### Conclusion

This is a straightforward probe-deferral fix for a real hardware
functionality issue. It uses a well-established kernel pattern
(`-EPROBE_DEFER`), is small and surgical, has been reviewed by multiple
media subsystem maintainers, and carries very low regression risk. It
fixes a real problem where the mt9m114 camera sensor fails to work on
ACPI-based systems with IPU bridges.

**YES**

 drivers/media/i2c/mt9m114.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c
index 554f25071cca6..b1325e2cd1321 100644
--- a/drivers/media/i2c/mt9m114.c
+++ b/drivers/media/i2c/mt9m114.c
@@ -2360,11 +2360,17 @@ static int mt9m114_parse_dt(struct mt9m114 *sensor)
 	struct fwnode_handle *ep;
 	int ret;
 
+	/*
+	 * On ACPI systems the fwnode graph can be initialized by a bridge
+	 * driver, which may not have probed yet. Wait for this.
+	 *
+	 * TODO: Return an error once bridge driver code will have moved
+	 * to the ACPI core.
+	 */
 	ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
-	if (!ep) {
-		dev_err(&sensor->client->dev, "No endpoint found\n");
-		return -EINVAL;
-	}
+	if (!ep)
+		return dev_err_probe(&sensor->client->dev, -EPROBE_DEFER,
+				     "waiting for fwnode graph endpoint\n");
 
 	sensor->bus_cfg.bus_type = V4L2_MBUS_UNKNOWN;
 	ret = v4l2_fwnode_endpoint_alloc_parse(ep, &sensor->bus_cfg);
-- 
2.51.0