1. 12 Jan, 2017 1 commit
    • Arnd Bergmann's avatar
      wext: handle NULL extra data in iwe_stream_add_point better · 93be2b74
      Arnd Bergmann authored
      gcc-7 complains that wl3501_cs passes NULL into a function that
      then uses the argument as the input for memcpy:
      
      drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
      include/net/iw_handler.h:559:3: error: argument 2 null where non-null expected [-Werror=nonnull]
         memcpy(stream + point_len, extra, iwe->u.data.length);
      
      This works fine here because iwe->u.data.length is guaranteed to be 0
      and the memcpy doesn't actually have an effect.
      
      Making the length check explicit avoids the warning and should have
      no other effect here.
      
      Also check the pointer itself, since otherwise we get warnings
      elsewhere in the code.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      93be2b74
  2. 11 Jan, 2017 1 commit
    • Jorge Ramirez-Ortiz's avatar
      cfg80211: wext does not need to set monitor channel in managed mode · 7acec26c
      Jorge Ramirez-Ortiz authored
      There is not a valid reason to attempt setting the monitor channel
      while in managed mode. Since this code path only deals with this mode,
      remove the code block.
      
      Johannes: I'll note that the comment indicated it was for backward
      compatibility, but the code wasn't functional since switching the
      monitor channel isn't supported (any more?) when in managed mode, as
      that mode owns the channel configuration. Additionally, since monitor
      can't be done on a managed mode interface, this would only have had
      any effect to start with if a separate monitor interface is present,
      in which case it's better to change the channel through that anyway,
      if even possible.
      Signed-off-by: default avatarJorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7acec26c
  3. 09 Jan, 2017 3 commits
    • Andrzej Zaborowski's avatar
      cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT · bd2522b1
      Andrzej Zaborowski authored
      Disconnect or deauthenticate when the owning socket is closed if this
      flag is supplied to CMD_CONNECT or CMD_ASSOCIATE.  This may be used
      to ensure userspace daemon doesn't leave an unmanaged connection behind.
      
      In some situations it would be possible to account for that, to some
      degree, in the deamon restart code or in the up/down scripts without
      the use of this attribute.  But there will be systems where the daemon
      can go away for varying periods without a warning due to local resource
      management.
      Signed-off-by: default avatarAndrew Zaborowski <andrew.zaborowski@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      bd2522b1
    • Johannes Berg's avatar
      cfg80211: size various nl80211 messages correctly · 4ef8c1c9
      Johannes Berg authored
      Ilan reported that sometimes nl80211 messages weren't working if
      the frames being transported got very large, which was really a
      problem for userspace-to-kernel messages, but prompted me to look
      at the code.
      
      Upon review, I found various places where variable-length data is
      transported in an nl80211 message but the message isn't allocated
      taking that into account. This shouldn't cause any problems since
      the frames aren't really that long, apart in one place where two
      (possibly very long frames) might not fit.
      
      Fix all the places (that I found) that get variable length data
      from the driver and put it into a message to take the length of
      the variable data into account. The 100 there is just a safe
      constant for the remaining message overhead (it's usually around
      50 for most messages.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4ef8c1c9
    • Michał Kępień's avatar
      rfkill: Add rfkill-any LED trigger · 9b8e34e2
      Michał Kępień authored
      Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
      which may be useful on laptops with a single "radio LED" and multiple
      radio transmitters.  The trigger is meant to turn a LED on whenever
      there is at least one radio transmitter active and turn it off
      otherwise.
      Signed-off-by: default avatarMichał Kępień <kernel@kempniu.pl>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9b8e34e2
  4. 06 Jan, 2017 3 commits
  5. 05 Jan, 2017 2 commits
  6. 04 Jan, 2017 1 commit
  7. 02 Jan, 2017 3 commits
  8. 20 Dec, 2016 1 commit
  9. 16 Dec, 2016 3 commits
  10. 15 Dec, 2016 11 commits
  11. 13 Dec, 2016 11 commits