From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750940AbXCaMuZ (ORCPT ); Sat, 31 Mar 2007 08:50:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751240AbXCaMuZ (ORCPT ); Sat, 31 Mar 2007 08:50:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]:9646 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750827AbXCaMuW (ORCPT ); Sat, 31 Mar 2007 08:50:22 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from; b=XDNG8NjxlEQ73KxE0do8jpc0nYjDEsiLAdS6Dwv6yGkgy669BNVCCQQtjC2pxn/dcNm/vfidP0F0UlBXbKEbbywSgj0Z4+YADE0WF7k01QsXvUCneopkheM9M4WoClBOqa0bVFsH14I6Ds9wcK1tD2H/+a/roX5RPLDjK/UIkUA= To: "Dmitry Torokhov" Subject: Re: [RFC] rfkill - Add support for input key to control wireless radio Date: Sat, 31 Mar 2007 14:49:39 +0200 User-Agent: KMail/1.9.5 Cc: "Stephen Hemminger" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, "John Linville" , "Jiri Benc" , "Lennart Poettering" , "Johannes Berg" , "Larry Finger" References: <200612031936.34343.IvDoorn@gmail.com> <200703301913.57656.IvDoorn@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703311449.40022.IvDoorn@gmail.com> From: Ivo van Doorn Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > Well in drivers/net are the network drivers but not the irda and bluetooth drivers, > > those are located in different folders in drivers/ so I think misc would be the most > > suitable location. > > We could also consider the ./net itself. rfkill is not a driver, it is > a facility. True, in that case ./net would be good. > > > Does this make sense? > > > > Yes, but what if the user loads both modules or has them both compiled in? > > Shouldn't there be some protection against that, since both handlers should not > > be active at the same time. > > Why not? evdev is just a delivery transport for input events to > userspace. Even if user wants the kernel to control state of RF > switches (which I expect most users woudl want) there still could be > applications interested in knowing that used turned off wireless. And > if userspace really wishes to control switch all by itself it can > "claim" it. Right, I forgot about that user_claim thingy. ;) > I guess what you are missing is that input event generated by a device > is pushed through every handler bound to the device so there is no way > for a "wrong" handler to "steals" an event from "right" handler. They > all work simultaneously. > > > > > personally I would prefer enforcing drivers to call > > > > allocate() > > > > register() > > > > unregister() > > > > free() > > > > > > > > Especially with unregister() doing the same steps as free() (put_device) > > > > might be somwhat confusing. But might be just me. ;) > > > > > > > > > > I know but for refcounted objects you can't really tell when they will > > > actually be freed. It depends when their last user drops off. > > > > Then perhaps rfkill_register could call put_device() when it fails, and free() > > can be removed entirely. That way it would we prevent some driver > > to call free() anyway. > > > > That would make error handling in ->probe() methods a bit unwieldy I > think - if you are using the standard "goto err_xxx; goto err_yyy;" > technique then you have to conditionally call rfkill_free(). Hovewer > if register simply fails and does not free anything and you call > rfkill_register() last (which you need to do because driver has to be > almost fully functional to be able to serve toggle_radio calls) you > can always call rfkill_free() if something fails. Ok. Well that would mean rfkill would be ready to applied to one of the kernel trees right? :) The first user of rfkill would be rt2x00, which is in wireless-dev as well as -mm. The second user could be the driver from Lennart, but I haven't heard from him quite a while (although he is on the CC list) so I am not sure if his MSI driver can be fixed to use rfkill. His MSI driver is already in the linus' tree. A third user could be bcm43xx but I don't know how far they are with hardware key detection and status reading (to make it work with rfkill), perhaps Larry could give more information about that. Ivo