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

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: <20081102034620.GA29606@khazad-dum.debian.net>
Date:	Sun, 2 Nov 2008 01:46:20 -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 and 5

On Fri, 31 Oct 2008, Matthew Garrett wrote:
> > Actually, normal boot doesn't preserve the setting either.  Your commit
> > changes the behaviour from the rfkill state being persistent across
> > reboot / power off (as a bios setting), to being always enabled on
> > boot.  It seems like a bad idea to me.
> 
> This is the behaviour of the rfkill core.

When you don't use rfkill_set_default().  Which, if you are a platform
driver, and your platform can store state across power off, you should use.

Yeah, it is a new thing, sort of. But it is in mainline already, so feel
free to use it.  The right way to do it is to call it BEFORE doing any
rfkill_register or rfkill_allocate.  Only the first caller for a given
rfkill type, wins.

-- 
  "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/