User Tools

Site Tools


en:developers:documentation:nl80211

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next 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 [2019/05/28 11:16]
Johannes Berg [vendor-specific API]
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. 
Line 49: Line 49:
 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.
 +  - Sub-attributes of the NL80211_ATTR_VENDOR_DATA shall usually be used (at least for driver code) and 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 "​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.
 +
 +Patches will be merged through Kalle Valo's tree, but should also be reviewed by Johannes (cfg80211 maintainer).
en/developers/documentation/nl80211.txt · Last modified: 2019/05/28 11:25 by Johannes Berg