[lkml]   [2007]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-03-31 14:53    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean