1. 31 May, 2019 40 commits
    • Wen Yang's avatar
      ASoC: eukrea-tlv320: fix a leaked reference by adding missing of_node_put · bac9fcee
      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>
      bac9fcee
    • Nicolas Saenz Julienne's avatar
      HID: core: move Usage Page concatenation to Main item · 1410277e
      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>
      1410277e
    • Chengguang Xu's avatar
      chardev: add additional check for minor range overlap · bb22efcb
      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>
      bb22efcb
    • Peter Zijlstra's avatar
      x86/ia32: Fix ia32_restore_sigcontext() AC leak · de90525f
      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>
      de90525f
    • Peter Zijlstra's avatar
      x86/uaccess, signal: Fix AC=1 bloat · c8fb42b7
      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>
      c8fb42b7
    • Wen Yang's avatar
      arm64: cpu_ops: fix a leaked reference by adding missing of_node_put · e07fb7e7
      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>
      e07fb7e7
    • Stanley Chu's avatar
      scsi: ufs: Avoid configuring regulator with undefined voltage range · 41761299
      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>
      41761299
    • Stanley Chu's avatar
      scsi: ufs: Fix regulator load and icc-level configuration · 75246f57
      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>
      75246f57
    • Piotr Figiel's avatar
      brcmfmac: fix Oops when bringing up interface during USB disconnect · 638b996e
      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>
      638b996e
    • Piotr Figiel's avatar
      brcmfmac: fix race during disconnect when USB completion is in progress · d857a7a2
      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>
      d857a7a2
    • Piotr Figiel's avatar
      brcmfmac: convert dev_init_lock mutex to completion · d696d385
      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>
      d696d385
    • Arnd Bergmann's avatar
      b43: shut up clang -Wuninitialized variable warning · 66fb5810
      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>
      66fb5810
    • Kangjie Lu's avatar
      brcmfmac: fix missing checks for kmemdup · d647661f
      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>
      d647661f
    • YueHaibing's avatar
      mwifiex: Fix mem leak in mwifiex_tm_cmd · 5ff8545c
      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>
      5ff8545c
    • Kangjie Lu's avatar
      rtlwifi: fix a potential NULL pointer dereference · 088c9aa3
      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>
      088c9aa3
    • Nathan Chancellor's avatar
      iio: common: ssp_sensors: Initialize calculated_time in ssp_common_process_data · b0ef67af
      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>
      b0ef67af
    • Kangjie Lu's avatar
      iio: hmc5843: fix potential NULL pointer dereferences · 2fd9d6a0
      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>
      2fd9d6a0
    • Lars-Peter Clausen's avatar
      iio: ad_sigma_delta: Properly handle SPI bus locking vs CS assertion · 0ce6473c
      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>
      0ce6473c
    • Kees Cook's avatar
      x86/build: Keep local relocations with ld.lld · c5e8fa7f
      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>
      c5e8fa7f
    • Wen Yang's avatar
      cpufreq: pmac32: fix possible object reference leak · 7296978b
      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>
      7296978b
    • Wen Yang's avatar
      cpufreq/pasemi: fix possible object reference leak · bf1ff11b
      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>
      bf1ff11b
    • Wen Yang's avatar
      cpufreq: ppc_cbe: fix possible object reference leak · 5a5e3e7e
      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>
      5a5e3e7e
    • Arnd Bergmann's avatar
      s390: cio: fix cio_irb declaration · f16886fa
      Arnd Bergmann authored
      [ Upstream commit e91012ee ]
      
      clang points out that the declaration of cio_irb does not match the
      definition exactly, it is missing the alignment attribute:
      
      ../drivers/s390/cio/cio.c:50:1: warning: section does not match previous declaration [-Wsection]
      DEFINE_PER_CPU_ALIGNED(struct irb, cio_irb);
      ^
      ../include/linux/percpu-defs.h:150:2: note: expanded from macro 'DEFINE_PER_CPU_ALIGNED'
              DEFINE_PER_CPU_SECTION(type, name, PER_CPU_ALIGNED_SECTION)     \
              ^
      ../include/linux/percpu-defs.h:93:9: note: expanded from macro 'DEFINE_PER_CPU_SECTION'
              extern __PCPU_ATTRS(sec) __typeof__(type) name;                 \
                     ^
      ../include/linux/percpu-defs.h:49:26: note: expanded from macro '__PCPU_ATTRS'
              __percpu __attribute__((section(PER_CPU_BASE_SECTION sec)))     \
                                      ^
      ../drivers/s390/cio/cio.h:118:1: note: previous attribute is here
      DECLARE_PER_CPU(struct irb, cio_irb);
      ^
      ../include/linux/percpu-defs.h:111:2: note: expanded from macro 'DECLARE_PER_CPU'
              DECLARE_PER_CPU_SECTION(type, name, "")
              ^
      ../include/linux/percpu-defs.h:87:9: note: expanded from macro 'DECLARE_PER_CPU_SECTION'
              extern __PCPU_ATTRS(sec) __typeof__(type) name
                     ^
      ../include/linux/percpu-defs.h:49:26: note: expanded from macro '__PCPU_ATTRS'
              __percpu __attribute__((section(PER_CPU_BASE_SECTION sec)))     \
                                      ^
      Use DECLARE_PER_CPU_ALIGNED() here, to make the two match.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f16886fa
    • Charles Keepax's avatar
      extcon: arizona: Disable mic detect if running when driver is removed · ffd48ee8
      Charles Keepax authored
      [ Upstream commit 00053de5 ]
      
      Microphone detection provides the button detection features on the
      Arizona CODECs as such it will be running if the jack is currently
      inserted. If the driver is unbound whilst the jack is still inserted
      this will cause warnings from the regulator framework as the MICVDD
      regulator is put but was never disabled.
      
      Correct this by disabling microphone detection on driver removal and if
      the microphone detection was running disable the regulator and put the
      runtime reference that was currently held.
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: default avatarChanwoo Choi <cw00.choi@samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ffd48ee8
    • Ulf Hansson's avatar
      PM / core: Propagate dev->power.wakeup_path when no callbacks · f4bb9041
      Ulf Hansson authored
      [ Upstream commit dc351d4c ]
      
      The dev->power.direct_complete flag may become set in device_prepare() in
      case the device don't have any PM callbacks (dev->power.no_pm_callbacks is
      set). This leads to a broken behaviour, when there is child having wakeup
      enabled and relies on its parent to be used in the wakeup path.
      
      More precisely, when the direct complete path becomes selected for the
      child in __device_suspend(), the propagation of the dev->power.wakeup_path
      becomes skipped as well.
      
      Let's address this problem, by checking if the device is a part the wakeup
      path or has wakeup enabled, then prevent the direct complete path from
      being used.
      Reported-by: default avatarLoic Pallardy <loic.pallardy@st.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      [ rjw: Comment cleanup ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f4bb9041
    • Yinbo Zhu's avatar
      mmc: sdhci-of-esdhc: add erratum eSDHC-A001 and A-008358 support · 6336b2f7
      Yinbo Zhu authored
      [ Upstream commit 05cb6b2a ]
      
      eSDHC-A001: The data timeout counter (SYSCTL[DTOCV]) is not
      reliable for DTOCV values 0x4(2^17 SD clock), 0x8(2^21 SD clock),
      and 0xC(2^25 SD clock). The data timeout counter can count from
      2^13–2^27, but for values 2^17, 2^21, and 2^25, the timeout
      counter counts for only 2^13 SD clocks.
      A-008358: The data timeout counter value loaded into the timeout
      counter is less than expected and can result into early timeout
      error in case of eSDHC data transactions. The table below shows
      the expected vs actual timeout period for different values of
      SYSCTL[DTOCV]:
      these two erratum has the same quirk to control it, and set
      SDHCI_QUIRK_RESET_AFTER_REQUEST to fix above issue.
      Signed-off-by: default avatarYinbo Zhu <yinbo.zhu@nxp.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6336b2f7
    • Yinbo Zhu's avatar
      mmc: sdhci-of-esdhc: add erratum eSDHC5 support · 84a16320
      Yinbo Zhu authored
      [ Upstream commit a46e4271 ]
      
      Software writing to the Transfer Type configuration register
      (system clock domain) can cause a setup/hold violation in the
      CRC flops (card clock domain), which can cause write accesses
      to be sent with corrupt CRC values. This issue occurs only for
      write preceded by read. this erratum is to fix this issue.
      Signed-off-by: default avatarYinbo Zhu <yinbo.zhu@nxp.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      84a16320
    • Kangjie Lu's avatar
      mmc_spi: add a status check for spi_sync_locked · cb1962ff
      Kangjie Lu authored
      [ Upstream commit 61102598 ]
      
      In case spi_sync_locked fails, the fix reports the error and
      returns the error code upstream.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cb1962ff
    • Andrea Merello's avatar
      mmc: core: make pwrseq_emmc (partially) support sleepy GPIO controllers · 20ac710a
      Andrea Merello authored
      [ Upstream commit 002ee28e ]
      
      pwrseq_emmc.c implements a HW reset procedure for eMMC chip by driving a
      GPIO line.
      
      It registers the .reset() cb on mmc_pwrseq_ops and it registers a system
      restart notification handler; both of them perform reset by unconditionally
      calling gpiod_set_value().
      
      If the eMMC reset line is tied to a GPIO controller whose driver can sleep
      (i.e. I2C GPIO controller), then the kernel would spit warnings when trying
      to reset the eMMC chip by means of .reset() mmc_pwrseq_ops cb (that is
      exactly what I'm seeing during boot).
      
      Furthermore, on system reset we would gets to the system restart
      notification handler with disabled interrupts - local_irq_disable() is
      called in machine_restart() at least on ARM/ARM64 - and we would be in
      trouble when the GPIO driver tries to sleep (which indeed doesn't happen
      here, likely because in my case the machine specific code doesn't call
      do_kernel_restart(), I guess..).
      
      This patch fixes the .reset() cb to make use of gpiod_set_value_cansleep(),
      so that the eMMC gets reset on boot without complaints, while, since there
      isn't that much we can do, we avoid register the restart handler if the
      GPIO controller has a sleepy driver (and we spit a dev_notice() message to
      let people know)..
      
      This had been tested on a downstream 4.9 kernel with backported
      commit 83f37ee7ba33 ("mmc: pwrseq: Add reset callback to the struct
      mmc_pwrseq_ops") and commit ae60fb031cf2 ("mmc: core: Don't do eMMC HW
      reset when resuming the eMMC card"), because I couldn't boot my board
      otherwise. Maybe worth to RFT.
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      20ac710a
    • John Garry's avatar
      scsi: libsas: Do discovery on empty PHY to update PHY info · 17d9e39b
      John Garry authored
      [ Upstream commit d8649fc1 ]
      
      When we discover the PHY is empty in sas_rediscover_dev(), the PHY
      information (like negotiated linkrate) is not updated.
      
      As such, for a user examining sysfs for that PHY, they would see
      incorrect values:
      
      root@(none)$ cd /sys/class/sas_phy/phy-0:0:20
      root@(none)$ more negotiated_linkrate
      3.0 Gbit
      root@(none)$ echo 0 > enable
      root@(none)$ more negotiated_linkrate
      3.0 Gbit
      
      So fix this, simply discover the PHY again, even though we know it's empty;
      in the above example, this gives us:
      
      root@(none)$ more negotiated_linkrate
      Phy disabled
      
      We must do this after unregistering the device associated with the PHY
      (in sas_unregister_devs_sas_addr()).
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      17d9e39b
    • Guenter Roeck's avatar
      hwmon: (f71805f) Use request_muxed_region for Super-IO accesses · 8f979e5b
      Guenter Roeck authored
      [ Upstream commit 73e6ff71 ]
      
      Super-IO accesses may fail on a system with no or unmapped LPC bus.
      
      Unable to handle kernel paging request at virtual address ffffffbffee0002e
      pgd = ffffffc1d68d4000
      [ffffffbffee0002e] *pgd=0000000000000000, *pud=0000000000000000
      Internal error: Oops: 94000046 [#1] PREEMPT SMP
      Modules linked in: f71805f(+) hwmon
      CPU: 3 PID: 1659 Comm: insmod Not tainted 4.5.0+ #88
      Hardware name: linux,dummy-virt (DT)
      task: ffffffc1f6665400 ti: ffffffc1d6418000 task.ti: ffffffc1d6418000
      PC is at f71805f_find+0x6c/0x358 [f71805f]
      
      Also, other drivers may attempt to access the LPC bus at the same time,
      resulting in undefined behavior.
      
      Use request_muxed_region() to ensure that IO access on the requested
      address space is supported, and to ensure that access by multiple
      drivers is synchronized.
      
      Fixes: e53004e2 ("hwmon: New f71805f driver")
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reported-by: default avatarJohn Garry <john.garry@huawei.com>
      Cc: John Garry <john.garry@huawei.com>
      Acked-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8f979e5b
    • Guenter Roeck's avatar
      hwmon: (pc87427) Use request_muxed_region for Super-IO accesses · 9e1261a9
      Guenter Roeck authored
      [ Upstream commit 755a9b0f ]
      
      Super-IO accesses may fail on a system with no or unmapped LPC bus.
      
      Also, other drivers may attempt to access the LPC bus at the same time,
      resulting in undefined behavior.
      
      Use request_muxed_region() to ensure that IO access on the requested
      address space is supported, and to ensure that access by multiple drivers
      is synchronized.
      
      Fixes: ba224e2c ("hwmon: New PC87427 hardware monitoring driver")
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reported-by: default avatarJohn Garry <john.garry@huawei.com>
      Cc: John Garry <john.garry@huawei.com>
      Acked-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9e1261a9
    • Guenter Roeck's avatar
      hwmon: (smsc47b397) Use request_muxed_region for Super-IO accesses · a7f8e2d5
      Guenter Roeck authored
      [ Upstream commit 8c082675 ]
      
      Super-IO accesses may fail on a system with no or unmapped LPC bus.
      
      Also, other drivers may attempt to access the LPC bus at the same time,
      resulting in undefined behavior.
      
      Use request_muxed_region() to ensure that IO access on the requested
      address space is supported, and to ensure that access by multiple drivers
      is synchronized.
      
      Fixes: 8d5d45fb ("I2C: Move hwmon drivers (2/3)")
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reported-by: default avatarJohn Garry <john.garry@huawei.com>
      Cc: John Garry <john.garry@huawei.com>
      Acked-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a7f8e2d5
    • Guenter Roeck's avatar
      hwmon: (smsc47m1) Use request_muxed_region for Super-IO accesses · ac713a6f
      Guenter Roeck authored
      [ Upstream commit d6410408 ]
      
      Super-IO accesses may fail on a system with no or unmapped LPC bus.
      
      Also, other drivers may attempt to access the LPC bus at the same time,
      resulting in undefined behavior.
      
      Use request_muxed_region() to ensure that IO access on the requested
      address space is supported, and to ensure that access by multiple drivers
      is synchronized.
      
      Fixes: 8d5d45fb ("I2C: Move hwmon drivers (2/3)")
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Reported-by: default avatarJohn Garry <john.garry@huawei.com>
      Cc: John Garry <john.garry@huawei.com>
      Acked-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ac713a6f
    • Guenter Roeck's avatar
      hwmon: (vt1211) Use request_muxed_region for Super-IO accesses · f418d00b
      Guenter Roeck authored
      [ Upstream commit 14b97ba5 ]
      
      Super-IO accesses may fail on a system with no or unmapped LPC bus.
      
      Also, other drivers may attempt to access the LPC bus at the same time,
      resulting in undefined behavior.
      
      Use request_muxed_region() to ensure that IO access on the requested
      address space is supported, and to ensure that access by multiple drivers
      is synchronized.
      
      Fixes: 2219cd81 ("hwmon/vt1211: Add probing of alternate config index port")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f418d00b
    • Colin Ian King's avatar
      RDMA/cxgb4: Fix null pointer dereference on alloc_skb failure · 3b82ce17
      Colin Ian King authored
      [ Upstream commit a6d2a5a9 ]
      
      Currently if alloc_skb fails to allocate the skb a null skb is passed to
      t4_set_arp_err_handler and this ends up dereferencing the null skb.  Avoid
      the NULL pointer dereference by checking for a NULL skb and returning
      early.
      
      Addresses-Coverity: ("Dereference null return")
      Fixes: b38a0ad8 ("RDMA/cxgb4: Set arp error handler for PASS_ACCEPT_RPL messages")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Acked-by: default avatarPotnuri Bharat Teja <bharat@chelsio.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3b82ce17
    • Vincenzo Frascino's avatar
      arm64: vdso: Fix clock_getres() for CLOCK_REALTIME · 9f641ee2
      Vincenzo Frascino authored
      [ Upstream commit 81fb8736 ]
      
      clock_getres() in the vDSO library has to preserve the same behaviour
      of posix_get_hrtimer_res().
      
      In particular, posix_get_hrtimer_res() does:
      
          sec = 0;
          ns = hrtimer_resolution;
      
      where 'hrtimer_resolution' depends on whether or not high resolution
      timers are enabled, which is a runtime decision.
      
      The vDSO incorrectly returns the constant CLOCK_REALTIME_RES. Fix this
      by exposing 'hrtimer_resolution' in the vDSO datapage and returning that
      instead.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      [will: Use WRITE_ONCE(), move adr off COARSE path, renumber labels, use 'w' reg]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9f641ee2
    • Nicholas Nunley's avatar
      i40e: don't allow changes to HW VLAN stripping on active port VLANs · f64615a8
      Nicholas Nunley authored
      [ Upstream commit bfb0ebed ]
      
      Modifying the VLAN stripping options when a port VLAN is configured
      will break traffic for the VSI, and conceptually doesn't make sense,
      so don't allow this.
      Signed-off-by: default avatarNicholas Nunley <nicholas.d.nunley@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f64615a8
    • Thomas Gleixner's avatar
      x86/irq/64: Limit IST stack overflow check to #DB stack · fad8d76d
      Thomas Gleixner authored
      [ Upstream commit 7dbcf2b0 ]
      
      Commit
      
        37fe6a42 ("x86: Check stack overflow in detail")
      
      added a broad check for the full exception stack area, i.e. it considers
      the full exception stack area as valid.
      
      That's wrong in two aspects:
      
       1) It does not check the individual areas one by one
      
       2) #DF, NMI and #MCE are not enabling interrupts which means that a
          regular device interrupt cannot happen in their context. In fact if a
          device interrupt hits one of those IST stacks that's a bug because some
          code path enabled interrupts while handling the exception.
      
      Limit the check to the #DB stack and consider all other IST stacks as
      'overflow' or invalid.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
      Cc: Nicolai Stange <nstange@suse.de>
      Cc: Sean Christopherson <sean.j.christopherson@intel.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190414160143.682135110@linutronix.deSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      fad8d76d
    • Alan Stern's avatar
      USB: core: Don't unbind interfaces following device reset failure · 9105d112
      Alan Stern authored
      [ Upstream commit 381419fa ]
      
      The SCSI core does not like to have devices or hosts unregistered
      while error recovery is in progress.  Trying to do so can lead to
      self-deadlock: Part of the removal code tries to obtain a lock already
      held by the error handler.
      
      This can cause problems for the usb-storage and uas drivers, because
      their error handler routines perform a USB reset, and if the reset
      fails then the USB core automatically goes on to unbind all drivers
      from the device's interfaces -- all while still in the context of the
      SCSI error handler.
      
      As it turns out, practically all the scenarios leading to a USB reset
      failure end up causing a device disconnect (the main error pathway in
      usb_reset_and_verify_device(), at the end of the routine, calls
      hub_port_logical_disconnect() before returning).  As a result, the
      hub_wq thread will soon become aware of the problem and will unbind
      all the device's drivers in its own context, not in the
      error-handler's context.
      
      This means that usb_reset_device() does not need to call
      usb_unbind_and_rebind_marked_interfaces() in cases where
      usb_reset_and_verify_device() has returned an error, because hub_wq
      will take care of everything anyway.
      
      This particular problem was observed in somewhat artificial
      circumstances, by using usbfs to tell a hub to power-down a port
      connected to a USB-3 mass storage device using the UAS protocol.  With
      the port turned off, the currently executing command timed out and the
      error handler started running.  The USB reset naturally failed,
      because the hub port was off, and the error handler deadlocked as
      described above.  Not carrying out the call to
      usb_unbind_and_rebind_marked_interfaces() fixes this issue.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarKento Kobayashi <Kento.A.Kobayashi@sony.com>
      Tested-by: default avatarKento Kobayashi <Kento.A.Kobayashi@sony.com>
      CC: Bart Van Assche <bvanassche@acm.org>
      CC: Martin K. Petersen <martin.petersen@oracle.com>
      CC: Jacky Cao <Jacky.Cao@sony.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9105d112