1. 04 Sep, 2018 36 commits
  2. 31 Aug, 2018 4 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