Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Michal Wilczynski" <m.wilczynski@samsung.com>
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v7 08/19] drm/bridge: inno-hdmi: Split probe out of bind
Date: Fri, 06 Nov 2026 14:52:59 +0000	[thread overview]
Message-ID: <sashiko-outbox-201623@kernel.org> (raw)
In-Reply-To: <20261106-jh7110-clean-send-v7-8-68f7ea9913db@samsung.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/bridge: inno-hdmi: race on bridge.dev in inno_hdmi_irq()
  after probe split
--

commit b0209990726be89f8d7446a146a593a4fe328e8b
Author: Michal Wilczynski <m.wilczynski@samsung.com>

drm/bridge: inno-hdmi: Split probe out of bind

This commit splits hardware and bridge setup out of inno_hdmi_bind() into
an exported inno_hdmi_probe() helper so standalone platform drivers can
register the bridge without immediately attaching it to an encoder.

> diff --git a/drivers/gpu/drm/bridge/inno-hdmi.c b/drivers/gpu/drm/bridge/inno-hdmi.c
> index 5bfe59f18823a..aa64ffdbd3072 100644
> --- a/drivers/gpu/drm/bridge/inno-hdmi.c
> +++ b/drivers/gpu/drm/bridge/inno-hdmi.c
> @@ -1063,11 +1063,24 @@ static struct i2c_adapter *inno_hdmi_i2c_adapter(struct inno_hdmi *hdmi)
>  	return adap;
>  }
>  
> -struct inno_hdmi *inno_hdmi_bind(struct device *dev,
> -				 struct drm_encoder *encoder,
> -				 const struct inno_hdmi_plat_data *plat_data)
> +/**
> + * inno_hdmi_probe - Internal helper to perform common setup
> + * @pdev: platform device
> + * @plat_data: SoC-specific platform data
> + *
> + * This function handles all the common hardware setup: allocating the main
> + * struct, mapping registers, getting clocks, initializing the hardware,
> + * setting up the IRQ, and initializing the DDC adapter and bridge struct.
> + *
> + * It registers the bridge but does not attach it, for glue drivers that probe
> + * as their own platform device rather than through a component bind.
> + *
> + * Return: the inno_hdmi instance on success, or an ERR_PTR() on failure.
> + */
> +struct inno_hdmi *inno_hdmi_probe(struct platform_device *pdev,
> +				  const struct inno_hdmi_plat_data *plat_data)
>  {
> -	struct platform_device *pdev = to_platform_device(dev);
> +	struct device *dev = &pdev->dev;
>  	struct inno_hdmi *hdmi;
>  	int irq;
>  	int ret;
> @@ -1131,7 +1144,23 @@ struct inno_hdmi *inno_hdmi_bind(struct device *dev,
>  	if (ret)
>  		return ERR_PTR(ret);
>  
> -	ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +	return hdmi;
> +}
> +EXPORT_SYMBOL_GPL(inno_hdmi_probe);

[Severity: Medium]
Can inno_hdmi_irq() race with drm_bridge_detach() on hdmi->bridge.dev when
a standalone bridge driver uses inno_hdmi_probe()?

Previously, inno_hdmi_bind() was called from component bind, so
component_unbind_all() released the devm_request_threaded_irq() handler
before drm_dev_put() detached the bridge and freed the drm_device.  When a
standalone platform driver calls inno_hdmi_probe(), the threaded IRQ stays
active for the lifetime of the bridge platform_device while the display
driver attaches and detaches the bridge.

drivers/gpu/drm/bridge/inno-hdmi.c:inno_hdmi_irq() {
	/* bridge.dev is NULL until drm_bridge_attach() */
	if (hdmi->bridge.dev)
		drm_helper_hpd_irq_event(hdmi->bridge.dev);
}

If an HPD interrupt fires while the display driver is tearing down its
drm_device, inno_hdmi_irq() reads hdmi->bridge.dev without synchronization
against drm_bridge_detach() and drm_dev_put():

CPU0                                  CPU1 (irq/inno_hdmi_irq)
drm_dev_put(drm)
  ...
    drm_encoder_cleanup(encoder)
      drm_bridge_detach(&hdmi->bridge)
                                      if (hdmi->bridge.dev)
        bridge->dev = NULL;
  kfree(drm)
                                        drm_helper_hpd_irq_event(...)
                                          <-- use-after-free or NULL deref

Depending on timing, this causes either a use-after-free of the drm_device
or a NULL pointer dereference in drm_helper_hpd_irq_event() if the compiler
reloads hdmi->bridge.dev.  Calling drm_bridge_hpd_notify(&hdmi->bridge,
status) instead of drm_helper_hpd_irq_event() would serialize against HPD
disable through bridge->hpd_mutex.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-jh7110-clean-send-v7-0-68f7ea9913db@samsung.com?part=8

  reply	other threads:[~2026-11-06 14:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20261106135849eucas1p242718d72fa1f38e31477210fd9ee30bc@eucas1p2.samsung.com>
2026-11-06 13:58 ` [PATCH v7 00/19] drm: starfive: jh7110: Enable display subsystem Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 01/19] drm/bridge: inno-hdmi: fix swapped HSYNC and VSYNC polarity Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 02/19] drm/bridge: inno-hdmi: Don't dereference a NULL drm_device on hotplug Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 03/19] dt-bindings: display: bridge: Add starfive,jh7110-inno-hdmi-controller Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 04/19] dt-bindings: display: starfive: Add starfive,jh7110-hdmi-subsystem Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 05/19] dt-bindings: soc: starfive: Add starfive,jh7110-vout-syscon Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 06/19] dt-bindings: display: verisilicon: Add starfive,jh7110-dc8200 Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 07/19] dt-bindings: display: starfive: Add starfive,jh7110-vout-subsystem Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 08/19] drm/bridge: inno-hdmi: Split probe out of bind Michal Wilczynski
2026-11-06 14:52     ` sashiko-bot [this message]
2026-11-06 13:58   ` [PATCH v7 09/19] drm/bridge: inno-hdmi: Use a regmap for register access Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 10/19] drm/bridge: inno-hdmi: Add .disable platform operation Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 11/19] drm/bridge: inno-hdmi: Add .mode_valid " Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 12/19] drm/bridge: inno-hdmi: Make the PHY configuration table optional Michal Wilczynski
2026-11-06 15:17     ` sashiko-bot
2026-11-06 13:58   ` [PATCH v7 13/19] drm/bridge: inno-hdmi: Make the register clock source selectable Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 14/19] drm/bridge: inno-hdmi: Make the supported HDMI version selectable Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 15/19] soc: starfive: Add jh7110-hdmi-subsystem driver Michal Wilczynski
2026-11-06 15:35     ` sashiko-bot
2026-11-06 13:58   ` [PATCH v7 16/19] soc: starfive: Add jh7110-vout-subsystem driver Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 17/19] drm/bridge: starfive: Add JH7110 HDMI controller driver Michal Wilczynski
2026-11-06 13:58   ` [PATCH v7 18/19] riscv: dts: starfive: jh7110: Update DT for display subsystem Michal Wilczynski
2026-11-06 16:12     ` sashiko-bot
2026-11-06 13:58   ` [PATCH v7 19/19] MAINTAINERS: Add StarFive JH7110 display subsystem entry Michal Wilczynski
2026-11-06 19:48   ` [PATCH v7 00/19] drm: starfive: jh7110: Enable display subsystem Owen O'Hehir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-201623@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=m.wilczynski@samsung.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox