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 :) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
