1. 04 Sep, 2018 32 commits
  2. 31 Aug, 2018 8 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
    • Dan Carpenter's avatar
      rt2x00: use simple_read_from_buffer() · f483039c
      Dan Carpenter authored
      The problem with this copy_to_user() calls is that they don't ensure
      that "size" is less than the "length" which the user provided.
      
      Obviously, this is debugfs and "size" is normally going to be very small
      so it probably doesn't matter, but this is the correct thing to do.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      f483039c
    • Ganapathi Bhat's avatar
      mwifex: free rx_cmd skb in suspended state · 33a164fa
      Ganapathi Bhat authored
      USB suspend handler will kill the presubmitted rx_cmd URB. This
      triggers a call to the corresponding URB complete handler, which
      will free the rx_cmd skb, associated with rx_cmd URB. Due to a
      possible race betwen suspend handler and main thread, depicted in
      'commit bfcacac6c84b ("mwifiex: do no submit URB in suspended
      state")', it is possible that the rx_cmd skb will fail to get
      freed. This causes a memory leak, since the resume handler will
      always allocate a new rx_cmd skb.
      
      To fix this, free the rx_cmd skb in mwifiex_usb_submit_rx_urb, if
      the device is in suspended state.
      Signed-off-by: default avatarVidya Dharmaraju <vidyad@marvell.com>
      Signed-off-by: default avatarCathy Luo <cluo@marvell.com>
      Signed-off-by: default avatarGanapathi Bhat <gbhat@marvell.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      33a164fa