From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F1E83B14A8; Wed, 30 Sep 2026 10:03:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.11.138.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790762632; cv=none; b=cURasU0blQC2s25fcIeYsK22YUiP34CV8+e4+/S+B/atwA0vCsMcQPNuQWGfu1g+dMlPCC+uMt6CkBx8bANnBNJ2aTw5SQJb7o7aOBpvLWNl+ec29+A5ntOoGu6oVKLKDDKLWodWWIfcuvc+68eHbPRuonTjWo3JBljrxKSfwAU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790762632; c=relaxed/simple; bh=n3Em4qv4TtlAboJtrIODavOjtBwxuIwwlGPwhb5onsk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=W51H74oocypsXKSTl4WnRFWdwLeiPHvvGW1YzCBsH383Sn9+88eono6K+KeUdinxMcgrhjDDLstAGr85PMC1yc+S2d2BwpYsaMnhwf8BwKw/aiwa5eb5efSTVwWxnNM1DNfo0rrHVY3D4hT6yRxwJF4D9ZpAVicOpApS5webIIo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=sntech.de; spf=pass smtp.mailfrom=sntech.de; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b=dQDZx7GN; arc=none smtp.client-ip=185.11.138.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=sntech.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sntech.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b="dQDZx7GN" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Reply-To; bh=sh5fC0CUc10hXDTzkPBdCZZkzPfnJFt3NuMWURsgHZU=; b=dQDZx7GNYaKjOyAprY0oq3+rhC /eRsMVCp7CHstO2amzfLwnWMpuZhOwZLV5zCzcz4BYLIiyI9kZ1yw0r9OgHEv+aIvi44sdtTirKwa OQzxVHJQX/qDklqrlWPmwXgnqqXLejnfAonFjc6ADre+i/BSBCvUdjrrSrOrH6Dl1fxjxFXnwhCso IPBJy26ZLjCtumpQqqejgo1MnBy4oKjXWyaJFjYC+jjpGjIJA0/q0xkiOVJoP0A2jPCkz/ZCOtkxz ncKW0RperYZyh/uHq/5ZVrtrNlVK174R8UiChq058TY1LetGeH75URGVPxm0LcveI87AsX1YnSDo2 tHqzyTzg==; From: Heiko =?UTF-8?B?U3TDvGJuZXI=?= To: Vinod Koul , Manivannan Sadhasivam , Neil Armstrong , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andrzej Hajda , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Andy Yan , Philipp Zabel , Emil Renner Berthing , Hal Feng , Michael Turquette , Stephen Boyd , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Dominique Belhachemi , Brian Masney , Jerome Brunet , Michal Wilczynski Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-riscv@lists.infradead.org, Marek Szyprowski , Maud Spierings , Graham Markall , Icenowy Zheng , Chaoyi Chen , Joshua Peisach , Uwe =?UTF-8?B?S2xlaW5lLUvDtm5pZw==?= , Michal Wilczynski Subject: Re: [PATCH v5 08/21] drm/bridge: inno-hdmi: Split probe out of bind Date: Wed, 30 Sep 2026 12:02:56 +0200 Message-ID: <6535891.44csPzL39Z@diego> In-Reply-To: <20260929-jh7110-clean-send-v5-8-82b4d8e3c6c7@samsung.com> References: <20260929-jh7110-clean-send-v5-0-82b4d8e3c6c7@samsung.com> <20260929-jh7110-clean-send-v5-8-82b4d8e3c6c7@samsung.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am Dienstag, 29. September 2026, 12:31:05 Mitteleurop=C3=A4ische Sommerzeit= schrieb Michal Wilczynski: > inno_hdmi_bind() both sets up the bridge and attaches it to a DRM > encoder. A platform whose HDMI controller is a child of a larger device > needs the first half without the second, since it registers as its own > platform driver and lets the DRM core bind the bridge later. >=20 > Move the setup into a new exported inno_hdmi_probe(), and reduce > inno_hdmi_bind() to a wrapper around it. >=20 > No functional change intended. >=20 > Reviewed-by: Joshua Peisach > Signed-off-by: Michal Wilczynski > --- > drivers/gpu/drm/bridge/inno-hdmi.c | 49 ++++++++++++++++++++++++++++++++= +----- > include/drm/bridge/inno_hdmi.h | 4 ++++ > 2 files changed, 47 insertions(+), 6 deletions(-) >=20 > diff --git a/drivers/gpu/drm/bridge/inno-hdmi.c b/drivers/gpu/drm/bridge/= inno-hdmi.c > index d7c33b92e2ddf4ced84d17304463f44be52270b8..7a9f54dce2647f0320d77629a= 28154eade14385f 100644 > --- a/drivers/gpu/drm/bridge/inno-hdmi.c > +++ b/drivers/gpu/drm/bridge/inno-hdmi.c > @@ -929,7 +929,14 @@ static irqreturn_t inno_hdmi_irq(int irq, void *dev_= id) > { > struct inno_hdmi *hdmi =3D dev_id; > =20 > - drm_helper_hpd_irq_event(hdmi->bridge.dev); > + /* > + * The interrupt is requested in probe, but bridge.dev is only set once > + * the DRM master binds and attaches the bridge, which may never happen. > + * Drop hotplug events that arrive before then rather than dereference a > + * NULL drm_device. > + */ > + if (hdmi->bridge.dev) > + drm_helper_hpd_irq_event(hdmi->bridge.dev); This is not part of the commit description and while true, should likely be its own patch with its own description. > =20 > return IRQ_HANDLED; > } > @@ -1061,11 +1068,24 @@ static struct i2c_adapter *inno_hdmi_i2c_adapter(= struct inno_hdmi *hdmi) > return adap; > } > =20 > -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 m= ain > + * struct, mapping registers, getting clocks, initializing the hardware, > + * setting up the IRQ, and initializing the DDC adapter and bridge struc= t. > + * It returns a pointer to the inno_hdmi struct on success, or an ERR_PTR > + * on failure. > + * > + * This function is used by modern, decoupled MFD/glue drivers. It regis= ters > + * the bridge but does not attach it. > + */ > +struct inno_hdmi *inno_hdmi_probe(struct platform_device *pdev, > + const struct inno_hdmi_plat_data *plat_data) > { > - struct platform_device *pdev =3D to_platform_device(dev); > + struct device *dev =3D &pdev->dev; > struct inno_hdmi *hdmi; > int irq; > int ret; > @@ -1128,7 +1148,24 @@ struct inno_hdmi *inno_hdmi_bind(struct device *de= v, > if (ret) > return ERR_PTR(ret); > =20 > - ret =3D drm_bridge_attach(encoder, &hdmi->bridge, NULL, DRM_BRIDGE_ATTA= CH_NO_CONNECTOR); > + return hdmi; > +} > +EXPORT_SYMBOL_GPL(inno_hdmi_probe); > + > +struct inno_hdmi *inno_hdmi_bind(struct device *dev, > + struct drm_encoder *encoder, > + const struct inno_hdmi_plat_data *plat_data) > +{ > + struct platform_device *pdev =3D to_platform_device(dev); > + struct inno_hdmi *hdmi; > + int ret; > + > + hdmi =3D inno_hdmi_probe(pdev, plat_data); > + if (IS_ERR(hdmi)) > + return hdmi; > + > + ret =3D drm_bridge_attach(encoder, &hdmi->bridge, NULL, > + DRM_BRIDGE_ATTACH_NO_CONNECTOR); > if (ret) > return ERR_PTR(ret); This clutters up the structure even more than it is right now. From "bind" back to "probe" and "dev" back to "pdev" and calling a function called "probe" from the bind callback. You are right, that all the resource allocation can (and probably should) live in the drivers probe-path, but then please call that probe function from the actual probe path. =46or example you could look at how all the Synopsys bridges do that. Thanks Heiko