linux-kernel - Re: eeepc-laptop rfkill, stupid question #4

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]

Date:	Mon, 3 Nov 2008 12:16:28 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Alan Jenkins <alan-jenkins@...fmail.co.uk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux acpi <linux-acpi@...r.kernel.org>
Subject: Re: eeepc-laptop rfkill, stupid question #4

On Sun, 02 Nov 2008, Matthew Garrett wrote:
> resume path. However, as you point out, right now it's possible for the 
> user to change the hardware state in the BIOS and cause the two to get 
> out of sync. That's certainly not ideal.

In fact, it is a bug.

Can you read the state?  If so, you need to unconditionally do so on resume
(from sleep or hibernation) and rfkill_force_state() it.

If you CANNOT read the state, you will have to force the radio to a known
state somehow.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/