linux-kernel - Re: [PATCH] Toshiba Bluetooth enabler (rfkill)

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: <20091208125530.GA23520@srcf.ucam.org>
Date:	Tue, 8 Dec 2009 12:55:30 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
Cc:	Jes Sorensen <jes.sorensen@...il.com>, linux-acpi@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>, lenb@...nel.org
Subject: Re: [PATCH] Toshiba Bluetooth enabler (rfkill)

On Tue, Dec 08, 2009 at 10:05:19AM +0000, Alan Jenkins wrote:

> I think this would benefit from an explanation.
> 
> 
> /* Some models include a placeholder for the TOS6205 device, but don't
> use it */ ?
> 
> /* May be disabled in BIOS */ ?
> 
> /* This device has _STA, not sure why, but let's honour it if disabled */ ?
> 
> 
> That might give us an idea of what to do if we find a model which
> doesn't have _STA :-).

TOS6205 seems to be present even on models which don't have bluetooth, 
and _STA then evaluates appropriately. But having checked, the core 
takes care of this so the driver shouldn't need to.

> I think you _could_ export an rfkill device.  It would at least be
> useful for trouble-shooting, because it lets userspace read the
> current state in a generic way.  So I would recommend doing so in the
> future, even though most current userspaces won't do anything
> interesting with it.  Given that the BIOS sets the state when the
> switch is turned off, I would recommend you expose it as a "hard"
> block - so you don't let userspace change the state.

The problem with that is that there's no event to indicate that the 
switch has been turned back on, so there's no way to update the rfkill 
core appropriately. Giving userspace potentially stale information 
doesn't seem helpful.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/