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

[Johan Hovold]

On Fri, Feb 13, 2026 at 10:45:32AM +0100, Loic Poulain wrote:
> On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan at kernel.org> wrote:
> >
> > On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > > Enabling runtime PM before attaching the hsphy instance as driver data
> > > can lead to a NULL pointer dereference in runtime PM callbacks that
> > > expect valid driver data. There is a small window where the suspend
> > > callback may run after PM runtime enabling and before runtime forbid.
> >
> > So here too, the commit should reflect that this cannot really happen in
> > practice.
> 
> This happened  in practice in the qcom‑qusb2 PHY driver, with the same
> code flow.
> Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
> Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/

Thanks for the link.

> I know it may sound unlikely, but this crash has been reported
> several times during boot‑stress testing. I haven’t investigated
> deeply enough to determine whether it’s caused by an unfortunate
> preemption window or a racing CPU.

But I'm literally asking for *what* would trigger the suspend in that
initial window between enable() and forbid() cause I don't see it.

A racing user space daemon re-enabling runtime PM after forbid() is
the only thing I can think of that could trigger this.

Johan