rfkill-input to be removed

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.

Il 21/04/2011 10:28, Marco Chiappero ha scritto:

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?

@@ -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);

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

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

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

johannes

Il 21/04/2011 18:22, Johannes Berg ha scritto:

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

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).