From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: Vasanth Thiagarajan <Vasanth.Thiagarajan@Atheros.com>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>
Subject: Re: [RFC] ath9k: fix listening to idle requests
Date: Mon, 2 Nov 2009 07:30:37 -0800 [thread overview]
Message-ID: <20091102153037.GA3647@tux> (raw)
In-Reply-To: <20091102065616.GB1989@vasanth-laptop>
On Sun, Nov 01, 2009 at 10:56:19PM -0800, Vasanth Thiagarajan wrote:
> 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@atheros.com> 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@atheros.com>
> > > >> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > > >> ---
> > > >>
> > > >> 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.
OK thanks for testing, I'll send in patch form.
Luis
prev parent reply other threads:[~2009-11-02 15:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 20:52 [RFC] ath9k: fix listening to idle requests Luis R. Rodriguez
2009-10-30 6:33 ` Vasanthakumar Thiagarajan
2009-10-30 14:38 ` Luis R. Rodriguez
2009-10-31 5:29 ` Vasanthakumar Thiagarajan
2009-11-02 6:56 ` Vasanthakumar Thiagarajan
2009-11-02 15:30 ` Luis R. Rodriguez [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091102153037.GA3647@tux \
--to=lrodriguez@atheros.com \
--cc=Luis.Rodriguez@Atheros.com \
--cc=Vasanth.Thiagarajan@Atheros.com \
--cc=ath9k-devel@lists.ath9k.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).