mac80211-wip preview

mac80211-wip preview

[Johannes Berg]

Hi,

This is a more tentative preview, things are still subject to change.

The included patchsets and their status:
 * P2P Device work
   I posted this, I'll apply it when I get back unless I see any
   objections then :-)
 * some more cleanups, including the CSA cleanups
   I posted most of these I believe, and will also apply most of it when
   I get back
 * a brcmsmac patch that I posted -- I'm not going to apply it but I
   just wanted to do a random cleanup (the obsolete functions removal)
 * and channel context code of course!
   This is still WIP, I need to
   - address SMPS -- I might just do passive/active # of chains per
     channel context and let the driver sort out the rest, this gives it
     more information and flexibility
   - TX power -- I'm open to suggestions about how we should do this,
     technically the user setting could be per virtual interface, but do
     we care? I have a feeling it should be per channel since even 11h
     TX power reduction is defined for the entire channel

FWIW, multi-channel works in hwsim, but hasn't been tested with actual
drivers yet. If somebody wants to do that while I'm on vacation, the
code is all there in the mac80211-next/wip branch on git.kernel.org. :-)

johannes


Johannes Berg (31):
      mac80211: remove unneeded 'bssid' variable
      mac80211: clean up CSA handling code
      mac80211: fix CSA handling timer
      mac80211: check size of channel switch IE when parsing
      mac80211: make ieee80211_beacon_connection_loss_work static
      mac80211: disconnect if channel switch fails
      brcmsmac: use ieee80211_channel_to_frequency
      wireless: remove obsolete chan no/center freq conversion functions
      cfg80211: add P2P Device abstraction
      mac80211: support P2P Device abstraction
      mac80211: add IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF
      mac80211_hwsim: add support for P2P Device
      mac80211: mesh: don't use global channel type
      mac80211: remove almost unused local variable
      mac80211: remove freq/chantype from debugfs
      mac80211: use oper_channel in rate init
      mac80211: don't assume channel is set in tracing
      mac80211: use RX status band instead of current band
      mac80211: check operating channel in scan
      mac80211: convert ops checks to WARN_ON
      mac80211: pass channel to ieee80211_send_probe_req
      mac80211: clean up ieee80211_subif_start_xmit
      mac80211: check channel context methods
      mac80211: track whether to use channel contexts
      mac80211: allow drv_add_chanctx to fail
      mac80211: return error code from ieee80211_vif_use_channel
      mac80211: use channel contexts
      mac80211_hwsim: move module_init/exit
      mac80211_hwsim: use channel contexts
      cfg80211: add ieee80211_operating_class_to_band
      mac80211: support extended channel switch

Michal Kazior (5):
      mac80211: introduce channel context skeleton code
      mac80211: introduce new ieee80211_ops
      mac80211: use channel context notifications
      mac80211: refactor set_channel_type
      mac80211: reuse channels for channel contexts

Re: mac80211-wip preview

[Ben Greear]

On 08/02/2012 08:44 AM, Johannes Berg wrote:
> Hi,
>
> This is a more tentative preview, things are still subject to change.
>
> The included patchsets and their status:
>   * P2P Device work
>     I posted this, I'll apply it when I get back unless I see any
>     objections then :-)
>   * some more cleanups, including the CSA cleanups
>     I posted most of these I believe, and will also apply most of it when
>     I get back
>   * a brcmsmac patch that I posted -- I'm not going to apply it but I
>     just wanted to do a random cleanup (the obsolete functions removal)
>   * and channel context code of course!
>     This is still WIP, I need to
>     - address SMPS -- I might just do passive/active # of chains per
>       channel context and let the driver sort out the rest, this gives it
>       more information and flexibility
>     - TX power -- I'm open to suggestions about how we should do this,
>       technically the user setting could be per virtual interface, but do
>       we care? I have a feeling it should be per channel since even 11h
>       TX power reduction is defined for the entire channel

I would love for tx power to be per network device.  If nothing else,
one could have two station interfaces talking on the same channel, to two different
APs..one close by and one far away.  Could set the tx-power higher for
the far-away one, for example.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com