On Friday 05 June 2009 23:20:55 Larry Finger wrote:
> Michael Buesch wrote:
> >
> > This is pretty silly behavior IMO. Just to bring it to the point:
> > We initialize a huge wireless MAC, PHY and Radio that consume several watts of power
> > just to poll a silly RF-kill bit.
>
> That is what the driver already does.
No. If the device is down, then it _is_ down. There won't be an rfkill thing
trying to bring it up again although the interface is down.
> > We can't we just accept that the RF-kill status is unknown while the device is down?
>
> The problem is that while the interface is down the switch status
> cannot be interrogated. If you try, you get a fatal SSB error. Thus
> the only way to bring it back up is to flip the switch, then
> rmmod/insmod the driver. If you want hardware rfkill to be one-way,
> then take Johannes's patch. We would save a little power by calling
> b43_wireless_exit() if we brought it up to test the switch, and the
> switch was still off. That would leave everything off most of the time.
Yeah well. We cannot read the rfkill status while the device is down. That is
a hardware limitation. I think we should _live_ with that limitation instead of
working around it by always keeping the device initialized.
Can't we teach the rfkill subsystem about an "unknown" state? Because that's what we're in.
> > I really do hate all that rfkill crap and I'm still refusing to sign off on anything that's
> > related to rfkill (like I did for the past year or so). If people want this merged,
> > somebody else maintain and sign it off, please.
>
> I'm sick of rfkill as well and really detest the endless discussions
> that have taken place; however, I do want the stuff to work.
Yeah. But wasting huge amounts of power to keep polling a bit that's not even used
most of the time is not really what I like.
> 1. We switch to the cfg80211 rfkill and use this patch modified to
> turn the interface back off if the switch is still off.
+void b43_rfkill_poll(struct ieee80211_hw *hw)
{
- struct b43_wldev *dev = data;
- struct b43_wl *wl = dev->wl;
+ struct b43_wl *wl = hw_to_b43_wl(hw);
+ struct b43_wldev *dev = wl->current_dev;
bool enabled;
mutex_lock(&wl->mutex);
if (unlikely(b43_status(dev) < B43_STAT_INITIALIZED)) {
- mutex_unlock(&wl->mutex);
- return;
+ if (b43_wireless_core_init(dev)) {
+ mutex_unlock(&wl->mutex);
+ return;
+ }
}
This is the part of the code which I really really really dislike.
Hell, just return a freaking error from b43_rfkill_poll(), if the interface
is down. If rfkill can't handle that, it should probably be taught to handle it.
Especially as there can be other errors as well, like memory allocation failures.
> 2. We continue to use the old rfkill mechanism. It works just fine,
> but this method runs the risk of the old method being deprecated and
> eliminated.
I agree that this is not really an option.
> 3. We get new callbacks that will only power down/up the radio when it
> is blocked. That saves a little power.
What is wrong with the current mechanism to power up the radio, if the interface is up
and powering it down if the interface is down? I think the power of the PHY/Radio should
not be affected by rfkill. It should work the other way around instead. Rfkill should
be tolerant to a radio that is down and simply live with an unknown switch state.
--
Greetings, Michael.
--
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
