Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Sep 27, 2011
  1. @pebolle

    doc: fix broken references

    pebolle authored Jiri Kosina committed
    There are numerous broken references to Documentation files (in other
    Documentation files, in comments, etc.). These broken references are
    caused by typo's in the references, and by renames or removals of the
    Documentation files. Some broken references are simply odd.
    
    Fix these broken references, sometimes by dropping the irrelevant text
    they were part of.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commits on Mar 10, 2010
  1. @FlorianMickler @linvjw

    Document the rfkill sysfs ABI

    FlorianMickler authored linvjw committed
    This moves sysfs ABI info from Documentation/rfkill.txt to the
    ABI subfolder and reformats it.
    
    This also schedules the deprecated sysfs parts to be removed in
    2012 (claim file) and 2014 (state file).
    
    Signed-off-by: Florian Mickler <florian@mickler.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Jun 19, 2009
  1. @linvjw

    rfkill: export persistent attribute in sysfs

    Alan Jenkins authored linvjw committed
    This information allows userspace to implement a hybrid policy where
    it can store the rfkill soft-blocked state in platform non-volatile
    storage if available, and if not then file-based storage can be used.
    
    Some users prefer platform non-volatile storage because of the behaviour
    when dual-booting multiple versions of Linux, or if the rfkill setting
    is changed in the BIOS setting screens, or if the BIOS responds to
    wireless-toggle hotkeys itself before the relevant platform driver has
    been loaded.
    
    Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
    Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Jun 15, 2009
  1. @jmberg @linvjw

    rfkill: improve docs

    jmberg authored linvjw committed
    Now that the dust has settled a bit, improve the docs on rfkill
    and include more information about /dev/rfkill.
    
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Jun 3, 2009
  1. @jmberg @linvjw

    rfkill: document /dev/rfkill

    jmberg authored linvjw committed
    Add some blurb about /dev/rfkill to the documentation and
    fix the "transmiter" spelling error.
    
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
  2. @jmberg @linvjw

    rfkill: rewrite

    jmberg authored linvjw committed
    This patch completely rewrites the rfkill core to address
    the following deficiencies:
    
     * all rfkill drivers need to implement polling where necessary
       rather than having one central implementation
    
     * updating the rfkill state cannot be done from arbitrary
       contexts, forcing drivers to use schedule_work and requiring
       lots of code
    
     * rfkill drivers need to keep track of soft/hard blocked
       internally -- the core should do this
    
     * the rfkill API has many unexpected quirks, for example being
       asymmetric wrt. alloc/free and register/unregister
    
     * rfkill can call back into a driver from within a function the
       driver called -- this is prone to deadlocks and generally
       should be avoided
    
     * rfkill-input pointlessly is a separate module
    
     * drivers need to #ifdef rfkill functions (unless they want to
       depend on or select RFKILL) -- rfkill should provide inlines
       that do nothing if it isn't compiled in
    
     * the rfkill structure is not opaque -- drivers need to initialise
       it correctly (lots of sanity checking code required) -- instead
       force drivers to pass the right variables to rfkill_alloc()
    
     * the documentation is hard to read because it always assumes the
       reader is completely clueless and contains way TOO MANY CAPS
    
     * the rfkill code needlessly uses a lot of locks and atomic
       operations in locked sections
    
     * fix LED trigger to actually change the LED when the radio state
       changes -- this wasn't done before
    
    Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Apr 22, 2009
  1. @jmberg @linvjw

    rfkill: remove user_claim stuff

    jmberg authored linvjw committed
    Almost all drivers do not support user_claim, so remove it
    completely and always report -EOPNOTSUPP to userspace. Since
    userspace cannot really drive rfkill _anyway_ (due to the
    odd restrictions imposed by the documentation) having this
    code is just pointless.
    
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Oct 31, 2008
  1. @hmh @linvjw

    rfkill: add master_switch_mode and EPO lock to rfkill and rfkill-input

    hmh authored linvjw committed
    Add of software-based sanity to rfkill and rfkill-input so that it can
    reproduce what hardware-based EPO switches do, blocking all transmitters
    and locking down any further attempts to unblock them until the switch is
    deactivated.
    
    rfkill-input is responsible for issuing the EPO control requests, like
    before.
    
    While an rfkill EPO is active, all transmitters are locked to one of the
    BLOCKED states and all attempts to change that through the rfkill API
    (userspace and kernel) will be either ignored or return -EPERM errors.
    
    The lock will be released upon receipt of EV_SW SW_RFKILL_ALL ON by
    rfkill-input, or should modular rfkill-input be unloaded.
    
    This makes rfkill and rfkill-input extend the operation of an existing
    wireless master kill switch to all wireless devices in the system, even
    those that are not under hardware or firmware control.
    
    Since the above is the expected operational behavior for the master rfkill
    switch, the EPO lock functionality is not optional.
    
    Also, extend rfkill-input to allow for three different behaviors when it
    receives an EV_SW SW_RFKILL_ALL ON input event.  The user can set which
    behavior he wants through the master_switch_mode parameter:
    
    master_switch_mode = 0: EV_SW SW_RFKILL_ALL ON just unlocks rfkill
    controller state changes (so that the rfkill userspace and kernel APIs can
    now be used to change rfkill controller states again), but doesn't change
    any of their states (so they will all remain blocked).  This is the safest
    mode of operation, as it requires explicit operator action to re-enable a
    transmitter.
    
    master_switch_mode = 1: EV_SW SW_RFKILL_ALL ON causes rfkill-input to
    attempt to restore the system to the state before the last EV_SW
    SW_RFKILL_ALL OFF event, or to the default global states if no EV_SW
    SW_RFKILL_ALL OFF ever happened.   This is the recommended mode of
    operation for laptops.
    
    master_switch_mode = 2: tries to unblock all rfkill controllers (i.e.
    enable all transmitters) when an EV_SW SW_RFKILL_ALL ON event is received.
    This is the default mode of operation, as it mimics the previous behavior
    of rfkill-input.
    
    In order to implement these features in a clean way, the entire event
    handling of rfkill-input was refactored into a single worker function.
    
    Protection against input event DoS (repeatedly firing rfkill events for
    rfkill-input to process) was removed during the code refactoring.  It will
    be added back in a future patch.
    
    Note that with these changes, rfkill-input doesn't need to explicitly
    handle any radio types for which KEY_<radio type> or SW_<radio type> events
    do not exist yet.
    
    Code to handle EV_SW SW_{WLAN,WWAN,BLUETOOTH,WIMAX,...} was added as it
    might be needed in the future (and its implementation is not that obvious),
    but is currently #ifdef'd out to avoid wasting resources.
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Cc: Ivo van Doorn <IvDoorn@gmail.com>
    Cc: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Sep 15, 2008
  1. @hmh @linvjw

    rfkill: remove transmitter blocking on suspend

    hmh authored linvjw committed
    Currently, rfkill would stand in the way of properly supporting wireless
    devices that are capable of waking the system up from sleep or hibernation
    when they receive a special wireless message.  It would also get in the way
    of mesh devices that need to remain operational even during platform
    suspend.
    
    To avoid that, stop trying to block the transmitters on the rfkill class
    suspend handler.
    
    Drivers that need rfkill's older behaviour will have to implement it by
    themselves in their own suspend handling.
    
    Do note that rfkill *will* attempt to restore the transmitter state on
    resume in any situation.  This happens after the driver's resume method is
    called by the suspend core (class devices resume after the devices they are
    attached to have been resumed).
    
    The following drivers need to check if they need to explicitly block
    their transmitters in their own suspend handlers (maintainers Cc'd):
    	arch/arm/mach-pxa/tosa-bt.c
    	drivers/net/usb/hso.c
    	drivers/net/wireless/rt2x00/* (USB might need it?)
    	drivers/net/wireless/b43/ (SSB over USB might need it?)
    	drivers/misc/hp-wmi.c
    	eeepc-laptop w/rfkill support (not in mainline yet)
    	Compal laptop w/rfkill support (not in mainline yet)
    	toshiba-acpi w/rfkill support (not in mainline yet)
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Cc: Ivo van Doorn <IvDoorn@gmail.com>
    Cc: Matthew Garrett <mjg@redhat.com>
    Cc: Andrew Bird <ajb@spheresystems.co.uk>
    Cc: Greg Kroah-Hartman <gregkh@suse.de>
    Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
    Cc: Philip Langdale <philipl@overt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Aug 18, 2008
  1. @hmh @linvjw

    rfkill: protect suspended rfkill controllers

    hmh authored linvjw committed
    Guard rfkill controllers attached to a rfkill class against state changes
    after class suspend has been issued.
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Jul 29, 2008
  1. @hmh @linvjw

    rfkill: document rfkill_force_state as required (v2)

    hmh authored linvjw committed
    While the rfkill class does work with just get_state(), it doesn't work
    well on devices that are subject to external events that cause rfkill state
    changes.
    
    Document that rfkill_force_state() is required in those cases.
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Jun 26, 2008
  1. @hmh @linvjw

    rfkill: improve documentation for kernel drivers

    hmh authored linvjw committed
    Improve the documentation of how to use the rfkill class in kernel drivers,
    based on the doubts that came up in a thread in linux-wireless.
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
  2. @hmh @linvjw

    rfkill: rename the rfkill_state states and add block-locked state

    hmh authored linvjw committed
    The current naming of rfkill_state causes a lot of confusion: not only the
    "kill" in rfkill suggests negative logic, but also the fact that rfkill cannot
    turn anything on (it can just force something off or stop forcing something
    off) is often forgotten.
    
    Rename RFKILL_STATE_OFF to RFKILL_STATE_SOFT_BLOCKED (transmitter is blocked
    and will not operate; state can be changed by a toggle_radio request), and
    RFKILL_STATE_ON to RFKILL_STATE_UNBLOCKED (transmitter is not blocked, and may
    operate).
    
    Also, add a new third state, RFKILL_STATE_HARD_BLOCKED (transmitter is blocked
    and will not operate; state cannot be changed through a toggle_radio request),
    which is used by drivers to indicate a wireless transmiter was blocked by a
    hardware rfkill line that accepts no overrides.
    
    Keep the old names as #defines, but document them as deprecated.  This way,
    drivers can be converted to the new names *and* verified to actually use rfkill
    correctly one by one.
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
  3. @hmh @linvjw

    rfkill: document rw rfkill switches and clarify input subsystem inter…

    hmh authored linvjw committed
    …actions
    
    Rework the documentation so as to make sure driver writers understand
    exactly where the boundaries are for input drivers related to rfkill
    switches, buttons and keys, and rfkill class drivers.
    
    Also fix a small error in the documentation: setting the state of a normal
    instance of the rfkill class does not affect the state of any other devices
    (unless they are tied by firmware/hardware somehow).
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Cc: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
  4. @hmh @linvjw

    rfkill: clarify meaning of rfkill states

    hmh authored linvjw committed
    rfkill really should have been named rfswitch.  As it is, one can get
    confused whether RFKILL_STATE_ON means the KILL switch is on (and
    therefore, the radio is being *blocked* from operating), or whether it
    means the RADIO rf output is on.
    
    Clearly state that RFKILL_STATE_ON means the radio is *unblocked* from
    operating (i.e. there is no rf killing going on).
    
    Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Cc: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Oct 10, 2007
  1. @IvD

    [RFKILL]: Add rfkill documentation

    IvD authored David S. Miller committed
    Add a documentation file which contains
    a short description about rfkill with some
    notes about drivers and the userspace interface.
    
    Changes since v1 and v2:
     - Spellchecking
    
    Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
    Acked-by: Dmitry Torokhov <dtor@mail.ru>
    Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Something went wrong with that request. Please try again.