Messages in this thread | | | Date | Tue, 18 Aug 2009 22:08:14 +0100 | Subject | Re: [PATCH 2/3] Add rfkill support to compal-laptop | From | Alan Jenkins <> |
| |
On 8/18/09, Mario Limonciello <mario_limonciello@dell.com> wrote: > Hi Alan & Marcel: > > Alan Jenkins wrote: >> Also, you're missing the calls to rfkill_destroy() here. >> >> Whew, I think that's everything. I hope you find the feedback useful, >> despite it being a little fragmented. >> >> > Thanks for all the feedback. I think i've addressed all of the concerns > that were pointed out. I appreciate the pointer to scripts/cleanpatch, > that does significantly help in finding whitespace problems that the > naked eye just browses over. > > I'm attaching the updated patch (sorry, git send-email seems to still > not be very graceful with line breaks when the SMTP implementation is > exchange from what i've seen)
> +static void compal_rfkill_poll(struct rfkill *rfkill, void *data) > +{ > + unsigned long radio = (unsigned long) data; > + u8 result; > + bool hw_blocked; > + bool sw_blocked; > + > + ec_read(COMPAL_EC_COMMAND_WIRELESS, &result); > + > + hw_blocked = !(result & KILLSWITCH_MASK); > + sw_blocked = (!hw_blocked && !(result & radio)); > + > + rfkill_set_states(rfkill, sw_blocked, hw_blocked); > +}
I assume you have good reason for having sw_block depend on hw_block. I.e. you can't read sw_blocked while hw_blocked is set, right?
If KILLSWITCH is toggled on and off, will the hardware "forget" any prior soft-blocks?
It would also be nice to know if hardware/firmware ever changes sw_blocked, e.g. in response to a button press.
Johannes, I think I'm confusing myself here. Can you have a look at this code? I remember the rfkill rewrite was designed to help with something like this, but I don't know how exactly.
Thanks Alan
| |