1. 06 8月, 2019 2 次提交
  2. 24 7月, 2019 1 次提交
  3. 28 5月, 2019 1 次提交
  4. 26 4月, 2019 3 次提交
  5. 19 2月, 2019 1 次提交
  6. 08 2月, 2019 3 次提交
  7. 01 2月, 2019 1 次提交
  8. 31 7月, 2018 1 次提交
  9. 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
  10. 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
  11. 14 3月, 2018 4 次提交
  12. 03 11月, 2017 1 次提交
  13. 30 10月, 2017 3 次提交
  14. 25 9月, 2017 1 次提交
  15. 31 8月, 2017 1 次提交
  16. 08 8月, 2017 1 次提交
  17. 28 7月, 2017 4 次提交
  18. 21 6月, 2017 1 次提交
  19. 24 5月, 2017 4 次提交
  20. 20 6月, 2014 1 次提交