From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755442AbYHTBSv (ORCPT ); Tue, 19 Aug 2008 21:18:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752664AbYHTBSl (ORCPT ); Tue, 19 Aug 2008 21:18:41 -0400 Received: from out3.smtp.messagingengine.com ([66.111.4.27]:38525 "EHLO out3.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752225AbYHTBSk (ORCPT ); Tue, 19 Aug 2008 21:18:40 -0400 X-Sasl-enc: 9t+RZ7D27ODJDuzQZkIvXIuLWpkNsmbY+dZiPf3Abg7c 1219195118 Date: Tue, 19 Aug 2008 22:18:29 -0300 From: Henrique de Moraes Holschuh To: Matthew Garrett Cc: Andrew Morton , corentincj@iksaif.net, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v2 2/2] eeepc-laptop: Use standard interfaces Message-ID: <20080820011828.GD29336@khazad-dum.debian.net> References: <20080804170833.GA9513@srcf.ucam.org> <20080806092352.GA17801@srcf.ucam.org> <20080806092523.GB17801@srcf.ucam.org> <20080819025815.b5ec1a4c.akpm@linux-foundation.org> <20080819111320.GA19223@srcf.ucam.org> <20080819230950.GC29336@khazad-dum.debian.net> <20080819232411.GA5421@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080819232411.GA5421@srcf.ucam.org> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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