From nobody Sun Dec 14 08:06:55 2025 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABA51154BE5 for ; Thu, 16 Jan 2025 17:43:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737049404; cv=none; b=QsqqOWKBTSrsHwJSvBy9AjM1+jZEvXJwG0R1KxAGwb09KNwkoFkVWWnIoksJi1Qh3EOOcs/edxofe9teDE6sTq0z2r8jsXNzYKZQ1jq3+k4vYZwul+0AiMZMb3S1BY+HnEHTt+KBsutblZS0a5LtTBSJP4n8QCHbX7BV/TRwp8o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737049404; c=relaxed/simple; bh=xc/rDDGiExRP3ODShlw+I9FejJGU9CmHj4NLy1vfe0g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=r5rnugc7HLkjHJFA6R16hKqsNvJ3MpEGdNuhtROGAnkWIgZtV0QnMEMZCLcZmFKQBsVchfyATZo3+kZABon7csyXdZaW3l7HsmTxHJsGCwUJMfaN3DPoBaO2S7CVpqV7DOeRUaxOI7gIoFlseWQDRcKxbDqoO35w9KPhhz/JK08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=DAY8mbAJ; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="DAY8mbAJ" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2166360285dso23949065ad.1 for ; Thu, 16 Jan 2025 09:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1737049402; x=1737654202; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=uBtKYlWCmsTWJXAsi/P2qVR1BJEci/r4rzSkSdKkiNI=; b=DAY8mbAJHVyx6QkzYNePih0Hre/AKc6LsH2Z79nZ3jiVP2rGyyHxt84ZpZCqSB3Kr6 suJtfjOwp12xeA0DkrSf7NvwVsGdLikcnkRy2Cu6Z3Qz6yWa/3KfpllI94M8Jt8WOEVE 0RPF7RGhnbtDuSe/YzgdatuaOwLrKWcJKsAcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737049402; x=1737654202; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uBtKYlWCmsTWJXAsi/P2qVR1BJEci/r4rzSkSdKkiNI=; b=ASUzq8krs7HyzSiS3lw0lokAAO1B2fHRFswn8bv0rzP8Q57L4trKIzeTYk0he7/GRp xeni4U/xblSv1OcFKgPn9Q7V09/oyBZ0pI+F7OlW4jsFKfFMgtV633ZNKAr9JnrMiBiA 4lgmmr9Ud0GbzVSZz777dYWz8u6ghH9w4OhoQYtDX/WqTAmCdGoOJx4BvhFG9LUqArg0 ltAq38lxdPlldYwTla7U4KgP61n6wXlpXNuuGLK8I8wWNATls3WvVFWKEgI5yUsQSHl7 DwKyGB27NhaCSBjTMwtzWz7btNPyV63xWbG8lUlfCk12/6SjCOk5XoPIHkzR/RPtexpC sjwg== X-Forwarded-Encrypted: i=1; AJvYcCXRw5slNry8ff6v1cSuDMXhv3WufkBsRz6EftdhYncrEOEZI+rLeTs+6oZRz79M6AnVRQzUsXpqro4l2KA=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7+YeHI0qAdhxnbg0po8ZUEV2m+Jp8tvmegS2VRIZmgbnIoqI/ i/efRqKJq0FkEumfgjjMnBl2Cy/IOoDCWUUVkw5dkap59b1cwndedqMQw9JQxw== X-Gm-Gg: ASbGncuK451Fusji1utlihqhzNKnhTMr26TCrhKps2Q92PvZMKoaBsrKBXm+mhQAqdx PspLKwMmBDUAZ+E6KBWw6M/b5j9XY3Ct60DPisqhC+cWRBD2dTbNpHlcKmOA3azlJgJNAdheFzC 1fyMVTODdUSlHXXX5sS7WJkW6WWBAro6dmj7h31KNG2Nm8Ou6CjgnRw0u8DyVMX/69icM+0qwG9 eoSwAYdFqUpSf2AIEUXHm7cdXiRanRpx9mIudZq8fsYSz5kYaSK6MeuP7hEtVEvwjLhxY065bdS X-Google-Smtp-Source: AGHT+IEoWJyIWX3XBujOXaws+wrtmniQvJSQSjRB+r+y96gKyl0M0uolS/sv8wolEPPpMrJANi3UYA== X-Received: by 2002:a05:6a20:2593:b0:1d9:aa1:23e3 with SMTP id adf61e73a8af0-1e88d2d5e64mr65470929637.32.1737049401836; Thu, 16 Jan 2025 09:43:21 -0800 (PST) Received: from dianders.sjc.corp.google.com ([2620:15c:9d:2:8dc2:8743:5c90:724f]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72daba4956esm259207b3a.128.2025.01.16.09.43.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 09:43:20 -0800 (PST) From: Douglas Anderson To: Chun-Kuang Hu , Philipp Zabel Cc: Douglas Anderson , Alexandre Mergnat , AngeloGioacchino Del Regno , CK Hu , David Airlie , Matthias Brugger , Simona Vetter , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [PATCH] drm/mediatek: dp: drm_err => dev_err in HPD path to avoid NULL ptr Date: Thu, 16 Jan 2025 09:42:50 -0800 Message-ID: <20250116094249.1.I29b0b621abb613ddc70ab4996426a3909e1aa75f@changeid> X-Mailer: git-send-email 2.48.0.rc2.279.g1de40edade-goog 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" The function mtk_dp_wait_hpd_asserted() may be called before the `mtk_dp->drm_dev` pointer is assigned in mtk_dp_bridge_attach(). Specifically it can be called via this callpath: - mtk_edp_wait_hpd_asserted - [panel probe] - dp_aux_ep_probe Using "drm" level prints anywhere in this callpath causes a NULL pointer dereference. Change the error message directly in mtk_dp_wait_hpd_asserted() to dev_err() to avoid this. Also change the error messages in mtk_dp_parse_capabilities(), which is called by mtk_dp_wait_hpd_asserted(). While touching these prints, also add the error code to them to make future debugging easier. Fixes: 7eacba9a083b ("drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bu= s") Signed-off-by: Douglas Anderson Reviewed-by: CK Hu --- Unfortunately, I have only been able to compile-time test this code. I hit the NULL pointer dereference on a device that's nowhere near upstream and it was running (sigh) a heavily modified copy of this code where the eDP stuff has been forked out of DP. Specifically, you can see . It's pretty easy to understand that the same problem affects both codebases though, so I'm posting this "blind" in the hopes to at least fix upstream. I'll also note that the fact that mtk_edp_wait_hpd_asserted() calls mtk_dp_parse_capabilities() feels weird/wrong to me based on other eDP code I've worked on, but I've only barely looked at the Mediatek driver and perhaps others have already debated this. In any case, that's not directly related to this patch. drivers/gpu/drm/mediatek/mtk_dp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/m= tk_dp.c index 0687672f0e52..ccd104d8851f 100644 --- a/drivers/gpu/drm/mediatek/mtk_dp.c +++ b/drivers/gpu/drm/mediatek/mtk_dp.c @@ -1763,7 +1763,7 @@ static int mtk_dp_parse_capabilities(struct mtk_dp *m= tk_dp) =20 ret =3D drm_dp_dpcd_readb(&mtk_dp->aux, DP_MSTM_CAP, &val); if (ret < 1) { - drm_err(mtk_dp->drm_dev, "Read mstm cap failed\n"); + dev_err(mtk_dp->dev, "Read mstm cap failed: %zd\n", ret); return ret =3D=3D 0 ? -EIO : ret; } =20 @@ -1773,7 +1773,7 @@ static int mtk_dp_parse_capabilities(struct mtk_dp *m= tk_dp) DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0, &val); if (ret < 1) { - drm_err(mtk_dp->drm_dev, "Read irq vector failed\n"); + dev_err(mtk_dp->dev, "Read irq vector failed: %zd\n", ret); return ret =3D=3D 0 ? -EIO : ret; } =20 @@ -2056,7 +2056,7 @@ static int mtk_dp_wait_hpd_asserted(struct drm_dp_aux= *mtk_aux, unsigned long wa =20 ret =3D mtk_dp_parse_capabilities(mtk_dp); if (ret) { - drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n"); + dev_err(mtk_dp->dev, "Can't parse capabilities: %d\n", ret); return ret; } =20 --=20 2.48.0.rc2.279.g1de40edade-goog