1. 04 Sep, 2018 34 commits
  2. 31 Aug, 2018 6 commits
    • Lorenzo Bianconi's avatar
      mt76: verify evt type in usb mcu response · ac5d5b3f
      Lorenzo Bianconi authored
      Verify if evt field is set to EVT_CMD_DONE in usb mcu
      response messages. This is a preliminary patch for usb_mcu layer
      unification between mt76x0u and mt76x2u driver.
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      ac5d5b3f
    • Lorenzo Bianconi's avatar
      mt76x2u: run device cleanup routine if resume fails · 9b2fd48d
      Lorenzo Bianconi authored
      Cleanup {tx,rx} and mcu queues if resume operation fails
      
      Fixes: ee676cd5 ("mt76: add driver code for MT76x2u based devices")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      9b2fd48d
    • Geert Uytterhoeven's avatar
      mt76: Fix comparisons with invalid hardware key index · 81c8eccc
      Geert Uytterhoeven authored
      With gcc 4.1.2:
      
          drivers/net/wireless/mediatek/mt76/mt76x0/tx.c: In function ‘mt76x0_tx’:
          drivers/net/wireless/mediatek/mt76/mt76x0/tx.c:169: warning: comparison is always true due to limited range of data type
          drivers/net/wireless/mediatek/mt76/mt76x2_tx_common.c: In function ‘mt76x2_tx’:
          drivers/net/wireless/mediatek/mt76/mt76x2_tx_common.c:35: warning: comparison is always true due to limited range of data type
      
      While assigning -1 to a u8 works fine, comparing with -1 does not work
      as expected.
      
      Fix this by comparing with 0xff, like is already done in some other
      places.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      81c8eccc
    • Siva Rebbagondla's avatar
      rsi: improve kernel thread handling to fix kernel panic · 4c62764d
      Siva Rebbagondla authored
      While running regressions, observed below kernel panic when sdio disconnect
      called. This is because of, kthread_stop() is taking care of
      wait_for_completion() by default. When wait_for_completion triggered
      in kthread_stop and as it was done already, giving kernel panic.
      Hence, removing redundant wait_for_completion() from rsi_kill_thread().
      
      ... skipping ...
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50
      PGD 0
      Oops: 0002 [#1] SMP
      CPU: 0 PID: 6502 Comm: rmmod Tainted: G  OE   4.15.9-Generic #154-Ubuntu
      Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017
      Stack:
      ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000
      ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000
      ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15
      Call Trace:
      [<ffffffff8108160a>] __put_task_struct+0x5a/0x140
      [<ffffffff810a484b>] kthread_stop+0x10b/0x110
      [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio]
      [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80
      [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100
      [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150
      [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0
      [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0
      [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50
      [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20
      [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio]
      [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210
      [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb
      Signed-off-by: default avatarSiva Rebbagondla <siva.rebbagondla@redpinesignals.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      4c62764d
    • Siva Rebbagondla's avatar
      rsi: fix memory alignment issue in ARM32 platforms · baa8caf4
      Siva Rebbagondla authored
      During testing in ARM32 platforms, observed below kernel panic, as driver
      accessing data beyond the allocated memory while submitting URB to USB.
      
      Fix: Resolved this by specifying correct length by considering 64 bit
      alignment. so that, USB bus driver will access only allocated memory.
      
      Unit-test: Tested and confirm that driver bring up and scanning,
      connection and data transfer works fine with this fix.
      
      ...skipping...
      [   25.389450] Unable to handle kernel paging request at virtual
      	       address 5aa11422
      [   25.403078] Internal error: Oops: 5 [#1] SMP ARM
      [   25.407703] Modules linked in: rsi_usb
      [   25.411473] CPU: 1 PID: 317 Comm: RX-Thread Not tainted 4.18.0-rc7 #1
      [   25.419221] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      [   25.425764] PC is at skb_release_data+0x90/0x168
      [   25.430393] LR is at skb_release_all+0x28/0x2c
      [   25.434842] pc : [<807435b0>] lr : [<80742ba0>] psr: 200e0013 5aa1141e
      [   25.464633] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32 ISA ARM Segment none
      [   25.477524] Process RX-Thread (pid: 317, stack limit = 0x(ptrval))
      [   25.483709] Stack: (0xedf69ed8 to 0xedf6a000)
      [   25.569907] Backtrace:
      [   25.572368] [<80743520>] (skb_release_data) from [<80742ba0>]
      	       (skb_release_all+0x28/0x2c)
      [   25.580555] r9:7f00258c r8:00000001 r7:ee355000 r6:eddab0d0
      	       r5:eddab000 r4:eddbb840
      [   25.588308] [<80742b78>] (skb_release_all) from [<807432cc>]
      	       (consume_skb+0x30/0x50)
      [   25.596055] r5:eddab000 r4:eddbb840
      [   25.599648] [<8074329c>] (consume_skb) from [<7f00117c>]
      	       (rsi_usb_rx_thread+0x64/0x12c [rsi_usb])
      [   25.608524] r5:eddab000 r4:eddbb840
      [   25.612116] [<7f001118>] (rsi_usb_rx_thread [rsi_usb]) from
      	       [<80142750>] (kthread+0x11c/0x15c)
      [   25.620735] r10:ee9ff9e0 r9:edcde3b8 r8:ee355000 r7:edf68000
      	       r6:edd3a780 r5:00000000
      [   25.628567] r4:edcde380
      [   25.631110] [<80142634>] (kthread) from [<801010e8>]
      	       (ret_from_fork+0x14/0x2c)
      [   25.638336] Exception stack(0xedf69fb0 to 0xedf69ff8)
      [   25.682929] ---[ end trace 8236a5496f5b5d3b ]---
      Signed-off-by: default avatarSiva Rebbagondla <siva.rebbagondla@redpinesignals.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      baa8caf4
    • Rasmus Villemoes's avatar
      brcmfmac: fix wrong strnchr usage · cb18e2e9
      Rasmus Villemoes authored
      strnchr takes arguments in the order of its name: string, max bytes to
      read, character to search for. Here we're passing '\n' aka 10 as the
      buffer size, and searching for sizeof(buf) aka BRCMF_DCMD_SMLEN aka
      256 (aka '\0', since it's implicitly converted to char) within those 10
      bytes.
      
      Just interchanging the last two arguments would still leave a bug,
      because if we've been successful once, there are not sizeof(buf)
      characters left after the new value of p.
      
      Since clmver is immediately afterwards passed as a %s argument, I assume
      that it is actually a properly nul-terminated string. For that case, we
      have strreplace().
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      cb18e2e9