| Message ID | 20260901-dw-hdmi-qp-scramb-v11-50-bc12954a0688@collabora.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-25440-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 4626D1C002D for <noreply@patchwork.local>; Tue, 1 Sep 2026 20:58:12 +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-25440-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-25440-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 BC4D16110C4 for <noreply@patchwork.local>; Tue, 1 Sep 2026 18:56:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EEFAC4A8425; Tue, 1 Sep 2026 18:51:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="bvEMwm0R" 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 2EBD14A6CCA for <linux-sunxi@lists.linux.dev>; Tue, 1 Sep 2026 18:51:20 +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=1788288682; cv=none; b=D/dQiPMqbYNs8sEkZZTLXNaFjLCoS7GTr7xPfNQKFgptq/4Ca/1ppj62f7P+ZGW2QxCP26d2Jef+TUSk6wKM64g9rFZgXZbTtAIhUdSQuDm5qnKczepgipnymw7m+2ykFKyC4Z3Pj6RQOAdi4FpdNNVowZRQtBAZcEqpnEgybzE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788288682; c=relaxed/simple; bh=0cXQh/wi9mNTTITbxgaDB3yHqtiGn5+Qa+cNMfRk9UA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=TwkzeZPxuNmEALTRAk3spkTEluyHcg1LnW2eHJwAPnEl7ifb8+F8j+8ObgDxtPgkQ/LdV0FR+hcs5YhW3HN1WGV4GDQfj4pl/7GpyiJW84/444553SGc1rrk1Tm+C2oh2HTSU9m6n+RDAKBJkC8SS5fWsVn+ixzZl9aCH3Xho8s= 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=bvEMwm0R; 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=1788288678; bh=0cXQh/wi9mNTTITbxgaDB3yHqtiGn5+Qa+cNMfRk9UA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=bvEMwm0R4HTcJXN0fRwhoeQ9+XkgI9mIBkkLPPDDjMXynwv5r35tGSGkWAmlC+G/1 V6g3L3B+papJwVafaVwroEXhSTBFdwFcnifiJ18PYA6/hM/KGnTia5/0HLfEbGB9Ax Xl4DiaBBx2xYUz7CbxmgFieMDUfzAwKUJCDOTngb3TZWXhV8KHF3HKAIpHkERR0Pv2 Umc041NnF3oo5NxRj6oi1gO50G/o2hDTpEllAFChOJFURqtBe34kvlhgJ9X1A+T+KO 601K+f1xVcHkI0lThJ+w+TdYSkRuAPrKZcuMEZcdo243ZODSycaVCBa8M/CjKoWv/I iY4d9aJrag7Jg== 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 D8BA717E3C71; Tue, 01 Sep 2026 20:51:17 +0200 (CEST) From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Date: Tue, 01 Sep 2026 21:51:14 +0300 Subject: [PATCH v11 50/74] drm/bridge: adv7511: 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: <20260901-dw-hdmi-qp-scramb-v11-50-bc12954a0688@collabora.com> References: <20260901-dw-hdmi-qp-scramb-v11-0-bc12954a0688@collabora.com> In-Reply-To: <20260901-dw-hdmi-qp-scramb-v11-0-bc12954a0688@collabora.com> To: 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>, Dave Stevenson <dave.stevenson@raspberrypi.com>, Dmitry Baryshkov <lumag@kernel.org>, 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>, Chen-Yu Tsai <wens@kernel.org>, Samuel Holland <samuel@sholland.org>, =?utf-8?q?Ma=C3=ADra_Canal?= <mcanal@igalia.com>, Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>, Raphael Gallais-Pou <rgallaispou@gmail.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>, Helge Deller <deller@gmx.de> 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, linux-fbdev@vger.kernel.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
Sept. 1, 2026, 6:51 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 max_mode_clock_khz does not exceed 165 MHz for any of the chip
variants handled by the driver, advertise HDMI 1.2 as the supported
version and set the bridge's max_tmds_char_rate so the connector limit
inferred from supported_hdmi_ver is overridden by the chip-specific
hardware constraints.
drm_bridge_connector_atomic_check() runs
drm_atomic_helper_connector_hdmi_check(), which rejects modes whose
computed TMDS character rate exceeds the connector limit before invoking
the driver's .tmds_char_rate_valid() hook, making
adv7511_bridge_hdmi_tmds_char_rate_valid() redundant. Drop it.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 22 +++-------------------
1 file changed, 3 insertions(+), 19 deletions(-)
Comments
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Missing IRQ disablement and workqueue cancellation in driver removal and probe error paths. -- commit e3d22519d26e84f17c45f704d4c2a1fc871e1036 Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> drm/bridge: adv7511: Advertise HDMI 1.2 capabilities Bridges using DRM_BRIDGE_OP_HDMI are now expected to provide a supported HDMI version. This commit advertises HDMI 1.2 as the supported version and sets the bridge's max_tmds_char_rate. It also drops the redundant adv7511_bridge_hdmi_tmds_char_rate_valid() hook. > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > index 038b852405b54..c3ef44074477b 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c [ ... ] > @@ -1359,6 +1341,8 @@ static int adv7511_probe(struct i2c_client *i2c) > > adv7511->bridge.vendor = "Analog"; > adv7511->bridge.product = adv7511->info->name; > + adv7511->bridge.supported_hdmi_ver = HDMI_VERSION_1_2; > + adv7511->bridge.max_tmds_char_rate = 1000ULL * adv7511->info->max_mode_clock_khz; > > #ifdef CONFIG_DRM_I2C_ADV7511_AUDIO [Severity: High] This isn't a bug introduced by this patch, but I noticed a potential use-after-free in the error handling and driver removal paths of this driver. In adv7511_probe(), the driver registers a shared interrupt via devm_request_threaded_irq() and initializes adv7511->hpd_work. However, in the err_unregister_audio probe error path, the devm-managed IRQ can still fire because the resources are manually freed before the devm cleanup runs: adv7511_probe() { ... err_unregister_audio: drm_bridge_remove(&adv7511->bridge); i2c_unregister_device(adv7511->i2c_cec); clk_disable_unprepare(adv7511->cec_clk); err_i2c_unregister_packet: i2c_unregister_device(adv7511->i2c_packet); ... } Similarly, adv7511_remove() manually unregisters I2C devices while the devm-managed IRQ remains active until devres cleanup: adv7511_remove() { ... i2c_unregister_device(adv7511->i2c_cec); clk_disable_unprepare(adv7511->cec_clk); i2c_unregister_device(adv7511->i2c_packet); i2c_unregister_device(adv7511->i2c_edid); ... } Could a hotplug or CEC interrupt firing during or just after these cleanup paths attempt to access the freed I2C clients? Furthermore, since cancel_work_sync() is never called for hpd_work, could any scheduled work execute after the adv7511 structure has been freed by devres, leading to memory corruption or a kernel panic?
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 038b852405b5..c3ef44074477 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -8,6 +8,7 @@ #include <linux/clk.h> #include <linux/device.h> #include <linux/gpio/consumer.h> +#include <linux/hdmi.h> #include <linux/module.h> #include <linux/of.h> #include <linux/slab.h> @@ -775,11 +776,6 @@ static int adv7511_connector_init(struct adv7511 *adv) * DRM Bridge Operations */ -static const struct adv7511 *bridge_to_adv7511_const(const struct drm_bridge *bridge) -{ - return container_of(bridge, struct adv7511, bridge); -} - static void adv7511_bridge_atomic_enable(struct drm_bridge *bridge, struct drm_atomic_commit *state) { @@ -817,19 +813,6 @@ static void adv7511_bridge_atomic_disable(struct drm_bridge *bridge, adv7511_power_off(adv); } -static enum drm_mode_status -adv7511_bridge_hdmi_tmds_char_rate_valid(const struct drm_bridge *bridge, - const struct drm_display_mode *mode, - unsigned long long tmds_rate) -{ - const struct adv7511 *adv = bridge_to_adv7511_const(bridge); - - if (tmds_rate > 1000ULL * adv->info->max_mode_clock_khz) - return MODE_CLOCK_HIGH; - - return MODE_OK; -} - static enum drm_mode_status adv7511_bridge_mode_valid(struct drm_bridge *bridge, const struct drm_display_info *info, const struct drm_display_mode *mode) @@ -1006,7 +989,6 @@ static const struct drm_bridge_funcs adv7511_bridge_funcs = { .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, .atomic_create_state = drm_atomic_helper_bridge_create_state, - .hdmi_tmds_char_rate_valid = adv7511_bridge_hdmi_tmds_char_rate_valid, .hdmi_clear_audio_infoframe = adv7511_bridge_hdmi_clear_audio_infoframe, .hdmi_write_audio_infoframe = adv7511_bridge_hdmi_write_audio_infoframe, .hdmi_clear_avi_infoframe = adv7511_bridge_hdmi_clear_avi_infoframe, @@ -1359,6 +1341,8 @@ static int adv7511_probe(struct i2c_client *i2c) adv7511->bridge.vendor = "Analog"; adv7511->bridge.product = adv7511->info->name; + adv7511->bridge.supported_hdmi_ver = HDMI_VERSION_1_2; + adv7511->bridge.max_tmds_char_rate = 1000ULL * adv7511->info->max_mode_clock_khz; #ifdef CONFIG_DRM_I2C_ADV7511_AUDIO adv7511->bridge.ops |= DRM_BRIDGE_OP_HDMI_AUDIO;