1. 26 Jul, 2019 40 commits
    • Miaoqing Pan's avatar
      ath10k: fix PCIE device wake up failed · 81124baa
      Miaoqing Pan authored
      [ Upstream commit 011d4111 ]
      
      Observed PCIE device wake up failed after ~120 iterations of
      soft-reboot test. The error message is
      "ath10k_pci 0000:01:00.0: failed to wake up device : -110"
      
      The call trace as below:
      ath10k_pci_probe -> ath10k_pci_force_wake -> ath10k_pci_wake_wait ->
      ath10k_pci_is_awake
      
      Once trigger the device to wake up, we will continuously check the RTC
      state until it returns RTC_STATE_V_ON or timeout.
      
      But for QCA99x0 chips, we use wrong value for RTC_STATE_V_ON.
      Occasionally, we get 0x7 on the fist read, we thought as a failure
      case, but actually is the right value, also verified with the spec.
      So fix the issue by changing RTC_STATE_V_ON from 0x5 to 0x7, passed
      ~2000 iterations.
      
      Tested HW: QCA9984
      Signed-off-by: default avatarMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      81124baa
    • Miaoqing Pan's avatar
      ath10k: fix fw crash by moving chip reset after napi disabled · 080c204b
      Miaoqing Pan authored
      [ Upstream commit 08d80e4c ]
      
      On SMP platform, when continuously running wifi up/down, the napi
      poll can be scheduled during chip reset, which will call
      ath10k_pci_has_fw_crashed() to check the fw status. But in the reset
      period, the value from FW_INDICATOR_ADDRESS register will return
      0xdeadbeef, which also be treated as fw crash. Fix the issue by
      moving chip reset after napi disabled.
      
      ath10k_pci 0000:01:00.0: firmware crashed! (guid 73b30611-5b1e-4bdd-90b4-64c81eb947b6)
      ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
      ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
      ath10k_pci 0000:01:00.0: failed to get memcpy hi address for firmware address 4: -16
      ath10k_pci 0000:01:00.0: failed to read firmware dump area: -16
      ath10k_pci 0000:01:00.0: Copy Engine register dump:
      ath10k_pci 0000:01:00.0: [00]: 0x0004a000   0   0   0   0
      ath10k_pci 0000:01:00.0: [01]: 0x0004a400   0   0   0   0
      ath10k_pci 0000:01:00.0: [02]: 0x0004a800   0   0   0   0
      ath10k_pci 0000:01:00.0: [03]: 0x0004ac00   0   0   0   0
      ath10k_pci 0000:01:00.0: [04]: 0x0004b000   0   0   0   0
      ath10k_pci 0000:01:00.0: [05]: 0x0004b400   0   0   0   0
      ath10k_pci 0000:01:00.0: [06]: 0x0004b800   0   0   0   0
      ath10k_pci 0000:01:00.0: [07]: 0x0004bc00   1   0   1   0
      ath10k_pci 0000:01:00.0: [08]: 0x0004c000   0   0   0   0
      ath10k_pci 0000:01:00.0: [09]: 0x0004c400   0   0   0   0
      ath10k_pci 0000:01:00.0: [10]: 0x0004c800   0   0   0   0
      ath10k_pci 0000:01:00.0: [11]: 0x0004cc00   0   0   0   0
      
      Tested HW: QCA9984,QCA9887,WCN3990
      Signed-off-by: default avatarMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      080c204b
    • Claire Chang's avatar
      ath10k: add missing error handling · 4e59c7c6
      Claire Chang authored
      [ Upstream commit 4b553f3c ]
      
      In function ath10k_sdio_mbox_rx_alloc() [sdio.c],
      ath10k_sdio_mbox_alloc_rx_pkt() is called without handling the error cases.
      This will make the driver think the allocation for skb is successful and
      try to access the skb. If we enable failslab, system will easily crash with
      NULL pointer dereferencing.
      
      Call trace of CONFIG_FAILSLAB:
      ath10k_sdio_irq_handler+0x570/0xa88 [ath10k_sdio]
      process_sdio_pending_irqs+0x4c/0x174
      sdio_run_irqs+0x3c/0x64
      sdio_irq_work+0x1c/0x28
      
      Fixes: d96db25d ("ath10k: add initial SDIO support")
      Signed-off-by: default avatarClaire Chang <tientzu@chromium.org>
      Reviewed-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4e59c7c6
    • Julian Anastasov's avatar
      ipvs: fix tinfo memory leak in start_sync_thread · 477c2749
      Julian Anastasov authored
      [ Upstream commit 5db7c8b9 ]
      
      syzkaller reports for memory leak in start_sync_thread [1]
      
      As Eric points out, kthread may start and stop before the
      threadfn function is called, so there is no chance the
      data (tinfo in our case) to be released in thread.
      
      Fix this by releasing tinfo in the controlling code instead.
      
      [1]
      BUG: memory leak
      unreferenced object 0xffff8881206bf700 (size 32):
       comm "syz-executor761", pid 7268, jiffies 4294943441 (age 20.470s)
       hex dump (first 32 bytes):
         00 40 7c 09 81 88 ff ff 80 45 b8 21 81 88 ff ff  .@|......E.!....
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       backtrace:
         [<0000000057619e23>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
         [<0000000057619e23>] slab_post_alloc_hook mm/slab.h:439 [inline]
         [<0000000057619e23>] slab_alloc mm/slab.c:3326 [inline]
         [<0000000057619e23>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
         [<0000000086ce5479>] kmalloc include/linux/slab.h:547 [inline]
         [<0000000086ce5479>] start_sync_thread+0x5d2/0xe10 net/netfilter/ipvs/ip_vs_sync.c:1862
         [<000000001a9229cc>] do_ip_vs_set_ctl+0x4c5/0x780 net/netfilter/ipvs/ip_vs_ctl.c:2402
         [<00000000ece457c8>] nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
         [<00000000ece457c8>] nf_setsockopt+0x4c/0x80 net/netfilter/nf_sockopt.c:115
         [<00000000942f62d4>] ip_setsockopt net/ipv4/ip_sockglue.c:1258 [inline]
         [<00000000942f62d4>] ip_setsockopt+0x9b/0xb0 net/ipv4/ip_sockglue.c:1238
         [<00000000a56a8ffd>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
         [<00000000fa895401>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130
         [<0000000095eef4cf>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
         [<000000009747cf88>] __do_sys_setsockopt net/socket.c:2089 [inline]
         [<000000009747cf88>] __se_sys_setsockopt net/socket.c:2086 [inline]
         [<000000009747cf88>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
         [<00000000ded8ba80>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
         [<00000000893b4ac8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Reported-by: syzbot+7e2e50c8adfccd2e5041@syzkaller.appspotmail.com
      Suggested-by: default avatarEric Biggers <ebiggers@kernel.org>
      Fixes: 998e7a76 ("ipvs: Use kthread_run() instead of doing a double-fork via kernel_thread()")
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      477c2749
    • Lorenzo Bianconi's avatar
      mt7601u: fix possible memory leak when the device is disconnected · 5d099ded
      Lorenzo Bianconi authored
      [ Upstream commit 23377c20 ]
      
      When the device is disconnected while passing traffic it is possible
      to receive out of order urbs causing a memory leak since the skb linked
      to the current tx urb is not removed. Fix the issue deallocating the skb
      cleaning up the tx ring. Moreover this patch fixes the following kernel
      warning
      
      [   57.480771] usb 1-1: USB disconnect, device number 2
      [   57.483451] ------------[ cut here ]------------
      [   57.483462] TX urb mismatch
      [   57.483481] WARNING: CPU: 1 PID: 32 at drivers/net/wireless/mediatek/mt7601u/dma.c:245 mt7601u_complete_tx+0x165/00
      [   57.483483] Modules linked in:
      [   57.483496] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.2.0-rc1+ #72
      [   57.483498] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-2.fc30 04/01/2014
      [   57.483502] Workqueue: usb_hub_wq hub_event
      [   57.483507] RIP: 0010:mt7601u_complete_tx+0x165/0x1e0
      [   57.483510] Code: 8b b5 10 04 00 00 8b 8d 14 04 00 00 eb 8b 80 3d b1 cb e1 00 00 75 9e 48 c7 c7 a4 ea 05 82 c6 05 f
      [   57.483513] RSP: 0000:ffffc900000a0d28 EFLAGS: 00010092
      [   57.483516] RAX: 000000000000000f RBX: ffff88802c0a62c0 RCX: ffffc900000a0c2c
      [   57.483518] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff810a8371
      [   57.483520] RBP: ffff88803ced6858 R08: 0000000000000000 R09: 0000000000000001
      [   57.483540] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000046
      [   57.483542] R13: ffff88802c0a6c88 R14: ffff88803baab540 R15: ffff88803a0cc078
      [   57.483548] FS:  0000000000000000(0000) GS:ffff88803eb00000(0000) knlGS:0000000000000000
      [   57.483550] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   57.483552] CR2: 000055e7f6780100 CR3: 0000000028c86000 CR4: 00000000000006a0
      [   57.483554] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   57.483556] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   57.483559] Call Trace:
      [   57.483561]  <IRQ>
      [   57.483565]  __usb_hcd_giveback_urb+0x77/0xe0
      [   57.483570]  xhci_giveback_urb_in_irq.isra.0+0x8b/0x140
      [   57.483574]  handle_cmd_completion+0xf5b/0x12c0
      [   57.483577]  xhci_irq+0x1f6/0x1810
      [   57.483581]  ? lockdep_hardirqs_on+0x9e/0x180
      [   57.483584]  ? _raw_spin_unlock_irq+0x24/0x30
      [   57.483588]  __handle_irq_event_percpu+0x3a/0x260
      [   57.483592]  handle_irq_event_percpu+0x1c/0x60
      [   57.483595]  handle_irq_event+0x2f/0x4c
      [   57.483599]  handle_edge_irq+0x7e/0x1a0
      [   57.483603]  handle_irq+0x17/0x20
      [   57.483607]  do_IRQ+0x54/0x110
      [   57.483610]  common_interrupt+0xf/0xf
      [   57.483612]  </IRQ>
      Acked-by: default avatarJakub Kicinski <kubakici@wp.pl>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5d099ded
    • Masahiro Yamada's avatar
      x86/build: Add 'set -e' to mkcapflags.sh to delete broken capflags.c · 79e5cd36
      Masahiro Yamada authored
      [ Upstream commit bc53d3d7 ]
      
      Without 'set -e', shell scripts continue running even after any
      error occurs. The missed 'set -e' is a typical bug in shell scripting.
      
      For example, when a disk space shortage occurs while this script is
      running, it actually ends up with generating a truncated capflags.c.
      
      Yet, mkcapflags.sh continues running and exits with 0. So, the build
      system assumes it has succeeded.
      
      It will not be re-generated in the next invocation of Make since its
      timestamp is newer than that of any of the source files.
      
      Add 'set -e' so that any error in this script is caught and propagated
      to the build system.
      
      Since 9c2af1c7 ("kbuild: add .DELETE_ON_ERROR special target"),
      make automatically deletes the target on any failure. So, the broken
      capflags.c will be deleted automatically.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Link: https://lkml.kernel.org/r/20190625072622.17679-1-yamada.masahiro@socionext.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      79e5cd36
    • Lorenzo Bianconi's avatar
      mt7601u: do not schedule rx_tasklet when the device has been disconnected · ce48f658
      Lorenzo Bianconi authored
      [ Upstream commit 4079e8cc ]
      
      Do not schedule rx_tasklet when the usb dongle is disconnected.
      Moreover do not grub rx_lock in mt7601u_kill_rx since usb_poison_urb
      can run concurrently with urb completion and we can unlink urbs from rx
      ring in any order.
      This patch fixes the common kernel warning reported when
      the device is removed.
      
      [   24.921354] usb 3-14: USB disconnect, device number 7
      [   24.921593] ------------[ cut here ]------------
      [   24.921594] RX urb mismatch
      [   24.921675] WARNING: CPU: 4 PID: 163 at drivers/net/wireless/mediatek/mt7601u/dma.c:200 mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
      [   24.921769] CPU: 4 PID: 163 Comm: kworker/4:2 Tainted: G           OE     4.19.31-041931-generic #201903231635
      [   24.921770] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.30 05/23/2014
      [   24.921782] Workqueue: usb_hub_wq hub_event
      [   24.921797] RIP: 0010:mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
      [   24.921800] RSP: 0018:ffff9bd9cfd03d08 EFLAGS: 00010086
      [   24.921802] RAX: 0000000000000000 RBX: ffff9bd9bf043540 RCX: 0000000000000006
      [   24.921803] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff9bd9cfd16420
      [   24.921804] RBP: ffff9bd9cfd03d28 R08: 0000000000000002 R09: 00000000000003a8
      [   24.921805] R10: 0000002f485fca34 R11: 0000000000000000 R12: ffff9bd9bf043c1c
      [   24.921806] R13: ffff9bd9c62fa3c0 R14: 0000000000000082 R15: 0000000000000000
      [   24.921807] FS:  0000000000000000(0000) GS:ffff9bd9cfd00000(0000) knlGS:0000000000000000
      [   24.921808] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   24.921808] CR2: 00007fb2648b0000 CR3: 0000000142c0a004 CR4: 00000000001606e0
      [   24.921809] Call Trace:
      [   24.921812]  <IRQ>
      [   24.921819]  __usb_hcd_giveback_urb+0x8b/0x140
      [   24.921821]  usb_hcd_giveback_urb+0xca/0xe0
      [   24.921828]  xhci_giveback_urb_in_irq.isra.42+0x82/0xf0
      [   24.921834]  handle_cmd_completion+0xe02/0x10d0
      [   24.921837]  xhci_irq+0x274/0x4a0
      [   24.921838]  xhci_msi_irq+0x11/0x20
      [   24.921851]  __handle_irq_event_percpu+0x44/0x190
      [   24.921856]  handle_irq_event_percpu+0x32/0x80
      [   24.921861]  handle_irq_event+0x3b/0x5a
      [   24.921867]  handle_edge_irq+0x80/0x190
      [   24.921874]  handle_irq+0x20/0x30
      [   24.921889]  do_IRQ+0x4e/0xe0
      [   24.921891]  common_interrupt+0xf/0xf
      [   24.921892]  </IRQ>
      [   24.921900] RIP: 0010:usb_hcd_flush_endpoint+0x78/0x180
      [   24.921354] usb 3-14: USB disconnect, device number 7
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ce48f658
    • Ping-Ke Shih's avatar
      rtlwifi: rtl8192cu: fix error handle when usb probe failed · e6506579
      Ping-Ke Shih authored
      [ Upstream commit 6c0ed66f ]
      
      rtl_usb_probe() must do error handle rtl_deinit_core() only if
      rtl_init_core() is done, otherwise goto error_out2.
      
      | usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
      | rtl_usb: reg 0xf0, usbctrl_vendorreq TimeOut! status:0xffffffb9 value=0x0
      | rtl8192cu: Chip version 0x10
      | rtl_usb: reg 0xa, usbctrl_vendorreq TimeOut! status:0xffffffb9 value=0x0
      | rtl_usb: Too few input end points found
      | INFO: trying to register non-static key.
      | the code is fine but needs lockdep annotation.
      | turning off the locking correctness validator.
      | CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
      | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      | Google 01/01/2011
      | Workqueue: usb_hub_wq hub_event
      | Call Trace:
      |   __dump_stack lib/dump_stack.c:77 [inline]
      |   dump_stack+0xe8/0x16e lib/dump_stack.c:113
      |   assign_lock_key kernel/locking/lockdep.c:786 [inline]
      |   register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
      |   __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
      |   lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
      |   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
      |   _raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
      |   rtl_c2hcmd_launcher+0xd1/0x390
      | drivers/net/wireless/realtek/rtlwifi/base.c:2344
      |   rtl_deinit_core+0x25/0x2d0 drivers/net/wireless/realtek/rtlwifi/base.c:574
      |   rtl_usb_probe.cold+0x861/0xa70
      | drivers/net/wireless/realtek/rtlwifi/usb.c:1093
      |   usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
      |   really_probe+0x2da/0xb10 drivers/base/dd.c:509
      |   driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
      |   __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
      |   bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
      |   __device_attach+0x223/0x3a0 drivers/base/dd.c:844
      |   bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
      |   device_add+0xad2/0x16e0 drivers/base/core.c:2106
      |   usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
      |   generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
      |   usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
      |   really_probe+0x2da/0xb10 drivers/base/dd.c:509
      |   driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
      |   __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
      |   bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
      |   __device_attach+0x223/0x3a0 drivers/base/dd.c:844
      |   bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
      |   device_add+0xad2/0x16e0 drivers/base/core.c:2106
      |   usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
      |   hub_port_connect drivers/usb/core/hub.c:5089 [inline]
      |   hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
      |   port_event drivers/usb/core/hub.c:5350 [inline]
      |   hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
      |   process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
      |   worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
      |   kthread+0x313/0x420 kernel/kthread.c:253
      |   ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      Reported-by: syzbot+1fcc5ef45175fc774231@syzkaller.appspotmail.com
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e6506579
    • Icenowy Zheng's avatar
      net: stmmac: sun8i: force select external PHY when no internal one · dc654e84
      Icenowy Zheng authored
      [ Upstream commit 0fec7e72 ]
      
      The PHY selection bit also exists on SoCs without an internal PHY; if it's
      set to 1 (internal PHY, default value) then the MAC will not make use of
      any PHY on such SoCs.
      
      This problem appears when adapting for H6, which has no real internal PHY
      (the "internal PHY" on H6 is not on-die, but on a co-packaged AC200 chip,
      connected via RMII interface at GPIO bank A).
      
      Force the PHY selection bit to 0 when the SOC doesn't have an internal PHY,
      to address the problem of a wrong default value.
      Signed-off-by: default avatarIcenowy Zheng <icenowy@aosc.io>
      Signed-off-by: default avatarOndrej Jirman <megous@megous.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dc654e84
    • Hans Verkuil's avatar
      media: hdpvr: fix locking and a missing msleep · 93ba4c72
      Hans Verkuil authored
      [ Upstream commit 6bc5a4a1 ]
      
      This driver has three locking issues:
      
      - The wait_event_interruptible() condition calls hdpvr_get_next_buffer(dev)
        which uses a mutex, which is not allowed. Rewrite with list_empty_careful()
        that doesn't need locking.
      
      - In hdpvr_read() the call to hdpvr_stop_streaming() didn't lock io_mutex,
        but it should have since stop_streaming expects that.
      
      - In hdpvr_device_release() io_mutex was locked when calling flush_work(),
        but there it shouldn't take that mutex since the work done by flush_work()
        also wants to lock that mutex.
      
      There are also two other changes (suggested by Keith):
      
      - msecs_to_jiffies(4000); (a NOP) should have been msleep(4000).
      - Change v4l2_dbg to v4l2_info to always log if streaming had to be restarted.
      Reported-by: default avatarKeith Pyle <kpyle@austin.rr.com>
      Suggested-by: default avatarKeith Pyle <kpyle@austin.rr.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      93ba4c72
    • André Almeida's avatar
      media: vimc: cap: check v4l2_fill_pixfmt return value · e116077a
      André Almeida authored
      [ Upstream commit 77ae46e1 ]
      
      v4l2_fill_pixfmt() returns -EINVAL if the pixelformat used as parameter is
      invalid or if the user is trying to use a multiplanar format with the
      singleplanar API. Currently, the vimc_cap_try_fmt_vid_cap() returns such
      value, but vimc_cap_s_fmt_vid_cap() is ignoring it. Fix that and returns
      an error value if vimc_cap_try_fmt_vid_cap() has failed.
      Signed-off-by: default avatarAndré Almeida <andrealmeid@collabora.com>
      Suggested-by: default avatarHelen Koike <helen.koike@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e116077a
    • Philipp Zabel's avatar
      media: coda: increment sequence offset for the last returned frame · d0e10dee
      Philipp Zabel authored
      [ Upstream commit b3b7d968 ]
      
      If no more frames are decoded in bitstream end mode, and a previously
      decoded frame has been returned, the firmware still increments the frame
      number. To avoid a sequence number mismatch after decoder restart,
      increment the sequence_offset correction parameter.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d0e10dee
    • Marco Felsch's avatar
      media: coda: fix last buffer handling in V4L2_ENC_CMD_STOP · cc1c3011
      Marco Felsch authored
      [ Upstream commit f3775f89 ]
      
      coda_encoder_cmd() is racy, as the last scheduled picture run worker can
      still be in-flight while the ENC_CMD_STOP command is issued. Depending
      on the exact timing the sequence numbers might already be changed, but
      the last buffer might not have been put on the destination queue yet.
      
      In this case the current implementation would prematurely wake the
      destination queue with last_buffer_dequeued=true, causing userspace to
      call streamoff before the last buffer is handled.
      
      Close this race window by synchronizing with the pic_run_worker before
      doing the sequence check.
      Signed-off-by: default avatarMarco Felsch <m.felsch@pengutronix.de>
      [l.stach@pengutronix.de: switch to flush_work, reword commit message]
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cc1c3011
    • Philipp Zabel's avatar
      media: coda: fix mpeg2 sequence number handling · b6a853dd
      Philipp Zabel authored
      [ Upstream commit 56d159a4 ]
      
      Sequence number handling assumed that the BIT processor frame number
      starts counting at 1, but this is not true for the MPEG-2 decoder,
      which starts at 0. Fix the sequence counter offset detection to handle
      this.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b6a853dd
    • Ard Biesheuvel's avatar
      acpi/arm64: ignore 5.1 FADTs that are reported as 5.0 · 67d73cc8
      Ard Biesheuvel authored
      [ Upstream commit 2af22f3e ]
      
      Some Qualcomm Snapdragon based laptops built to run Microsoft Windows
      are clearly ACPI 5.1 based, given that that is the first ACPI revision
      that supports ARM, and introduced the FADT 'arm_boot_flags' field,
      which has a non-zero field on those systems.
      
      So in these cases, infer from the ARM boot flags that the FADT must be
      5.1 or later, and treat it as 5.1.
      Acked-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Tested-by: default avatarLee Jones <lee.jones@linaro.org>
      Reviewed-by: default avatarGraeme Gregory <graeme.gregory@linaro.org>
      Acked-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      67d73cc8
    • Kuninori Morimoto's avatar
      ASoC: soc-core: call snd_soc_unbind_card() under mutex_lock; · 95783489
      Kuninori Morimoto authored
      [ Upstream commit b545542a ]
      
      commit 34ac3c3e ("ASoC: core: lock client_mutex while removing
      link components") added mutex_lock() at soc_remove_link_components().
      
      Is is called from snd_soc_unbind_card()
      
      	snd_soc_unbind_card()
      =>		soc_remove_link_components()
      		soc_cleanup_card_resources()
      			soc_remove_dai_links()
      =>				soc_remove_link_components()
      
      And, there are 2 way to call it.
      
      (1)
      	snd_soc_unregister_component()
      **		mutex_lock()
      			snd_soc_component_del_unlocked()
      =>				snd_soc_unbind_card()
      **		mutex_unlock()
      
      (2)
      	snd_soc_unregister_card()
      =>		snd_soc_unbind_card()
      
      (1) case is already using mutex_lock() when it calles
      snd_soc_unbind_card(), thus, we will get lockdep warning.
      
      commit 495f926c ("ASoC: core: Fix deadlock in
      snd_soc_instantiate_card()") tried to fixup it, but still not
      enough. We still have lockdep warning when we try unbind/bind.
      
      We need mutex_lock() under snd_soc_unregister_card()
      instead of snd_remove_link_components()/snd_soc_unbind_card().
      
      Fixes: 34ac3c3e ("ASoC: core: lock client_mutex while removing link components")
      Fixes: 495f926c ("ASoC: core: Fix deadlock in snd_soc_instantiate_card()")
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      95783489
    • Robert Jarzmik's avatar
      media: mt9m111: fix fw-node refactoring · 3b12115f
      Robert Jarzmik authored
      [ Upstream commit 8d4e29a5 ]
      
      In the patch refactoring the fw-node, the mt9m111 was broken for all
      platform_data based platforms, which were the first aim of this
      driver. Only the devicetree platform are still functional, probably
      because the testing was done on these.
      
      The result is that -EINVAL is systematically return for such platforms,
      what this patch fixes.
      
      [Sakari Ailus: Rework this to resolve a merge conflict and use dev_fwnode]
      
      Fixes: 98480d65 ("media: mt9m111: allow to setup pixclk polarity")
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3b12115f
    • Nathan Huckleberry's avatar
      timer_list: Guard procfs specific code · ee2e483f
      Nathan Huckleberry authored
      [ Upstream commit a9314773 ]
      
      With CONFIG_PROC_FS=n the following warning is emitted:
      
      kernel/time/timer_list.c:361:36: warning: unused variable
      'timer_list_sops' [-Wunused-const-variable]
         static const struct seq_operations timer_list_sops = {
      
      Add #ifdef guard around procfs specific code.
      Signed-off-by: default avatarNathan Huckleberry <nhuck@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: john.stultz@linaro.org
      Cc: sboyd@kernel.org
      Cc: clang-built-linux@googlegroups.com
      Link: https://github.com/ClangBuiltLinux/linux/issues/534
      Link: https://lkml.kernel.org/r/20190614181604.112297-1-nhuck@google.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee2e483f
    • Miroslav Lichvar's avatar
      ntp: Limit TAI-UTC offset · a0d5e56f
      Miroslav Lichvar authored
      [ Upstream commit d897a4ab ]
      
      Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
      to a value larger than 100000 seconds.
      
      This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
      clock from getting too far ahead of the CLOCK_REALTIME clock, and it is
      still large enough to allow leap seconds to be inserted at the maximum rate
      currently supported by the kernel (once per day) for the next ~270 years,
      however unlikely it is that someone can survive a catastrophic event which
      slowed down the rotation of the Earth so much.
      Reported-by: default avatarWeikang shi <swkhack@gmail.com>
      Signed-off-by: default avatarMiroslav Lichvar <mlichvar@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Stephen Boyd <sboyd@kernel.org>
      Link: https://lkml.kernel.org/r/20190618154713.20929-1-mlichvar@redhat.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      a0d5e56f
    • Anders Roxell's avatar
      media: i2c: fix warning same module names · 10e60db5
      Anders Roxell authored
      [ Upstream commit b2ce5617 ]
      
      When building with CONFIG_VIDEO_ADV7511 and CONFIG_DRM_I2C_ADV7511
      enabled as loadable modules, we see the following warning:
      
        drivers/gpu/drm/bridge/adv7511/adv7511.ko
        drivers/media/i2c/adv7511.ko
      
      Rework so that the file is named adv7511-v4l2.c.
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      10e60db5
    • Marek Szyprowski's avatar
      media: s5p-mfc: Make additional clocks optional · c98a3afe
      Marek Szyprowski authored
      [ Upstream commit e08efef8 ]
      
      Since the beginning the second clock ('special', 'sclk') was optional and
      it is not available on some variants of Exynos SoCs (i.e. Exynos5420 with
      v7 of MFC hardware).
      
      However commit 1bce6fb3 ("[media] s5p-mfc: Rework clock handling")
      made handling of all specified clocks mandatory. This patch restores
      original behavior of the driver and fixes its operation on
      Exynos5420 SoCs.
      
      Fixes: 1bce6fb3 ("[media] s5p-mfc: Rework clock handling")
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c98a3afe
    • Julian Anastasov's avatar
      ipvs: defer hook registration to avoid leaks · affa31e6
      Julian Anastasov authored
      [ Upstream commit cf47a0b8 ]
      
      syzkaller reports for memory leak when registering hooks [1]
      
      As we moved the nf_unregister_net_hooks() call into
      __ip_vs_dev_cleanup(), defer the nf_register_net_hooks()
      call, so that hooks are allocated and freed from same
      pernet_operations (ipvs_core_dev_ops).
      
      [1]
      BUG: memory leak
      unreferenced object 0xffff88810acd8a80 (size 96):
       comm "syz-executor073", pid 7254, jiffies 4294950560 (age 22.250s)
       hex dump (first 32 bytes):
         02 00 00 00 00 00 00 00 50 8b bb 82 ff ff ff ff  ........P.......
         00 00 00 00 00 00 00 00 00 77 bb 82 ff ff ff ff  .........w......
       backtrace:
         [<0000000013db61f1>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
         [<0000000013db61f1>] slab_post_alloc_hook mm/slab.h:439 [inline]
         [<0000000013db61f1>] slab_alloc_node mm/slab.c:3269 [inline]
         [<0000000013db61f1>] kmem_cache_alloc_node_trace+0x15b/0x2a0 mm/slab.c:3597
         [<000000001a27307d>] __do_kmalloc_node mm/slab.c:3619 [inline]
         [<000000001a27307d>] __kmalloc_node+0x38/0x50 mm/slab.c:3627
         [<0000000025054add>] kmalloc_node include/linux/slab.h:590 [inline]
         [<0000000025054add>] kvmalloc_node+0x4a/0xd0 mm/util.c:431
         [<0000000050d1bc00>] kvmalloc include/linux/mm.h:637 [inline]
         [<0000000050d1bc00>] kvzalloc include/linux/mm.h:645 [inline]
         [<0000000050d1bc00>] allocate_hook_entries_size+0x3b/0x60 net/netfilter/core.c:61
         [<00000000e8abe142>] nf_hook_entries_grow+0xae/0x270 net/netfilter/core.c:128
         [<000000004b94797c>] __nf_register_net_hook+0x9a/0x170 net/netfilter/core.c:337
         [<00000000d1545cbc>] nf_register_net_hook+0x34/0xc0 net/netfilter/core.c:464
         [<00000000876c9b55>] nf_register_net_hooks+0x53/0xc0 net/netfilter/core.c:480
         [<000000002ea868e0>] __ip_vs_init+0xe8/0x170 net/netfilter/ipvs/ip_vs_core.c:2280
         [<000000002eb2d451>] ops_init+0x4c/0x140 net/core/net_namespace.c:130
         [<000000000284ec48>] setup_net+0xde/0x230 net/core/net_namespace.c:316
         [<00000000a70600fa>] copy_net_ns+0xf0/0x1e0 net/core/net_namespace.c:439
         [<00000000ff26c15e>] create_new_namespaces+0x141/0x2a0 kernel/nsproxy.c:107
         [<00000000b103dc79>] copy_namespaces+0xa1/0xe0 kernel/nsproxy.c:165
         [<000000007cc008a2>] copy_process.part.0+0x11fd/0x2150 kernel/fork.c:2035
         [<00000000c344af7c>] copy_process kernel/fork.c:1800 [inline]
         [<00000000c344af7c>] _do_fork+0x121/0x4f0 kernel/fork.c:2369
      
      Reported-by: syzbot+722da59ccb264bc19910@syzkaller.appspotmail.com
      Fixes: 719c7d56 ("ipvs: Fix use-after-free in ip_vs_in")
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      affa31e6
    • Arnd Bergmann's avatar
      ipsec: select crypto ciphers for xfrm_algo · a275d049
      Arnd Bergmann authored
      [ Upstream commit 597179b0 ]
      
      kernelci.org reports failed builds on arc because of what looks
      like an old missed 'select' statement:
      
      net/xfrm/xfrm_algo.o: In function `xfrm_probe_algs':
      xfrm_algo.c:(.text+0x1e8): undefined reference to `crypto_has_ahash'
      
      I don't see this in randconfig builds on other architectures, but
      it's fairly clear we want to select the hash code for it, like we
      do for all its other users. As Herbert points out, CRYPTO_BLKCIPHER
      is also required even though it has not popped up in build tests.
      
      Fixes: 17bc1970 ("ipsec: Use skcipher and ahash when probing algorithms")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a275d049
    • Julien Thierry's avatar
      arm64: Do not enable IRQs for ct_user_exit · 7e41783d
      Julien Thierry authored
      [ Upstream commit 9034f625 ]
      
      For el0_dbg and el0_error, DAIF bits get explicitly cleared before
      calling ct_user_exit.
      
      When context tracking is disabled, DAIF gets set (almost) immediately
      after. When context tracking is enabled, among the first things done
      is disabling IRQs.
      
      What is actually needed is:
      - PSR.D = 0 so the system can be debugged (should be already the case)
      - PSR.A = 0 so async error can be handled during context tracking
      
      Do not clear PSR.I in those two locations.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7e41783d
    • Minwoo Im's avatar
      nvme-pci: adjust irq max_vector using num_possible_cpus() · 8d81f2b8
      Minwoo Im authored
      [ Upstream commit dad77d63 ]
      
      If the "irq_queues" are greater than num_possible_cpus(),
      nvme_calc_irq_sets() can have irq set_size for HCTX_TYPE_DEFAULT greater
      than it can be afforded.
      2039         affd->set_size[HCTX_TYPE_DEFAULT] = nrirqs - nr_read_queues;
      
      It might cause a WARN() from the irq_build_affinity_masks() like [1]:
      220         if (nr_present < numvecs)
      221                 WARN_ON(nr_present + nr_others < numvecs);
      
      This patch prevents it from the WARN() by adjusting the max_vector value
      from the nvme_setup_irqs().
      
      [1] WARN messages when modprobe nvme write_queues=32 poll_queues=0:
      root@target:~/nvme# nproc
      8
      root@target:~/nvme# modprobe nvme write_queues=32 poll_queues=0
      [   17.925326] nvme nvme0: pci function 0000:00:04.0
      [   17.940601] WARNING: CPU: 3 PID: 1030 at kernel/irq/affinity.c:221 irq_create_affinity_masks+0x222/0x330
      [   17.940602] Modules linked in: nvme nvme_core [last unloaded: nvme]
      [   17.940605] CPU: 3 PID: 1030 Comm: kworker/u17:4 Tainted: G        W         5.1.0+ #156
      [   17.940605] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      [   17.940608] Workqueue: nvme-reset-wq nvme_reset_work [nvme]
      [   17.940609] RIP: 0010:irq_create_affinity_masks+0x222/0x330
      [   17.940611] Code: 4c 8d 4c 24 28 4c 8d 44 24 30 e8 c9 fa ff ff 89 44 24 18 e8 c0 38 fa ff 8b 44 24 18 44 8b 54 24 1c 5a 44 01 d0 41 39 c4 76 02 <0f> 0b 48 89 df 44 01 e5 e8 f1 ce 10 00 48 8b 34 24 44 89 f0 44 01
      [   17.940611] RSP: 0018:ffffc90002277c50 EFLAGS: 00010216
      [   17.940612] RAX: 0000000000000008 RBX: ffff88807ca48860 RCX: 0000000000000000
      [   17.940612] RDX: ffff88807bc03800 RSI: 0000000000000020 RDI: 0000000000000000
      [   17.940613] RBP: 0000000000000001 R08: ffffc90002277c78 R09: ffffc90002277c70
      [   17.940613] R10: 0000000000000008 R11: 0000000000000001 R12: 0000000000000020
      [   17.940614] R13: 0000000000025d08 R14: 0000000000000001 R15: ffff88807bc03800
      [   17.940614] FS:  0000000000000000(0000) GS:ffff88807db80000(0000) knlGS:0000000000000000
      [   17.940616] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   17.940617] CR2: 00005635e583f790 CR3: 000000000240a000 CR4: 00000000000006e0
      [   17.940617] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   17.940618] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   17.940618] Call Trace:
      [   17.940622]  __pci_enable_msix_range+0x215/0x540
      [   17.940623]  ? kernfs_put+0x117/0x160
      [   17.940625]  pci_alloc_irq_vectors_affinity+0x74/0x110
      [   17.940626]  nvme_reset_work+0xc30/0x1397 [nvme]
      [   17.940628]  ? __switch_to_asm+0x34/0x70
      [   17.940628]  ? __switch_to_asm+0x40/0x70
      [   17.940629]  ? __switch_to_asm+0x34/0x70
      [   17.940630]  ? __switch_to_asm+0x40/0x70
      [   17.940630]  ? __switch_to_asm+0x34/0x70
      [   17.940631]  ? __switch_to_asm+0x40/0x70
      [   17.940632]  ? nvme_irq_check+0x30/0x30 [nvme]
      [   17.940633]  process_one_work+0x20b/0x3e0
      [   17.940634]  worker_thread+0x1f9/0x3d0
      [   17.940635]  ? cancel_delayed_work+0xa0/0xa0
      [   17.940636]  kthread+0x117/0x120
      [   17.940637]  ? kthread_stop+0xf0/0xf0
      [   17.940638]  ret_from_fork+0x3a/0x50
      [   17.940639] ---[ end trace aca8a131361cd42a ]---
      [   17.942124] nvme nvme0: 7/1/0 default/read/poll queues
      Signed-off-by: default avatarMinwoo Im <minwoo.im.dev@gmail.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8d81f2b8
    • Heiner Litz's avatar
      lightnvm: pblk: fix freeing of merged pages · dc7cb800
      Heiner Litz authored
      [ Upstream commit 510fd8ea ]
      
      bio_add_pc_page() may merge pages when a bio is padded due to a flush.
      Fix iteration over the bio to free the correct pages in case of a merge.
      Signed-off-by: default avatarHeiner Litz <hlitz@ucsc.edu>
      Reviewed-by: default avatarJavier González <javier@javigon.com>
      Signed-off-by: default avatarMatias Bjørling <mb@lightnvm.io>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dc7cb800
    • Chaitanya Kulkarni's avatar
      nvme-pci: set the errno on ctrl state change error · e05c9c36
      Chaitanya Kulkarni authored
      [ Upstream commit e71afda4 ]
      
      This patch removes the confusing assignment of the variable result at
      the time of declaration and sets the value in error cases next to the
      places where the actual error is happening.
      
      Here we also set the result value to -ENODEV when we fail at the final
      ctrl state transition in nvme_reset_work(). Without this assignment
      result will hold 0 from nvme_setup_io_queue() and on failure 0 will be
      passed to he nvme_remove_dead_ctrl() from final state transition.
      Signed-off-by: default avatarChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e05c9c36
    • Minwoo Im's avatar
      nvme-pci: properly report state change failure in nvme_reset_work · bd3df654
      Minwoo Im authored
      [ Upstream commit cee6c269 ]
      
      If the state change to NVME_CTRL_CONNECTING fails, the dmesg is going to
      be like:
      
        [  293.689160] nvme nvme0: failed to mark controller CONNECTING
        [  293.689160] nvme nvme0: Removing after probe failure status: 0
      
      Even it prints the first line to indicate the situation, the second line
      is not proper because the status is 0 which means normally success of
      the previous operation.
      
      This patch makes it indicate the proper error value when it fails.
        [   25.932367] nvme nvme0: failed to mark controller CONNECTING
        [   25.932369] nvme nvme0: Removing after probe failure status: -16
      
      This situation is able to be easily reproduced by:
        root@target:~# rmmod nvme && modprobe nvme && rmmod nvme
      Signed-off-by: default avatarMinwoo Im <minwoo.im.dev@gmail.com>
      Reviewed-by: default avatarChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bd3df654
    • Anton Eidelman's avatar
      nvme: fix possible io failures when removing multipathed ns · 942c09be
      Anton Eidelman authored
      [ Upstream commit 2181e455 ]
      
      When a shared namespace is removed, we call blk_cleanup_queue()
      when the device can still be accessed as the current path and this can
      result in submission to a dying queue. Hence, direct_make_request()
      called by our mpath device may fail (propagating the failure to userspace).
      Instead, we want to failover this I/O to a different path if one exists.
      Thus, before we cleanup the request queue, we make sure that the device is
      cleared from the current path nor it can be selected again as such.
      
      Fix this by:
      - clear the ns from the head->list and synchronize rcu to make sure there is
        no concurrent path search that restores it as the current path
      - clear the mpath current path in order to trigger a subsequent path search
        and sync srcu to wait for any ongoing request submissions
      - safely continue to namespace removal and blk_cleanup_queue
      Signed-off-by: default avatarAnton Eidelman <anton@lightbitslabs.com>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      942c09be
    • Pan Bian's avatar
      EDAC/sysfs: Fix memory leak when creating a csrow object · 3db69908
      Pan Bian authored
      [ Upstream commit 585fb3d9 ]
      
      In edac_create_csrow_object(), the reference to the object is not
      released when adding the device to the device hierarchy fails
      (device_add()). This may result in a memory leak.
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: https://lkml.kernel.org/r/1555554438-103953-1-git-send-email-bianpan2016@163.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      3db69908
    • Greg KH's avatar
      EDAC/sysfs: Drop device references properly · 4b036124
      Greg KH authored
      [ Upstream commit 7adc05d2 ]
      
      Do put_device() if device_add() fails.
      
       [ bp: do device_del() for the successfully created devices in
         edac_create_csrow_objects(), on the unwind path. ]
      Signed-off-by: default avatarGreg KH <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: https://lkml.kernel.org/r/20190427214925.GE16338@kroah.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      4b036124
    • Tudor Ambarus's avatar
      spi: fix ctrl->num_chipselect constraint · a2fd0a9b
      Tudor Ambarus authored
      [ Upstream commit f9481b08 ]
      
      at91sam9g25ek showed the following error at probe:
      atmel_spi f0000000.spi: Using dma0chan2 (tx) and dma0chan3 (rx)
      for DMA transfers
      atmel_spi: probe of f0000000.spi failed with error -22
      
      Commit 0a919ae4 ("spi: Don't call spi_get_gpio_descs() before device name is set")
      moved the calling of spi_get_gpio_descs() after ctrl->dev is set,
      but didn't move the !ctrl->num_chipselect check. When there are
      chip selects in the device tree, the spi-atmel driver lets the
      SPI core discover them when registering the SPI master.
      The ctrl->num_chipselect is thus expected to be set by
      spi_get_gpio_descs().
      
      Move the !ctlr->num_chipselect after spi_get_gpio_descs() as it was
      before the aforementioned commit. While touching this block, get rid
      of the explicit comparison with 0 and update the commenting style.
      
      Fixes: 0a919ae4 ("spi: Don't call spi_get_gpio_descs() before device name is set")
      Signed-off-by: default avatarTudor Ambarus <tudor.ambarus@microchip.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a2fd0a9b
    • Rafael J. Wysocki's avatar
      ACPICA: Clear status of GPEs on first direct enable · 467ebe42
      Rafael J. Wysocki authored
      [ Upstream commit 44758baf ]
      
      ACPI GPEs (other than the EC one) can be enabled in two situations.
      First, the GPEs with existing _Lxx and _Exx methods are enabled
      implicitly by ACPICA during system initialization.  Second, the
      GPEs without these methods (like GPEs listed by _PRW objects for
      wakeup devices) need to be enabled directly by the code that is
      going to use them (e.g. ACPI power management or device drivers).
      
      In the former case, if the status of a given GPE is set to start
      with, its handler method (either _Lxx or _Exx) needs to be invoked
      to take care of the events (possibly) signaled before the GPE was
      enabled.  In the latter case, however, the first caller of
      acpi_enable_gpe() for a given GPE should not be expected to care
      about any events that might be signaled through it earlier.  In
      that case, it is better to clear the status of the GPE before
      enabling it, to prevent stale events from triggering unwanted
      actions (like spurious system resume, for example).
      
      For this reason, modify acpi_ev_add_gpe_reference() to take an
      additional boolean argument indicating whether or not the GPE
      status needs to be cleared when its reference counter changes from
      zero to one and make acpi_enable_gpe() pass TRUE to it through
      that new argument.
      
      Fixes: 18996f2d ("ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume")
      Reported-by: default avatarFurquan Shaikh <furquan@google.com>
      Tested-by: default avatarFurquan Shaikh <furquan@google.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      467ebe42
    • Dennis Zhou's avatar
      blk-iolatency: only account submitted bios · c8632e34
      Dennis Zhou authored
      [ Upstream commit a3fb01ba ]
      
      As is, iolatency recognizes done_bio and cleanup as ending paths. If a
      request is marked REQ_NOWAIT and fails to get a request, the bio is
      cleaned up via rq_qos_cleanup() and ended in bio_wouldblock_error().
      This results in underflowing the inflight counter. Fix this by only
      accounting bios that were actually submitted.
      Signed-off-by: default avatarDennis Zhou <dennis@kernel.org>
      Cc: Josef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c8632e34
    • Qian Cai's avatar
      x86/cacheinfo: Fix a -Wtype-limits warning · 1d4bf99c
      Qian Cai authored
      [ Upstream commit 1b7aebf0 ]
      
      cpuinfo_x86.x86_model is an unsigned type, so comparing against zero
      will generate a compilation warning:
      
        arch/x86/kernel/cpu/cacheinfo.c: In function 'cacheinfo_amd_init_llc_id':
        arch/x86/kernel/cpu/cacheinfo.c:662:19: warning: comparison is always true \
          due to limited range of data type [-Wtype-limits]
      
      Remove the unnecessary lower bound check.
      
       [ bp: Massage. ]
      
      Fixes: 68091ee7 ("x86/CPU/AMD: Calculate last level cache ID from number of sharing threads")
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Pu Wen <puwen@hygon.cn>
      Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/1560954773-11967-1-git-send-email-cai@lca.pwSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d4bf99c
    • Ilias Apalodimas's avatar
      net: netsec: initialize tx ring on ndo_open · a98c1517
      Ilias Apalodimas authored
      [ Upstream commit 39e3622e ]
      
      Since we changed the Tx ring handling and now depends on bit31 to figure
      out the owner of the descriptor, we should initialize this every time
      the device goes down-up instead of doing it once on driver init. If the
      value is not correctly initialized the device won't have any available
      descriptors
      
      Changes since v1:
      - Typo fixes
      
      Fixes: 35e07d23 ("net: socionext: remove mmio reads on Tx")
      Signed-off-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a98c1517
    • Mika Westerberg's avatar
      PCI: Add missing link delays required by the PCIe spec · 3c795a8e
      Mika Westerberg authored
      [ Upstream commit c2bf1fc2 ]
      
      Currently Linux does not follow PCIe spec regarding the required delays
      after reset. A concrete example is a Thunderbolt add-in-card that
      consists of a PCIe switch and two PCIe endpoints:
      
        +-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
                                        +-01.0-[04-36]-- DS hotplug port
                                        +-02.0-[37]----00.0 xHCI controller
                                        \-04.0-[38-6b]-- DS hotplug port
      
      The root port (1b.0) and the PCIe switch downstream ports are all PCIe
      gen3 so they support 8GT/s link speeds.
      
      We wait for the PCIe hierarchy to enter D3cold (runtime):
      
        pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
      
      When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
      PCIe switch is put to reset and its power is re-applied. This means that
      we must follow the rules in PCIe 4.0 section 6.6.1.
      
      For the PCIe gen3 ports we are dealing with here, the following applies:
      
        With a Downstream Port that supports Link speeds greater than 5.0
        GT/s, software must wait a minimum of 100 ms after Link training
        completes before sending a Configuration Request to the device
        immediately below that Port. Software can determine when Link training
        completes by polling the Data Link Layer Link Active bit or by setting
        up an associated interrupt (see Section 6.7.3.3).
      
      Translating this into the above topology we would need to do this (DLLLA
      stands for Data Link Layer Link Active):
      
        pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
        pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
        pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
      
      I've instrumented the kernel with additional logging so we can see the
      actual delays the kernel performs:
      
        pcieport 0000:00:1b.0: power state changed by ACPI to D0
        pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
        pcieport 0000:00:1b.0: waking up bus
        pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
        pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
        ...
        pcieport 0000:00:1b.0: PME# disabled
        pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        ...
        pcieport 0000:01:00.0: PME# disabled
        pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        ...
        pcieport 0000:02:00.0: PME# disabled
        pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        ...
        pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
        pcieport 0000:02:01.0: PME# disabled
        pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        ...
        pcieport 0000:02:02.0: PME# disabled
        pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        ...
        pcieport 0000:02:04.0: PME# disabled
        pcieport 0000:02:01.0: PME# enabled
        pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
        pcieport 0000:02:04.0: PME# enabled
        pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
        thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
        ...
        thunderbolt 0000:03:00.0: PME# disabled
        xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
        ...
        xhci_hcd 0000:37:00.0: PME# disabled
      
      For the switch upstream port (01:00.0) we wait for 100ms but not taking
      into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
      transition of the root port and the two downstream hotplug ports. This
      means that we deviate from what the spec requires.
      
      Performing the same check for system sleep (s2idle) transitions we can
      see following when resuming from s2idle:
      
        pcieport 0000:00:1b.0: power state changed by ACPI to D0
        pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
        ...
        pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        ...
        pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
        pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
        pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
        pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
        pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
        pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
        pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
        pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
        pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
        pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
        pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
        pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
        pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
        pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
        pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
        pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
        pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
        pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
        pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
        pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
        pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
        pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
        pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
        pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
        pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
        pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
        pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
        pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
        pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
        pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
        pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
        pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
        pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
        xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
        ...
        thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
      
      This is even worse. None of the mandatory delays are performed. If this
      would be S3 instead of s2idle then according to PCI FW spec 3.2 section
      4.6.8.  there is a specific _DSM that allows the OS to skip the delays
      but this platform does not provide the _DSM and does not go to S3 anyway
      so no firmware is involved that could already handle these delays.
      
      In this particular Intel Coffee Lake platform these delays are not
      actually needed because there is an additional delay as part of the ACPI
      power resource that is used to turn on power to the hierarchy but since
      that additional delay is not required by any of standards (PCIe, ACPI)
      it is not present in the Intel Ice Lake, for example where missing the
      mandatory delays causes pciehp to start tearing down the stack too early
      (links are not yet trained).
      
      For this reason, change the PCIe portdrv PM resume hooks so that they
      perform the mandatory delays before the downstream component gets
      resumed. We perform the delays before port services are resumed because
      otherwise pciehp might find that the link is not up (even if it is just
      training) and tears-down the hierarchy.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3c795a8e
    • Alexei Starovoitov's avatar
      bpf: fix callees pruning callers · 70cc29db
      Alexei Starovoitov authored
      [ Upstream commit eea1c227 ]
      
      The commit 7640ead9 partially resolved the issue of callees
      incorrectly pruning the callers.
      With introduction of bounded loops and jmps_processed heuristic
      single verifier state may contain multiple branches and calls.
      It's possible that new verifier state (for future pruning) will be
      allocated inside callee. Then callee will exit (still within the same
      verifier state). It will go back to the caller and there R6-R9 registers
      will be read and will trigger mark_reg_read. But the reg->live for all frames
      but the top frame is not set to LIVE_NONE. Hence mark_reg_read will fail
      to propagate liveness into parent and future walking will incorrectly
      conclude that the states are equivalent because LIVE_READ is not set.
      In other words the rule for parent/live should be:
      whenever register parentage chain is set the reg->live should be set to LIVE_NONE.
      is_state_visited logic already follows this rule for spilled registers.
      
      Fixes: 7640ead9 ("bpf: verifier: make sure callees don't prune with caller differences")
      Fixes: f4d7e40a ("bpf: introduce function calls (verification)")
      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>
      70cc29db
    • Nilkanth Ahirrao's avatar
      ASoC: rsnd: fixup mod ID calculation in rsnd_ctu_probe_ · f89b29fa
      Nilkanth Ahirrao authored
      [ Upstream commit ac28ec07 ]
      
      commit c16015f3 ("ASoC: rsnd: add .get_id/.get_id_sub")
      introduces rsnd_ctu_id which calcualates and gives
      the main Device id of the CTU by dividing the id by 4.
      rsnd_mod_id uses this interface to get the CTU main
      Device id. But this commit forgets to revert the main
      Device id calcution previously done in rsnd_ctu_probe_
      which also divides the id by 4. This path corrects the
      same to get the correct main Device id.
      
      The issue is observered when rsnd_ctu_probe_ is done for CTU1
      
      Fixes: c16015f3 ("ASoC: rsnd: add .get_id/.get_id_sub")
      Signed-off-by: default avatarNilkanth Ahirrao <anilkanth@jp.adit-jv.com>
      Signed-off-by: default avatarSuresh Udipi <sudipi@jp.adit-jv.com>
      Signed-off-by: default avatarJiada Wang <jiada_wang@mentor.com>
      Acked-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f89b29fa
    • Denis Kirjanov's avatar
      ipoib: correcly show a VF hardware address · c545bda3
      Denis Kirjanov authored
      [ Upstream commit 64d701c6 ]
      
      in the case of IPoIB with SRIOV enabled hardware
      ip link show command incorrecly prints
      0 instead of a VF hardware address.
      
      Before:
      11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
      state UP mode DEFAULT group default qlen 256
          link/infiniband
      80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
      00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
          vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state disable,
      trust off, query_rss off
      ...
      After:
      11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
      state UP mode DEFAULT group default qlen 256
          link/infiniband
      80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
      00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
          vf 0     link/infiniband
      80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
      00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof
      checking off, link-state disable, trust off, query_rss off
      
      v1->v2: just copy an address without modifing ifla_vf_mac
      v2->v3: update the changelog
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Acked-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c545bda3