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

[Loic Poulain]

On Mon, Feb 16, 2026 at 11:48 AM Johan Hovold <johan at kernel.org> wrote:
>
> 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.

Ok, yes, using the usual pm_runtime_get_noresume() before enabling
runtime PM would work as well. This is conceptually similar to this
change, which instead relies on pm_runtime_forbid(). However, I agree
that forbid provides no guarantee about when runtime PM may be
re-enabled by a user...

Regards,
Loic