1. 31 May, 2019 40 commits
    • Oded Gabbay's avatar
      habanalabs: prevent CPU soft lockup on Palladium · 9965948a
      Oded Gabbay authored
      [ Upstream commit e850b89f ]
      
      Unmapping ptes in the device MMU on Palladium can take a long time, which
      can cause a kernel BUG of CPU soft lockup.
      
      This patch minimize the chances for this bug by sleeping a little between
      unmapping ptes.
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9965948a
    • Sowjanya Komatineni's avatar
      spi: tegra114: reset controller on probe · 1955cfc8
      Sowjanya Komatineni authored
      [ Upstream commit 01919493 ]
      
      Fixes: SPI driver can be built as module so perform SPI controller reset
      on probe to make sure it is in valid state before initiating transfer.
      Signed-off-by: default avatarSowjanya Komatineni <skomatineni@nvidia.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1955cfc8
    • Hans de Goede's avatar
      HID: logitech-hidpp: change low battery level threshold from 31 to 30 percent · ddd85a2f
      Hans de Goede authored
      [ Upstream commit 1f87b0cd ]
      
      According to hidpp20_batterylevel_get_battery_info my Logitech K270
      keyboard reports only 2 battery levels. This matches with what I've seen
      after testing with batteries at varying level of fullness, it always
      reports either 5% or 30%.
      
      Windows reports "battery good" for the 30% level. I've captured an USB
      trace of Windows reading the battery and it is getting the same info
      as the Linux hidpp code gets.
      
      Now that Linux handles these devices as hidpp devices, it reports the
      battery as being low as it treats anything under 31% as low, this leads
      to the user constantly getting a "Keyboard battery is low" warning from
      GNOME3, which is very annoying.
      
      This commit fixes this by changing the low threshold to anything under
      30%, which I assume is what Windows does.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ddd85a2f
    • Takeshi Kihara's avatar
      clk: renesas: rcar-gen3: Correct parent clock of Audio-DMAC · f67fd9a6
      Takeshi Kihara authored
      [ Upstream commit b9df2ea2 ]
      
      The clock sources of the AXI-bus clock (266.66 MHz) used for Audio-DMAC
      DMA transfers are:
      
          Channel        R-Car H3    R-Car M3-W    R-Car M3-N    R-Car E3
          ---------------------------------------------------------------
          Audio-DMAC0    S1D2        S1D2          S1D2          S1D2
          Audio-DMAC1    S1D2        S1D2          S1D2          -
      
      As a result, change the parent clocks of the Audio-DMAC{0,1} module
      clocks on R-Car H3, R-Car M3-W, and R-Car M3-N to S1D2, and change the
      parent clock of the Audio-DMAC0 module on R-Car E3 to S1D2.
      
      NOTE: This information will be reflected in a future revision of the
            R-Car Gen3 Hardware Manual.
      Signed-off-by: default avatarTakeshi Kihara <takeshi.kihara.df@renesas.com>
      [geert: Update R-Car D3, RZ/G2M, and RZ/G2E]
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f67fd9a6
    • Ming Lei's avatar
      block: pass page to xen_biovec_phys_mergeable · 36478bcf
      Ming Lei authored
      [ Upstream commit 0383ad43 ]
      
      xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
      for checking if the two bvecs can be merged, so pass page to
      xen_biovec_phys_mergeable() directly.
      
      No function change.
      
      Cc: ris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: Omar Sandoval <osandov@fb.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      36478bcf
    • Ming Lei's avatar
      block: avoid to break XEN by multi-page bvec · 0aa9a8d4
      Ming Lei authored
      [ Upstream commit db5ebd6e ]
      
      XEN has special page merge requirement, see xen_biovec_phys_mergeable().
      We can't merge pages into one bvec simply for XEN.
      
      So move XEN's specific check on page merge into __bio_try_merge_page(),
      then abvoid to break XEN by multi-page bvec.
      
      Cc: ris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: Omar Sandoval <osandov@fb.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0aa9a8d4
    • Takeshi Kihara's avatar
      clk: renesas: rcar-gen3: Correct parent clock of SYS-DMAC · 46a9cbe9
      Takeshi Kihara authored
      [ Upstream commit 3c772f71 ]
      
      The clock sources of the AXI BUS clock (266.66 MHz) used for SYS-DMAC
      DMA transfers are:
      
          Channel      R-Car H3    R-Car M3-W    R-Car M3-N
          -------------------------------------------------
          SYS-DMAC0    S0D3        S0D3          S0D3
          SYS-DMAC1    S3D1        S3D1          S3D1
          SYS-DMAC2    S3D1        S3D1          S3D1
      
      As a result, change the parent clocks of the SYS-DMAC{1,2} module clocks
      on R-Car H3, R-Car M3-W, and R-Car M3-N to S3D1.
      
      NOTE: This information will be reflected in a future revision of the
            R-Car Gen3 Hardware Manual.
      Signed-off-by: default avatarTakeshi Kihara <takeshi.kihara.df@renesas.com>
      [geert: Update RZ/G2M]
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      46a9cbe9
    • Gustavo A. R. Silva's avatar
      cxgb3/l2t: Fix undefined behaviour · c9e691c2
      Gustavo A. R. Silva authored
      [ Upstream commit 76497732 ]
      
      The use of zero-sized array causes undefined behaviour when it is not
      the last member in a structure. As it happens to be in this case.
      
      Also, the current code makes use of a language extension to the C90
      standard, but the preferred mechanism to declare variable-length
      types such as this one is a flexible array member, introduced in
      C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last. Which is beneficial
      to cultivate a high-quality code.
      
      Fixes: e48f129c ("[SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c9e691c2
    • Wen Yang's avatar
      ASoC: wcd9335: fix a leaked reference by adding missing of_node_put · 58492aad
      Wen Yang authored
      [ Upstream commit 64b92de9 ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/codecs/wcd9335.c:5193:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 5183, but without a correspon    ding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Vinod Koul <vkoul@kernel.org>
      Cc: Dan Carpenter <dan.carpenter@oracle.com> (commit_signer:1/11=9%,authored:1/11=9%)
      Cc: alsa-devel@alsa-project.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      58492aad
    • Wen Yang's avatar
      ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put · f7d84b84
      Wen Yang authored
      [ Upstream commit c7052471 ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 38, but without a corresponding     object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Timur Tabi <timur@kernel.org>
      Cc: Nicolin Chen <nicoleotsuka@gmail.com>
      Cc: Xiubo Li <Xiubo.Lee@gmail.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f7d84b84
    • Wen Yang's avatar
      ASoC: eukrea-tlv320: fix a leaked reference by adding missing of_node_put · 28779829
      Wen Yang authored
      [ Upstream commit b820d52e ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/fsl/eukrea-tlv320.c:121:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 102, but without a correspo    nding object release within this function.
      ./sound/soc/fsl/eukrea-tlv320.c:127:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 102, but without a correspo    nding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      28779829
    • Nicolas Saenz Julienne's avatar
      HID: core: move Usage Page concatenation to Main item · a30cdaf1
      Nicolas Saenz Julienne authored
      [ Upstream commit 58e75155 ]
      
      As seen on some USB wireless keyboards manufactured by Primax, the HID
      parser was using some assumptions that are not always true. In this case
      it's s the fact that, inside the scope of a main item, an Usage Page
      will always precede an Usage.
      
      The spec is not pretty clear as 6.2.2.7 states "Any usage that follows
      is interpreted as a Usage ID and concatenated with the Usage Page".
      While 6.2.2.8 states "When the parser encounters a main item it
      concatenates the last declared Usage Page with a Usage to form a
      complete usage value." Being somewhat contradictory it was decided to
      match Window's implementation, which follows 6.2.2.8.
      
      In summary, the patch moves the Usage Page concatenation from the local
      item parsing function to the main item parsing function.
      Signed-off-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Reviewed-by: default avatarTerry Junge <terry.junge@poly.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a30cdaf1
    • Geert Uytterhoeven's avatar
      sh: sh7786: Add explicit I/O cast to sh7786_mm_sel() · 653117ea
      Geert Uytterhoeven authored
      [ Upstream commit 8440bb9b ]
      
      When compile-testing on arm:
      
          arch/sh/include/cpu-sh4/cpu/sh7786.h: In function ‘sh7786_mm_sel’:
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:21: warning: passing argument 1 of ‘__raw_readl’ makes pointer from integer without a cast [-Wint-conversion]
            return __raw_readl(0xFC400020) & 0x7;
      			 ^~~~~~~~~~
          In file included from include/linux/io.h:25:0,
      		     from arch/sh/include/cpu-sh4/cpu/sh7786.h:14,
      		     from drivers/pinctrl/sh-pfc/pfc-sh7786.c:15:
          arch/arm/include/asm/io.h:113:21: note: expected ‘const volatile void *’ but argument is of type ‘unsigned int’
           #define __raw_readl __raw_readl
      			 ^
          arch/arm/include/asm/io.h:114:19: note: in expansion of macro ‘__raw_readl’
           static inline u32 __raw_readl(const volatile void __iomem *addr)
      		       ^~~~~~~~~~~
      
      __raw_readl() on SuperH is a macro that casts the passed I/O address to
      the correct type, while the implementations on most other architectures
      expect to be passed the correct pointer type.
      
      Add an explicit cast to fix this.
      
      Note that this also gets rid of a sparse warning on SuperH:
      
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:16: warning: incorrect type in argument 1 (different base types)
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:16:    expected void const volatile [noderef] <asn:2>*<noident>
          arch/sh/include/cpu-sh4/cpu/sh7786.h:135:16:    got unsigned int
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      653117ea
    • Leon Romanovsky's avatar
      RDMA/hns: Fix bad endianess of port_pd variable · 75b841b1
      Leon Romanovsky authored
      [ Upstream commit 6734b297 ]
      
      port_pd is treated as le32 in declaration and read, fix assignment to be
      in le32 too. This change fixes the following compilation warnings.
      
      drivers/infiniband/hw/hns/hns_roce_ah.c:67:24: warning: incorrect type
      in assignment (different base types)
      drivers/infiniband/hw/hns/hns_roce_ah.c:67:24: expected restricted __le32 [usertype] port_pd
      drivers/infiniband/hw/hns/hns_roce_ah.c:67:24: got restricted __be32 [usertype]
      
      Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver")
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarGal Pressman <galpress@amazon.com>
      Reviewed-by: default avatarLijun Ou <ouliun@huawei.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      75b841b1
    • Chengguang Xu's avatar
      chardev: add additional check for minor range overlap · c106ddc7
      Chengguang Xu authored
      [ Upstream commit de36e16d ]
      
      Current overlap checking cannot correctly handle
      a case which is baseminor < existing baseminor &&
      baseminor + minorct > existing baseminor + minorct.
      Signed-off-by: default avatarChengguang Xu <cgxu519@gmx.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c106ddc7
    • Peter Zijlstra's avatar
      x86/uaccess: Fix up the fixup · b086be4c
      Peter Zijlstra authored
      [ Upstream commit b69656fa ]
      
      New tooling got confused about this:
      
        arch/x86/lib/memcpy_64.o: warning: objtool: .fixup+0x7: return with UACCESS enabled
      
      While the code isn't wrong, it is tedious (if at all possible) to
      figure out what function a particular chunk of .fixup belongs to.
      
      This then confuses the objtool uaccess validation. Instead of
      returning directly from the .fixup, jump back into the right function.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b086be4c
    • Peter Zijlstra's avatar
      x86/ia32: Fix ia32_restore_sigcontext() AC leak · 025c323c
      Peter Zijlstra authored
      [ Upstream commit 67a0514a ]
      
      Objtool spotted that we call native_load_gs_index() with AC set.
      Re-arrange the code to avoid that.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      025c323c
    • Peter Zijlstra's avatar
      x86/uaccess, signal: Fix AC=1 bloat · 1bd3284b
      Peter Zijlstra authored
      [ Upstream commit 88e47182 ]
      
      Occasionally GCC is less agressive with inlining and the following is
      observed:
      
        arch/x86/kernel/signal.o: warning: objtool: restore_sigcontext()+0x3cc: call to force_valid_ss.isra.5() with UACCESS enabled
        arch/x86/kernel/signal.o: warning: objtool: do_signal()+0x384: call to frame_uc_flags.isra.0() with UACCESS enabled
      
      Cure this by moving this code out of the AC=1 region, since it really
      isn't needed for the user access.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1bd3284b
    • Johannes Berg's avatar
      iwlwifi: mvm: IBSS: use BE FIFO for multicast · 3ff4740d
      Johannes Berg authored
      [ Upstream commit 192a7e1f ]
      
      Back in commit 4d339989 ("iwlwifi: mvm: support ibss in dqa mode")
      we changed queue selection for IBSS to be:
      
          if (ieee80211_is_probe_resp(fc) || ieee80211_is_auth(fc) ||
              ieee80211_is_deauth(fc))
                  return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;
          if (info->hw_queue == info->control.vif->cab_queue)
                  return info->hw_queue;
          return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;
      
      Clearly, the thought at the time must've been that mac80211 will
      select the hw_queue as the cab_queue, so that we'll return and use
      that, where we store the multicast queue for IBSS. This, however,
      isn't true because mac80211 doesn't implement powersave for IBSS
      and thus selects the normal IBSS interface AC queue (best effort).
      
      This therefore always used the probe response queue, which maps to
      the BE FIFO.
      
      In commit cfbc6c4c ("iwlwifi: mvm: support mac80211 TXQs model")
      we rethought this code, and as a consequence now started mapping the
      multicast traffic to the multicast hardware queue since we no longer
      relied on mac80211 selecting the queue, doing it ourselves instead.
      This queue is mapped to the MCAST FIFO. however, this isn't actually
      enabled/controlled by the firmware in IBSS mode because we don't
      implement powersave, and frames from this queue can never go out in
      this case.
      
      Therefore, we got queue hang reports such as
      https://bugzilla.kernel.org/show_bug.cgi?id=201707
      
      Fix this by mapping the multicast queue to the BE FIFO in IBSS so
      that all the frames can go out.
      
      Fixes: cfbc6c4c ("iwlwifi: mvm: support mac80211 TXQs model")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3ff4740d
    • Peter Zijlstra's avatar
      x86/uaccess, ftrace: Fix ftrace_likely_update() vs. SMAP · b65b70ba
      Peter Zijlstra authored
      [ Upstream commit 4a6c91fb ]
      
      For CONFIG_TRACE_BRANCH_PROFILING=y the likely/unlikely things get
      overloaded and generate callouts to this code, and thus also when
      AC=1.
      
      Make it safe.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b65b70ba
    • Lior David's avatar
      wil6210: fix return code of wmi_mgmt_tx and wmi_mgmt_tx_ext · 38e068cd
      Lior David authored
      [ Upstream commit 49122ec4 ]
      
      The functions that send management TX frame have 3 possible
      results: success and other side acknowledged receive (ACK=1),
      success and other side did not acknowledge receive(ACK=0) and
      failure to send the frame. The current implementation
      incorrectly reports the ACK=0 case as failure.
      Signed-off-by: default avatarLior David <liord@codeaurora.org>
      Signed-off-by: default avatarMaya Erez <merez@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      38e068cd
    • Peter Zijlstra's avatar
      locking/static_key: Fix false positive warnings on concurrent dec/inc · 68cccec0
      Peter Zijlstra authored
      [ Upstream commit a1247d06 ]
      
      Even though the atomic_dec_and_mutex_lock() in
      __static_key_slow_dec_cpuslocked() can never see a negative value in
      key->enabled the subsequent sanity check is re-reading key->enabled, which may
      have been set to -1 in the meantime by static_key_slow_inc_cpuslocked().
      
                      CPU  A                               CPU B
      
       __static_key_slow_dec_cpuslocked():          static_key_slow_inc_cpuslocked():
                                     # enabled = 1
         atomic_dec_and_mutex_lock()
                                     # enabled = 0
                                                    atomic_read() == 0
                                                    atomic_set(-1)
                                     # enabled = -1
         val = atomic_read()
         # Oops - val == -1!
      
      The test case is TCP's clean_acked_data_enable() / clean_acked_data_disable()
      as tickled by KTLS (net/ktls).
      Suggested-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reported-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Tested-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: ard.biesheuvel@linaro.org
      Cc: oss-drivers@netronome.com
      Cc: pbonzini@redhat.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      68cccec0
    • Wen Yang's avatar
      arm64: cpu_ops: fix a leaked reference by adding missing of_node_put · 2f5decc2
      Wen Yang authored
      [ Upstream commit 92606ec9 ]
      
      The call to of_get_next_child returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
        ./arch/arm64/kernel/cpu_ops.c:102:1-7: ERROR: missing of_node_put;
        acquired a node pointer with refcount incremented on line 69, but
        without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2f5decc2
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Prevent cursor hotspot overflow for RV overlay planes · fcff7bdf
      Nicholas Kazlauskas authored
      [ Upstream commit 6752bea8 ]
      
      [Why]
      The actual position for the cursor on the screen is essentially:
      
      x_out = x - x_plane - x_hotspot
      y_out = y - y_plane - y_hotspot
      
      The register values for cursor position and cursor hotspot need to be
      greater than zero when programmed, but we also need to subtract off
      the plane position to display the cursor at the correct position.
      
      Since we don't want x or y to be less than zero, we add the plane
      position as a positive value to x_hotspot or y_hotspot. However, what
      this doesn't take into account is that the hotspot registers are limited
      by the maximum cursor size.
      
      On DCN10 the cursor hotspot regitsers are masked to 0xFF, so they have
      a maximum value of 0-255. Values greater this will wrap, causing the
      cursor to display in the wrong position.
      
      In practice this means that for sufficiently large plane positions, the
      cursor will be drawn twice on the screen, and can cause screen flashes
      or p-state WARNS depending on what the wrapped value is.
      
      So we need a way to remove the value from x_plane and y_plane without
      exceeding the maximum cursor size.
      
      [How]
      Subtract as much as x_plane/y_plane as possible from x and y and place
      the remainder in the cursor hotspot register.
      
      The value for x_hotspot and y_hotspot can still wrap around but it
      won't happen in a case where the cursor is actually enabled.
      
      The cursor plane needs to intersect at least one pixel of the plane's
      rectangle to be enabled, so the cursor position + hotspot provided by
      userspace must always be strictly less than the maximum cursor size for
      the cursor to actually be enabled.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarSun peng Li <Sunpeng.Li@amd.com>
      Acked-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fcff7bdf
    • Yannick Fertré's avatar
      drm/panel: otm8009a: Add delay at the end of initialization · a9b2666b
      Yannick Fertré authored
      [ Upstream commit 0084c3c7 ]
      
      At the end of initialization, a delay is required by the panel. Without
      this delay, the panel could received a frame early & generate a crash of
      panel (black screen).
      Signed-off-by: default avatarYannick Fertré <yannick.fertre@st.com>
      Reviewed-by: default avatarPhilippe Cornu <philippe.cornu@st.com>
      Tested-by: default avatarPhilippe Cornu <philippe.cornu@st.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1553155445-13407-1-git-send-email-yannick.fertre@st.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      a9b2666b
    • Stanley Chu's avatar
      scsi: ufs: Avoid configuring regulator with undefined voltage range · 81ba6b9d
      Stanley Chu authored
      [ Upstream commit 3b141e8c ]
      
      For regulators used by UFS, vcc, vccq and vccq2 will have voltage range
      initialized by ufshcd_populate_vreg(), however other regulators may have
      undefined voltage range if dt-bindings have no such definition.
      
      In above undefined case, both "min_uV" and "max_uV" fields in ufs_vreg
      struct will be zero values and these values will be configured on
      regulators in different power modes.
      
      Currently this may have no harm if both "min_uV" and "max_uV" always keep
      "zero values" because regulator_set_voltage() will always bypass such
      invalid values and return "good" results.
      
      However improper values shall be fixed to avoid potential bugs.  Simply
      bypass voltage configuration if voltage range is not defined.
      Signed-off-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAvri Altman <avri.altman@wdc.com>
      Acked-by: default avatarAlim Akhtar <alim.akhtar@samsung.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      81ba6b9d
    • Stanley Chu's avatar
      scsi: ufs: Fix regulator load and icc-level configuration · d59bc35d
      Stanley Chu authored
      [ Upstream commit 0487fff7 ]
      
      Currently if a regulator has "<name>-fixed-regulator" property in device
      tree, it will skip current limit initialization.  This lead to a zero
      "max_uA" value in struct ufs_vreg.
      
      However, "regulator_set_load" operation shall be required on regulators
      which have valid current limits, otherwise a zero "max_uA" set by
      "regulator_set_load" may cause unexpected behavior when this regulator is
      enabled or set as high power mode.
      
      Similarly, in device's icc_level configuration flow, the target icc_level
      shall be updated if regulator also has valid current limit, otherwise a
      wrong icc_level will be calculated by zero "max_uA" and thus causes
      unexpected results after it is written to device.
      Signed-off-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAvri Altman <avri.altman@wdc.com>
      Acked-by: default avatarAlim Akhtar <alim.akhtar@samsung.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d59bc35d
    • Ping-Ke Shih's avatar
      rtlwifi: fix potential NULL pointer dereference · a7704ab6
      Ping-Ke Shih authored
      [ Upstream commit 60209d48 ]
      
      In case dev_alloc_skb fails, the fix safely returns to avoid
      potential NULL pointer dereference.
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a7704ab6
    • Geert Uytterhoeven's avatar
      spi: Add missing error handling for CS GPIOs · 91b6a564
      Geert Uytterhoeven authored
      [ Upstream commit 1723fdec ]
      
      While devm_gpiod_get_index_optional() returns NULL if the GPIO is not
      present (i.e. -ENOENT), it may still return other error codes, like
      -EPROBE_DEFER.  Currently these are not handled, leading to
      unrecoverable failures later in case of probe deferral:
      
          gpiod_set_consumer_name: invalid GPIO (errorpointer)
          gpiod_direction_output: invalid GPIO (errorpointer)
          gpiod_set_value_cansleep: invalid GPIO (errorpointer)
          gpiod_set_value_cansleep: invalid GPIO (errorpointer)
          gpiod_set_value_cansleep: invalid GPIO (errorpointer)
      
      Detect and propagate errors to fix this.
      
      Fixes: f3186dd8 ("spi: Optionally use GPIO descriptors for CS GPIOs")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      91b6a564
    • Alexandre Belloni's avatar
      rtc: xgene: fix possible race condition · 3c328af8
      Alexandre Belloni authored
      [ Upstream commit a652e00e ]
      
      The IRQ is requested before the struct rtc is allocated and registered, but
      this struct is used in the IRQ handler. This may lead to a NULL pointer
      dereference.
      
      Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
      struct before requesting the IRQ.
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3c328af8
    • Piotr Figiel's avatar
      brcmfmac: fix Oops when bringing up interface during USB disconnect · 335e7c03
      Piotr Figiel authored
      [ Upstream commit 24d413a3 ]
      
      Fix a race which leads to an Oops with NULL pointer dereference.  The
      dereference is in brcmf_config_dongle() when cfg_to_ndev() attempts to get
      net_device structure of interface with index 0 via if2bss mapping. This
      shouldn't fail because of check for bus being ready in brcmf_netdev_open(),
      but it's not synchronised with USB disconnect and there is a race: after
      the check the bus can be marked down and the mapping for interface 0 may be
      gone.
      
      Solve this by modifying disconnect handling so that the removal of mapping
      of ifidx to brcmf_if structure happens after netdev removal (which is
      synchronous with brcmf_netdev_open() thanks to rtln being locked in
      devinet_ioctl()). This assures brcmf_netdev_open() returns before the
      mapping is removed during disconnect.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      pgd = bcae2612
      [00000008] *pgd=8be73831
      Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      Modules linked in: brcmfmac brcmutil nf_log_ipv4 nf_log_common xt_LOG xt_limit
      iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6
      nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis
      u_ether usb_serial_simple usbserial cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc
      usbmisc_imx ulpi 8250_exar 8250_pci 8250 8250_base libcomposite configfs
      udc_core [last unloaded: brcmutil]
      CPU: 2 PID: 24478 Comm: ifconfig Not tainted 4.19.23-00078-ga62866d-dirty #115
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      PC is at brcmf_cfg80211_up+0x94/0x29c [brcmfmac]
      LR is at brcmf_cfg80211_up+0x8c/0x29c [brcmfmac]
      pc : [<7f26a91c>]    lr : [<7f26a914>]    psr: a0070013
      sp : eca99d28  ip : 00000000  fp : ee9c6c00
      r10: 00000036  r9 : 00000000  r8 : ece4002c
      r7 : edb5b800  r6 : 00000000  r5 : 80f08448  r4 : edb5b968
      r3 : ffffffff  r2 : 00000000  r1 : 00000002  r0 : 00000000
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 7ca0c04a  DAC: 00000051
      Process ifconfig (pid: 24478, stack limit = 0xd9e85a0e)
      Stack: (0xeca99d28 to 0xeca9a000)
      9d20:                   00000000 80f873b0 0000000d 80f08448 eca99d68 50d45f32
      9d40: 7f27de94 ece40000 80f08448 80f08448 7f27de94 ece4002c 00000000 00000036
      9d60: ee9c6c00 7f27262c 00001002 50d45f32 ece40000 00000000 80f08448 80772008
      9d80: 00000001 00001043 00001002 ece40000 00000000 50d45f32 ece40000 00000001
      9da0: 80f08448 00001043 00001002 807723d0 00000000 50d45f32 80f08448 eca99e58
      9dc0: 80f87113 50d45f32 80f08448 ece40000 ece40138 00001002 80f08448 00000000
      9de0: 00000000 80772434 edbd5380 eca99e58 edbd5380 80f08448 ee9c6c0c 80805f70
      9e00: 00000000 ede08e00 00008914 ece40000 00000014 ee9c6c0c 600c0013 00001043
      9e20: 0208a8c0 ffffffff 00000000 50d45f32 eca98000 80f08448 7ee9fc38 00008914
      9e40: 80f68e40 00000051 eca98000 00000036 00000003 80808b9c 6e616c77 00000030
      9e60: 00000000 00000000 00001043 0208a8c0 ffffffff 00000000 80f08448 00000000
      9e80: 00000000 816d8b20 600c0013 00000001 ede09320 801763d4 00000000 50d45f32
      9ea0: eca98000 80f08448 7ee9fc38 50d45f32 00008914 80f08448 7ee9fc38 80f68e40
      9ec0: ed531540 8074721c 00000800 00000001 00000000 6e616c77 00000030 00000000
      9ee0: 00000000 00001002 0208a8c0 ffffffff 00000000 50d45f32 80f08448 7ee9fc38
      9f00: ed531560 ec8fc900 80285a6c 80285138 edb910c0 00000000 ecd91008 ede08e00
      9f20: 80f08448 00000000 00000000 816d8b20 600c0013 00000001 ede09320 801763d4
      9f40: 00000000 50d45f32 00021000 edb91118 edb910c0 80f08448 01b29000 edb91118
      9f60: eca99f7c 50d45f32 00021000 ec8fc900 00000003 ec8fc900 00008914 7ee9fc38
      9f80: eca98000 00000036 00000003 80285a6c 00086364 7ee9fe1c 000000c3 00000036
      9fa0: 801011c4 80101000 00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
      9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
      9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc 600c0010 00000003 00000000 00000000
      [<7f26a91c>] (brcmf_cfg80211_up [brcmfmac]) from [<7f27262c>] (brcmf_netdev_open+0x74/0xe8 [brcmfmac])
      [<7f27262c>] (brcmf_netdev_open [brcmfmac]) from [<80772008>] (__dev_open+0xcc/0x150)
      [<80772008>] (__dev_open) from [<807723d0>] (__dev_change_flags+0x168/0x1b4)
      [<807723d0>] (__dev_change_flags) from [<80772434>] (dev_change_flags+0x18/0x48)
      [<80772434>] (dev_change_flags) from [<80805f70>] (devinet_ioctl+0x67c/0x79c)
      [<80805f70>] (devinet_ioctl) from [<80808b9c>] (inet_ioctl+0x210/0x3d4)
      [<80808b9c>] (inet_ioctl) from [<8074721c>] (sock_ioctl+0x350/0x524)
      [<8074721c>] (sock_ioctl) from [<80285138>] (do_vfs_ioctl+0xb0/0x9b0)
      [<80285138>] (do_vfs_ioctl) from [<80285a6c>] (ksys_ioctl+0x34/0x5c)
      [<80285a6c>] (ksys_ioctl) from [<80101000>] (ret_fast_syscall+0x0/0x28)
      Exception stack(0xeca99fa8 to 0xeca99ff0)
      9fa0:                   00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
      9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
      9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc
      Code: e5970328 eb002021 e1a02006 e3a01002 (e5909008)
      ---[ end trace 5cbac2333f3ac5df ]---
      Signed-off-by: default avatarPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      335e7c03
    • Piotr Figiel's avatar
      brcmfmac: fix race during disconnect when USB completion is in progress · 9429cd8c
      Piotr Figiel authored
      [ Upstream commit db3b9e2e ]
      
      It was observed that rarely during USB disconnect happening shortly after
      connect (before full initialization completes) usb_hub_wq would wait
      forever for the dev_init_lock to be unlocked. dev_init_lock would remain
      locked though because of infinite wait during usb_kill_urb:
      
      [ 2730.656472] kworker/0:2     D    0   260      2 0x00000000
      [ 2730.660700] Workqueue: events request_firmware_work_func
      [ 2730.664807] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
      [ 2730.670587] [<809dd164>] (schedule) from [<8069af44>] (usb_kill_urb+0xdc/0x114)
      [ 2730.676815] [<8069af44>] (usb_kill_urb) from [<7f258b50>] (brcmf_usb_free_q+0x34/0xa8 [brcmfmac])
      [ 2730.684833] [<7f258b50>] (brcmf_usb_free_q [brcmfmac]) from [<7f2517d4>] (brcmf_detach+0xa0/0xb8 [brcmfmac])
      [ 2730.693557] [<7f2517d4>] (brcmf_detach [brcmfmac]) from [<7f251a34>] (brcmf_attach+0xac/0x3d8 [brcmfmac])
      [ 2730.702094] [<7f251a34>] (brcmf_attach [brcmfmac]) from [<7f2587ac>] (brcmf_usb_probe_phase2+0x468/0x4a0 [brcmfmac])
      [ 2730.711601] [<7f2587ac>] (brcmf_usb_probe_phase2 [brcmfmac]) from [<7f252888>] (brcmf_fw_request_done+0x194/0x220 [brcmfmac])
      [ 2730.721795] [<7f252888>] (brcmf_fw_request_done [brcmfmac]) from [<805748e4>] (request_firmware_work_func+0x4c/0x88)
      [ 2730.731125] [<805748e4>] (request_firmware_work_func) from [<80141474>] (process_one_work+0x228/0x808)
      [ 2730.739223] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [ 2730.746105] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [ 2730.752227] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      
      [ 2733.099695] kworker/0:3     D    0  1065      2 0x00000000
      [ 2733.103926] Workqueue: usb_hub_wq hub_event
      [ 2733.106914] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
      [ 2733.112693] [<809dd164>] (schedule) from [<809e2a8c>] (schedule_timeout+0x214/0x3e4)
      [ 2733.119621] [<809e2a8c>] (schedule_timeout) from [<809dde2c>] (wait_for_common+0xc4/0x1c0)
      [ 2733.126810] [<809dde2c>] (wait_for_common) from [<7f258d00>] (brcmf_usb_disconnect+0x1c/0x4c [brcmfmac])
      [ 2733.135206] [<7f258d00>] (brcmf_usb_disconnect [brcmfmac]) from [<8069e0c8>] (usb_unbind_interface+0x5c/0x1e4)
      [ 2733.143943] [<8069e0c8>] (usb_unbind_interface) from [<8056d3e8>] (device_release_driver_internal+0x164/0x1fc)
      [ 2733.152769] [<8056d3e8>] (device_release_driver_internal) from [<8056c078>] (bus_remove_device+0xd0/0xfc)
      [ 2733.161138] [<8056c078>] (bus_remove_device) from [<8056977c>] (device_del+0x11c/0x310)
      [ 2733.167939] [<8056977c>] (device_del) from [<8069cba8>] (usb_disable_device+0xa0/0x1cc)
      [ 2733.174743] [<8069cba8>] (usb_disable_device) from [<8069507c>] (usb_disconnect+0x74/0x1dc)
      [ 2733.181823] [<8069507c>] (usb_disconnect) from [<80695e88>] (hub_event+0x478/0xf88)
      [ 2733.188278] [<80695e88>] (hub_event) from [<80141474>] (process_one_work+0x228/0x808)
      [ 2733.194905] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [ 2733.201724] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [ 2733.207913] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      
      It was traced down to a case where usb_kill_urb would be called on an URB
      structure containing more or less random data, including large number in
      its use_count. During the debugging it appeared that in brcmf_usb_free_q()
      the traversal over URBs' lists is not synchronized with operations on those
      lists in brcmf_usb_rx_complete() leading to handling
      brcmf_usbdev_info structure (holding lists' head) as lists' element and in
      result causing above problem.
      
      Fix it by walking through all URBs during brcmf_cancel_all_urbs using the
      arrays of requests instead of linked lists.
      Signed-off-by: default avatarPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9429cd8c
    • Piotr Figiel's avatar
      brcmfmac: fix WARNING during USB disconnect in case of unempty psq · d3e2c7b5
      Piotr Figiel authored
      [ Upstream commit c80d26e8 ]
      
      brcmu_pkt_buf_free_skb emits WARNING when attempting to free a sk_buff
      which is part of any queue. After USB disconnect this may have happened
      when brcmf_fws_hanger_cleanup() is called as per-interface psq was never
      cleaned when removing the interface.
      Change brcmf_fws_macdesc_cleanup() in a way that it removes the
      corresponding packets from hanger table (to avoid double-free when
      brcmf_fws_hanger_cleanup() is called) and add a call to clean-up the
      interface specific packet queue.
      
      Below is a WARNING during USB disconnect with Raspberry Pi WiFi dongle
      running in AP mode. This was reproducible when the interface was
      transmitting during the disconnect and is fixed with this commit.
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1171 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x3c/0x40
      Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc ulpi usbmisc_imx 8250_exar 8250_pci 8250 8250_base libcomposite configfs udc_core
      CPU: 0 PID: 1171 Comm: kworker/0:0 Not tainted 4.19.23-00075-gde33ed8 #99
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: usb_hub_wq hub_event
      [<8010ff84>] (unwind_backtrace) from [<8010bb64>] (show_stack+0x10/0x14)
      [<8010bb64>] (show_stack) from [<80840278>] (dump_stack+0x88/0x9c)
      [<80840278>] (dump_stack) from [<8011f5ec>] (__warn+0xfc/0x114)
      [<8011f5ec>] (__warn) from [<8011f71c>] (warn_slowpath_null+0x40/0x48)
      [<8011f71c>] (warn_slowpath_null) from [<805a476c>] (brcmu_pkt_buf_free_skb+0x3c/0x40)
      [<805a476c>] (brcmu_pkt_buf_free_skb) from [<805bb6c4>] (brcmf_fws_cleanup+0x1e4/0x22c)
      [<805bb6c4>] (brcmf_fws_cleanup) from [<805bc854>] (brcmf_fws_del_interface+0x58/0x68)
      [<805bc854>] (brcmf_fws_del_interface) from [<805b66ac>] (brcmf_remove_interface+0x40/0x150)
      [<805b66ac>] (brcmf_remove_interface) from [<805b6870>] (brcmf_detach+0x6c/0xb0)
      [<805b6870>] (brcmf_detach) from [<805bdbb8>] (brcmf_usb_disconnect+0x30/0x4c)
      [<805bdbb8>] (brcmf_usb_disconnect) from [<805e5d64>] (usb_unbind_interface+0x5c/0x1e0)
      [<805e5d64>] (usb_unbind_interface) from [<804aab10>] (device_release_driver_internal+0x154/0x1ec)
      [<804aab10>] (device_release_driver_internal) from [<804a97f4>] (bus_remove_device+0xcc/0xf8)
      [<804a97f4>] (bus_remove_device) from [<804a6fc0>] (device_del+0x118/0x308)
      [<804a6fc0>] (device_del) from [<805e488c>] (usb_disable_device+0xa0/0x1c8)
      [<805e488c>] (usb_disable_device) from [<805dcf98>] (usb_disconnect+0x70/0x1d8)
      [<805dcf98>] (usb_disconnect) from [<805ddd84>] (hub_event+0x464/0xf50)
      [<805ddd84>] (hub_event) from [<80135a70>] (process_one_work+0x138/0x3f8)
      [<80135a70>] (process_one_work) from [<80135d5c>] (worker_thread+0x2c/0x554)
      [<80135d5c>] (worker_thread) from [<8013b1a0>] (kthread+0x124/0x154)
      [<8013b1a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
      Exception stack(0xecf8dfb0 to 0xecf8dff8)
      dfa0:                                     00000000 00000000 00000000 00000000
      dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
      ---[ end trace 38d234018e9e2a90 ]---
      ------------[ cut here ]------------
      Signed-off-by: default avatarPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d3e2c7b5
    • Piotr Figiel's avatar
      brcmfmac: convert dev_init_lock mutex to completion · 100ba77f
      Piotr Figiel authored
      [ Upstream commit a9fd0953 ]
      
      Leaving dev_init_lock mutex locked in probe causes BUG and a WARNING when
      kernel is compiled with CONFIG_PROVE_LOCKING. Convert mutex to completion
      which silences those warnings and improves code readability.
      
      Fix below errors when connecting the USB WiFi dongle:
      
      brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43143 for chip BCM43143/2
      BUG: workqueue leaked lock or atomic: kworker/0:2/0x00000000/434
           last function: hub_event
      1 lock held by kworker/0:2/434:
       #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: usb_hub_wq hub_event
      [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
      [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
      [<809c4324>] (dump_stack) from [<8014195c>] (process_one_work+0x710/0x808)
      [<8014195c>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xed1d9fb0 to 0xed1d9ff8)
      9fa0:                                     00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.19.23-00084-g454a789-dirty #123 Not tainted
      ------------------------------------------------------
      kworker/0:2/434 is trying to acquire lock:
      e29cf799 ((wq_completion)"events"){+.+.}, at: process_one_work+0x174/0x808
      
      but task is already holding lock:
      18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (&devinfo->dev_init_lock){+.+.}:
             mutex_lock_nested+0x1c/0x24
             brcmf_usb_probe+0x78/0x550 [brcmfmac]
             usb_probe_interface+0xc0/0x1bc
             really_probe+0x228/0x2c0
             __driver_attach+0xe4/0xe8
             bus_for_each_dev+0x68/0xb4
             bus_add_driver+0x19c/0x214
             driver_register+0x78/0x110
             usb_register_driver+0x84/0x148
             process_one_work+0x228/0x808
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      -> #1 (brcmf_driver_work){+.+.}:
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      -> #0 ((wq_completion)"events"){+.+.}:
             process_one_work+0x1b8/0x808
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      other info that might help us debug this:
      
      Chain exists of:
        (wq_completion)"events" --> brcmf_driver_work --> &devinfo->dev_init_lock
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&devinfo->dev_init_lock);
                                     lock(brcmf_driver_work);
                                     lock(&devinfo->dev_init_lock);
        lock((wq_completion)"events");
      
       *** DEADLOCK ***
      
      1 lock held by kworker/0:2/434:
       #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      
      stack backtrace:
      CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: events request_firmware_work_func
      [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
      [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
      [<809c4324>] (dump_stack) from [<80172838>] (print_circular_bug+0x210/0x330)
      [<80172838>] (print_circular_bug) from [<80175940>] (__lock_acquire+0x160c/0x1a30)
      [<80175940>] (__lock_acquire) from [<8017671c>] (lock_acquire+0xe0/0x268)
      [<8017671c>] (lock_acquire) from [<80141404>] (process_one_work+0x1b8/0x808)
      [<80141404>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xed1d9fb0 to 0xed1d9ff8)
      9fa0:                                     00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      Signed-off-by: default avatarPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      100ba77f
    • Arnd Bergmann's avatar
      b43: shut up clang -Wuninitialized variable warning · e96af6fa
      Arnd Bergmann authored
      [ Upstream commit d825db34 ]
      
      Clang warns about what is clearly a case of passing an uninitalized
      variable into a static function:
      
      drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
            [-Werror,-Wuninitialized]
                      lpphy_papd_cal(dev, gains, 0, 1, 30);
                                          ^~~~~
      drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
              struct lpphy_tx_gains gains, oldgains;
              ^
      1 error generated.
      
      However, this function is empty, and its arguments are never evaluated,
      so gcc in contrast does not warn here. Both compilers behave in a
      reasonable way as far as I can tell, so we should change the code
      to avoid the warning everywhere.
      
      We could just eliminate the lpphy_papd_cal() function entirely,
      given that it has had the TODO comment in it for 10 years now
      and is rather unlikely to ever get done. I'm doing a simpler
      change here, and just pass the 'oldgains' variable in that has
      been initialized, based on the guess that this is what was
      originally meant.
      
      Fixes: 2c0d6100 ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e96af6fa
    • Kangjie Lu's avatar
      brcmfmac: fix missing checks for kmemdup · 135870bd
      Kangjie Lu authored
      [ Upstream commit 46953f97 ]
      
      In case kmemdup fails, the fix sets conn_info->req_ie_len and
      conn_info->resp_ie_len to zero to avoid buffer overflows.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Acked-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      135870bd
    • YueHaibing's avatar
      mwifiex: Fix mem leak in mwifiex_tm_cmd · 1d8e898a
      YueHaibing authored
      [ Upstream commit 003b686a ]
      
      'hostcmd' is alloced by kzalloc, should be freed before
      leaving from the error handling cases, otherwise it will
      cause mem leak.
      
      Fixes: 3935ccc1 ("mwifiex: add cfg80211 testmode support")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d8e898a
    • Kangjie Lu's avatar
      rtlwifi: fix a potential NULL pointer dereference · 8dc032a2
      Kangjie Lu authored
      [ Upstream commit 76597628 ]
      
      In case alloc_workqueue fails, the fix reports the error and
      returns to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8dc032a2
    • Daniel T. Lee's avatar
      selftests/bpf: ksym_search won't check symbols exists · f382ab1a
      Daniel T. Lee authored
      [ Upstream commit 0979ff79 ]
      
      Currently, ksym_search located at trace_helpers won't check symbols are
      existing or not.
      
      In ksym_search, when symbol is not found, it will return &syms[0](_stext).
      But when the kernel symbols are not loaded, it will return NULL, which is
      not a desired action.
      
      This commit will add verification logic whether symbols are loaded prior
      to the symbol search.
      Signed-off-by: default avatarDaniel T. Lee <danieltimlee@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f382ab1a
    • Jian Shen's avatar
      net: hns3: add protect when handling mac addr list · 3f52cbfe
      Jian Shen authored
      [ Upstream commit 389775a6 ]
      
      It used netdev->uc and netdev->mc list in function
      hns3_recover_hw_addr() and hns3_remove_hw_addr().
      We should add protect for them.
      
      Fixes: f05e2109 ("net: hns3: Clear mac vlan table entries when unload driver or function reset")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3f52cbfe