rfkill-input to be removed

rfkill-input to be removed

[Marco Chiappero]

While working on the the sony-laptop driver, adding support for 
persistent rfkill state storing and adding the SW_RFKILL_ALL switch 
event forwarding to the input core to notify userspace, I realized that 
rfkill-input interferes with correct behavior of the driver, vanishing 
the hardware device state storing. Then, looking at 
Documentation/feature-removal-schedule.txt I realized that rfkill-input 
was scheduled to be removed in 2.6.33, but it's still there in 2.6.39. 
Please remove that code as soon as possible, rfkill input events should 
be handled by user space tools.

Re: rfkill-input to be removed

[Marco Chiappero]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

Il 21/04/2011 10:28, Marco Chiappero ha scritto:
> Please remove that code as soon as possible, rfkill input events should
> be handled by user space tools.

About this topic, I've created a patch right now, you can find it here:
http://www.absence.it/vaio-acpi/source/patches/rfkill-input.patch
Does it look fine?

Moreover, using checkpatch.pl I've found 3 coding style errors, I'm 
attaching a patch to fix them (apply this one first).

And just one last thing: as there is no configuration option inside the 
menu, shouldn't we change the "menuconfig RFKILL" line to "config 
RFKILL" inside net/rfkill/Kconfig?

[-- Attachment #2: rfkill-style.patch --]
[-- Type: text/x-patch, Size: 982 bytes --]

Signed-off-by: Marco Chiappero <marco@absence.it>
--- a/net/rfkill/core.c	2011-04-19 06:26:00.000000000 +0200
+++ b/net/rfkill/core.c	2011-04-21 15:33:21.970094489 +0200
@@ -621,7 +621,7 @@ static ssize_t rfkill_hard_show(struct d
 {
 	struct rfkill *rfkill = to_rfkill(dev);
 
-	return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_HW) ? 1 : 0 );
+	return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_HW) ? 1 : 0);
 }
 
 static ssize_t rfkill_soft_show(struct device *dev,
@@ -630,7 +630,7 @@ static ssize_t rfkill_soft_show(struct d
 {
 	struct rfkill *rfkill = to_rfkill(dev);
 
-	return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_SW) ? 1 : 0 );
+	return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_SW) ? 1 : 0);
 }
 
 static ssize_t rfkill_soft_store(struct device *dev,
@@ -648,7 +648,7 @@ static ssize_t rfkill_soft_store(struct 
 	if (err)
 		return err;
 
-	if (state > 1 )
+	if (state > 1)
 		return -EINVAL;
 
 	mutex_lock(&rfkill_global_mutex);

Re: rfkill-input to be removed

[Dan Williams]

On Thu, 2011-04-21 at 15:47 +0200, Marco Chiappero wrote:
> Il 21/04/2011 10:28, Marco Chiappero ha scritto:
> > Please remove that code as soon as possible, rfkill input events should
> > be handled by user space tools.
> 
> About this topic, I've created a patch right now, you can find it here:
> http://www.absence.it/vaio-acpi/source/patches/rfkill-input.patch
> Does it look fine?

You'll want to follow the patch submission guidelines:

http://linux.yyz.us/patch-format.html

before people will look at the patch, because many of the people who
would look at it are quite busy.  That means:

1) use a subject like "[PATCH] rfkill-input: remove deprecated module"
2) Add your Signed-off-by: Your Name <your email>
3) paste your patch *inline*, not as an attachment, and make *sure* to
use the "preformat" or whatever option when you do, so that your mailer
doesn't wrap long lines

Dan

> Moreover, using checkpatch.pl I've found 3 coding style errors, I'm 
> attaching a patch to fix them (apply this one first).
> 
> And just one last thing: as there is no configuration option inside the 
> menu, shouldn't we change the "menuconfig RFKILL" line to "config 
> RFKILL" inside net/rfkill/Kconfig?

Re: rfkill-input to be removed

[Johannes Berg]

On Thu, 2011-04-21 at 10:28 +0200, Marco Chiappero wrote:
> While working on the the sony-laptop driver, adding support for 
> persistent rfkill state storing and adding the SW_RFKILL_ALL switch 
> event forwarding to the input core to notify userspace, I realized that 
> rfkill-input interferes with correct behavior of the driver, vanishing 
> the hardware device state storing. 

Yeah we noticed this before with some other drivers. The persistent
stuff seems to only be suitable for a small number of semantics.

> Then, looking at 
> Documentation/feature-removal-schedule.txt I realized that rfkill-input 
> was scheduled to be removed in 2.6.33, but it's still there in 2.6.39. 
> Please remove that code as soon as possible, rfkill input events should 
> be handled by user space tools.

Frankly, I don't think we're ready for this yet, most distros don't yet
ship the rfkill daemon.

johannes

Re: rfkill-input to be removed

[Marco Chiappero]

Il 21/04/2011 18:22, Johannes Berg ha scritto:
> Yeah we noticed this before with some other drivers. The persistent
> stuff seems to only be suitable for a small number of semantics.

Sorry, what do you mean exactly? The persistent stuff seems to work well 
with those notebooks.

> Frankly, I don't think we're ready for this yet, most distros don't yet
> ship the rfkill daemon.

Ok, in the meantime I'm going to avoid the SW_RFKILL_ALL switch event 
forwarding, unless the master_switch_mode=1 is going to be changed to 
honor the stored power state on drivers loading as well, not only when 
moving the "kill all" switch (it seems that on boot every device is 
always turned on, which is very annoying).