From: Sven Peter <sven@kernel.org>
To: Jacob Procee <sn125164@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Janne Grunau <j@jannau.net>
Subject: Re: [PATCH v2] usb: typec: tipd: cd321x: replay the plug on resume
Date: Sat, 14 Nov 2026 13:39:17 +0100 [thread overview]
Message-ID: <3a3f5721-dc37-41d1-8ef5-9a5fdbecc446@kernel.org> (raw)
In-Reply-To: <20261112122825.7730-1-sn125164@gmail.com>
On 11/12/26 13:28, Jacob Procee wrote:
> On Apple Silicon the Type-C PHY and the dwc3 controller behind a CD321x
> port lose their state during s2idle while the plug stays connected, and
> the CD321x does not raise an interrupt on resume. xhci notices the lost
> state and re-initializes the host controller:
>
> xhci-hcd xhci-hcd.0.auto: xHC error in resume, USBSTS 0x401, Reinit
> usb usb1: root hub lost power or was reset
> usb 1-1: USB disconnect, device number 2
>
> but the PHY is only ever programmed from typec_mux_set(), so a device
> left plugged in (here a FIDO2 security key) never comes back until it is
> unplugged and plugged in again.
>
> Re-initializing only dwc3 after resume does not work: tearing dwc3 down
> also powers off the PHY, and nothing turns it back on, so xhci then
> times out ("Host halt failed, -110", "can't setup: -110").
>
> Instead, make cd321x replay the plug on resume when a partner was
> connected: mark the plug as changed and queue the update work, which
> then goes through the same sequence as a real replug (role none, mux
> safe, mux back to the partner's mode, role back on). Queue the update
> work on system_freezable_wq, from the interrupt path as well, so that no
> update runs before all devices have resumed and the work item is only
> ever queued on one workqueue.
>
> Tested on a 14" MacBook Pro (M1 Pro, j314s) with a backport of this
> change to the Asahi 7.3.3 kernel: a USB-C security key left plugged in
> re-enumerates right after "PM: suspend exit", where it previously stayed
> gone until replugged. Unplugging the device while the system is asleep
> also works: after resume the role goes to none, nothing is brought back
> up, and replugging it later enumerates normally. Booting with the key
> plugged in and replugging it while awake also still work. This mainline
> version was build-tested only (W=1, checkpatch --strict clean).
>
> Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x")
> Assisted-by: LLM
> Signed-off-by: Jacob Procee <sn125164@gmail.com>
> ---
Nah, making suspend/resume work isn't the job of the type-c controller.
next prev parent reply other threads:[~2026-11-14 12:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 12:28 [PATCH v2] usb: typec: tipd: cd321x: replay the plug on resume Jacob Procee
2026-11-12 12:43 ` sashiko-bot
2026-11-14 12:39 ` Sven Peter [this message]
2026-11-14 13:00 ` Jacob Procee
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=3a3f5721-dc37-41d1-8ef5-9a5fdbecc446@kernel.org \
--to=sven@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=j@jannau.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sn125164@gmail.com \
/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