1. 05 9月, 2017 1 次提交
  2. 07 7月, 2017 4 次提交
  3. 30 6月, 2017 1 次提交
  4. 13 6月, 2017 3 次提交
  5. 19 5月, 2017 2 次提交
  6. 08 5月, 2017 1 次提交
  7. 28 4月, 2017 1 次提交
  8. 27 4月, 2017 3 次提交
  9. 18 4月, 2017 2 次提交
  10. 14 4月, 2017 2 次提交
    • J
      netlink: pass extended ACK struct where available · fe52145f
      Johannes Berg 提交于
      This is an add-on to the previous patch that passes the extended ACK
      structure where it's already available by existing genl_info or extack
      function arguments.
      
      This was done with this spatch (with some manual adjustment of
      indentation):
      
      @@
      expression A, B, C, D, E;
      identifier fn, info;
      @@
      fn(..., struct genl_info *info, ...) {
      ...
      -nlmsg_parse(A, B, C, D, E, NULL)
      +nlmsg_parse(A, B, C, D, E, info->extack)
      ...
      }
      
      @@
      expression A, B, C, D, E;
      identifier fn, info;
      @@
      fn(..., struct genl_info *info, ...) {
      <...
      -nla_parse_nested(A, B, C, D, NULL)
      +nla_parse_nested(A, B, C, D, info->extack)
      ...>
      }
      
      @@
      expression A, B, C, D, E;
      identifier fn, extack;
      @@
      fn(..., struct netlink_ext_ack *extack, ...) {
      <...
      -nlmsg_parse(A, B, C, D, E, NULL)
      +nlmsg_parse(A, B, C, D, E, extack)
      ...>
      }
      
      @@
      expression A, B, C, D, E;
      identifier fn, extack;
      @@
      fn(..., struct netlink_ext_ack *extack, ...) {
      <...
      -nla_parse(A, B, C, D, E, NULL)
      +nla_parse(A, B, C, D, E, extack)
      ...>
      }
      
      @@
      expression A, B, C, D, E;
      identifier fn, extack;
      @@
      fn(..., struct netlink_ext_ack *extack, ...) {
      ...
      -nlmsg_parse(A, B, C, D, E, NULL)
      +nlmsg_parse(A, B, C, D, E, extack)
      ...
      }
      
      @@
      expression A, B, C, D;
      identifier fn, extack;
      @@
      fn(..., struct netlink_ext_ack *extack, ...) {
      <...
      -nla_parse_nested(A, B, C, D, NULL)
      +nla_parse_nested(A, B, C, D, extack)
      ...>
      }
      
      @@
      expression A, B, C, D;
      identifier fn, extack;
      @@
      fn(..., struct netlink_ext_ack *extack, ...) {
      <...
      -nlmsg_validate(A, B, C, D, NULL)
      +nlmsg_validate(A, B, C, D, extack)
      ...>
      }
      
      @@
      expression A, B, C, D;
      identifier fn, extack;
      @@
      fn(..., struct netlink_ext_ack *extack, ...) {
      <...
      -nla_validate(A, B, C, D, NULL)
      +nla_validate(A, B, C, D, extack)
      ...>
      }
      
      @@
      expression A, B, C;
      identifier fn, extack;
      @@
      fn(..., struct netlink_ext_ack *extack, ...) {
      <...
      -nla_validate_nested(A, B, C, NULL)
      +nla_validate_nested(A, B, C, extack)
      ...>
      }
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe52145f
    • J
      netlink: pass extended ACK struct to parsing functions · fceb6435
      Johannes Berg 提交于
      Pass the new extended ACK reporting struct to all of the generic
      netlink parsing functions. For now, pass NULL in almost all callers
      (except for some in the core.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fceb6435
  11. 13 4月, 2017 3 次提交
  12. 31 3月, 2017 2 次提交
  13. 16 3月, 2017 2 次提交
  14. 06 3月, 2017 2 次提交
    • V
      cfg80211: Disallow moving out of operating DFS channel in non-ETSI · 34373d12
      Vasanthakumar Thiagarajan 提交于
      For non-ETSI regulatory domain, CAC result on DFS channel
      may not be valid once moving out of that channel (as done
      during remain-on-channel, scannning and off-channel tx).
      Running CAC on an operating DFS channel after every off-channel
      operation will only add complexity and disturb the current
      link. Better do not allow any off-channel switch from a DFS
      operating channel in non-ETSI domain.
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34373d12
    • A
      cfg80211: Accept multiple RSSI thresholds for CQM · 4a4b8169
      Andrew Zaborowski 提交于
      Change the SET CQM command's RSSI threshold attribute to accept any
      number of thresholds as a sorted array.  The API should be backwards
      compatible so that if one s32 threshold value is passed, the old
      mechanism is enabled.  The netlink event generated is the same in both
      cases.
      
      cfg80211 handles an arbitrary number of RSSI thresholds but drivers have
      to provide a method (set_cqm_rssi_range_config) that configures a range
      set by a high and a low value.  Drivers have to call back when the RSSI
      goes out of that range and there's no additional event for each time the
      range is reconfigured as there was with the current one-threshold API.
      
      This method doesn't have a hysteresis parameter because there's no
      benefit to the cfg80211 code from having the hysteresis be handled by
      hardware/driver in terms of the number of wakeups.  At the same time
      it would likely be less consistent between drivers if offloaded or
      done in the drivers.
      Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4a4b8169
  15. 09 2月, 2017 1 次提交
    • L
      cfg80211: fix NAN bands definition · 8585989d
      Luca Coelho 提交于
      The nl80211_nan_dual_band_conf enumeration doesn't make much sense.
      The default value is assigned to a bit, which makes it weird if the
      default bit and other bits are set at the same time.
      
      To improve this, get rid of NL80211_NAN_BAND_DEFAULT and add a wiphy
      configuration to let the drivers define which bands are supported.
      This is exposed to the userspace, which then can make a decision on
      which band(s) to use.  Additionally, rename all "dual_band" elements
      to "bands", to make things clearer.
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8585989d
  16. 08 2月, 2017 4 次提交
  17. 06 2月, 2017 1 次提交
  18. 13 1月, 2017 2 次提交
  19. 11 1月, 2017 1 次提交
    • B
      cfg80211: consider VHT opmode on station update · 06f7c88c
      Beni Lev 提交于
      Currently, this attribute is only fetched on station addition, but
      not on station change. Since this info is only present in the assoc
      request, with full station state support in the driver it cannot be
      present when the station is added.
      
      Thus, add support for changing the VHT opmode on station update if
      done before (or while) the station is marked as associated. After
      this, ignore it, since it used to be ignored.
      Signed-off-by: NBeni Lev <beni.lev@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      06f7c88c
  20. 09 1月, 2017 2 次提交
    • A
      cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT · bd2522b1
      Andrzej Zaborowski 提交于
      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: NAndrew Zaborowski <andrew.zaborowski@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bd2522b1
    • J
      cfg80211: size various nl80211 messages correctly · 4ef8c1c9
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      4ef8c1c9