[PATCH RESEND v4 0/3] drm/bridge: sii9234: use extcon to detect cable attachment

[PATCH RESEND v4 0/3] drm/bridge: sii9234: use extcon to detect cable attachment

[Henrik Grimler]

Hi,

This series fixes so HDMI through the sii9234 MHL chip works when
cable is hotplugged, by making the MHL chip use extcon cable detection
functions. Patch 3, that actually implements the extcon parts, is heavily
inspired by commit 688838442147 ("drm/bridge/sii8620: use micro-USB
cable detection logic to detect MHL") by Maciej Purski.

Before these changes, HDMI only worked if cable was plugged in before
booting. If no cable was connected, then wlr-randr still showed HDMI
as connected, with 0x0 px, which confused at least some UIs (phosh)
and caused problems:
https://gitlab.gnome.org/World/Phosh/phosh/-/issues/828

Tested on exynos4412-i9305.

Best regards,
Henrik Grimler

Signed-off-by: Henrik Grimler <henrik@grimler.se>
---
Changes in v4:
- Collect tags
- Link to v3: https://lore.kernel.org/r/20250824-exynos4-sii9234-driver-v3-0-80849e716a37@grimler.se

Changes in v3:
- Fix return of dev_err_probe in patch 2 and patch 3, spotted by
  Dmitry and Marek respectively.
- Change to depends on EXTCON || !EXTCON instead of select
- Collect tags for patch 1 (not 3 since there were (minor) changes)
- Link to v2: https://lore.kernel.org/r/20250724-exynos4-sii9234-driver-v2-0-faee244f1d40@grimler.se

Changes in v2:
- Add dependency on extcon in patch 3. Issue reported by kernel test robot <lkp@intel.com>
- Link to v1: https://lore.kernel.org/r/20250721-exynos4-sii9234-driver-v1-0-2e47ed02f677@grimler.se

---
Henrik Grimler (3):
      drm/bridge: sii9234: fix some typos in comments and messages
      drm/bridge: sii9234: use dev_err_probe where applicable
      drm/bridge: sii9234: use extcon cable detection logic to detect MHL

 drivers/gpu/drm/bridge/Kconfig   |   1 +
 drivers/gpu/drm/bridge/sii9234.c | 124 +++++++++++++++++++++++++++++++--------
 2 files changed, 102 insertions(+), 23 deletions(-)
---
base-commit: a87fef0880c4f52769b5a3c2fc1b2d73aaa04eb3
change-id: 20231218-exynos4-sii9234-driver-d817d4b511d5

Best regards,
-- 
Henrik Grimler <henrik@grimler.se>

[PATCH RESEND v4 1/3] drm/bridge: sii9234: fix some typos in comments and messages

[Henrik Grimler]

Fix spelling and formatting so that the code is easier to follow, and
so that it is more searchable.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Henrik Grimler <henrik@grimler.se>
---
v4: no changes
v3: collect tags
v2: no changes
---
 drivers/gpu/drm/bridge/sii9234.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
index bb1bed03eb5b..930117bbba87 100644
--- a/drivers/gpu/drm/bridge/sii9234.c
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -339,7 +339,7 @@ static int sii9234_cbus_reset(struct sii9234 *ctx)
 	return sii9234_clear_error(ctx);
 }
 
-/* Require to chek mhl imformation of samsung in cbus_init_register */
+/* Require to check mhl information of samsung in cbus_init_register */
 static int sii9234_cbus_init(struct sii9234 *ctx)
 {
 	cbus_writeb(ctx, 0x07, 0xF2);
@@ -614,7 +614,7 @@ static void sii9234_cable_out(struct sii9234 *ctx)
 
 	disable_irq(to_i2c_client(ctx->dev)->irq);
 	tpi_writeb(ctx, TPI_DPD_REG, 0);
-	/* Turn on&off hpd festure for only QCT HDMI */
+	/* Turn on&off hpd feature for only QCT HDMI */
 	sii9234_hw_off(ctx);
 
 	ctx->state = ST_OFF;
@@ -708,7 +708,7 @@ static enum sii9234_state sii9234_rsen_change(struct sii9234 *ctx)
 {
 	int value;
 
-	/* Work_around code to handle wrong interrupt */
+	/* Workaround code to handle wrong interrupt */
 	if (ctx->state != ST_RGND_1K) {
 		dev_err(ctx->dev, "RSEN_HIGH without RGND_1K\n");
 		return ST_FAILURE;
@@ -723,9 +723,9 @@ static enum sii9234_state sii9234_rsen_change(struct sii9234 *ctx)
 	}
 	dev_dbg(ctx->dev, "RSEN lost\n");
 	/*
-	 * Once RSEN loss is confirmed,we need to check
-	 * based on cable status and chip power status,whether
-	 * it is SINK Loss(HDMI cable not connected, TV Off)
+	 * Once RSEN loss is confirmed, we need to check
+	 * based on cable status and chip power status, whether
+	 * it is SINK Loss (HDMI cable not connected, TV Off)
 	 * or MHL cable disconnection
 	 * TODO: Define the below mhl_disconnection()
 	 */
@@ -820,7 +820,7 @@ static int sii9234_init_resources(struct sii9234 *ctx,
 	int ret;
 
 	if (!ctx->dev->of_node) {
-		dev_err(ctx->dev, "not DT device\n");
+		dev_err(ctx->dev, "no DT device\n");
 		return -ENODEV;
 	}
 

-- 
2.54.0

[PATCH RESEND v4 2/3] drm/bridge: sii9234: use dev_err_probe where applicable

[Henrik Grimler]

In case of error during resource acquisition the driver should print
an error message only if it is not deferred probe. Use dev_err_probe
helper to handle this, which will also record defer probe reason for
debugging.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Henrik Grimler <henrik@grimler.se>
---
v4: collect tags
v3: add missing return in error path, spotted by Dmitry
v2: no changes
---
 drivers/gpu/drm/bridge/sii9234.c | 21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
index 930117bbba87..e43248e515b3 100644
--- a/drivers/gpu/drm/bridge/sii9234.c
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -825,21 +825,17 @@ static int sii9234_init_resources(struct sii9234 *ctx,
 	}
 
 	ctx->gpio_reset = devm_gpiod_get(ctx->dev, "reset", GPIOD_OUT_LOW);
-	if (IS_ERR(ctx->gpio_reset)) {
-		dev_err(ctx->dev, "failed to get reset gpio from DT\n");
-		return PTR_ERR(ctx->gpio_reset);
-	}
+	if (IS_ERR(ctx->gpio_reset))
+		return dev_err_probe(ctx->dev, PTR_ERR(ctx->gpio_reset),
+				     "failed to get reset gpio from DT\n");
 
 	ctx->supplies[0].supply = "avcc12";
 	ctx->supplies[1].supply = "avcc33";
 	ctx->supplies[2].supply = "iovcc18";
 	ctx->supplies[3].supply = "cvcc12";
 	ret = devm_regulator_bulk_get(ctx->dev, 4, ctx->supplies);
-	if (ret) {
-		if (ret != -EPROBE_DEFER)
-			dev_err(ctx->dev, "regulator_bulk failed\n");
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(ctx->dev, ret, "regulator_bulk failed\n");
 
 	ctx->client[I2C_MHL] = client;
 
@@ -911,10 +907,9 @@ static int sii9234_probe(struct i2c_client *client)
 					sii9234_irq_thread,
 					IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
 					"sii9234", ctx);
-	if (ret < 0) {
-		dev_err(dev, "failed to install IRQ handler\n");
-		return ret;
-	}
+	if (ret < 0)
+		return dev_err_probe(dev, ret,
+				     "failed to install IRQ handler\n");
 
 	ret = sii9234_init_resources(ctx, client);
 	if (ret < 0)

-- 
2.54.0

[PATCH RESEND v4 3/3] drm/bridge: sii9234: use extcon cable detection logic to detect MHL

[Henrik Grimler]

To use MHL we currently need the MHL chip to be permanently on, which
consumes unnecessary power. Let's use extcon attached to MUIC to enable
the MHL chip only if it detects an MHL cable.

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Henrik Grimler <henrik@grimler.se>
---
v4: collect tags
v3: add missing return in error path, spotted by Marek
    Use depends on EXTCON || !EXTCON instead of select
v2: add dependency on extcon. Issue reported by kernel test robot
    <lkp@intel.com>
---
 drivers/gpu/drm/bridge/Kconfig   |  1 +
 drivers/gpu/drm/bridge/sii9234.c | 89 ++++++++++++++++++++++++++++++++++++++--
 2 files changed, 87 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 39385deafc68..a8343df2d424 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -310,6 +310,7 @@ config DRM_SII902X
 config DRM_SII9234
 	tristate "Silicon Image SII9234 HDMI/MHL bridge"
 	depends on OF
+	depends on EXTCON || !EXTCON
 	help
 	  Say Y here if you want support for the MHL interface.
 	  It is an I2C driver, that detects connection of MHL bridge
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
index e43248e515b3..72c6aeed6e12 100644
--- a/drivers/gpu/drm/bridge/sii9234.c
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -19,6 +19,7 @@
 
 #include <linux/delay.h>
 #include <linux/err.h>
+#include <linux/extcon.h>
 #include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/interrupt.h>
@@ -26,6 +27,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/of_graph.h>
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
@@ -170,8 +172,12 @@ struct sii9234 {
 	struct drm_bridge bridge;
 	struct device *dev;
 	struct gpio_desc *gpio_reset;
-	int i2c_error;
 	struct regulator_bulk_data supplies[4];
+	struct extcon_dev *extcon;
+	struct notifier_block extcon_nb;
+	struct work_struct extcon_wq;
+	int cable_state;
+	int i2c_error;
 
 	struct mutex lock; /* Protects fields below and device registers */
 	enum sii9234_state state;
@@ -863,6 +869,70 @@ static int sii9234_init_resources(struct sii9234 *ctx,
 	return 0;
 }
 
+static void sii9234_extcon_work(struct work_struct *work)
+{
+	struct sii9234 *ctx =
+		container_of(work, struct sii9234, extcon_wq);
+	int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+	if (state == ctx->cable_state)
+		return;
+
+	ctx->cable_state = state;
+
+	if (state > 0)
+		sii9234_cable_in(ctx);
+	else
+		sii9234_cable_out(ctx);
+}
+
+static int sii9234_extcon_notifier(struct notifier_block *self,
+			unsigned long event, void *ptr)
+{
+	struct sii9234 *ctx =
+		container_of(self, struct sii9234, extcon_nb);
+
+	schedule_work(&ctx->extcon_wq);
+
+	return NOTIFY_DONE;
+}
+
+static int sii9234_extcon_init(struct sii9234 *ctx)
+{
+	struct extcon_dev *edev;
+	struct device_node *musb, *muic;
+	int ret;
+
+	/* Get micro-USB connector node */
+	musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+	/* Then get micro-USB Interface Controller node */
+	muic = of_get_next_parent(musb);
+
+	if (!muic) {
+		dev_info(ctx->dev,
+			 "no extcon found, switching to 'always on' mode\n");
+		return 0;
+	}
+
+	edev = extcon_find_edev_by_node(muic);
+	of_node_put(muic);
+	if (IS_ERR(edev)) {
+		return dev_err_probe(ctx->dev, PTR_ERR(edev),
+			      "invalid or missing extcon\n");
+	}
+
+	ctx->extcon = edev;
+	ctx->extcon_nb.notifier_call = sii9234_extcon_notifier;
+	INIT_WORK(&ctx->extcon_wq, sii9234_extcon_work);
+	ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
+	if (ret) {
+		dev_err(ctx->dev, "failed to register notifier for MHL\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static enum drm_mode_status sii9234_mode_valid(struct drm_bridge *bridge,
 					 const struct drm_display_info *info,
 					 const struct drm_display_mode *mode)
@@ -915,12 +985,17 @@ static int sii9234_probe(struct i2c_client *client)
 	if (ret < 0)
 		return ret;
 
+	ret = sii9234_extcon_init(ctx);
+	if (ret < 0)
+		return ret;
+
 	i2c_set_clientdata(client, ctx);
 
 	ctx->bridge.of_node = dev->of_node;
 	drm_bridge_add(&ctx->bridge);
 
-	sii9234_cable_in(ctx);
+	if (!ctx->extcon)
+		sii9234_cable_in(ctx);
 
 	return 0;
 }
@@ -929,7 +1004,15 @@ static void sii9234_remove(struct i2c_client *client)
 {
 	struct sii9234 *ctx = i2c_get_clientdata(client);
 
-	sii9234_cable_out(ctx);
+	if (ctx->extcon) {
+		extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+					   &ctx->extcon_nb);
+		flush_work(&ctx->extcon_wq);
+		if (ctx->cable_state > 0)
+			sii9234_cable_out(ctx);
+	} else {
+		sii9234_cable_out(ctx);
+	}
 	drm_bridge_remove(&ctx->bridge);
 }
 

-- 
2.54.0

Claude review: drm/bridge: sii9234: use extcon to detect cable attachment

[Claude Code Review Bot]

Overall Series Review

Subject: drm/bridge: sii9234: use extcon to detect cable attachment
Author: Henrik Grimler <henrik@grimler.se>
Patches: 4
Reviewed: 2026-06-04T12:19:46.158919

---

This is a clean, well-structured 3-patch series that adds extcon-based MHL cable detection to the sii9234 bridge driver. The motivation is sound -- without extcon, the MHL chip must stay permanently on and HDMI hotplug doesn't work. The implementation closely mirrors the existing sii8620 driver (commit 688838442147), which is the right approach.

Patches 1 and 2 are straightforward cleanups (typos and dev_err_probe conversion). Patch 3 is the functional change. The series has Reviewed-by from Dmitry Baryshkov and Tested-by from Marek Szyprowski. This is on its 4th revision and appears ready.

One issue worth flagging in patch 3 (race window on remove), and a couple minor observations below.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/bridge: sii9234: fix some typos in comments and messages

[Claude Code Review Bot]

Patch Review

**Verdict: Good to go.**

Straightforward typo fixes:
- `chek` -> `check`, `imformation` -> `information`
- `festure` -> `feature`
- `Work_around` -> `Workaround`
- Missing spaces after commas/before parentheses in comments
- `not DT device` -> `no DT device`

All changes are correct. No functional impact.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/bridge: sii9234: use dev_err_probe where applicable

[Claude Code Review Bot]

Patch Review

**Verdict: Good to go.**

Converts three error paths to use `dev_err_probe()`:
1. GPIO reset acquisition -- was using `IS_ERR` + `dev_err` + return, now uses `dev_err_probe` which correctly handles deferred probe suppression.
2. Regulator bulk get -- was manually checking for `-EPROBE_DEFER` to suppress the message, `dev_err_probe` handles this automatically.
3. IRQ handler request -- was using `dev_err` unconditionally, `dev_err_probe` is better since `devm_request_threaded_irq` can return `-EPROBE_DEFER`.

All three conversions are correct. Net reduction of 5 lines. Reviewed-by from Dmitry is appropriate.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/bridge: sii9234: use extcon cable detection logic to detect MHL

[Claude Code Review Bot]

Patch Review

**Verdict: Acceptable with minor observations.**

**Kconfig dependency (line 539):**
```
depends on EXTCON || !EXTCON
```
This is the standard pattern to express "use extcon if available, compile without it if not" -- `extcon_find_edev_by_node()` and friends have stubs when `CONFIG_EXTCON` is disabled. Note the sii8620 driver uses `select EXTCON` instead, which is a stronger dependency. The `depends on EXTCON || !EXTCON` approach is better here since the driver works fine without extcon in "always on" mode. Good choice.

**`sii9234_extcon_init` (lines 900-934):**
The implementation mirrors sii8620's `sii8620_extcon_init` nearly 1:1, with the improvement of using `dev_err_probe` instead of the manual `-EPROBE_DEFER` check. One observation:

```c
musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
muic = of_get_next_parent(musb);
```

If `of_graph_get_remote_node` returns NULL (no port 1 in DT), `of_get_next_parent(NULL)` returns NULL, so `muic` will be NULL and the function falls through to the "always on" path. This is safe -- same pattern as sii8620.

**Race window in `sii9234_remove` (lines 1003-1017):**

```c
if (ctx->extcon) {
    extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
                               &ctx->extcon_nb);
    flush_work(&ctx->extcon_wq);
    if (ctx->cable_state > 0)
        sii9234_cable_out(ctx);
} else {
    sii9234_cable_out(ctx);
}
drm_bridge_remove(&ctx->bridge);
```

The ordering is correct: unregister the notifier first (so no new work items get scheduled), then flush any in-flight work, then tear down. This matches the sii8620 pattern. The `drm_bridge_remove` after `cable_out` is also correct.

**Minor observation:** There is a small theoretical race between `flush_work` completing and a final extcon notification sneaking in. Between `extcon_unregister_notifier` returning and the notifier chain lock being fully released, a concurrent `schedule_work` could theoretically be in-flight. However, this is the same pattern as the existing sii8620 driver and hasn't been a problem in practice. Using `cancel_work_sync` instead of `flush_work` would be slightly more robust, as it would also cancel a freshly-queued-but-not-yet-running work item. But since `extcon_unregister_notifier` synchronizes with the notifier chain, this is not a real bug.

**`sii9234_extcon_work` (lines 872-887):**

```c
int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);

if (state == ctx->cable_state)
    return;

ctx->cable_state = state;
```

The `cable_state` field is accessed without locking here, but since this runs from a non-reentrant work queue (system_wq with `schedule_work`, which is serialized for the same work item), and the only other reader is `sii9234_remove` after `flush_work`, this is fine. The `cable_in`/`cable_out` functions internally take `ctx->lock`.

**Probe path (lines 988-998):**

```c
ret = sii9234_extcon_init(ctx);
if (ret < 0)
    return ret;
...
if (!ctx->extcon)
    sii9234_cable_in(ctx);
```

Clean fallback: if no extcon is found, immediately call `cable_in` (original behavior). If extcon is present, cable state will be driven by notifications. One note: there's no initial `extcon_get_state` call after registering the notifier, so if the cable is already plugged in at probe time, the driver relies on a notification arriving. The sii8620 driver also doesn't do an initial poll, so this matches existing behavior. The cable will be detected on next state change. This could be improved in a follow-up but is not a blocker.

**Overall:** This is a well-written series that follows established patterns from the sii8620 driver. The code is correct, has appropriate reviews and testing, and the Kconfig dependency is handled properly. Ready to merge.

---
Generated by Claude Code Patch Reviewer