[PATCH 0/5] drm/bridge: replace deprecated DRM logging macros

[PATCH 0/5] drm/bridge: replace deprecated DRM logging macros

[Piyush Patle]

Replace a small set of deprecated DRM_INFO() and DRM_ERROR() calls in
bridge drivers with device-aware drm_info() and drm_err() helpers.

The replacements pass connector->dev or bridge->dev as appropriate,
preserving log levels while associating messages with the DRM device.

No functional changes.

Piyush Patle (5):
  drm/bridge: simple-bridge: replace deprecated DRM logging macros
  drm/bridge: ti-tfp410: replace deprecated DRM_INFO macro
  drm/bridge: chrontel-ch7033: replace deprecated DRM_ERROR macro
  drm/bridge: panel: replace deprecated DRM_ERROR macro
  drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: replace deprecated
    DRM_ERROR macro

 drivers/gpu/drm/bridge/chrontel-ch7033.c                 | 2 +-
 drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 2 +-
 drivers/gpu/drm/bridge/panel.c                           | 2 +-
 drivers/gpu/drm/bridge/simple-bridge.c                   | 6 +++---
 drivers/gpu/drm/bridge/ti-tfp410.c                       | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.43.0

[PATCH 1/5] drm/bridge: simple-bridge: replace deprecated DRM logging macros

[Piyush Patle]

Replace deprecated DRM_ERROR() and DRM_INFO() with device-aware
drm_err() and drm_info(), passing bridge->dev or connector->dev.

This is preferred over the plain pr_err()/pr_info() suggested by
the deprecation note as it associates log output with the DRM device.

No functional changes.

Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
 drivers/gpu/drm/bridge/simple-bridge.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..d8457e68c342 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -56,7 +56,7 @@ static int simple_bridge_get_modes(struct drm_connector *connector)
 	if (sbridge->bridge.next_bridge->ops & DRM_BRIDGE_OP_EDID) {
 		drm_edid = drm_bridge_edid_read(sbridge->bridge.next_bridge, connector);
 		if (!drm_edid)
-			DRM_INFO("EDID read failed. Fallback to standard modes\n");
+			drm_info(connector->dev, "EDID read failed. Fallback to standard modes\n");
 	} else {
 		drm_edid = NULL;
 	}
@@ -123,7 +123,7 @@ static int simple_bridge_attach(struct drm_bridge *bridge,
 					  sbridge->info->connector_type,
 					  sbridge->bridge.next_bridge->ddc);
 	if (ret) {
-		DRM_ERROR("Failed to initialize connector\n");
+		drm_err(bridge->dev, "Failed to initialize connector\n");
 		return ret;
 	}
 
@@ -140,7 +140,7 @@ static void simple_bridge_enable(struct drm_bridge *bridge)
 	if (sbridge->vdd) {
 		ret = regulator_enable(sbridge->vdd);
 		if (ret)
-			DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
+			drm_err(bridge->dev, "Failed to enable vdd regulator: %d\n", ret);
 	}
 
 	gpiod_set_value_cansleep(sbridge->enable, 1);
-- 
2.43.0

Re: [PATCH 1/5] drm/bridge: simple-bridge: replace deprecated DRM logging macros

[sashiko-bot]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but proceeding with hardware enablement after a power regulator failure can cause hardware damage. In `simple_bridge_enable()`, if `regulator_enable(sbridge->vdd)` fails, an error is logged but the function continues and unconditionally asserts the `enable` GPIO. Driving logic signals into an unpowered integrated circuit can back-power the chip through its IO pins, potentially leading to latch-up or permanent hardware damage. The function should abort early if the regulator fails to enable.
--

commit db4bbe0cc09da9b2a76aa9fd998d0133aa578bd2
Author: Piyush Patle <piyushpatle228@gmail.com>

drm/bridge: simple-bridge: replace deprecated DRM logging macros

Replace deprecated DRM_ERROR() and DRM_INFO() with device-aware
drm_err() and drm_info(), passing bridge->dev or connector->dev.

> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
> index 8aa31ca3c72d4..d8457e68c342f 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c

[ ... ]

> @@ -140,7 +140,7 @@ static void simple_bridge_enable(struct drm_bridge *bridge)
>  	if (sbridge->vdd) {
>  		ret = regulator_enable(sbridge->vdd);
>  		if (ret)
> -			DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> +			drm_err(bridge->dev, "Failed to enable vdd regulator: %d\n", ret);
>  	}
>  
>  	gpiod_set_value_cansleep(sbridge->enable, 1);

[Severity: High]
This isn't a bug introduced by this patch, but does proceeding with hardware
enablement after a power regulator failure risk hardware damage?

If regulator_enable() fails for sbridge->vdd, an error is logged, but the
function continues and unconditionally asserts the enable GPIO in
simple_bridge_enable().

Driving logic signals into an unpowered integrated circuit can back-power
the chip through its IO pins, potentially leading to latch-up or permanent
hardware damage.

Should the function abort early if the regulator fails to enable?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260606193625.24465-1-piyushpatle228@gmail.com?part=1

[PATCH 2/5] drm/bridge: ti-tfp410: replace deprecated DRM_INFO macro

[Piyush Patle]

Replace DRM_INFO() with device-aware drm_info() using connector->dev.

No functional changes.

Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
 drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
index 3b6b0e92cf89..1ebb2da1b789 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -55,7 +55,7 @@ static int tfp410_get_modes(struct drm_connector *connector)
 	if (dvi->bridge.next_bridge->ops & DRM_BRIDGE_OP_EDID) {
 		drm_edid = drm_bridge_edid_read(dvi->bridge.next_bridge, connector);
 		if (!drm_edid)
-			DRM_INFO("EDID read failed. Fallback to standard modes\n");
+			drm_info(connector->dev, "EDID read failed. Fallback to standard modes\n");
 	} else {
 		drm_edid = NULL;
 	}
-- 
2.43.0

[PATCH 3/5] drm/bridge: chrontel-ch7033: replace deprecated DRM_ERROR macro

[Piyush Patle]

Replace DRM_ERROR() with device-aware drm_err() using bridge->dev.

No functional changes.

Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
 drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c b/drivers/gpu/drm/bridge/chrontel-ch7033.c
index 54d49d4882c8..0e845f789f2e 100644
--- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
+++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
@@ -302,7 +302,7 @@ static int ch7033_bridge_attach(struct drm_bridge *bridge,
 					  priv->next_bridge->type,
 					  priv->next_bridge->ddc);
 	if (ret) {
-		DRM_ERROR("Failed to initialize connector\n");
+		drm_err(bridge->dev, "Failed to initialize connector\n");
 		return ret;
 	}
 
-- 
2.43.0

Re: [PATCH 3/5] drm/bridge: chrontel-ch7033: replace deprecated DRM_ERROR macro

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing cleanup on error paths in `ch7033_bridge_attach()` causes a resource leak and use-after-free.
- [High] `ch7033_bridge_detach()` incorrectly cleans up uninitialized resources if the bridge was attached with `DRM_BRIDGE_ATTACH_NO_CONNECTOR`.
- [High] HPD is enabled before connector initialization is complete, causing a NULL pointer dereference race condition.
--

commit 0d74a63f280c9b3d909b1d5c59227a795c81f570
Author: Piyush Patle <piyushpatle228@gmail.com>
drm/bridge: chrontel-ch7033: replace deprecated DRM_ERROR macro

Replace DRM_ERROR() with device-aware drm_err() using bridge->dev.

No functional changes.

> diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> index 54d49d4882c85..0e845f789f2e9 100644
> --- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> @@ -302,7 +302,7 @@ static int ch7033_bridge_attach(struct drm_bridge *bridge,
>  					  priv->next_bridge->type,
>  					  priv->next_bridge->ddc);
>  	if (ret) {
> -		DRM_ERROR("Failed to initialize connector\n");
> +		drm_err(bridge->dev, "Failed to initialize connector\n");
>  		return ret;
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but does this early return
leak resources?

If drm_connector_init_with_ddc() fails here in ch7033_bridge_attach(),
we return without calling drm_bridge_hpd_disable(). Does this leave a
dangling pointer in next_bridge for the HPD callback (ch7033_hpd_event)
and its data (priv)?

If an HPD event fires later after the device probing failed, could it
lead to a use-after-free?

Also, if the subsequent drm_connector_attach_encoder() call fails:

drivers/gpu/drm/bridge/chrontel-ch7033.c:ch7033_bridge_attach() {
    ...
    if (ret) {
        drm_err(bridge->dev, "Failed to initialize connector\n");
        return ret;
    }

    return drm_connector_attach_encoder(&priv->connector, encoder);
}

Does returning that error directly fail to roll back
drm_connector_init_with_ddc() and leave the HPD enabled, leaking the
connector structure and the registered callback?

[Severity: High]
This is also a pre-existing issue, but is there a race condition with when
HPD is enabled in this same function?

Looking at ch7033_bridge_attach() in drivers/gpu/drm/bridge/chrontel-ch7033.c:

drivers/gpu/drm/bridge/chrontel-ch7033.c:ch7033_bridge_attach() {
    ...
    if (priv->next_bridge->ops & DRM_BRIDGE_OP_HPD) {
        drm_bridge_hpd_enable(priv->next_bridge, ch7033_hpd_event, priv);
    }

    drm_connector_helper_add(connector, &ch7033_connector_helper_funcs);
    ret = drm_connector_init_with_ddc(...);
    ...
}

Since drm_bridge_hpd_enable() is called before drm_connector_init_with_ddc(),
if an HPD event fires immediately, ch7033_hpd_event() is invoked.
That callback checks if priv->bridge.dev is set (which is true here)
and then passes priv->connector.dev to drm_helper_hpd_irq_event().

Since priv->connector.dev is only populated later during
drm_connector_init_with_ddc(), will it still be NULL here, causing
drm_helper_hpd_irq_event() to dereference a NULL pointer?

[Severity: High]
Finally, this is another pre-existing issue, but does ch7033_bridge_detach()
clean up uninitialized resources?

If ch7033_bridge_attach() is called with DRM_BRIDGE_ATTACH_NO_CONNECTOR,
it returns early and skips drm_connector_init_with_ddc().
However, ch7033_bridge_detach() unconditionally calls:

drivers/gpu/drm/bridge/chrontel-ch7033.c:ch7033_bridge_detach() {
    ...
    drm_connector_cleanup(&priv->connector);
}

Since priv is allocated with devm_drm_bridge_alloc() (which zeroes memory),
priv->connector contains zero-initialized list heads.
Because drm_connector_cleanup() iterates over &connector->probed_modes
using list_for_each_entry_safe(), could this dereference NULL list
pointers and cause a kernel crash when the uninitialized connector is
cleaned up?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260606193625.24465-1-piyushpatle228@gmail.com?part=3

[PATCH 4/5] drm/bridge: panel: replace deprecated DRM_ERROR macro

[Piyush Patle]

Replace DRM_ERROR() with device-aware drm_err() using bridge->dev.

No functional changes.

Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
 drivers/gpu/drm/bridge/panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 184a8b7049a7..3f96af335e06 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -76,7 +76,7 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
 				 &panel_bridge_connector_funcs,
 				 panel_bridge->connector_type);
 	if (ret) {
-		DRM_ERROR("Failed to initialize connector\n");
+		drm_err(bridge->dev, "Failed to initialize connector\n");
 		return ret;
 	}
 
-- 
2.43.0

[PATCH 5/5] drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: replace deprecated DRM_ERROR macro

[Piyush Patle]

Replace DRM_ERROR() with device-aware drm_err() using bridge->dev.

No functional changes.

Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
 drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c b/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c
index 2d02cc69f237..a34212f10b6d 100644
--- a/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c
@@ -168,7 +168,7 @@ static int ge_b850v3_lvds_create_connector(struct drm_bridge *bridge)
 				 &ge_b850v3_lvds_connector_funcs,
 				 DRM_MODE_CONNECTOR_DisplayPort);
 	if (ret) {
-		DRM_ERROR("Failed to initialize connector with drm\n");
+		drm_err(bridge->dev, "Failed to initialize connector with drm\n");
 		return ret;
 	}
 
-- 
2.43.0