All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helmut Schaa <helmut.schaa@googlemail.com>
To: reinette chatre <reinette.chatre@intel.com>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ipw3945-devel@lists.sourceforge.net"
	<ipw3945-devel@lists.sourceforge.net>,
	"Guy, Wey-Yi W" <wey-yi.w.guy@intel.com>
Subject: Re: [PATCH 2/3] iwlwifi: remove STATUS_ALIVE checking from rf_kill
Date: Thu, 26 Mar 2009 20:49:17 +0100	[thread overview]
Message-ID: <200903262049.18049.helmut.schaa@gmail.com> (raw)
In-Reply-To: <1238095859.25000.54.camel@rc-desk>

Am Donnerstag, 26. M=C3=A4rz 2009 schrieb reinette chatre:
> On Thu, 2009-03-26 at 12:11 -0700, Helmut Schaa wrote:
> > Am Donnerstag, 26. M=C3=A4rz 2009 schrieb reinette chatre:
> > > On Thu, 2009-03-26 at 10:50 -0700, Helmut Schaa wrote:
> > > > Hi,
> > > >=20
> > > > Am Donnerstag, 26. M=C3=A4rz 2009 schrieb Reinette Chatre:
> > > > > From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> > > > >=20
> > > > > Remove STATUS_ALIVE checking when HW RF KILL disabled, the bi=
t get
> > > > > clear in __iwl_down() function; the additional checking will =
fail and
> > > > > cause RF can not be turn back on.
> > > >=20
> > > > Are you sure this is needed? I'd argue we should only restart t=
he adapter
> > > > if it was alive when it got rf_killed. In case the adapter was =
rf_killed
> > > > while the interface was down I don't think we want to restart t=
he adapter
> > > > immediately but first when the interface is taken up again.
> > >=20
> > > We also need to consider if a suspend/resume happens in the middl=
e.
> > > Without the patch, if you enable rfkill, suspend, resume, disable
> > > rfkill, then your interface cannot be brought up.
> >=20
> > I guess you refer to the situation where the interface is up, right=
?
> > Something like:
> >=20
> > - ifconfig wlan0 up
> > - press killswitch (kill wireless)
> > - suspend
> > - resume
> > - press killswitch (enable wireless)
> > - here the interface should still be up
> >=20
> > As the interface is/was up, mac80211's resume handler should restar=
t the
> > adapter and thus we wouldn't need to restart the adapter in the
> > rfkill-handler, or did I miss anything?
>=20
> Yes, the resume handler will start the adapter (call "start"), but th=
e
> actions done by it will exit early because of rfkill being enabled. T=
he
> STATUS_ALIVE bit will thus not be set after this is completed. Later,
> when user disables rfkill, we want to restart the adapter to get all
> this corrected, but this call currently fails because of this check.

Got it, thanks for the explanation.

Nevertheless, removing the check will result in restarting the adapter =
even
if the interface is down. So, I agree that we have a problem here but I=
 do
not agree with the solution ;)

Maybe taking the interface up (not only pseudo-up, as done currently) s=
hould
be allowed even if wireless is killed? We already allow the interface t=
o
stay up when the adapter gets rfkilled.

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

  reply	other threads:[~2009-03-26 19:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26 17:14 [PATCH 0/3] iwlwifi driver updates 03/26/2009 Reinette Chatre
2009-03-26 17:14 ` [PATCH 1/3] iwlwifi: merge and better support of suspend/resume for iwlagn and iwl3945 Reinette Chatre
2009-03-26 17:14   ` [PATCH 2/3] iwlwifi: remove STATUS_ALIVE checking from rf_kill Reinette Chatre
2009-03-26 17:14     ` [PATCH 3/3] iwl3945: use iwl_mac_conf_tx Reinette Chatre
2009-03-26 17:50     ` [PATCH 2/3] iwlwifi: remove STATUS_ALIVE checking from rf_kill Helmut Schaa
2009-03-26 18:22       ` reinette chatre
2009-03-26 19:11         ` Helmut Schaa
2009-03-26 19:30           ` reinette chatre
2009-03-26 19:49             ` Helmut Schaa [this message]
2009-03-26 20:37               ` reinette chatre
2009-03-26 20:58                 ` Helmut Schaa
2009-03-26 23:26                   ` reinette chatre
2009-03-27  6:19                     ` Helmut Schaa
2009-03-27  6:25                     ` Helmut Schaa
2009-03-27 15:45                       ` reinette chatre
2009-03-27  3:49                   ` reinette chatre
2009-03-27  6:18     ` Helmut Schaa
2009-03-27 16:03       ` reinette chatre
2009-03-27 16:30         ` reinette chatre

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=200903262049.18049.helmut.schaa@gmail.com \
    --to=helmut.schaa@googlemail.com \
    --cc=ipw3945-devel@lists.sourceforge.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=reinette.chatre@intel.com \
    --cc=wey-yi.w.guy@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.