From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivo van Doorn Subject: Re: [RFC] rfkill - Add support for input key to control wireless radio Date: Sat, 31 Mar 2007 14:49:39 +0200 Message-ID: <200703311449.40022.IvDoorn@gmail.com> References: <200612031936.34343.IvDoorn@gmail.com> <200703301913.57656.IvDoorn@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Stephen Hemminger" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, "John Linville" , "Jiri Benc" , "Lennart Poettering" , "Johannes Berg" , "Larry Finger" To: "Dmitry Torokhov" Return-path: Received: from ug-out-1314.google.com ([66.249.92.168]:9340 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940AbXCaMuW (ORCPT ); Sat, 31 Mar 2007 08:50:22 -0400 Received: by ug-out-1314.google.com with SMTP id 44so1073382uga for ; Sat, 31 Mar 2007 05:50:21 -0700 (PDT) In-Reply-To: Content-Disposition: inline Sender: netdev-owner@vger.kernel.org List-Id: netdev.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