Repository navigation
wifi: mt7932: report a connect the AP did not complete at info level - #632
Merged
Merged
Conversation
A Neo boot logged mt7932-fullmac 0000:01:00.0: CONNECT_FAILED: -110; recovery-required=0 at error level while NetworkManager brought up Wi-Fi. The firmware was fine. The association timed out at the AP, cfg80211 reported the failed connect to the supplicant, and the next attempt connected. Once the request has gone to the AP, a timeout, a refusal or a reset with the firmware still healthy is how the AP answered. These are the same three outcomes the connect worker already treats as retryable for the first OWE attempt. mac80211 reports association timeouts and refusals at info level, and the supplicant logs them too. Log them at info level here as well. Everything else keeps the error level: failures before the request reaches the AP, protocol and I/O errors, and any failure that leaves the link needing recovery. A firmware command timeout sets link_failed, so it still shows as an error. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
Boot-tested on the MacBook Neo (J700). Kernel 7.3.0-aurora-fleet10nv (fleet10 46b7a93f plus #626), with mt7932-fullmac built from this PR's link.c and loaded from updates/.
Pass. 🤖 Generated with Claude Code |
The connect worker now asks mt_connect_failed_at_peer() whether a failed connect is the AP's answer, and logs those at info level. The host test compiled the report path on its own, so it failed on the missing helper and the auth_submitted local. Extract the helper next to the report, pass auth_submitted to the test worker and give the stub a link_failed flag. Count dev_info() and dev_err() calls and check every error code with the request at the AP or not and the firmware healthy or not: only a timeout, refusal or reset of a request that reached the AP with healthy firmware is logged at info level. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
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.
One Neo boot tonight (fleet10, boot at 22:14) logged an error-level line while NetworkManager brought Wi-Fi up:
Nothing was wrong with the driver or firmware. wpa_supplicant logged
CTRL-EVENT-ASSOC-REJECT ... status_code=1 timeoutat the same moment andCTRL-EVENT-CONNECTED5 s later, and NM activated the link.Once the request has gone to the AP (
auth_submitted), a timeout, a refusal or a reset with the firmware still healthy (!link_failed) is how the AP answered. Those are the same three codes the connect worker already treats as retryable for the first OWE attempt. mac80211 reports association timeouts and refusals at info level, so this does the same.Still at error level:
link_failedset. A firmware command timeout sets it infrontend.c, so a stalled firmware still shows as an error.The message text is unchanged, so log searches keep working.
Build
drivers/net/wireless/mediatek/mt7932/withW=1 LLVM=1on aurora-wip 72b4b56 using the universal config (Fedora base + asahi.config). No warnings. checkpatch clean.Hardware test (not run, the Neo is owned by the U-Boot agent tonight)
This is only a log level change. Carry it in the next fleet kernel through the fleet kit, then on the Neo:
🤖 Generated with Claude Code