Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend

From: Johan Hovold <johan@kernel.org>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Loic Poulain <loic.poulain@oss.qualcomm.com>,
	vkoul@kernel.org, kishon@kernel.org,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	dmitry.baryshkov@oss.qualcomm.com, neil.armstrong@linaro.org,
	konrad.dybcio@oss.qualcomm.com,
	Abel Vesa <abel.vesa@oss.qualcomm.com>
Subject: Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
Date: Mon, 16 Feb 2026 11:47:54 +0100	[thread overview]
Message-ID: <aZL12oyiLumpf39e@hovoldconsulting.com> (raw)
In-Reply-To: <20260213201550.vk5cosmoewokarlx@skbuf>

On Fri, Feb 13, 2026 at 10:15:50PM +0200, Vladimir Oltean wrote:

> Another comment upon reviewing this driver's runtime PM use (although
> this is at most something that may result in a patch for "next"):
> 
> This driver uses hsphy->phy_initialized to make sure qcom_snps_hsphy_suspend()
> isn't called unless qcom_snps_hsphy_init() was called.
> 
> Don't we achieve the same behaviour by replacing "hsphy->phy_initialized = true"
> with pm_runtime_get_sync(dev) and "hsphy->phy_initialized = false" with
> pm_runtime_put(dev)?

No, the device can still suspend before phy_init() is called.

What would work, and which should probably be preferred over adding
these phy_initialized flags, is to increment the pm usage counter before
enabling runtime pm and decrementing it after the PHY has been created.

Johan