| Message ID | 20260731-dw-hdmi-qp-scramb-v10-49-294364b2cf15@collabora.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-24848-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74]) by mxe881.netcup.net (Postfix) with ESMTPS id 227B51C22FA for <noreply@patchwork.local>; Fri, 31 Jul 2026 18:39:36 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=collabora.com; spf=pass (sender IP is 172.232.135.74) smtp.mailfrom=linux-sunxi+bounces-24848-noreply=patchwork.local@lists.linux.dev smtp.helo=sto.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.232.135.74 as permitted sender) client-ip=172.232.135.74; envelope-from=linux-sunxi+bounces-24848-noreply=patchwork.local@lists.linux.dev; helo=sto.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id 7312731190FC for <noreply@patchwork.local>; Fri, 31 Jul 2026 16:24:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 48DF246A5E2; Fri, 31 Jul 2026 16:20:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="IiFq5wAR" X-Original-To: linux-sunxi@lists.linux.dev Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 58F2E44C649 for <linux-sunxi@lists.linux.dev>; Fri, 31 Jul 2026 16:19:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785514798; cv=none; b=W74bWdbtlqEBusIzThKBUiD2F+ZJ2Y/DIwb3RqRo6dIXfsO2hf+Gfty8BCloOdJM6t0CCp78VyK7nWv2M5W7t1wCGujzv7B6g9MRjj1jEWPy2WF+qbSaz2CNHNdIhn1SxZYA4wrOfmWIXyHqVzqgIZjU6OYUKzAIMDtUTxZy+5c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785514798; c=relaxed/simple; bh=hse6ZoBRDdkgueZEFZSp6DqlC7adzsHmGMK2OKfFL4E=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Vww7RhG6KXbRMkb9NOPGcg9d8hYfam43gYVrtIIQEDr8YkMnURyiY45OkyhL4XFdrD0w+KRtCC1UjcnkZBC4o9y2lxj89WM3uHRav7fQCgTsk0H3+yB4lPecbKtEunnFPaLRNaAgn9Mg+TwAS5NZq4S759NIzXMVXcWFXs/uK6o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=IiFq5wAR; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1785514789; bh=hse6ZoBRDdkgueZEFZSp6DqlC7adzsHmGMK2OKfFL4E=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=IiFq5wARocQVqFD0cNI83kNg5TUsSbclt8ZwoJEBxXDvmO1oxshnL1PymkbQk4abG J4jCdnMtGv61ajDAZNcicCL+1MZRS8yKjMczkmIByIPRKQQGJwkA+l29u0HhLt8a7q ENZekvJp2QuJwBKVaIB26gmr9+Zgn/ZB6W89sDgmRlSEH+ivzhiNKK5QGb79wJ3rdh 8wZzraSEvRWQAEMsfiPx6QpJVIhpiVaJVyI35n+zTwYqsg9lHvn5Xr8e1EPXTw0x0/ CW1XJSlNMsLT2rcEa45in5sqzDfpyos2E9g+gjVghMZCZ/BGNZbiCTp628ptZgLZGV /2rbb4pP7MJ4g== Received: from localhost (unknown [100.64.0.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id A01BA17E090B; Fri, 31 Jul 2026 18:19:49 +0200 (CEST) From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Date: Fri, 31 Jul 2026 19:19:56 +0300 Subject: [PATCH v10 49/69] drm/bridge: inno-hdmi: Advertise HDMI 1.2 capabilities Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260731-dw-hdmi-qp-scramb-v10-49-294364b2cf15@collabora.com> References: <20260731-dw-hdmi-qp-scramb-v10-0-294364b2cf15@collabora.com> In-Reply-To: <20260731-dw-hdmi-qp-scramb-v10-0-294364b2cf15@collabora.com> To: Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Luca Ceresoli <luca.ceresoli@bootlin.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>, Chen-Yu Tsai <wens@kernel.org>, Samuel Holland <samuel@sholland.org>, Dave Stevenson <dave.stevenson@raspberrypi.com>, =?utf-8?q?Ma=C3=ADra_Canal?= <mcanal@igalia.com>, Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>, Sandy Huang <hjc@rock-chips.com>, =?utf-8?q?Heiko_St=C3=BCbner?= <heiko@sntech.de>, Andy Yan <andy.yan@rock-chips.com>, Algea Cao <algea.cao@rock-chips.com>, Daniel Stone <daniels@collabora.com>, Liu Ying <victor.liu@nxp.com>, Phong LE <ple@baylibre.com> Cc: kernel@collabora.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-rockchip@lists.infradead.org X-Mailer: b4 0.15.2 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
Add HDMI 2.0 support to DW HDMI QP TX
|
|
Commit Message
Cristian Ciocaltea
July 31, 2026, 4:19 p.m. UTC
Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a
supported HDMI version. This is not yet enforced, but will become
mandatory once the migration to the new caps-based HDMI connector
initialization API is completed.
Since inno_hdmi_phy_config.pixelclock does not exceed 165 MHz for any of
the chip variants handled by the driver, advertise HDMI 1.2 as the
supported version.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/bridge/inno-hdmi.c | 1 +
1 file changed, 1 insertion(+)
Comments
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: Pre-existing issues: - [High] The I2C adapter is registered and exposed before `hdmi->i2c` is assigned, creating a race window where an I2C transfer can trigger a NULL pointer dereference. - [High] The threaded IRQ is requested before the DRM bridge is fully initialized and attached, causing a NULL pointer dereference if an early interrupt fires. -- --- Patch [49]: [PATCH v10 49/69] drm/bridge: inno-hdmi: Advertise HDMI 1.2 capabilities --- commit edc5142ea37d19616540dca30f30fcf265c228eb Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> drm/bridge: inno-hdmi: Advertise HDMI 1.2 capabilities Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a supported HDMI version. This is not yet enforced, but will become mandatory once the migration to the new caps-based HDMI connector initialization API is completed. Since inno_hdmi_phy_config.pixelclock does not exceed 165 MHz for any of the chip variants handled by the driver, advertise HDMI 1.2 as the supported version. > diff --git a/drivers/gpu/drm/bridge/inno-hdmi.c b/drivers/gpu/drm/bridge/inno-hdmi.c > index dd35f5a875d3d..ea3447d4f285b 100644 > --- a/drivers/gpu/drm/bridge/inno-hdmi.c > +++ b/drivers/gpu/drm/bridge/inno-hdmi.c > @@ -1119,6 +1119,7 @@ struct inno_hdmi *inno_hdmi_bind(struct device *dev, > hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA; > hdmi->bridge.vendor = "Inno"; > hdmi->bridge.product = "Inno HDMI"; [Severity: High] This is a pre-existing issue, but is it possible for an early interrupt to cause a NULL pointer dereference here? Earlier in inno_hdmi_bind(), devm_request_threaded_irq() is called, which can enable the IRQ and trigger inno_hdmi_irq() before the bridge is fully initialized. If that happens, inno_hdmi_irq() calls: drm_helper_hpd_irq_event(hdmi->bridge.dev). However, hdmi->bridge.dev is not initialized until drm_bridge_attach() is called later in the inno_hdmi_bind() sequence. Will this lead to drm_helper_hpd_irq_event() dereferencing a NULL pointer? > + hdmi->bridge.supported_hdmi_ver = HDMI_VERSION_1_2; > > hdmi->bridge.ddc = inno_hdmi_i2c_adapter(hdmi); [Severity: High] This isn't a bug introduced by this patch, but does registering the I2C adapter before assigning the internal data structure pointer create a race condition? Inside inno_hdmi_i2c_adapter(), devm_i2c_add_adapter(hdmi->dev, adap) is called before hdmi->i2c = i2c is set. If a concurrent I2C transfer is initiated (for example, from userspace via i2c-dev) immediately after registration, the transfer callback inno_hdmi_i2c_xfer() will execute. When inno_hdmi_i2c_xfer() runs, it does: struct inno_hdmi_i2c *i2c = hdmi->i2c; mutex_lock(&i2c->lock); Could this dereference the uninitialized hdmi->i2c pointer, causing a crash? > if (IS_ERR(hdmi->bridge.ddc))
diff --git a/drivers/gpu/drm/bridge/inno-hdmi.c b/drivers/gpu/drm/bridge/inno-hdmi.c index dd35f5a875d3..ea3447d4f285 100644 --- a/drivers/gpu/drm/bridge/inno-hdmi.c +++ b/drivers/gpu/drm/bridge/inno-hdmi.c @@ -1119,6 +1119,7 @@ struct inno_hdmi *inno_hdmi_bind(struct device *dev, hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA; hdmi->bridge.vendor = "Inno"; hdmi->bridge.product = "Inno HDMI"; + hdmi->bridge.supported_hdmi_ver = HDMI_VERSION_1_2; hdmi->bridge.ddc = inno_hdmi_i2c_adapter(hdmi); if (IS_ERR(hdmi->bridge.ddc))