1. 31 May, 2019 40 commits
    • 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
    • Huazhong Tan's avatar
      net: hns3: check resetting status in hns3_get_stats() · 9cc0b2b5
      Huazhong Tan authored
      [ Upstream commit c4e401e5 ]
      
      hns3_get_stats() should check the resetting status firstly,
      since the device will be reinitialized when resetting. If the
      reset has not completed, the hns3_get_stats() may access
      invalid memory.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9cc0b2b5
    • Justin Chen's avatar
      iio: adc: ti-ads7950: Fix improper use of mlock · 8f52f331
      Justin Chen authored
      [ Upstream commit abbde279 ]
      
      Indio->mlock is used for protecting the different iio device modes.
      It is currently not being used in this way. Replace the lock with
      an internal lock specifically used for protecting the SPI transfer
      buffer.
      Signed-off-by: default avatarJustin Chen <justinpopo6@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8f52f331
    • Nathan Chancellor's avatar
      iio: common: ssp_sensors: Initialize calculated_time in ssp_common_process_data · 1b98d51d
      Nathan Chancellor authored
      [ Upstream commit 6f9ca1d3 ]
      
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/iio/common/ssp_sensors/ssp_iio.c:95:6: warning: variable
      'calculated_time' is used uninitialized whenever 'if' condition is false
      [-Wsometimes-uninitialized]
      
      While it isn't wrong, this will never be a problem because
      iio_push_to_buffers_with_timestamp only uses calculated_time
      on the same condition that it is assigned (when scan_timestamp
      is not zero). While iio_push_to_buffers_with_timestamp is marked
      as inline, Clang does inlining in the optimization stage, which
      happens after the semantic analysis phase (plus inline is merely
      a hint to the compiler).
      
      Fix this by just zero initializing calculated_time.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/394Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1b98d51d
    • Kangjie Lu's avatar
      iio: hmc5843: fix potential NULL pointer dereferences · f899898e
      Kangjie Lu authored
      [ Upstream commit 536cc27d ]
      
      devm_regmap_init_i2c may fail and return NULL. The fix returns
      the error when it fails.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f899898e
    • Lars-Peter Clausen's avatar
      iio: ad_sigma_delta: Properly handle SPI bus locking vs CS assertion · 5e526a75
      Lars-Peter Clausen authored
      [ Upstream commit df1d80ae ]
      
      For devices from the SigmaDelta family we need to keep CS low when doing a
      conversion, since the device will use the MISO line as a interrupt to
      indicate that the conversion is complete.
      
      This is why the driver locks the SPI bus and when the SPI bus is locked
      keeps as long as a conversion is going on. The current implementation gets
      one small detail wrong though. CS is only de-asserted after the SPI bus is
      unlocked. This means it is possible for a different SPI device on the same
      bus to send a message which would be wrongfully be addressed to the
      SigmaDelta device as well. Make sure that the last SPI transfer that is
      done while holding the SPI bus lock de-asserts the CS signal.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarAlexandru Ardelean <Alexandru.Ardelean@analog.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5e526a75
    • Wen Yang's avatar
      drm/pl111: fix possible object reference leak · eaf6e69d
      Wen Yang authored
      [ Upstream commit bc29d3a6 ]
      
      The call to of_find_matching_node_and_match returns a node pointer with
      refcount incremented thus it must be explicitly decremented after the
      last usage.
      
      Detected by coccinelle with the following warnings:
      drivers/gpu/drm/pl111/pl111_versatile.c:333:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
      drivers/gpu/drm/pl111/pl111_versatile.c:340:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
      drivers/gpu/drm/pl111/pl111_versatile.c:346:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
      drivers/gpu/drm/pl111/pl111_versatile.c:354:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
      drivers/gpu/drm/pl111/pl111_versatile.c:395:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
      drivers/gpu/drm/pl111/pl111_versatile.c:402:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Eric Anholt <eric@anholt.net> (supporter:DRM DRIVER FOR ARM PL111 CLCD)
      Cc: David Airlie <airlied@linux.ie> (maintainer:DRM DRIVERS)
      Cc: Daniel Vetter <daniel@ffwll.ch> (maintainer:DRM DRIVERS)
      Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
      Cc: linux-kernel@vger.kernel.org (open list)
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Link: https://patchwork.freedesktop.org/patch/msgid/1554307455-40361-6-git-send-email-wen.yang99@zte.com.cnSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      eaf6e69d
    • Ranjani Sridharan's avatar
      ASoC: core: remove link components before cleaning up card resources · 34e3da15
      Ranjani Sridharan authored
      [ Upstream commit f96fb7d1 ]
      
      When the card is registered by the machine driver,
      dai link components are probed after the snd_card is
      created. This is done in snd_soc_bind_card() which calls
      snd_soc_instantiate_card() to first create the snd_card
      and then probes the link components by calling
      soc_probe_link_components(). The snd_card is used by the
      component driver to add the kcontrols associated
      with dapm widgets to the card.
      
      When the machine driver is unregistered, the snd_card
      is freed when the card resources are cleaned up.
      But the snd_card needs to be valid while unloading the
      topology dapm widgets in order to remove the kcontrols
      from the card.
      
      Since, unloading topology is done when the component
      driver is removed, the link components should be removed
      in snd_soc_unbind_card(). This will ensure that the kcontrols
      are removed before the card resources are cleaned up and
      the snd_card itself is freed.
      Signed-off-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      34e3da15
    • Charles Keepax's avatar
      regulator: core: Avoid potential deadlock on regulator_unregister · 18127d11
      Charles Keepax authored
      [ Upstream commit 06377301 ]
      
      Lockdep reports the following issue on my setup:
      
      Possible unsafe locking scenario:
      
      CPU0                    CPU1
      ----                    ----
      lock((work_completion)(&(&rdev->disable_work)->work));
                              lock(regulator_list_mutex);
                              lock((work_completion)(&(&rdev->disable_work)->work));
      lock(regulator_list_mutex);
      
      The problem is that regulator_unregister takes the
      regulator_list_mutex and then calls flush_work on disable_work. But
      regulator_disable_work calls regulator_lock_dependent which will
      also take the regulator_list_mutex. Resulting in a deadlock if the
      flush_work call actually needs to flush the work.
      
      Fix this issue by moving the flush_work outside of the
      regulator_list_mutex. The list mutex is not used to guard the point at
      which the delayed work is queued, so its use adds no additional safety.
      
      Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Reviewed-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      18127d11
    • Andrey Smirnov's avatar
      spi: Don't call spi_get_gpio_descs() before device name is set · cf0e0ec1
      Andrey Smirnov authored
      [ Upstream commit 0a919ae4 ]
      
      Move code calling spi_get_gpio_descs() to happen after ctlr->dev's
      name is set in order to have proper GPIO consumer names.
      
      Before:
      
      cat /sys/kernel/debug/gpio
      gpiochip0: GPIOs 0-31, parent: platform/40049000.gpio, vf610-gpio:
       gpio-6   (                    |regulator-usb0-vbus ) out lo
      
      gpiochip1: GPIOs 32-63, parent: platform/4004a000.gpio, vf610-gpio:
       gpio-36  (                    |scl                 ) in  hi
       gpio-37  (                    |sda                 ) in  hi
       gpio-40  (                    |(null) CS1          ) out lo
       gpio-41  (                    |(null) CS0          ) out lo ACTIVE LOW
       gpio-42  (                    |miso                ) in  hi
       gpio-43  (                    |mosi                ) in  lo
       gpio-44  (                    |sck                 ) out lo
      
      After:
      
      cat /sys/kernel/debug/gpio
      gpiochip0: GPIOs 0-31, parent: platform/40049000.gpio, vf610-gpio:
       gpio-6   (                    |regulator-usb0-vbus ) out lo
      
      gpiochip1: GPIOs 32-63, parent: platform/4004a000.gpio, vf610-gpio:
       gpio-36  (                    |scl                 ) in  hi
       gpio-37  (                    |sda                 ) in  hi
       gpio-40  (                    |spi0 CS1            ) out lo
       gpio-41  (                    |spi0 CS0            ) out lo ACTIVE LOW
       gpio-42  (                    |miso                ) in  hi
       gpio-43  (                    |mosi                ) in  lo
       gpio-44  (                    |sck                 ) out lo
      Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: linux-spi@vger.kernel.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>
      cf0e0ec1
    • Kees Cook's avatar
      x86/build: Keep local relocations with ld.lld · 5fa810fc
      Kees Cook authored
      [ Upstream commit 7c21383f ]
      
      The LLVM linker (ld.lld) defaults to removing local relocations, which
      causes KASLR boot failures. ld.bfd and ld.gold already handle this
      correctly. This adds the explicit instruction "--discard-none" during
      the link phase. There is no change in output for ld.bfd and ld.gold,
      but ld.lld now produces an image with all the needed relocations.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: clang-built-linux@googlegroups.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190404214027.GA7324@beast
      Link: https://github.com/ClangBuiltLinux/linux/issues/404Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5fa810fc
    • Alexei Starovoitov's avatar
      samples/bpf: fix build with new clang · 10a8c316
      Alexei Starovoitov authored
      [ Upstream commit 636e78b1 ]
      
      clang started to error on invalid asm clobber usage in x86 headers
      and many bpf program samples failed to build with the message:
      
        CLANG-bpf  /data/users/ast/bpf-next/samples/bpf/xdp_redirect_kern.o
      In file included from /data/users/ast/bpf-next/samples/bpf/xdp_redirect_kern.c:14:
      In file included from ../include/linux/in.h:23:
      In file included from ../include/uapi/linux/in.h:24:
      In file included from ../include/linux/socket.h:8:
      In file included from ../include/linux/uio.h:14:
      In file included from ../include/crypto/hash.h:16:
      In file included from ../include/linux/crypto.h:26:
      In file included from ../include/linux/uaccess.h:5:
      In file included from ../include/linux/sched.h:15:
      In file included from ../include/linux/sem.h:5:
      In file included from ../include/uapi/linux/sem.h:5:
      In file included from ../include/linux/ipc.h:9:
      In file included from ../include/linux/refcount.h:72:
      ../arch/x86/include/asm/refcount.h:72:36: error: asm-specifier for input or output variable conflicts with asm clobber list
                                               r->refs.counter, e, "er", i, "cx");
                                                                            ^
      ../arch/x86/include/asm/refcount.h:86:27: error: asm-specifier for input or output variable conflicts with asm clobber list
                                               r->refs.counter, e, "cx");
                                                                   ^
      2 errors generated.
      
      Override volatile() to workaround the problem.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      10a8c316
    • Oded Gabbay's avatar
      habanalabs: all FD must be closed before removing device · f1d84fe4
      Oded Gabbay authored
      [ Upstream commit caa3c8e5 ]
      
      This patch fixes a bug in the implementation of the function that removes
      the device.
      
      The bug can happen when the device is removed but not the driver itself
      (e.g. remove by the OS due to PCI freeze in Power architecture).
      
      In that case, there maybe open users that are calling IOCTLs while the
      device is removed. This is a possible race condition that the driver must
      handle. Otherwise, a kernel panic may occur.
      
      This race is prevented in the hard-reset flow, because the driver makes
      sure the users are closed before continuing with the hard-reset. This
      race can not occur when the driver itself is removed because the OS makes
      sure all the file descriptors are closed.
      
      The fix is to make sure the open users close their file descriptors and if
      they don't (after a certain amount of time), the driver sends them a
      SIGKILL, because the remove of the device can't be stopped.
      
      The patch re-uses the same code that is called from the hard-reset flow.
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f1d84fe4
    • Oded Gabbay's avatar
      habanalabs: prevent device PTE read/write during hard-reset · 7de03fc0
      Oded Gabbay authored
      [ Upstream commit 9f201aba ]
      
      During hard-reset, contexts are closed as part of the tear-down process.
      After a context is closed, the driver cleans up the page tables of that
      context in the device's DRAM. This action is both dangerous and
      unnecessary.
      
      It is unnecessary, because the device is going through a hard-reset, which
      means the device's DRAM contents are no longer valid and the device's MMU
      is being reset.
      
      It is dangerous, because if the hard-reset came as a result of a PCI
      freeze, this action may cause the entire host machine to hang.
      
      Therefore, prevent all device PTE updates when a hard-reset operation is
      pending.
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7de03fc0
    • David Kozub's avatar
      block: sed-opal: fix IOC_OPAL_ENABLE_DISABLE_MBR · 7c1c65c5
      David Kozub authored
      [ Upstream commit 78bf4735 ]
      
      The implementation of IOC_OPAL_ENABLE_DISABLE_MBR handled the value
      opal_mbr_data.enable_disable incorrectly: enable_disable is expected
      to be one of OPAL_MBR_ENABLE(0) or OPAL_MBR_DISABLE(1). enable_disable
      was passed directly to set_mbr_done and set_mbr_enable_disable where
      is was interpreted as either OPAL_TRUE(1) or OPAL_FALSE(0). The end
      result was that calling IOC_OPAL_ENABLE_DISABLE_MBR with OPAL_MBR_ENABLE
      actually disabled the shadow MBR and vice versa.
      
      This patch adds correct conversion from OPAL_MBR_DISABLE/ENABLE to
      OPAL_FALSE/TRUE. The change affects existing programs using
      IOC_OPAL_ENABLE_DISABLE_MBR but this is typically used only once when
      setting up an Opal drive.
      Acked-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarScott Bauer <sbauer@plzdonthack.me>
      Signed-off-by: default avatarDavid Kozub <zub@linux.fjfi.cvut.cz>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7c1c65c5
    • Wen Yang's avatar
      cpufreq: ap806: fix possible object reference leak · 91efbd9d
      Wen Yang authored
      [ Upstream commit b623fa32 ]
      
      The call to of_find_compatible_node returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/cpufreq/armada-8k-cpufreq.c:187:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 130, but without a corresponding object release within this function.
      ./drivers/cpufreq/armada-8k-cpufreq.c:191:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 130, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@bootlin.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      91efbd9d
    • Wen Yang's avatar
      cpufreq: imx6q: fix possible object reference leak · 9e2a8a94
      Wen Yang authored
      [ Upstream commit ddb64c5d ]
      
      The call to of_node_get returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/cpufreq/imx6q-cpufreq.c:391:4-10: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 348, but without a corresponding object release within this function.
      ./drivers/cpufreq/imx6q-cpufreq.c:395:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 348, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: NXP Linux Team <linux-imx@nxp.com>
      Cc: linux-pm@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9e2a8a94
    • Wen Yang's avatar
      cpufreq: kirkwood: fix possible object reference leak · 6446fdec
      Wen Yang authored
      [ Upstream commit 7c468966 ]
      
      The call to of_get_child_by_name returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/cpufreq/kirkwood-cpufreq.c:127:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 118, but without a corresponding object release within this function.
      ./drivers/cpufreq/kirkwood-cpufreq.c:133:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 118, but without a corresponding object release within this function.
      
      and also do some cleanup:
      - of_node_put(np);
      - np = NULL;
      ...
      of_node_put(np);
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: linux-pm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6446fdec
    • Wen Yang's avatar
      cpufreq: pmac32: fix possible object reference leak · e84c252b
      Wen Yang authored
      [ Upstream commit 8d10dc28 ]
      
      The call to of_find_node_by_name returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 552, but without a corresponding object release within this function.
      ./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 552, but without a corresponding object release within this function.
      ./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 587, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linux-pm@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e84c252b
    • Wen Yang's avatar
      cpufreq/pasemi: fix possible object reference leak · 37792ced
      Wen Yang authored
      [ Upstream commit a9acc26b ]
      
      The call to of_get_cpu_node returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/cpufreq/pasemi-cpufreq.c:212:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function.
      ./drivers/cpufreq/pasemi-cpufreq.c:220:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      37792ced
    • Wen Yang's avatar
      cpufreq: ppc_cbe: fix possible object reference leak · d1f82d91
      Wen Yang authored
      [ Upstream commit 23329803 ]
      
      The call to of_get_cpu_node returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/cpufreq/ppc_cbe_cpufreq.c:89:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 76, but without a corresponding object release within this function.
      ./drivers/cpufreq/ppc_cbe_cpufreq.c:89:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 76, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: linux-pm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d1f82d91
    • Huazhong Tan's avatar
      net: hns3: add error handler for initializing command queue · bbc8d4d4
      Huazhong Tan authored
      [ Upstream commit 4339ef39 ]
      
      This patch adds error handler for the failure of command queue
      initialization both PF and VF.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bbc8d4d4
    • Kristian Evensen's avatar
      qmi_wwan: Add quirk for Quectel dynamic config · 3063f0f5
      Kristian Evensen authored
      [ Upstream commit e4bf6348 ]
      
      Most, if not all, Quectel devices use dynamic interface numbers, and
      users are able to change the USB configuration at will. Matching on for
      example interface number is therefore not possible.
      
      Instead, the QMI device can be identified by looking at the interface
      class, subclass and protocol (all 0xff), as well as the number of
      endpoints. The reason we need to look at the number of endpoints, is
      that the diagnostic port interface has the same class, subclass and
      protocol as QMI. However, the diagnostic port only has two endpoints,
      while QMI has three.
      
      Until now, we have identified the QMI device by combining a match on
      class, subclass and protocol, with a call to the function
      quectel_diag_detect(). In quectel_diag_detect(), we check if the number
      of endpoints matches for known Quectel vendor/product ids.
      
      Adding new vendor/product ids to quectel_diag_detect() is not a good
      long-term solution. This commit replaces the function with a quirk, and
      applies the quirk to affected Quectel devices that I have been able to
      test the change with (EP06, EM12 and EC25). If the quirk is set and the
      number of endpoints equal two, we return from qmi_wwan_probe() with
      -ENODEV.
      Signed-off-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3063f0f5
    • Huazhong Tan's avatar
      net: hns3: fix keep_alive_timer not stop problem · e88bd7e3
      Huazhong Tan authored
      [ Upstream commit e233516e ]
      
      When hclgevf_client_start() fails or VF driver unloaded, there is
      nobody to disable keep_alive_timer.
      
      So this patch fixes them.
      
      Fixes: a6d818e3 ("net: hns3: Add vport alive state checking support")
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e88bd7e3