[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXTbpd6k=_yF4vG-zU4C0ymriLYXcT4AusCFJ03wZWJecOS5w@mail.gmail.com>
Date: Wed, 10 Sep 2025 20:43:45 +0800
From: Pin-yen Lin <treapking@...omium.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Len Brown <lenb@...nel.org>, Pavel Machek <pavel@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Danilo Krummrich <dakr@...nel.org>,
Saravana Kannan <saravanak@...gle.com>, Hsin-Te Yuan <yuanhsinte@...omium.org>,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
Chen-Yu Tsai <wenst@...omium.org>
Subject: Re: [PATCH] PM: sleep: Don't wait for SYNC_STATE_ONLY device links
Hi Rafael,
Thanks for the review.
On Wed, Sep 10, 2025 at 7:56 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Tue, Sep 9, 2025 at 11:44 AM Pin-yen Lin <treapking@...omium.org> wrote:
> >
> > Device links with DL_FLAG_SYNC_STATE_ONLY should not affect suspend
> > and resume, and functions like device_reorder_to_tail() and
> > device_link_add() doesn't try to reorder the consumers with such flag.
> >
> > However, dpm_wait_for_consumers() and dpm_wait_for_suppliers() doesn't
> > check this flag before triggering dpm_wait, leading to potential hang
> > during suspend/resume.
>
> Have you seen this happen or is it just a theory?
We initially see this with a downstream kernel, but I can reproduce
this with the upstream kernel when I connect the usb host controller
to a "usb-a-connector" node on MT8186 Corsola Chromebook. The
devicetree looks like:
usb-a-connector {
compatible = "usb-a-connector";
port {
usb_a_con: endpoint {
remote-endpoint = <&usb_hs>;
};
};
};
usb_host {
compatible = "mediatek,mt8186-xhci", "mediatek,mtk-xhci";
port {
usb_hs: endpoint {
remote-endpoint = <&usb_a_con>;
};
};
};
In this case, the two nodes form a cycle and I ended up seeing a
SYNC_STATE_ONLY devlink from usb_host (supplier) to the
usb-a-connector (consumer).
I'm not very sure why we didn't see this issue before. Maybe it's
related to the fact that the usb-a-connector has a compatible string
(so a platform device is created) but no driver binds into it.
>
> > Add DL_FLAG_SYNC_STATE_ONLY in dpm_wait_for_consumers() and
> > dpm_wait_for_suppliers() to fix this.
>
> The above sentence is incomplete AFAICS.
Sorry, I meant "Add a check for DL_FLAG_SYNC_STATE_ONLY in ...". I'll
update this in the next version.
>
> > Fixes: 05ef983e0d65a ("driver core: Add device link support for SYNC_STATE_ONLY flag")
> > Signed-off-by: Pin-yen Lin <treapking@...omium.org>
> > ---
> >
> > drivers/base/power/main.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > index 2ea6e05e6ec90..3271f4af2cb65 100644
> > --- a/drivers/base/power/main.c
> > +++ b/drivers/base/power/main.c
> > @@ -282,7 +282,8 @@ static void dpm_wait_for_suppliers(struct device *dev, bool async)
> > * walking.
> > */
> > list_for_each_entry_rcu_locked(link, &dev->links.suppliers, c_node)
> > - if (READ_ONCE(link->status) != DL_STATE_DORMANT)
> > + if (READ_ONCE(link->status) != DL_STATE_DORMANT &&
> > + !device_link_test(link, DL_FLAG_SYNC_STATE_ONLY))
>
> This should use a check like device_link_flag_is_sync_state_only(),
> which is different from the above one, for consistency with
> device_reorder_to_tail().
Thanks. I'll fix this in the next version.
>
> > dpm_wait(link->supplier, async);
> >
> > device_links_read_unlock(idx);
> > @@ -339,7 +340,8 @@ static void dpm_wait_for_consumers(struct device *dev, bool async)
> > * unregistration).
> > */
> > list_for_each_entry_rcu_locked(link, &dev->links.consumers, s_node)
> > - if (READ_ONCE(link->status) != DL_STATE_DORMANT)
> > + if (READ_ONCE(link->status) != DL_STATE_DORMANT &&
> > + !device_link_test(link, DL_FLAG_SYNC_STATE_ONLY))
>
> And same here.
>
> > dpm_wait(link->consumer, async);
> >
> > device_links_read_unlock(idx);
> > --
Regards,
Pin-yen
Powered by blists - more mailing lists