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
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:25] (current)
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.
 +  - 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 "​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.1551833107.txt.gz · Last modified: 2019/03/06 00:45 by Andrew Zaborowski