linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: mjg59@srcf.ucam.org, linux-wireless@vger.kernel.org
Subject: Re: Multiple rfkill knobs for the same hardware interface
Date: Tue, 04 Aug 2009 10:13:02 -0700	[thread overview]
Message-ID: <1249405982.3094.23.camel@localhost.localdomain> (raw)
In-Reply-To: <200908041630.00533.arvidjaar@mail.ru>

Hi Andrey,

> This is mostly the same situation as ACPI vs. platform backlight 
> control. Here on Dell XPS M1330:
> 
> {pts/1}% rfkill list
> 0: dell-wifi: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 1: dell-bluetooth: Bluetooth
>         Soft blocked: no
>         Hard blocked: no
> 2: phy0: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 4: hci0: Bluetooth
>         Soft blocked: no
>         Hard blocked: no
> 
> Arguably, either one in the pair is redundant. Moreover, hard disabling 
> wireless (using slider on notebook side):
> 
> {pts/1}% rfkill list
> 0: dell-wifi: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 1: dell-bluetooth: Bluetooth
>         Soft blocked: no
>         Hard blocked: no
> 2: phy0: Wireless LAN
>         Soft blocked: no
>         Hard blocked: yes
> 
> So dell-laptop actually lies claiming that both radios are enabled. Even 
> if this is a bug that can be fixed, having two knobs for exactly the 
> same piece of hardware is confusing at the very least.

this is clearly a bug in the dell-laptop module and it seems that
Matthew fixed that already.

The redundancy is just fine. The new RFKILL subsystem is capable of
handling it and we have OP_CHANGE_ALL for exactly this case. You either
wanna switch Bluetooth on or off. And with a 2.6.31 kernel you can do
exactly this and no longer have to bother with details of the RFKILL
switches representing Bluetooth for example.

Also while we would like to have the platform RFKILL switches mapping to
a device switch, it is in practice not possible since in most cases they
are using some kind of hotplug anyway.

Regards

Marcel



      parent reply	other threads:[~2009-08-04 17:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-04 12:29 Multiple rfkill knobs for the same hardware interface Andrey Borzenkov
2009-08-04 12:43 ` Matthew Garrett
2009-08-04 17:13 ` Marcel Holtmann [this message]

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=1249405982.3094.23.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=arvidjaar@mail.ru \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    /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).