Re: [RFC][RFT] fix iwlagn hw-rfkill while the interface is down

[Helmut Schaa <helmut.schaa@googlemail.com>]

Am Mittwoch, 17. Dezember 2008 schrieb Dan Williams:
> On Wed, 2008-12-17 at 15:29 -0500, John W. Linville wrote:
> > On Wed, Dec 17, 2008 at 12:10:11PM -0800, mohamed salim abbas wrote:
> > > the interrupt moved from pci_probe to mac_start for power saving. once
> > > the interface is up the driver will read some register to know rfkill
> > > status, if the interface in down the driver don't care to keep track
> > > of rfkill switch. I wonder what the purpose of changing this behavior?
> > 
> > I think it still isn't settled in everyone's minds whether rfkill
> > only matters if the device is "up" or if it is something that
> > e.g. NetworkManager might want to monitor as a clue to bring the
> > device up or down in response to rfkill changes.
> 
> The question is:  does NetworkManager just always keep the device 'up'
> irregardless of whether it's supposed to be associated with anything
> just so we can get rfkill events?

Another question is: is it worth to keep the interface up (and thus the
firmware loaded) even if the transceiver is killed by a hardware switch?
Wouldn't that consume even more power than just listening to rfkill
interrupts (or polling the killswitch state in case of 3945) with no
firmware loaded.

> I guess I'll treat rfkill the same as ethernet carrier.  If we cannot
> rely on rfkill notifications when the device is down (we already can't,
> since iwl3945 simply can't do it) 

I've just checked the 3945 and it is indeed possible to poll the killswitch
state even if the firmware is not loaded. Hence 3945 could also expose
the killswitch state while the interface is down (of course the driver would
have to poll for that information).

> if there are quirks for devices, those quirks need to live in the driver,
> not worked around in userspace.

Agreed.

Helmut