ENUM IEEE80211_REGULATORY_FLAGS(9)

✨ enum ieee80211_regulatory_flags ✨

okay bestie, so this page is literally all about the device regulatory flags for the kernel API manual, and honestly it's giving main character energy in include/net/regulatory.h. let's get into it 🫶

🌸 SYNOPSIS 🌸

enum ieee80211_regulatory_flags {
    REGULATORY_CUSTOM_REG ,
    REGULATORY_STRICT_REG ,
    REGULATORY_DISABLE_BEACON_HINTS ,
    REGULATORY_COUNTRY_IE_FOLLOW_POWER ,
    REGULATORY_COUNTRY_IE_IGNORE ,
    REGULATORY_ENABLE_RELAX_NO_IR ,
    REGULATORY_WIPHY_SELF_MANAGED

};

💅 CONSTANTS 💅

• REGULATORY_CUSTOM_REG — this flag is telling you that the driver for this device has its own custom regulatory domain and literally cannot identify which ISO / IEC 3166 alpha2 it belongs to. when this is enabled, we will disregard the first regulatory hint (when the initiator is REGDOM_SET_BY_CORE). drivers that use wiphy_apply_custom_regulatory should have this flag set, or the regulatory core will set it for the wiphy. and like, if you use regulatory_hint after using wiphy_apply_custom_regulatory, the wireless core will clear the REGULATORY_CUSTOM_REG for your wiphy because it would be implied that the device somehow gained knowledge of its region. iykyk 😌
• REGULATORY_STRICT_REG — bestie, this one tells us that the wiphy for this device has a regulatory domain that it wishes to be considered as the superset for regulatory rules. after this device gets its regulatory domain programmed, further regulatory hints shall only be considered for this device to enhance regulatory compliance, forcing the device to only possibly use subsets of the original regulatory rules. for example, if channel 13 and 14 are disabled by this device's regulatory domain, no user specified regulatory hint which has these channels enabled would enable them for this wiphy — the device's original regulatory domain will be trusted as the base. you can program the superset of regulatory rules for this wiphy with regulatory_hint for cards programmed with an ISO3166-alpha2 country code. wiphys that use regulatory_hint will have their wiphy->regd programmed once the regulatory domain is set, and all other regulatory hints will be ignored until their own regulatory domain gets programmed. periodt. 💁‍♀️
• REGULATORY_DISABLE_BEACON_HINTS — enable this if your driver needs to ensure that passive scan flags and beaconing flags may not be lifted by cfg80211 due to regulatory beacon hints. for more info on beacon hints, read the documentation for regulatory_hint_found_beacon. no cap, it's all in there. 🔍
• REGULATORY_COUNTRY_IE_FOLLOW_POWER — for devices that have a preference that even though they may have programmed their own custom power setting prior to wiphy registration, they want to ensure their channel power settings are updated for this connection with the power settings derived from the regulatory domain. the regulatory domain used will be based on the ISO3166-alpha2 from country IE provided through regulatory_hint_country_ie. it's giving ✨glow-up✨ for your power settings.
• REGULATORY_COUNTRY_IE_IGNORE — for devices that have a preference to ignore all country IE information processed by the regulatory core. this will override REGULATORY_COUNTRY_IE_FOLLOW_POWER as all country IEs will be ignored. like, bye felicia to all that country IE info. 🚫
• REGULATORY_ENABLE_RELAX_NO_IR — for devices that wish to allow the NO_IR relaxation, which enables transmissions on channels on which otherwise initiating radiation is not allowed. this will enable the relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration option. it's the chill pill for your channels. 🧘‍♀️
• REGULATORY_WIPHY_SELF_MANAGED — for devices that employ wiphy-specific regdom management. these devices will ignore all regdom changes not originating from their own wiphy. a self-managed wiphy only employs regulatory information obtained from the FW and driver and does not use other cfg80211 sources like beacon-hints, country-code IEs, and hints from other devices on the same system. conversely, a self-managed wiphy does not share its regulatory hints with other devices in the system. if a system contains several devices, one or more of which are self-managed, there might be contradictory regulatory settings between them. usage of this flag is generally discouraged. only use it if the FW/driver is incompatible with non-locally originated hints. this flag is incompatible with the flags: REGULATORY_CUSTOM_REG, REGULATORY_STRICT_REG, REGULATORY_COUNTRY_IE_FOLLOW_POWER, REGULATORY_COUNTRY_IE_IGNORE and REGULATORY_DISABLE_BEACON_HINTS. mixing any of the above flags with this flag will result in a failure to register the wiphy. this flag implies REGULATORY_DISABLE_BEACON_HINTS and REGULATORY_COUNTRY_IE_IGNORE.

⚠️ bestie, seriously, the self-managed flag is highkey discouraged unless your firmware/driver literally cannot handle non-locally originated hints. and DO NOT mix it with the other flags listed above or your wiphy registration will straight up fail. you've been warned. 💀

🦋 SEE ALSO 🦋

• Kernel file ./include/net/regulatory.h
• enum environment_cap(9)
• struct regulatory_request(9)
• struct ieee80211_wmm_ac(9)

that's the whole vibe, bestie. go forth and configure your regulatory flags responsibly. and remember, this page is from ./include/net, dated October 2026, and it's the enum ieee80...latory_flags(9) manual — slay. 💖✨🎀