1. 15 Jun, 2018 1 commit
  2. 14 Jul, 2017 1 commit
  3. 24 Oct, 2016 1 commit
  4. 24 Feb, 2016 1 commit
  5. 09 Jan, 2015 1 commit
  6. 05 May, 2014 1 commit
  7. 02 Dec, 2013 1 commit
  8. 27 Sep, 2011 1 commit
    • Paul Bolle's avatar
      doc: fix broken references · 395cf969
      Paul Bolle authored
      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: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      395cf969
  9. 10 Mar, 2010 1 commit
  10. 19 Jun, 2009 1 commit
  11. 15 Jun, 2009 1 commit
  12. 03 Jun, 2009 2 commits
    • Johannes Berg's avatar
      rfkill: document /dev/rfkill · f71fea23
      Johannes Berg authored
      Add some blurb about /dev/rfkill to the documentation and
      fix the "transmiter" spelling error.
      Signed-off-by: Johannes Berg's avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f71fea23
    • Johannes Berg's avatar
      rfkill: rewrite · 19d337df
      Johannes Berg authored
      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: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: Johannes Berg's avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      19d337df
  13. 22 Apr, 2009 1 commit
  14. 31 Oct, 2008 1 commit
    • Henrique de Moraes Holschuh's avatar
      rfkill: add master_switch_mode and EPO lock to rfkill and rfkill-input · d003922d
      Henrique de Moraes Holschuh authored
      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's avatarHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d003922d
  15. 15 Sep, 2008 1 commit
    • Henrique de Moraes Holschuh's avatar
      rfkill: remove transmitter blocking on suspend · bed7aac9
      Henrique de Moraes Holschuh authored
      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's avatarHenrique 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: default avatarJohn W. Linville <linville@tuxdriver.com>
      bed7aac9
  16. 18 Aug, 2008 1 commit
  17. 29 Jul, 2008 1 commit
  18. 26 Jun, 2008 4 commits
  19. 10 Oct, 2007 1 commit