Skip to content

L
linux
Switch branch/tag
  1. 04 Sep, 2018 31 commits
  3. 31 Aug, 2018 9 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
    • Ganapathi Bhat's avatar
      mwifiex: do no submit URB in suspended state · 7bd4628c
      Ganapathi Bhat authored 
      There is a possible race between USB suspend and main thread:

1. After processing the command response, main thread will submit
rx_cmd URB back so as to process next command response, by
calling mwifiex_usb_submit_rx_urb.

2. During USB suspend, the suspend handler will check if rx_cmd
URB is pending(submitted) and if true, kill this URB.

There is a possible race between #1 and #2, where rx_cmd URB will
be submitted by main thread(#1) after the suspend handler check
in #2.

To fix this, check if device is already suspended in
mwifiex_usb_submit_rx_urb, in which case do not submit the URB.
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>
      7bd4628c
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7