From: Johan Hovold <johan@kernel.org>
To: Loic Poulain <loic.poulain@oss.qualcomm.com>
Cc: 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:41:38 +0100 [thread overview]
Message-ID: <aZL0YhiDcUwKaIz4@hovoldconsulting.com> (raw)
In-Reply-To: <CAFEp6-0rzkqc0ajN72q=mv3U-TT0JHMSPmnJD6ohKuLmbPz2-A@mail.gmail.com>
On Fri, Feb 13, 2026 at 04:04:43PM +0100, Loic Poulain wrote:
> On Fri, Feb 13, 2026 at 11:45 AM Johan Hovold <johan@kernel.org> wrote:
> > 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.
>
> To be honest, I had not initially looked into the exact cause of the
> suspend trigger until now, but here is what is happening.
>
> The PHY is a supplier of the USB device. A USB device cannot be probed
> until all its suppliers are ready. As long as the PHY is not ready, the
> device core keeps retrying the probe, which fails with -EPROBE_DEFER.
>
> At some point the PHY probe finally runs, but the device core may still be
> attempting to probe the USB device concurrently.
>
> Inside __driver_probe_device(), we have:
>
> ret = really_probe(dev, drv);
> pm_request_idle(dev);
>
> if (dev->parent)
> pm_runtime_put(dev->parent);
>
> pm_runtime_put_suppliers(dev);
> return ret;
>
> This means that whenever a USB probe attempt completes, whether with an
> error or not, its suppliers are released via pm_runtime_put_suppliers().
> Releasing suppliers may in turn trigger a runtime suspend.
>
> In our case, since the PHY is a supplier of the USB device, the USB core
> keeps 'looping' in __driver_probe_device() returning -EPROBE_DEFER until
> the PHY becomes ready. As a result, pm_runtime_put_suppliers() may run
> concurrently with the PHY's probe function. If this happens after
> runtime PM has been enabled for the PHY, but before the driver has
> forbidden suspend or taken a PM reference, the PHY may end up being
> runtime-suspended 'unexpectedly'.
Thanks for tracking that down. That's an unexpected side effect of
fw_devlink adding runtime pm enabled links (which is the default
behaviour since late 2023).
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
prev parent reply other threads:[~2026-02-16 10:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-05 16:02 [PATCH v3 0/5] phy: qcom: Fix possible NULL-deref and runtime PM race conditions Loic Poulain
2026-02-05 16:02 ` [PATCH v3 1/5] phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot Loic Poulain
2026-02-13 8:47 ` Johan Hovold
2026-02-05 16:02 ` [PATCH v3 2/5] phy: qcom: qmp-usbc: " Loic Poulain
2026-02-09 13:18 ` Dmitry Baryshkov
2026-02-05 16:02 ` [PATCH v3 3/5] phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend Loic Poulain
2026-02-09 13:18 ` Dmitry Baryshkov
2026-02-13 9:02 ` Johan Hovold
2026-02-05 16:02 ` [PATCH v3 4/5] phy: qcom: qmp-usb-legacy: Prevent unnecessary PM runtime suspend at boot Loic Poulain
2026-02-09 13:18 ` Dmitry Baryshkov
2026-02-05 16:02 ` [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Loic Poulain
2026-02-13 9:07 ` Johan Hovold
2026-02-13 9:45 ` Loic Poulain
2026-02-13 10:45 ` Johan Hovold
2026-02-13 15:04 ` Loic Poulain
2026-02-13 20:15 ` Vladimir Oltean
2026-02-16 10:47 ` Johan Hovold
2026-02-17 10:40 ` Loic Poulain
2026-02-16 10:41 ` Johan Hovold [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZL0YhiDcUwKaIz4@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=abel.vesa@oss.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=kishon@kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=loic.poulain@oss.qualcomm.com \
--cc=neil.armstrong@linaro.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox