Is rfkill class really appropriate for eeepc-laptop?

Is rfkill class really appropriate for eeepc-laptop?

[Alan Jenkins]

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

Re: Is rfkill class really appropriate for eeepc-laptop?

[Matthew Garrett]

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

Re: Is rfkill class really appropriate for eeepc-laptop?

[Alan Jenkins]

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

Re: Is rfkill class really appropriate for eeepc-laptop?

[Matthew Garrett]

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

Re: Is rfkill class really appropriate for eeepc-laptop?

[Henrique de Moraes Holschuh]

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