From: Zhu Yi <yi.zhu@intel.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Adel Gadllah <adel.gadllah@gmail.com>,
linux-wireless@vger.kernel.org, randy.dunlap@oracle.com,
"John W. Linville" <linville@tuxdriver.com>,
Ivo van Doorn <ivdoorn@gmail.com>,
fcrespel@gmail.com
Subject: Re: [PATCH] iwlwifi: remove input device and fix rfkill state
Date: Wed, 02 Jul 2008 16:25:35 +0800 [thread overview]
Message-ID: <1214987135.14590.496.camel@debian.sh.intel.com> (raw)
In-Reply-To: <20080701165657.GC6962@khazad-dum.debian.net>
On Tue, 2008-07-01 at 13:56 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 01 Jul 2008, Adel Gadllah wrote:
> > The calls to iwl|iwl3945_rfkill_set_hw_state() had to be moved
> because rfkill_force_state() cannot be called from an atomic context.
Yes, but what your patch changed is not in the atomic context. It is
just inside the driver's priv->mutex. I don't see any problem if you
call rfkill_force_state() inside it.
> Yeah, the joys of mutexes. If this is going to be a severe annoyance
> to drivers, I don't see why rfkill could not be changed to use some
> other locking primitive that does work on atomic contexes.
Allowing rfkill_force_state() to be called in the atomic context would
be useful especially for hardware rfkill. Devices (i.e iwl4965) receive
an interrupt when the hw-rfkill state changes. It's natural to update
the rfkill state in this context.
How about protect the rfkill->state by a spinlock and put the
notifier_call_chain() into a workqueue in the rfkill subsystem?
Thanks,
-yi
next prev parent reply other threads:[~2008-07-02 8:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 15:49 [PATCH] iwlwifi: remove input device and fix rfkill state Adel Gadllah
2008-07-01 16:56 ` Henrique de Moraes Holschuh
2008-07-02 8:25 ` Zhu Yi [this message]
2008-07-02 15:43 ` Henrique de Moraes Holschuh
2008-07-02 16:00 ` Ivo van Doorn
2008-07-02 18:41 ` Henrique de Moraes Holschuh
2008-07-02 22:31 ` Ivo van Doorn
2008-07-03 1:53 ` Henrique de Moraes Holschuh
2008-07-03 3:11 ` Zhu Yi
2008-07-03 12:49 ` Henrique de Moraes Holschuh
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=1214987135.14590.496.camel@debian.sh.intel.com \
--to=yi.zhu@intel.com \
--cc=adel.gadllah@gmail.com \
--cc=fcrespel@gmail.com \
--cc=hmh@hmh.eng.br \
--cc=ivdoorn@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=randy.dunlap@oracle.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.