Message-Id: <200703311449.40022.IvDoorn@gmail.com>
Date:	Sat, 31 Mar 2007 14:49:39 +0200
From:	Ivo van Doorn <ivdoorn@...il.com>
To:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
Cc:	"Stephen Hemminger" <shemminger@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	"John Linville" <linville@...driver.com>,
	"Jiri Benc" <jbenc@...e.cz>,
	"Lennart Poettering" <lennart@...ttering.net>,
	"Johannes Berg" <johannes@...solutions.net>,
	"Larry Finger" <Larry.Finger@...inger.net>
Subject: Re: [RFC] rfkill - Add support for input key to control wireless radio

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

Powered by blists - more mailing lists