1. 05 Sep, 2019 33 commits
  2. 03 Sep, 2019 7 commits
    • Gustavo A. R. Silva's avatar
      zd1211rw: zd_usb: Use struct_size() helper · 84b0b663
      Gustavo A. R. Silva authored
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct usb_int_regs {
      	...
              struct reg_data regs[0];
      } __packed;
      
      Make use of the struct_size() helper instead of an open-coded version
      in order to avoid any potential type mistakes.
      
      So, replace the following function:
      
      static int usb_int_regs_length(unsigned int count)
      {
             return sizeof(struct usb_int_regs) + count * sizeof(struct reg_data);
      }
      
      with:
      
      struct_size(regs, regs, count)
      
      This code was detected with the help of Coccinelle.
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      84b0b663
    • Rafał Miłecki's avatar
      brcmfmac: get chip's default RAM info during PCIe setup · 82f93cf4
      Rafał Miłecki authored
      Getting RAM info just once per driver's lifetime (during chip
      recognition) is not enough as it may get adjusted later (depending on
      the used firmware). Subsequent inits may load different firmwares so a
      full RAM recognition is required on every PCIe setup. This is especially
      important since implementing hardware reset on a firmware crash.
      
      Moreover calling brcmf_chip_get_raminfo() makes sure that RAM core is
      up. It's important as having BCMA_CORE_SYS_MEM down on BCM4366 was
      resulting in firmware failing to initialize and following error:
      [   65.657546] brcmfmac 0000:01:00.0: brcmf_pcie_download_fw_nvram: Invalid shared RAM address 0x04000001
      
      This change makes brcmf_chip_get_raminfo() call during chip recognition
      redundant for PCIe devices but SDIO and USB still need it and it's a
      very small overhead anyway.
      
      Fixes: 4684997d ("brcmfmac: reset PCIe bus on a firmware crash")
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      82f93cf4
    • Colin Ian King's avatar
      bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA · 420c20be
      Colin Ian King authored
      An earlier commit re-worked the setting of the bitmask and is now
      assigning v with some bit flags rather than bitwise or-ing them
      into v, consequently the earlier bit-settings of v are being lost.
      Fix this by replacing an assignment with the bitwise or instead.
      
      Addresses-Coverity: ("Unused value")
      Fixes: 2be25cac ("bcma: add constants for PCI and use them")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      420c20be
    • Xulin Sun's avatar
      brcmfmac: replace strncpy() by strscpy() · 5f42b382
      Xulin Sun authored
      The strncpy() may truncate the copied string,
      replace it by the safer strscpy().
      
      To avoid below compile warning with gcc 8.2:
      
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 'brcmf_vndr_ie':
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2:
      warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation]
        strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: default avatarXulin Sun <xulin.sun@windriver.com>
      Acked-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      5f42b382
    • Stanislaw Gruszka's avatar
      rt2x00: do not set IEEE80211_TX_STAT_AMPDU_NO_BACK on tx status · 567a9b76
      Stanislaw Gruszka authored
      According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose
      to be used when we do not recive BA (BlockAck). However on rt2x00 we
      use it when remote station fail to decode one or more subframes within
      AMPDU (some bits are not set in BlockAck bitmap). Setting the flag result
      in sent of BAR (BlockAck Request) frame and this might result of abuse
      of BA session, since remote station can sent BA with incorrect
      sequence numbers after receiving BAR. This problem is visible especially
      when connecting two rt2800 devices.
      
      Previously I observed some performance benefits when using the flag
      when connecting with iwlwifi devices. But currently possibly due
      to reacent changes in rt2x00 removing the flag has no effect on
      those test cases.
      
      So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK.
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      567a9b76
    • Colin Ian King's avatar
      ipw2x00: fix spelling mistake "initializationg" -> "initialization" · 14aba893
      Colin Ian King authored
      There is a spelling mistake in an IPW_DEBUG_INFO message. Fix it.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      14aba893
    • Wenwen Wang's avatar
      airo: fix memory leaks · 145a32fe
      Wenwen Wang authored
      In proc_BSSList_open(), 'file->private_data' is allocated through kzalloc()
      and 'data->rbuffer' is allocated through kmalloc(). In the following
      execution, if an error occurs, they are not deallocated, leading to memory
      leaks. To fix this issue, free the allocated memory regions before
      returning the error.
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      145a32fe