From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W Linville <linville@tuxdriver.com>,
bcm43xx-dev@lists.berlios.de, linux-wireless@vger.kernel.org
Subject: Re: [RFC] b43: A patch for control of the radio LED using rfkill
Date: Thu, 18 Sep 2008 19:31:49 +0200 [thread overview]
Message-ID: <200809181931.49636.mb@bu3sch.de> (raw)
In-Reply-To: <48d1e227.AmBwRnEuhx6kxlHv%Larry.Finger@lwfinger.net>
On Thursday 18 September 2008 07:07:51 Larry Finger wrote:
> Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
> +++ wireless-testing/drivers/net/wireless/b43/rfkill.c
> @@ -44,13 +44,11 @@ static bool b43_is_hw_radio_enabled(stru
> return 0;
> }
>
> -/* The poll callback for the hardware button. */
> -static void b43_rfkill_poll(struct input_polled_dev *poll_dev)
> +static void b43_rfkill_update(struct b43_wldev *dev)
> {
> - struct b43_wldev *dev = poll_dev->private;
> struct b43_wl *wl = dev->wl;
> bool enabled;
> - bool report_change = 0;
> + struct b43_rfkill *rfk = &(dev->wl->rfkill);
>
> mutex_lock(&wl->mutex);
> if (unlikely(b43_status(dev) < B43_STAT_INITIALIZED)) {
> @@ -60,18 +58,40 @@ static void b43_rfkill_poll(struct input
> enabled = b43_is_hw_radio_enabled(dev);
> if (unlikely(enabled != dev->radio_hw_enable)) {
> dev->radio_hw_enable = enabled;
> - report_change = 1;
> b43info(wl, "Radio hardware status changed to %s\n",
> enabled ? "ENABLED" : "DISABLED");
> + if (!enabled)
> + rfkill_force_state(rfk->rfkill,
> + RFKILL_STATE_HARD_BLOCKED);
> + else {
> + if (!dev->phy.radio_on)
> + rfkill_force_state(rfk->rfkill,
> + RFKILL_STATE_SOFT_BLOCKED);
> + else
> + rfkill_force_state(rfk->rfkill,
> + RFKILL_STATE_UNBLOCKED);
> + }
> }
> mutex_unlock(&wl->mutex);
Can rfkill_force_state recurse into b43_rfkill_soft_toggle()?
input_report_key could do this in the past (Dunno if that's still true now),
so that's why it's done outside of the lock to avoid deadlocks.
Also keep in mind that N and LP(?) devices report state through interrupt.
> +}
>
> - /* send the radio switch event to the system - note both a key press
> - * and a release are required */
> - if (unlikely(report_change)) {
> - input_report_key(poll_dev->input, KEY_WLAN, 1);
> - input_report_key(poll_dev->input, KEY_WLAN, 0);
> - }
> +static void b43_rfkill_poll(unsigned long data)
> +{
> + struct b43_rfkill *rfkill = (struct b43_rfkill *)data;
> + schedule_work(&rfkill->poll_queue);
> +}
> +
> +static void b43_rfkill_work(struct work_struct *work)
> +{
> + struct b43_rfkill *rfk = container_of(work, struct b43_rfkill,
> + poll_queue);
> + struct b43_wl *wl = container_of(rfk, struct b43_wl, rfkill);
> + struct b43_wldev *dev = wl->current_dev;
> +
> + b43_rfkill_update(dev);
> + rfk->poll_timer.function = b43_rfkill_poll;
> + rfk->poll_timer.expires = round_jiffies(jiffies + HZ);
> + add_timer(&rfk->poll_timer);
> }
Why not using delayed work instead of reinventing the wheel?
Also please schedule it on the mac80211 workqueue to avoid possible
deadlocks with the networking core.
> /* Called when the RFKILL toggled in software. */
> @@ -141,48 +161,23 @@ void b43_rfkill_init(struct b43_wldev *d
> rfk->rfkill->toggle_radio = b43_rfkill_soft_toggle;
> rfk->rfkill->user_claim_unsupported = 1;
>
> - rfk->poll_dev = input_allocate_polled_device();
> - if (!rfk->poll_dev) {
> - rfkill_free(rfk->rfkill);
> - goto err_freed_rfk;
> - }
> -
> - rfk->poll_dev->private = dev;
> - rfk->poll_dev->poll = b43_rfkill_poll;
> - rfk->poll_dev->poll_interval = 1000; /* msecs */
> -
> - rfk->poll_dev->input->name = rfk->name;
> - rfk->poll_dev->input->id.bustype = BUS_HOST;
> - rfk->poll_dev->input->id.vendor = dev->dev->bus->boardinfo.vendor;
> - rfk->poll_dev->input->evbit[0] = BIT(EV_KEY);
> - set_bit(KEY_WLAN, rfk->poll_dev->input->keybit);
> -
> err = rfkill_register(rfk->rfkill);
> if (err)
> - goto err_free_polldev;
> + goto err_free_rfk;
>
> -#ifdef CONFIG_RFKILL_INPUT_MODULE
> - /* B43 RF-kill isn't useful without the rfkill-input subsystem.
> - * Try to load the module. */
> - err = request_module("rfkill-input");
> - if (err)
> - b43warn(wl, "Failed to load the rfkill-input module. "
> - "The built-in radio LED will not work.\n");
> -#endif /* CONFIG_RFKILL_INPUT */
> + rfk->registered = 1;
>
> - err = input_register_polled_device(rfk->poll_dev);
> - if (err)
> - goto err_unreg_rfk;
> + INIT_WORK(&rfk->poll_queue, b43_rfkill_work);
>
> - rfk->registered = 1;
> + init_timer(&rfk->poll_timer);
> + rfk->poll_timer.function = b43_rfkill_poll;
> + rfk->poll_timer.expires = round_jiffies(jiffies + HZ);
> + rfk->poll_timer.data = (unsigned long)rfk;
> + add_timer(&rfk->poll_timer);
>
> return;
> -err_unreg_rfk:
> - rfkill_unregister(rfk->rfkill);
> -err_free_polldev:
> - input_free_polled_device(rfk->poll_dev);
> - rfk->poll_dev = NULL;
> -err_freed_rfk:
> +err_free_rfk:
> + rfkill_free(rfk->rfkill);
> rfk->rfkill = NULL;
> out_error:
> rfk->registered = 0;
> @@ -197,9 +192,8 @@ void b43_rfkill_exit(struct b43_wldev *d
> return;
> rfk->registered = 0;
>
> - input_unregister_polled_device(rfk->poll_dev);
> + del_timer(&rfk->poll_timer);
> +
cancel the work. I'm not sure whether to do it here, however.
One must take care to avoid deadlocks for wl->mutex.
I don't know from the top of my head whether b43_rfkill_exit is called
with the mutex locked or not. However, in case it is, dropping and
reaquireing the lock is not an option.
> rfkill_unregister(rfk->rfkill);
> - input_free_polled_device(rfk->poll_dev);
> - rfk->poll_dev = NULL;
> rfk->rfkill = NULL;
> }
> Index: wireless-testing/drivers/net/wireless/b43/rfkill.h
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43/rfkill.h
> +++ wireless-testing/drivers/net/wireless/b43/rfkill.h
> @@ -7,14 +7,14 @@ struct b43_wldev;
> #ifdef CONFIG_B43_RFKILL
>
> #include <linux/rfkill.h>
> -#include <linux/input-polldev.h>
> -
>
> struct b43_rfkill {
> /* The RFKILL subsystem data structure */
> struct rfkill *rfkill;
> - /* The poll device for the RFKILL input button */
> - struct input_polled_dev *poll_dev;
> + /* The timer list for the RFKILL polling */
> + struct timer_list poll_timer;
> + /* Workqueue for the RFKILL polling */
> + struct work_struct poll_queue;
> /* Did initialization succeed? Used for freeing. */
> bool registered;
> /* The unique name of this rfkill switch */
--
Greetings Michael.
next prev parent reply other threads:[~2008-09-18 17:32 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-18 5:07 [RFC] b43: A patch for control of the radio LED using rfkill Larry Finger
2008-09-18 13:19 ` Ivo van Doorn
2008-09-18 13:47 ` Larry Finger
2008-09-18 13:53 ` Ivo van Doorn
2008-09-18 14:21 ` Henrique de Moraes Holschuh
2008-09-18 14:26 ` Ivo van Doorn
2008-09-18 14:52 ` Henrique de Moraes Holschuh
2008-09-18 15:19 ` [PATCH] rfkill: clarify usage of rfkill_force_state() and rfkill->get_state() Henrique de Moraes Holschuh
2008-09-18 15:24 ` Ivo van Doorn
2008-09-18 16:43 ` Henrique de Moraes Holschuh
2008-09-18 16:45 ` Johannes Berg
2008-09-18 17:32 ` Ivo van Doorn
2008-09-18 17:52 ` Johannes Berg
2008-09-18 18:12 ` Ivo van Doorn
2008-09-18 17:40 ` Ivo van Doorn
2008-09-18 17:41 ` [RFC] b43: A patch for control of the radio LED using rfkill Michael Buesch
2008-09-18 17:37 ` Michael Buesch
2008-09-18 17:48 ` Ivo van Doorn
2008-09-18 17:56 ` Michael Buesch
2008-09-18 18:10 ` Ivo van Doorn
2008-09-18 18:17 ` Michael Buesch
2008-09-18 18:23 ` Ivo van Doorn
2008-09-18 18:34 ` Michael Buesch
2008-09-18 18:36 ` Johannes Berg
2008-09-18 19:23 ` Henrique de Moraes Holschuh
2008-09-18 20:09 ` Ivo van Doorn
2008-09-18 19:08 ` Henrique de Moraes Holschuh
2008-09-18 20:17 ` Ivo van Doorn
2008-09-18 20:28 ` Henrique de Moraes Holschuh
2008-09-18 20:42 ` Ivo van Doorn
2008-09-18 17:34 ` Michael Buesch
2008-09-18 17:42 ` Ivo van Doorn
2008-09-18 17:49 ` Johannes Berg
2008-09-18 18:02 ` Ivo van Doorn
2008-09-18 19:50 ` Henrique de Moraes Holschuh
2008-09-18 17:53 ` Michael Buesch
2008-09-18 18:06 ` Ivo van Doorn
2008-09-18 14:10 ` Henrique de Moraes Holschuh
2008-09-18 14:24 ` Ivo van Doorn
2008-09-18 14:37 ` Henrique de Moraes Holschuh
2008-09-18 15:16 ` Ivo van Doorn
2008-09-18 16:08 ` Henrique de Moraes Holschuh
2008-09-18 16:51 ` Ivo van Doorn
2008-09-18 18:47 ` Henrique de Moraes Holschuh
2008-09-18 19:14 ` Johannes Berg
2008-09-18 20:35 ` Ivo van Doorn
2008-09-18 21:34 ` Henrique de Moraes Holschuh
2008-09-18 17:44 ` Michael Buesch
2008-09-18 17:52 ` Ivo van Doorn
2008-09-18 17:54 ` Johannes Berg
2008-09-18 18:06 ` Ivo van Doorn
2008-09-18 18:13 ` Johannes Berg
2008-09-18 20:10 ` Henrique de Moraes Holschuh
2008-09-18 20:41 ` Ivo van Doorn
2008-09-18 21:36 ` Henrique de Moraes Holschuh
2008-09-19 17:02 ` Ivo van Doorn
2008-09-20 13:10 ` Henrique de Moraes Holschuh
2008-09-20 13:20 ` Ivo van Doorn
2008-09-22 3:01 ` Henrique de Moraes Holschuh
2008-09-22 21:16 ` Michael Buesch
2008-09-18 17:31 ` Michael Buesch [this message]
2008-09-18 20:13 ` 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=200809181931.49636.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=Larry.Finger@lwfinger.net \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.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 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).