Hi Dan, > > > > > > > > > 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? it'll make a lot of people happy :) > > > > > > > > if we can't get the rfkill state change via interrupt, then the kernel > > > > driver has to poll for it (in the no-firmware cases). Or we have to > > > > remove the rfkill support completely. Everything else is just not > > > > acceptable. It is _not_ the responsibility of the userspace to make this > > > > work with quirks. > > > > > > Right; I meant polling in *iwl3945* every 2 - 4 seconds or so, not from > > > userspace. Userspace should still listen for the rfkill uevents (not > > > that HAL does yet, but...) > > > > you actually could use libudev for it directly. That is what I am doing > > right now. Works pretty smooth. > > Do what with libudev? Poll the register directly? Or hit some sysfs > file that eventually polls the register? And you said "it's not the > responsibility of userspace to make this work with quirks" which to me > says you'd prefer this polling to be done in the driver, not > userspace... no? with libudev you can listen on udev events that translate directly from uevent from the kernel. Don't confuse libudev with the broken libsysfs attempt. And this comment was meant in response for HAL not being able to notify you of rfkill state changes. You don't need HAL for this if you want proper support for rfkill events. The iwl3945 driver has to do the polling of the rfkill register if the firmware is not loaded. There is nothing we can or should do in userspace. Regards Marcel -- 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
