1. 26 4月, 2019 2 次提交
  2. 08 2月, 2019 11 次提交
  3. 18 12月, 2018 1 次提交
  4. 10 9月, 2018 1 次提交
    • J
      cfg80211: Address some corner cases in scan result channel updating · 119f94a6
      Jouni Malinen 提交于
      cfg80211_get_bss_channel() is used to update the RX channel based on the
      available frame payload information (channel number from DSSS Parameter
      Set element or HT Operation element). This is needed on 2.4 GHz channels
      where frames may be received on neighboring channels due to overlapping
      frequency range.
      
      This might of some use on the 5 GHz band in some corner cases, but
      things are more complex there since there is no n:1 or 1:n mapping
      between channel numbers and frequencies due to multiple different
      starting frequencies in different operating classes. This could result
      in ieee80211_channel_to_frequency() returning incorrect frequency and
      ieee80211_get_channel() returning incorrect channel information (or
      indication of no match). In the previous implementation, this could
      result in some scan results being dropped completely, e.g., for the 4.9
      GHz channels. That prevented connection to such BSSs.
      
      Fix this by using the driver-provided channel pointer if
      ieee80211_get_channel() does not find matching channel data for the
      channel number in the frame payload and if the scan is done with 5 MHz
      or 10 MHz channel bandwidth. While doing this, also add comments
      describing what the function is trying to achieve to make it easier to
      understand what happens here and why.
      Signed-off-by: NJouni Malinen <jouni@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      119f94a6
  5. 19 12月, 2017 1 次提交
  6. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  7. 23 5月, 2017 1 次提交
    • A
      cfg80211: make cfg80211_sched_scan_results() work from atomic context · 1b57b621
      Arend Van Spriel 提交于
      Drivers should be able to call cfg80211_sched_scan_results() from atomic
      context. However, with the introduction of multiple scheduled scan feature
      this requirement was not taken into account resulting in regression shown
      below.
      
      [  119.021594] BUG: scheduling while atomic: irq/47-iwlwifi/517/0x00000200
      [  119.021604] Modules linked in: [...]
      [  119.021759] CPU: 1 PID: 517 Comm: irq/47-iwlwifi Not tainted 4.12.0-rc2-t440s-20170522+ #1
      [  119.021763] Hardware name: LENOVO 20AQS03H00/20AQS03H00, BIOS GJET91WW (2.41 ) 09/21/2016
      [  119.021766] Call Trace:
      [  119.021778]  ? dump_stack+0x5c/0x84
      [  119.021784]  ? __schedule_bug+0x4c/0x70
      [  119.021792]  ? __schedule+0x496/0x5c0
      [  119.021798]  ? schedule+0x2d/0x80
      [  119.021804]  ? schedule_preempt_disabled+0x5/0x10
      [  119.021810]  ? __mutex_lock.isra.0+0x18e/0x4c0
      [  119.021817]  ? __wake_up+0x2f/0x50
      [  119.021833]  ? cfg80211_sched_scan_results+0x19/0x60 [cfg80211]
      [  119.021844]  ? cfg80211_sched_scan_results+0x19/0x60 [cfg80211]
      [  119.021859]  ? iwl_mvm_rx_lmac_scan_iter_complete_notif+0x17/0x30 [iwlmvm]
      [  119.021869]  ? iwl_pcie_rx_handle+0x2a9/0x7e0 [iwlwifi]
      [  119.021878]  ? iwl_pcie_irq_handler+0x17c/0x730 [iwlwifi]
      [  119.021884]  ? irq_forced_thread_fn+0x60/0x60
      [  119.021887]  ? irq_thread_fn+0x16/0x40
      [  119.021892]  ? irq_thread+0x109/0x180
      [  119.021896]  ? wake_threads_waitq+0x30/0x30
      [  119.021901]  ? kthread+0xf2/0x130
      [  119.021905]  ? irq_thread_dtor+0x90/0x90
      [  119.021910]  ? kthread_create_on_node+0x40/0x40
      [  119.021915]  ? ret_from_fork+0x26/0x40
      
      Fixes: b34939b9 ("cfg80211: add request id to cfg80211_sched_scan_*() api")
      Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
      Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1b57b621
  8. 28 4月, 2017 1 次提交
  9. 27 4月, 2017 2 次提交
  10. 18 4月, 2017 1 次提交
  11. 16 12月, 2016 1 次提交
  12. 18 11月, 2016 1 次提交
    • J
      cfg80211: limit scan results cache size · 9853a55e
      Johannes Berg 提交于
      It's possible to make scanning consume almost arbitrary amounts
      of memory, e.g. by sending beacon frames with random BSSIDs at
      high rates while somebody is scanning.
      
      Limit the number of BSS table entries we're willing to cache to
      1000, limiting maximum memory usage to maybe 4-5MB, but lower
      in practice - that would be the case for having both full-sized
      beacon and probe response frames for each entry; this seems not
      possible in practice, so a limit of 1000 entries will likely be
      closer to 0.5 MB.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9853a55e
  13. 16 9月, 2016 1 次提交
  14. 06 7月, 2016 1 次提交
    • A
      nl80211: support beacon report scanning · 1d76250b
      Avraham Stern 提交于
      Beacon report radio measurement requires reporting observed BSSs
      on the channels specified in the beacon request. If the measurement
      mode is set to passive or active, it requires actually performing a
      scan (passive or active, accordingly), and reporting the time that
      the scan was started and the time each beacon/probe was received
      (both in terms of TSF of the BSS of the requesting AP). If the
      request mode is table, this information is optional.
      In addition, the radio measurement request specifies the channel
      dwell time for the measurement.
      
      In order to use scan for beacon report when the mode is active or
      passive, add a parameter to scan request that specifies the
      channel dwell time, and add scan start time and beacon received time
      to scan results information.
      
      Supporting beacon report is required for Multi Band Operation (MBO).
      Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d76250b
  15. 12 5月, 2016 1 次提交
  16. 12 4月, 2016 1 次提交
  17. 05 4月, 2016 1 次提交
    • J
      cfg80211: Allow a scan request for a specific BSSID · 818965d3
      Jouni Malinen 提交于
      This allows scans for a specific BSSID to be optimized by the user space
      application by requesting the driver to set the Probe Request frame
      BSSID field (Address 3) to the specified BSSID instead of the wildcard
      BSSID. This prevents other APs from replying which reduces airtime need
      and latency in getting the response from the target AP through.
      
      This is an optimization and as such, it is acceptable for some of the
      drivers not to support the mechanism. If not supported, the wildcard
      BSSID will be used and more responses may be received.
      Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      818965d3
  18. 13 10月, 2015 2 次提交
    • A
      cfg80211: Add multiple scan plans for scheduled scan · 3b06d277
      Avraham Stern 提交于
      Add the option to configure multiple 'scan plans' for scheduled scan.
      Each 'scan plan' defines the number of scan cycles and the interval
      between scans. The scan plans are executed in the order they were
      configured. The last scan plan will always run infinitely and thus
      defines only the interval between scans.
      The maximum number of scan plans supported by the device and the
      maximum number of iterations in a single scan plan are advertised
      to userspace so it can configure the scan plans appropriately.
      
      When scheduled scan results are received there is no way to know which
      scan plan is being currently executed, so there is no way to know when
      the next scan iteration will start. This is not a problem, however.
      The scan start timestamp is only used for flushing old scan results,
      and there is no difference between flushing all results received until
      the end of the previous iteration or the start of the current one,
      since no results will be received in between.
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3b06d277
    • D
      nl80211: allow BSS data to include CLOCK_BOOTTIME timestamp · 6e19bc4b
      Dmitry Shmidt 提交于
      For location and connectivity services, userspace would often like
      to know the time when the BSS was last seen. The current "last seen"
      value is calculated in a way that makes it less useful, especially
      if the system suspended in the meantime.
      
      Add the ability for the driver to report a real CLOCK_BOOTTIME stamp
      that can then be reported to userspace (if present).
      
      Drivers wishing to use this must be converted to the new API to call
      cfg80211_inform_bss_data() or cfg80211_inform_bss_frame_data(). They
      need to ensure the reported value is accurate enough even when the
      frame might have been buffered in the device (e.g. firmware.)
      Signed-off-by: NDmitry Shmidt <dimitrysh@google.com>
      [modified to use struct, inlines]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e19bc4b
  19. 03 3月, 2015 1 次提交
    • D
      cfg80211: add bss_type and privacy arguments in cfg80211_get_bss() · 6eb18137
      Dedy Lansky 提交于
      802.11ad adds new a network type (PBSS) and changes the capability
      field interpretation for the DMG (60G) band.
      The same 2 bits that were interpreted as "ESS" and "IBSS" before are
      re-used as a 2-bit field with 3 valid values (and 1 reserved). Valid
      values are: "IBSS", "PBSS" (new) and "AP".
      
      In order to get the BSS struct for the new PBSS networks, change the
      cfg80211_get_bss() function to take a new enum ieee80211_bss_type
      argument with the valid network types, as "capa_mask" and "capa_val"
      no longer work correctly (the search must be band-aware now.)
      
      The remaining bits in "capa_mask" and "capa_val" are used only for
      privacy matching so replace those two with a privacy enum as well.
      Signed-off-by: NDedy Lansky <dlansky@codeaurora.org>
      [rewrite commit log, tiny fixes]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6eb18137
  20. 01 3月, 2015 2 次提交
    • J
      cfg80211-wext: return -E2BIG when buffer can't hold full BSS entry · 76a70e9c
      James Minor 提交于
      When using the wext compatibility code in cfg80211, part of the IEs
      can be truncated if the passed user buffer is large enough for part
      of the BSS but not large enough for all of the IEs.  This can cause
      an EAP network to show up as a PSK network.
      
      Always return -E2BIG in this case to avoid truncating data.
      
      Since this changes the control flow, use an on-stack variable for
      a small buffer instead of allocating it.
      Signed-off-by: NJames Minor <james.minor@ni.com>
      [rework patch to error out immediately, use _check wrappers]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      76a70e9c
    • J
      cfg80211-wext: export symbols only when needed · 2afe38d1
      Johannes Berg 提交于
      When a fully converted cfg80211 driver needs cfg80211-wext for
      userspace API purposes, the symbols need not be exported. When
      other drivers (orinoco/hermes or ipw2200) are enabled, they do
      need the symbols exported as they use them directly.
      
      Make those drivers select a new CFG80211_WEXT_EXPORT Kconfig
      symbol (instead of just CFG80211_WEXT) and export the functions
      only if requested - this saves about 1/2k due to the size of
      EXPORT_SYMBOL() itself.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2afe38d1
  21. 18 12月, 2014 1 次提交
  22. 05 9月, 2014 1 次提交
  23. 26 8月, 2014 2 次提交
    • J
      cfg80211: allow passing frame type to cfg80211_inform_bss() · 5bc8c1f2
      Johannes Berg 提交于
      When using the cfg80211_inform_bss[_width]() functions drivers
      cannot currently indicate whether the data was received in a
      beacon or probe response. Fix that by passing a new enum that
      indicates such (or unknown).
      
      For good measure, use it in ath6kl.
      
      Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
      Acked-by: Arend van Spriel <arend@broadcom.com> [brcmfmac]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5bc8c1f2
    • J
      cfg80211: clarify BSS probe response vs. beacon data · 0e227084
      Johannes Berg 提交于
      There are a few possible cases of where BSS data came from:
       1) only a beacon has been received
       2) only a probe response has been received
       3) the driver didn't report what it received (this happens when
          using cfg80211_inform_bss[_width]())
       4) both probe response and beacon data has been received
      
      Unfortunately, in the userspace API, a few things weren't there:
       a) there was no way to differentiate cases 1) and 4) above
          without comparing the data of the IEs
       b) the TSF was always from the last frame, instead of being
          exposed for beacon/probe response separately like IEs
      
      Fix this by
         i) exporting a new flag attribute that indicates whether or
            not probe response data has been received - this addresses (a)
        ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
            if a beacon has been received
       iii) not exporting the beacon attributes in case (3) above as that
            would just lead userspace into thinking the data actually came
            from a beacon when that isn't clear
      
      To implement this, track inside the IEs struct whether or not it
      (definitely) came from a beacon.
      
      Reported-by: William Seto
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0e227084
  24. 22 5月, 2014 1 次提交
    • E
      cfg80211: allow RSSI compensation · 67af9811
      Emmanuel Grumbach 提交于
      Channels in 2.4GHz band overlap, this means that if we
      send a probe request on channel 1 and then move to channel
      2, we will hear the probe response on channel 2. In this
      case, the RSSI will be lower than if we had heard it on
      the channel on which it was sent (1 in this case).
      
      The firmware / low level driver can parse the channel in
      the DS IE or HT IE and compensate the RSSI so that it will
      still have a valid value even if we heard the frame on an
      adjacent channel. This can be done up to a certain offset.
      
      Add this offset as a configuration for the low level driver.
      A low level driver that can compensate the low RSSI in this
      case should assign the maximal offset for which the RSSI
      value is still valid.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      67af9811
  25. 05 5月, 2014 1 次提交