DEVICE REGISTRATION(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– DEVICE REGISTRATION πŸ’–

okay so this is Device registration(9) from the Kernel API Manual, and honestly? it's kind of the moment your driver's whole social life begins πŸ’…

Here's the situation, bestie: for a driver to use cfg80211, it must register the hardware device with cfg80211. That's not optional, that's the whole entry fee. And how does it do that? Through a number of hardware capability structs, described below. Slay. Get into it. ✨


🌸 the main character: wiphy

The fundamental structure for each device is the wiphy β€” literally the it-girl of this entire page. Each instance of it describes a physical wireless device connected to the system. One wiphy, one physical wireless device, that's the vibe.

Each such wiphy can have zero, one, or many virtual interfaces associated with it β€” the range is giving versatility, fr fr. Those virtual interfaces need to be identified as such by pointing the network interface's ieee80211_ptr pointer to a struct wireless_dev, which further describes the wireless part of the interface. Normally this struct is embedded in the network interface's private data area 🫢 cozy placement, we love to see it.

Drivers can optionally allow creating or destroying virtual interfaces on the fly. But heads up β€” without at least one interface, or without the ability to create some, the wireless device isn't useful. Like, a wireless device with no interfaces is giving decorative πŸ’€

πŸ¦‹ capabilities + ops

Each wiphy structure contains device capability information, and also has a pointer to the various operations the driver offers. The definitions and structures here describe these capabilities in detail β€” so keep scrolling, we're getting into it πŸ‘‘


still here? good. there's more where that came from ✨

✨ SEE ALSO ✨

okay bestie, buckle up, because this is the part of the page that's basically the group photo at the end of the yearbook β€” every single one of these is a real page and they're all linked here so you can go read them yourself πŸ’–

  • Kernel file ./include/net/cfg80211.h β€” yeah, the actual header. go touch grass (it's a header file, it's the closest thing to grass in this subsystem 🌱)

and then the cast list, in the order the page gives it, no cap:

yes that's all one blob in the original, i just ✨separated✨ them so your eyes survive. all of them, in that order, nothing dropped πŸ’…

now the actions & config era, which is a whole mood πŸŽ€

that's so many channel definition helpers, and honestly? iconic. the chandef girlies stay winning πŸ“‘


surveys, beacons, AP setup, and the station lore 🌸

  • enum survey_info_flags(9)
  • struct survey_info(9)
  • struct cfg80211_crypto_settings(9)
  • struct cfg80211_mbssid_config(9)
  • struct cfg80211_mbssid_elems(9)
  • struct cfg80211_rnr_elems(9)
  • struct cfg80211_beacon_data(9)
  • struct cfg80211_acl_data(9)
  • struct cfg80211_fils_discovery(9)
  • struct cfg80211_unsol_bcast_probe_resp(9)
  • struct cfg80211_s1g_short_beacon(9)
  • struct cfg80211_ap_settings(9)
  • struct cfg80211_ap_update(9)
  • struct cfg80211_csa_settings(9)
  • struct cfg80211_color_change_settings(9)
  • struct iface_combination_params(9)
  • enum station_parameters_apply_mask(9)
  • struct sta_txpwr(9)
  • struct link_station_parameters(9)
  • struct link_station_del_parameters(9)
  • struct cfg80211_ttlm_params(9)
  • struct station_parameters(9)
  • struct station_del_parameters(9)
  • enum cfg80211_station_type(9)
  • cfg80211_check_station_change(9)
  • enum rate_info_flags(9)
  • enum rate_info_bw(9)
  • struct rate_info(9)
  • enum bss_param_flags(9)
  • struct sta_bss_parameters(9)
  • struct cfg80211_txq_stats(9)
  • struct cfg80211_tid_stats(9)
  • struct link_station_info(9)
  • struct station_info(9)
  • struct cfg80211_sar_sub_specs(9)
  • struct cfg80211_sar_specs(9)
  • struct cfg80211_sar_freq_ranges(9)
  • struct cfg80211_sar_capa(9)
  • cfg80211_get_station(9)
  • enum monitor_flags(9)
  • enum mpath_info_flags(9)
  • struct mpath_info(9)
  • enum wiphy_bss_param_flags(9)
  • struct bss_parameters(9)
  • struct mesh_config(9)
  • struct mesh_setup(9)
  • struct ocb_setup(9)
  • struct ieee80211_txq_params(9)

mesh, OCB, SAR, monitor mode β€” the whole polycule of wireless modes, together at last 🫢


scanning & BSS list handling (the "where did all these beacons come from" section) πŸ¦‹

  • Scanning and BSS list handling(9)
  • struct cfg80211_ssid(9)
  • struct cfg80211_scan_info(9)
  • struct cfg80211_scan_6ghz_params(9)
  • struct cfg80211_scan_request(9)
  • struct cfg80211_match_set(9)
  • struct cfg80211_sched_scan_plan(9)
  • struct cfg80211_bss_select_adjust(9)
  • struct cfg80211_sched_scan_request(9)
  • enum cfg80211_signal_type(9)
  • struct cfg80211_inform_bss(9)
  • struct cfg80211_bss_ies(9)
  • struct cfg80211_bss(9)
  • ieee80211_bss_get_elem(9)
  • ieee80211_bss_get_ie(9)
  • struct cfg80211_auth_request(9)
  • struct cfg80211_assoc_link(9)
  • struct cfg80211_ml_reconf_req(9)
  • enum cfg80211_assoc_req_flags(9)
  • struct cfg80211_assoc_request(9)
  • struct cfg80211_deauth_request(9)
  • struct cfg80211_disassoc_request(9)
  • struct cfg80211_ibss_params(9)
  • struct cfg80211_bss_selection(9)
  • struct cfg80211_connect_params(9)
  • enum cfg80211_connect_params_changed(9)
  • enum wiphy_params_flags(9)
  • struct cfg80211_pmksa(9)
  • struct cfg80211_pkt_pattern(9)
  • struct cfg80211_wowlan_tcp(9)
  • struct cfg80211_wowlan(9)
  • struct cfg80211_coalesce_rules(9)
  • struct cfg80211_coalesce(9)
  • struct cfg80211_wowlan_nd_match(9)
  • struct cfg80211_wowlan_nd_info(9)
  • struct cfg80211_wowlan_wakeup(9)
  • struct cfg80211_gtk_rekey_data(9)
  • struct cfg80211_update_ft_ies_params(9)
  • struct cfg80211_mgmt_tx_params(9)
  • struct cfg80211_dscp_exception(9)
  • struct cfg80211_dscp_range(9)
  • struct cfg80211_qos_map(9)

authentication, association, wowlan, QoS maps β€” literally the whole social life of a wifi card, laid out πŸ’€


NAN πŸ’« (Neighbor Awareness Networking, aka the extrovert protocol)

  • Neighbor Awareness Networking (NAN)(9)
  • struct cfg80211_nan_band_config(9)
  • struct cfg80211_nan_conf(9)
  • struct cfg80211_nan_channel(9)
  • struct cfg80211_nan_local_sched(9)
  • struct cfg80211_nan_peer_map(9)
  • struct cfg80211_nan_peer_sched(9)
  • enum cfg80211_nan_conf_changes(9)
  • struct cfg80211_nan_func_filter(9)
  • struct cfg80211_nan_func(9)
  • struct cfg80211_pmk_conf(9)
  • struct cfg80211_external_auth_params(9)
  • struct cfg80211_ftm_responder_stats(9)
  • struct cfg80211_pmsr_ftm_result(9)
  • struct cfg80211_pmsr_result(9)
  • struct cfg80211_pmsr_ftm_request_peer(9)
  • struct cfg80211_pmsr_request_peer(9)
  • struct cfg80211_pmsr_request(9)
  • struct cfg80211_update_owe_info(9)
  • struct mgmt_frame_regs(9)

the wiphy lifecycle, aka the main character arc πŸ‘‘

look at all those work/cancel/flush/pending triples. it's giving chore chart. and yes, you need all of them, there's no "just call flush" shortcut in this list, don't @ me 🧚


utility functions πŸŽ€

channel↔frequency conversions for days, plus header length math. ngl the header length ones are lowkey the most useful πŸ“


data path helpers 🌈

the whole find_elem / find_ie / find_ext_* / find_vendor_* family tree β€” pick the right one or cry later, iykyk 😭


regulatory enforcement infrastructure 🚨

internal regulatory db functions (yes, an entire separate little club) πŸ’œ


BSS handling, MLME, and the notification economy πŸ”₯


RFkill integration πŸ“΄


vendor commands πŸ’…

test mode πŸ§ͺ


connect / roam / disconnect / sta / cqm β€” the big finale of notifications πŸ’–

okay that's the entire list, fr fr. yes it's long. no you don't have to read all of it in one sitting β€” but every single one of these is a real page and if you need it, it's right there πŸ’€πŸ«Ά

…and we're back, bestie, still in the SEE ALSO list, because this section is a whole friend group and we are NOT skipping a single one πŸ’…

Okay so. The rest of this list is 64 entries long and every single one is a (9) page, so you already know they're kernel-section lore. Going through them in order, no cap, zero skips:

That's the regulatory + channel-switch clique β€” reg_can_beacon gets a _relax sibling, which is honestly so real of it. πŸ’–

The conversion girlies ✨ β€” they go both ways between operating class and chandef, and one of them literally speaks kHz. Then two randoms wander in (tdls and bitrate math) and we love them anyway.

Not a struct getting its own manpage reference β€” yes bestie, structs get lore pages too, we stan a data structure with main character energy. πŸ‘‘

Splitting and fragmenting, the whole "take it apart" squad πŸŽ€

Combinations get both a check and an iter version, because of course they do. 😭

set and isset 🫢 β€” the classic duo, name a more iconic pair, I'll wait.

The nan block!! 🌸 (_nan_ in the middle of a name is never not funny, I don't make the rules.) Also another struct entry β€” cfg80211_nan_match_params said "I'm a page too."

assoc_comeback is lowkey the best function name on this whole page and I will not be taking questions. πŸ’€

The color-change family!! 🌈 started, aborted, and the plain one β€” three notifications and a collision, it's giving full drama arc.

Another struct page β€” cfg80211_mlo_reconf_done_data, you ate that. πŸ”₯

The nan girlies come back for round two πŸ¦‹ β€” cluster joined, ulw updated, channel evacuated, we love a comeback tour.

And it ends on debugfs read/write (locked, both of them, matching set πŸŽ€), the three s1g frequency helpers β€” start, end, and the very adorable primary_sibling β€” and finally cfg80211_incumbent_signal_notify(9) closing out the whole list. ⭐


That's genuinely every single reference, bestie. Nothing dropped, nothing merged, nothing "cleaned up" β€” 64 for 64. πŸ™ˆ

So yeah β€” that's the page, start to finish. 🫢 Source lives at ./include/net, dated October 2026, and the page itself is Device registration(9). Go read the whole set, ily, bye! πŸ’–βœ¨

πŸ“¦ where this page comes from