Search Linux Wireless

Re: [RFC] ath9k: fix listening to idle requests

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

 



On Sat, Oct 31, 2009 at 10:59:53AM +0530, Vasanth Thiagarajan wrote:
> On Fri, Oct 30, 2009 at 08:08:22PM +0530, Luis Rodriguez wrote:
> > On Thu, Oct 29, 2009 at 11:33 PM, Vasanthakumar Thiagarajan
> > <vasanth@xxxxxxxxxxx> wrote:
> > > On Fri, Oct 30, 2009 at 02:22:26AM +0530, Luis Rodriguez wrote:
> > >> The way idle configuration detection was implemented as
> > >> busted due to the fact that it assumed the ath9k virtual wiphy,
> > >> the aphy, would be marked as inactive if it was not used but
> > >> it turns out an aphy is always active if its the only wiphy
> > >> present. We need to distinguish between aphy activity and
> > >> idleness so we now add an idle bool for the aphy and mark
> > >> it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
> > >> from mac80211.
> > >>
> > >> Previous to all_wiphys_idle would never be true when using
> > >> only one device so we never really were using
> > >> IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
> > >> off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
> > >> changes depended on all_wiphys_idle being true either to
> > >> turn the radio on or off. Since it was always false for
> > >> one device this code was doing nothing.
> > >>
> > >> Reported-by: Vasanthakumar Thiagarajan <vasanth@xxxxxxxxxxx>
> > >> Signed-off-by: Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx>
> > >> ---
> > >>
> > >> Vasanth, what do you think?
> > >
> > > Still we will have issue when bringing up a sec wiphy while the
> > > primary wiphy is in idle state. ath9k_start() does not brought up
> > > the newly created wiphy interface when the state of at least one
> > > previously created interface is in ACTIVE state. Unless already
> > > brought up interfaces are put down we hit this situation whenever
> > > we try to bring up a new secondary wiphy interface. So with this
> > > patch the actual h/w will remain radio disabled state even after
> > > a new interface is in active state. We need to bring the h/w into
> > > active state if all old interfaces are in idle state in
> > > ath9k_start().
> >
> > I don't see what prevents a secondary virtual wiphy from getting the
> > radio started -- perhaps I'm missing something. When a virtual wiphy
> > needs to become non-idle that'll come from the mac80211 non-idle
> > config call and that will find that one device is non-idle and hence
> > start it.
> 
> mac80211 will issue config() for non-idle only when the respective
> wiphy is already put into idle state.

When testing the patch I did not see this issue. The patch works
fine. I'll debug it further to see why the issue I was expecting
did not show up, but now this patch looks fine.

Vasanth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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