From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: Tobias Doerffel <tobias.doerffel@gmail.com>
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org
Subject: Re: [ath5k-devel] ath5k: initial RFKILL support for Atheros 5xxx cards
Date: Sun, 25 Jan 2009 11:37:48 +0000 [thread overview]
Message-ID: <497C4F0C.3060908@tuffmail.co.uk> (raw)
In-Reply-To: <1232812567-11014-1-git-send-email-tobias.doerffel@gmail.com>
Tobias Doerffel wrote:
> Hi,
>
> as announced here's a reworked patch for RFKILL support. It now features
> actually reading RFKILL state from according GPIO. Furthermore it's not
> a polled input device anymore (and thus does not depend on polled input device
> support in kernel anymore) and handles interrupts instead. Everything for this
> is in place, however it probably still needs some tweaking by someone else as
> I don't have a physical rfkill switch with my netbook.
>
> The same applies for GPIO configuration (pin/polarity) which is read from
> EEPROM. It at least works for me reliably but might not work on other machines.
>
> The LED patches are not included anymore as the radio LED seems to be controlled
> automatically when changing RFKILL state in hardware.
>
> One note on behaviour: rfkill is enabled (i.e. radio disabled) in 3 cases
> - interface is not up
> - "0" is written to /sys/class/rfkill/rfkillX/state
> - physical rf-switch switched off
>
> As mentioned above, I can't guarantee the third case to actually work.
>
> When rfkill is enabled my netbook consumes about 0.8 watts less compared to
> being up, associated and idle.
>
How can I check if the ath5k device on my netbook will be able to
support this? I worry that if this works on my netbook, it is going to
interact badly with the eeepc-laptop platform driver, which also has
rfkill support.
eeepc-laptop uses a somewhat unique mechanism. It's a sort of
platform-specific pci hotplug. Here is my concern:
- When an rfkill device is created, the rfkill core forces it into the
default state (for that type of rfkill switch, e.g. WLAN).
- eeepc-laptop calls rfkill_set_default() on startup. This effectively
allows the global rfkill state to be preserved while the system is
turned off, and restored on startup.
Consider the case where the system starts up with rkfill enabled (i.e.
radio disabled). The ath5k PCI device will not exist. The default
rfkill state will be set to "radio disabled".
As a user of rfkill-input, I press the wireless toggle hotkey. The
global rfkill state changes to disabled (radio enabled). All *existing*
rfkill devices are switched to disabled (radio enabled). The only
rfkill device is eeepc-laptop; so this is disabled, and the PCI device
appears...
When ath5k binds to the PCI device and creates it's rfkill device, it
will inherit the *default* rfkill state, which was set on startup - to
enabled (radio disabled).
Thanks
Alan
parent reply other threads:[~2009-01-25 11:37 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <1232812567-11014-1-git-send-email-tobias.doerffel@gmail.com>]
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=497C4F0C.3060908@tuffmail.co.uk \
--to=alan-jenkins@tuffmail.co.uk \
--cc=ath5k-devel@lists.ath5k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=tobias.doerffel@gmail.com \
/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).