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 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
