From: Andriy Stepanov <[email protected]>
Use as:
modprobe rfkill unblocked=1
or
/etc/modprobe.d/options
options rfkill unblocked=1
Signed-off-by: Andriy Stepanov <[email protected]>
---
net/rfkill/core.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index be90640..9d9014a 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -47,6 +47,10 @@
RFKILL_BLOCK_SW_PREV)
#define RFKILL_BLOCK_SW_SETCALL BIT(31)
+int rfkill_unblocked;
+module_param_named(unblocked, rfkill_unblocked, int, 0);
+MODULE_PARM_DESC(unblocked, "rfkill subsystem become inactive.");
+
struct rfkill {
spinlock_t lock;
@@ -455,6 +459,10 @@ bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
{
bool ret, change;
+ if (rfkill_unblocked) {
+ return blocked;
+ }
+
ret = __rfkill_set_hw_state(rfkill, blocked, &change);
if (!rfkill->registered)
@@ -486,6 +494,10 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool blocked)
unsigned long flags;
bool prev, hwblock;
+ if (rfkill_unblocked) {
+ return blocked;
+ }
+
BUG_ON(!rfkill);
spin_lock_irqsave(&rfkill->lock, flags);
@@ -511,6 +523,10 @@ void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked)
{
unsigned long flags;
+ if (rfkill_unblocked) {
+ return;
+ }
+
BUG_ON(!rfkill);
BUG_ON(rfkill->registered);
@@ -526,6 +542,10 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
unsigned long flags;
bool swprev, hwprev;
+ if (rfkill_unblocked) {
+ return;
+ }
+
BUG_ON(!rfkill);
spin_lock_irqsave(&rfkill->lock, flags);
@@ -760,6 +780,10 @@ static int rfkill_dev_uevent(struct device *dev, struct kobj_uevent_env *env)
void rfkill_pause_polling(struct rfkill *rfkill)
{
+ if (rfkill_unblocked) {
+ return;
+ }
+
BUG_ON(!rfkill);
if (!rfkill->ops->poll)
@@ -771,6 +795,10 @@ EXPORT_SYMBOL(rfkill_pause_polling);
void rfkill_resume_polling(struct rfkill *rfkill)
{
+ if (rfkill_unblocked) {
+ return;
+ }
+
BUG_ON(!rfkill);
if (!rfkill->ops->poll)
@@ -818,6 +846,10 @@ bool rfkill_blocked(struct rfkill *rfkill)
unsigned long flags;
u32 state;
+ if (rfkill_unblocked) {
+ return false;
+ }
+
spin_lock_irqsave(&rfkill->lock, flags);
state = rfkill->state;
spin_unlock_irqrestore(&rfkill->lock, flags);
@@ -836,6 +868,11 @@ struct rfkill * __must_check rfkill_alloc(const char *name,
struct rfkill *rfkill;
struct device *dev;
+ if (rfkill_unblocked) {
+ printk(KERN_DEBUG "rfkill: ignore object allocation.\n");
+ return ERR_PTR(-ENODEV);
+ }
+
if (WARN_ON(!ops))
return NULL;
@@ -915,6 +952,14 @@ int __must_check rfkill_register(struct rfkill *rfkill)
struct device *dev = &rfkill->dev;
int error;
+ if (rfkill_unblocked) {
+ if (rfkill == ERR_PTR(-ENODEV)) {
+ return 0;
+ } else {
+ return -EINVAL;
+ }
+ }
+
BUG_ON(!rfkill);
mutex_lock(&rfkill_global_mutex);
@@ -978,6 +1023,10 @@ void rfkill_unregister(struct rfkill *rfkill)
{
BUG_ON(!rfkill);
+ if (rfkill_unblocked) {
+ return;
+ }
+
if (rfkill->ops->poll)
cancel_delayed_work_sync(&rfkill->poll_work);
@@ -999,6 +1048,11 @@ EXPORT_SYMBOL(rfkill_unregister);
void rfkill_destroy(struct rfkill *rfkill)
{
+
+ if (rfkill_unblocked) {
+ return;
+ }
+
if (rfkill)
put_device(&rfkill->dev);
}
--
1.7.4.4
On Tue, 2011-09-27 at 12:03 +0400, Andrew V. Stepanov wrote:
> On Tue, Sep 27, 2011 at 11:46 AM, Johannes Berg
> <[email protected]> wrote:
> > On Tue, 2011-09-27 at 14:33 +0400, Andrew V. Stepanov wrote:
> >> From: Andriy Stepanov <[email protected]>
> >>
> >> Use as:
> >> modprobe rfkill unblocked=1
> >> or
> >> /etc/modprobe.d/options
> >> options rfkill unblocked=1
> >
> > Apart from the obvious style problems in this patch (tons of extra
> > braces) I'm not convinced this is a good idea.
> >
> > What problem does it solve? Why can that problem not be solved
> > differently with existing mechanisms (e.g. urfkilld configured to do
> > nothing)?
> 2. urfkilld can't be used to ignore Hard blocked buttons.
Oh that's a good point -- so NACK on the patch.
You *can't* ignore hard block buttons. All you can ignore is events from
them, which is definitely not useful.
johannes
On Tue, 27 Sep 2011, Johannes Berg wrote:
> > This patch give ability disable rfkill sub-system by means to pass
> > special module parameter.
>
> Because the platform driver is doing the wrong thing.
Hmm? Is it?
> > Example from real life. Some company want to make inactive rfkill
> > SW+HW buttons on some company notebooks.
> > For this, you advise to recompile kernel.
>
> No, you need to fix the thinkpad driver.
Eh, I can certainly blacklist platform rfkill support for the x201i on the
grounds that it is a piece of crap, since a hardware button that does it in
software is clearly el-cheap-o land that does not belong to something that
dares call itself a ThinkPad X-series. But I am not sure this is the best
way to go about it. It will cause that switch to become useless, for one.
I can map it to a soft rfkill button, which seems to be more in line with
the real truth behind it. But this is very weird, the EC used to even kick
bluetooth out of the USB bus when that switch was enabled...
dmidecode dump, please. And I'd really appreciate a _full_ report of the
issue and behaviour of the rfkill hw button on the x201i, please send it to
[email protected], and we can take the thread there.
I'd ask it to be done through bugzilla.kernel.org, but that's still down.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Tue, Sep 27, 2011 at 3:08 PM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2011-09-27 at 13:34 +0400, Andrew V. Stepanov wrote:
>> On Tue, Sep 27, 2011 at 12:54 PM, Johannes Berg
>> <[email protected]> wrote:
>> > On Tue, 2011-09-27 at 12:46 +0400, Andrew V. Stepanov wrote:
>> >
>> >> I wan't to completely ignore events (state) of software\hardware rfkill buttons.
>> >
>> > Why would you ever want to do that? I can see that you might want to
>> > ignore soft buttons, but you can use urfkilld for that. Ignoring hard
>> > buttons is completely useless -- they will affect the device they're
>> > wired up to *anyway*.
>>
>> No. That is not true.
>>
>> Hardware rfkill button doesn't have any action to wlan\bluetooth
>> devices on ThinkPad x201i with "CONFIG_RFKILL is not set".
>> I can assume this is true for other notebooks.
>
> Then why is it a hard button instead of the soft button on a separate
> platform device?
>
> johannes
>
1.
Lenovo ThinkPad x201i has two rfkill buttons.
One soft: Fn-F5.
Second hard: small switch on left case side.
With RFKILL_CONFIG == "is not set" this two buttons became inactive.
They do not has any influence to adapter\drivers state.
This patch give ability disable rfkill sub-system by means to pass
special module parameter.
Example from real life. Some company want to make inactive rfkill
SW+HW buttons on some company notebooks.
For this, you advise to recompile kernel.
2.
One more thing, why this patch is necessary. You advise to use
urfkilld. But this is doesn't help in case of external USB WIFI
devices.
Turn on(off) HW button will be effect on all WIFI devices, even
external. rfkill kernel subsystem will bring all cfg80211 devices to
software lock. See: net/wireless/core.c for rfkill. I do not think,
that urfkilld will help.
On Tue, Sep 27, 2011 at 12:08 PM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2011-09-27 at 12:03 +0400, Andrew V. Stepanov wrote:
>> On Tue, Sep 27, 2011 at 11:46 AM, Johannes Berg
>> <[email protected]> wrote:
>> > On Tue, 2011-09-27 at 14:33 +0400, Andrew V. Stepanov wrote:
>> >> From: Andriy Stepanov <[email protected]>
>> >>
>> >> Use as:
>> >> modprobe rfkill unblocked=1
>> >> or
>> >> /etc/modprobe.d/options
>> >> options rfkill unblocked=1
>> >
>> > Apart from the obvious style problems in this patch (tons of extra
>> > braces) I'm not convinced this is a good idea.
>> >
>> > What problem does it solve? Why can that problem not be solved
>> > differently with existing mechanisms (e.g. urfkilld configured to do
>> > nothing)?
>
>> 2. urfkilld ?can't be used to ignore Hard blocked buttons.
>
> Oh that's a good point -- so NACK on the patch.
>
> You *can't* ignore hard block buttons. All you can ignore is events from
> them, which is definitely not useful.
>
> johannes
>
>
I wan't to completely ignore events (state) of software\hardware rfkill buttons.
One solution for this, is to compile Linux kernel with "CONFIG_RFKILLL
is no net".
Than hardware/software rfkill buttons dosn't have any action to wlan-interfaces.
Other method is use this patch.
Do you know third method ?
On Tue, 2011-09-27 at 13:34 +0400, Andrew V. Stepanov wrote:
> On Tue, Sep 27, 2011 at 12:54 PM, Johannes Berg
> <[email protected]> wrote:
> > On Tue, 2011-09-27 at 12:46 +0400, Andrew V. Stepanov wrote:
> >
> >> I wan't to completely ignore events (state) of software\hardware rfkill buttons.
> >
> > Why would you ever want to do that? I can see that you might want to
> > ignore soft buttons, but you can use urfkilld for that. Ignoring hard
> > buttons is completely useless -- they will affect the device they're
> > wired up to *anyway*.
>
> No. That is not true.
>
> Hardware rfkill button doesn't have any action to wlan\bluetooth
> devices on ThinkPad x201i with "CONFIG_RFKILL is not set".
> I can assume this is true for other notebooks.
Then why is it a hard button instead of the soft button on a separate
platform device?
johannes
On Tue, Sep 27, 2011 at 12:54 PM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2011-09-27 at 12:46 +0400, Andrew V. Stepanov wrote:
>
>> I wan't to completely ignore events (state) of software\hardware rfkill buttons.
>
> Why would you ever want to do that? I can see that you might want to
> ignore soft buttons, but you can use urfkilld for that. Ignoring hard
> buttons is completely useless -- they will affect the device they're
> wired up to *anyway*.
No. That is not true.
Hardware rfkill button doesn't have any action to wlan\bluetooth
devices on ThinkPad x201i with "CONFIG_RFKILL is not set".
I can assume this is true for other notebooks.
>
> johannes
>
On Tue, 2011-09-27 at 12:46 +0400, Andrew V. Stepanov wrote:
> I wan't to completely ignore events (state) of software\hardware rfkill buttons.
Why would you ever want to do that? I can see that you might want to
ignore soft buttons, but you can use urfkilld for that. Ignoring hard
buttons is completely useless -- they will affect the device they're
wired up to *anyway*.
johannes
On Tue, Sep 27, 2011 at 11:46 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2011-09-27 at 14:33 +0400, Andrew V. Stepanov wrote:
>> From: Andriy Stepanov <[email protected]>
>>
>> Use as:
>> modprobe rfkill unblocked=1
>> or
>> /etc/modprobe.d/options
>> options rfkill unblocked=1
>
> Apart from the obvious style problems in this patch (tons of extra
> braces) I'm not convinced this is a good idea.
>
> What problem does it solve? Why can that problem not be solved
> differently with existing mechanisms (e.g. urfkilld configured to do
> nothing)?
>
> johannes
>
1. I can remove extra braces.
2. urfkilld can't be used to ignore Hard blocked buttons.
On Tue, 2011-09-27 at 15:50 +0400, Andrew V. Stepanov wrote:
> 1.
>
> Lenovo ThinkPad x201i has two rfkill buttons.
> One soft: Fn-F5.
> Second hard: small switch on left case side.
>
> With RFKILL_CONFIG == "is not set" this two buttons became inactive.
> They do not has any influence to adapter\drivers state.
Then the hard one isn't actually a hard button. The typical hard button
is a switch that is wired directly to the mini-pcie slot and
enables/disables the card via a GPIO line on the card. This is reported
as a hard even *through the wifi card*. Nothing you can do about it in
those cases.
> This patch give ability disable rfkill sub-system by means to pass
> special module parameter.
Because the platform driver is doing the wrong thing.
> Example from real life. Some company want to make inactive rfkill
> SW+HW buttons on some company notebooks.
> For this, you advise to recompile kernel.
No, you need to fix the thinkpad driver.
> 2.
>
> One more thing, why this patch is necessary. You advise to use
> urfkilld. But this is doesn't help in case of external USB WIFI
> devices.
>
> Turn on(off) HW button will be effect on all WIFI devices, even
> external. rfkill kernel subsystem will bring all cfg80211 devices to
> software lock. See: net/wireless/core.c for rfkill. I do not think,
> that urfkilld will help.
No, it will not. It doesn't work that way. A hard switch in one wifi
device doesn't impact any other devices unless you use urfkilld or
RFKILL_INPUT.
johannes
On Tue, 2011-09-27 at 14:33 +0400, Andrew V. Stepanov wrote:
> From: Andriy Stepanov <[email protected]>
>
> Use as:
> modprobe rfkill unblocked=1
> or
> /etc/modprobe.d/options
> options rfkill unblocked=1
Apart from the obvious style problems in this patch (tons of extra
braces) I'm not convinced this is a good idea.
What problem does it solve? Why can that problem not be solved
differently with existing mechanisms (e.g. urfkilld configured to do
nothing)?
johannes