linux-kernel - Re: [PATCH v2 2/2] eeepc-laptop: Use standard interfaces

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: <20080820011828.GD29336@khazad-dum.debian.net>
Date:	Tue, 19 Aug 2008 22:18:29 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, corentincj@...aif.net,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v2 2/2] eeepc-laptop: Use standard interfaces

On Wed, 20 Aug 2008, Matthew Garrett wrote:
> On Tue, Aug 19, 2008 at 08:09:50PM -0300, Henrique de Moraes Holschuh wrote:
> > Looks fine to me at first glance.  I do wonder if there are no events at all
> > you could hook to rfkill_force_state() instead of (or in addition to) using
> > the get_state()?
> 
> The only change event is generated by hitting the wifi key, which ties 
> into rfkill-input. Won't that already force a state update on the event?

Yes, but one must keep this in mind:

1. If the event has no bearing on compulsory hardware state changes (i.e.
the hardware won't change state by itself when the event happens, it is
really just reporting a simple key press that will do nothing by itself),
you just report the key as an event.

2. If the hardware/firmware *ALSO* compulsory changes the rfkill state (i.e.
the event also means the real rfkill controller state probably changed), you
take the opportunity to do a forced immediate state poll and
rfkill_force_state() the new state.

So, it basically depends whether the EEEPC hardware/firmware does (1) or
(2).  If it is (1), the patch is correct.  If it is (2), it should do a bit
more stuff that ends up with a call to rfkill_force_state().

The reason is that there is absolutely *NO* reason why rfkill-input (or
anything else for that matter) has to obey the input event.  They can just
discard it if they want: it is a local system policy matter.  Therefore, if
there is anything in *hardware* or *firmware* that is already acting on that
event, you *MUST* arrange for a call to rfkill_force_state().

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