* Is rfkill class really appropriate for eeepc-laptop? [not found] ` <48D6AC5E.70502@xandros.com> @ 2008-09-26 13:49 ` Alan Jenkins 2008-09-26 13:55 ` Matthew Garrett 0 siblings, 1 reply; 5+ messages in thread From: Alan Jenkins @ 2008-09-26 13:49 UTC (permalink / raw) To: corentincj, Matthew Garrett Cc: Woody Suwalski, Sitsofe Wheeler, acpi4asus-user, linux-acpi 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Is rfkill class really appropriate for eeepc-laptop? 2008-09-26 13:49 ` Is rfkill class really appropriate for eeepc-laptop? Alan Jenkins @ 2008-09-26 13:55 ` Matthew Garrett 2008-09-26 14:14 ` Alan Jenkins 2008-09-26 16:48 ` Henrique de Moraes Holschuh 0 siblings, 2 replies; 5+ messages in thread From: Matthew Garrett @ 2008-09-26 13:55 UTC (permalink / raw) To: Alan Jenkins Cc: corentincj, Woody Suwalski, Sitsofe Wheeler, acpi4asus-user, linux-acpi On Fri, Sep 26, 2008 at 02:49:53PM +0100, Alan Jenkins wrote: > 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? No, it's to use allow the OS to control whatever mechanism the platform provides for making the radio stop transmitting. The fact that this is, uh, "interestingly" implemented on the Eee doesn't alter that. We should just sort out the hotplug code... -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Is rfkill class really appropriate for eeepc-laptop? 2008-09-26 13:55 ` 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 1 sibling, 1 reply; 5+ messages in thread From: Alan Jenkins @ 2008-09-26 14:14 UTC (permalink / raw) To: Matthew Garrett Cc: corentincj, Woody Suwalski, Sitsofe Wheeler, acpi4asus-user, linux-acpi Matthew Garrett wrote: > On Fri, Sep 26, 2008 at 02:49:53PM +0100, Alan Jenkins wrote: > > >> 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? >> > > No, it's to use allow the OS to control whatever mechanism the platform > provides for making the radio stop transmitting. The fact that this is, > uh, "interestingly" implemented on the Eee doesn't alter that. So rfkill should be allowed to mean "entire PCI device goes away, network interface will vanish" - just so long as it comes back correctly when re-enabled :-). > We should just sort out the hotplug code... > Ok. I have a little knowledge, I'll see if I can be dangerous. My real question was, is it safe to merge your rfkill support before this is sorted out? Thanks Alan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Is rfkill class really appropriate for eeepc-laptop? 2008-09-26 14:14 ` Alan Jenkins @ 2008-09-26 14:17 ` Matthew Garrett 0 siblings, 0 replies; 5+ messages in thread From: Matthew Garrett @ 2008-09-26 14:17 UTC (permalink / raw) To: Alan Jenkins Cc: corentincj, Woody Suwalski, Sitsofe Wheeler, acpi4asus-user, linux-acpi On Fri, Sep 26, 2008 at 03:14:48PM +0100, Alan Jenkins wrote: > Matthew Garrett wrote: > > No, it's to use allow the OS to control whatever mechanism the platform > > provides for making the radio stop transmitting. The fact that this is, > > uh, "interestingly" implemented on the Eee doesn't alter that. > > So rfkill should be allowed to mean "entire PCI device goes away, > network interface will vanish" - just so long as it comes back correctly > when re-enabled :-). Sure, if that's how the platform implements it. This is how almost every bluetooth rfkill interface works, so applications should be able to cope. > > We should just sort out the hotplug code... > > > > Ok. I have a little knowledge, I'll see if I can be dangerous. My real > question was, is it safe to merge your rfkill support before this is > sorted out? I don't see why not. It works on various versions of the eee, and unless anything actually pokes it people can carry on using their bizarro userspace scripts. I'm working with the PCI guys on handling the hotplug case sanely. It may be possible to special case this in eeepc-laptop, though I'd prefer a more generic solution. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Is rfkill class really appropriate for eeepc-laptop? 2008-09-26 13:55 ` Matthew Garrett 2008-09-26 14:14 ` Alan Jenkins @ 2008-09-26 16:48 ` Henrique de Moraes Holschuh 1 sibling, 0 replies; 5+ messages in thread From: Henrique de Moraes Holschuh @ 2008-09-26 16:48 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Jenkins, corentincj, Woody Suwalski, Sitsofe Wheeler, acpi4asus-user, linux-acpi On Fri, 26 Sep 2008, Matthew Garrett wrote: > On Fri, Sep 26, 2008 at 02:49:53PM +0100, Alan Jenkins wrote: > > 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? > > No, it's to use allow the OS to control whatever mechanism the platform > provides for making the radio stop transmitting. The fact that this is, > uh, "interestingly" implemented on the Eee doesn't alter that. We should > just sort out the hotplug code... Almost correct. rfkill is for making the wireless transmitters stop EMITTING ENERGY. If one just stops sending data but, e.g., a carrier is still being transmitted, the device is NOT rfkill'ed... it is just silenced or something like that. Anyway, Matthew is quite right that it is well within rfkill's intended usage to power off and disconnect from the host bus the entire device in order to shut down energy emissions. However, if the hardware/platform can do it in a less heavy-handed way, that would be vastly prefered over kicking the device off the bus and powering it off, as far as rfkill is concered. -- "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-09-26 16:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 ` Is rfkill class really appropriate for eeepc-laptop? Alan Jenkins
2008-09-26 13:55 ` 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox