From patchwork Fri Feb 25 13:45:03 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Ricardo_Ca=C3=B1uelo?= X-Patchwork-Id: 12760363 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 980EFC433EF for ; Fri, 25 Feb 2022 13:55:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=V2kx2/G84xlpcWK+TahXIXZ93px5tEJRcGb5NCfcFVE=; b=iN91tAj+gXL3Rx RBUqJoEE1Bg5af1e75AfvKt+IrpSj97L+n2Cgqgp4NJKlJ60agrG0Vjbw63+JJBQhx2MbfpjT4F6j tMK0bZ7v4Pek4Tk7AHbpxpA+eLV3nKuDCTiQTZ7drJCGGRYDC/Q7O5PkNMB0uNkwa7pu7HyGNZkpO nMX96+bEMUFbOEga00x2V9YOHBD+BWfGTmzu3dSgOniQVtYvtoq8b9Ul4GbNCioyWd2kla8qzx2D+ XoROFcS8xM1OlgUBtj4XpZ8nM9au+Kq1UoE2UWdewO9XIo6G0fU/7eHV20fVaBeKwQZzN4z0+v3FF r014F2hY13fi1In56GNw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNb3o-005GPD-QS; Fri, 25 Feb 2022 13:55:04 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNaum-005DEG-DU for linux-mediatek@lists.infradead.org; Fri, 25 Feb 2022 13:45:46 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: rcn) with ESMTPSA id 7A6AF1F45F92 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1645796741; bh=PEG3axVN//YyYVluyyyZUdTkTfte6RZExlKRrKGNNGg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V/oym2rKqKgD8WS1WPUP98b3I3JMruzcQzkNhu3PgRNVN3ZTTJw+3GtVTL7aQoSOC ptLBuP3f9+pjoz9+9FnrgPRUlPo8VUleDaWCGLiwJzBpw/YoZOPgnqe50SuZ7CI3JM cBm7FrVwATP5cHVP41V99XezDyNEe+JLDXvRQJT3FOB6nF4qJGptcikBkNbiOeKqrq cYst4IN9RE4IHAGzU7XZe4bZk0uzpZw6GGOlQiX6xQ8R2LTgwiYm/vHddpjkOwekzs 5rJVyJdqyqIFY/UJ48Ojz3PCzr+Plzv/pWZts6M45eVOhHQ9qPvjsnEhpEV4N01hB+ hqRo5dsRtjmaQ== From: =?utf-8?q?Ricardo_Ca=C3=B1uelo?= To: dri-devel@lists.freedesktop.org Cc: =?utf-8?q?Ricardo_Ca=C3=B1uelo?= , linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, kernel@collabora.com, andrzej.hajda@intel.com, narmstrong@baylibre.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org Subject: [PATCH 1/2] drm/bridge: parade-ps8640: avoid race condition on driver unbinding Date: Fri, 25 Feb 2022 14:45:03 +0100 Message-Id: <20220225134504.457245-2-ricardo.canuelo@collabora.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220225134504.457245-1-ricardo.canuelo@collabora.com> References: <20220225134504.457245-1-ricardo.canuelo@collabora.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220225_054544_672215_98C71B83 X-CRM114-Status: GOOD ( 13.10 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org When unbinding a DRM master driver there's a race condition that sometimes results in an invalid vm access when userspace (gnome-shell) issues a DRM_IOCTL_MODE_GETCONNECTOR ioctl right after a bridge has been removed from an encoder's bridge chain. This means that once a bridge has been disabled and gone through ps8640_post_disable(), if ps8640_bridge_get_edid() runs afterwards as a result of that ioctl call it will call drm_bridge_chain_pre_enable() and drm_bridge_chain_post_disable() again in a bridge that has been already detached. Setting `ps_bridge->pre_enabled = false` at a later stage of the bringdown path and calling drm_bridge_chain_pre_enable() inside ps8640_bridge_get_edid() only if needed avoid this, although a proper subsystem-wide fix would be the proper solution, since the same type of race conditions might happen somewhere else. Tested on an Acer Chromebook R13 (Elm, MT8173) with Debian Sid. Signed-off-by: Ricardo Cañuelo --- drivers/gpu/drm/bridge/parade-ps8640.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index 3f17337ee389..a927787a89bf 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -434,8 +434,6 @@ static void ps8640_post_disable(struct drm_bridge *bridge) { struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); - ps_bridge->pre_enabled = false; - ps8640_bridge_vdo_control(ps_bridge, DISABLE); pm_runtime_put_sync_suspend(&ps_bridge->page[PAGE0_DP_CNTL]->dev); } @@ -487,6 +485,7 @@ static void ps8640_bridge_detach(struct drm_bridge *bridge) drm_dp_aux_unregister(&ps_bridge->aux); if (ps_bridge->link) device_link_del(ps_bridge->link); + ps_bridge->pre_enabled = false; } static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge, @@ -508,7 +507,8 @@ static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge, * EDID, for this chip, we need to do a full poweron, otherwise it will * fail. */ - drm_bridge_chain_pre_enable(bridge); + if (poweroff) + drm_bridge_chain_pre_enable(bridge); edid = drm_get_edid(connector, ps_bridge->page[PAGE0_DP_CNTL]->adapter);