lkml.org 
[lkml]   [2009]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2/3] Add rfkill support to compal-laptop
From
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


\
 
 \ /
  Last update: 2009-08-18 23:11    [W:0.082 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site