From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794063942; b=gUc2CkjY7LgqdCx8IFKU/vxj0ffx5JD5xVuW2RaBSi1C2idS2X1NgfesFmLNHpJo8MDu yLMlGfEb+rJW5hLHf9jPuHRmoxSFpPyuwBmpiVvv1zJlopa+4/AOUeUo/f64+vDw93Kt3 /Gbe1T1QhvFZnmC1J91wPBfblmoifD7nK74j5ILbDX6TRAdFJehrXZa93jf1rB6zRzB5e vIdFrYO+MT8Ck+7WfovFw7gLoYVVGf/adaZvH9k/T5wOu54IdcgNKj7gk4PywyxZ9OEua sYbSr6Y5R8rabbZMnBujnJjfjlNmVd2lSfcXelzlEQ+Ctr9A9nzWNrtjMplh62Xtn3A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794063942; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=y0a+kWrFBMH/xDBJQrevYw/UpQQXU3bAT4kXS/4slbg=; b=IWlDRGDxaQpj8LeCiIgXt/Dc892kkZlFyH1YivyptXsRbefiW4zG75QdzuHQxnccu3aG WWSqMJIyYUpA7+H//xhWWkVisoS8OKwm84Op/V84SWP1XwTbAK3pmCioB5DBv9dzFYNTi PRKHStcIaLyj+QaGYkLWj5Xln0c7hZ4qF/vtT+P2agCEUK40A6UuCw1T990HhIRP4cd6f E8lOS4w2Em0/GgvOdQUs+si+UMaUsxFli/YHoHUbwT602c/FObQIir1jM9/mnf13apfKp dQakFj3eYjo95kdsR5qbibw6q+YWNM2c59tx6D0VQpcag5sSz5T7/rZ+S/TCkUyZuGA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=RBMQQmMq; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA89A606D829; Sat, 7 Nov 2026 15:05:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=RBMQQmMq Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F4591F008A2; Sat, 7 Nov 2026 15:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794063941; bh=y0a+kWrFBMH/xDBJQrevYw/UpQQXU3bAT4kXS/4slbg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=RBMQQmMqc18lJPTmJO7I2CWup4OoA5xjiLIK5Hw9maKH/FZsAwdGejYqOZjHav0rr ugnAKglf/41pk7EN96KNLv1BuCiOnGXT9ba1jbVexHjx20PZhb4XHkANfQhdJJ7OlA i4ITQ6MhtRwkf/a9MedbwdkhzHNWlAtH0tfMLl1A= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Luca Ceresoli , Damon Ding , Sasha Levin Subject: [PATCH 7.3 0126/1257] drm/bridge: analogix_dp: Restore mandatory samsung DP DT properties Date: Sat, 7 Nov 2026 08:40:22 -0500 Message-ID: <20261107134942.805884501@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134939.434104957@linuxfoundation.org> References: <20261107134939.434104957@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Damon Ding [ Upstream commit 02f569dd66c94dd67b2586f776235cf4177409ed ] Revert the change that made samsung,link-rate and samsung,lane-count optional for Exynos DP. Add error checking to fail probe early if the required DT properties are missing. If these properties are missing, video_info->max_link_rate and video_info->max_lane_count remain zero, and so do link_train.link_rate and link_train.lane_count used in the subsequent link training flow, resulting in link training failure. There is no way at all a device can work without these properties. Here is the code flow when either max_link_rate or max_lane_count is 0: analogix_dp_commit() -> analogix_dp_full_link_train(dp, max_lanes = 0, max_rate = 0) analogix_dp_full_link_train(max_lanes, max_rate): // Read sink capabilities via DPCD and sanitize them link_rate = read_dpcd(DP_MAX_LINK_RATE); // >= 0x06 after fixup lane_count = read_dpcd(DP_MAX_LANE_COUNT); // >= 1 after fixup // Clamp by the limits from DT if (link_rate > max_rate) // 0x06 > 0, always true link_rate = max_rate; // link_rate = 0 if (lane_count > max_lanes) // 1 > 0, always true lane_count = max_lanes; // lane_count = 0 // Configure TX with the zeroed values set_link_bandwidth(link_rate = 0) // writel() is only executed for bwtype == 0x06/0x0a, // so LINK_BW_SET is never written and stays at // reset value; phy_configure() gets link_rate = 0. set_lane_count(lane_count = 0) // writel(0, ANALOGIX_DP_LANE_COUNT_SET) enables 0 lanes; // phy_configure() is called with lanes = 0. // Program sink for link training drm_dp_dpcd_write(DP_LINK_BW_SET, {link_rate = 0/lane_count = 0}) // DP spec requires link rate in {0x06, 0x0a, 0x14} and // lane count in {1, 2, 4}. Writing zeros is illegal, so // the sink cannot enter the training state. // Training loop for (lane = 0; lane < lane_count /* 0 */; lane++) // loop body never executes; training_lane[] stays // uninitialized and no training register is programmed Since the sanitized sink values are always non-zero (link_rate >= 0x06, lane_count >= 1), the clamping with a zero maximum unconditionally forces the training parameters to zero. Clock recovery can never be achieved, so link training fails deterministically. Consequently, making these properties mandatory again cannot break any existing device: a DT without them could never have worked in the first place. Failing probe early with a clear error message is more helpful than a silent link training failure at runtime. Fixes: 0d0abd894ead ("drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260828065153.590802-4-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 30c0c0b41d5aa..4213cd68d5a0d 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -1248,6 +1248,7 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp) { struct device_node *dp_node = dp->dev->of_node; struct video_info *video_info = &dp->video_info; + u32 val; switch (dp->plat_data->dev_type) { case RK3288_DP: @@ -1269,10 +1270,14 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp) * NOTE: those property parseing code is used for * providing backward compatibility for samsung platform. */ - of_property_read_u32(dp_node, "samsung,link-rate", - &video_info->max_link_rate); - of_property_read_u32(dp_node, "samsung,lane-count", - &video_info->max_lane_count); + if (of_property_read_u32(dp_node, "samsung,link-rate", &val)) + return dev_err_probe(dp->dev, -EINVAL, + "Failed to get samsung,link-rate\n"); + video_info->max_link_rate = val; + if (of_property_read_u32(dp_node, "samsung,lane-count", &val)) + return dev_err_probe(dp->dev, -EINVAL, + "Failed to get samsung,lane-count\n"); + video_info->max_lane_count = val; break; } -- 2.53.0