On Wed, Mar 19, 2008 at 12:35 AM, Tomas Winkler <tomasw@xxxxxxxxx> wrote: > > On Wed, Mar 19, 2008 at 1:10 AM, drago01 <drago01@xxxxxxxxx> wrote: > > > > On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <tomasw@xxxxxxxxx> wrote: > > > On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette > > > > > > <reinette.chatre@xxxxxxxxx> wrote: > > > > > > > > > > > > > > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote: > > > > > > > > >> Please note that the driver loads/unloads the firmware during > > > > >> interface up/down. That means that the host will not receive rfkill > > > > >> events while the interface is down as there is no firmware to deal > > > > >> with these events. > > > > >> > > > > >> Reinette > > > > >> > > > > > > > > > > OK that makes sense. > > > > > So a solution would be to not unload the firmware on down when the hw > > > > > rfkill is on. Is this a acceptable one or are they other (better > > > > > solutions). I can't think of any. And userspace cannot do anything > > > > > because bringing the device up and down again to look for the rfkill > > > > > status would be racy. > > > > > > > > Having the firmware unloaded when the interface is down is a requirement > > > > for powersaving. We do not want the device to consume power when it is > > > > not used. The rfkill status should always be reported accurately when > > > > the interface is up. If it is not then it is a bug. > > > > > > We will catch the HW rfkill event after loading the uCode so there is > > > no problem with this. > > > Not sure where should be the SW rfkill state stored. > > > > yeah, but the ucode will be loaded when the device is brought back up, > > which does not happen in NM's case. > > > > You mean that NM doesn't have any notification that the radio was enabled again? yes > This one is tricky with 3945...the trivial question is why NM disables > the device? Thats a question for Dan, maybe other devices/drivers just send an event to userspace "please disable the radio" ? > In 4965 there is an interrupt announcing rkfil, in 3965 it's event > from firmware. There was portably a good reason why the interrupt was > added :) OK, but aren't the interrupts disabled too on down? (don't have any 4965 hw to test with) > Sorry no solution for now. ok, might be a way to solve it in userspace (not bringing down the device) -- 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
