1. 01 11月, 2008 2 次提交
    • T
      ipw2x00: change default policy for auto-associate · 5c7f9b73
      Tim Gardner 提交于
      Do not attempt association until directed to do so by a user space
      application. In particular, this avoids race conditions with
      NetworkManager association state.
      Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
      Acked-by: NDan Williams <dcbw@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5c7f9b73
    • H
      rfkill: add master_switch_mode and EPO lock to rfkill and rfkill-input · d003922d
      Henrique de Moraes Holschuh 提交于
      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: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d003922d
  2. 31 10月, 2008 8 次提交
  3. 30 10月, 2008 6 次提交
  4. 28 10月, 2008 3 次提交
  5. 27 10月, 2008 2 次提交
  6. 23 10月, 2008 8 次提交
  7. 22 10月, 2008 1 次提交
    • M
      powerpc: Support for relocatable kdump kernel · 54622f10
      Mohan Kumar M 提交于
      This adds relocatable kernel support for kdump. With this one can
      use the same regular kernel to capture the kdump. A signature (0xfeed1234)
      is passed in r6 from panic code to the next kernel through kexec_sequence
      and purgatory code. The signature is used to differentiate between
      kdump kernel and non-kdump kernels.
      
      The purgatory code compares the signature and sets the __kdump_flag in
      head_64.S.  During the boot up, kernel code checks __kdump_flag and if it
      is set, the kernel will behave as relocatable kdump kernel. This kernel
      will boot at the address where it was loaded by kexec-tools ie. at the
      address reserved through crashkernel boot parameter.
      
      CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump
      kernel as relocatable. So the same kernel can be used as production and
      kdump kernel.
      
      This patch incorporates the changes suggested by Paul Mackerras to avoid
      GOT use and to avoid two copies of the code.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NMohan Kumar M <mohan@in.ibm.com>
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54622f10
  8. 21 10月, 2008 8 次提交
  9. 20 10月, 2008 2 次提交