1. 21 Jul, 2019 1 commit
    • Brian Norris's avatar
      mwifiex: Don't abort on small, spec-compliant vendor IEs · ced121ed
      Brian Norris authored
      commit 63d7ef36103d26f20325a921ecc96a3288560146 upstream.
      
      Per the 802.11 specification, vendor IEs are (at minimum) only required
      to contain an OUI. A type field is also included in ieee80211.h (struct
      ieee80211_vendor_ie) but doesn't appear in the specification. The
      remaining fields (subtype, version) are a convention used in WMM
      headers.
      
      Thus, we should not reject vendor-specific IEs that have only the
      minimum length (3 bytes) -- we should skip over them (since we only want
      to match longer IEs, that match either WMM or WPA formats). We can
      reject elements that don't have the minimum-required 3 byte OUI.
      
      While we're at it, move the non-standard subtype and version fields into
      the WMM structs, to avoid this confusion in the future about generic
      "vendor header" attributes.
      
      Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element")
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ced121ed
  2. 30 Jun, 2017 1 commit
  3. 31 May, 2017 1 commit
  4. 20 Apr, 2017 1 commit
  5. 20 Mar, 2017 1 commit
  6. 20 Jan, 2017 1 commit
    • Brian Norris's avatar
      mwifiex: don't complain about 'unknown event id: 0x63' · 0ed917d0
      Brian Norris authored
      Marvell folks tell me this is a debugging event that the driver doesn't
      need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of
      these sorts of messages at (for instance) boot time:
      
      [   13.825848] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
      [   14.838561] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
      [   14.850397] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
      [   32.529923] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
      
      Let's handle this "event" with a much lower verbosity.
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      0ed917d0
  7. 30 Dec, 2016 2 commits
  8. 25 Nov, 2016 1 commit
  9. 18 Nov, 2016 1 commit
  10. 26 Sep, 2016 1 commit
  11. 03 Sep, 2016 6 commits
  12. 08 Jul, 2016 1 commit
  13. 05 Jul, 2016 1 commit
  14. 07 Apr, 2016 2 commits
  15. 06 Feb, 2016 1 commit
  16. 29 Jan, 2016 5 commits
  17. 30 Dec, 2015 1 commit
  18. 11 Dec, 2015 1 commit
  19. 18 Nov, 2015 1 commit
  20. 14 Oct, 2015 1 commit
  21. 29 Sep, 2015 1 commit
  22. 13 Aug, 2015 1 commit
  23. 06 Aug, 2015 1 commit
    • Andreas Fenkart's avatar
      mwifiex: remove CMD_F_CANCELED flag · e9f21d40
      Andreas Fenkart authored
      CMD_F_CANCELED was used to abort mwifiex_process_cmdresp in
      case it already started or starts processing the cmd.
      But this was probably not working the way intended:
      - it is racy: mwifiex_process_cmdresp might already have passed that
        test and is continuing to use the cmd node being recycled
      - mwifiex_process_cmdresp repeatedly uses adapter->curr_cmd which
        we just set to NULL
      - mwifiex_recycle_cmd_node will clear the flag
      
      The reason why it probably works is that mwifiex_cancel_pending_ioctl
      is only called from mwifiex_cmd_timeout_func, where the there is little
      chance of a command response still arriving
      Signed-off-by: default avatarAndreas Fenkart <afenkart@gmail.com>
      Acked-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      e9f21d40
  24. 21 Jul, 2015 6 commits