Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Dienstag, 6. Januar 2009 schrieb Dan Williams:
> On Mon, 2009-01-05 at 15:56 +0100, Helmut Schaa wrote:
> > 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).
> 
> Even polling the state once every 2 - 4 seconds would be perfectly
> acceptable latency for me.  It doesn't have to be instantaneous, so we
> can certainly trade off latency for fewer wakeups.  Care to propose a
> patch?

Will do that soon.

Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux