lkml.org 
[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
    Date
    From
    > > 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-31 14:53    [W:0.035 / U:0.572 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site