Search Linux Wireless

Re: [PATCH] dell-laptop: Fix rfkill state setting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2009-07-27 at 08:47 -0600, Tim Gardner wrote:
> Matthew,
> 
> I think the rfkill state change logic is inverted. I've tried the original
> code on 3 different Dell models. Once 'rfkill block all' is run, then you
> can never unblock 'dell-wifi: Wireless LAN'. With this change you can get
> it unblocked, but you need to run 'rfkill unblock all' twice (which is
> likely an issue with rfkill).
> 
> rtg
> 
> From 778aec563a251418e455d63f711aab1c936bff73 Mon Sep 17 00:00:00 2001
> From: Tim Gardner <tim.gardner@xxxxxxxxxxxxx>
> Date: Mon, 27 Jul 2009 08:30:54 -0600
> Subject: [PATCH] UBUNTU: [Upstream] dell-laptop: Fix rfkill state setting.
> 
> rfkill enable/disable transitions are predicated on the state of the
> external hardware switch, i.e., if the external switch is in the on position,
> then no rfkill state transitions are allowed.
> 
> Signed-off-by: Tim Gardner <tim.gardner@xxxxxxxxxxxxx>
> ---
>  drivers/platform/x86/dell-laptop.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
> index 74909c4..cf40c4e 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -197,8 +197,11 @@ static void dell_rfkill_query(struct rfkill *rfkill, void *data)
>  	dell_send_request(&buffer, 17, 11);
>  	status = buffer.output[1];
>  
> -	if (status & BIT(bit))
> -		rfkill_set_hw_state(rfkill, !!(status & BIT(16)));
> +	/*
> +	 * Don't change state unless the read-only HW rfkill switch is disabled.
> +	 */
> +	if (status & BIT(16))
> +		rfkill_set_hw_state(rfkill, !!(status & BIT(bit)));

Hmm. The previous code was

-       if (status & (1<<16))
-               new_state = RFKILL_STATE_SOFT_BLOCKED;
-
-       if (status & (1<<bit))
-               *state = new_state;
-       else
-               *state = RFKILL_STATE_UNBLOCKED;
-
-       return 0;

where new_state was initialised to RFKILL_STATE_HARD_BLOCKED.

So doesn't that mean that 1<<bit is the hard-block bit? Or was the
previous code just bogus, but happened to work since rfkill didn't
separate the hard/soft kill concepts?

johannes

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux