Is rfkill class really appropriate for eeepc-laptop?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Woody Suwalski
Quoted 6 lines · Alan Jenkins
Quoted 4 lines · Woody Suwalski
Quoted 1 line
I have found one of the earliest source code snippets we have got
from
Quoted 2 lines
Asus (eeepc_hotkey.tar.gz), and the current one we are using on new models (P901 an later - hopefully back compatible?).
<>
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
And also - how far is now kernel eeepc support from this acpi
module?
<>
Quoted 7 lines
Quoted 7 lines
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.
<>
Quoted 5 lines
About the rfkill switch - be careful.
The current/proc/acpi/asus/wlanimplementation 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?
Quoted 2 lines
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
Quoted 6 lines · Alan Jenkins
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...
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · Matthew Garrett
Quoted 7 lines · Alan Jenkins
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?
Quoted 3 lines
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 :-).
Quoted 2 lines
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
Quoted 8 lines · Alan Jenkins
Quoted 3 lines · Matthew Garrett
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.
Quoted 6 lines
Quoted 2 lines
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 8 lines · Matthew Garrett
Quoted 6 lines · Alan Jenkins
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?
Quoted 4 lines
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.
Signature · 4 lines
"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