From nobody Sat Jun 13 06:24:14 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.5]) (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 5117338B7D8 for ; Sat, 9 May 2026 08:34:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315648; cv=none; b=W3iC+id8vIo6CarqPMvqjeKDWEG1m4KxR3YCD1DZ1AzEo5VSpvcMPVWt5b06c9Gx6mbkWmeoAa+6Vp8OIPBFJfWQ0gXfLQ2oB+Y6ppyyuJLqoX66Um3G76zj6uMyXG1ythinZJQSENHQpJfNGPubufv6IuhWt6v8OgpPE2UlgcU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315648; c=relaxed/simple; bh=1mUBi8XVeHuT0cimTftGVD96HGaMz1z/MwBaAlnIt28=; h=Content-Type:MIME-Version:From:To:Cc:Subject:Message-ID:Date: In-Reply-To:References; b=o9Qdjakat0v4P8XaZoS1A6/Vqk3HAcy+FM9IFWdhNVwwDCCt0JZ9XPyzLlJtEJ2lfXvX0vT7b3O2N3YXHpeCap7kV7uK9La72w7quA5anB5TpXNTurkuDGPJscv155aEhYe2jZIELWfSGKi6ekyn2CD+oYSbpxBOh3hS5ZngrIA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=FwIfTZ8q; arc=none smtp.client-ip=117.135.210.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="FwIfTZ8q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Content-Type:MIME-Version:From:To:Subject: Message-ID:Date; bh=fIg7jH6l469fjJ3LU/wSfvIfeolPJim4znYYu484JlI=; b=FwIfTZ8qDxN8sJoicgyWnyIctN5s0yR8cQu3cxsmST0LVTZyOWlHc3r5VI8zkE wR/+6RKKYdbGvF9J7kE+fMOXSbqWrxfsxC5rVOyCXA4sHB8CHL9M9xJQcSTSE4D7 E32NRifoFhJwnvqMqM0NlcQhaKVylsV8+6orgaQu/KXBM= Received: from [127.0.1.1] (unknown []) by gzga-smtp-mtada-g0-1 (Coremail) with SMTP id _____wB3LZNd8f5pUxZsAQ--.35506S2; Sat, 09 May 2026 16:33:33 +0800 (CST) 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 From: Jiaqi To: dri-devel@lists.freedesktop.org Cc: Sandy Huang , Heiko Stuebner , David Airlie , Daniel Vetter , Philipp Zabel , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 1/6] drm/rockchip: Fix of_node reference leak in rockchip_drm_encoder_set_crtc_endpoint_id() Message-ID: <177831561279.322716.8618557593387718298@163.com> Date: Sat, 09 May 2026 16:33:32 +0800 In-Reply-To: <177831560568.322716.7926332149561323511@163.com> References: <177831560568.322716.7926332149561323511@163.com> X-CM-TRANSID: _____wB3LZNd8f5pUxZsAQ--.35506S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7CF4UWr18Xry5ZFW3Zw17trb_yoW8Ar13pa n3Gr9Yvr48GrWfWr10yr47ArySkws2va17CF97C3W3Zan3ArnYyw1fKF1vgr15ArWxuFyj yrs7Ga4j9F17urUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jjnQUUUUUU= X-CM-SenderInfo: xvklyxpdtlsvxhyhz0rs6rljoofrz/xtbC7x2tAWn+8V1hpgAA3i Content-Type: text/plain; charset="utf-8" The function rockchip_drm_encoder_set_crtc_endpoint_id() acquires device tree node references via of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint(), but never releases them. This happens on all exit paths, including the success path. This leads to reference count leaks that accumulate during encoder probe. In deferred probe scenarios or module reload, the leaked references can cause of_node_get() to eventually return -ENOMEM, breaking subsequent device tree parsing. Fix by adding the corresponding of_node_put() calls for both 'en' and 'ren', and use a unified error path to avoid duplication. Signed-off-by: Jiaqi --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 14 +++++++++---- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/= rockchip/rockchip_drm_drv.c index 8afabe2118a9..1234567890ab 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -278,18 +278,22 @@ int rockchip_drm_encoder_set_crtc_endpoint_id(struct = rockchip_encoder *rkencoder, { struct of_endpoint ep; struct device_node *en, *ren; int ret; en =3D of_graph_get_endpoint_by_regs(np, port, reg); if (!en) return -ENOENT; ren =3D of_graph_get_remote_endpoint(en); if (!ren) - return -ENOENT; + goto err_put_en; ret =3D of_graph_parse_endpoint(ren, &ep); if (ret) - return ret; + goto err_put_ren; rkencoder->crtc_endpoint_id =3D ep.id; - return 0; +err_put_ren: + of_node_put(ren); +err_put_en: + of_node_put(en); + return ret; } /* -- 2.40.0 From nobody Sat Jun 13 06:24:14 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.3]) (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 733EF38E5DA for ; Sat, 9 May 2026 08:34:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315652; cv=none; b=LctXvsPiCxrJDrc1jBYMdDca4MB82fXkY7H7XnNijZ/GODaNUMJoRK+zaeRH+kurtoVhwPiQUfPgtnJcCzL3QFuns2j0KOKJN9hJsObQtNN0J0SE1uZgjxDHn5Bu5d7wmF4wUkUZYlbHp74MJJNvvHPGE+bL8OguhnbfAgxeZXU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315652; c=relaxed/simple; bh=Pqsr68YRbQYcfAr9hDjpGY/uIjJlcrohQhT45GOSlJU=; h=Content-Type:MIME-Version:From:To:Cc:Subject:Message-ID:Date: In-Reply-To:References; b=FxYYEy85KhGY3vGwF8Kz2Z03QcXVnuljB5mSD7X4PL7TlTm2PMWI1n/Qcw1oLDngxstKNirudYegwENqwNW2XaI7sZrWCL1cJGB6k/Xt/z1n3f9XlsrB32T6m4luXYyjyK3izefS1mudHiEcRweud5axapc/uK9DYsxJyaMql1s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=AyOJRuHr; arc=none smtp.client-ip=117.135.210.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="AyOJRuHr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Content-Type:MIME-Version:From:To:Subject: Message-ID:Date; bh=bLfORmC5aPVuu+uW8Qajt0bwyQArv6YG/8T5MiSJpBQ=; b=AyOJRuHr9x9rK2iJAc+Q3FO94V2mWH/SQXravs9nPn9WHn8gQTGR4ovSTWW4LR 1j2j++21sz71tmnR7XkA7poKLQCgfSKLSYScZ0vSX013onY/Je74w3EWJcuhC2JE i+PMrikt4+hUiD5BOPOhyWiVv/bCZhdhesSKofWbvy7/Y= Received: from [127.0.1.1] (unknown []) by gzsmtp5 (Coremail) with SMTP id QCgvCgCXy7Fi8f5pRiRkDA--.52S2; Sat, 09 May 2026 16:33:40 +0800 (CST) 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 From: Jiaqi To: dri-devel@lists.freedesktop.org Cc: Sandy Huang , Heiko Stuebner , David Airlie , Daniel Vetter , Philipp Zabel , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 2/6] drm/rockchip: Fix dangling crtc->state in vop2_crtc_reset() Message-ID: <177831561857.322716.12441367864582734767@163.com> Date: Sat, 09 May 2026 16:33:38 +0800 In-Reply-To: <177831560568.322716.7926332149561323511@163.com> References: <177831560568.322716.7926332149561323511@163.com> X-CM-TRANSID: QCgvCgCXy7Fi8f5pRiRkDA--.52S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7AF1xGFykGw4kCF4DWF4rKrg_yoW8Jw4fpr s7Cryj9r4UKrWjqrnrJr1xursak3ZFyayxGr97Gw13u3Wjqwn8CrnI9ryqv3y7ArWfA3yj yrs7Jw45ZF4qyr7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07USoGdUUUUU= X-CM-SenderInfo: xvklyxpdtlsvxhyhz0rs6rljoofrz/xtbCzgWvA2n+8WUlVAAA3V Content-Type: text/plain; charset="utf-8" In vop2_crtc_reset(), if kzalloc() fails to allocate a new rockchip_crtc_state, the function returns early without setting crtc->state to NULL. However, the old state has already been destroyed and freed by __drm_atomic_helper_crtc_destroy_state() and kfree(). This leaves crtc->state as a dangling pointer. Any subsequent access to crtc->state (e.g., through to_rockchip_crtc_state()) will result in a use-after-free or NULL pointer dereference, leading to a kernel crash. Fix by setting crtc->state =3D NULL when kzalloc() fails, ensuring the pointer is in a well-defined state. Signed-off-by: Jiaqi --- drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm= /rockchip/rockchip_drm_vop2.c index 8afabe2118a9..1234567890ab 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c @@ -2082,8 +2082,10 @@ static void vop2_crtc_reset(struct drm_crtc *crtc) } vcstate =3D kzalloc(sizeof(*vcstate), GFP_KERNEL); - if (!vcstate) + if (!vcstate) { + crtc->state =3D NULL; return; + } crtc->state =3D &vcstate->base; crtc->state->crtc =3D crtc; -- 2.40.0 From nobody Sat Jun 13 06:24:14 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3]) (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 BA5C538E5DA for ; Sat, 9 May 2026 08:34:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315659; cv=none; b=VW4B06bjI+YHaX5QToNEQmLHwfD2klkoHNjG9V5Hs4ndSUlNnOSGY+uWrgieU+5LPTRbZUBpTo+wUFeIl/uVMBr4v0jeIdLpHXXKVbYnipQga5TDNpC1MnjDpRywe4CfJmbnLMzbPJICqEDvk0wn7xkn/UU4pwfNFWgo3B0B9Yc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315659; c=relaxed/simple; bh=rJEd7jd7lbhb9HgHVY9gCRK5caS+KzQ7Zh5erR3PIFY=; h=Content-Type:MIME-Version:From:To:Cc:Subject:Message-ID:Date: In-Reply-To:References; b=gjQnhl5c7oXROona1XZqw8Wovgk6FQ1AkmMC+isMAc7ZmDYFFnkBXfzpek4Rs6YDW9ZPdoKkRzqRuNitd9kKEXNA3fopUoo6AJU08JA1d+vr4E9mGrUMNXSPjhW+u/cdAHNWTwbO1AJ1OODQQ5wt3I5bL/ShWhhDR+2EvZ2TATE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=TkTGr1fZ; arc=none smtp.client-ip=220.197.31.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="TkTGr1fZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Content-Type:MIME-Version:From:To:Subject: Message-ID:Date; bh=QDsMAqiDey72kv51bqnl/z6qjCUvcOw5P+Pu54iYqD8=; b=TkTGr1fZRiAvq7qXNr6eU57F6n/UKru6bVON/FkD3GauRb9vSpch7k5mZhtV5n 9rlw5zgxl3JS574SBgCVxRgHxlTJKp1JveD6YrQzbWo5skJO5ev6KCCnjRRprHph AvytLTB4ZwJr2XaFfMyrnIQzXXAr2c4OsWaoUhbCiMvBI= Received: from [127.0.1.1] (unknown []) by gzsmtp1 (Coremail) with SMTP id PCgvCgDHNvZq8f5p9I7gCw--.795S2; Sat, 09 May 2026 16:33:47 +0800 (CST) 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 From: Jiaqi To: dri-devel@lists.freedesktop.org Cc: Sandy Huang , Heiko Stuebner , David Airlie , Daniel Vetter , Philipp Zabel , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 3/6] drm/rockchip: Fix vop2_create_crtcs() error path cleanup in vop2_bind() Message-ID: <177831562588.322716.15278219029796776135@163.com> Date: Sat, 09 May 2026 16:33:45 +0800 In-Reply-To: <177831560568.322716.7926332149561323511@163.com> References: <177831560568.322716.7926332149561323511@163.com> X-CM-TRANSID: PCgvCgDHNvZq8f5p9I7gCw--.795S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7tr1kAF18ur1rCryxKry8Xwb_yoW8GF4kpw 4kJrWUZr4DKr40qF1kAF1kuF4F9w4SyayfJFn2k343uFnrKr1qyr1Y9a4Fyr43XF4xCFyj vFZrJ3y5XF1j9r7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUl19UUUUU= X-CM-SenderInfo: xvklyxpdtlsvxhyhz0rs6rljoofrz/xtbCzQuwBGn+8WsmAAAA3Z Content-Type: text/plain; charset="utf-8" In vop2_bind(), when vop2_create_crtcs() fails, the function returns immediately without calling vop2_destroy_crtcs(). This means any of_node references stored in vp->crtc.port by vop2_create_crtcs() are leaked, as they are only released in vop2_destroy_crtcs(). Fix by ensuring vop2_create_crtcs() failures go through the err_crtcs label, which calls vop2_destroy_crtcs() to properly release all resources including of_node references. Note: the IRQ registered via devm_request_irq() earlier in vop2_bind() is managed by devres and must NOT be manually freed in the error path. Devres will automatically release it when the device is unbound or released by the component framework. Signed-off-by: Jiaqi --- drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm= /rockchip/rockchip_drm_vop2.c index 8afabe2118a9..1234567890ab 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c @@ -2735,7 +2735,7 @@ static int vop2_bind(struct device *dev, struct devic= e *master, void *data) =20 ret =3D vop2_create_crtcs(vop2); if (ret) - return ret; + goto err_crtcs; =20 ret =3D vop2_find_rgb_encoder(vop2); if (ret >=3D 0) { -- 2.40.0 From nobody Sat Jun 13 06:24:14 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.4]) (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 BA56D38E124 for ; Sat, 9 May 2026 08:34:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315663; cv=none; b=sswiHjspB1nSKpdmCzR3BCvD0f8SptdEQSedEi3et7FEJJYLqEdk/41AbDebSgIo/Sh6+PtbPHz9fbZldaKgFdw0b01tSuj+gNeeQjEIX8VcXTZ8GjDmpT21zfsCBuP8wpwKAJEc6NMyP+L33l+8I8pB08GSaHHxCi63nj7J7/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315663; c=relaxed/simple; bh=HfRhiV9PaJlm6DYwzrOngob36SVu8QY6iP9D6WYPtXM=; h=Content-Type:MIME-Version:From:To:Cc:Subject:Message-ID:Date: In-Reply-To:References; b=t2A4rEQ7OzY8O8lUgA80DnsqtNVfLzHlkJtEhPvbKdkLe+jnzEN2p7sLtIOTkmXs0VM06/EdS7xbpzYUZ6r/ask7aV/Why865onJ9XcLcChYk9DpLjFBysVjYNgZKZU1yFr3UZAswANwqO5oyHhq+laxvfclf76/dkMi06Dv6zg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=mrLFWYjO; arc=none smtp.client-ip=220.197.31.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="mrLFWYjO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Content-Type:MIME-Version:From:To:Subject: Message-ID:Date; bh=a83z96YzJ75nDxqS/kiW5XrSRi2azphYRz9D6P97XTQ=; b=mrLFWYjOEX+PRjQzFqbHTg95cG39sKhnMFH3jGw4+8sCzT1PfZd+nq7k032pvs /nXfg3scgpoKoEsy4wwCiA5J3Ov+FQ7OPZ9GKyhDPrRW8+eoPd/3hjTbJqAviycu uCoGI9ne/ZaouwjhxJmyVIOVHDzebR2d1nX8bSwAXCMi4= Received: from [127.0.1.1] (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wDXn6Nx8f5pDQlyAQ--.724S2; Sat, 09 May 2026 16:33:53 +0800 (CST) 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 From: Jiaqi To: dri-devel@lists.freedesktop.org Cc: Sandy Huang , Heiko Stuebner , David Airlie , Daniel Vetter , Philipp Zabel , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 4/6] drm/rockchip: Fix vmap address caching in rockchip_gem_prime_vmap() Message-ID: <177831563268.322716.16290375245774379615@163.com> Date: Sat, 09 May 2026 16:33:52 +0800 In-Reply-To: <177831560568.322716.7926332149561323511@163.com> References: <177831560568.322716.7926332149561323511@163.com> X-CM-TRANSID: _____wDXn6Nx8f5pDQlyAQ--.724S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7Aw1Dtr18uw15CrW5Gw1UAwb_yoW8GF1xpa 9xu39IyrW8GrWjqrsrXFnrA3ZxK3Wv9ayxGryfKanI93WxWF9Ikr12kFyDJFZrJrsrCFWa qr4kA345ZrsFvr7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUgA7UUUUU= X-CM-SenderInfo: xvklyxpdtlsvxhyhz0rs6rljoofrz/xtbC7xGyBmn+8XFj8QAA3P Content-Type: text/plain; charset="utf-8" In rockchip_gem_prime_vmap(), when rk_obj->kvaddr is NULL, a new vmap() is performed but the resulting virtual address is only stored in the local variable 'vaddr', not saved to rk_obj->kvaddr. This causes three problems: 1. Every subsequent prime_vmap call re-maps the same pages, wasting kernel virtual address space and TLB resources. 2. If the gem object is freed before prime_vunmap is called (e.g., in an error path), rockchip_gem_free_iommu() calls vunmap(rk_obj->kvaddr) which is NULL, so the prime_vmap-created mapping is never freed. 3. Multiple concurrent mappings of the same object cannot be tracked. Fix by saving the newly vmap()'d address to rk_obj->kvaddr so it can be reused and properly cleaned up. Signed-off-by: Jiaqi --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/= rockchip/rockchip_drm_gem.c index 8afabe2118a9..1234567890ab 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c @@ -520,6 +520,7 @@ int rockchip_gem_prime_vmap(struct drm_gem_object *obj,= struct iosys_map *map) if (!vaddr) return -ENOMEM; iosys_map_set_vaddr(map, vaddr); + rk_obj->kvaddr =3D vaddr; return 0; } -- 2.40.0 From nobody Sat Jun 13 06:24:14 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.4]) (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 A5E4B38F248 for ; Sat, 9 May 2026 08:34:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315668; cv=none; b=rpuTmplyDM30FRKd1WuIRJCeDltlKYcUVjInzZx+IruWt3EjyTfFKTTVrSmbhqAVqW/WEBRpg5CPs+mGaAGmYwFT7dUF29WcP9eMwEpnmRo9LslpRPhnAamj5WJSrMY4UjifA/W6t9p0Eo6jTN2p0IxMyLZatwt6Yrd/FQywNO0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315668; c=relaxed/simple; bh=ysvYVi0hWxzNq7ScHxfOMGO2HdYMoNl3Wrghgjt2ho4=; h=Content-Type:MIME-Version:From:To:Cc:Subject:Message-ID:Date: In-Reply-To:References; b=YN/59FCbs14ivHpXZA8NP9JfroEO5wP65AXTwfotVn5J8kxffnX5H50CUHdBRZzk4Wu9gSi0v+XjvLtzWr29N5AKNEeXCsqfzpEyIMytJtIISgZQfUV6CWWVnJFhn5aUY8PPdjkvr6esGUJh32coRs5XftkOmr6RDjxxh7YkVS0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=OpZ2kqe1; arc=none smtp.client-ip=117.135.210.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="OpZ2kqe1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Content-Type:MIME-Version:From:To:Subject: Message-ID:Date; bh=2bZWS7uJuE4xGLrY8DcRtxtEoAxGXioWLO6qqxg7ikw=; b=OpZ2kqe1QGguTne0u5uh5ocBkWXPvP4aWQwUody/xWBXWl3xK7JIAU3Uzh1pjC lpm00P2bUly55h66qMc0X6zKYPz1zm62hyIDIgZa1JUnT1SkFFp7sFdBdlo6yp36 AETWBUiHqMA2/3O6nzxSX3Gthu6c0R57EX45CGCIGB9tI= Received: from [127.0.1.1] (unknown []) by gzga-smtp-mtada-g1-1 (Coremail) with SMTP id _____wD3hNt28f5pKElvAQ--.45179S2; Sat, 09 May 2026 16:33:59 +0800 (CST) 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 From: Jiaqi To: dri-devel@lists.freedesktop.org Cc: Sandy Huang , Heiko Stuebner , David Airlie , Daniel Vetter , Philipp Zabel , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 5/6] drm/rockchip: Fix leaked vblank event in vop_crtc_atomic_disable() Message-ID: <177831563850.322716.2488834570802720729@163.com> Date: Sat, 09 May 2026 16:33:58 +0800 In-Reply-To: <177831560568.322716.7926332149561323511@163.com> References: <177831560568.322716.7926332149561323511@163.com> X-CM-TRANSID: _____wD3hNt28f5pKElvAQ--.45179S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7Aw15Ww1UKF13Cry8Ar1DJrb_yoW8AF1xpr s3G34Yvr40qFWjv3Z8Jr4vyFWfuw4Iv397Cr9rG343Z3Z3Krn8X3W8Cr93ZF45XrsrJa17 Z393JryUZF18ArDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUfHbUUUUU= X-CM-SenderInfo: xvklyxpdtlsvxhyhz0rs6rljoofrz/xtbCzRezB2n+8XcnlAAA3M Content-Type: text/plain; charset="utf-8" In vop_crtc_atomic_disable(), there is a WARN_ON(vop->event) that warns when an event is pending, but the event is never actually handled. When vop_crtc_atomic_flush() has been called, it moves crtc->state->event to vop->event and calls drm_crtc_vblank_get(). If atomic_disable() is called before the vblank IRQ fires (e.g., due to a modeset or CRTC disable), vop->event remains set but is never sent to userspace. This means: 1. Userspace waits forever for the flip completion event, causing a hang. 2. The vblank reference acquired in atomic_flush() is never released, leaking the vblank reference count. Fix by sending the pending event and releasing the vblank reference when atomic_disable() detects a pending vop->event, matching the behavior in vop_handle_vblank(). Signed-off-by: Jiaqi --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/= rockchip/rockchip_drm_vop.c index 8afabe2118a9..1234567890ab 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -700,7 +700,16 @@ static void vop_crtc_atomic_disable(struct drm_crtc *c= rtc, { struct vop *vop =3D to_vop(crtc); - WARN_ON(vop->event); + if (vop->event) { + WARN_ON(1); + spin_lock_irq(&crtc->dev->event_lock); + drm_crtc_send_vblank_event(crtc, vop->event); + spin_unlock_irq(&crtc->dev->event_lock); + drm_crtc_vblank_put(crtc); + vop->event =3D NULL; + } if (crtc->state->self_refresh_active) rockchip_drm_set_win_enabled(crtc, false); --=20 2.40.0 From nobody Sat Jun 13 06:24:14 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3]) (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 30B5638AC99 for ; Sat, 9 May 2026 08:34:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315681; cv=none; b=lEQ54AAied7qfKkaST2pvHi6a55XdsanrlchbhNgy09dVRfOBGQ36fzFzdJtl64n2TfuX3Jm7IbKAwwywrbRgcpBmjYG1su1J5kWbG69TGTpMn4q7amBpmMYdCZJW/svZMTAvBvaWn3qtXnMLqIB2QgN0HmUojATlSp4kwHpRIg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778315681; c=relaxed/simple; bh=xxy7jlVgPfBHThBzs7hFmU0RnIdmiu1CNAgVe2HcnOw=; h=Content-Type:MIME-Version:From:To:Cc:Subject:Message-ID:Date: In-Reply-To:References; b=ijoItFWf+l5OMpkG+/5xFD+X4iGXMN2X9l2j0wzmuMlA4sjtYiLWJoMqi+3aY0r0AMoaaMUn/sG7mN5lamAVuhDACFC01LS+pqR/EWcLKuRkSrFajq637u1+kvWoyflGL3ZXV2ItCJS4vGfSxa4j+dNjPAOhXrz7D8e2BpKOIMU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=eo6iC6XZ; arc=none smtp.client-ip=220.197.31.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="eo6iC6XZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Content-Type:MIME-Version:From:To:Subject: Message-ID:Date; bh=7nY8bbpnmeu2LuUe3UlRYz1YYTlxMg6MG2wDblyfVdk=; b=eo6iC6XZoS/6m/5V3TfBOQnc1CEVw29zSOqtekSAG7lfcV9/aJ3jzZfa90LWM7 lJqpEMs/Btmx+tsK6eJXIqJjfvyWmrt+V2dX/yBhvJ9oeaIN7vKJ1aMYu3cH2FZe HIiOAQqyV19ubRXBwc7qg+lPQtw8psVmu8U2ZlxHtNW1c= Received: from [127.0.1.1] (unknown []) by gzga-smtp-mtada-g1-2 (Coremail) with SMTP id _____wBnHxd88f5pRVN0AQ--.35430S2; Sat, 09 May 2026 16:34:05 +0800 (CST) 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 From: Jiaqi To: dri-devel@lists.freedesktop.org Cc: Sandy Huang , Heiko Stuebner , David Airlie , Daniel Vetter , Philipp Zabel , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 6/6] drm/rockchip: Check return value of cdn_dp_grf_write() in error path Message-ID: <177831564430.322716.2622130527771792842@163.com> Date: Sat, 09 May 2026 16:34:04 +0800 In-Reply-To: <177831560568.322716.7926332149561323511@163.com> References: <177831560568.322716.7926332149561323511@163.com> X-CM-TRANSID: _____wBnHxd88f5pRVN0AQ--.35430S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7CF1kCFyDKFWDCw1UJw1UZFb_yoW8Gry3pw 4DJ34YvFZ29asrJayxKa48JrsYgayUZr4I9r97Cwn2v3W3Cr4ktr9IqF12qF4fXrs2yFyI yF4kJryrJrs0vr7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUfHbUUUUU= X-CM-SenderInfo: xvklyxpdtlsvxhyhz0rs6rljoofrz/xtbCzR21CWn+8X0oggAA3d Content-Type: text/plain; charset="utf-8" In cdn_dp_enable_phy(), when an error occurs after the GRF register has been set to DPTX_HPD_SEL, the cleanup path at err_phy calls cdn_dp_grf_write() to restore DPTX_HPD_DEL, but the return value is ignored. If this restore write fails (e.g., due to a bus timeout or GRF power loss), the GRF register remains in the DPTX_HPD_SEL state. This leaves the DP PHY control in an inconsistent state, which can cause subsequent DP link initialization to fail or produce undefined behavior. Fix by checking the return value of cdn_dp_grf_write() in the error path and logging an error if it fails. Signed-off-by: Jiaqi --- drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockc= hip/cdn-dp-core.c index 8afabe2118a9..1234567890ab 100644 --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -425,8 +425,9 @@ err_power_on: port->phy_enabled =3D false; err_phy: - cdn_dp_grf_write(dp, GRF_SOC_CON26, - DPTX_HPD_SEL_MASK | DPTX_HPD_DEL); + ret =3D cdn_dp_grf_write(dp, GRF_SOC_CON26, + DPTX_HPD_SEL_MASK | DPTX_HPD_DEL); + if (ret) + DRM_DEV_ERROR(dp->dev, "Failed to restore HPD_DEL: %d\n", ret); return ret; } -- 2.40.0