On Wed, 2008-04-23 at 15:26 -0400, Dan Williams wrote: > On Wed, 2008-03-19 at 10:15 -0400, Dan Williams wrote: > > On Wed, 2008-03-19 at 01:35 +0200, Tomas Winkler 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? > > > > Well, NM would only be able to get that notification via HAL, which > > would get the notification via the kernel RFKill layer or the input > > layer. In the case of iwlwifi, that even must come through the kernel > > rfkill layer, however the driver decides to post that event. > > > > > This one is tricky with 3945...the trivial question is why NM disables > > > the device? > > > > Because when the device is down (!IFF_UP), then the device is supposed > > to enter the deepest power saving mode that it supports. That's the > > same for ethernet drivers and wireless drivers. I think it's pretty > > much up to the driver/ucode to track rfkill state across up/down/etc. > > > > If 3945 can only detect the rfkill change when the ucode is loaded, then > > we have a problem. > > > > I'm not opposed to changing NetworkManager to keep the device up, but > > just setting the TX power to 'off', though we must keep in mind that the > > device is (a) not in a lowest power mode because RX circuits can still > > be on, and (b) not all drivers probably respect WEXT txpower. I don't > > care about (b) at all, those drivers just have to get fixed. But (a) > > worries me since we don't have any API for inactive power saving modes > > right now _other_ than !IFF_UP. We will drain more power than setting > > the device !IFF_UP. > > So I did this, but we need a few changes to HAL, because the rfkill bits > there aren't rich enough to distinguish between a hardware rfkill and a > software rfkill. So when SIOCSIWTXPOW to 'off', all you can get out of > HAL is "I'm dead", which doesn't let you know whether you can turn the Clarification: this behavior was seen on ipw2200. Drivers/hardware that use the kernels' rfkill framework may be different. Dan > radio back on with SIOCSIWTXPOW or whether there's a switch flipped > somewhere. > > Dan > > > Dan > > > > > 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 :) > > > > > > Sorry no solution for now. > > > > > > Tomas > > > > -- > > 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 > > -- > 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 -- 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
