linux-kernel - Re: [PATCH 1/1] toshiba_acpi: Add support for bluetooth toggling through rfkill (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <489A7CCF.1090407@overt.org>
Date:	Wed, 06 Aug 2008 21:40:47 -0700
From:	Philip Langdale <philipl@...rt.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	toshiba_acpi@...ebeam.org, Ivo van Doorn <ivdoorn@...il.com>,
	linux-wireless@...r.kernel.org
Subject: Re: [PATCH 1/1] toshiba_acpi: Add support for bluetooth toggling
 through rfkill (v2)

Henrique de Moraes Holschuh wrote:
> 
> Well, the textbook way to connect that to rfkill is something like this,
> please check if it makes sense:
> 
> Export (1) as a input device (you have events to hook to when it changes
> state) or polled input device (you don't have said events).  Do NOT register
> (1) with a struct rfkill at all.  It is purely an input device.
> 
> DO NOT expose (2) as an input device at all.  Instead, register it to a
> rfkill struct, of type bluetooth.
> 
> On the event handler for (1), you issue the EV_SW SW_RFKILL_ALL input event.
> Since you *do* know events from (1) are likely to also have messed with the
> state of (2), you also check (2)'s state at this time and update it through
> rfkill_force_state().
> 
> Due to the interaction of 1 and 2, you need to implement and deal with
> RFKILL_STATE_HARD_BLOCKED.  Since you do know the firmware will be
> hard-blocking (2) when (1) is active, you return RFKILL_STATE_HARD_BLOCKED
> for (2)'s state every time (1) is active.  Otherwise, you return
> RFKILL_STATE_SOFT_BLOCKED when (2) is blocked, and RFKILL_STATE_UNBLOCKED
> otherwise.
> 
> This will cause the state of (2) to go to either RFKILL_STATE_HARD_BLOCKED
> or RFKILL_STATE_SOFT_BLOCKED when (1) changes state.
> 
> [Note: the above does assume (1) blocks (2) in some way you cannot override,
> and that trying to unblock (2) while (1) is blocking it is futile].
> 
> rfkill-input (now) or userspace (someday) will take care of kicking the
> radio to RFKILL_STATE_UNBLOCKED when (1) issues an event that signals that
> radios don't have to remain blocked.  Maybe this is why you see the WLAN
> going on when you deactivate the radio kill switch?
> 
> And rfkill-input will soon be enhanced to let the user configure it to do
> something different if he wants.  Your driver doesn't (and shouldn't)
> hardcode policy about it.

Hmm. So, I've updated the diff to do this, but rfkill-input is not kicking
the bluetooth device back on after I release the kill switch. it just returns
to SOFT_UNBLOCKED and stays there.

--phil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/