mac80211 driver API

mac80211 driver API

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3005 bytes --]

Hi,

Another thing I noticed when looking at the short slot stuff is that a
number of drivers do not use the use_short_preamble flag but also do not
set IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE; this seems like a bug
affecting at least b43legacy, ath5k, at76_usb, rtl8180, rtl8187.

You should review the mac80211 driver API for things you aren't using
but should be using, this affects a number of drivers, for example
adm8211, p54, stlc45xx, ath5k, ath9k, libertas_tf, rtl8180, rtl8187
don't use radio_enabled; a number of drivers don't use power_level.

There are also still drivers (ath5k, adm8211, rtl8180, iwlwifi,
libertas_tf, zd1211rw, mac80211_hwsim, ...?) not using the
IEEE80211_TX_CTL_ASSIGN_SEQ flag, I can fix those since I broke them,
but help from the authors would be appreciated since I don't know the hw
in all cases, I know that stlc45xx for example can use a corresponding
firmware flag for it.


Do we need a document that indicates which parts of the API must be
implemented? Or should we mark such things in mac80211.h? Would
something like this help? I've thrown this together quickly so it
probably isn't complete yet...

A driver must (alternatives in order of preference)
 * either honour the IEEE80211_TX_CTL_USE_RTS_CTS flag
   or implement the set_rts_threshold call
 * either honour the IEEE80211_TX_CTL_USE_CTS_PROTECT flag
   or honour bss_conf's use_cts_prot value
 * either honour IEEE80211_TX_CTL_SHORT_PREAMBLE
   or honour bss_conf's use_short_preamble
   or set the IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE hw flag
 * honour bss_conf's use_short_slot or set the
   IEEE80211_HW_2GHZ_SHORT_SLOT_INCAPABLE hw flag
 * honour bss_conf's basic_rates bitmap to set up the control response
   frame bitrate (cf. IEEE 802.11-2007 9.6 "Multirate support" paragraph 7)
 * honour IEEE80211_TX_CTL_NO_ACK unless the hardware does based on the
   multicast bit
 * honour IEEE80211_TX_CTL_ASSIGN_SEQ (we could make this depend on
   IBSS/AP/MESH modes)
 * honour IEEE80211_TX_CTL_REQ_TX_STATUS or always report TX status
 * honour the radio_enabled value of the hw config
 * not change it's operating mode based on IEEE80211_CONF_RADIOTAP
 * clear/set MAC address filters/control response frame generation based
   on the interface add/remove callbacks
 * set up beacon access parameters based on the interface mode (ibss/ap)
 * use SET_IEEE80211_DEV and SET_IEEE80211_PERM_ADDR
 * set the wiphy interface modes
 * set one of the IEEE80211_HW_SIGNAL_* hw flags (?)
 * set channel_change_time
 * ...

For QoS/WME, it must
 * support at least four queues
 * support configurable access parameters for those queues
 * ...

For AP mode, it must
 * honour IEEE80211_TX_CTL_SEND_AFTER_DTIM
 * ...

For MESH mode, it must
 * [anything special other than beaconing?]
 * ...

For HT, it must
 * support QoS
 * [need help, Tomas/Ron?]
 * ...

For spectrum management, it must
 * [unfinished]
 * ...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mac80211 driver API

[John W. Linville]

On Tue, Oct 07, 2008 at 07:01:25PM +0200, Johannes Berg wrote:

> Another thing I noticed when looking at the short slot stuff is that a
> number of drivers do not use the use_short_preamble flag but also do not
> set IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE; this seems like a bug
> affecting at least b43legacy, ath5k, at76_usb, rtl8180, rtl8187.
> 
> You should review the mac80211 driver API for things you aren't using
> but should be using, this affects a number of drivers, for example
> adm8211, p54, stlc45xx, ath5k, ath9k, libertas_tf, rtl8180, rtl8187
> don't use radio_enabled; a number of drivers don't use power_level.
> 
> There are also still drivers (ath5k, adm8211, rtl8180, iwlwifi,
> libertas_tf, zd1211rw, mac80211_hwsim, ...?) not using the
> IEEE80211_TX_CTL_ASSIGN_SEQ flag, I can fix those since I broke them,
> but help from the authors would be appreciated since I don't know the hw
> in all cases, I know that stlc45xx for example can use a corresponding
> firmware flag for it.

Should we recruit janitor's (or gregkh's army) to help with stuff
like the above?

> Do we need a document that indicates which parts of the API must be
> implemented? Or should we mark such things in mac80211.h? Would
> something like this help? I've thrown this together quickly so it
> probably isn't complete yet...

<snip>

Looks like a good start, and I would definitely value such a list.
Please continue to improve it, and we'll figure-out where it needs
to live in the long run.

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: mac80211 driver API

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On Tue, 2008-10-07 at 13:21 -0400, John W. Linville wrote:
> On Tue, Oct 07, 2008 at 07:01:25PM +0200, Johannes Berg wrote:
> 
> > Another thing I noticed when looking at the short slot stuff is that a
> > number of drivers do not use the use_short_preamble flag but also do not
> > set IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE; this seems like a bug
> > affecting at least b43legacy, ath5k, at76_usb, rtl8180, rtl8187.
> > 
> > You should review the mac80211 driver API for things you aren't using
> > but should be using, this affects a number of drivers, for example
> > adm8211, p54, stlc45xx, ath5k, ath9k, libertas_tf, rtl8180, rtl8187
> > don't use radio_enabled; a number of drivers don't use power_level.
> > 
> > There are also still drivers (ath5k, adm8211, rtl8180, iwlwifi,
> > libertas_tf, zd1211rw, mac80211_hwsim, ...?) not using the
> > IEEE80211_TX_CTL_ASSIGN_SEQ flag, I can fix those since I broke them,
> > but help from the authors would be appreciated since I don't know the hw
> > in all cases, I know that stlc45xx for example can use a corresponding
> > firmware flag for it.
> 
> Should we recruit janitor's (or gregkh's army) to help with stuff
> like the above?

Not sure that's possible, they'd have to ask a lot about how the hw
works.

> > Do we need a document that indicates which parts of the API must be
> > implemented? Or should we mark such things in mac80211.h? Would
> > something like this help? I've thrown this together quickly so it
> > probably isn't complete yet...
> 
> <snip>
> 
> Looks like a good start, and I would definitely value such a list.
> Please continue to improve it, and we'll figure-out where it needs
> to live in the long run.

I've put it up on
http://wireless.kernel.org/en/developers/Documentation/mac80211/API for
now, can those folks who did the HT/mesh/spectrum mgmt/etc. stuff help
completing it?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]