FullMAC or SoftMAC for a Custom Linux Device: Choose Where the Required Behavior Can Be Changed
Choose a Wi-Fi architecture by tracing the behavior you must change to its effective owner. The labels FullMAC and SoftMAC are useful starting points, but they do not establish that a particular scheduling, rate-control or power-save decision is editable in host code. Hardware and firmware offloads can bypass code that appears to be the obvious extension point.
This feasibility procedure uses Linux 6.12 cfg80211/mac80211 contracts and the brcmfmac connection implementation as concrete references. It does not certify a module, grant access to vendor firmware or predict RF performance. Record the exact chip, driver, firmware, exposed capabilities and supported interfaces for the candidate product.
Start with a testable behavior requirement
Replace “we need a flexible Wi-Fi stack” with an observable requirement: for example, “the selected transmit-rate algorithm must be replaceable in our supported host build,” or “the product must choose among saved connection profiles using our policy.” These requirements live at different layers. Profile selection may be implemented above the driver, while per-frame rate selection may reside below the host’s control.
For each requirement, define the input under your control, the decision to be changed and the target observation that would demonstrate the effect. Also state constraints: supported security modes, legal operating configuration, CPU budget, firmware availability and maintenance responsibility. A change that requires an unavailable firmware build is a blocked dependency, not a host-driver implementation estimate.
Do not confuse a common API with common ownership
Linux’s wireless configuration interfaces expose operations across different driver architectures. mac80211 provides substantial host-side functionality for participating drivers, but its hardware flags explicitly identify behavior delegated elsewhere. Read the actual driver capabilities and source path before choosing an extension. Linux 6.12 mac80211 driver interface
A particularly clear boundary is IEEE80211_HW_HAS_RATE_CONTROL. Its contract says that hardware or firmware performs rate control and that it cannot be controlled by the stack. In the pinned rate-control source, the transmit rate-selection path returns without calling the host algorithm when that flag is set; initialization also avoids allocating a host rate-control algorithm. Editing a host algorithm that is bypassed cannot establish the required behavior. Linux 6.12 hardware capability contracts Linux 6.12 rate_control_get_rate() and ieee80211_init_rate_ctrl_alg()
Other offload flags expose different boundaries. AP_LINK_PS delegates AP station power-save handling, including mechanisms otherwise processed by mac80211. TX_AMPDU_SETUP_IN_HW concerns hardware setup of transmit aggregation sessions; it is not a statement that every aggregation decision is host-owned or firmware-owned. Audit the specific operation instead of collapsing all offloads into one yes/no column.
Never clear a capability flag merely to force an attractive host path. The flag describes a driver/device contract. A valid change needs compatible implementation and target evidence, not just a different branch condition.
Trace a FullMAC operation to the firmware boundary
In Linux 6.12 brcmfmac, brcmf_cfg80211_connect() prepares connection parameters and security settings, then submits a firmware join command. Its fallback uses BRCMF_C_SET_SSID. This shows where that implementation hands the connection operation to firmware; it does not mean every FullMAC driver has identical commands or that userspace cannot choose which connection to request. Linux 6.12 brcmfmac connection path
A successful command submission is still different from successful association and working service. Likewise, finding a configurable firmware parameter does not establish permission to modify the firmware algorithm behind it. Obtain the vendor-supported interface and compatibility contract before promising a customization.
Build a responsibility and feasibility matrix
| Required change | Ownership question | Evidence needed before commitment |
|---|---|---|
| Saved-profile preference | Which userspace manager owns selection? | Supported policy API, eligibility rules and repeatable selection test |
| Custom transmit-rate algorithm | Is the host algorithm actually selected, or bypassed by rate-control offload? | Driver flags, selected algorithm path and target proof of changed decisions |
| AP power-save delivery behavior | Does mac80211 or the device manage the station’s service periods? | Effective AP offload contract, supported modification point and receiver-side validation |
| New firmware-controlled association behavior | Is there a supported parameter, firmware extension or vendor development path? | Documented interface, compatible firmware and an achievable qualification plan |
Classify each row as supported configuration, supported host extension, vendor/firmware dependency, or unsupported in the proposed design. Keep unresolved rows visible. A driver source license and a firmware customization agreement are separate pieces of evidence.
Run a proof-of-effect campaign before freezing the platform
- Inventory the actual path. Capture driver and firmware versions, relevant capabilities and the function or command that owns the decision. Read the branch conditions, not only the exported API name.
- Choose one bounded experiment. Change one supported input or a narrowly scoped development build. Specify an observable consequence and an unchanged control case. Keep regulatory, security and calibration constraints intact.
- Prove the code was exercised. Use suitable existing instrumentation or a reviewed development trace to show the intended path ran. A successful compile establishes syntax/build compatibility, not ownership or RF effect.
- Verify the consequence on the target. Observe the relevant frames, driver counters or application outcome with their limitations. A host trace alone may show a request while firmware applies a different supported policy.
- Assess lifecycle cost. Repeat after reconnect, restart and the supported firmware update path. Identify who maintains the extension when kernel and firmware interfaces change.
For a hypothetical design, the team wants a custom host rate algorithm and selects a mac80211-based driver. Inspection finds HAS_RATE_CONTROL set. The initial proposal therefore fails its ownership gate even though the architecture is called SoftMAC. The next decision is to use a supported device-controlled mechanism, obtain a suitable vendor path, choose another qualified platform, or revise the requirement. Benchmarking the unused host patch would not resolve the dependency.
No driver patch, firmware modification or radio experiment was executed here. The checked source paths establish where the feasibility questions arise; target work must establish support and effect for the chosen hardware. Approve the platform only when every mandatory behavior has an owner, an authorized modification path and a credible verification method.
