Fix/atcphy pipehandler#503
Open
milijan wants to merge 2 commits into
Open
Conversation
At boot the Apple co-processor firmware does not acknowledge the pipehandler lock within the fixed 1ms timeout (PIPEHANDLER_LOCK_ACK_TIMEOUT_US = 1000). The function clears the lock bit and returns an error, leaving the PHY unconfigured for the rest of the session and preventing USB3 and DP alt mode from working. Replace the single poll attempt with a retry loop: up to 10 attempts with a 5-10ms sleep between each, giving the firmware approximately 100ms total to respond. Add an early return if the lock is already held to avoid double-locking. Tested on Apple M1 MacBook Air (J313), Fedora Asahi Remix 44, kernel 6.19.14. Boot with multiport hub connected no longer produces "Pipehandler lock not acked" errors and USB3 enumerates correctly. Signed-off-by: milijan <milijan@users.noreply.github.com>
…N on USB3_DP When DP alt mode is negotiated on hotplug, atcphy_mux_set() can be called while atcphy->pipehandler_up is still true. The existing WARN_ON fired unconditionally, but the situation has two distinct sub-cases that require different handling: 1. Target mode uses ATCPHY_PIPEHANDLER_STATE_DUMMY (DP-only, USB2, TBT, OFF): pipehandler_up being true is a teardown race between the TypeC mux call chain (cd321x_update_work -> typec_mux_set -> atcphy_mux_set) and the DWC3 PHY teardown (phy_power_off -> atcphy_usb3_power_off). By the time the kernel TypeC stack reaches atcphy_mux_set the USB PD Enter_Mode handshake is complete and the SS lanes are already being repurposed, so switching the pipehandler to dummy is safe. Tear it down explicitly here rather than relying on the race resolving itself. 2. Target mode uses ATCPHY_PIPEHANDLER_STATE_USB3 (USB3_DP, pin assignment D): pipehandler_up being true is correct and expected. The Apple USB-C Digital AV Multiport Adapter (05ac:1463) always negotiates pin assignment D, so the previous WARN_ON fired on every hotplug despite nothing being wrong with the pipehandler state. Retain the WARN_ON but scope it to case 1 only: warn when the target mode requires dummy state but the pipehandler is still up after the explicit teardown attempt (indicating atcphy_configure_pipehandler_dummy failed). Do not warn for USB3_DP transitions where USB3 pipehandler state is the correct precondition. Tested on Apple M1 MacBook Air (J313), Fedora Asahi Remix 44, kernel 6.19.14, with Apple USB-C Digital AV Multiport Adapter (05ac:1463). Hotplug no longer produces a spurious WARN_ON. Signed-off-by: milijan <milijan@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes observed on J313 (M1 MacBook Air) with a USB-C multiport hub:
Retry pipehandler lock with backoff: Replace the single poll with up to 10 retries at 5–10 ms intervals (~100 ms total). Avoids having to hard cycle the usb-c connection.
Fix teardown race and spurious WARN on USB3_DP. Scope the WARN to the failure case only.
Tested on Fedora Asahi Remix 44, kernel 6.19.