1. 18 4月, 2021 1 次提交
    • M
      rsi: Use resume_noirq for SDIO · c434e5e4
      Marek Vasut 提交于
      The rsi_resume() does access the bus to enable interrupts on the RSI
      SDIO WiFi card, however when calling sdio_claim_host() in the resume
      path, it is possible the bus is already claimed and sdio_claim_host()
      spins indefinitelly. Enable the SDIO card interrupts in resume_noirq
      instead to prevent anything else from claiming the SDIO bus first.
      
      Fixes: 20db0733 ("rsi: sdio suspend and resume support")
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com>
      Cc: Angus Ainslie <angus@akkea.ca>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: Karun Eagalapati <karun256@gmail.com>
      Cc: Martin Kepplinger <martink@posteo.de>
      Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
      Cc: Siva Rebbagondla <siva8118@gmail.com>
      Cc: netdev@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20210327235932.175896-1-marex@denx.de
      c434e5e4
  2. 18 3月, 2021 1 次提交
  3. 11 11月, 2020 1 次提交
    • M
      rsi: Move card interrupt handling to RX thread · 28743146
      Marek Vasut 提交于
      The interrupt handling of the RS911x is particularly heavy. For each RX
      packet, the card does three SDIO transactions, one to read interrupt
      status register, one to RX buffer length, one to read the RX packet(s).
      This translates to ~330 uS per one cycle of interrupt handler. In case
      there is more incoming traffic, this will be more.
      
      The drivers/mmc/core/sdio_irq.c has the following comment, quote "Just
      like traditional hard IRQ handlers, we expect SDIO IRQ handlers to be
      quick and to the point, so that the holding of the host lock does not
      cover too much work that doesn't require that lock to be held."
      
      The RS911x interrupt handler does not fit that. This patch therefore
      changes it such that the entire IRQ handler is moved to the RX thread
      instead, and the interrupt handler only wakes the RX thread.
      
      This is OK, because the interrupt handler only does things which can
      also be done in the RX thread, that is, it checks for firmware loading
      error(s), it checks buffer status, it checks whether a packet arrived
      and if so, reads out the packet and passes it to network stack.
      
      Moreover, this change permits removal of a code which allocated an
      skbuff only to get 4-byte-aligned buffer, read up to 8kiB of data
      into the skbuff, queue this skbuff into local private queue, then in
      RX thread, this buffer is dequeued, the data in the skbuff as passed
      to the RSI driver core, and the skbuff is deallocated. All this is
      replaced by directly calling the RSI driver core with local buffer.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Angus Ainslie <angus@akkea.ca>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Martin Kepplinger <martink@posteo.de>
      Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
      Cc: Siva Rebbagondla <siva8118@gmail.com>
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Tested-by: NMartin Kepplinger <martin.kepplinger@puri.sm>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20201103180941.443528-1-marex@denx.de
      28743146
  4. 01 9月, 2020 1 次提交
    • L
      rsi: rsi_91x_sdio: Fix a few kernel-doc related issues · 64403dc3
      Lee Jones 提交于
      - File headers do not make for good kernel-doc candidates
       - Kernel-doc header lines should start with " *"
       - Fix doc-rot issue
      
      Fixes the following W=1 kernel build warning(s):
      
       drivers/net/wireless/rsi/rsi_91x_sdio.c:25: warning: cannot understand function prototype: 'u16 dev_oper_mode = DEV_OPMODE_STA_BT_DUAL; '
       drivers/net/wireless/rsi/rsi_91x_sdio.c:802: warning: bad line:                                    from the device.
       drivers/net/wireless/rsi/rsi_91x_sdio.c:842: warning: Function parameter or member 'pfunction' not described in 'rsi_init_sdio_interface'
       drivers/net/wireless/rsi/rsi_91x_sdio.c:842: warning: Excess function parameter 'pkt' description in 'rsi_init_sdio_interface'
      
      Cc: Amitkumar Karwar <amitkarwar@gmail.com>
      Cc: Siva Rebbagondla <siva8118@gmail.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200826093401.1458456-17-lee.jones@linaro.org
      64403dc3
  5. 13 7月, 2020 1 次提交
  6. 13 2月, 2020 1 次提交
  7. 06 8月, 2019 2 次提交
  8. 24 7月, 2019 1 次提交
  9. 28 5月, 2019 1 次提交
  10. 26 4月, 2019 3 次提交
  11. 19 2月, 2019 1 次提交
  12. 08 2月, 2019 3 次提交
  13. 01 2月, 2019 1 次提交
  14. 31 7月, 2018 1 次提交
  15. 25 4月, 2018 3 次提交
    • S
      rsi: Fix 'invalid vdd' warning in mmc · 78e45071
      Siva Rebbagondla 提交于
      While performing cleanup, driver is messing with card->ocr
      value by not masking rocr against ocr_avail. Below panic
      is observed with some of the SDIO host controllers due to
      this. Issue is resolved by reverting incorrect modifications
      to vdd.
      
      [  927.423821] mmc1: Invalid vdd 0x1f
      [  927.423925] Modules linked in: rsi_sdio(+) cmac bnep arc4 rsi_91x
      	       mac80211 cfg80211 btrsi rfcomm bluetooth ecdh_generic
      [  927.424073] CPU: 0 PID: 1624 Comm: insmod Tainted: G		W        4.15.0-1000-caracalla #1
      [  927.424075] Hardware name: Dell Inc. Edge Gateway	3003/      , BIOS 01.00.06 01/22/2018
      [  927.424082] RIP: 0010:sdhci_set_power_noreg+0xdd/0x190[sdhci]
      [  927.424085] RSP: 0018:ffffac3fc064b930 EFLAGS:  00010282
      [  927.424107] Call Trace:
      [  927.424118]  sdhci_set_power+0x5a/0x60 [sdhci]
      [  927.424125]  sdhci_set_ios+0x360/0x3b0 [sdhci]
      [  927.424133]  mmc_set_initial_state+0x92/0x120
      [  927.424137]  mmc_power_up.part.34+0x33/0x1d0
      [  927.424141]  mmc_power_up+0x17/0x20
      [  927.424147]  mmc_sdio_runtime_resume+0x2d/0x50
      [  927.424151]  mmc_runtime_resume+0x17/0x20
      [  927.424156]  __rpm_callback+0xc4/0x200
      [  927.424161]  ? idr_alloc_cyclic+0x57/0xd0
      [  927.424165]  ? mmc_runtime_suspend+0x20/0x20
      [  927.424169]  rpm_callback+0x24/0x80
      [  927.424172]  ? mmc_runtime_suspend+0x20/0x20
      [  927.424176]  rpm_resume+0x4b3/0x6c0
      [  927.424181]  __pm_runtime_resume+0x4e/0x80
      [  927.424188]  driver_probe_device+0x41/0x490
      [  927.424192]  __driver_attach+0xdf/0xf0
      [  927.424196]  ? driver_probe_device+0x490/0x490
      [  927.424201]  bus_for_each_dev+0x6c/0xc0
      [  927.424205]  driver_attach+0x1e/0x20
      [  927.424209]  bus_add_driver+0x1f4/0x270
      [  927.424217]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
      [  927.424221]  driver_register+0x60/0xe0
      [  927.424227]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
      [  927.424231]  sdio_register_driver+0x20/0x30
      [  927.424237]  rsi_module_init+0x16/0x40 [rsi_sdio]
      Signed-off-by: NSiva Rebbagondla <siva.rebbagondla@redpinesignals.com>
      Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      78e45071
    • S
      rsi: fix nommu_map_sg overflow kernel panic · f7005466
      Siva Rebbagondla 提交于
      Following overflow kernel panic is observed on some platforms while
      loading the driver. It is fixed if dynamically allocated memory is
      passed to SDIO instead of static one
      
      [  927.513963] nommu_map_sg: overflow 17d54064ba7c+20 of device mask ffffffff
      [  927.517712] Modules linked in: rsi_sdio(+) cmac bnep arc4 rsi_91x mac80211 cfg80211
      	       btrsi rfcomm bluetooth ecdh_generic snd_soc_sst_bytcr_rt5660
      [  927.517861] CPU: 0 PID: 1624 Comm: insmod Tainted: G W 4.15.0-1000 #1
      [  927.517870] RIP: 0010:sdhci_send_command+0x5f0/0xa90 [sdhci]
      [  927.517873] RSP: 0000:ffffac3fc064b6d8 EFLAGS: 00010086
      [  927.517895] Call Trace:
      [  927.517908]  ? __schedule+0x3cd/0x890
      [  927.517915]  ? mod_timer+0x17b/0x3c0
      [  927.517922]  sdhci_request+0x7c/0xf0 [sdhci]
      [  927.517928]  __mmc_start_request+0x5a/0x170
      [  927.517932]  mmc_start_request+0x74/0x90
      [  927.517936]  mmc_wait_for_req+0x87/0xe0
      [  927.517940]  mmc_io_rw_extended+0x2fd/0x330
      [  927.517946]  ? mmc_wait_data_done+0x30/0x30
      [  927.517951]  sdio_io_rw_ext_helper+0x160/0x210
      [  927.517956]  sdio_writesb+0x1d/0x20
      [  927.517966]	rsi_sdio_write_register_multiple+0x68/0x110 [rsi_sdio]
      [  927.517976]  rsi_hal_device_init+0x357/0x910 [rsi_91x]
      [  927.517983]  ? rsi_hal_device_init+0x357/0x910 [rsi_91x]
      [  927.517990]  rsi_probe+0x2c6/0x450 [rsi_sdio]
      [  927.517995]  sdio_bus_probe+0xfc/0x110
      [  927.518000]  driver_probe_device+0x2b3/0x490
      [  927.518005]  __driver_attach+0xdf/0xf0
      [  927.518008]  ? driver_probe_device+0x490/0x490
      [  927.518014]  bus_for_each_dev+0x6c/0xc0
      [  927.518018]  driver_attach+0x1e/0x20
      [  927.518021]  bus_add_driver+0x1f4/0x270
      [  927.518028]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
      [  927.518031]  driver_register+0x60/0xe0
      [  927.518038]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
      [  927.518041]  sdio_register_driver+0x20/0x30
      [  927.518047]  rsi_module_init+0x16/0x40 [rsi_sdio]
      Signed-off-by: NSiva Rebbagondla <siva.rebbagondla@redpinesignals.com>
      Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      f7005466
    • D
      rsi: remove unecessary PTR_ALIGN()s · 350fcdb8
      Dan Carpenter 提交于
      The issue here is that we allocate "data" and then set
      "data = PTR_ALIGN(data, 8);" and then we free the aligned pointer
      instead of the original pointer.
      
      kmalloc() pointers are already ARCH_SLAB_MINALIGN aligned which is 8 or
      more on everything except certain Xtensa variants.  We decided that if
      the Xtensa people ever notice a bug here then we'll tell them the bug is
      on their side.  ;)
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      350fcdb8
  16. 27 3月, 2018 3 次提交
    • A
      rsi: fix kernel panic observed on 64bit machine · 864db4d5
      Amitkumar Karwar 提交于
      Following kernel panic is observed on 64bit machine while loading
      the driver. It is fixed if we pass dynamically allocated memory to
      SDIO for DMA.
      
      BUG: unable to handle kernel paging request at ffffeb04000172e0
      IP: sg_miter_stop+0x56/0x70
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      Modules linked in: rsi_sdio(OE+) rsi_91x(OE) btrsi(OE) rfcomm bluetooth
      ecdh_generic mac80211 mmc_block fuse xt_CHECKSUM iptable_mangle
      drm_kms_helper mmc_core serio_raw drm firewire_ohci tg3
      CPU: 0 PID: 4003 Comm: insmod Tainted: G           OE    4.16.0-rc1+ #27
      Hardware name: Dell Inc. Latitude E5500                  /0DW634, BIOS
      A19 06/13/2013
      RIP: 0010:sg_miter_stop+0x56/0x70
      RSP: 0018:ffff88007d003e78 EFLAGS: 00010002
      RAX: 0000000000000003 RBX: 0000000000000004 RCX: 0000000000000000
      RDX: ffffeb04000172c0 RSI: ffff88002f58002c RDI: ffff88007d003e80
      RBP: 0000000000000004 R08: ffff88007d003e80 R09: 0000000000000008
      R10: 0000000000000003 R11: 0000000000000001 R12: 0000000000000004
      R13: ffff88002f580028 R14: 0000000000000000 R15: 0000000000000004
      FS:  00007f35c29db700(0000) GS:ffff88007d000000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffeb04000172e0 CR3: 000000007038e000 CR4: 00000000000406f0
      Call Trace:
      <IRQ>
      sg_copy_buffer+0xc6/0xf0
      sdhci_tasklet_finish+0x170/0x260 [sdhci]
      tasklet_action+0xf4/0x100
      __do_softirq+0xef/0x26e
      irq_exit+0xbe/0xd0
      do_IRQ+0x4a/0xc0
      common_interrupt+0xa2/0xa2
      </IRQ>
      Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      864db4d5
    • A
      rsi: fix error path handling in SDIO probe · 90b12aeb
      Amitkumar Karwar 提交于
      We miss to release IRQ in certain error path in SDIO probe which
      causes following kernel panic. This patch corrects error path
      handling
      
      BUG: unable to handle kernel NULL pointer dereference at        (null)
      IP:           (null)
      PGD 0 P4D 0
      Oops: 0010 [#1] SMP PTI
      Call Trace:
       <IRQ>
       ? call_timer_fn+0x29/0x120
       ? run_timer_softirq+0x1da/0x420
       ? timer_interrupt+0x11/0x20
       ? __do_softirq+0xef/0x26e
       ? irq_exit+0xbe/0xd0
       ? do_IRQ+0x4a/0xc0
       ? common_interrupt+0xa2/0xa2
       </IRQ>
       ? cpuidle_enter_state+0x118/0x250
       ? do_idle+0x186/0x1e0
       ? cpu_startup_entry+0x6f/0x80
       ? start_kernel+0x47c/0x49c
       ? secondary_startup_64+0xa5/0xb0
      
      Fixes: 50117605 ("rsi: improve RX handling in SDIO interface")
      Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      90b12aeb
    • T
      rsi: Remove stack VLA usage · 44f98a93
      Tobin C. Harding 提交于
      The use of stack Variable Length Arrays needs to be avoided, as they
      can be a vector for stack exhaustion, which can be both a runtime bug
      (kernel Oops) or a security flaw (overwriting memory beyond the
      stack). Also, in general, as code evolves it is easy to lose track of
      how big a VLA can get. Thus, we can end up having runtime failures
      that are hard to debug. As part of the directive[1] to remove all VLAs
      from the kernel, and build with -Wvla.
      
      Currently rsi code uses a VLA based on a function argument to
      `rsi_sdio_load_data_master_write()`.  The function call chain is
      
      Both these functions
      
      	rsi_sdio_reinit_device()
      	rsi_probe()
      
      start the call chain:
      
      	rsi_hal_device_init()
      	rsi_load_fw()
      	auto_fw_upgrade()
      	ping_pong_write()
      	rsi_sdio_load_data_master_write()
      
      [Without familiarity with the code] it appears that none of the 4 locks
      
      	mutex
      	rx_mutex
      	tx_mutex
      	tx_bus_mutex
      
      are held when `rsi_sdio_load_data_master_write()` is called.  It is therefore
      safe to use kmalloc with GFP_KERNEL.
      
      We can avoid using the VLA by using `kmalloc()` and free'ing the memory on all
      exit paths.
      
      Change buffer from 'u8 array' to 'u8 *'.  Call `kmalloc()` to allocate memory for
      the buffer.  Using goto statement to call `kfree()` on all return paths.
      
      It can be expected that this patch will result in a small increase in overhead
      due to the use of `kmalloc()` however this code is only called on initialization
      (and re-initialization) so this overhead should not degrade performance.
      
      [1] https://lkml.org/lkml/2018/3/7/621Signed-off-by: NTobin C. Harding <me@tobin.cc>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      44f98a93
  17. 14 3月, 2018 4 次提交
  18. 03 11月, 2017 1 次提交
  19. 30 10月, 2017 3 次提交
  20. 25 9月, 2017 1 次提交
  21. 31 8月, 2017 1 次提交
  22. 08 8月, 2017 1 次提交
  23. 28 7月, 2017 4 次提交