en:developers:documentation:nl80211
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:developers:documentation:nl80211 [2019/03/06 00:45] Andrew Zaborowski [Users of nl80211] Link to NM as well as it talks nl80211 directly |
en:developers:documentation:nl80211 [2024/02/27 19:24] (current) Johannes Berg add wifi prefix to subject |
||
|---|---|---|---|
| Line 43: | Line 43: | ||
| Current users of the testmode interface are: | Current users of the testmode interface are: | ||
| - | * [[en/users/Drivers/wl12xx/calibrator|wl12xx calibrator]] (chipsets WL1271 etc.) | + | * [[http://linuxwireless.sipsolutions.net/en/users/Drivers/wl12xx/calibrator/|wl12xx calibrator]] (chipsets WL1271 etc.) |
| TODO: could list (references to) ready-made scripts which implement nicely automated / elegant workflows for SAR testing etc. | TODO: could list (references to) ready-made scripts which implement nicely automated / elegant workflows for SAR testing etc. | ||
| For ATH9K chipsets, there's SAR testing functionality provided via the non-testmode setting [[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath9k/Kconfig|CONFIG_ATH9K_TX99]]. Hmm, this possibly needs conversion to (additionally?) providing the generic nl80211 testmode functionality? | For ATH9K chipsets, there's SAR testing functionality provided via the non-testmode setting [[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath9k/Kconfig|CONFIG_ATH9K_TX99]]. Hmm, this possibly needs conversion to (additionally?) providing the generic nl80211 testmode functionality? | ||
| + | |||
| + | ===== vendor-specific API ===== | ||
| + | |||
| + | Under the NL80211_CMD_VENDOR command, there's the ability to register vendor-specific behavior. For a long time, we've explicitly rejected these upstream, but after many discussions some may be allowed, subject to (at least) the following constraints: | ||
| + | |||
| + | - Upstream vendor commands shall not replace existing functionality. | ||
| + | - The submitter shall consider a pure nl80211 implementation and explain the reasoning against it in the commit message. | ||
| + | - Example users/use cases of the API shall be documented. | ||
| + | - The newly proposed API shall be subject to stable API rules. | ||
| + | - Unless the data inside NL80211_ATTR_VENDOR_DATA is just an opaque blob not used by the driver (but e.g. by firmware), sub-attributes shall be used inside of it, and those shall be documented. | ||
| + | - Vendor command and sub-attribute definitions shall be in a common header file location (TBD, e.g. include/uapi/nl80211-vnd-*.h) | ||
| + | - Patches introducing such commands shall be submitted separately, not "buried" in big driver patchsets. Give them a "wifi: nl80211: vendor-cmd: " prefix to make them easily identifiable. | ||
| + | |||
| + | The goal with these rules is to enable use of vendor commands in a fashion that is transparent enough to allow later reuse by other components with similar needs, and then potentially defining "real" nl80211 API for the use case in question. | ||
en/developers/documentation/nl80211.1551833107.txt.gz · Last modified: 2019/03/06 00:45 by Andrew Zaborowski
Page Tools
