From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: corentincj@iksaif.net, Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Woody Suwalski <woodys@xandros.com>,
Sitsofe Wheeler <sits@sucs.org>,
acpi4asus-user@lists.sourceforge.net,
linux-acpi <linux-acpi@vger.kernel.org>
Subject: Is rfkill class really appropriate for eeepc-laptop?
Date: Fri, 26 Sep 2008 14:49:53 +0100 [thread overview]
Message-ID: <48DCE881.5000501@tuffmail.co.uk> (raw)
In-Reply-To: <48D6AC5E.70502@xandros.com>
Woody Suwalski wrote:
> Alan Jenkins wrote:
>> Woody Suwalski wrote:
>>
>>> > I have found one of the earliest source code snippets we have got
>>> from
>>> > Asus (eeepc_hotkey.tar.gz), and the current one we are using on new
>>> > models (P901 an later - hopefully back compatible?).
<>
>>> > And also - how far is now kernel eeepc support from this acpi
>>> module?
<>
>> The main difference in eeepc-laptop is the shiny new interface. The
>> files are created in /sys/bus/platform/devices/eeepc, instead of
>> /proc/acpi/asus. It uses a recently added generic backlight interface
>> (/sys/class/backlight/eeepc) - so it's the same as all the other "laptop
>> extras" modules. In 2.6.27 it will implements the new generic "rfkill"
>> interface for the wireless toggle. Plus it will generate real input
>> events (as opposed to acpi events) for hotkeys.
<>
> About the rfkill switch - be careful.
> The current /proc/acpi/asus/wlan implementation is actually killing
> the power from wireless chip - as a result we had to do a lot of
> hooplas with pciehp or fakephp to bring the chip up "pci-wise" after
> the sleep.
Hmm, so it does. I guess that makes it unsuitable for a straight port
to the rfkill interface.
The rfkill switch subsystem exists to add a generic interface to
circuitry that
can enable or disable the signal output of a wireless *transmitter*
of any
type. By far, the most common use is to disable radio-frequency
transmitters.
Both the pre-installed OS and the community scripts play these games; I
think you have to reload the pciehp module with a "force" parameter.
I was wrong to say that rfkill support was already in mainline. But it
is introduced by Matthew's patch "eeepc-laptop: Use standard
interfaces", as posted and reviewed on the linux-acpi list. I think
this is a bad idea. Surely the whole point of rfkill is to let
NetworkManager do power management *without* having to do different
things for different laptops?
> Luckily the newest model (e.g. S101) is now using "normal" kill of the
> antenna, which is easy to work with.
Sounds good in theory. Maybe not so good if it does something different
in response to the exact same acpi method :-(.
Alan
next parent reply other threads:[~2008-09-26 13:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080918133144.GA4338@silver.sucs.org>
[not found] ` <48D564A8.7030009@xandros.com>
[not found] ` <20080921102246.GA27071@silver.sucs.org>
[not found] ` <48D660C5.6070204@xandros.com>
[not found] ` <48D69052.1040908@tuffmail.co.uk>
[not found] ` <48D6AC5E.70502@xandros.com>
2008-09-26 13:49 ` Alan Jenkins [this message]
2008-09-26 13:55 ` Is rfkill class really appropriate for eeepc-laptop? Matthew Garrett
2008-09-26 14:14 ` Alan Jenkins
2008-09-26 14:17 ` Matthew Garrett
2008-09-26 16:48 ` Henrique de Moraes Holschuh
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=48DCE881.5000501@tuffmail.co.uk \
--to=alan-jenkins@tuffmail.co.uk \
--cc=acpi4asus-user@lists.sourceforge.net \
--cc=corentincj@iksaif.net \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=sits@sucs.org \
--cc=woodys@xandros.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.