[PATCH v2 2/6] phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend

[Loic Poulain]

On Thu, Jan 22, 2026 at 4:00 PM Konrad Dybcio
<konrad.dybcio at oss.qualcomm.com> wrote:
>
> On 1/21/26 3:28 PM, Loic Poulain wrote:
> > There is a small window where the runtime suspend callback may run
> > after pm_runtime_enable() and before pm_runtime_forbid(). In this
> > case, a crash occurs because runtime suspend/resume dereferences
> > qmp->phy pointer, which is not yet initialized:
> >     `if (!qmp->phy->init_count) {`
> >
> > This can also occur if user re-enables runtime-pm via the sysfs
> > attribute before qmp phy is initialized.
> >
> > Use qmp->usb_init_count instead of qmp->phy->init_count to avoid
> > depending on the possibly uninitialized phy pointer.
> >
> > Fixes: 19281571a4d5 ("phy: qcom: qmp-usb: split USB-C PHY driver")
> > Signed-off-by: Loic Poulain <loic.poulain at oss.qualcomm.com>
> > ---
> >  drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> > index 5e7fcb26744a..edfaa14db967 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> > @@ -690,7 +690,7 @@ static int __maybe_unused qmp_usbc_runtime_suspend(struct device *dev)
> >
> >       dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
> >
> > -     if (!qmp->phy->init_count) {
> > +     if (!qmp->usb_init_count) {
>
> This function changed a month ago, please rebase against next
>
> Although I believe this patch becomes unnecessary with 3 in the picture.

Thanks. I can indeed remove this patch from the series

> I suppose the case that you mention in the commit message, however
> improbable, could be fixed by moving the pm call to after devm_phy_create

For whatever scheduling effect, this behavior has been seen quite
regularly (~1/50 boots) during stress‑test scenarios with other PHY
driver (qcom-qusb2).

As Dmitry noted earlier, PM must be enabled before calling
devm_phy_create(), because phy_create() relies on the PM‑enabled state
to configure its own runtime PM behavior.

>
> Although we'd then rely on devlink to make sure a consumer doesn't snatch
> the reference halfway through .probe...
>
> Konrad

Cheers,
Loic