1. 24 7月, 2019 1 次提交
  2. 28 5月, 2019 2 次提交
  3. 21 2月, 2019 1 次提交
  4. 08 2月, 2019 1 次提交
  5. 10 1月, 2019 1 次提交
    • H
      brcmfmac: Use firmware_request_nowarn for the clm_blob · 4ad0be16
      Hans de Goede 提交于
      The linux-firmware brcmfmac firmware files contain an embedded table with
      per country allowed channels and strength info.
      
      For recent hardware these versions of the firmware are specially build for
      linux-firmware, the firmware files directly available from Cypress rely on
      a separate clm_blob file for this info.
      
      For some unknown reason Cypress refuses to provide the standard firmware
      files + clm_blob files it uses elsewhere for inclusion into linux-firmware,
      instead relying on these special builds with the clm_blob info embedded.
      This means that the linux-firmware firmware versions often lag behind,
      but I digress.
      
      The brcmfmac driver does support the separate clm_blob file and always
      tries to load this. Currently we use request_firmware for this. This means
      that on any standard install, using the standard combo of linux-kernel +
      linux-firmware, we will get a warning:
      "Direct firmware load for ... failed with error -2"
      
      On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
      device may have limited channels available".
      
      This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
      device logging the warning (it leaves the brcmfmac info message in place).
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4ad0be16
  6. 29 11月, 2018 1 次提交
    • H
      brcmfmac: Call brcmf_dmi_probe before brcmf_of_probe · 554da386
      Hans de Goede 提交于
      ARM systems with UEFI may have both devicetree (of) and DMI data in this
      case we end up setting brcmf_mp_device.board_type twice.
      
      In this case we should prefer the devicetree data, because:
      1) The devicerree data is more reliable
      2) Some ARM systems (e.g. the Raspberry Pi 3 models) support both UEFI and
         classic uboot booting, the devicetree data is always there, so using it
         makes sure we ask for the same nvram file independent of how we booted.
      
      This commit moves the brcmf_dmi_probe call to before the brcmf_of_probe
      call, so that the latter can override the value of the first if both are
      set.
      
      Fixes: bd1e82bb ("brcmfmac: Set board_type from DMI on x86 based ...")
      Cc: Peter Robinson <pbrobinson@gmail.com>
      Tested-and-reported-by: NPeter Robinson <pbrobinson@gmail.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      554da386
  7. 07 11月, 2018 2 次提交
  8. 31 8月, 2018 1 次提交
    • R
      brcmfmac: fix wrong strnchr usage · cb18e2e9
      Rasmus Villemoes 提交于
      strnchr takes arguments in the order of its name: string, max bytes to
      read, character to search for. Here we're passing '\n' aka 10 as the
      buffer size, and searching for sizeof(buf) aka BRCMF_DCMD_SMLEN aka
      256 (aka '\0', since it's implicitly converted to char) within those 10
      bytes.
      
      Just interchanging the last two arguments would still leave a bug,
      because if we've been successful once, there are not sizeof(buf)
      characters left after the new value of p.
      
      Since clmver is immediately afterwards passed as a %s argument, I assume
      that it is actually a properly nul-terminated string. For that case, we
      have strreplace().
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      cb18e2e9
  9. 23 5月, 2018 1 次提交
  10. 27 3月, 2018 5 次提交
  11. 16 3月, 2018 1 次提交
    • R
      brcmfmac: drop Inter-Access Point Protocol packets by default · 12590551
      Rafał Miłecki 提交于
      Testing brcmfmac with more recent firmwares resulted in AP interfaces
      not working in some specific setups. Debugging resulted in discovering
      support for IAPP in Broadcom's firmwares.
      
      Older firmwares were only generating 802.11f frames. Newer ones like:
      1) 10.10 (TOB) (r663589)
      2) 10.10.122.20 (r683106)
      for 4366b1 and 4366c0 respectively seem to also /respect/ 802.11f frames
      in the Tx path by performing a STA disassociation.
      
      This obsoleted standard and its implementation is something that:
      1) Most people don't need / want to use
      2) Can allow local DoS attacks
      3) Breaks AP interfaces in some specific bridge setups
      
      To solve issues it can cause this commit modifies brcmfmac to drop IAPP
      packets. If affects:
      1) Rx path: driver won't be sending these unwanted packets up.
      2) Tx path: driver will reject packets that would trigger STA
         disassociation perfromed by a firmware (possible local DoS attack).
      
      It appears there are some Broadcom's clients/users who care about this
      feature despite the drawbacks. They can switch it on using a new module
      param.
      
      This change results in only two more comparisons (check for module param
      and check for Ethernet packet length) for 99.9% of packets. Its overhead
      should be very minimal.
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      12590551
  12. 28 2月, 2018 1 次提交
  13. 17 1月, 2018 1 次提交
  14. 11 11月, 2017 1 次提交
  15. 21 3月, 2017 1 次提交
  16. 08 2月, 2017 1 次提交
  17. 20 1月, 2017 1 次提交
  18. 19 1月, 2017 1 次提交
  19. 26 4月, 2016 1 次提交
  20. 07 3月, 2016 5 次提交
  21. 20 1月, 2016 1 次提交
  22. 07 1月, 2016 2 次提交
  23. 30 11月, 2015 2 次提交
  24. 18 11月, 2015 1 次提交
  25. 29 1月, 2015 2 次提交
  26. 07 1月, 2015 1 次提交
  27. 31 10月, 2014 1 次提交