[PATCH v3 0/3] drm/bridge: ti-sn65dsi83: Various fixes

[PATCH v3 0/3] drm/bridge: ti-sn65dsi83: Various fixes

[Esben Haabendal]

This small series adds support for using SN65DSI84 in single-link mode with
output to LVDS channel B, and provides a fix for a PLL locking issue.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
Changes in v3:
- Rename panel_port variable to output_port.
- Propagate error code from drm_bridge_helper_reset_crtc() in
  sn65dsi83_reset_pipe().
- Drop with fix for premature PLL locking. Should be fixed in DSI host
  driver (or upstream bridge driver) instead.
  See https://lore.kernel.org/all/48f6f55f-43fd-4355-88b9-d2e2d0e26d07@kontron.de/
- Link to v2: https://patch.msgid.link/20260715-ti-sn65dsi83-fixes-v2-0-ebc4c3fe29b6@geanix.com

Changes in v2:
- Fix error handling in sn65dsi83_atomic_enable() to ensure
  drm_brige_exit() is always called on exit.
- Change logging level from warn to dbg for two messages in
  sn65dsi83_parse_dt().
- Removed trailing dot in comment lines.
- Added patch with fix so that DRM bridge critical section is exited on
  error in sn65dsi83_reset_work().
- Added Fixes and Cc: stable tags to the premature PLL patch.
- Re-ordered patch so fixes comes first.
- Link to v1: https://patch.msgid.link/20260711-ti-sn65dsi83-fixes-v1-0-d85eb5342b98@geanix.com

To: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Herve Codina <herve.codina@bootlin.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Robert Foss <rfoss@kernel.org>
To: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
To: Jonas Karlman <jonas@kwiboo.se>
To: Jernej Skrabec <jernej.skrabec@gmail.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
To: David Airlie <airlied@gmail.com>
To: Simona Vetter <simona@ffwll.ch>
To: Linus Walleij <linusw@kernel.org>
To: Frieder Schrempf <frieder.schrempf@kontron.de>
To: Marek Vasut <marex@denx.de>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org

---
Esben Haabendal (3):
      drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()
      drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()
      drm/bridge: ti-sn65dsi83: Support LVDS Channel B on SN65DSI84

 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 39 +++++++++++++++++++++++------------
 1 file changed, 26 insertions(+), 13 deletions(-)
---
base-commit: 075b74841bd0065a3bda3440873c747938e69b68
change-id: 20260710-ti-sn65dsi83-fixes-1d08e0ac67b3

Best regards,
--  
Esben Haabendal <esben@geanix.com>

[PATCH v3 1/3] drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()

[Esben Haabendal]

Propagate the error code from drm_bridge_helper_reset_crtc(), so that
callers has a chance to handle the failure.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 42b451432bbb..476f255bd34d 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -403,7 +403,7 @@ static int sn65dsi83_reset_pipe(struct sn65dsi83 *sn65dsi83)
 	drm_modeset_drop_locks(&ctx);
 	drm_modeset_acquire_fini(&ctx);
 
-	return 0;
+	return err;
 }
 
 static void sn65dsi83_reset_work(struct work_struct *ws)

-- 
2.55.0

Re: [PATCH v3 1/3] drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Leaking an SRCU read lock on the error path in `sn65dsi83_reset_work()` due to an early return without calling `drm_bridge_exit()`.
--

--- Patch [1]: [PATCH v3 1/3] drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe() ---
commit d19637cc30dea31a13c6747fe2aa3733116ec5e5
Author: Esben Haabendal <esben@geanix.com>

drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()
    
Propagate the error code from drm_bridge_helper_reset_crtc(), so that
callers has a chance to handle the failure.

> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index 42b451432bbb6..476f255bd34dd 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -403,7 +403,7 @@ static int sn65dsi83_reset_pipe(struct sn65dsi83 *sn65dsi83)
>  	drm_modeset_drop_locks(&ctx);
>  	drm_modeset_acquire_fini(&ctx);
>  
> -	return 0;
> +	return err;
>  }
>  
>  static void sn65dsi83_reset_work(struct work_struct *ws)

[Severity: High]
Does propagating the error here cause an SRCU read lock leak?

By propagating the error from sn65dsi83_reset_pipe(), it is now possible
to hit the early return path in sn65dsi83_reset_work():

	if (!drm_bridge_enter(&ctx->bridge, &idx))
		return;

	/* Reset the pipe */
	ret = sn65dsi83_reset_pipe(ctx);
	if (ret) {
		dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret));
		return;
	}

Because this early return skips the call to drm_bridge_exit(idx) at the
end of the function, wouldn't this leak the lock and cause a system hang
during drm_bridge_unplug() when synchronize_srcu() is called?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-ti-sn65dsi83-fixes-v3-0-9b403a405ccd@geanix.com?part=1

Re: [PATCH v3 1/3] drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()

[Esben Haabendal]

<sashiko-bot@kernel.org> writes:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Leaking an SRCU read lock on the error path in `sn65dsi83_reset_work()` due to an early return without calling `drm_bridge_exit()`.
> --
>
> --- Patch [1]: [PATCH v3 1/3] drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe() ---
> commit d19637cc30dea31a13c6747fe2aa3733116ec5e5
> Author: Esben Haabendal <esben@geanix.com>
>
> drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()
>
> Propagate the error code from drm_bridge_helper_reset_crtc(), so that
> callers has a chance to handle the failure.
>
>> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> index 42b451432bbb6..476f255bd34dd 100644
>> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> @@ -403,7 +403,7 @@ static int sn65dsi83_reset_pipe(struct sn65dsi83 *sn65dsi83)
>>  	drm_modeset_drop_locks(&ctx);
>>  	drm_modeset_acquire_fini(&ctx);
>>
>> -	return 0;
>> +	return err;
>>  }
>>
>>  static void sn65dsi83_reset_work(struct work_struct *ws)
>
> [Severity: High]
> Does propagating the error here cause an SRCU read lock leak?
>
> By propagating the error from sn65dsi83_reset_pipe(), it is now possible
> to hit the early return path in sn65dsi83_reset_work():
>
> 	if (!drm_bridge_enter(&ctx->bridge, &idx))
> 		return;
>
> 	/* Reset the pipe */
> 	ret = sn65dsi83_reset_pipe(ctx);
> 	if (ret) {
> 		dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret));
> 		return;
> 	}
>
> Because this early return skips the call to drm_bridge_exit(idx) at the
> end of the function, wouldn't this leak the lock and cause a system hang
> during drm_bridge_unplug() when synchronize_srcu() is called?

Yes. This is resolved in patch 2. I will reorder the patches in next
version.

/Esben

Re: [PATCH v3 1/3] drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()

[Luca Ceresoli]

On Mon, 03 Aug 2026 16:57:03 +0200, Esben Haabendal <esben@geanix.com> wrote:

Hi Esben,

> Propagate the error code from drm_bridge_helper_reset_crtc(), so that
> callers has a chance to handle the failure.
> 
> Signed-off-by: Esben Haabendal <esben@geanix.com>

Thanks for the improved patches!

Patches 1-2 look like big fixes, so they need a Fixes tag along with 'Cc:
stable'.

Other than that they look OK to me.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v3 1/3] drm/bridge: ti-sn65dsi83: Propagate error in sn65dsi83_reset_pipe()

[Esben Haabendal]

On Wednesday, August 5th, 2026 at 09:47, Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:

> On Mon, 03 Aug 2026 16:57:03 +0200, Esben Haabendal <esben@geanix.com> wrote:
> 
> Hi Esben,
> 
> > Propagate the error code from drm_bridge_helper_reset_crtc(), so that
> > callers has a chance to handle the failure.
> >
> > Signed-off-by: Esben Haabendal <esben@geanix.com>
> 
> Thanks for the improved patches!
> 
> Patches 1-2 look like big fixes, so they need a Fixes tag along with 'Cc:
> stable'.

Added for v4.

> Other than that they look OK to me.

/Esben

[PATCH v3 2/3] drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()

[Esben Haabendal]

We obviously should not leave the DRM bridge critical section activated
when exiting on error.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 476f255bd34d..5551845ea0dd 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -419,11 +419,12 @@ static void sn65dsi83_reset_work(struct work_struct *ws)
 	ret = sn65dsi83_reset_pipe(ctx);
 	if (ret) {
 		dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret));
-		return;
+		goto err_exit;
 	}
 	if (ctx->irq)
 		enable_irq(ctx->irq);
 
+err_exit:
 	drm_bridge_exit(idx);
 }
 

-- 
2.55.0

Re: [PATCH v3 2/3] drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing cancel_work_sync() for ctx->reset_work during driver teardown leads to a Use-After-Free.
- [High] Skipping enable_irq() on the error path causes an IRQ disable depth leak, leaving the interrupt permanently disabled.
--

--- Patch [2]: [PATCH v3 2/3] drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work() ---
commit 58246b5ef131d7aeea7b5c2b693088e7255aa435
Author: Esben Haabendal <esben@geanix.com>

drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()

This commit fixes the error path in sn65dsi83_reset_work() by adding a
goto to ensure drm_bridge_exit() is called when sn65dsi83_reset_pipe()
fails, safely closing the critical section.

> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -419,11 +419,12 @@ static void sn65dsi83_reset_work(struct work_struct *ws)

[Severity: Critical]
This is a pre-existing issue, but could this work function execute after
the device is unbound, resulting in a use-after-free?

If the driver is removed and devres frees the ctx structure, the work
could still be pending since sn65dsi83_remove() does not appear to call
cancel_work_sync() before returning:

sn65dsi83_remove() {
        ...
        drm_bridge_unplug(&ctx->bridge);
        // missing cancel_work_sync(&ctx->reset_work);
}

If the workqueue executes sn65dsi83_reset_work() after teardown,
dereferencing ctx for drm_bridge_enter() might access freed memory.

>  	ret = sn65dsi83_reset_pipe(ctx);
>  	if (ret) {
>  		dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret));
> -		return;
> +		goto err_exit;

[Severity: High]
This isn't a bug introduced by this patch, but doesn't jumping to err_exit
here leave the interrupt permanently disabled?

If a hardware error triggers the IRQ handler, sn65dsi83_handle_errors()
calls disable_irq_nosync(), which increments the IRQ disable depth. By
skipping the enable_irq() call on this error path, the depth counter
remains unbalanced.

Would it be better to mask the interrupt source via hardware registers
on failure, and still call enable_irq() so the kernel's depth counter
remains balanced?

>  	}
>  	if (ctx->irq)
>  		enable_irq(ctx->irq);
>  
> +err_exit:
>  	drm_bridge_exit(idx);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-ti-sn65dsi83-fixes-v3-0-9b403a405ccd@geanix.com?part=2

Re: [PATCH v3 2/3] drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()

[Esben Haabendal]

<sashiko-bot@kernel.org> writes:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] Missing cancel_work_sync() for ctx->reset_work during driver teardown leads to a Use-After-Free.
> - [High] Skipping enable_irq() on the error path causes an IRQ disable depth leak, leaving the interrupt permanently disabled.
> --
>
> --- Patch [2]: [PATCH v3 2/3] drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work() ---
> commit 58246b5ef131d7aeea7b5c2b693088e7255aa435
> Author: Esben Haabendal <esben@geanix.com>
>
> drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()
>
> This commit fixes the error path in sn65dsi83_reset_work() by adding a
> goto to ensure drm_bridge_exit() is called when sn65dsi83_reset_pipe()
> fails, safely closing the critical section.
>
>> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> @@ -419,11 +419,12 @@ static void sn65dsi83_reset_work(struct work_struct *ws)
>
> [Severity: Critical]
> This is a pre-existing issue, but could this work function execute after
> the device is unbound, resulting in a use-after-free?
>
> If the driver is removed and devres frees the ctx structure, the work
> could still be pending since sn65dsi83_remove() does not appear to call
> cancel_work_sync() before returning:
>
> sn65dsi83_remove() {
>         ...
>         drm_bridge_unplug(&ctx->bridge);
>         // missing cancel_work_sync(&ctx->reset_work);
> }
>
> If the workqueue executes sn65dsi83_reset_work() after teardown,
> dereferencing ctx for drm_bridge_enter() might access freed memory.
>
>>  	ret = sn65dsi83_reset_pipe(ctx);
>>  	if (ret) {
>>  		dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret));
>> -		return;
>> +		goto err_exit;
>
> [Severity: High]
> This isn't a bug introduced by this patch, but doesn't jumping to err_exit
> here leave the interrupt permanently disabled?
>
> If a hardware error triggers the IRQ handler, sn65dsi83_handle_errors()
> calls disable_irq_nosync(), which increments the IRQ disable depth. By
> skipping the enable_irq() call on this error path, the depth counter
> remains unbalanced.
>
> Would it be better to mask the interrupt source via hardware registers
> on failure, and still call enable_irq() so the kernel's depth counter
> remains balanced?

Nah. I would rather just balance the counter here.
Calling enable_irq() on error should be the safe choice.
As sn65dsi83_reset_pipe() have always been returning 0 until now, we
have in practise been doing that unconditionally anyway.

I will do that in next version.

>
>>  	}
>>  	if (ctx->irq)
>>  		enable_irq(ctx->irq);
>>
>> +err_exit:
>>  	drm_bridge_exit(idx);
>>  }
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260803-ti-sn65dsi83-fixes-v3-0-9b403a405ccd@geanix.com?part=2

[PATCH v3 3/3] drm/bridge: ti-sn65dsi83: Support LVDS Channel B on SN65DSI84

[Esben Haabendal]

This adds support for using SN65DSI84 in single-link mode with output to
LVDS Channel B.

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 34 +++++++++++++++++++++++-----------
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 5551845ea0dd..b830538b405b 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -11,6 +11,8 @@
  *   = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS
  *   - Supported
  *   - Dual-link LVDS mode tested
+ *   - Single-link to LVDS Channel A tested
+ *   - Single-link to LVDS Channel B tested
  *   - 2x Single-link LVDS mode unsupported
  *     (should be easy to add by someone who has the HW)
  * - SN65DSI85
@@ -162,7 +164,7 @@ struct sn65dsi83 {
 	struct gpio_desc		*enable_gpio;
 	struct regulator		*vcc;
 	bool				lvds_dual_link;
-	bool				lvds_dual_link_even_odd_swap;
+	bool				lvds_channel_swap;
 	int				lvds_vod_swing_conf[2];
 	int				lvds_term_conf[2];
 	int				irq;
@@ -643,7 +645,7 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
 			REG_LVDS_VCOM_CHA_LVDS_VOD_SWING(ctx->lvds_vod_swing_conf[CHANNEL_A]) |
 			REG_LVDS_VCOM_CHB_LVDS_VOD_SWING(ctx->lvds_vod_swing_conf[CHANNEL_B]));
 	regmap_write(ctx->regmap, REG_LVDS_LANE,
-		     (ctx->lvds_dual_link_even_odd_swap ?
+		     (ctx->lvds_channel_swap ?
 		      REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
 		     (ctx->lvds_term_conf[CHANNEL_A] ?
 			  REG_LVDS_LANE_CHA_LVDS_TERM : 0) |
@@ -894,6 +896,7 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
 {
 	struct drm_bridge *panel_bridge;
 	struct device *dev = ctx->dev;
+	u32 output_port = 2;
 	int ret;
 
 	ret = sn65dsi83_parse_lvds_endpoint(ctx, CHANNEL_A);
@@ -905,29 +908,38 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
 		return ret;
 
 	ctx->lvds_dual_link = false;
-	ctx->lvds_dual_link_even_odd_swap = false;
+	ctx->lvds_channel_swap = false;
 	if (model != MODEL_SN65DSI83) {
-		struct device_node *port2, *port3;
+		struct device_node *port0, *port1, *port2, *port3;
 		int dual_link;
 
+		port0 = of_graph_get_port_by_id(dev->of_node, 0);
+		port1 = of_graph_get_port_by_id(dev->of_node, 1);
 		port2 = of_graph_get_port_by_id(dev->of_node, 2);
 		port3 = of_graph_get_port_by_id(dev->of_node, 3);
 		dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
-		of_node_put(port2);
-		of_node_put(port3);
 
 		if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
-			ctx->lvds_dual_link = true;
 			/* Odd pixels to LVDS Channel A, even pixels to B */
-			ctx->lvds_dual_link_even_odd_swap = false;
-		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
 			ctx->lvds_dual_link = true;
+		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
 			/* Even pixels to LVDS Channel A, odd pixels to B */
-			ctx->lvds_dual_link_even_odd_swap = true;
+			ctx->lvds_dual_link = true;
+			ctx->lvds_channel_swap = true;
+		} else if (port0 && !port1 && port2 && !port3) {
+			/* DSI Channel A to LVDS Channel A */
+		} else if (port0 && !port1 && !port2 && port3) {
+			/* DSI Channel A to LVDS Channel B */
+			ctx->lvds_channel_swap = true;
+			output_port = 3;
 		}
+		of_node_put(port0);
+		of_node_put(port1);
+		of_node_put(port2);
+		of_node_put(port3);
 	}
 
-	panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 2, 0);
+	panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node, output_port, 0);
 	if (IS_ERR(panel_bridge))
 		return dev_err_probe(dev, PTR_ERR(panel_bridge), "Failed to get panel bridge\n");
 

-- 
2.55.0

Re: [PATCH v3 0/3] drm/bridge: ti-sn65dsi83: Various fixes

[Luca Ceresoli]

On Mon Aug 3, 2026 at 4:57 PM CEST, Esben Haabendal wrote:
> This small series adds support for using SN65DSI84 in single-link mode with
> output to LVDS channel B, and provides a fix for a PLL locking issue.
>
> Signed-off-by: Esben Haabendal <esben@geanix.com>

With the planned changes (Fixes/Cc:stable tags, patches 1-2 swapped)
applied you can send v4 with:

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v3 0/3] drm/bridge: ti-sn65dsi83: Various fixes

[Esben Haabendal]

On Thursday, August 6th, 2026 at 11:02, Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:

> On Mon Aug 3, 2026 at 4:57 PM CEST, Esben Haabendal wrote:
> > This small series adds support for using SN65DSI84 in single-link mode with
> > output to LVDS channel B, and provides a fix for a PLL locking issue.
> >
> > Signed-off-by: Esben Haabendal <esben@geanix.com>
> 
> With the planned changes (Fixes/Cc:stable tags, patches 1-2 swapped)
> applied you can send v4 with:
> 
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

Thanks. I have made one additional change for v4 though.

As pointed out by sashiko-bot, I fixed a problem where we would end up with
an unbalanced irq enable counter if/when sn65dsi83_reset_pipe() failed.

And as I am introducing the possibility of sn65dsi_reset_pipe() actually
returning an error, this bug would be a regression introduced by this series
without this additional fix.

/Esben