Johannes Berg wrote: > On Mon, 2009-06-08 at 12:10 +0100, Alan Jenkins wrote: > > >>>> - rfkill_set_sw_state(wwan_rfkill, hp_wmi_wwan_state()); >>>> err = rfkill_register(wwan_rfkill); >>>> if (err) >>>> goto register_wwan_err; >>>> >>>> >>> Hmm. Anyone know anything about HP? That kinda looks persistent too. >>> >>> >> Quite possibly. I just don't know, and it's never been treated that way >> before. The old core, when I first read it, you were supposed to report >> the initial state so that it knew whether it differed from the default >> state. So the core could "optimise away" the initialization if the >> current state was the same. Then rfkill_set_default() was added, but it >> was only used in tp-acpi and then eeepc-laptop. >> > > Oh, good point. Then maybe that was just to avoid the core > initialisation that I just always did for ease of use. > > >> The counter is the sony-laptop case. That driver also hits ACPI to >> query it's current state. But apparently it doesn't always power up in >> a useful state, because there's a specific git commit which forces the >> radios to unblock at load time. >> >> >> I think this patch should preserve the existing behaviour. But the >> rfkill rewrite as a whole is a good opportunity to re-check this issue. >> There's only a few maintainers to contact so I don't mind doing it - >> unless you were going to check with them about the rewrite anyway? >> > > I wasn't planning on doing anything more than before -- where I had > copied hopefully all maintainers on the rewrite patch. > > > >>> Ah, this is the quirky backward compat code you're talking about. I >>> guess we need it, although I don't particularly like it. >>> >>> >> I don't like it either. The patch as a whole only makes sense because >> rfkill-input is going away, so the global states will become less >> important. When you use rfkill-input, you really want the individual >> states to match the global ones, otherwise your user experience >> suffers. When you don't use rfkill-input, the "global" states will just >> be load-time defaults (once suspend is fixed). >> > > Yeah. Want to fix suspend too? I would now, but I really need to get > lunch first :) > Sure, will do! -- 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
