Search Linux Wireless

Re: RFC: unified BSS configuration approach

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > Hm, true, that could happen. Does it happen in practice though? I can't
> > see why a low level driver would decide that it should have short
> > preamble or CTS protection on by default. Maybe we should just document
> > initial state? Or we can keep the initial call and remove that "don't
> > call w/o BSS" restriction instead, which seems saner. We should then
> > probably rename reset_erp_info() to reset_bss_info() though.
> 
> Yes it happens in practices. I think with short slot.
> reset_bss_info() sounds good.

Ok so let's rename reset_erp_info() to reset_bss_info() and have it
handle all the other stuff too.

> > > 1 - change the original intention of bss_info_changed so mac80211 will
> > > be able to set low-level driver in the "init" or "configure" flows as
> > > well, not only as BSS is formed or changes
> > > 2 - maintain original intention, use "bss_info_changed" only when we
> > > want to deliver BSS configuration when we get associate or during
> > > association state,  and deliver all initial configuration info through
> > > different ops
> >
> > I prefer the first option since that's essentially just a small
> > documentation change and it makes sense. We just should make sure that
> > it's called only when the device is started (through ->start()).
> 
> what about reset_bss_info() ?

Well reset_bss_info() would still call ->bss_info_changed(), no?

johannes

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux