Skip to contentSkip to conversation

b43: Use input-polldev for the rfkill switch

PATCH In review Michael Buesch 3 participants 11 messages Sep 28, 2007 – Oct 10, 2007 Networking drivers (wireless)

lore
Share & tools
lore

Michael Buesch

author
#0 lore raw

PATCH 1/1 b43: Use input-polldev for the rfkill switch

This removes the direct call to rfkill on an rfkill event and replaces it with an input device. This way userspace is also notified about the event.

Signed-off-by Michael Buesch <[email protected]>
drivers/net/wireless/b43/Kconfig +1 -1
Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===================================================================
@@ -70,7 +70,7 @@ config B43_LEDS
 # RFKILL support
 config B43_RFKILL
 	bool
-	depends on B43 && RFKILL
+	depends on B43 && RFKILL && RFKILL_INPUT && INPUT_POLLDEV
 	default y
 
 config B43_DEBUG
drivers/net/wireless/b43/main.c +12 -41

103 lines not on this page · raw message

drivers/net/wireless/b43/rfkill.c +79 -50

163 lines not on this page · raw message

drivers/net/wireless/b43/rfkill.h +15 -6
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.h
===================================================================
@@ -7,19 +7,25 @@ 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 unique name of this rfkill switch */
 	char name[32];
-	/* Workqueue for asynchronous notification. */
-	struct work_struct notify_work;
 };
 
+/* All the init functions return void, because we are not interested
+ * in failing the b43 init process when rfkill init failed. */
+void b43_rfkill_alloc(struct b43_wldev *dev);
+void b43_rfkill_free(struct b43_wldev *dev);
 void b43_rfkill_init(struct b43_wldev *dev);
 void b43_rfkill_exit(struct b43_wldev *dev);
-void b43_rfkill_toggled(struct b43_wldev *dev, bool on);
+
 char * b43_rfkill_led_name(struct b43_wldev *dev);
 
 

@@ -30,13 +36,16 @@ struct b43_rfkill {
 	/* empty */
 };
 
-static inline void b43_rfkill_init(struct b43_wldev *dev)
+static inline void b43_rfkill_alloc(struct b43_wldev *dev)
 {
 }
-static inline void b43_rfkill_exit(struct b43_wldev *dev)
+static inline void b43_rfkill_free(struct b43_wldev *dev)
 {
 }
-static inline void b43_rfkill_toggled(struct b43_wldev *dev, bool on)
+static inline void b43_rfkill_init(struct b43_wldev *dev)
+{
+}
+static inline void b43_rfkill_exit(struct b43_wldev *dev)
 {
 }
 static inline char * b43_rfkill_led_name(struct b43_wldev *dev)
#1 lore raw
Quoted 5 lines · Michael Buesch

This removes the direct call to rfkill on an rfkill event and replaces it with an input device. This way userspace is also notified about the event.

Signed-off-by Michael Buesch <[email protected]>

...

Quoted 44 lines

static void do_periodic_work(struct b43_wldev *dev) {

drivers/net/wireless/b43/main.c +8 -12
 	unsigned int state;
 
 	state = dev->periodic_state;
-	if (state % 120 == 0)
+	if (state % 8 == 0)
 		b43_periodic_every120sec(dev);
-	if (state % 60 == 0)
+	if (state % 4 == 0)
 		b43_periodic_every60sec(dev);
-	if (state % 30 == 0)
+	if (state % 2 == 0)
 		b43_periodic_every30sec(dev);
-	if (state % 15 == 0)
-		b43_periodic_every15sec(dev);
-	b43_periodic_every1sec(dev);
+	b43_periodic_every15sec(dev);
 }
 
 /* Estimate a "Badness" value based on the periodic work

@@ -2429,13 +2400,11 @@ static int estimate_periodic_work_badnes
 {
 	int badness = 0;
 
-	if (state % 120 == 0)	/* every 120 sec */
+	if (state % 8 == 0)	/* every 120 sec */
 		badness += 10;
-	if (state % 60 == 0)	/* every 60 sec */
+	if (state % 4 == 0)	/* every 60 sec */
 		badness += 5;
-	if (state % 30 == 0)	/* every 30 sec */
-		badness += 1;
-	if (state % 15 == 0)	/* every 15 sec */
+	if (state % 2 == 0)	/* every 30 sec */
 		badness += 1;
 
 #define BADNESS_LIMIT	4

@@ -2486,13 +2455,13 @@ static void b43_periodic_work_handler(st
 		spin_unlock_irqrestore(&dev->wl->irq_lock, flags);
 	}
 	dev->periodic_state++;
-      out_requeue:
+out_requeue:

drivers/net/wireless/b43/main.c static void b43_periodic_work_handler(st · line 2466

Quoted 10 lines
drivers/net/wireless/b43/main.c +2 -2
 	if (b43_debug(dev, B43_DBG_PWORK_FAST))
 		delay = msecs_to_jiffies(50);
 	else
-		delay = round_jiffies(HZ);
+		delay = round_jiffies(HZ * 15);
 	queue_delayed_work(dev->wl->hw->workqueue, &dev->periodic_work, delay);
-      out:
+out:
 	mutex_unlock(&dev->wl->mutex);
 }

Does this bit belong to your other patch?

Signature · 1 line
dwmw2
author
#2 lore raw
Quoted 1 line · On Saturday 29 September 2007 18:52:48 David Woodhouse wrote:

Does this bit belong to your other patch?

I'm not sure what you are trying to ask.

Signature · 1 line
Greetings Michael.
#3 lore raw
Quoted 1 line · Michael Buesch

I'm not sure what you are trying to ask.

The hunks I quoted don't seem relevant to the rfkill switch. They seem to be related to periodic work, which was the subject of the other patch you posted at about the same time. Did you get them mixed up?

Signature · 1 line
dwmw2
author
#4 lore raw
Quoted 6 lines · On Saturday 29 September 2007 19:14:34 David Woodhouse wrote:
Quoted 1 line · Michael Buesch

I'm not sure what you are trying to ask.

The hunks I quoted don't seem relevant to the rfkill switch. They seem to be related to periodic work, which was the subject of the other patch you posted at about the same time. Did you get them mixed up?

The patch is correct as-is. RF-kill was polled by the periodic work.

Signature · 1 line
Greetings Michael.
#5 lore raw
Quoted 1 line · Michael Buesch

The patch is correct as-is. RF-kill was polled by the periodic work.

OK, cool. Just checking.

Signature · 1 line
dwmw2
#6 lore raw
In reply to Michael Buesch

Hi Michael,

Quoted 11 lines · Michael Buesch

This removes the direct call to rfkill on an rfkill event and replaces it with an input device. This way userspace is also notified about the event.

Signed-off-by Michael Buesch <[email protected]>

Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===================================================================

drivers/net/wireless/b43/Kconfig 2007-09-28 12:34:23.000000000 +0200 config B43_LEDS · line 74

Quoted 6 lines
drivers/net/wireless/b43/Kconfig 2007-09-28 12:34:23.000000000 +0200 renamed from drivers/net/wireless/b43/Kconfig 2007-09-27 21:31:15.000000000 +0200 +1 -1
@@ -70,7 +70,7 @@ config B43_LEDS
 # RFKILL support
 config B43_RFKILL
       bool
-       depends on B43 && RFKILL
+       depends on B43 && RFKILL && RFKILL_INPUT && INPUT_POLLDEV
       default y

I don't think that broadcom driver should depend on RFKILL_INPUT... RFKILL_INPUT is a default link between input and rfkill layers but it is by no means a mandatory component.

I think proper dependency should be:

        depends on B43 && RFKILL && INPUT
        select INPUT_POLLDEV
Signature · 1 line
Dmitry
author
#7 lore raw
Quoted 25 lines · On Wednesday 10 October 2007 16:30:35 Dmitry Torokhov wrote:

Hi Michael,

Quoted 11 lines · Michael Buesch

This removes the direct call to rfkill on an rfkill event and replaces it with an input device. This way userspace is also notified about the event.

Signed-off-by Michael Buesch <[email protected]>

Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===================================================================

drivers/net/wireless/b43/Kconfig 2007-09-28 12:34:23.000000000 +0200 config B43_LEDS · line 74

Quoted 6 lines
drivers/net/wireless/b43/Kconfig 2007-09-28 12:34:23.000000000 +0200 renamed from drivers/net/wireless/b43/Kconfig 2007-09-27 21:31:15.000000000 +0200 +1 -1
@@ -70,7 +70,7 @@ config B43_LEDS
 # RFKILL support
 config B43_RFKILL
       bool
-       depends on B43 && RFKILL
+       depends on B43 && RFKILL && RFKILL_INPUT && INPUT_POLLDEV
       default y

I don't think that broadcom driver should depend on RFKILL_INPUT... RFKILL_INPUT is a default link between input and rfkill layers but it is by no means a mandatory component.

Quoted 5 lines

I think proper dependency should be:

        depends on B43 && RFKILL && INPUT
        select INPUT_POLLDEV

b43 rfkill support is useless without also having RFKILL_INPUT, as the button reporting is done though it.
b43 does _not_ depend on RFKILL_INPUT, but b43-rfkill support is disabled, if there's no RFKILL_INPUT compiled.

Signature · 1 line
Greetings Michael.
#8 lore raw
Quoted 28 lines · Michael Buesch
Quoted 27 lines · On Wednesday 10 October 2007 16:30:35 Dmitry Torokhov wrote:

Hi Michael,

Quoted 11 lines · Michael Buesch

This removes the direct call to rfkill on an rfkill event and replaces it with an input device. This way userspace is also notified about the event.

Signed-off-by Michael Buesch <[email protected]>

Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===================================================================

drivers/net/wireless/b43/Kconfig 2007-09-28 12:34:23.000000000 +0200 config B43_LEDS · line 74

Quoted 6 lines
drivers/net/wireless/b43/Kconfig 2007-09-28 12:34:23.000000000 +0200 renamed from drivers/net/wireless/b43/Kconfig 2007-09-27 21:31:15.000000000 +0200 +1 -1
@@ -70,7 +70,7 @@ config B43_LEDS
 # RFKILL support
 config B43_RFKILL
       bool
-       depends on B43 && RFKILL
+       depends on B43 && RFKILL && RFKILL_INPUT && INPUT_POLLDEV
       default y

I don't think that broadcom driver should depend on RFKILL_INPUT... RFKILL_INPUT is a default link between input and rfkill layers but it is by no means a mandatory component.

I think proper dependency should be:

Quoted 9 lines
Quoted 3 lines
        depends on B43 && RFKILL && INPUT
        select INPUT_POLLDEV

b43 rfkill support is useless without also having RFKILL_INPUT, as the button reporting is done though it.
b43 does _not_ depend on RFKILL_INPUT, but b43-rfkill support is disabled, if there's no RFKILL_INPUT compiled.

No, it is not. One can have a userspace daemon claiming the rfkill switch and listening on corresponding evdevX interface and managing the switch state.

We normally specify dependencies that are needed to build the code, not necessarily to use it. It's like various joystick drivers do not depend on joydev or evdev modules although most people would need these modules as well to use their joysticks. Or SCSI drivers don't depend on sd or sr being selected, etc, etc.

Thanks.

Signature · 1 line
Dmitry
author
#9 lore raw
Quoted 10 lines · On Wednesday 10 October 2007 16:51:38 Dmitry Torokhov wrote:
Quoted 10 lines
Quoted 9 lines

I don't think that broadcom driver should depend on RFKILL_INPUT... RFKILL_INPUT is a default link between input and rfkill layers but it is by no means a mandatory component.

I think proper dependency should be:

        depends on B43 && RFKILL && INPUT
        select INPUT_POLLDEV
Quoted 8 lines
Quoted 5 lines

b43 rfkill support is useless without also having RFKILL_INPUT, as the button reporting is done though it.
b43 does _not_ depend on RFKILL_INPUT, but b43-rfkill support is disabled, if there's no RFKILL_INPUT compiled.

No, it is not. One can have a userspace daemon claiming the rfkill switch...

No, that's impossible with b43.

Quoted 5 lines

We normally specify dependencies that are needed to build the code, not necessarily to use it. It's like various joystick drivers do not depend on joydev or evdev modules although most people would need these modules as well to use their joysticks. Or SCSI drivers don't depend on sd or sr being selected, etc, etc.

Yeah, well. As I said. This is not a dependency. It's an auto-select option, which automatically selects the code.

Signature · 1 line
Greetings Michael.
#10 lore raw
Quoted 17 lines · Michael Buesch
Quoted 16 lines · On Wednesday 10 October 2007 16:51:38 Dmitry Torokhov wrote:
Quoted 15 lines
Quoted 9 lines

I don't think that broadcom driver should depend on RFKILL_INPUT... RFKILL_INPUT is a default link between input and rfkill layers but it is by no means a mandatory component.

I think proper dependency should be:

        depends on B43 && RFKILL && INPUT
        select INPUT_POLLDEV

b43 rfkill support is useless without also having RFKILL_INPUT, as the button reporting is done though it.
b43 does _not_ depend on RFKILL_INPUT, but b43-rfkill support is disabled, if there's no RFKILL_INPUT compiled.

Quoted 5 lines
Quoted 2 lines

No, it is not. One can have a userspace daemon claiming the rfkill switch...

No, that's impossible with b43.

Ah, OK. I see that you added "user_claim_unsupported" to rfkill and just rely on rfkill-input to update internal state of rfkill. I don't think it is a good solution - userspace may issue EVIOCGRAB on corresponding evdev node which will cause rfkill-input to miss all events.

It looks like we need to allow rfkill-implementing drivers that do not allow software control their RF state to change rfkill state directly.

Signature · 1 line
Dmitry