Message ID | 20240217150228.5788-6-johan+linaro@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-69921-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp364550dyc; Sat, 17 Feb 2024 07:05:09 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXrJKw7wLdbKnTm3rtCJkZbV2ab12wKLNqUu1FcYwsq2xS9aJeedZG6CWt5Be0wcEH9qokXj5gFUePPmgRlj5WGG2XJ0Q== X-Google-Smtp-Source: AGHT+IEg1iq37MNSS7vsMfCqPD9EA9UREjs6FyEtHDMkOzQTKc/8o2rAJ6amGj7bFtg6e1tbUrSu X-Received: by 2002:a05:6a00:180d:b0:6e0:a559:d667 with SMTP id y13-20020a056a00180d00b006e0a559d667mr10133971pfa.27.1708182308951; Sat, 17 Feb 2024 07:05:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708182308; cv=pass; d=google.com; s=arc-20160816; b=himGdoU08zmTjZVfNsW+WZO3S9nH//lOrHwTbr3Dd1dBkvsq4uaqgtMjYuu2QJ+XqJ DZjsDH026wz1O6yihIh8piW77YsIpFAV4UJG0Glbuo52VmRUw0yoaQkTIrsdZZ3qKO4N 5QHnNNBBpiAMmGsTe6rL8rSDyZrU6ETgP596zDdcyfKSKer/qP3RJ2rJYD08RnIsBLHZ 1AZbi73dIc2eKpmeEUMNWcFlPjx0JZciyoTHRD4kQRRcHo0iH/sqvpLtFWmhddmwRrx5 GbSNrayNLX0Hk+p+N7sLUmws536tB9gIIIPzEcbnIowCG3X5gl9HFLNtC4CiZ0LGNbYY ujjA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=o0a25HtfcPJejsy1uDB1LRVcNybTZPlBxiOl/ey4334=; fh=Hl8lnpz4ISbBsnoeQao/t6wY6CVeFI0lIzv3X7tdDqA=; b=CQoRdZiDF4s+q11CW+A+h6PpgP3CevGtJqOgXsJ3v0n1Ohk81vg4lKOe3BcmUnPcqk UwO5q00axcKcejTHAuKZ2KMAVqzYucKxm2B0krpalIoIu6dFhZFb7Ga81q/yeiWHt/aB zD73A64NPLaO90BoL40FyuVgYt7C9bJ95iMfRbIIMMLFo9xzNcmFF9EMiG5w6fDCwpZS EHr/4MJdY5eIWRH0V8F/6puPf+eXe8i492CIXwVZT9aRlk2Ai1sNtKZBoTowKKiLPn9c Yy+rxhCt9/VcQVOjDPgGHi3MRuoXQF9CqKx2KVNy2zmsRLhuE73UTuuvaMtywf7AxWIy 3ThQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YYCrcRG2; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-69921-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69921-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id m6-20020a632606000000b005dc956c2c09si1632124pgm.147.2024.02.17.07.05.08 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Feb 2024 07:05:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-69921-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YYCrcRG2; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-69921-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69921-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 9231BB22563 for <ouuuleilei@gmail.com>; Sat, 17 Feb 2024 15:04:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 437DF7D410; Sat, 17 Feb 2024 15:03:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YYCrcRG2" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 6C5CA7B3D0; Sat, 17 Feb 2024 15:03:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708182183; cv=none; b=PMggC/IGKfVt4fITT+X9KR3YntsvIBOAlljdQTwpxYKXpxUx7TW3d8s/JFGuUMAjNuYY8hELxAzxq2f4MU6KBsO6zozdMezxR1tBGPyQ63SNR6ZLLizBX+1ux36AUNi5KjSLv1vwHK4XP9HBxSU5hRlSUAEahMMohrzjbZWq3H4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708182183; c=relaxed/simple; bh=gXXEjah83df2mjIZE6PBMMf9QLss5RTOxJWznY2GGWw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CkLjS7Tarl/0VQ5x/BLpigBRZzt4Zl1pzWFTd2D+fDLf7Tr5B5zt+u4GC7g1R7p9WpJb3rgSkToLfq8/VDLV43bFUq+X5Aww53c+xf4Bg6CuRRucJ0NuXaFmp7C5LRnwt7nWmJjtLMFb6VL9qsXAAVUXbWizRi34mxmFkNwKZFc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YYCrcRG2; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D7A2C43394; Sat, 17 Feb 2024 15:03:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708182183; bh=gXXEjah83df2mjIZE6PBMMf9QLss5RTOxJWznY2GGWw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YYCrcRG2Bd4HtdSjVhBFoyvNHGakjwLypXKacKIBHXJrLfhpQut/AO/LcBQ3Y0KjF sPdXqHSXykK74eTVnJeNok7niPfXO0Czt/1YPR768rWKLabFR6u9U6X5zIoNHXtfCO USZHcA9Rm8QSNKTbGnvdNY/kIjWyg4w+1ZXDETyizCJSpTAN1qQacxjTa7UDJF9A2O msphIG/8uQP28WXSj7qoecFU1NmlhQEAP7CJjIeye7CoVAI4y/049aiTpZjWH59Xcd XI5S8l0Qbk9Ya0xxP0z0xuzlJ6QUvVP0P3e4nAwJAmqIZ/HBGy+WfJdIV0A5NlROZa yxMde5QWQVT1A== Received: from johan by xi.lan with local (Exim 4.97.1) (envelope-from <johan+linaro@kernel.org>) id 1rbMDW-000000001Vw-3n8S; Sat, 17 Feb 2024 16:03:02 +0100 From: Johan Hovold <johan+linaro@kernel.org> To: Bjorn Andersson <andersson@kernel.org>, Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Vinod Koul <vkoul@kernel.org> Cc: Jonas Karlman <jonas@kwiboo.se>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jernej Skrabec <jernej.skrabec@gmail.com>, Konrad Dybcio <konrad.dybcio@linaro.org>, Kishon Vijay Abraham I <kishon@kernel.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Rob Clark <robdclark@gmail.com>, Abhinav Kumar <quic_abhinavk@quicinc.com>, Kuogee Hsieh <quic_khsieh@quicinc.com>, freedreno@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, Johan Hovold <johan+linaro@kernel.org>, stable@vger.kernel.org, Bjorn Andersson <quic_bjorande@quicinc.com> Subject: [PATCH 5/6] phy: qcom-qmp-combo: fix drm bridge registration Date: Sat, 17 Feb 2024 16:02:27 +0100 Message-ID: <20240217150228.5788-6-johan+linaro@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240217150228.5788-1-johan+linaro@kernel.org> References: <20240217150228.5788-1-johan+linaro@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791158972733410311 X-GMAIL-MSGID: 1791158972733410311 |
Series |
soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
|
|
Commit Message
Johan Hovold
Feb. 17, 2024, 3:02 p.m. UTC
Due to a long-standing issue in driver core, drivers may not probe defer
after having registered child devices to avoid triggering a probe
deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
-EPROBE_DEFER")).
This could potentially also trigger a bug in the DRM bridge
implementation which does not expect bridges to go away even if device
links may avoid triggering this (when enabled).
Move registration of the DRM aux bridge to after looking up clocks and
other resources.
Note that PHY creation can in theory also trigger a probe deferral when
a 'phy' supply is used. This does not seem to affect the QMP PHY driver
but the PHY subsystem should be reworked to address this (i.e. by
separating initialisation and registration of the PHY).
Fixes: 35921910bbd0 ("phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE")
Fixes: 1904c3f578dc ("phy: qcom-qmp-combo: Introduce drm_bridge")
Cc: stable@vger.kernel.org # 6.5
Cc: Bjorn Andersson <quic_bjorande@quicinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Comments
On 17/02/2024 16:02, Johan Hovold wrote: > Due to a long-standing issue in driver core, drivers may not probe defer > after having registered child devices to avoid triggering a probe > deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of > -EPROBE_DEFER")). > > This could potentially also trigger a bug in the DRM bridge > implementation which does not expect bridges to go away even if device > links may avoid triggering this (when enabled). > > Move registration of the DRM aux bridge to after looking up clocks and > other resources. > > Note that PHY creation can in theory also trigger a probe deferral when > a 'phy' supply is used. This does not seem to affect the QMP PHY driver > but the PHY subsystem should be reworked to address this (i.e. by > separating initialisation and registration of the PHY). > > Fixes: 35921910bbd0 ("phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE") > Fixes: 1904c3f578dc ("phy: qcom-qmp-combo: Introduce drm_bridge") > Cc: stable@vger.kernel.org # 6.5 > Cc: Bjorn Andersson <quic_bjorande@quicinc.com> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> > --- > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > index 1ad10110dd25..e19d6a084f10 100644 > --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > @@ -3566,10 +3566,6 @@ static int qmp_combo_probe(struct platform_device *pdev) > if (ret) > return ret; > > - ret = drm_aux_bridge_register(dev); > - if (ret) > - return ret; > - > /* Check for legacy binding with child nodes. */ > usb_np = of_get_child_by_name(dev->of_node, "usb3-phy"); > if (usb_np) { > @@ -3589,6 +3585,10 @@ static int qmp_combo_probe(struct platform_device *pdev) > if (ret) > goto err_node_put; > > + ret = drm_aux_bridge_register(dev); > + if (ret) > + goto err_node_put; > + > pm_runtime_set_active(dev); > ret = devm_pm_runtime_enable(dev); > if (ret) Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
On Sat, Feb 17, 2024 at 04:02:27PM +0100, Johan Hovold wrote: > Due to a long-standing issue in driver core, drivers may not probe defer > after having registered child devices to avoid triggering a probe > deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of > -EPROBE_DEFER")). > > This could potentially also trigger a bug in the DRM bridge > implementation which does not expect bridges to go away even if device > links may avoid triggering this (when enabled). > > Move registration of the DRM aux bridge to after looking up clocks and > other resources. > > Note that PHY creation can in theory also trigger a probe deferral when > a 'phy' supply is used. This does not seem to affect the QMP PHY driver > but the PHY subsystem should be reworked to address this (i.e. by > separating initialisation and registration of the PHY). > > Fixes: 35921910bbd0 ("phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE") > Fixes: 1904c3f578dc ("phy: qcom-qmp-combo: Introduce drm_bridge") > Cc: stable@vger.kernel.org # 6.5 > Cc: Bjorn Andersson <quic_bjorande@quicinc.com> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Regards, Bjorn > --- > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > index 1ad10110dd25..e19d6a084f10 100644 > --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > @@ -3566,10 +3566,6 @@ static int qmp_combo_probe(struct platform_device *pdev) > if (ret) > return ret; > > - ret = drm_aux_bridge_register(dev); > - if (ret) > - return ret; > - > /* Check for legacy binding with child nodes. */ > usb_np = of_get_child_by_name(dev->of_node, "usb3-phy"); > if (usb_np) { > @@ -3589,6 +3585,10 @@ static int qmp_combo_probe(struct platform_device *pdev) > if (ret) > goto err_node_put; > > + ret = drm_aux_bridge_register(dev); > + if (ret) > + goto err_node_put; > + > pm_runtime_set_active(dev); > ret = devm_pm_runtime_enable(dev); > if (ret) > -- > 2.43.0 >
On Sat, 17 Feb 2024 at 17:03, Johan Hovold <johan+linaro@kernel.org> wrote: > > Due to a long-standing issue in driver core, drivers may not probe defer > after having registered child devices to avoid triggering a probe > deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of > -EPROBE_DEFER")). > > This could potentially also trigger a bug in the DRM bridge > implementation which does not expect bridges to go away even if device > links may avoid triggering this (when enabled). > > Move registration of the DRM aux bridge to after looking up clocks and > other resources. > > Note that PHY creation can in theory also trigger a probe deferral when > a 'phy' supply is used. This does not seem to affect the QMP PHY driver > but the PHY subsystem should be reworked to address this (i.e. by > separating initialisation and registration of the PHY). > > Fixes: 35921910bbd0 ("phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE") > Fixes: 1904c3f578dc ("phy: qcom-qmp-combo: Introduce drm_bridge") > Cc: stable@vger.kernel.org # 6.5 > Cc: Bjorn Andersson <quic_bjorande@quicinc.com> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> > --- > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
On 17-02-24, 16:02, Johan Hovold wrote: > Due to a long-standing issue in driver core, drivers may not probe defer > after having registered child devices to avoid triggering a probe > deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of > -EPROBE_DEFER")). > > This could potentially also trigger a bug in the DRM bridge > implementation which does not expect bridges to go away even if device > links may avoid triggering this (when enabled). > > Move registration of the DRM aux bridge to after looking up clocks and > other resources. > > Note that PHY creation can in theory also trigger a probe deferral when > a 'phy' supply is used. This does not seem to affect the QMP PHY driver > but the PHY subsystem should be reworked to address this (i.e. by > separating initialisation and registration of the PHY). Acked-by: Vinod Koul <vkoul@kernel.org>
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c index 1ad10110dd25..e19d6a084f10 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c @@ -3566,10 +3566,6 @@ static int qmp_combo_probe(struct platform_device *pdev) if (ret) return ret; - ret = drm_aux_bridge_register(dev); - if (ret) - return ret; - /* Check for legacy binding with child nodes. */ usb_np = of_get_child_by_name(dev->of_node, "usb3-phy"); if (usb_np) { @@ -3589,6 +3585,10 @@ static int qmp_combo_probe(struct platform_device *pdev) if (ret) goto err_node_put; + ret = drm_aux_bridge_register(dev); + if (ret) + goto err_node_put; + pm_runtime_set_active(dev); ret = devm_pm_runtime_enable(dev); if (ret)